LLM을 활용한 익스플로잇 생성의 산업화가 다가오고 있다

• 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 저장소에서 공개됨