- 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 を直接操作してリバースエンジニアリングを行える水準まで進歩
- 今後の方向性として、商用ツール連携とローカルモデルベースのセキュリティ分析が示されている
- ベンチマーク全体と結果は GitHub の QuesmaOrg/BinaryAudit で公開されている
1件のコメント
Hacker News の意見
難読化はしていないとはいえ、import やシンボルを隠し、文字列を難読化すれば検出成功率はすぐに 0 になる
この場合、LLM が検出しているのは単に悪意ある挙動に関連した言語的な異常パターンにすぎず、それほど印象的ではない
たとえば Ghidra や Radare2 のようなツーリングを理解するモデルは、Opus 4.5、4.6、Gemini 3 Pro、GLM 5 くらいです
関連ベンチマークはこちらで見られます
これは AI がバイナリと一緒に作業できる出発点にすぎず、完全なソリューションまではまだ遠いです
実際のソフトウェアのリバースエンジニアリングでは、しばらく空回りしたあと難読化だと認識すると、その後は CLAUDE.md のような文書に結果を更新しながらスムーズに進みます
例として dnsmasq-backdoor と dropbear-brokenauth のパッチを参照できます
ただし私が扱ったのは国家級のバックドアではなく、ソフトウェアクラック程度のものでした
むしろ複雑なロジックのほうが LLM を崩しますが、良いモデルはその複雑さを自分で認識して表示してくれます
自分の ghidra-cli プロジェクトを紹介します
Ghidra で Altium のファイルフォーマット（Delphi 部分）をリバースしたのですが、その効果は驚くほどでした
モデルが完全なパーサーをゼロから書けるわけではありませんが、LLM 以前ならこんな試み自体しなかったでしょう
セキュリティ監査に全面的に頼るつもりはありませんが、最新モデルはファイルフォーマットのリバースエンジニアリングには十分使えます
たとえば図の生成、攻撃面のマッピング、コード探索などを任せ、自分は手動分析に集中します
LLM は退屈な反復作業を肩代わりしてくれるので速度が上がります。ただし任せすぎると生産性の罠にはまります
適切な「スキル」セットを持つエージェントの組み合わせを使えば、確実に効率は上がります
Ghidra の最大の制約は、Go 言語の解析速度があまりにも遅いことでした
私は GhidrAssistMCP、analyzeHeadless、PyGhidra などを使ってきましたが、
とくに明示的な SKILL.md があるアプローチは AI エージェントとの連携性が高いです
このスレッドの核心は方法論の議論です
「難読化を追加すると成功率 0%」という話はその通りですが、実験の目的は AI が熟練したリバースエンジニアのように非難読化バイナリを扱えるかを見ることです
これは内部監査やレガシーコード分析など、実際に使えるシナリオです
本当に重要なのは脅威モデルの定義です。自動化された攻撃者レベルが相手ならすでに十分有用ですが、
AI 検出を意識した高度な攻撃者が相手なら、このテストでは不十分です
実質的な検証は「軽い難読化（インポート隠し、文字列エンコード）」レベルでの性能を見ることです
天気が曇るとリンゴを摘めないロボットを「熟練したリンゴ摘みの専門家」と呼べるのか、という疑問です
GPT は偽陽性率 0%で安定していますが、検出率は 18% 程度です
一方 Claude Opus 4.6 は検出率 46% と高いものの、偽陽性率は 22% です
もし複数モデルを組み合わせて、1 つに検証手順を設計させ、別の 1 つに実際のエクスプロイトテストを実行させれば、もっと興味深い結果になりそうです
それなのに生成モデルが登場すると、みんな忘れてしまったようです
要点は、「AI が完全なマルウェア検出を行うのは難しいが、開発者が初期のセキュリティ監査を行うのははるかに簡単になった」ということです
リバースエンジニアリング経験のない開発者でも、疑わしいバイナリを一次分析できるようになりました
これはセキュリティだけでなく、最適化、デバッグ、ハードウェアのリバース、アーキテクチャ移植などさまざまな領域に広がり得ます
結局重要なのは、AI を完璧な解析器ではなく仮説生成ツールとして活用する視点です
ベンチマークの実行ファイルは数百〜数千の関数で構成されており、バックドアはそのうち数行にすぎません
したがって、ネットワークパーサーや入力処理ルーチンなど重要な経路を戦略的に探索する必要があります
こうした戦略を .md ファイルの形で LLM に与えるのも方法かもしれません
プロンプトの微妙な一語が結果を変えかねません
結局、実験設計の複雑さが爆発的に増し、結果の頑健性が下がります
専門家のガイドが加われば、強力な性能増幅効果を生み出せる可能性があります
人間の戦略的思考を AI に本当に従わせるのは、依然として難しい課題です
ベンチマークへの直接リンクはこちらで、
オープンソースコードは GitHub リポジトリで確認できます
Gemini が偽陽性率が最も高いという結果は、自分の経験と一致します
ChatGPT、Claude、Gemini をすべて使ってきましたが、Gemini が最も肯定バイアスが強いです
いつも最も楽観的な答えを出します
こうした特性を数値で示すベンチマークを探していたのですが、今回の結果がその根拠になりそうです
私は専門家ではありませんが、偽陽性の問題を減らすには、モデル自身にバックドアを実行して検証させてはどうかと思います
そのためクロスモデル比較が難しく、代わりにモデルにバックドアの位置を明示させるよう求めています
モデルを直接カスタマイズしたりファインチューニングしたりするなら、提案された方法は有用かもしれません
最高性能のモデルが約 50% しか検出できなかったのは悪くありません。人間より優れている可能性すらあります
ただ、残りの 50% をなぜ見逃したのかは気になります
Claude Opus 4.6 がバックドアを見つけておきながら「問題なし」と結論づけたのは興味深いです
結局これは、AI が人間の判断支援なしに完全な理解へ到達するのは難しいことを示しています