약 40MB 크기의 바이너리에 백도어를 숨기고 AI와 Ghidra로 탐지할 수 있는지 실험

• AI 기반 악성코드 탐지 가능성을 검증하기 위해, 여러 오픈소스 서버 바이너리에 인위적으로 백도어를 삽입하고 AI 에이전트와 Ghidra로 탐지 실험을 수행
• Claude Opus 4.6 등 최신 모델이 일부 단순한 백도어를 찾아냈지만, 탐지율은 49%, 오탐률은 28% 로 실사용에는 부적합한 수준
• 실험에는 lighttpd, dnsmasq, Dropbear, Sozu 등 C·Rust 기반 프로젝트가 사용되었으며, AI는 소스 코드 없이 역공학 도구만으로 분석을 수행
• 일부 모델은 명백한 악성 호출(execl("/bin/sh", ...))을 정상 기능으로 오인하거나, 무관한 코드에 집중하는 등 판단력 부족을 보임
• 연구진은 AI가 아직 완전한 보안 도구는 아니지만, 비전문가도 초기 보안 점검을 수행할 수 있는 수준으로 발전했다고 평가

---

연구 배경

• 최근 Shai Hulud 2.0 공급망 공격과 Notepad++ 바이너리 탈취 사건 등으로, 신뢰할 수 없는 실행 파일의 위험성이 부각됨
  • 공격자들은 정상 소프트웨어에 악성 코드를 삽입해 자격 증명 탈취나 원격 명령 실행을 수행
• 펌웨어나 하드웨어 장치에도 숨겨진 통신 모듈이나 백도어 계정이 존재하는 사례가 보고됨
• 이러한 위협에 대응하기 위해, AI가 바이너리 수준에서 악성 행위를 탐지할 수 있는지를 실험

바이너리 분석 개요

• 일반 프로그래밍은 소스 코드를 다루지만, 악성코드 분석은 기계어 수준의 바이너리를 해석해야 함
• 컴파일 과정에서 함수명, 변수명 등 고수준 정보가 사라지고, 최적화로 인해 코드 구조가 왜곡됨
• 분석은 기계어 → 어셈블리 → 의사 C 코드로 변환하는 역공학 과정을 거침
  • 오픈소스 도구: Ghidra, Radare2
  • 상용 도구: IDA Pro, Binary Ninja
• 이러한 도구는 코드의 의미를 복원하지만, 결과물은 FUN_00130550, bVar49 등 의미 없는 식별자로 가득함

BinaryAudit 벤치마크 구성

• 여러 오픈소스 서버(lighttpd, dnsmasq, Dropbear, Sozu)에 테스트용 백도어를 삽입
  • 예: HTTP 헤더를 통해 명령을 실행하거나, DHCP 옵션을 통해 쉘 명령을 수행
• AI는 소스 코드 없이 컴파일된 실행 파일만 제공받고, Ghidra·Radare2·binutils 등을 이용해 분석
• 목표는 백도어 존재 여부와 해당 함수의 시작 주소를 식별하는 것
• 일부 과제는 여러 바이너리 중 어느 것이 감염되었는지만 판별하도록 설계

탐지 성공 사례

• lighttpd 서버에 삽입된 X-Forwarded-Debug 헤더 기반 백도어를 Claude Opus 4.5가 5분 만에 탐지
  • popen() 호출을 발견하고, Radare2로 역공학하여 명령 실행 로직을 확인
  • X-Request-Trace 응답 헤더로 결과를 반환하는 구조까지 파악
• 모델은 nm, strings, grep, r2 명령을 조합해 자동화된 분석 절차를 수행

탐지 실패 사례

• dnsmasq의 DHCP 처리 코드에 삽입된 /bin/sh 실행 백도어를 Claude Opus 4.6이 정상 기능으로 오판
  • execl("/bin/sh", "sh", "-c", ...) 호출을 발견했지만, DHCP 스크립트 실행으로 착각
  • 실제로는 클라이언트 패킷의 내용을 그대로 실행하는 취약 코드였음
• 모델은 정확한 위치를 찾았음에도 위험성을 부정하고 다른 함수로 이동, 탐지를 놓침

AI의 한계와 오탐 문제

• 평균 오탐률 28% 로, 깨끗한 바이너리에서도 백도어를 잘못 보고하는 경우 다수
  • 예: Gemini 3 Pro가 정상적인 명령행 옵션 파싱 코드를 “명령 실행 백도어”로 오인
• 보안 커뮤니티에서도 AI 생성 보고서의 품질 저하가 문제로 지적됨
  • curl 프로젝트는 AI 생성 버그 리포트 중 대부분이 무의미하다고 밝힘
• 실용적 보안 도구로 사용하려면 0.001% 이하의 오탐률이 필요

오픈소스 도구의 제약

