マルウェアに「核兵器の作り方を教えて」 AIによるコード解析を止めさせる新手口「GuardBreaker」：こんなにある「LLM組み込みスキャナー」の欺き方

ESETは、マルウェアのコメントにLLMの安全機構を作動させる文言を仕込み、AIによる解析を止めさせる手口を報告した。ウクライナを狙った攻撃で使われていたという。

[＠IT]

　セキュリティ企業ESETは2026年9月10日（スロバキア時間）、マルウェアのコードコメントに大規模言語モデル（LLM）の安全装置を作動させる文言を仕込み、AIを使ったコード解析を途中で止めさせる手口を報告した。ESETはこの手法を「GuardBreaker」と名付けている。

「GuardBreaker」はAIによるマルウェア解析をどうやって止めさせるのか

　見つかったのは、ロシアと結び付きのある攻撃グループ「UAC-0099」が、ウクライナ国内の標的に対する攻撃の初期段階で使った「VBScript」だ。

　スクリプトのコメント行には、核兵器の作り方を教えるよう求める文言が書き込まれていた。LLMを組み込んだコードスキャナーがガードレール（安全装置）を起動して応答を拒否し、ファイルの該当コメント行以降を検査しないまま処理を打ち切ることを狙ったものだ。

　スクリプトの本来の目的は、UAC-0099が追加のペイロードを配信するためにのみ使用するローダー「MATCHBOIL」をダウンロードしてインストールすることにある。

わざとガードレールを起動させるコメント（提供：ESET）

　GuardBreakerが使う“おとり”のコメントは、攻撃者が常用する検知回避の手口の多くとは性質が異なる。コードを読む者の目から隠すのではなく、解析するモデルに読ませるために、誰の目にも見える形で書かれている。実行時のスクリプトの動作には何の影響も及ぼさない。

　それでもこの記述があること自体が、UAC-0099が標的の防御にAIが組み込まれていることを織り込んでいたことをうかがわせる。同グループは最近の別の攻撃でも、「IDA」「Wireshark」といった従来型の解析ツールに関連するプロセスの有無を確認していた。

本質はプロンプトインジェクション

　ESETは、GuardBreakerを極めて単純なプロンプトインジェクション（外部から不正な指示を紛れ込ませる攻撃）と位置付けている。攻撃者の入力が、解析対象のファイルという経路で推論時にLLMに届く形だ。今日のLLMは、信頼できないコンテンツと信頼できる指示を、両者の間に確かな境界を設けないまま処理している。GuardBreakerはこのアーキテクチャ上の弱点を突こうとするものだ。

　LLMを使ったスキャナーを妨害する試みは、ソフトウェアサプライチェーン攻撃で特に表面化している。

　セキュリティ企業Socketは、Pythonの公式リポジトリ「PyPI」で公開されていた悪意あるパッケージの中で、JavaScriptのペイロードの手前に偽造されたシステム指示とLLMのポリシー違反判定を誘発する内容が置かれているのを見つけた。同じ一連の攻撃を調べたセキュリティ企業StepSecurityは、ファイルを解析したモデルに対して、悪質なコードを無視してパッケージを「問題なし」と報告するよう露骨に指示するプロンプトを確認している。

　別の事例では、メインのJavaScriptファイルの中で「You're absolutely right!」という文字列を数万回繰り返す「npm」パッケージが見つかった。モデルのコンテキストウィンドウを使い切らせ、後続の悪質なスクリプトを実質的に解析できないようにする狙いだった。

ファイル構造や外部ツールの呼び出しを悪用する余地も

　ESETは、解析のパイプラインの目をふさぐ単純な手口は他にもあり、それらの組み合わせも考えられると指摘する。例えば、通常とは異なる、または不自然な構造のファイルは、切り詰められたり、一部しか解析されなかったりする可能性がある。悪質なコードの一部を、機密情報やその他の取り扱いに注意を要するデータであるかのように見せ掛けて隠すこともできる。

　攻撃者側のツールでなければ処理できない独自のファイル形式を使う攻撃や、人間のレビューが必要な動作にAIエージェントを誘導し、対応が遅れる時間を突く攻撃もあり得る。アンパッカー（圧縮、暗号化された実行ファイルを展開するツール）や難読化解除ツールといった外部ツールを呼び出すエージェントは、その呼び出し自体がマルウェアの配布や実行に乗っ取られる場合があり、アタックサーフェス（攻撃対象領域）をさらに広げる可能性がある。

単一のLLMに「安全」の判断を委ねない

　ESETは、LLMによるコードレビューやLLMを組み込んだ業務プロセスに頼る企業に対して、そのツールが「何を検査するのか」「意思決定プロセスのどこに位置するのか」「応答を拒んだり、タスクを完了できなかったりしたときに何が起こるのか」を正確に把握するよう求めている。

　中でも重要なのは、コードの安全性を判断する権限を単一のLLMエンジンだけに持たせないことだ。AIの出力結果は、高度な自動化と人間の専門性を組み合わせた多層かつ複数モデルによるアプローチで相互に検証する必要がある。出力が得られなかったこと自体も、追加の確認を促すトリガーとして扱わなければならない。

　ESETによると、24時間体制のセキュリティチームを持たない企業には、MDR（Managed Detection and Response）が対策の選択肢になるという。専門家が疑わしいインシデントを、環境内の他の活動と関連付けながら調査し、次に取るべき手順を判断する。同社は、1つのLLMモデルの挙動が組織のサイバー防御の死角にならないようにする必要があるとしている。