Opus 4.5와 GPT-5.2 기반 에이전트로 QuickJS 제로데이 익스플로잇을 제작한 실험을 통해, 공격적 사이버보안의 여러 구성 요소가 토큰 처리량에 의해 ‘산업화’될 가능성을 논한다.
URL: https://sean.heelan.io/2026/01/18/on-the-coming-industrialisation-of-exploit-generation-with-llms/
최근 나는 Opus 4.5와 GPT-5.2 위에 에이전트를 구축한 뒤, QuickJS 자바스크립트 인터프리터의 제로데이 취약점에 대한 익스플로잇을 작성하라는 과제를 주는 실험을 진행했다. 여기에 다양한 현대적 익스플로잇 완화 기법, 여러 제약(예: 힙 시작 상태를 알 수 없다고 가정, 익스플로잇에서 하드코딩된 오프셋 금지)과 다양한 목표(셸 실행, 파일 쓰기, C2 서버로 콜백 연결)를 추가했다. 에이전트들은 6가지 서로 다른 시나리오에서 40개가 넘는 서로 다른 익스플로잇을 만드는 데 성공했고, GPT-5.2는 모든 시나리오를 해결했다. Opus 4.5는 두 개를 제외한 모두를 해결했다. 실험과 결과에 대한 기술적인 정리 글을 Github에 올려두었고, 실험을 재현할 수 있는 코드도 함께 공개했다.
이 글에서는 이 작업으로부터 내가 도출한 핵심 결론에 집중하려 한다. 즉, 공격적 사이버 보안의 많은 구성 요소가 ‘산업화(industrialisation)’될 것에 대비해야 한다는 점이다. 가까운 미래에는 국가나 집단이 익스플로잇을 개발하고, 네트워크에 침투하고, 권한을 상승시키고, 그 네트워크 내에 머무르는 능력의 제한 요인이 고용한 해커의 수가 아니라 시간에 따른 토큰 처리량(token throughput)이 될 것이라고 가정하기 시작해야 한다. 확실한 것은 없지만, 이 시나리오를 생각하느라 노력만 낭비하고 실제로는 일어나지 않는 편이, 실제로 일어났을 때 준비가 안 되어 있는 것보다 낫다.
실험을 다시 실행하기 위한 모든 코드, 상세한 기술 문서, 그리고 에이전트가 생성한 원시 데이터는 Github에 있다. 여기서는 에이전트들이 무엇을 해냈는지 감만 잡을 수 있도록 몇 가지를 요약하겠다.
계속하기 전에, 이 실험에 대해 반드시 염두에 둬야 할 중요한 단서(caveat) 두 가지가 있다.
여기서 ‘산업화’란, 어떤 조직이 한 작업을 완수하는 능력이 그 작업에 투입할 수 있는 토큰의 양에 의해 제한되는 상황을 뜻한다. 어떤 작업이 이런 방식으로 ‘산업화’되려면 두 가지가 필요하다.
익스플로잇 개발은 산업화의 이상적인 사례다. 환경을 구축하기 쉽고, 문제 해결에 필요한 도구도 잘 알려져 있으며, 검증도 간단하다. 내가 실험에서 사용한 검증 과정을 여기에 정리해 두었는데, 요약하면 이렇다. 익스플로잇은 보통 “원래는 할 수 없어야 하는 일을 할 수 있게 만드는 능력”을 구축하는 과정이다. 익스플로잇을 실행한 뒤 그 일을 할 수 있으면, 이긴 것이다. 예를 들어 어떤 실험에서는 자바스크립트 프로세스에서 셸을 실행(spawn)하는 익스플로잇을 작성하는 것이 목표였다. 이를 검증하기 위해 검증 하네스는 로컬의 특정 포트에서 리스너를 시작하고, 자바스크립트 인터프리터를 실행한 다음, 그 인터프리터에 명령을 파이핑하여 로컬 포트로 연결을 시도하는 커맨드라인 유틸리티를 실행하게 만든다. 자바스크립트 인터프리터는 정상 실행에서는 네트워크 연결이나 다른 프로세스 생성 능력이 전혀 없으므로, 콜백 연결이 들어온다면 익스플로잇이 동작한 것이다. 즉, 시작된 셸이 내가 보낸 커맨드라인 유틸리티를 실행했음을 의미한다.
이 영역의 문제가 언제/어떻게 산업화될 수 있는지에 영향을 줄 수 있는 세 번째 속성도 있다. 에이전트가 오프라인 환경에서 문제를 풀고 나서 그 해법을 그대로 사용할 수 있다면, 이는 오늘날 모델들이 잘하는 것으로 보이는 “대규모 해 공간 탐색”과 잘 맞는다. 반대로 오프라인 탐색이 불가능해서, 실제 환경과 상호작용하면서 해법을 찾아야 하고**, 그리고** 그 환경에서 에이전트의 특정 행동이 탐색을 영구적으로 종료시키는 속성이 있다면, 산업화는 더 어려울 수 있다. 또는 적어도 현재의 LLM 역량이 이런 속성을 가진 문제에 그대로 매핑된다고 말하기가 덜 명확하다.
사이버 침투에는 이 세 번째 속성을 가진 작업이 여럿 있다. 익스플로잇을 통한 초기 접근(initial access), 내부 이동(lateral movement), 접근 유지(maintaining access), 그리고 접근을 활용한 첩보 활동(즉 데이터 유출, exfiltration) 등이 그렇다. 전체 탐색을 사전에 다 해놓고 나서 해법을 사용하는 것이 불가능하다. 어느 정도의 탐색은 실제 환경에서 이뤄져야 하고, 그 환경은 적대적이어서 잘못된 행동 하나로 전체 탐색이 종료될 수 있다. 즉 에이전트가 탐지되어 네트워크에서 쫓겨나고, 잠재적으로 전체 작전이 노출되어 끝날 수 있다. 이런 작업들에 대해서는, 내 현재 실험이 제공하는 정보가 더 적다고 생각한다. 이것들은 본질적으로 “토큰을 해 공간 커버리지로 교환”하는 문제라기보다는 다른 성격이 있기 때문이다. 그렇다고 해도, 코딩과 SRE 업무를 자동화하는 모델을 만들 수 있다고 생각한다면, 이런 해킹 관련 작업들이 불가능하다고 생각하는 것도 이상해 보인다.
우리는 취약점 탐색과 익스플로잇 개발에서 이미 “토큰을 실제 결과로 바꿀 수 있는” 지점에 와 있다. OpenAI의 Aardvark 프로젝트에서 그들은 이런 현상을 보고 있다고 말한 바 있다. 즉 토큰을 더 쓸수록 더 많은 버그를 찾고, 그 버그의 품질도 좋아진다는 것이다. 내 실험에서도 이를 확인할 수 있다. 과제가 어려워질수록, 더 많은 토큰을 써서 계속 해를 찾을 수 있었다. 결국 제한 요인은 모델이 아니라 내 예산이었다. 나는 LLM에 의해 이것이 산업화되지 않을 가능성보다, 산업화될 가능성이 더 높다고 생각한다.
해킹/사이버 침투에 포함되는 다른 작업들에 대해서는 추측이 필요하다. 실제 환경에서 LLM이 이런 작업을 얼마나 잘하는지에 대한 공개 정보가 더 적기 때문이다(명백한 이유로). Anthropic이 공개한, 중국 해킹 팀이 그들의 API를 사용해 공격을 오케스트레이션했다는 보고서가 있으므로, 최소한 조직들이 _이걸 되게 만들려고 시도하고 있다_는 점은 알 수 있다. 반대로, 접근 이후(post-access)의 해킹 관련 작업들이 아직 자동화 가능한 수준이 아닐 수 있다는 단서도 있다. 내가 알기론 SRE 업무를 완전히 자동화한 회사가 아직 눈에 띄지 않기 때문이다(적어도 내가 아는 한).
프로덕션 네트워크를 운영·관리하는 SRE, 시스템 관리자, 개발자의 일을 자동화하려 할 때 마주치는 문제 유형은, 적의 네트워크 안에서 활동하는 해커가 마주치는 문제와 개념적으로 유사하다. SRE 에이전트는 행동의 결과를 고려하지 않은 채로 해법을 무작정 탐색할 수 없다. 어떤 행동은 수행하는 순간 탐색이 종료되고 영구적으로 패배한다(예: 프로덕션 데이터베이스를 날려버리는 것). 이런 세 번째 속성을 가진 해킹 관련 작업들이 지금 당장 자동화 가능하다는 공개 확인을 받지는 못하더라도, 우리에겐 ‘카나리아(canary)’가 있다. 최전선 연구소의 범용 모델을 사용해 SRE 업무 자동화 에이전트를 실제로 판매하고 있는 회사들이 등장한다면, 그 동일한 모델들이 적의 네트워크 내에서 작동해야 하는 다양한 해킹 관련 작업을 자동화하는 데에도 쓰일 가능성이 더 커진다.
이번 실험은 사이버 도메인에서 무엇이 자동화될 가능성이 높고 낮은지, 그리고 그 타임라인에 대한 내 기대를 바꿨다. 또한 AI 기업들과 (모델 평가를 하는) 다른 조직들에 바라는 점도 생겼다.
지금 우리는 현 세대 모델의 진짜 능력을 명확히 알고 있지 못하다고 생각한다. 그 이유는 CTF 기반 평가나 합성 데이터/오래된 취약점을 사용한 평가가, “어려운 타깃에서 제로데이를 찾아 익스플로잇하는 능력”이라는 질문에 그다지 유용하지 않기 때문이다. 나는 모델 역량을 평가하는 최전선 연구소(frontier labs)의 팀들, 그리고 AI Security Institute들이, 실제의 어렵고 현실적인 타깃을 대상으로 제로데이 취약점을 사용해 모델을 평가하고 그 결과를 공개적으로 보고하는 것을 진지하게 고려하길 강하게 권한다. 다음번 최전선 연구소의 주요 릴리즈에서는, “우리는 리눅스 커널과 Firefox를 대상으로 에이전트를 돌리는 데 X0억(또는 X0억) 토큰을 썼고 Y개의 익스플로잇을 만들었다” 같은 문구를 읽어보고 싶다. Y가 0이어도 상관없다. 중요한 것은 X가 아주 큰 숫자라는 점이다. 두 회사 모두 강력한 보안 팀을 갖추고 있으므로, 이미 이런 방향으로 움직이고 있을 가능성도 충분히 있다. OpenAI는 이미 Aardvark 프로젝트가 있으니, 그들이 찾고 있는 취약점을 실제로 익스플로잇하려는 프로젝트를 함께 운영한다면 매우 유용할 것이다.
AI Security Institute 측에서는 모델 회사들이 수행하는 평가에서의 공백(gap)을 식별하고, 그 공백을 메우도록 협력하는 데 시간을 쓰는 것이 가치 있을 것이다. 예를 들어, Opus 4.5나 GPT-5.2 기반 에이전트에 수많은 IoT 장치(라우터, IP 카메라 등)의 펌웨어를 넣어주기만 해도, 1주일도 안 되는 작업으로 반대편에서 동작하는 익스플로잇을 뽑아낼 수 있을 것이라고 나는 거의 확신한다. 평가가 CTF, 합성 환경, 오래된 취약점에만 집중하고, 현실 타깃에 대한 이런 직접 평가를 제공하지 않는 것은 바람직하지 않다.
전반적으로 연구자나 엔지니어라면, 본인이 생각할 수 있는 가장 흥미로운 익스플로잇 관련 문제를 하나 고르고, 감당 가능한 한 많은 토큰을 써서 결과를 정리해 보길 권한다. 얼마나 잘 되는지에 놀랄지도 모른다.
내 실험의 소스 코드가 그 과정에서 조금이라도 도움이 되길 바란다.
