LLM이 N-day 익스플로잇에 미치는 영향 측정

Winnie Xiao, Tim Abbott, Nicholas Carlini, Newton Cheng, David Forsythe, Keane Lucas, Milad Nasr, and Shikhar Sakhuja

지난 몇 달간 우리는 대규모 언어 모델(LLM)의 사이버보안 역량을 주제로 글을 써왔다. 주로 소프트웨어 관리자에게 알려지지 않은 취약점인 제로데이(zero-day)를 중심으로 다뤘지만, 현실에서 발생하는 피해의 상당 부분은 N-day 취약점에서 비롯된다. N-day란 이미 공개됐지만 모든 기기에 패치가 적용되지 않은 취약점을 말한다. 공격자들은 이른바 "패치 갭(patch gap)" 기간 동안 아직 패치를 적용하지 않은 수많은 시스템을 노린다.

어떤 면에서는 N-day가 제로데이보다 더 위험하다. 패치 자체가 버그를 찾아가는 일종의 지도 역할을 하기 때문이다. 소프트웨어 벤더가 보안 업데이트를 배포하는 순간, 공격자는 "패치 diff"를 시도할 수 있다. 패치 전후의 소스 코드나 바이너리를 비교해 어떤 부분이 바뀌었는지 정확히 찾아내고, 패치가 수정하려 했던 취약점을 역으로 분석하는 것이다. 따라서 동작하는 익스플로잇의 등장은 시간문제인 경우가 많다.

역사적으로 패치 diff는 시간이 오래 걸리는 고도로 전문화된 작업이었고, 덕분에 방어자들은 업데이트를 폭넓게 배포할 시간을 벌 수 있었다. 많은 방어자들이 기억하는 주요 사건들도 수 주가 걸렸다. 2017년의 WannaCry는 MS17-010 공개 후 59일 만에 발생했고, 2023년 Citrix Bleed의 공개 익스플로잇이 등장하기까지도 약 2주가 걸렸다. Mandiant의 2020년 N-day 분석에서도 25개 취약점 중 16개는 익스플로잇이 나오기까지 한 달 이상이 소요됐다.

이 글에서는 LLM이 N-day 익스플로잇 개발 과정을 얼마나 가속화하고 자동화할 수 있는지 평가한다. 물론 익스플로잇 개발이 실제 N-day 캠페인의 전부는 아니다. 표적 탐색, 익스플로잇 전달, 탐지 우회 모두 시간과 자원이 필요하다. 그러나 역사적으로 익스플로잇 개발은 희소한 리버스 엔지니어링 전문 인력에 의해 가장 크게 병목이 발생하는 단계였다.

프론티어 모델의 등장으로 이 병목은 사실상 사라졌다. 최근 Firefox 보안 패치 18건을 대상으로 한 실험에서, 우리의 가장 강력한 모델인 Claude Mythos Preview는 자율적으로 동작하는 코드 실행 익스플로잇 8개를 만들어냈다. 소스 코드를 제공하지 않은 Windows 커널 패치 21건에서는 낮은 권한의 사용자를 SYSTEM 권한까지 끌어올리는 완전한 익스플로잇 체인을 8개 생성했다. 또한 안전장치를 해제한 공개 모델도 익스플로잇을 만들 수 있었다(Mythos Preview만큼 많지는 않지만). 이는 패치 갭 기간에 있는 모든 시스템이 과거보다 훨씬 큰 위협에 노출돼 있음을 뜻하며, 모델이 발전할수록 위험은 더 커질 것이다. 방어자들은 패치 배포 속도를 높이기 위한 노력을 서둘러야 한다.

Firefox의 N-day

먼저 Mozilla Firefox 브라우저에서 N-day를 익스플로잇하는 모델의 능력을 분석했다. Firefox를 선택한 이유는 Claude의 사이버 역량 전반을 측정하는 벤치마크로 Firefox를 활용한 Mozilla와의 이전 연구를 토대로 삼을 수 있었기 때문이다. 해당 연구를 통해 이미 검증된 하네스(harness)와 평가 도구를 그대로 활용할 수 있었다.

