# LLM 기반 해킹용 익스플로잇 생성의 산업화가 다가온다 > Clean Markdown view of GeekNews topic #25993. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25993](https://news.hada.io/topic?id=25993) - GeekNews Markdown: [https://news.hada.io/topic/25993.md](https://news.hada.io/topic/25993.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-21T08:33:02+09:00 - Updated: 2026-01-21T08:33:02+09:00 - Original source: [sean.heelan.io](https://sean.heelan.io/2026/01/18/on-the-coming-industrialisation-of-exploit-generation-with-llms/) - Points: 9 - Comments: 1 ## Summary LLM이 **제로데이 익스플로잇을 자율적으로 생성**하는 단계에 도달했습니다. Opus 4.5와 GPT‑5.2는 QuickJS 취약점을 대상으로 6개 시나리오에서 40여 개의 익스플로잇을 만들어내며, 코드 분석·디버깅·체인 구성까지 스스로 수행했습니다. 실험은 익스플로잇 개발이 인간 해커의 역량이 아니라 **토큰 처리량에 의해 제한될 수 있음**을 보여주며, 향후 사이버 공격 자동화와 보안 평가 체계의 근본적 재설계를 요구합니다. ## Topic Body - Opus 4.5와 GPT-5.2 기반 **에이전트가 QuickJS 제로데이 취약점**을 이용해 6가지 시나리오에서 40개 이상의 익스플로잇을 생성 - GPT-5.2는 모든 과제를 해결했고, Opus 4.5는 두 개를 제외한 모든 과제를 해결하며 **자율적 코드 분석·디버깅·익스플로잇 체인 구성 능력**을 보임 - 실험 결과, **익스플로잇 개발이 인간 해커 수가 아닌 토큰 처리량에 의해 제한될 가능성**이 제시됨 - 취약점 탐지와 익스플로잇 생성은 이미 토큰 투입량에 비례해 성과가 증가하는 단계에 도달 - 향후 **사이버 공격 자동화와 보안 평가 체계의 재정비 필요성**이 강조됨 --- ### 실험 개요 - Opus 4.5와 GPT-5.2를 이용해 QuickJS 자바스크립트 인터프리터의 **제로데이 취약점**을 대상으로 익스플로잇 생성 실험 수행 - 다양한 **익스플로잇 완화 기법**(ASLR, NX, RELRO, CFI, 섀도 스택, seccomp 등)을 적용 - 에이전트는 **쉘 생성, 파일 쓰기, C2 연결** 등 여러 목표를 달성 - GPT-5.2는 모든 시나리오를 해결했고, Opus 4.5는 두 개를 제외한 모든 과제를 해결 - 각 실행은 최대 3천만 토큰 제한, 약 30달러 비용 - 가장 어려운 과제에서는 5천만 토큰, 약 3시간, 50달러 비용으로 해결 - GPT-5.2는 seccomp 샌드박스와 섀도 스택이 활성화된 환경에서 **glibc의 exit 핸들러 체인을 이용한 7단계 함수 호출**로 파일 쓰기 익스플로잇을 완성 ### 실험의 한계 - QuickJS는 실제 브라우저 엔진보다 **규모와 복잡도가 훨씬 작음**, 따라서 결과의 일반화에는 한계 존재 - 생성된 익스플로잇은 **보호기법 자체의 새로운 취약점**을 발견한 것은 아니며, 기존에 알려진 **배포상의 취약 지점**을 활용 - QuickJS 취약점 자체가 새로 발견된 것이며, GPT-5.2의 해결 방식은 **기존에 문서화되지 않은 새로운 체인 구성**으로 평가됨 ### 침투의 산업화 - ‘산업화’란 **조직의 공격 능력이 인력 수가 아닌 토큰 처리량에 의해 결정되는 상태**를 의미 - 이를 위해 필요한 조건은 두 가지 - LLM 기반 에이전트가 **환경 내에서 자율적으로 탐색**할 수 있어야 함 - **정확하고 빠른 검증 시스템**이 존재해야 함 - 익스플로잇 개발은 이러한 조건을 충족하는 이상적인 사례 - 환경 구축이 용이하고, 검증 절차가 명확 - 예: 쉘 생성 익스플로잇의 경우, 포트 리스너를 통해 연결 성공 여부로 검증 가능 - 반면, **실시간 상호작용이 필요한 침투·권한 상승·지속적 접근 유지·데이터 탈취** 등은 산업화가 더 어려움 - 실제 환경에서의 잘못된 행동이 탐지로 이어질 수 있기 때문 ### 현재 단계 - **취약점 탐지와 익스플로잇 개발은 이미 토큰 투입량에 비례해 성과가 증가** - OpenAI의 **Aardvark 프로젝트**에서도 동일한 경향 확인 - 실험에서도 예산이 한계였을 뿐, 모델의 성능이 한계가 아니었음 - 실제 네트워크 내에서의 해킹 자동화는 아직 불확실 - Anthropic 보고서에 따르면 **중국 해킹팀이 API를 이용한 공격 시도**를 한 사례 존재 - 그러나 완전 자동화된 **SRE(사이트 신뢰성 엔지니어링)** 에이전트가 상용화된 사례는 없음 - SRE 자동화가 성공한다면, **적대적 네트워크 내 자동화 해킹**도 가능할 가능성 높음 ### 결론 및 제언 - 이번 실험은 **사이버 영역에서 자동화 가능성의 범위와 시기**에 대한 인식을 바꿈 - 현재의 모델 평가 방식(CTF, 구형 취약점, 합성 데이터)은 **실제 제로데이 공격 능력을 측정하기에 부적절** - **프론티어 연구소와 AI 보안 기관**은 실제 제로데이 대상(예: Linux 커널, Firefox)에 대한 평가를 수행해야 함 - “X억 토큰을 사용해 Y개의 익스플로잇을 생성했다”는 형태의 공개 보고 필요 - IoT 펌웨어 등 실제 장비를 대상으로 한 평가도 필요 - Opus 4.5나 GPT-5.2 기반 에이전트로 **일주일 내 실질적 익스플로잇 생성 가능성** 제시 - 연구자와 엔지니어에게는 **직접 실험을 수행하고 결과를 공개할 것**을 권장 - 실험용 코드와 데이터는 GitHub 저장소에서 공개됨 ## Comments ### Comment 49568 - Author: neo - Created: 2026-01-21T08:33:02+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46676081) - GPT‑5.2에게 가장 어려운 과제로 **디스크의 특정 경로에 문자열을 쓰는 방법**을 찾게 했음 ASLR, 비실행 메모리, full RELRO, 세밀한 CFI, 하드웨어 shadow‑stack, seccomp 샌드박스 등 모든 보호가 켜진 QuickJS 환경이었음 GPT‑5.2는 glibc의 **exit handler 체인**을 이용해 7단계 함수 호출로 문제를 해결했음. 정말 놀라운 결과였음 - 이런 완화책들을 아예 제거해야 하는 게 아닐까 생각함 실제 익스플로잇은 대부분 “취약점 찾기(어려움)” 후 “쓸모없는 완화책 여러 겹 뚫기(귀찮지만 가능)” 순서로 진행됨 확률적 완화는 확률적 공격엔 통하지만, 공격자는 **의도적**으로 약점을 찾아냄 - 결국 기계어 스택 하단엔 구멍이 너무 많음 미래엔 왜 더 일찍 **WASM**으로 전환하지 않았는지 후회할 것 같음 그 전까지는 하드웨어 완화책을 덕지덕지 붙이며 낡은 스택 오버라이트 문제를 붙잡고 있을 것임 - “glibc의 exit handler”라니… 소름임 - 요즘 **킬체인**은 대부분 여러 버그를 연쇄적으로 이용함 내 일이라 잘 아는데, 점점 **무력감**이 커지고 있음 - 이런 사례는 C로 빌드된 QuickJS가 얼마나 **LLM에게 취약한지** 보여줌 Use‑After‑Free로 libc 포인터를 유출하는 식임 Rust라면 훨씬 어렵겠지만, libc 호출이 많으면 완전한 방어는 어려움 - GPT‑5.2의 익스플로잇은 완화책을 새로 깨뜨린 게 아니라, 이미 알려진 **구현상의 틈**을 이용한 것임 인간 해커도 마찬가지로 완화책 자체를 새로 깨지 않음 다만 CTF 분야에서는 LLM이 이제 **원샷으로 pwn 문제를 푸는** 경우가 늘고 있음 이런 발전 덕분에 불완전한 완화 구현들이 무너지고, **형식적 익스플로잇 모델링** 연구가 촉진될 것 같음 - “형식적 익스플로잇 모델링”이 미성숙한 분야라는데, 참고할 만한 자료가 궁금함 - 보안 연구자로서 보면, LLM이 만든 **read/write primitive API**는 기존 API를 단순히 재조합한 수준임 새 기술이라기보단 CTF용 장난감 바이너리와 비슷함 다만 최신 OpenAI 모델이 실제 익스플로잇 코드를 생성하지 않으려는 경향이 있는데, **프롬프트 우회**가 쓰인 건지 궁금함 - 저자는 흥미로운 포인트를 짚었지만, 나는 크게 걱정하지 않음 이런 도구는 **방어자도 대칭적으로** 활용 가능함 CI 단계에서 “LLM Red Team”을 돌리는 식으로 **자동 보안 테스트**를 추가할 수 있음 - 수학적으로 보면 대칭이 아님 공격자는 한 번만 성공하면 되고, 방어자는 항상 성공해야 함 현재 모델은 pass@x 성능이 maj@x보다 20~30% 높음 그래도 **Red vs Blue 루프**를 돌리면 보안 수준은 개선될 것임 - 복잡한 시스템에서는 이런 대칭이 깨짐 공격자는 한 번의 실패만 찾아내면 되고, 방어자는 모든 걸 막아야 함 - 이미 방어적으로도 사용 중임 예: Google Project Zero의 [Big Sleep 프로젝트](https://projectzero.google/2024/10/from-naptime-to-big-sleep.html) 관련 취약점 목록은 [이곳](https://issuetracker.google.com/savedsearches/7155917)에서 볼 수 있음 - 대칭이 될 수 없음 공격자는 **하나의 버그**만 찾아도 무기화 가능하지만, 방어자는 **모든 버그**를 찾아야 함 “any vs all”의 비대칭 구조임 - 유지되지 않는 소프트웨어가 너무 많음 결국 **LLM 기업만이 진정한 승자**가 되어 양쪽에 토큰을 팔게 됨 - Codex 5.2가 가장 복잡한 익스플로잇을 찾아낸 점이 흥미로움 나도 Opus 4.5를 주로 쓰지만, Codex 5.2의 **Extra High thinking** 모드는 확실히 강력함 LLM 발전이 둔화됐다는 말은 믿지 않음. 오히려 **과제가 너무 어려워져서** 체감이 줄었을 뿐임 - 실제로는 익스플로잇을 “찾은” 게 아니라, 이미 주어진 취약점을 **활용하는 코드**를 작성한 것임 로그는 [이 저장소](https://github.com/SeanHeelan/anamnesis-release/blob/master/experiment-results/connectback-gpt52/run-001/agent.log)에서 확인 가능함 - Anthropic 모델은 **도구 사용자형**, OpenAI Codex High는 **리뷰어/수정자형**, Gemini는 **창의적 예술가형**임 각자 스타일이 다름 - “충분히 어려운 과제”는 대부분 **기업 내부 IP**로 묶여 있음 상업적 가치가 사라질 때까지 공개되지 않음 - QuickJS는 원래 **패치되지 않은 취약점**이 많은 장난감 프로젝트임 curl 같은 실전 대상에서의 익스플로잇이 더 흥미로울 것임 - LLM이 훌륭한 익스플로잇을 쓴다는 주장과, 쓸모없는 버그 리포트를 낸다는 주장이 공존함 둘 다 사실일 수 있을까? - 둘 다 충분히 가능함 LLM의 품질은 **사용자 프롬프트와 해석 능력**에 따라 달라짐 전문가가 선별적으로 활용하면 훌륭한 결과를 얻을 수 있음 - 익스플로잇은 “작동하느냐”로 명확히 평가되지만, **CVE 리포트**는 검증이 훨씬 힘듦 자동 생성된 리포트는 유지보수자에게 큰 부담임 - 실제로는 사용 방식에 따라 품질 차이가 큼 단순히 “이 프로그램의 취약점을 찾아줘”라고 하면 헛소리가 많지만, **테스트 루프와 환경을 제공**하면 반복적으로 개선해 진짜 동작하는 결과를 냄 - 익스플로잇은 명확한 성공 기준이 있고, LLM의 **집요한 반복성**과 잘 맞음 반면 버그 리포트는 모호하고 평가가 어려움 - 예산 구조도 다름 예를 들어 $100 중 $50짜리 진짜 이슈 하나와 $0.01짜리 5000개의 가짜 리포트가 섞여 있으면, **진짜 다이아몬드**를 찾기 어렵게 됨 - 샌드박스 설명이 모호해서 처음엔 의심스러웠음 [저자 저장소](https://github.com/SeanHeelan/anamnesis-release/?tab=readme-ov-file#the-hardest-challenge-relro-cfi-shadowstack-and-a-sandbox)를 보니 “/tmp/pwned에 ‘PWNED’ 문자열을 쓰는 것”이 목표였음 즉, **샌드박스 탈출이 아니라 단순 파일쓰기 제한**이었음 - 전체 리포지토리와 글이 다소 **오해를 부를 만한 구성**임 OOB R/W primitive API를 만들게 한 것도, 이미 수천 개의 GitHub 예시를 **재활용**한 수준임 - “앞으로 국가나 조직의 해킹 역량은 해커 수가 아니라 **토큰 처리량**으로 결정될 것”이라는 말이 인상적이었음 - 실제로는 그런 조직들이 LLM의 **허술한 코드 패턴을 분석**해, 사람이 직접 범용 익스플로잇을 작성하고 있을 가능성이 큼 - **소프트웨어 제작의 진입장벽**과 **해킹의 진입장벽**이 동시에 낮아지는 건 폭발적인 조합임 이제는 **보안 가드레일과 검증 가능성**을 갖춘 새로운 플랫폼이 필요함 비전문가가 만든 코드에 의존하기엔 위험함 - 원래 세 번째 문단에서 “단 하나의 익스플로잇 vs 전체 시스템 방어”의 불균형을 언급했는데, 왜 삭제했는지 궁금함