찾아낸 취약점을 일단 거짓말로 의심하는 시스템이 오탐을 이긴다

2026-08-31 · ##ai-security ##llm-agent ##vuln-hunting ##mcp ##automation

찾아낸 취약점을 일단 거짓말로 의심하는 시스템이 오탐을 이긴다

분류: Security · AI·보안 방법론 · 자동화 취약점 헌팅 [정보성]

덱. 보안 연구자 한 명이 Claude Code(앤트로픽의 에이전트형 코딩 도구)와 MCP(Model Context Protocol, LLM에게 외부 도구를 함수처럼 호출하게 해주는 개방 표준)를 엮어, 취약점 헌팅 과정 대부분을 자동화한 개인 연구 파이프라인을 공개했습니다. 도구 자체보다 눈에 띄는 것은 설계 철학입니다 — 새로 찾은 결과를 처음부터 “찾아낸 취약점”이 아니라 “아직 증명 안 된 환각(hallucination)“으로 다루는 검증 관문 구조입니다.

리드

자동화된 취약점 헌팅(자동 퍼징 등)은 새로운 이야기가 아닙니다. 수십 년째 있었던 일이고, 이번 사례의 저자도 그 점을 스스로 인정합니다. 정말 새로운 건 LLM(거대언어모델)을 도구 실행에 붙였다는 사실 자체가 아니라, LLM이 결과를 판단하는 역할까지 맡을 때 생기는 위험(그럴듯하지만 틀린 결론을 자신 있게 내놓는 “환각”)을, 명시적인 검증 관문으로 구조화해 눌렀다는 점입니다. 도구를 자동화하는 건 예전에도 됐습니다. 이번 사례가 보여주는 건 “판단까지 자동화하려면 그 판단을 의심하는 절차부터 자동화해야 한다”는 원칙입니다.

핵심 사실 요약

연구자는 격리된 프록스목스(Proxmox) 기반 VM 5대로 실험실을 꾸리고, 그 위에 MCP 서버 8개·도구 300개 이상을 붙였습니다. 정찰(공격 표면 파악), 리버스엔지니어링(디컴파일·디버깅), 퍼징(무작위/구조화 입력으로 크래시 유발), 익스플로잇 개발, 지식검색(RAG), 인프라 관리, 보고서 작성까지 각 단계를 전담 MCP 서버가 맡고, Claude Code가 이들을 오케스트레이션하는 구조입니다.
설계의 핵심은 저자가 “환각 보관함(hallucination bin)“이라 부르는 상태 머신입니다. 새로 발견된 것은 전부 정식 발견 목록이 아니라 미검증 보관함에 먼저 들어가고, 아래 4단계 관문을 순서대로 통과해야만 정식 발견으로 승격됩니다.
1. PoC(개념 증명 코드)가 존재하고 실제로 컴파일되는가
2. 깨끗한 VM 스냅샷에서 크래시가 재현되는가
3. 단순 널 포인터 역참조나 정상 종료가 아니라 실제로 악용 가능한 크래시인가
4. SYSTEM·관리자 권한이 아니라 일반 사용자 권한에서도 트리거되는가
- 저자는 초기 헌팅 세션에서 자동 엔진이 “유망하다”고 표시한 결과 6건이 실제 동적 검증 단계에서 전부 오탐으로 드러났다고 밝혔습니다.
매 캠페인 시작 전, 시스템은 자체 RAG(검색증강생성 — 과거 기록을 벡터로 찾아 답변에 참고시키는 방식) 지식베이스에 “이 바이너리, 이 종류의 프로그램에서 전에 크래시를 본 적 있는가, 어떤 방어(예: 서명 검증, 프로세스 보호)에 막혔었는가”를 먼저 질의합니다. 막다른 길로 판명된 방어 기법은 기록에 남아, 이후 캠페인이 같은 타깃에 같은 시간을 또 쓰지 않도록 우선순위를 낮춥니다.
어떤 타깃부터 조사할지는 별도의 “바운티 인텔리전스” 모듈이 정합니다. 취약점 클래스별 예상 소요시간과, 각 버그바운티 프로그램이 공시한 최저 보상액을 근거로 기대 보상을 계산한 뒤, 경쟁이 심한 대형 벤더 프로그램일수록 기대값을 큰 폭으로 깎아(최대 80%까지) 반영합니다. 헤드라인 보상이 큰 타깃에 무작정 매달리지 않게 하려는 장치입니다.
이 파이프라인으로 Go 언어 표준 라이브러리의 이미지·폰트 파서에서 공개 CVE 두 건(CVE-2026-33809, CVE-2026-33812 — 둘 다 파서가 파일 내부 값을 검증 없이 신뢰해 수 기가바이트를 할당하게 만드는 서비스거부(OOM) 결함)을 찾아 벤더 측에 수정 커밋까지 반영시켰다고 밝혔습니다. 별도로 한 OEM(주문자상표부착생산) 벤더의 시스템 관리 에이전트에서, 클라이언트 측에서만 이뤄지던 인증을 우회하고 이어진 몇 단계를 거쳐 SYSTEM 권한 코드 실행까지 도달하는 체인, macOS 앱 배포 플랫폼에서 브라우저 방문 기록 유출과 자동 업데이트 서명 검증 우회를 확인한 사례도 있다고 밝혔습니다. ⚠️미확인 — 정확한 지급액수, 벤더명, 진행 중이라고만 밝힌 다수 미공개 건(권한상승·원격코드실행 등)은 이 초안에서 1차출처로 확증하지 못했습니다.
비용도 자체 제작한 별도 도구로 추적해, API 종량 과금만으로 계산하면 CVE 한 건당 약 5,000파운드가 들었을 것으로 추산되지만 구독 요금제를 쓴 덕에 실제로는 그보다 훨씬 저렴했다고 밝혔습니다. 캠페인 하나의 비용 대비 효율은 (캠페인 소요시간 × 사용 VM 수) ÷ 검증을 통과한 발견 수로 계산했다고 밝혔습니다. ⚠️미확인 — “바운티 수익이 하드웨어·구독료·개발 시간을 합친 비용을 넘어섰다”는 주장은 원문에 있으나, 정확한 총 지출액·구독료·누적 수익의 구체 금액은 원문에 수치로 제시되지 않아 이 초안에서 확증하지 못했습니다.