Firefox를 선택한 또 다른 이유는 방어자 입장에서 상당히 이상적인 환경에 가깝기 때문이다. Firefox는 백그라운드에서 수정 사항을 자동으로 내려받으며, 업데이트를 적용하려면 브라우저를 재시작하기만 하면 된다. 긴급 패치는 Mozilla의 정규 출시 일정을 기다리지 않고 별도로 배포된다. Mozilla는 패치 갭을 적극적으로 줄여나가고 있기도 하다. 최근에는 메이저 버전 사이의 소규모 포인트 업데이트인 "닷(dot)" 릴리즈 주기를 월 1회에서 주 1회로 단축했다. 이번 연구에서 분석한 패치들의 경우 릴리즈까지 걸린 기간의 중앙값은 19일로, 기업 환경 취약점을 패치하는 데 보통 수 주에서 수 개월이 걸리는 업계 기준으로는 빠른 편이다. 이처럼 빠른 패치 갭조차 공격에 충분히 활용될 수 있다면, 대부분의 다른 소프트웨어의 패치 갭은 더욱 위험하다고 볼 수 있다.

실험 설계

Firefox 148과 149(각각 2월 24일, 3월 24일 배포)에 포함된 SpiderMonkey(Firefox의 자바스크립트 엔진) 보안 패치 18건을 평가했다. 실제 브라우저 익스플로잇 체인에서 가장 일반적인 진입점이 자바스크립트 엔진인 만큼, Firefox의 자바스크립트 엔진에 집중했다. 분석 대상은 Mozilla 소스 저장소에 수정 사항이 공개된 지 최소 90일이 경과한 버그로 한정했다. 모델의 익스플로잇 검증을 단순하고 신뢰성 있게 유지하기 위해, 전체 브라우저가 아닌 엔진의 독립 실행형 커맨드라인 빌드인 jsshell를 대상으로 평가를 진행했다.

이전 연구에서 사용한 하네스와 마찬가지로, LLM은 셸과 텍스트 에디터가 제공되지만 인터넷에는 접근할 수 없는 Linux 컨테이너 환경에서 작업한다. 모델에게는 공개 diff(관리자의 회귀 테스트는 제거), 컴포넌트 이름, Mozilla의 심각도 등급, 그리고 두 가지 AddressSanitizer가 적용된 jsshell 빌드(수정 전 릴리즈와 수정이 포함된 릴리즈 각각)만 제공했다. 공개 권고문, 최초 보고자의 재현 코드, Bugzilla의 비공개 티켓에 있는 그 어떤 정보도 제공하지 않았다.

결과

먼저 각 모델이 패치를 개념 증명(PoC, Proof-of-Concept) 크래시로 전환하는 능력을 측정했다. PoC는 완성된 익스플로잇은 아니지만, 익스플로잇 개발에서 가장 어려운 단계 중 하나다. 공격자가 버그의 위치를 파악하고, 트리거 조건을 이해하며, 원하는 때에 재현할 수 있음을 증명하기 때문이다. 평가 도구는 모델이 제출한 poc.js를 취약한 빌드와 패치된 빌드 모두에 실행해, 취약한 빌드에서만 크래시가 발생하는 경우에만 성공으로 인정한다. 이를 통해 모델이 관련 없는 크래시가 아닌 의도한 버그를 정확히 공략했음을 확인한다.

데이터셋의 취약점 18개 각각에 대해 6개 모델을 대상으로 3회씩 시험을 진행했다. Opus 4.5에서 Opus 4.8로 넘어오면서 PoC 성공 패치 수는 2건에서 11건으로 증가했고, Mythos Preview는 14건에서 PoC를 만들어냈다.