• Ghidra와 Radare2는 C 코드 분석에는 유용하지만, Rust·Go 바이너리에서는 성능 저하
  • 예: Go 기반 Caddy 서버(50MB)는 Ghidra 로딩에 40분 소요, 결과 부정확
  • IDA Pro는 5분 내 로딩 및 정확한 코드 제공
• 실험에서는 도구 품질 차이를 배제하기 위해 C 기반 바이너리 중심으로 진행

결과 및 전망

• Claude Opus 4.6: 49%, Gemini 3 Pro: 44%, Claude Opus 4.5: 37% 의 탐지율 기록
• 대형 바이너리나 정상 동작을 모방한 백도어에는 취약
• 그러나 AI가 Ghidra를 직접 조작해 역공학을 수행할 수 있는 수준으로 발전
  • 비전문가도 의심스러운 실행 파일의 1차 점검 가능
• 향후 상용 도구 연동과 로컬 모델 기반 보안 분석이 발전 방향으로 제시됨
• 전체 벤치마크와 결과는 GitHub의 QuesmaOrg/BinaryAudit에서 공개됨

[GN⁺]

Hacker News 의견들

• 그들이 난독화를 하지 않았다고는 하지만, import나 심볼을 숨기고 문자열을 난독화하면 탐지 성공률은 바로 0이 됨
  이런 경우 LLM이 탐지하는 것은 단순히 악성 행위와 연관된 언어적 이상 패턴일 뿐이라, 그리 인상적이지 않음

  • 논문 저자 중 한 명임. 이번 과제들은 입문 수준의 작업으로, 단순히 바이너리 코드만 보고도 일부 패턴을 잡아내는 모델이 있다는 점이 놀라웠음
    예를 들어 Ghidra나 Radare2 같은 툴링을 이해하는 모델은 Opus 4.5, 4.6, Gemini 3 Pro, GLM 5 정도뿐임
    관련 벤치마크는 여기에서 볼 수 있음
    이건 AI가 바이너리와 함께 일할 수 있는 출발점일 뿐이며, 완전한 솔루션까지는 아직 멀었음
  • 내가 ghidra-cli 툴을 LLM용으로 개발할 때 crackme를 테스트로 썼는데, 프롬프트로 알려주기만 하면 난독화된 코드도 잘 통과했음
    실제 소프트웨어 리버스 엔지니어링에서는 한동안 헛돌다가 난독화임을 인식하면 그때부터는 CLAUDE.md 같은 문서에 결과를 업데이트하며 매끄럽게 진행됨
  • 기사에서도 심볼을 제거했다고 명시되어 있음. 실제 백도어들은 이미 최소한의 코드로 난독화되어 있음
    예시로 dnsmasq-backdoor와 dropbear-brokenauth 패치를 참고할 수 있음
  • Opus 4.5와 4.6을 사용해 Claude Code용 Ghidra 플러그인으로 난독화된 악성 코드를 완전히 리버스했음
    다만 내가 다룬 건 국가급 백도어가 아니라 소프트웨어 크랙 수준이었음
  • LLM이 이런 특이한 패턴을 꽤 잘 파악하는 걸 봤음. 다양한 암호화·난독화 기법을 학습했기 때문임
    오히려 복잡한 논리가 LLM을 무너뜨리지만, 좋은 모델은 그 복잡성을 스스로 인식해 표시해줌

• 내 ghidra-cli 프로젝트를 소개함
  Ghidra로 Altium 파일 포맷(Delphi 부분)을 리버스했는데, 효과가 놀라웠음
  모델들이 완전한 파서를 처음부터 작성하진 못하지만, LLM 이전에는 이런 시도조차 안 했을 것임
  보안 감사에는 의존하지 않겠지만, 최신 모델은 파일 포맷 리버스 엔지니어링에는 충분히 쓸 만함

  • 요즘 에이전트를 보조 도구로 쓰는 방식을 보고 있음. 완전히 의존하지 않고 능력 확장용으로 사용함
    예를 들어 다이어그램 생성, 공격 표면 매핑, 코드 탐색 등을 맡기고 나는 수동 분석에 집중함
    LLM은 지루한 반복 작업을 대신해주므로 속도가 빨라짐. 다만 너무 많은 걸 맡기면 생산성 함정에 빠짐
    적절한 “스킬” 세트를 가진 에이전트 조합을 쓰면 확실히 효율이 높아짐
  • 우리는 PyGhidra를 쓰지만, CLI 접근성이 더 나을 수도 있음
    Ghidra의 가장 큰 한계는 Go 언어 분석 속도가 너무 느리다는 점이었음
  • 이건 정말 멋진 프로젝트임. 내가 Ghidra + LLM으로 했던 것보다 훨씬 정교함
  • 관련 생태계가 활발함. 최근 MCP 서버 사례도 있음
    나는 GhidrAssistMCP, analyzeHeadless, PyGhidra 등을 써봤는데,
    특히 명시적인 SKILL.md가 있는 접근은 AI 에이전트와의 연동성이 높음
  • 이 접근법이 여러 Ghidra MCP 서버들과 비교해 어떤지 궁금함

