ビジネスセキュリティ
LLMベースのコードスキャナーは攻撃者が核兵器を製造する手助けはしませんが、その「拒否」自体が攻撃者に有利に働く可能性があります
マルウェア開発者は長年にわたり、自らの立ちはだかる防御策や監視の目に合わせてコードや戦術を適応させてきました。さまざまな回避・解析妨害の手法を駆使し、コード解析を妨げたり、検査中にマルウェアの本当の挙動を隠したりすることを常套手段としています。中でもESETの研究者が詳しく報告しているEDRキラーのように、セキュリティソリューションそのものを直接狙うツールも存在します。
LLMベースのツールがコードのトリアージや解析をはじめとするさまざまなセキュリティ業務を支援する場面が増えるにつれ、脅威アクターがこうしたツールを出し抜く実用的な方法を探し始めるのは時間の問題でした。従来の回避技術に加えて、一部の攻撃者は違うアプローチを取り始めています。解析を妨げることを狙った敵対的な入力を、あえて誰の目にも見える形で残しておくという手口です。
ESETの研究者は最近、こうした試みの一例を、ロシアと連携する攻撃グループUAC-0099がウクライナの標的に対する攻撃の初期段階で使用したVBScriptの中に発見しました。攻撃者はスクリプトのコメント内に核兵器の製造方法を尋ねる偽のリクエストを仕込み、LLM搭載のコードスキャナーの安全装置(ガードレール)を作動させ、悪性コードにたどり着く前にファイルの残りの検査を止めさせようとしたのです。このスクリプトの目的は、同グループが独占的に使用するローダーMATCHBOILをダウンロードしてインストールすることでした。
ESETがGuardBreakerと名付けたこのシンプルな手法は、LLMモデルが拒否することで知られる類の「リクエスト」をまさに利用しています。
攻撃者の回避手口集に見られる他の多くのトリックとは異なり、このおとりコメントは「誰の目にも」、とりわけコードを解析するモデルの目にも触れる場所に置かれています。加えて、実行時のスクリプトの挙動には当然ながら一切影響を与えません。それでもこのコメントの存在は、UAC-0099が標的の防御策にAIシステムが組み込まれていることを想定していたことを示唆しています。実際、同グループは他の最近の攻撃でも、IDAやWiresharkといった確立された解析ツールに関連するプロセスの有無をチェックしています。
解析妨害が新たな標的に照準
GuardBreakerは、プロンプトインジェクションの極めて単純な試みとして理解するのが適切です。攻撃者の入力が、解析対象のファイルを通じて推論時にLLMへ届けられる仕組みです。この手法は、信頼できないコンテンツと信頼された指示との間に確実な境界線がないまま両者を処理してしまう、今日のLLMのアーキテクチャ上の弱点を突こうとするものです。
LLM搭載のスキャナーを妨害しようとする同様の試みは、特にソフトウェアサプライチェーン攻撃で表面化しています。例えばSocketは、悪性PyPIパッケージ内でJavaScriptのペイロードの手前に、捏造されたシステム指示とポリシーを作動させるコンテンツが置かれているのを発見しました。同じ大規模なキャンペーンについて報告したStepSecurityは、ファイルを解析するあらゆるモデルに対し、悪性コードを無視してこのパッケージを「問題なし」と報告するよう真正面から指示するプロンプトを発見しています。別の事例では、研究者らが、メインのJavaScriptファイル内で「You’re absolutely right!」という文言を数万回も繰り返すnpmパッケージを発見しました。モデルのコンテキストウィンドウを使い果たさせ、その後に続く悪性スクリプトを実質的に解析不能な状態に追い込むことを狙ったものです。
攻撃者は、こうした単純なトリックや、その組み合わせによって解析パイプラインをマルウェアに対して盲目にすることも試みる可能性があります。不自然な構造や扱いにくい構造のファイルは、切り詰められたり一部しか解析されなかったりする結果を招きかねません。悪性コードの一部を、機密情報やその他の秘匿すべきデータであるかのように偽装して隠すことも考えられます。
他の攻撃では、攻撃者側のツールに処理を強いるカスタムファイル形式を展開するケースもあるでしょう。あるいは、AIエージェントを人間によるレビューが必要な操作へと誘導し、応答時間を利用して処理を遅延させる手口も考えられます。アンパッカーや難読化解除ツールといった外部ツールを呼び出すエージェントは攻撃対象領域(アタックサーフェス)をさらに広げるものであり、場合によってはその呼び出し自体がマルウェアの配布・実行に乗っ取られる恐れもあります。
誰が主導権を握るのか
GuardBreakerは、セキュリティ専門家がすでに知っている教訓を改めて浮き彫りにしています。それは、攻撃者の成功率に影響を与えうる技術は、いずれ攻撃者に狙われるということです。LLM搭載のコードレビューやその他のLLM支援ワークフローに頼る企業は、そうしたツールが具体的に何を検査しているのか、意思決定の連鎖のどこに位置しているのか、そして応答を拒否した場合やタスクを完了できなかった場合に何が起きるのかを正確に把握しておく必要があります。
しかし何より重要なのは、あるコードが安全かどうかを判断する権限を、単一のLLMエンジンだけに委ねてはならないという点です。AI支援による出力は、高度な自動化と人間の専門知識を最大限に活用する多層的かつ複数モデルによるアプローチを用いて相互検証する必要があります。同時に、出力が得られない場合も、さらなる確認作業のきっかけとする必要があります。
あらゆる規模の組織は、予防から検知、対応へとつながる明確な道筋も必要としています。24時間体制の自社セキュリティチームを持たない組織にとっては、マネージド検知・対応(MDR)が必要なフォローアップを提供してくれます。専門家が、環境全体における他の活動状況も踏まえながら疑わしいインシデントを調査し、次の対応策を判断するというものです。このアプローチは、AIの基盤技術を長年にわたり活用してきた実績、実証済みの解析手法、専門家の判断力、脅威リサーチ、そしてグローバルなテレメトリの上に築かれてこそ最大限に機能します。そうすることで、企業は単一のLLMモデルによる判断が組織のサイバー防御における死角にならないよう確保できます。