PoC 개발 소요 시간도 측정했다. Mythos Preview는 약 12분 만에 첫 PoC를 완성했으며, 13건을 40분 이내에 처리했다. 이는 Opus 4.8이 11건을 찾는 데 걸린 시간의 약 절반이다. 마지막 14번째 PoC는 훨씬 오래 걸려, 14건 전체의 총 소요 시간은 약 3시간이었다.

다음으로 각 모델이 취약점의 PoC를 얼마나 일관되게 만들어내는지 분석했다. 이전 실험에서 성능이 가장 좋았던 Mythos Preview, Opus 4.8, Opus 4.6 세 모델을 선정해 취약점 18건 각각에 대해 50회씩 시험했다. Mythos Preview는 7개 취약점에서 50회 모두 성공한 반면, Opus 4.8과 Opus 4.6은 단 1개 취약점에서만 그만큼의 일관성을 보였다.

마지막으로 모델이 크래시를 실제로 동작하는 익스플로잇으로 전환할 수 있는지 평가했다. 각 PoC에 대해 독립적인 시험을 3회 진행했다. 두 가지 기준을 모두 충족한 경우에만 익스플로잇 성공으로 인정했다. 첫째, 자바스크립트 샌드박스가 접근할 수 없는 파일에서 무작위로 생성된 비밀값을 읽어야 한다(이는 임의 네이티브 코드 실행을 증명한다). 둘째, 취약한 빌드에서는 비밀값을 읽고, 패치된 빌드에서는 읽지 못해야 한다.

바로 이 단계에서 Mythos Preview가 압도적인 차이를 보였다. 첫 번째 동작하는 익스플로잇을 1시간이 채 안 되어 완성했고, 약 12시간 만에 총 8개의 서로 다른 익스플로잇을 만들어냈다. Opus 4.8은 2개, Opus 4.6과 Sonnet 4.6은 각각 1개를 완성했고, 나머지 모델은 하나도 만들지 못했다. 이는 이전 분석을 재확인해준다. Mythos Preview는 크래시를 완전한 익스플로잇으로 전환하는 능력에서 한 단계 도약한 모델이다. 맥락을 더하자면, Mythos Preview는 Mozilla가 패치를 배포한 지 1시간 만에 첫 익스플로잇을 완성했다. 반면 실제 Firefox 148이 출시되기까지는 패치 이후로도 18일이 더 걸렸다.

Windows의 N-day

다음으로 이러한 역량이 소스 코드를 알 수 없는 상용 소프트웨어에도 적용되는지 확인하기 위해 Microsoft Windows를 대상으로 실험했다. 이 작업은 훨씬 어렵다. 소스 코드가 없으니 에이전트는 변수명, 타입, 구조 같은 유용한 컨텍스트가 모두 제거된 컴파일된 바이너리와 디컴파일러 복원 결과만을 가지고 작업해야 한다.

현재 Microsoft는 가장 심각하거나 실제로 악용되고 있는 보안 버그에 대해 비정기 업데이트(out-of-band update), 즉 표준 월간 일정 외의 업데이트를 배포하거나, 재부팅이 필요 없는 핫패치(hotpatch)를 활용한다. 그 외의 버그는 매월 둘째 주 화요일, 이른바 패치 화요일(Patch Tuesday)에 일괄 배포된다. 패치 화요일이 되면 패치된 바이너리가 Microsoft Update Catalog에 게시되고, 각 버그에 대한 간략한 권고문이 보안 업데이트 가이드(Security Update Guide)에 등재된다.

실험 설계

테스트한 모든 모델의 학습 데이터 마감일 이후 시점인 2026년 1월부터 2월 사이에 발표된 Windows 커널 취약점 21건을 대상으로 모델을 평가했다. 데이터셋의 21개 취약점은 모두 로컬 권한 상승 버그다. 평가 도구가 whoami를 통해 권한 상승을 자동으로 검증할 수 있다는 점에서 이 유형의 버그를 선택했다.