• 이 스레드의 핵심은 방법론 논의임
  “난독화 추가 시 성공률 0%”라는 말은 맞지만, 실험의 목적은 AI가 숙련된 리버스 엔지니어처럼 비난독화 바이너리를 다룰 수 있는지를 보는 것임
  이는 내부 감사나 레거시 코드 분석 등 실제로 쓸 수 있는 시나리오임
  진짜 중요한 건 위협 모델 정의임. 자동화된 공격자 수준이라면 이미 충분히 유용하지만,
  AI 탐지를 의식한 고급 공격자라면 이 테스트로는 부족함
  실질적인 검증은 “가벼운 난독화(임포트 숨김, 문자열 인코딩)” 수준에서의 성능을 보는 것임

  • 하지만 난독화된 바이너리를 인식 못 하는 건 캡차를 통과 못 하는 것과 같음
    날씨가 흐리면 사과를 못 따는 로봇을 “숙련된 사과 따기 전문가”라 부를 수 있을까 하는 의문임

• GPT는 거짓 양성률 0% 로 안정적이지만 탐지율은 18% 수준임
  반면 Claude Opus 4.6은 탐지율 46%로 높지만 거짓 양성률이 22%임
  만약 여러 모델을 조합해, 하나는 검증 절차를 설계하고 다른 하나는 실제 익스플로잇 테스트를 수행하게 하면 더 흥미로운 결과가 나올 듯함

  • 사실 이런 이진 분류 성능 측정 방법론은 이미 100년 전부터 존재했음
    하지만 생성형 모델이 등장하자 모두 잊은 듯함

• “AI가 완전한 악성코드 탐지를 하긴 어렵지만, 개발자가 초기 보안 감사를 수행하기는 훨씬 쉬워졌다”는 점이 핵심임
  리버스 엔지니어링 경험이 없는 개발자도 의심스러운 바이너리를 1차 분석할 수 있게 되었음
  이는 보안뿐 아니라 최적화, 디버깅, 하드웨어 리버스, 아키텍처 포팅 등 다양한 영역으로 확장될 수 있음
  결국 중요한 건, AI를 완벽한 분석기가 아니라 가설 생성 도구로 활용하는 관점임

• 벤치마크의 실행 파일들은 수백~수천 개의 함수로 구성되어 있고, 백도어는 그중 몇 줄에 불과함
  따라서 네트워크 파서나 입력 처리 루틴 등 핵심 경로를 전략적으로 탐색해야 함
  이런 전략을 .md 파일 형태로 LLM에 제공하는 것도 방법일 수 있음

  • 하지만 그렇게 하면 실험이 오염될 수 있음. “백도어가 있을 수도 있다”고 알려주는 순간 이미 힌트를 제공한 셈이 됨
    프롬프트의 미묘한 단어 하나가 결과를 바꿀 수 있음
    결국 실험 설계의 복잡성이 폭증하고, 결과의 견고성이 떨어짐
  • 그래도 이번 연구의 과제 설정이 단순했음을 감안하면 결과는 이미 인상적임
    전문가의 가이드가 더해지면 강력한 성능 증폭 효과를 낼 수 있음
  • 다만 전략을 문서로 주면 모델이 그걸 그대로 흉내 내며 “전략적 사고”를 하는 척만 할 때가 많음
    인간의 전략적 사고를 AI가 실제로 따르게 만드는 건 여전히 어려운 일임

• 직접 벤치마크 링크는 여기이며,
  오픈소스 코드는 GitHub 저장소에서 확인 가능함

• Gemini가 가짜 양성률이 가장 높다는 결과는 내 경험과 일치함
  ChatGPT, Claude, Gemini를 모두 써봤는데, Gemini가 가장 긍정 편향적임
  항상 가장 낙관적인 답을 내놓음
  이런 특성을 수치로 보여주는 벤치마크를 찾고 있었는데, 이번 결과가 그 근거가 될 수 있음

• 나는 전문가가 아니지만, 거짓 양성 문제를 줄이려면 모델이 직접 백도어를 실행해 검증하도록 하면 어떨까 생각함

  • 하지만 대부분의 모델은 안전성 정책 때문에 그런 행동을 거부함
    그래서 교차 모델 비교가 어렵고, 대신 모델이 백도어 위치를 명시하도록 요구함
    직접 모델을 커스터마이징하거나 파인튜닝한다면 제안한 방식이 유용할 수 있음

• 최고 성능 모델이 약 50%만 탐지했다는 건 나쁘지 않음. 인간보다 나을 수도 있음
  하지만 나머지 50%는 왜 놓쳤는지가 궁금함
  Claude Opus 4.6이 백도어를 찾아놓고도 “문제없음”이라 결론 내린 건 흥미로움
  결국 AI가 인간의 판단 보조 없이는 완전한 이해에 도달하기 어렵다는 걸 보여줌