약 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에서 공개됨