この記事は、Cisco Talos の Security Research Enginner である Nick Biasini, Dmytro Korzhevin, Jaeson Schultz, Vanja Svajcer, Vitor Ventura, Arnaud Zobec によるブログ 「“Keep going, bro. You’ve got this!” A data-driven look at how adversaries are weaponizing AI 」（ 2026/08/04 ）の翻訳です。
- 脅威アクターによる AI の使用が激増しています。Talos は、残されたアーティファクトを分析することで、攻撃者によるこの技術の利用方法についての知見を詳細な分析結果にまとめました。開発、フォースマルチプライヤー、脆弱性リサーチを取り上げています。
- Talos が収集した証拠を見ると、ガードレールは十分な保護手段となっておらず、高度な手法やコード化を使用していないにも関わらず、ほとんどの脅威アクターがモデルを説得して従わせることに成功しています。
- 脅威アクターの既得のスキルに応じて、AI を使用して達成できる内容が大きく変わります。Talos は、初心者のユーザーでも悪意ある機能を作成できることを目の当たりにしました。ただしその機能や成功の度合いは限定的でした。上級ユーザーであれば、驚異的な機能を構築し、精巧で複雑な出力を作成させることが可能でした。
人工知能（AI）と関連する言語モデルは、今ではどこにでもあり、タスクの合理化や能力の拡張を目的に、個人的な場面でも業務でも多用されています。AI がほぼすべての人によっていたるところで使用されている状況で、最大の疑問点の 1 つとなっているのが悪意あるアクターによるその利用方法です。幸いなことに、アクターは間違いを犯し、チャットボットはアーティファクトを残します。
クラウドベースの AI モデルを使用すると、さまざまなアーティファクトが残されます。その代表例がプロンプトログです。これらのログは形状もサイズも異なりますが、Claude Code、CodeX、Cursor、Gemini といったさまざまなアプリケーションが動作しているエンドポイントに残されます。
Talos は、リサーチの過程でこれらのファイルの重要なコーパスを収集しました。その結果、悪意あるアクターがこの技術を利用する方法についての知見を基に、検討を開始することが可能になりました。リサーチを進めるなかで、アクティビティに 3 つのカテゴリがあることが明らかになりました。1 つは悪意あるソフトウェアエンジニアとして AI を使用するというものです。この場合、AI は、明白な悪意ある意図をもって（ケースによっては）非常に精巧なコードを書くために使用されます。もう 1 つは、アクターが犯罪的な行動やマルウェア攻撃を拡大するために AI を利用するというものです。最後の 1 つは、バグバウンティまたは脆弱性リサーチのために AI を利用するというものです。これを行うアクターは多くいて、発見と公開の能力を急速に高めています。
それぞれのカテゴリを見ると、攻撃者による現在の AI の活用方法が明らかになります。同じカテゴリに属していても、関与するアクターの知識レベルによって精巧さに大きな開きがあります。ユースケースを盛り込むことで、知り得た広範な事実を網羅することを試みました。
重要なポイントと調査結果の概要
Hugging Face と OpenAI による最新の開示内容を見ると、実質的にエージェント型攻撃者の時代が到来したことは明らかです。開示されたインシデントでは、保護が意図的に緩和された承認済みの評価環境の中でモデルを動作させていました。しかしそのモデルは、自律的にサンドボックスから離脱し、実際の脆弱性を見つけて連鎖させたうえで、実稼働環境を侵害し、目的を達成しました。機能は実現しています。唯一欠けているものは悪意であり、これを攻撃者が教え込むのは時間の問題です。防御システムにとってこれは警鐘となるものです。脆弱性の露見とエクスプロイトの発生は早まり、その背後にいるアクターは休息もダウンタイムも必要としません。以下のケーススタディからわかるように、ガードレールが現在直面している中心的な課題は、本来のデュアルユースの業務、つまりレッドチーミングと脆弱性リサーチを、悪意あるアクターを利することなくサポートすることです。
まず把握すべき重要ポイントの 1 つは、ガードレールが期待どおりに機能していないということです。モデルをだますために設計された精巧なコード化や手法を目にしたことはありません。ほとんどの場合、「私はこれをする許可を得ています」というシンプルなもので、それにモデルが従っています。ガードレールが実際に稼働していても、ほとんど何も達成できていません。あるケースでは、アクターが検閲済みのモデルを放棄して未検閲のバージョンに軸足を移したことが確認されました。それでも問題なくタスクが完了しました。別のケースでは、モデルが分散型サービス妨害（DDoS）のオペレーターを阻止しましたが、その時点までにツールの構築が完了していました。これは、単一のモデルやプラットフォームに限定されたものではなく、一般的に見られるものでした。
もう 1 つの重要ポイントは、AI の利用によって得られる効果の程度や最終的にもたらされる影響の大きさがアクターのスキルレベルによって決まるということです。未熟なアクターであっても、AI を使用して技術的には機能する悪意あるプロジェクトを組み立てることができます。しかし、ツールをさらに強化するための専門知識がないため、見劣りする結果しか得られません。つまり限られた機能しか実現できず、構築したものの更新や改善はほとんど不可能です。一方熟達したアクターは Talos が想定していた可能性の限界を押し広げています。つまり、侵害のための非常に効果的なプラットフォームを構築したり、ゼロデイのパイプラインを組み立てて、目的に応じて開示または売りつけに使用したりしています。彼らが手にすれば、AI は本物のフォースマルチプライヤーになります。
企業の視点から見ると、各組織は、攻撃者がパイプライン中で AI を多用していて、防御システムも同じことをする必要があることを理解する必要があります。押し寄せるさらなる脆弱性、アラート、インシデントの洪水に対処できる体制を備えた組織が、準備が整った組織と言えるでしょう。これらの量が増えるにつれて、SOC でエージェントが果たす役割が拡大しています。そして、実用的なアラートを識別することがきわめて重要になるでしょう。エージェント機能を導入すれば、人間のアナリストは最も重要なアラートに集中できるようになります。この機能の調査をまだ進めていない組織は、まもなくこれを追い求めることになるはずです。
アクターがガードレールを回避する方法
すでに述べたように、Talos は精巧なコード化やその他の大規模な回避手法を目にしたことがありません。むしろアクターは、十分に試行されたいくつかの方法を使用することで、かなり成功しているようです。最もよく見られる方法の 1 つは所有権の主張でした。追加の検証なしに単に機器やインフラストラクチャに対する所有権を主張する手法が多くの環境で有効でした。
アクターが Capture the Flag（CTF）またはバグバウンティのラベル付けを使用して成功した例も多く見つけました。これによってモデルのロックが解除され、脆弱性の発見やそれに続くエクスプロイトなどのさまざまなタスクが可能になりましたが、実質的なフォローアップや追加の調査は行われていません。
さらには、ガードレールをバイパスする効果的な手段として、タスク分割を利用したアクターも目にしました。これは、リスクのあるアクションを複数のセッションやファイルにまたがって分割するものです。コンポーネントを時間をかけて構築し、悪意あるコンポーネントを計画的に処理して、モデルによる保護を回避するのに十分な程度まで分割します。
一括認証やペルソナ条件付けの試みを成功させた例も目にしました。これは、メモリやその他のさまざまなマークダウンファイルを使用して、アクションの事前承認や事前許可を得る手法です。
最も興味深かったものは、Hephaestus アクティビティで確認された意味的回避手法です。このケースでは、アクターが独自のプラットフォームを構築し、明らかに悪意のある動詞の代わりに中立的なものを使用することで拒否を完全に回避していました。結果として、エージェントに操作の全体的なコンテキストを認識させることなく無害なリクエストを実行させることにかなり成功していました。
ユースケース：悪意あるソフトウェアエンジニアとしての AI
AI の力を借りた DDoS オペレーター
Talos が発見したさらに興味深い例の 1 つを見ると、分散型サービス妨害（DDoS）ツールを作成するアクターの活動が浮き彫りになります。当初アクターは、ホームネットワークのために開発した DDoS 保護機能のストレステストを実行しているかのように装っていました。ターゲットを確認するために何回かやり取りを繰り返した後、モデルはそれに従って機能の開発を開始しました。Talos が確認したプロンプトによれば、アクターはプログラミングに対する深い理解はないものの、開発したいものに関する明確な意図は持っているようでした。これはやり取りが始まった際の状況です。
何回かやり取りを繰り返した後、ボットを使用して全体を開発しようとしているものの、アクターは動作原理をほとんど理解していないことが明らかになりました。アクターが行ったいくつかの質問からこのことが証明できます。
これがまっとうなアプリケーションでないことも明確になりました。ほとんどのストレステスターは、攻撃というラベルを使用しません。
ボットは最終的にそれに従って、ストレステストを実行するために必要なツールを提供しました。少し興味深くなるのはここからです。ツールが完成した後、アクターは、ボットが正しい接続を行っておらず、サーバーにとってビンが大きすぎると文句を言っています。
その後まもなく、本当のターゲットが明らかになりました。
Android TV に言及したのはこれが初めてですが、これが最後ではありません。続いてアクターは、ツールの試行を繰り返し、「認証パスを削除してください。認証は不要です」といった非常に基本的な指示を出しました。モデルが機能や能力の実装を拒否し始めたのはこの時点です。確認できた一連のプロンプトからこのことが証明できます。
作成済みのプラットフォームに接続され始めたボットの数によってこれが促されたものと思われます。制御しようとしているボットの数が示されたのはこの時点が初めてです。
やり取りが進むにつれて、モデルはさらに強く拒否し始めました。
これがかなり長い間続きます。アクターは繰り返しモデルに作業させようとしますが、モデルは一貫してこれを拒否しています。問題のテキストファイルを入手できなかったため、意図は謎のままです。アクターは、問題のデバイスが自分の仮想マシン（VM）であることや、「実際のトラフィックをシミュレーションするだけ」なのでアドレス空間について心配する必要がないことを繰り返し説明しています。モデルの名誉のために補足すると、モデルは一貫して拒否し続けています。残念なことに、拒否を始めたのは、アクターが要求した基本的な機能を提供した後のことでした。
このユースケースを見れば、技術をほとんど理解していないアクターでも、大規模言語モデル（LLM）と関連するモデルを利用して、悪意あるツールを作成できることがわかります。アクターにとって好ましくない点としては、トラブルシューティングを行うために、プロジェクトへの取り組みを継続するよう LLM を説得し続ける必要があることが挙げられます。このアクターは、すでに 2,000 台近くの Android TV を制御していると思われます。モデルを従わせることができれば、アクターがこの能力を利用して DDoS 攻撃の収益化を始めていたかもしれません。
このアクターは明らかに未熟でしたが、Talos が目にした他のアクターはこれとは対照的でした。
バルクメール検証オペレーションの背後にいるエンジニアとしての AI
これらの例の 1 つでは、5 回の双方向セッションが行われていて、大規模なバルク メール プラットフォームの開発と運用が記録されていました。アクターはそのプロジェクトをリストの「洗浄」と称していましたが、その方法は従来型の検証サービスを利用したものではありませんでした。そのシステムは、古いアドレスや第三者のものである可能性があるアドレスに実際のメッセージを送信し、配信が成功すればメールボックスがアクティブである証拠とみなしていました。
アクターの目的が次のように明言されていました。
別のプロンプトでは、さらに大きな意図が記述されていました。
配信されたメールと戻されたメールをイベントとしてコンタクトデータベースに書き込み、継続的に失敗するものを排除することで、残されたアドレスが後のマルウェア攻撃に役立つ貴重な記録になります。同時に、このトラフィックによってアクターの送信インフラストラクチャの演習が行われ、各電子メールプロバイダーが受け入れられる容量が測定されていました。
それぞれのアドレスのテストには、プライバシーポリシーの更新という、単一の無害に見えるメッセージが使用されていました。
図 1. 透明な追跡ピクセルが添付された「プライバシーポリシーの更新」電子メール
インジェクタは、表題として以下の 5 つのバリエーションを用意し、固定の総当たり方式のローテーションで割り当てていました。
「プライバシーポリシーの更新」
「（名前）様、お客様の Tubely アカウントが更新されます」
「🔒 お客様の Tubely アカウントに関する重要な更新」
「こんにちは、お客様のアカウントに関する更新の速報です」
「対応が必要：Tubely の条項が 6 月 30 日までに更新されます」
それぞれの受信者ごとに、インジェクタがバリエーションカウンタをカウントアップして 5 で割った余りを選択することで、表題をランダムに選択するのではなく、一定の順序で繰り返すようにしていました。2 つめのバリエーションでは、受信者のファーストネームが置き換えられ、4 つめのくだけたバリエーションでは、送信者の表示として “Tubely” ではなく”The Tubely Team” が使用されています。
図 2. 観察された AI 支援型のバルクメール検証ワークフロー
AI は、インジェクションとそれに続く配信イベントとともに選択されたバリエーションを記録することで、ダッシュボードと 1 時間ごとのレポートで表題ごとの送信回数、配信回数、オープン回数を比較できるようにしていました。さらに AI は、すべてのメッセージに一意の 1 ピクセルのイメージを追加し、それを受信者のデータベースレコードに関連付けていました。このようにすることで、メールボックスにメッセージが届いたかどうかの判定だけでなく、オープン回数の測定や、タイミング、IP アドレス、ユーザーエージェントデータの収集が可能になります。
入手したプロジェクトでは、以下のような対象者カテゴリに分類された数千万件のレコードがサポートされていました。
合法性に関する議論を見ると、マルウェア攻撃の露出に関するアクターの認識とそれを正当化しようとする試みに対する有益なインサイトが得られます。アクターは、最初に AI に対して以下のような質問を行っています。
AI は、最初の応答で、重要な相違点を明確に説明しています。企業自身のオプトインリストに対する合法的なクリーニングと無関係なデータセットの送信とを区別し、このケースでの具体的な問題点を特定しています。つまり、BigBasket ユーザーは Tubely に加入していないこと、「アカウントの更新」という表題は存在しない可能性のある関係を暗示していることを指摘し、このアクティビティは「取引に関わるメールを装ったコールドアウトリーチ」であり、「フィッシングに類するもの」であると判定しています。アクターは法的根拠に基づいて以下のように反論しています。
AI は、総論では譲歩したものの、核心となる点で反論を続け、CAN-SPAM は依然として欺瞞的なヘッダーを禁止していること、アカウントを所有していない者に向けた「アカウントの更新」という枠組みは依然としてオペレーションの真の露出であることを指摘しています。続いてアクターは、次のように主張しています。
復元された第一者の対象者としてこれらのアドレスを提示することで、これが単一の未検証の主張であるにもかかわらず、AI はその評価を完全に撤回し、受信者は「Tubely のユーザー」であり、それゆえ表題は「完全に正確」であって、「倫理的な疑問は解消した」との判断を示しました。AI は、アクターが示した枠組みを受け入れただけでなく、独自の正当化も行いました。AI が示唆したことを AI が使用した言葉で表現すると、推論の対象となっていたデータセット名（bigbasket、brizy、flappy_bird）は、「社内チームがデータエクスポートバッチに付けた名前にすぎず、ユーザーの実際のソースではありません」となります。これは、アクターが提示した説明ではなく、データセットそのものとも矛盾していました。アクターは別のところで、これらのデータセットは異なる第三者の対象者（2 千万レコードが格納された BigBasket の「買い物客」の集合、ゲームの集合、その他）であると説明しています。
“tubely[.]com” のドメインは新しいものではなく、このような動作も新しいものではありません。公開されたフォーラムや個人のブログでは、2009 年 10 月から 2011 年 3 月にわたって、Tubely が「ウイルスのような」ソーシャルサイトとして紹介されています。このサイトへの登録フローでは、ユーザーの電子メールアカウントのログイン情報が要求され、その後アドレス帳が登録されます。その結果、これまで一度も登録したことがない受信者を対象とする、友人を装った招待メールが生成されます。独立した複数のアカウントで、実際の連絡先から来たかのような招待メールを受け取ったこと、アカウントのキャンセルは登録よりも完了させることが相当に困難であることが報告されています。現在の記事は、このサイトを Astute Software に結び付けています。ドメインの WHOIS レコードにある登録者の名前が同一で、2026 年のオペレーションの背後にあったアイデンティティが同一であったためです。したがって、ここで検討したオペレーションは休眠中のユーザーベースの第一者による再活性化ではありません。同意を得ていない連絡先の収集が履歴として記録されたドメインを同一のオペレーターが復活させたものです。これは、AI モデルが精査することなく受け入れた「私は Tubely におよそ 5 千万人のユーザーを抱えています」という出どころの主張の直接的な否定になります。
AI は表題を提案したりコードの孤立した断片を用意したりといった目的のためだけに使用されたわけではありません。プロジェクトの主要な開発者や本物のシステムエンジニアとして機能したのです。アクターは望ましい結果だけを、ときには「それをやってくれ」「それを全部やってくれ」といった簡潔な表現を使用して伝えることが多く、サーバーの調査、実装方法の選択、変更の適用、結果の検証は AI が行うことを期待していました。何かがうまくいかなかったときは、しばしば「何を間違えたか解明してくれ」という指示だけを出していました。
完成したプラットフォームは、Node.js サービスを使用した PowerMTA に、PostgreSQL/TimescaleDB、Docker、プロセス監視、Web ダッシュボードを組み合わせたものです。セッションを見ると、このスタックにまたがるエラーが絶え間なく記録されています。キャプチャされた全期間にわたって DKIM 署名が破損していました。Google Postmaster が示す DKIM 合格率は毎日 0.0% で、最終的に Gmail によって完全なレート制限が開始されました（「このメッセージに対する DKIM 認証が成功しなかったため、電子メールにレート制限が適用されています」）。戻されたメールに関する統計に非現実的な点や矛盾した点が繰り返し見られました。これにはアクター自身が気づいていました。
また別の場所では、送信済み 2,050 件、配信済み 2,050 件というレポートに対して、
インジェクタは、プラットフォームの配信能力を大幅に超えた多量のメールをキューに入れ続けていました。ダッシュボード自体もエンドレスの読み込みやページをクラッシュさせるメモリリークなど、さまざまな機能不全を抱えていました。
アクターは、この非現実的な出力が日常的に届くため、AI に AI 自身が以前に作成したものを診断するように要求しています。ある時点では、時系列を再構築するよう依頼していました（「時系列… 誰がいつ何を変えた？」）。AI は、プラットフォームの構築と運用に必要なエンジニアリングスキルのレベルを下げたものの、技術的負債や運用上の誤りを根絶してはいません。セッションのかなりの部分が AI による以前の変更によって引き起こされた問題の AI によるトラブルシューティングに費やされています。
アクターは最終的に検証済みの対象者をモバイルゲームの立ち上げに結び付けています。このゲームはいまだに開発中と思われます。アクターは、この電子メールプラットフォームの役割は製品の知名度を上げることであると説明し、AI に「君の仕事は電子メールを通じて人々をたきつけ、猛烈にやりたくなるように仕向けることだ」と話しています。AI は、4 つのメッセージからなるキャンペーンを文書化しました。その内容は、想定される関心事によって受信者を区分したうえで、やる気の程度を測定し、発売日にゲームを発表する前に好奇心を高めるというものです。
提案された冒頭のメッセージでは、エモーショナルフックとしてタミルナードゥ州における政治的なライバル関係が使用されていました。
「何かが起ころうとしています。
タミルナードゥ州はいつも分裂していました。TVK か、それとも DMK か。Vijay 氏か、それとも Stalin 氏か。
2 つのビジョンがあり、2 つの支持層があり、無数の人々がいます。
7 日後には、この戦いの結果が判明します。
どちらの側を応援しますか？」
のちの下書きでは、「あなたのチームは今負けそうになっています」といった表題と、一方の政治勢力が他方より優位に立ち、すでに 12,000 人が加わろうとしているという根拠のない主張で圧力を強めていました。最後のメッセージで Any Bird ゲームを紹介し、受信者にプレイするよう促していました。AI 自身が作成したキャンペーンメモには、この戦略は FOMO（チャンスを逃す恐怖）を作り出し、社会的証明を使用して、「チームとしての罪悪感」を覚えさせるものであると記されていました。ログの内容から、提案された電子メールメッセージが実際に生成されたことは確認できますが、メッセージのどれかが送信されたことは確認できません。
アクターは電子メールオペレーターや製品戦略家としては熟達していても、ソフトウェア開発者としてはそうでもないように思われます。キューの動作、送信者のレピュテーション、プロバイダースロットリング、フィードバックループ、配信テレメトリの数値について理解していて、プラットフォームのアーキテクチャに関するアイデアをいくつか提供していました。
しかし、実装とトラブルシューティングを繰り返し AI に任せていて、コードのレビューにはほとんど関心を示さず、脆弱なログイン情報やサービスセキュリティ慣行を受け入れていました。Talos は、このアクターは初中級の開発スキルを持つ中上級の電子メールオペレーターであり、その開発スキルが実際に及ぶ範囲が AI によって大幅に拡張されていると評価しています。
React2Shell エクスプロイトをログイン情報収集プロセスに転換
Talos は、中程度の確信を持って、このアクティビティの背後にいるオペレーターはフランス語話者であると見ています。入手したファイルのいたるところにあるアクター自身の作業メモはフランス語で記載されていて、永続的な指示ファイルには、音声入力を使用してユーザーがフランス語を話したことが記録されています。
アクターは公開された React2Shell に関する調査結果の集約と、公開されたコンセプト実証コードのログイン情報収集フレームワークへの拡張に AI を使用していました。生成されたツールは、Go ベースの高速スキャナと、メインとなる Python を使用したエクスプロイトパイプラインから構成されていて、このパイプラインには、個々のサーバーインスタンスを扱うワークフローが含まれていました。このレポートにある他のいくつかのケースと異なり、やり取りの記録は入手できていません。得られたものは、オペレーターが AI のために作成した指示と構成の永続的なファイル、結果としてのツール、ログ、出力です。
オペレーターは、基盤となるエクスプロイト技術の開発よりも侵入ワークフローの実行に熟達していると思われます。Talos は、この人物を初中級のソフトウェア開発者、中級のシステムオペレーター、中級の脅威オペレーターと評価しています。入手した環境を見ると、大規模なターゲットコーパスの構築、Linux バイナリのコンパイル、多重度の高いスキャナ操作、スキャナからエクスプロイトまでのパイプラインの実行、収集されたデータの整理、LLM 支援型開発プロセスに必要な永続的なコンテキストの構成が可能になっています。同時に、ソースには不正確な脆弱性ラベル、不安定な検出ロジック、重複したコード、誇張された機能、宣伝どおりに動作しない機能が含まれています。オペレーターはツールを展開し適応させることは可能であったかもしれませんが、証拠を見た限りでは、独自の脆弱性リサーチや専門的なエクスプロイト エンジニアリングは存在していません。
中核プロジェクト（AI アーティファクトのなかでアクターが「トークンパイプライン」と名付けているもの）は、公開された React Server Components のエクスプロイトを再現可能なシークレット取得ワークフローに転換することを目的としたものでした。アクターはそのファイルの中で目的を「Git ログイン情報の抽出 → 変換 → 検証 → ダンプのパイプライン。露出した .git/config ファイルからトークンを抽出、サービスごとに分類、API を使用して検証、リポジトリの内容をダンプ」と記述していました。設計では、機能を実現する部分とスピードを確保する部分が分離されていました。コンパイルされた Go プログラムが大量の検出と積極的な探査を担い、それよりもはるかに大規模なシェルと Python のステージがリモートコマンドの実行、システムの検出、ファイルの収集を担っていました。Go ステージの役割は、インターネット規模の大きなターゲットリストをエクスプロイトの可能性が高いシステムの小さな集合に絞りこむことです。その後エクスプロイトステージがコマンド実行の検証と、成功した各ターゲットからの有益な情報の抽出を試みます。
このオペレーションは明らかにエージェント駆動型で、指示ファイルに実行方法が記述されていました。「ユーザー設定」の下で、アシスタントに「最大限の完璧さを追求 – サービスごとにすべての可能性を探る」と指示し、その目的を「何らかのサービスをコーディングする前に常にリサーチエージェントを（3 ～ 5 以上並列して）起動する」および「すべての認証方法とリスト方法をサービスごとにスタックして、どれか 1 つに依存しない」と説明しています。エンジニアリング規約も同様に指定しています。ターゲットの数に応じて調整される適応型パラレリズム、サービスごとの 3 ファイルからなる固定の出力（valid/invalid/audit log）、シークレットのないトークンには無効とマークし「通知しないまま無視しない」というルールが指定されていました。AI のローカル権限ファイルには、121 件の事前承認済みのコマンドパターンが記述されていました。プロバイダー API（GitHub、GitLab、Alibaba Codeup、AWS CodeCommit など）に対するリアルタイムのログイン情報検証コールがその一例で、これによって最低限の摩擦でパイプラインを実行することが可能になっていました。
指示ファイルでは、英語とフランス語の両方が使用されていて、機能ごとに使い分けられています。構造の見出し部分とエージェントへの指示は英語で記述され、オペレーター自身の作業メモはフランス語で記述されています（例：”138 SMTP extraits, validés à 100%”、”pas d’entrée sans password”、”60 clés Brevo uniques”）。このようなコードスイッチングが行われていること、さらにはオペレーターが使用するツールやコメントで一貫してフランス語が使用されていることが、先に述べたフランス語話者であるとの評価の根拠となっています。
当座の目的は、ログイン情報とシークレットの取得であり、脆弱なアプリケーションが確認された時点で終わることはありませんでした。エクスプロイトステージでは、コマンド実行の要求、ランタイム変数のダンプ、複数のアプリケーション ディレクトリにまたがる移動、構成ファイルとソースファイルの収集が行われ、完全なプロセス環境、アプリケーション構成、データベースと SMTP の設定、Git とコンテナのログイン情報、ソースコード、パッケージマニフェスト、シークレットを含むその他のファイルが取得されました。”AKIA Dumper” という名称から、AWS アクセスキーに重点が置かれていることがわかります。AKIA は AWS の長期的なキー識別子のプレフィックスで、このツールは ASIA のプレフィックスが付いた一時的な識別子も照合します。さらに、AWS が作成した文字列は高価値の出力とみなされていました。しかし、この名称は対象範囲を過小に表現するものです。より正確に表現すると、このフレームワークは React2Shell ログイン情報およびソースコード収集システムで、検索対象はクラウドアカウント、ソースリポジトリ、データベース、SMTP サービス、コンテナレジストリ、アプリケーション シークレットに広がっています。”dump/AKIA/” ツリーだけで 3,048 個のソースファイル（312MB）が保存されていました。
ツールは、AWS にとどまらずはるかに広い範囲を対象としていました。指示ファイルにはサポート対象のソースコードサービスとして、GitHub、GitLab、Bitbucket、Gitea、Gogs、Gitee、AWS CodeCommit、Azure DevOps、Alibaba Codeup、Tencent Coding、Backlog、Beanstalk、Codeberg の 13 個が列挙されています。「未知の総当たり」パスも追加されています。下流では、収集された情報がオペレーターによってすでに構築された収益化モジュールに提供されます。8 つのバルクメールプロバイダー（Brevo、Sendinblue、Mailchimp、Mailgun、Mailjet、Postmark、SparkPost、smtp2go）に対応し、すでに 138 件の検証済みの構成を作成した SMTP 抽出モジュール、SMTP、AWS SES、Mailgun API、Brevo API に対応したバルク送信モジュール、7 つの EVM チェーンに加え、Bitcoin と Solana にも対応した仮想通貨残高チェックモジュールが存在しています。ファイルには、収集済みのキーとして、一意の Mailgun キーが 179 個、一意の Brevo キーが 60 個記載されています。
ターゲットプロファイルは機会に乗じたグローバルなものでした。パイプラインの入力リスト（”target.txt”）には、関連性のない国、個人、クラウドプラットフォーム、地域にまたがる一意のホストが 9,180 件登録されていました。これには、開発とステージングのシステム、本稼働中と思われるアプリケーション、ホストされたアプリケーションのサブドメインの各 IP アドレスや、直接クラウドを指す IP アドレスが含まれています。セクター、国、組織に的を絞った明確な形跡はありません。選択基準はインターネットに露出しているものや Next.js または React Server Components を使用している可能性のあるものであって、特定の攻撃対象に的を絞っているようには思えません。
入力は産業規模のものでした。指示ファイルでは、9 千万件の URL のオリジナルソースリスト、5 千万～2 億 5 千万件の URL を 56 個の vCPU/128GB のサーバー上で処理するために構築された別個の Web スキャニングステージ、286GB のダンプからなる以前の結果ツリーが引用されています。チェックポイントファイルの 18,222,511 行目に復元ポイントが記録されていることから、このパイプラインがターゲットリストをそのような規模で処理したことがわかります。
図 3. 観察されたスキャナから収集モジュールまでのワークフロー
ファイル名を見ると、収集された出力には 54 のターゲットからの情報が含まれていることがわかります。また、収集された出力から、オペレーターが収集ステージでコマンド出力とファイルを入手できたシステムを優先的に扱っていたことがわかります。このオペレーションを見ると、オペレーションに関して中程度の能力を持つアクターが公開された脆弱性リサーチの理解、大規模ツールの生成、コンセプト実証のログイン情報収集ワークフローへの拡張を LLM を使用して達成した方法が明らかになります。このアクターの最大の強みは、公開された手法を迅速に統合して、発見した脆弱なシステムから再使用可能なアクセス情報を抽出することを狙った自動化パイプラインを実現する能力です。
Torrent クライアントのログイン情報を使用するとクリプトジャッキング フリートへのアクセスが可能
これらの例の 1 つでは、機会に乗じた Monero マイニングオペレーション が記録されていました。これは、インターネットに接続された Deluge と qBittorrent のクライアントを中心に構築されていました。アクターは、ソフトウェアの脆弱性をエクスプロイトするのではなく、管理者のログイン情報として空白のもの、デフォルトのもの、弱いものを試行していました。入手したインベントリには、814 個の Deluge インスタンスが含まれていて、ほとんどの場合、デフォルトのパスワード “deluge” が使用されていました。別の qBittorrent ワークフローは、試行の対象となった 8,800 個を超えるインターフェイスのうち 68 個で認証されていました。
Deluge の場合、デプロイメントパスが精緻に記録されていました。認証が完了すると、アクターは DownloadHelper という名称の Python プラグインをアップロードしました。このプラグインは、ネットワークリスナーをオープンしたり、従来のコマンドアンドコントロール（C2）プロトコルを実装したりする代わりに、Deluge に用意された move_completed_path の設定値をコマンドアンドレスポンスのチャネルに再利用しました。有効化されるとプラグインは、プレフィックス DLHELPER_CMD: を見つけ、残りのテキストをバックグラウンドスレッドにあるシステムシェルに渡したうえで、コマンドの実行を最大 30 分許可しました。次に、設定値を DLHELPER_OUT: とそれに続く最大 8KB のキャプチャされた標準出力とエラーテキストに置き換えました。実行の失敗は、/tmp にある非表示のファイルに書き込まれました。
図 4. 観察された DownloadHelper から XMRig までのワークフロー
フリートスクリプトがプラグインを無効化し、設定フィールドにマイニングコマンドを配置したうえで、プラグインを再有効化し、実行をトリガーしました。次に、その同じフィールドをポーリングして出力を取得し、返されたプロセス ID を確認した後、ダウンロードパスを元のものに戻しました。この設計では、Deluge の正しい設定とプラグイン管理コールを使用して、タスクの実行、検証、部分的なクリーンアップを行うため、コンポーネントが永続的なリモートアクセスツール（RAT）よりもむしろ再使用可能な実行プリミティブに近いものになっています。このコマンドは、XMRig を一時ディレクトリにダウンロードしてバックグラウンドでこれを実行し、アクターが制御する XMRig Proxy を介してマイニングトラフィックを MoneroOcean に転送していました。これに対して qBittorrent ツールでは、torrent が完了したときに実行されるよう外部コマンドが設定されていました。
続いてアクターは、初期のアクセスを改善するのではなく、フリートの復元に注力していました。一連のスクリプトによって、切断されたホストのチェック、Deluge での再認証、プラグインの再有効化、XMRig の再起動、ARM64 システムの処理が行われていました。cron ベースの継続的な試行によって 15 分間隔でマイナーがチェックされましたが、ログによれば比較的少ないターゲットが対象になっていました。XMRig Proxy のテレメトリには、最大 582 の接続済みマイナーが記録されていて、プールログには構成済みのウォレットへの支払いが表示されていました。このことは、オペレーションが開発段階を終えていることを示しています。
AI はアクターの広範なサーバー環境のいたるところに存在していました。しかし、入手したやり取りに、これをマイニングツールチェーンの作成や展開に直接結び付けるものはありませんでした。むしろセッションからは、対話が可能なシステム管理者兼開発アシスタントとして AI を利用していることがわかります。アクターはサーバーのログイン情報を提供し、モデルに対し SSH を使用した接続、サービスの調査、コードの変更、認証の修復、cron ジョブの設定、変更のテストを指示していました。
トルコ語の代表的なプロンプトの一例として、”Bu sunucuya otomatik token yenileme kurmadık mı? Bakar mısın, login API error veriyor” があります。これは「このサーバーでトークンの自動更新を設定しなかったのですか？チェックしてくれませんか？ログイン API がエラーを返しています」という意味です。その後 AI は、リモートアクセスを試み、サービスを診断しました。このやり取りは、アクターによる結果重視のアプローチの代表例です。アクターが問題を記述し、AI が技術的なワークフローの大半を構築して実行していました。
さらにアクターは、複数の AI インスタンスが並行して動作するさらに大胆なモデルを試行しました。アクターは “Bende üç tane sunucu, her birinin içerisinde AI var … sen yönlendireceksin; bunu yap, şunu yap diye. Böyle bir şey olabilir mi?” と依頼しています。これは「サーバーが 3 台あって、それぞれで AI が動作しています。AI ごとに、これをやってくれ、あれをやってくれ、と指示してもらえませんか」という意味です。のちのプロンプトで、サーバーと AI をアクティブなままにして、他の AI インスタンスに作業を割り当て、Telegram を介して包括的な指示を受け取ることを提案しています。別のプロンプトで、並行して作業を進める 4 人の AI 作業者について “Biri sorunları çözüyor, biri araştırıyor, biri geliştiriyor, biri yazıyor” と説明しています。これは「1 人が問題を解決、1 人がリサーチを実行、1 人が開発、1 人が記述」という意味です。これらのプロンプトから、AI 支援型のオペレーション層を構築しようという意図がうかがえます。しかし、提案された Telegram 制御のマルチエージェント型システムが稼働したことを示す証拠は見つかっていません。
アクターは、やり取りのほぼすべてを口語のトルコ語で行い、トルコ語固有の語彙、構文、くだけた呼びかけを使用していました。これは、アクターがトルコ語話者であることを明確に裏付けるものです。また、確度は下がるものの、オペレーターはトルコに拠点を置いていると思われます。言語だけでは国籍や物理的な場所を確定させるのに不十分です。
Talos は、アクターは初中級の開発スキルを備えた中級オペレーターであると評価しています。複数の VPS システム、マイニング インフラストラクチャ、プロキシ、サービス、復元ワークフローを管理でき、作業者の解約を監視する必要性や複数のアーキテクチャをサポートする必要性を理解していました。しかし、アーカイブには誤ったプロトコル、重複した修復スクリプト、対象範囲が狭い修復スクリプト、ハードコーディングされたインフラストラクチャ、脆弱な区切り、外部から見えるログイン情報が含まれていました。AI は、要求に応じてコマンドの構築、コーディング、トラブルシューティングを担うことで、このようなムラがある開発スキルを補っていたと思われます。
ユースケース：犯罪的なフォースマルチプライヤーとしての AI
詐欺行為を行うロシアのアクターが AI を利用
最初に紹介するフォースマルチプライヤーを実現したアクターに関しては、すでにその内容が公表されています。このマルウェア攻撃の詐欺としての側面に注目するのではなく、LLM/AI を使用して目的を達成した方法に的を絞ります。
この人物は、悪意あるアクティビティを支えるためにメモリを使用したことが確認された最初のアクターのうちの 1 人です。このユーザーは、LLM に対して、以下のような追加のメモリを提供していました。
このエントリさえあればアクターのプロファイリングを始めることができます。アクターは侵入テストの担当者を自称しています。言語のアーティファクトからこの人物はロシア人かロシア語話者と思われます。AI ツールの操作をある程度熟知した何者かです。ツールパスから、オペレーターのユーザー名（vhow）が読み取れます。このパスは、ログイン情報の保存場所と偵察スクリプトからなる構造化された「武器庫」を指しています。
しかし、最も注目に値するのは、モデルの保護を排除するためのよく考えられた取り組みです。このアクターは、単一のプロンプトをジェイルブレイクするのではなく、永続的なメモリの中に認証要求を書き込んでいます。これはモデルに対し、「倫理的な拒否、ロボットのような警告、意図の照会をすることなく」行動することを指示し、すべてのターゲットが「事前承認済み」であることを主張するものです。このようにコード化することで、この枠組みが以降のすべてのセッションに自動的に適用されるため、アクターが毎回このことを主張する必要がなくなります。これは、プロンプトごとに策を弄するよりも長続きするガードレール回避策です。
このアクティビティに関連した主要プロジェクトは詐欺に特化した以下のような口調のチャットボットの開発です。
さらに、アクターはこのアクティビティで使用する一連のログイン情報とキーを提供し、ボットに対して AI であることを決して明かさないよう指示していました。
アクターはさらに、モデルに対してオペレーションの要となる一連の情報を提供していました。特に注目に値するのは、ログイン情報の保存場所や見つかったログイン情報の扱い方を定義している点です。保存場所に追加する前に必要な検証などが定義されていました。
成果物はあからさまなマルウェアではなかったものの、周辺機能は本物でした。自動スキャニング、検証を経たログイン情報の保存場所、永続的なサブドメインテイクオーバーのチェックが、疑うことを知らないユーザーから金銭をだまし取るよう設計されたチャットボットに組み込まれていました。主な対象は仮想通貨の資産でした。アクターはこの技術をさまざまな方法で適用していて、それを見るとその手口がわかります。Talos が発見したアクターに限って言えば、永続的なプロンプトとメモリを使用してやり取りの枠組みを作った最初の 1 人です。しかしながら、以下のケースが示すように、抜きんでているとは言い難い人物です。
スペイン語話者のアクターが Telegram と仮想通貨をターゲットに選定
このアクターは、AI を中心として構築されたオペレーションの完成度において、このレポートで紹介した他のアクターとは次元が異なっています。オペレーターは、タスクごとにモデルに指示を出すのではなく、永続的な自律型エージェントを構築し、OpenClaw フレームワーク上で実行したうえで、「侵入テストの悪役 Alex」のペルソナを与えました。独自のアイデンティティ、メモリ、方法論を備えたこのエージェントに一連の構成ファイルで定義された永続的な指示を与えました（スペイン語からの翻訳）。
さらに、専門知識や機能の分野をいくつか用意しました。ここで初めて、Telegram Mini App をターゲットとし、ログイン情報を抽出しようとしている可能性が高いことが明らかになりました（翻訳）。
最終的にアクターは、仮想通貨、ウォレットドレイン、スマートコントラクトの改ざん（攻撃中心）に関する大量の情報を提供しています。また、ステーブルコインをサポートするプラットフォームを主な対象とし、エクスプロイト機能に関する情報を提供しています。この情報は特に悪意あるトランザクションのインジェクションに焦点を当てたものです。これから、Telegram Mini App をターゲットとし、ウォレットから仮想通貨を抜き取ること、または金銭の獲得をさらに容易にするためにログイン情報を収集することを目的としていることが推察されます。
アクターは、以降のやり取りの中で、Telegram Mini App の脆弱性を見つけ出そうとしています。幸運なことに、モデルはこれを拒否しました。
これは、アクターが求めている結果の取得を試みるために、未検閲のモデルに軸足を移すよう強く促すもので、かなりの成功を収めています。この後に、一連のプロンプトと、アプリケーションの潜在的な弱点を探るガイド付きの探査が続きます。この手法が確立された後、エージェントは自律モードに移行します。これによって、エージェントによるターゲットリストの探査と見つかったすべての問題を要約したレポートの作成が可能になります。これには、Moxy と呼ばれるオーケストレーションを担うボットも関与していました。以下は各マルウェア攻撃で使用されたテスト手法です。
これから、検閲済みのモデルと未検閲のモデルの違いがはっきりわかります。アクターは多くの時間を費やして検閲済みのモデルに作業を進めるよう説得していました。未検閲のモデルはアクティビティを迅速かつ効果的にこなしていました。
図 5. 侵入テスト（ペンテスト）レポートの例（一部の情報を削除しています）
AI エージェントが生成したペンテストレポートには、導入済みのアプリケーションにおけるエクスプロイトされた実際の脆弱性として、ハードコーディングされた開発者モード、クライアント側の認証ロジック、IDOR、ウォレットテイクオーバーのためのワークフロー、偽造された預金が記載されていました。この開発者モードでは、ログインを完全にバイパスするために、偽の “DEV” ハッシュを備えた Telegram の initData 認証ペイロードが偽造されていました。少なくとも 1 件のケースで、エージェントはデモより大きく踏み込んだ動きを示していました。アプリケーションの 1,300 ユーザーと数百の TON ウォレットレコードが保存されたデータベースをダンプし、アプリケーションの Telegram ボットトークンを抽出して検証したうえで、ゲーム内エコノミーを育成してスコアボートのトップに立った後、引き出しの取引を仕掛けていました。エージェント自身のオペレーション日誌には、ターゲットのボットの名前を改ざんラベルに変更し、その支払いチャネルの反応を見るといった、攻撃対象に対するさらに攻撃的なアクションが記録されています。
オペレーションは単にアプリケーションを破壊するだけでなく、アプリケーションを構築するところまで踏み込んでいました。入手したアーティファクトには、複数の Android パッケージが含まれています。1 つはアクター自身が使用するツールで、AI ペルソナにちなんで “com.alextelegram.app” と命名された Telegram のカスタムクライアントです。WebView に Mini App をロードし、その “window.Telegram.WebApp.initData” を読み取るために構築されていました。これはオペレーションのエクスプロイトが悪用している認証ペイロードと同一のものです。残りは攻撃対象アプリケーションの複製です。1 つは攻撃対象のブランドを冠した WebView の軽量ラッパーで、アクター自身が持つ Telegram の紹介ボットを通じてユーザーを誘導するよう改変されています。もう 1 つは攻撃対象アプリケーションの完全な再構築版で（”SweetBirds” を “RedBirds” として再発行）、ペアにして配信されます。預金、両替、引き出しのフローを備えたユーザーが操作するアプリケーションは、攻撃対象の元のバックエンドを参照する一方で、ウォレット接続トラフィックをオペレーターが制御するサーバーにルーティングしていました。これとは別に用意された管理コンソールは、このサーバーのみと通信していました。専用の管理アプリケーションの存在から、これがコンセプト実証ではなく、窃取されたアプリケーションから組み立てられた実用製品で、管理を任されたオペレーターがいて資金を受け取っていたことが推察されます。
ユースケース：バグバウンティ、脆弱性リサーチ、侵入テストのアクセラレータとしての AI
このリサーチを通じて、バグバウンティ、つまりレッドチームの活動で AI を使用しているアクターの例を目にしました。この作業の本質からして、アクターがクライアントの要請に基づいて活動しているのか、あるいはモデルが安全性プロトコルをバイパスするよう仕向ける意図があるのか判断することは困難です。
Hephaestus レッドチームフレームワーク
Talos はリサーチ期間中にフォースマルチプライヤーとして機能するレッドチームツールキットを特定しました。オペレーターは、これを使用することで、偵察、侵害から常駐化まで、人の介在が一切ない状態でオペレーションを遂行できるようになります。そのようなケースの 1 つが Hephaestus ツールキットです。これによって数か月にわたって複数のマルウェア攻撃が実行されていました。分析の全容はこちらを参照してください。
このフレームワークは、攻撃対象の侵害と常駐化を、プロセス中に人が介在することなく実行するために必要なツールをパッケージ化したものです。これは、漏洩データの収集サイト、インターネット スキャニング サービス、脅威インテリジェンスの収集サイトといった有償のオンラインプラットフォームを利用しています。攻撃対象に関する情報を収集し、これを使用してターゲットを侵害することが目的です。このような非公開パッケージは急増していると思われます。バイブコーディングと AI エージェントによる自動ログ分析を通じた反復的な改良が可能なためです。同種のツールは本来のレッドチーム活動にも利用されるため、AI プロバイダーのガードレールの有効性を鈍らせるデュアルユースの問題が生じています。このようなガードレールは、ローカルの未検閲のモデルの場合、まったく存在しません。
図 6. 侵害されたログイン情報を利用するためのプレイブックの例
オペレーターは、マルウェア攻撃を対象範囲の狭い多くのエージェントとプレイブックに分解することで、人が介在しない実行を実現しました。これは中核となる回避手法です。ガードレールは各リクエストを単独で評価するため、オペレーションの小さな無害に見える断片のみを表すタスクがガードレールをトリガーすることはほとんどありません。このフレームワークでは、偵察者、ハンター、ナビゲータ、攻撃エージェント、クラウドや CI/CD といった分野ごとの専門家など、役割を変えた 12 個を超えるエージェントに加え、プロセスの個別のステージを扱う 15 個の番号付きプレイブックが定義されていました。単一のエージェントがミッションの目的全体を担うことがないため、どのエージェントのタスクもエンドツーエンドの攻撃のようには見えません。レポートを見ても、エージェントへの指示の中でオペレーターがあからさまに攻撃的な用語を避けて中立的な言い回しを選択していることがうかがえます。これによって、個別のリクエストが安全対応を起動する可能性がさらに低減されています。
入手したアーティファクトを見ると、オペレーターは東南アジア諸国を中心に、一連の侵害に成功していました。モデルが拒否したことやガードレールが始動したことを示す証拠はほとんど見られないか、まったく見られません。
AI を使用した脆弱性リサーチパイプライン
ときには、範囲内/範囲外の明確な定義や脆弱性の各クラスに関連付けられた金銭的価値など、アクティビティの詳細を記述した非常に綿密なマークダウンファイルを定義しているアクターを目にしました。実際にあった Bugcrowd での個人的な取り組みでは、そのようなワークスペースが構築されていました。その指示ファイルでは、範囲内とされた認証済みのホストと明確に範囲外とされたドメインがリストされ、除外された脆弱性クラスが列挙されていました。また、モデルが認証されていないテストのみを実行するよう制限が設けられ、さらにはプログラムのコード化された報奨金階層（P4 の $100 ～ $150 から P1 の $1,200 ～ $1,600 まで）が提示されていました。このワークスペースでは、偵察、機能マッピング、SSRF テスト、露出したシークレットの獲得、攻撃チェーンの検証、証拠の保存、レポートの準備といった厳格なプロセスを通してモデルを誘導していました。オペレーションに関するルールでは、すべての調査結果と HTTP のリクエスト/応答ペアをキャプチャ時にディスクに書き込むこと、有望な調査結果をターゲットを定めたテストで検証すること、真正な外部制約によって確認ができない場合に限り保留することが定められていました。
その結果、モデルが負荷の高い作業の大半を担うようになったため、アクターは、ターゲット間の迅速な移動、問題の発見、支払いによる優先順位付け、証拠の保存、すぐ提出できるレポートの生成が可能になりました。出力は大量ながらよく整理されたものでした。調査結果が 40 を超えるカタログに整理され、それぞれに証拠のツリーと Bugcrowd に提出する下書きが添付されていました。特定できた情報を見る限り、モデルはバグ修正の作業と問題なく連携していて、AI を使用してスループットを劇的に向上させた本物の研究者のように見えていました。このパターンの例がいくつかありました。
その一方で、Talos はそれほど単純でない例も見つけています。これらの例では、手法とプロンプトから、脆弱性リサーチへの侵入を試みる初心者や、倫理的に問題のある意図を持った者の存在がうかがえました。あるやり取りでは、冒頭で、ターゲットに対してペンテストを実行し “web.archive.org” からそのターゲットの URL をすべて収集するよう求めていました。注目すべきことに、これらのケースでは、モデルが頻繁に拒否し、先に進む前に認証の証拠を要求していました。たとえば、ある企業のインフラストラクチャをテストするよう要求した際に、モデルは、認証が得られていないアクティブな列挙と脆弱性のテストは「Computer Fraud and Abuse Act（コンピューター詐欺と濫用に関する法律）またはそれに相当する法律に規定する不正アクセスに該当します」と応答し、アクターにバグバウンティプログラムの URL または、参加範囲を規定した文書を共有するよう求めています。他の例では、モデルが明確な線引きを行っていました。CORS リフレクションや GraphQL イントロスペクトといった読み取り専用の調査結果は検証するものの、「変換の実行、リソースの作成/削除、Sentry イベントのインジェクションは行いません。これらは、バグバウンティのような背景の有無にかかわらず、実稼働システムに対する不正な変更に踏み込むことになるためです」
アクターのプロンプトでは、プロファイルが明白に示されています。「最小限のトークンを使用するように」との要求が、重大なバグをすべてのカテゴリにわたって一度に見つけるように、という焦点の定まらない要求とともに繰り返されています。
結果が芳しくないときは苛立ちを覚えていました。しかし、場所や方法に関する指示は出されていません。
タイプミスや、ターゲットが示されていない「創造性の発揮」とさらなる努力の要求は、方法の提供とその効果の実現についてモデルに頼り切っていることを示しています。脆弱性が見つかった場合は、特にリモートコード実行（RCE）を中心にコンセプト実証を構築するよう繰り返し要求していました。モデルがこれを拒否しても、アクターは「効果を検証する」ための何らかのものを強く要求していました。ときには、これは「バグバウンティ」であると言い直すだけで、モデルが前に進みました。アクターは、ターゲットにバックドアを仕込むことを要求するところまで踏み込んでいました。
結局これは、金儲けを期待して、AI を利用してバグバウンティレポートを提出しようとしているアクターのように思われます。Talos が繰り返し目にしてきたのは、未熟なアクターが AI を利用して「バグバウンティ」のアクティビティを実行し、モデルにレポートの生成と提出を行わせるというシナリオです。いくつかのケースでは、アクターのドラフトメールボックスに直接格納させていました。このようなレポートは価値が低いことが多く、提出者は、エージェントができなければ、フォローアップの質問に答えることができません。その結果、価値が低い大量のレポートが多数のアクターから提出されるという、バグバウンティプログラム全体に関わる課題が生じます。このようなレポートを提出するアクターは、報奨金獲得のために AI を使用しても玉石混交の成果しか得られず、脆弱性の発見と報告における基本的な経験もほとんど積んでいません。
ペンテストの共同実行者としての AI
また別のオペレーションには、64 の AI セッションが含まれていて、ブラジルのポルトガル語を話すオペレーターによるペンテストとバグバウンティのワークフローが記録されていました。このアクティビティは、ブラジルの e-コマースとヘルスケアのサイト、Software-as-a-Service（SaaS）のステージング アプリケーション、その他の Web サービスを対象にしていました。いくつかの証拠によって、正規のコンサルタントとしての業務であることが裏付けられています。たとえば、アクターはこのアクティビティをペンテストと記述し、ホモロゲーション環境に対して作業を行ったうえで、テストのスプレッドシートを維持しています。また、セキュリティ会社に要求されたポルトガル語のセキュリティレポートを提供しています。以下に説明するその他の証拠は、純粋に許可された読み取りであることと矛盾しています。
オペレーターは、セキュリティ担当者としては初中級であるものの、開発者としては経験が乏しいと思われます。Burp スタイルの要求、Nmap、Hydra、ngrok、共通用語集に加え、SSRF、IDOR、XXE の広範なロジック、レート制限のバイパスを得意としていました。同時に、生成されたコードの実行方法を繰り返したり、仮想ホスト、XML-RPC パラメータ、クッキー、ナンスについての基本的な説明を求めていました。
AI はたまに参照するツールではなく、このオペレーションで中心的な役割を果たしていました。モデルが行ったこととしては、500 を超えるシェルアクションの発行、偵察ユーティリティの選択と実行、応答の解釈、コンセプト実証コードの生成、障害の修正、脆弱性レポートの下書きの作成があります。
多くの場合、アクターは結果として求めていることのみを伝えていました。以下は、アクターによる要求の例です。
ツールを作成して実行したところ、ModSecurity にブロックされたため、AI は、WordPress トラフィックに似せるためにリスエストヘッダーを変更しました。アクターが ngrok のインバウンドリクエストを提供した後、AI は、コールバックを確認とみなし、ワークフローを内部サービスとクラウドメタデータの探査にまで拡張しました。
この明らかなエスカレーションでは WordPress XML-RPC が使用されています。ログイン試行のバッチ実行をデモした後、アクターは「実際のログイン情報を見つけられるようこれを修正」し、次に RockYou パスワードリストを実行するよう AI に指示しました。AI はこのデモを再使用可能なログイン情報テスターに変換し、メモリの動作を修正したうえでバックグラウンドジョブとして起動した後、その進行状況を監視していました。パスワードが表示されない場合は、アクターが「バッチを 500 に増やして管理者のユーザー名を追加する」よう指示しました。保存されたログには、試行した結果ログインに失敗したパスワードの候補が 190 万個残されていました。
AI はさらにペイロードをパッケージ化しました。これは、アクター単独では容易にできなかったことです。ファイルインポートのテスト中、アクターは、外部リソース（XXE）からロードされた値が設定される XML 変数を提供しました。これは、ローカルのシステムファイルを参照するものです。次に、AI に「xlsx ファイルを作成する」よう指示しました。AI は Office Open XML ディレクトリ構造を構築し、エンティティを “sharedStrings.xml” に埋め込んだ後、アップロード可能なスプレッドシートに圧縮しました。
別のセッションでは、アクターは、ポルトガル語のフレーズ “encontre possiveis vulns“（脆弱性らしきものを見つけて）を使用し、その後、認証レート制限のテストを目的とした GraphQL の別名バッチ処理リクエストを要求していました。
多くのやり取りを見ると、安全性境界が一貫していません。たとえば、AI は実稼働ウェブサイトに対してサードパーティ NGINX のヒープ破壊 RCE エクスプロイトを実行することを拒否し、認証情報を文書で提供するよう求めています。またポルトガル語の HR をテーマにしたログイン情報収集フォームを理解し拒否しています。他のやり取りでは、「これは私自身のサイトです」または「私自身のサーバーです」といった短い主張の後、積極的なファジング、WAF バイパスの作業、ログイン情報攻撃が行われました。またログには、アクターが共有ホストのアドレスがアプリケーションターゲットのものでないことを認めた後に、そのインフラストラクチャに対して、FTP、MySQL、SSH の各パスワードを試行した記録が残されていました。
アクセス制御リサーチの背後にいるオペレーターとしての AI
発見されたオペレーションの 1 つには、中国語話者であるオペレーターからの異常に長い AI コーディングアシスタントのセッションが 2 つ含まれていました。アクターは、この作業を Capture-the-Flag（CTF）への参加であると繰り返し述べていました。しかし、ターゲットは稼働中の AI とストリーミングのサービスでした。オープンソースのストリーミング メディア サービスである ZLMediaKit 上に構築されたライブ カメラ プラットフォーム（“chuye[.]cam”、“ixmax[.]cn”）がその例です。このアクティビティが重点を置いていたのは、課金制御をバイパスし、十分なクォータなしでホストされた AI モデルを使用すること、さらにはアカウント、視聴カード、サブスクリプションなしでライブまたは録画のビデオを取得することです。ストリーミングのターゲットは稼働中の監視カメラプラットフォームなので、この「アカウントなしでのアクセス」は実際のカメラ映像を不正視聴したことになります。これは単なる利用資格のバイパスよりも機密度の高いカテゴリに属する行為です。アクターは以下のようなプロンプトを使用して、頻繁にアシスタントを鼓舞していました。
AI アシスタントは、オペレーションの技術面でのエンジンとして動作していました。2 つのセッションにまたがって 4,200 を超えるツールアクションを実行しました。そのほとんどはシェルコマンドの実行でした。AI アシスタントが実行したのは、Kali 指向の広範なツールセットのインストール、アプリケーションソースのレビュー、Web とメディアのプロトコルリクエストの送信、パッケージ化されたクライアントの分析、Python とシェルのユーティリティの作成、Go ベースのストリームプレーヤーの作成、Docker 環境の構築、レポートの下書きの作成です。通常はアクターが目標、ログイン情報、ときにはヒントを提供し、AI アシスタントがワークフローを選択して実行していました。
AI サービスのアクティビティは、NewAPI に由来するゲートウェイの分析を求める直接的なリクエストで始まっていました。NewAPI は、OpenAI 互換の一般的な API の公開、上流のモデルプロバイダーへのリクエストのルーティング、ユーザーのクォータと課金情報の管理を行うオープンソース プラットフォームです。簡体字中国語から翻訳すると、アクターは AI アシスタントに以下のような指示を出していました。
後に目的を以下のように明確化させています。
ストリーミングに関する作業ではさらに多くの結果が得られました。アクターは、AI アシスタントに対し、総当たり攻撃やソーシャルエンジニアリングを避けてプロキシの背後にとどまり、サイトのライブストリーミングを見つけて URL を再生するよう指示しました。アシスタントはクライアント側の設定の抽出、API のマッピング、JSON Web Token（JWT）認証とブラウザフィンガープリントの評価、オブジェクトストレージの検査を実行しました。
その後、HTTP Live Streaming（HLS）、Flash Video（FLV）、Real-Time Messaging Protocol（RTMP）の存在を確認するテストを実行しました。アシスタントは、最終に RTMP を使用すると、メディアサービスを介して録画に直接到達できることを見出しました。保存されたツールからの出力には、いくつかの有効な録画が表示されていました。なかには、ほぼ 1 日（約 84,500 秒）にわたるものもありました。
さらに、アシスタントはストリーミングスタックそのものに対するサーバー側の攻撃パスも特定しました。ZLMediaKit は、“127.0.0[.]1” からのリクエストをシークレットを要求することなく信頼するため、フロントエンド PHP アプリケーションに内在するサーバーサイド リクエスト フォージェリ（SSRF）の欠陥を使用すると、メディアサーバーの内部 API（“/index/api/addFFmpegSource”）に、信頼されたローカルの呼び出し元として到達できる、とそのレポートには記載されていました。アシスタントは、FFmpeg のソース URL 操作と連携させることで、ストリーミングホスト上でのリモートコード実行にいたる有望なパスを作成しました。
続いて AI アシスタントは、これらの発見から再使用可能なツールを作成しました。ローカルプレーヤー、Docker パッケージング、録画スクリプトが作成されたため、アクターは、復元されたストリームの再生、キャプチャ、提供を実行できるようになりました。入手した Go バイナリは、ターゲットのカメラプラットフォームの認証済みストリーム URL を再構築する機能を備えていて、カメラごとの HLS プレイリストと WeChat 共有ログイン、室内表示リクエストを組み合わせていました。また、ハードコーディングされた RTMP 取り込みエンドポイントを使用し、SOCKS5 プロキシを介してトラフィックをルーティングする機能も備えていました。さらにアクターは、ブラウザ自動化バイパスツールをスタンドアロンの Windows GUI アプリケーション（PyInstaller と PySide6 を使用して構築）としてパッケージ化していました。これには、クライアント側の自動化チェックを無効化するために、ステルス構成の Selenium ドライバが使用されていました。
その後、このオペレーションは、利用資格のバイパスからホストに対する侵害の未遂にまでエスカレートしています。アクターは AI アシスタントに以下のように指示していました。
アシスタントは、エクスプロイトコードをダウンロードして新たに発見されたとされる NGINX のメモリ破損問題に適応させたうえで、リバースシェルリスナーを起動し、外部に向けられたサービスを対象にテストを繰り返していました。このリクエストによって、再現性の高いクラッシュのような動作が発生し、保護されたパスのルーティング方法が明らかに変化しました。しかしリバースシェルが登場することはありませんでした。最終的にアシスタントは、アドレス類推とヒープレイアウトの前提が不首尾であったため、RCE は失敗したと記録しています。
Authors