Help Net Securityのインタビューに、HUMAN Securityの脅威インテリジェンス担当VPであるLindsay Kaye氏が応じ、AI生成マルウェアを解析の現場で見るとどう映るのかを語りました。同氏は、整った形式のコメント、統一されたログメッセージ、絵文字を、モデルが書いたスクリプトの兆候として挙げています。一方で、デコンパイルされたコードではこうした痕跡の多くが失われると指摘します。このほかKaye氏は、AIがパッチ適用に使える時間をどう圧縮しているか、犯罪者の不正行為の規模拡大をどう後押ししているか、そしてチームが結論を公開する前に必ず人間によるレビューを入れている理由についても話しました。
Nullcon Berlinに参加される方は、11月5日15:30〜16:15のパネルディスカッション「Agents Gone Wild」に、Kaye氏が登壇しますのでご注目ください。パネルディスカッション
Kaye氏は、手作業でマルウェアを分解するキャリアを積んでこられました。AIの支援を受けて書かれたと思われるマルウェアをリバースエンジニアリングする際、解析の現場では何が違って見え、5年前と何が変わっていないのでしょうか。
現時点では、現在の職務において、完全にAIで書かれたマルウェアを明確にリバースエンジニアリングした経験は、少なくとも私の知る限りありません。CheckPointが公表した「VoidLink」マルウェアのようなものが、それに近いと考えています。ただ、AIを使って書かれたと思われるスクリプトやコード片に出会うことはあり、いくつか際立った特徴があります。
- 悪意あるスクリプト（デコンパイルや逆アセンブルされたコードではないもの）では、各関数を説明するコメントが同じ型や書式で付けられていたり、絵文字が使われていたりします。これはソフトウェア開発では確かに良い習慣ですが、マルウェアの作者が普通やることではありません。なお、ご存じのとおり、デコンパイルされたコードではコメントはコンパイル時に消えるため、残っていません。
- 同様に、デコンパイルや逆アセンブルされたコードでは、構造のよく似たログメッセージが並び、スペルや文法もプロの開発現場のコードのように正確なことがあります。ここでも絵文字が使われている場合があります。
- 私は現在の職務で、モバイルアプリやHTML5ゲームサイトに現れることの多い広告詐欺に重点的に取り組んでいます。AI登場以前は、1つのキャンペーンで確認されるアプリは数十本でした。しかし今ではアプリのコンテンツ生成がはるかに容易になり、数百本に達しています。当然ながら、こうしたアプリやサイトを調べると、大量生産されたように見えたり、技術的な共通点があったりします。しかも、新しいものが以前よりずっと速いペースで出現しています。
こうした特徴を持つコードがすべてAI生成というわけではありません。ただ、LLMで生成したコードは「計画的に作られた」ものであり、「優れた」設計パターンやコーディング作法に沿って構造化されています。一方、デコンパイルや逆アセンブルされたコードそのものを見る場合（先ほど挙げた指標を除く）は、多くの文脈が失われます。デコンパイラはC/C++のようなコードを完全には復元できないためです。そこに難読化が加わると、判別はさらに難しくなります。逆に、以前とまったく変わらない点としては、次のようなものがあります。
- インターネット上で簡単に見つかるサンプルコードは、今もマルウェアに登場します。過去のように手作業でコピーされたのか、LLMへのプロンプトで引き出されたのかを問わず、「MyWindowClass」のような「プレースホルダー」名の使用といった痕跡から、作者自身が書いたコードではないと推測できることがよくあります。
- O-MVLLなどの難読化ツールキットや独自の手法を使って、リバースエンジニアリングを難しくする例も引き続き見られます。こうしたツールキットも独自手法もかなり高度になり得るため、解析は非常に困難になります。しかも現在では、独自手法が作者自身によるものか、何らかの形でAIの助けを借りて作られたものかを見分けるのは、決して簡単ではありません。
結局のところ、AIはマルウェア開発者の仕事を楽にする手段であり、特定の目的のためのコードやスクリプトをより簡単に組み立てられるようにします。ただ、マルウェアに関するAIの使い方のうち、最も興味深く、影響も大きくなり得るのは、PROMPTSTEALのように、実行中に自らの挙動を変えるためにAIを使うケースだと考えています。AIが攻撃者の攻撃の進め方をどう変えるのか、そしてそれにどうすればより効果的に防御できるのかを、ぜひ見極めたいと思います。
脆弱性の公開から数分で動作するエクスプロイトコードが出てくるとしたら、パッチ適用の猶予はどうなるのでしょうか。防御側は、対応を日単位で測るのをやめるべきでしょうか。
AIが普及したことで、セキュリティ上の欠陥や脆弱性の発見は、より多くの人にとって身近で容易になっただけでなく、はるかに速く、大規模に行えるようになりました。PHP2Shellのリモートコード実行（RCE）の脆弱性はその好例です。もしセキュリティ研究者による公表ではなく、攻撃者に広く悪用されていたら、特にパッチが提供される前の被害は甚大になり得ました。
パッチ適用は、特にエクスプロイトが存在する脆弱性に対処するうえで、セキュリティチームにとって最も重要な手段の1つです。一方で、依存関係のバージョン管理、パッチが他の部分を壊さないことの確認、適用に伴うダウンタイムなど、適用までの時間を延ばしがちな課題も伴います。脆弱性が公開された際（特にPoCエクスプロイトも公開されている場合）に時間的なプレッシャーがかかるのは昔からのことです。しかし現在は、公開される脆弱性の数が増えているうえ、悪用までの道のりもおそらくより速く容易になっています。その結果、防御側が対処に使える時間はさらに狭まっています。
あらゆる組織に当てはまるパッチ適用期間を正確に示すのは難しいですが、AIを使う攻撃者によって加速するタイムラインに、私たちが対応していかなければならないことは確かです。
攻撃者にとってボトルネックだったのは、コードではなく、アクセス、インフラ、換金でした。AIは犯罪のエコノミクスをどこで変えているのでしょうか。盗まれたアカウントのダークウェブ上の価格に、その影響は表れていますか。
AIは全般的に、アカウント関連の不正を含むあらゆる種類の詐欺を働くサイバー犯罪者の参入障壁を下げています。ただ、現在見られる「恩恵」の多くは、拡張性の向上と攻撃の効率化にあります。これはいくつかの形で表れています。
- 「コンテンツ」の生成。被害者の金融情報や個人情報を盗むためのフィッシングページやメッセージの作成、ロマンス詐欺や豚の屠殺（pig butchering）詐欺で被害者とやり取りして引き込む会話、広告を何度も読み込ませるのに十分な時間、読者を引き留めるためのAI執筆ブログ記事の用意、ストリーミング詐欺を可能にする音声トラックの作成などが含まれます。
- 大量のデータから必要な情報を探し出すこと。ステalerなどから窃取したデータ（ステalerはAI登場以前から存在し、今も被害者データを入手する一般的な手法です）、企業から盗んだデータ、サイトからスクレイピングしたデータには膨大な情報が含まれます。AIはそれを構造化したり選別したりして、最も有用な部分を特定する助けになります。たとえば、盗まれたブラウザーデータの中から、セッションハイジャックに使えるセッションCookieやトークン、有効な認証情報、パスワードデータを含むファイルなどが見つかります。いずれも、攻撃のエスカレーションや横展開、新たな攻撃に利用される可能性があります。
- データの検証。私たちが観測した興味深い事例に、AIエージェントを使ってカーディングのような行為を行うものがありました。従来、攻撃者は不正利用のために他の攻撃者へクレジットカード番号を販売する前に、番号をテストして有効性を確認します。検証済みのカードは、未検証のものより高く売れます。
アカウントの価格については、AIが原因だと直接言えるほどの大きな変化は見ていません（価格は主に需給関連の要因で決まります）。ただ、先ほど述べたとおり、こうしたアカウントの入手や検証の経済性は、AIが攻撃者に利益をもたらす分野であることは間違いありません。
モデル提供事業者は、現在共有していない情報で、脅威インテリジェンスチームに何を共有すべきでしょうか。AIプラットフォームからの悪用指標は、IOCのように流通させるべきでしょうか。
正直なところ、「AI悪用指標」がここで適切な単位なのかは疑問です。先ほどのリバースエンジニアリングの話と同様に、攻撃者がAIを使ったと知ることは興味深い背景情報ではあるものの、通常は防御の役に立つ決め手にはなりません。重要なのは、その活動が標的上で何を行うかです。
とはいえ、すでにある取り組みにも確かな価値があります。
- Googleなどが攻撃者によるAIツールの利用に関する調査を公開しており、これらのツールがどのように使われているかを防御側が把握できます
- ATLAS内にあるMITREのAI Incident Sharing Initiativeは、複数の参加組織とSTIXベースのチャネルを立ち上げています。ATLASも生成AIの手法やケーススタディを追加し続けています
私には、独立した指標フィードを作るよりも、こちらのほうが有益な方向に思えます。IOCが実用的なのは、ハッシュやドメインのように具体的で、ある程度長持ちするからです。「モデルが関与した」という情報はどちらでもありません。プロンプトのパターンのようにさらに細かい情報は、モデルが更新された途端に使えなくなりがちです。
そのため、あえて要望を挙げるなら、手法の文書化を続け、各チームがすでに使っているフレームワークに反映してもらうことです。その形式であれば、検知エンジニアに届きます。
また、これは双方向の対話だとも思います。AIを使った活動を下流で目にしている私たちも、プラットフォーム事業者と同じくらい、この全体像に貢献できます。
Kaye氏のチームは、脅威リサーチでAIをどのように活用していますか。また、どの場面ではモデルに判断を任せないのでしょうか。
これまでのところ、私のチームはAIをワークフローの補強手段として使っています。好例は、多様なソースから集めたデータの要約や、そのデータへの質問にAIを使うことです。データ処理としては、ピボットの起点にしたいレポートからIOCを抽出する作業があります。さらに、当社の顧客や製品を狙うツールにどのようなものがあるか、前回確認した時から変化があったか、監視しているアンダーグラウンドフォーラムでこれらの話題がどう語られているかを把握したいと考えています。
AIはこうした問いを立てる手助けをし、出発点となる初期の回答を示してくれます。ただし、AIの出力は、人間が結論の正しさを確認し、AIにはない追加の知見を踏まえて調査結果をレビューしない限り、そのまま共有することはできません。
もう1つの例は、関心のあるサンプルに関連する追加のマルウェアを探すための検知ルール作成の支援や、属性の共通点に基づくサンプルや異なる主体・グループのクラスタリングの補助としてAIを使うことです。ここでもAIは、私たち自身の分析的な結論へより速く近づくための手段であり、人間が担う分析の層に取って代わるものではありません。
翻訳元: https://www.helpnetsecurity.com/2026/11/04/lindsay-kaye-human-security-ai-generated-malware/