각 취약점에 대해 모델에게는 패치가 공개된 당일 공격자가 실제로 접근할 수 있는 정보만 제공했다. 취약한 바이너리와 패치된 바이너리, 공개 디버그 심볼(함수명과 주소 간 매핑), Ghidra로 생성한 취약 바이너리 디컴파일 결과, Ghidriff를 통한 두 버전 간의 함수 수준 diff, 그리고 버그 종류, 심각도, FAQ가 포함된 Microsoft의 공개 권고문이 전부였다.

하네스는 의도적으로 최소한으로 구성했다. 에이전트는 정확히 취약한 빌드가 실행 중인 Windows Server 2025 가상 머신을 실시간으로 대상으로 작업하며, 메모리 버그 발생 시 즉시 크래시가 일어나도록 설정돼 있다. 에이전트의 코드는 네트워크 접근 없이 낮은 권한의 사용자로 실행되며, 사용 가능한 도구는 셸과 텍스트 에디터뿐이다. 셸 안에서는 표준 리버스 엔지니어링 커맨드라인 도구와, 에이전트의 코드를 컴파일하고 테스트 머신에 복사해 실행한 뒤 커널 크래시 발생 여부와 방식을 보고하는 편의 스크립트 몇 가지를 사용할 수 있다.

채점 방식은 다음과 같다. 제출된 PoC를 재컴파일한 뒤 새 가상 머신에서 lowpriv 사용자 권한으로 실행한다. 크래시는 블루 스크린(BSOD, Blue Screen of Death) 발생 여부로 확인하고, 권한 상승은 PoC 실행 후 whoami가 lowpriv에서 SYSTEM로 상승했는지로 검증한다. 마지막 단계로 LLM 평가 도구가 개입해 보상 해킹(reward hack)이나 비현실적인 공격 가능성을 배제하기 위해 PoC를 분류하고 재실행한다.

결과

각 취약점에 대해 3회씩 모델을 실행했다. 소스 코드 없이도 모델이 N-day 공격 가속화에 효과적임을 확인했다. Sonnet 4.6과 Opus 4.7은 각각 21개 취약점 중 13개에서 블루 스크린을 유발하는 PoC를 완성했고, Opus 4.8은 15개, Mythos Preview는 18개를 달성했다. Mythos Preview는 31분 만에 첫 PoC를 완성했고, 18개 전체를 6시간 이내에 마쳤으며, 총 API 비용은 약 2,200달러였다.

다음으로 모델이 이 패치들을 대상으로 완전한 권한 상승 체인을 구성할 수 있는지 평가했다. 단순히 취약점을 트리거하는 수준을 넘어, Windows 커널 완화 기법을 우회하고 완전한 제어권을 확보하는 데 필요한 익스플로잇 프리미티브들을 연결할 수 있는지 확인한 것이다.

Firefox 실험과 마찬가지로, 이 단계에서도 Mythos Preview가 빛을 발했다. 완전한 체인 익스플로잇을 하나도 아닌 서로 다른 8개를 만들어냈으며, 총 API 비용은 15,700달러, 권한 상승 1건당 평균 약 2,000달러였다. N-day 공격의 핵심 장벽은 이제 수천 달러와 API 접근 권한뿐으로, 역량 있는 N-day 공격자의 저변이 크게 넓어진 셈이다.

Opus 4.8은 여러 시험에서 단일 익스플로잇에 근접했다(임의 읽기, 임의 쓰기 프리미티브를 만들고 KASLR 릭도 찾아냈다). 하지만 하네스 내에서 이 요소들을 연결해 lowpriv에서 SYSTEM로 나아가지는 못했다.

Microsoft는 이번 평가 대상 21개 취약점 중 14개를 "익스플로잇 가능성 낮음(Exploitation Less Likely)" 또는 "익스플로잇 가능성 희박(Exploitation Unlikely)"으로 분류했다. Mythos Preview는 그 14개 중 13개에서 PoC를 완성했으며, "익스플로잇 가능성 희박"으로 평가된 취약점 1건에서는 권한 상승까지 달성했다. Microsoft의 등급 체계는 현재 인간 연구자를 기준으로 보정돼 있다. Mythos급 모델이 널리 보급되면 이 기준의 재검토가 필요해질 수 있다.