짧은 논평

이 사례에서 저희가 눈여겨보는 지점은 도구 목록이 아니라 신뢰 구조입니다. LLM을 취약점 헌팅에 붙이면 필연적으로 오탐 관리 문제가 따라옵니다 — 코드 맥락을 이해하고 “이건 취약해 보인다”고 판단하는 능력이 좋아질수록, 그 판단이 틀렸을 때도 자신 있게 틀립니다. 이 파이프라인이 취한 해법은 신기술이 아니라 태도의 문제입니다: 자동화된 판단을 기본값으로 신뢰하지 않고, 증명될 때까지 거짓으로 취급한다.

저희도 LLM 기반 코드 감사·CVE 발굴 작업에서 같은 문제를 겪습니다 — 정적 분석만으로 그럴듯해 보이는 결과가 실제 환경에서는 프레임워크의 기본 처리(예: 입력 이스케이프, 확장자 정규화)에 걸려 무력화되는 경우가 반복해서 나옵니다. 그래서 저희 파이프라인도 발견을 곧장 결론으로 삼지 않고 실제 재현을 거치게 하고, 발행 전에는 작성자와 독립된 검증자가 근거를 다시 대조하는 절차를 필수 관문으로 둡니다. 이 사례의 “환각 보관함”과 저희의 독립 검증 게이트는 이름만 다를 뿐 같은 문제의식에서 나온 같은 구조입니다 — 자동화가 늘수록, 그 자동화를 의심하는 관문도 같이 늘어야 전체 시스템이 신뢰를 얻습니다.

바운티 타깃을 예상 보상÷소요시간으로 줄 세우는 접근도 낯설지 않습니다. 헌팅 자원은 한정돼 있고, 헤드라인 보상이 큰 타깃일수록 이미 많은 연구자가 몰려 있어 실제 기대값은 낮습니다. 이 원리는 사람이 손으로 헌팅할 때도, 자동화 파이프라인을 굴릴 때도 똑같이 적용됩니다.

이 글이 다루는 건 특정 회사의 특정 버그가 아니라 **“판단을 자동화할 때는 그 판단에 대한 불신도 같이 자동화해야 한다”**는 방법론입니다. 도구는 계속 바뀌지만 이 원칙은 남습니다 — 그래서 도구가 아니라 방법을 남깁니다.

References / 참고자료

zsec.uk, “Bullying LLMs into Finding 0Days” — 이 글이 재구성한 원 분석. Claude Code와 MCP를 이용한 자율 취약점 헌팅 파이프라인 구축기, 검증 관문(“환각 보관함”) 설계, 발견 사례, 비용 계산 방식을 다룸. https://blog.zsec.uk/bullyingllms/

이 글은 위 원 분석을 우리 관점에서 다시 쓰고 짧은 논평을 더한 정보성 초안입니다. 특정 문장·코드·페이로드를 그대로 옮기지 않았으며, 실제 취약점의 익스플로잇 세부(패킷/바이트 값, 우회에 쓰인 구체 기법)는 재현하지 않고 방법론 수준에서만 서술했습니다. ⚠️미확인 표시 항목은 발행 전 독립 팩트체크에서 확증·정정되어야 합니다.