TradingClaw Needle Stealer、偽のAI取引エージェントをウォレットの罠に変える
TradingClaw Needle Stealerは、2026年に確認されたキャンペーンで、1つの偽AI取引エージェントを7種類の暗号資産ウォレットへ至る直接的な侵入口に変えた。ダウンロードされたソフトウェアは取引を自動化するのではなく、正規のブラウザ拡張機能を、ウォレットのパスワードを窃取するよう設計された巧妙な偽造版に置き換えた。
HPは、2026年4月から6月に収集したテレメトリーでこの活動を特定した。Malwarebytesも4月にこのキャンペーンの分析を独自に実施し、悪意あるtradingclaw[.]proサイトとの関連を突き止めた。このサイトはTradingViewとも、類似したTradingClaw名を使用する正規のスタートアップとも無関係だった。
中心的な対立は、AIの性能と人間による取引の比較ではない。自律的な金融支援という約束と、その約束のためにユーザーが明け渡すよう求められるアクセス権との間にある。攻撃者は新しい人工知能モデルも、ブロックチェーンの脆弱性も必要としなかった。AIをテーマにしたダウンロードを十分な時間だけ信頼させ、一般的なWindowsマルウェアを実行させればよかった。
TradingClaw Needle Stealerは正規のウォレット拡張機能を置き換えた
決定的だったのは受動的なデータ収集ではない。Needle Stealerは、ユーザーがすでに信頼していた拡張機能を、悪意あるウォレットインターフェースへと積極的にすり替えた。
不正なTradingClawサイトは、TradingViewユーザー向けのAI搭載アシスタントを宣伝していた。個別最適化された戦略と、継続的な暗号資産取引を約束していた。訪問者には、Trading Agent.exeという実行ファイルと付属のダイナミックリンクライブラリを含むZIPアーカイブが配布された。
Trading Agent.exeは取引プログラムではなかった。研究者らはこれを、Microsoft署名付きの正規ユーティリティであるOLEViewだと特定した。攻撃者は、その信頼された実行ファイルの隣にiviewers.dllという悪意あるファイルを配置していた。
OLEViewが起動すると、Windowsは近くにあるDLLを読み込んだ。この挙動により、正規アプリケーションに攻撃者が制御するコードを読み込ませる実行手法であるDLLサイドローディングが可能になった。この手法では、認知されたプログラムを隠れみのにして悪意ある活動を開始できる。
その後キャンペーンは別のペイロードを復号し、新たに起動した正規のWindowsプロセスに注入した。プロセスホロウイングと呼ばれるこの手法は、外見を保ったまま信頼されたプロセス内部のコードを置き換える。
最終ペイロードは、Goで記述されたモジュール型の情報窃取マルウェア、Needle Stealerだった。Malwarebytesは、その広範な機能にブラウザデータ、ログインセッション、スクリーンショット、ファイル、Telegram情報、暗号資産ウォレット関連データの収集が含まれていたと確認した。
このキャンペーンを特に危険なものにしたのは、ウォレット置換機能だった。HPによると、このマルウェアはインストール済みのブラウザ拡張機能から、Phantom、Trust Wallet、Atomic Wallet、Coinbase Wallet、OKX Wallet、MetaMask、Tonkeeperという7つの標的を検索していた。
対応するウォレットを見つけると、マルウェアはブラウザを終了させた。その後、既存の拡張機能の場所に悪意あるバージョンのウォレット拡張機能を展開した。
置換版は、正規ウォレットを模した現実的なインターフェースを表示した。被害者がウォレット識別子とパスワードを入力すると、そのコピーは認証情報を攻撃者が管理するサーバーへ送信した。
この一連の流れは、見慣れたロック解除画面の意味を変える。ユーザーは、当初インストールした拡張機能にパスワードを入力していたのではなくなっていた。インターフェースは見覚えのあるままだが、そのコードと送信先は変えられていた。
HPは2026年9月の第2四半期の脅威調査結果で、このキャンペーンを要約した。同社によれば、ポートフォリオの自動化を探していた被害者は、ブラウザウォレットをすり替えられるマルウェアをダウンロードしていた。
この報告書は、確認された被害者数や盗まれた暗号資産の総額を明らかにしていない。また、アーカイブをダウンロードした訪問者数も示していない。技術的な能力だけではキャンペーンの金銭的影響を立証できないため、これらの欠落は重要だ。
確認された事象はより限定的だが、依然として深刻である。研究者らは、AI取引を餌に、信頼されたソフトウェア、秘匿化手法、認証情報を窃取するウォレット置換を組み合わせた、機能する配布チェーンを観測した。
AIエージェントは技術的ブレークスルーではなく、誘い文句だった
TradingClawは、攻撃者が本物のエージェントを自ら構築せずとも、AIエージェントを取り巻く市場を悪用できることを示している。
このウェブサイトは自律型金融の言葉を借用した。ユーザーの戦略に従い、継続的に取引を行うとされるボットを提供していた。これらの約束は、より少ない直接監督で計画・行動できるソフトウェアへの関心の高まりと一致していた。
この枠組みは攻撃者にとって有用な近道を生んだ。新しいエージェントを評価する人々は、未知のソフトウェア、広範な権限、アカウント接続、継続的な活動をすでに想定している。通常のデスクトップユーティリティなら疑わしく見える挙動も、自動取引製品には必要に思える可能性がある。
偽製品は、価値の高い文脈も標的にした。ブラウザウォレットは取引可能な資産、取引承認、アカウント認証情報のすぐ近くにある。そのロック解除インターフェースを侵害すれば、無関係なウェブサイトのパスワードを盗むよりも直接的に資金へ到達できる可能性がある。
ただし、このキャンペーンは窃取の実行に生成AIを必要としなかった。Needle Stealerの分析では、ソーシャルエンジニアリング、悪意あるダウンロード、DLL読み込み、ブラウザ操作を中心に構築された従来型の感染チェーンが説明されている。
この区別はユーザーと防御側の双方にとって重要である。プロンプトをブロックしたり、モデル出力を調査したり、AIガバナンス規則を適用したりしても、ユーザーがアーカイブをダウンロードすることは防げない。悪意ある挙動はソフトウェア配布とエンドポイント実行の段階で始まっていた。
エージェントというラベルは、新しいものをインストールするもっともらしい理由を与えることで、誘い文句を強化した。また、検索広告や検索エンジン操作によって増幅できる物語もサイトに与えた。
HPの説明に基づく報道によると、運用者は汚染された検索結果と有料広告を通じて訪問者を引き寄せようとした。検索エンジンポイズニングは、明らかに迷惑なメッセージ内ではなく、人々が発見や比較を期待する場所に欺瞞的なページを配置する。
この経路は被害者の認識を変える。不審な添付ファイルをクリックする人は、別の当事者がやり取りを始めたことを認識している。AI取引ツールを検索する人は、結果として表示されたダウンロードが自らの独立した選択から生じたと感じることがある。
このサイトは選択的な配信も行っていた。Malwarebytesは、一部の訪問者には偽製品が表示される一方、別の訪問者はstudypages[.]comへリダイレクトされることを観測した。そのため、検索エンジンが標的となる訪問者とは異なるコンテンツを受け取る可能性があった。
選択的な表示は、自動スキャナーや研究者への露出を減らせる。また、調査者が常に悪意あるページを受け取れるとは限らないため、単純なレピュテーションチェックを複雑にする。
これは正規のTradingViewプラットフォームによる攻撃ではなかった。Malwarebytesは、この偽サイトをTradingViewおよび正規のtradingclaw.chatスタートアップから明確に切り離した。この明確化により、悪意あるドメインが類似名のサービスに責任を転嫁することを防ぐ。
この名前の衝突は、より広範な検証上の問題も示している。もっともらしい製品名、洗練されたインターフェース、既知のプラットフォームへの言及があっても、所有者を証明するものではない。新しいAIツールには長い運用履歴がないことが多く、ユーザーが通常頼るレピュテーションシグナルは弱くなる。
だからといって、すべての小規模なAI製品が安全でないわけではない。新規性を正当性の証拠として扱えない、という意味である。本物の開発者に恩恵をもたらす同じ高速なリリースサイクルは、攻撃者にも未知のブランド、インストーラー、権限要求を隠れみのにする機会を与える。
信頼されたWindowsソフトウェアが欺瞞の一部になった
有効な署名は1つの実行ファイルの正体を確立するが、その隣に置かれたファイルやパッケージを配布する製品を検証するものではない。
このキャンペーンにおける最も重要な逆転は、Microsoft署名付きのOLEViewに関わるものだった。ユーザーやセキュリティ制御は、デジタル署名を強力な信頼シグナルとして扱うことが多い。ここでは、署名済みコンポーネントが署名されていない悪意ある隣接ファイルの起動を助けた。
この区別は技術的だが、本質的である。コード署名は、特定のファイルが表明された発行元から提供され、署名後に改変されていないことを確認できる。同じアーカイブ内のすべてのファイルを認証するものではない。
Needle StealerはWindowsのライブラリ読み込み動作を悪用した。署名済みプログラムは必要なDLLを探し、攻撃者は予想される名前と場所で悪意あるファイルを提供した。
MITREはこの挙動をDLLサイドローディングとして分類している。同組織は、攻撃者が正規アプリケーションの隣に悪意あるペイロードを置くことで、信頼されたプログラムに敵対的なコードを実行させると説明している。
したがって、信頼された実行ファイルは改変されることなく配布コンポーネントになった。この構成は、可視化されるプロセスが正規の発行元に属するため、検知を複雑にし得る。
HPは、OLEViewがアーカイブによるMicrosoft Defender SmartScreenのレピュテーションチェック通過を助けたと報告した。ただし、この発見を、署名が現在のすべてのWindows防御を自動的に回避する証拠と解釈すべきではない。
Microsoftは、レピュテーションチェックが発行元のレピュテーションとファイルハッシュのレピュテーションの両方を考慮すると説明している。新たに署名されたプログラムであっても、十分な良好な履歴を確立するまでは警告を受ける可能性がある。
エンドポイントでの挙動も、Windowsのバージョン、ポリシー、有効化されたセキュリティ機能によって異なる。Smart App Controlは、一部のWindows 11システムで特定のSmartScreen動作に優先する場合がある。
より大きな教訓は、1つの肯定的なシグナルではインストールチェーン全体を検証できないということだ。署名済み実行ファイル、暗号化されたウェブサイト接続、プロフェッショナルなデザイン、見慣れたウォレットインターフェースはいずれも、限定的な問いにしか答えない。
このキャンペーンは、複数の限定的なシグナルを重ね合わせた。ウェブサイトはエージェントのような製品を提示した。アーカイブにはもっともらしいファイル名が使われた。実行ファイルにはMicrosoftの署名があった。置換された拡張機能は既存のウォレットに似せられていた。
各要素は異なる段階で摩擦を減らした。しかし、パッケージが主張された製品開発者から提供されたことを示すものはなかった。
実行後、マルウェアは別の偽装層を使用した。プロセスホロウイングは、悪意あるコードを新たに開始された正規プロセス内に配置した。この手法は、元のダウンロードから注意をそらし、一見すると通常に見えるプロセスへと向けさせた。
ブラウザの置換は最後の層を加えた。MetaMaskやCoinbase Walletに戻ったユーザーは、必ずしも信頼を求める新しい拡張機能を目にしたわけではない。マルウェアは、既存の場所にある見慣れた拡張機能を置き換えようとした。
このことは、視覚的な認識が信頼できる防御ではないことを示す。ロゴ、レイアウト、パスワード入力画面はコピーできる。ユーザーには、インストール前の配布元の来歴と技術的な検証が必要であり、インターフェースを後から見分けるだけでは不十分だ。
組織には追加の問題がある。ブラウザウォレットは、企業メール、文書、認証情報も扱うデバイス上に存在する場合がある。Needle Stealerの文書化された機能は、暗号資産情報を超えていた。
そのため、感染に成功すれば、個人取引と職場へのアクセスの境界を越える可能性がある。保存されたブラウザセッション、ファイル、メッセージングデータ、スクリーンショットはいずれも二次的な露出を生み得る。
これは、このキャンペーンが暗号資産の界隈にとどまらず重要である理由を説明している。最初の誘導対象は暗号資産ユーザーだったが、感染したエンドポイントには、より広範な価値の高い情報が存在していた。
本当のトレードオフは、エージェントへのアクセスと検証可能な制御の間にある
エージェントはより多くのアクセスを与えられるほど有用になるが、接続が一つ増えるごとに、誤ったソフトウェアを信頼するコストも高まる。
トレーディングアシスタントが有益な分析を提供するには、市場情報と指示が必要になる。より自律性の高い製品であれば、取引所へのアクセス、ウォレットの可視化、ブラウザの制御、API認証情報、継続実行の許可も求める可能性がある。
こうした機能は、ソフトウェアが正規のものであり、慎重に制約されている場合には価値を生む。一方、製品が悪意あるものであれば、効率的な窃取経路になる。
TradingClawは、約束されたエージェントを提供することなく、この緊張関係を悪用した。攻撃者に必要だったのは、自動化アシスタントにはインストールと金融関連のコンテキストが必要だという期待だけだった。
このため、エージェントの検証は通常のWebサイトの検証とは異なる。欺瞞的なWebサイトは、送信された一つの認証情報を盗むかもしれない。インストールされたエージェントは、ファイル、ブラウザセッション、クリップボードの内容、ローカルアプリケーション、将来の活動を観察できる可能性がある。
ユーザーが一台のデバイスで機密性の高い作業を組み合わせると、リスクは増大する。企業メール、暗号資産ウォレット、開発者認証情報、実験的なAIツールに使われるマシンは、一度侵害されると複数の価値ある標的を提示する。
HPは、ウォレットのパスワードと決済ワークフローを、不透明または未検証のエージェントアプリケーションから切り離すようユーザーに助言した。この推奨は、宣伝された取引戦略が機能するかを判断しようとするのではなく、アクセス境界に対処するものだ。
企業は、管理対象ブラウザを通じて同様の境界を適用できる。Googleは、管理者がインストール元を制限し、外部拡張機能をブロックし、許容できない権限を持つ拡張機能を防止できる拡張機能の制御を文書化している。
こうしたポリシーは管理対象システムでの露出を減らせるが、問題を排除するものではない。TradingClawのパッケージは、コード実行後にローカルの拡張機能ファイルを操作した。そのため、防止はエンドポイント制御、アプリケーションポリシー、分離にも依存する。
情報窃取型マルウェアがOSに到達した後も、ブラウザウォレットが信頼できる状態にあるとユーザーは想定すべきではない。永続化、窃取されたセッション、追加ペイロードが残っている場合、拡張機能を一つ再インストールするだけでは不十分な可能性がある。
この報告書は、Needle Stealerがハードウェアウォレットの取引確認を回避したかどうかを確認していない。ブラウザ認証情報の窃取とハードウェアキーの侵害は別の主張である。接続されたハードウェアウォレットも欺瞞的な取引確認プロンプトに直面し得るが、それは今回報告された仕組みではない。
同様に、このキャンペーンをブロックチェーンを攻撃するAIエージェントとして説明すべきではない。自律モデルが標的を選び、スマートコントラクトを悪用し、独自に資金を移動させたことを示す証拠はない。
攻撃者はAIブランディングをソーシャルエンジニアリングとして利用した。技術的な経路は、Windowsでの実行とブラウザウォレット認証を標的としていた。
このより限定的な説明により、防御の優先事項が明確になる。購入者は、開発元、配布チャネル、署名の主体、インストールパッケージ、要求されるアクセス、利用可能なセキュリティ文書を検証すべきだ。
検索結果での表示位置は、こうした確認の代わりにはならない。有料広告や上位表示されたページが、ユーザーを悪意あるドメインに誘導することがある。ツールを能動的に検索したという事実は、結果の信頼性を保証しない。
有効なHTTPS接続も、誠実な意図を証明できない。暗号化はブラウザとサイトの間の通信を保護する。サイトの運営者が正当であることを保証するものではない。
セキュリティチームは、実験的なエージェントソフトウェアをアクセスに関する意思決定として検討すべきだ。重要なのは、製品がAIを使用しているかどうかだけではない。そのアイデンティティ、更新チャネル、依存関係が破綻した場合に、ソフトウェアが何に到達できるかである。
この評価には、ローカルファイル、ブラウザプロファイル、パスワードストア、ウォレット拡張機能、APIキー、認証済みセッションを含めるべきだ。また、それらの認証情報をどれだけ迅速に失効できるかも対象にする必要がある。
懐疑的な観点も同様に重要である。HPのテレメトリとMalwarebytesのリバースエンジニアリングは、このキャンペーンの仕組みを確立しているが、その全体的な流行規模までは示していない。
9月の報告書は、ある四半期中に観測された活動を説明している。偽のAI取引ツールが現在、支配的なマルウェア配布チャネルになったことを証明するものではない。攻撃者がこのパターンを運用可能なものにしたことを示している。
規模を誇張せずとも、制御を正当化するには十分である。再現可能な一つの感染チェーンでも、信頼できる被害者数が判明する前に設計上の弱点を露呈させられる。
TradingClawキャンペーン後に防御側が注視すべきこと
次の試金石は、これが一つの洗練された誘い文句にとどまるのか、それともエージェントのカテゴリをまたぐ再利用可能な配布パターンになるのかである。
最初のシグナルは、新たな製品名の下でNeedle Stealerの配布チェーンが再利用されることだ。Malwarebytesは、Amadey、GCleaner、CountLoaderまたはDeepLoadを含む他のマルウェアもNeedle Stealerを配布していたと報告している。
一つの悪意あるドメインから複数のAIブランド製品への移行は、攻撃者がエージェントの発見を反復可能な獲得チャネルと見なしているという見方を強める。孤立した再利用であれば、より限定的な解釈を支持する。
防御側は、認識可能な実行可能ファイルと想定外のDLLファイルを組み合わせたZIPアーカイブを探すべきだ。また、ユーザーが書き込み可能なダウンロード先からライブラリを読み込むプロセスも監視すべきである。
第二のシグナルは、ブラウザ拡張機能の置換がさらに広がるかどうかだ。観測された構成は7種類のウォレット製品をサポートしていたが、Needle Stealerのモジュール式設計により、運用者は機能と標的を変更できる。
パスワードマネージャー、IDツール、職場向け拡張機能を狙う新たな悪意あるコピーは、暗号資産ユーザー以外にも圧力を広げる。この展開は、インターフェースの置換が一般的な認証情報窃取戦略になりつつあることを示すだろう。
管理者は、計画されていない拡張機能ディレクトリの変更、拡張機能の変更に先立つブラウザの終了、承認済みの配布経路外に現れる拡張機能を監視すべきだ。
第三のシグナルは、検索プロバイダー、ブラウザベンダー、エンドポイントプラットフォームが取得チェーン全体を妨害できるかどうかである。広告と汚染された検索結果がすぐにユーザーを代替先へリダイレクトするなら、悪意あるドメインを一つ削除しても価値は限定的だ。
意味のある対応は、欺瞞的な広告、不審なダウンロード、署名済みバイナリの悪用、ローカル拡張機能の置換、コマンドサーバーとの通信を結び付けるものになる。一つのチェックポイントだけでは、シーケンス全体を把握できない。
Microsoftのレピュテーションシステムは依然として有用だが、TradingClawの事例は、なぜレピュテーションだけでは機能し得ないのかを示している。ブラウザポリシーは役立つが、ユーザーがデバイスに到達した後から始まる。エンドポイント分離も有用だが、実行前に構成されている場合に限られる。
ウォレットプロバイダーにも役割がある。ユーザーには、拡張機能の完全性を検証し、予期しない置換を認識するための、より明確な方法が必要だ。ローカルで変更された拡張機能に関するより強い警告は、見た目の親しみやすさへの依存を減らせる可能性がある。
AI開発者は、なりすましを製品セキュリティの一部として扱うべきだ。公式ダウンロード先、署名情報、ハッシュ、サポートドメイン、明確なインストール手順を公開すれば、ユーザーが具体的に照合できる対象を提供できる。
小規模な開発者は、この問題のより難しい形に直面する。通常とは異なる権限を正当に必要とするソフトウェアを公開する一方で、確立された評判を持たない可能性がある。したがって、透明性の高い配布慣行は、重要性が下がるどころか、より重要になる。
個人にとっての当面の行動は、実験と金融アクセスを分離することだ。未検証のエージェントは、有効なウォレット拡張機能や機密セッションを保持する同一のブラウザプロファイル内で実行すべきではない。
tradingclaw[.]proからソフトウェアを実行した人は、デバイスが侵害された可能性があるものとして扱うべきだ。切断すれば継続的な通信を制限できるが、インシデント対応はクリーンなデバイスから実施すべきである。
感染後に入力したウォレット認証情報は、漏洩したものと見なすべきだ。ユーザーは、信頼できるソフトウェアで資産を移動し、取引所セッションを失効させ、パスワードを変更し、ブラウザに保存された他のアカウントを確認する必要があるかもしれない。
組織は、証拠を消去する前にセキュリティチームを関与させるべきだ。ブラウザの変更、ダウンロードされたアーカイブ、プロセス活動、ネットワーク記録は、感染範囲の確立に役立つ。
ユーザーは、パスワード変更とウォレット復旧も区別すべきだ。攻撃者がリカバリーフレーズまたは秘密鍵を取得している場合、ウォレットのパスワード変更では資産を保護できない可能性がある。
確認されたキャンペーンは、置換された拡張機能を通じたウォレット識別子とパスワードの取得に焦点を当てていた。Malwarebytesは、Needleのコントロールパネルに、より広範なウォレット偽装機能とシードフレーズ取得機能も記録している。
この能力は、すべての被害者がリカバリーフレーズを失ったことを証明するものではない。ただし、感染システム上でリカバリーフレーズが表示または保存されたことがないか確認する根拠にはなる。
TradingClaw Needle Stealerキャンペーンは、最終的にエージェントソフトウェアをめぐる検証の空白を露呈させている。新しいツールは、評判が確立される前に、ユーザーへ迅速な行動、未知のコンポーネントのインストール、価値あるデータの接続を求める。
攻撃者は、この体験を比較的低コストで模倣できる。実在する取引モデルを上回る必要はない。最初の実行まで、信頼できるように見せるだけでよい。
金融アカウントへアクセスするAIエージェントをインストールする前に、別の信頼できるチャネルを通じて発行元を検証する。正確なダウンロードドメインと署名の主体を確認する。そして、同じ作業をウォレットアクセスなしで実行できないかを問うべきだ。
これらの確認が依然として不明確なら、インストールを保留する。決定的なセキュリティ上の問いは、エージェントがより良い取引を約束するかどうかではない。ブラウザ、認証情報、資金に到達する前に、そのソフトウェアを誰が管理しているかを証明できるかどうかである。