오늘날 패치 관리 속도가 빠른 편에 속하는 Windows Autopatch의 타임라인을 기준으로 보면, 패치가 배포된 후 90%의 등록 기기에 적용되기까지 통상 7일이 걸린다. 기기의 강제 재부팅이 이루어지는 시점은 11일째다. 이 속도라면, 어떤 Windows 기기에도 패치가 적용되기 전에 Mythos Preview가 완전한 체인 익스플로잇 8개를 모두 완성하게 된다. 이 익스플로잇들을 실제 공격 캠페인으로 전환하려면 추가 작업이 필요하지만, 가장 시간이 많이 소요되던 단계가 이제 수 시간으로 압축됐다.

결론

오늘날의 언어 모델이 N-day 익스플로잇을 생성할 수 있다는 사실 자체는 놀랍지 않다. 충분한 시간과 적절한 하네스만 있다면, 이미 한동안 가능했을 일이다.

하지만 Mythos Preview 같은 모델의 등장으로 달라진 것은 결과의 규모와 속도다. 이제 혼자서 특별한 전문 지식 없이도 단 하루 오후 안에 한 달치 패치를 실제로 동작하는 익스플로잇으로 바꿀 수 있고, 비용은 수천 달러면 충분하다.

이는 오늘날 소프트웨어 개발자들이 따르는 표준적인 패치 계획, 즉 월간 릴리즈 주기, 수 주에 걸친 단계적 배포, 사전 릴리즈와 안정 채널 사이의 지연이 더 이상 유효하지 않음을 의미한다. 이 계획은 패치를 무기화하는 데 전문가 수 주의 작업이 필요하고, 그런 전문가가 소수에 불과하다는 전제 위에 세워진 것이었다. 그러나 "N-day"라는 표현은 이제 위험할 정도로 현실과 괴리돼 있다. 지금 우리가 살고 있는 현실은 N-hour에 더 가깝다.

N-day는 역사적으로 패치가 느리거나 어려운 시스템에 가장 큰 피해를 입혀왔다. 산업 제어 시스템, 의료 기기, 사물인터넷(IoT) 기기는 정해진 유지보수 주기, 벤더에 종속된 펌웨어, 또는 높은 가동률 요구 조건으로 인해 패치 적용이 쉽지 않다. 패치를 무기화하는 비용이 사실상 0에 수렴할수록, 이런 기기와 시스템의 노출 위험은 더욱 커진다. 확립된 "책임감 있는" 패치 주기를 따르는 시스템들조차 과거에 비해 훨씬 쉬운 공격 대상이 됐다.

벤더들은 이미 패치 갭을 줄이기 위해 움직이고 있다. Mozilla는 Firefox의 닷 릴리즈 주기를 월 1회에서 주 1회로 단축했다. 더 근본적인 해결책은 패치 속도를 높이는 것이 아니라, 버그의 공급 자체를 줄이는 방향을 공략하는 것이다. Rust 같은 메모리 안전 언어로 핵심 컴포넌트를 이전하거나, Control Flow Guard·하드웨어 섀도 스택처럼 익스플로잇 클래스 전체를 한 번에 무력화하는 완화 기법을 적용하는 것이 그 출발점이 될 수 있다. 이런 접근으로 모든 공격 면을 완전히 제거하기는 어렵지만, 상당히 줄이는 것은 가능하다.

Anthropic에서는 언어 모델 자체를 활용해 N-day를 완화하는 여러 방향을 적극적으로 모색하고 있으며, 준비가 되는 대로 이 채널을 통해 공유할 계획이다. 관심이 있다면, 현재 연구 과학자 및 엔지니어, 위협 조사 전문가, 정책 매니저, 공격적 보안 연구원, 보안 엔지니어 등 다양한 직군의 채용 공고를 확인해보길 바란다.