タグアーカイブ マルウェア

WordPressに勝手にインストールされるwp-flareマルウェアの感染経路と駆除方法

WordPressに勝手にインストールされるwp-flareマルウェアの感染経路と駆除方法

WordPressに「wp-flare」という身に覚えのないプラグインがインストールされていた場合、それはマルウェアによる不正侵入の痕跡だ。感染したプラグインファイルとデータベース上の登録を削除し、侵入経路を特定して塞ぐことが根本対策になる。

wp-flareマルウェアの感染経路はどこにあるのか

wp-flareマルウェアの感染経路はどこにあるのか

wp-flareは正規のプラグインディレクトリには存在しない、攻撃者が設置する不正なプラグインだ。このプラグインがインストールされるということは、すでに何らかの方法でサイトの管理者権限を奪われている、またはファイルを書き込む経路を確保されていることを意味する。

感染経路として最も多いのは、使用しているプラグインやテーマに存在する脆弱性の悪用だ。すべてのプラグインが最新版でも、サポートが終了した古いプラグインや、公式ディレクトリにない野良プラグインに脆弱性が残っているケースがある。攻撃者はこうした穴を突いて任意のファイルをアップロードし、不正なプラグインを設置する。

次に疑うべきは、管理者パスワードの漏洩や総当たり攻撃の成功だ。二段階認証(2FA)を導入していても、XML-RPC経由の認証試行や、別サイトから流出した同じパスワードを使い回している場合は突破されることがある。

複数サイトが同時期に感染する理由

異なるホスティングの複数サイトが同時期に感染する場合、共通して使っているプラグインやテーマ、管理ツールが感染源になっている可能性が高い。たとえば、同じ開発元が配布するプラグインの配布元が改ざんされていたり、管理用のパソコン自体がマルウェアに感染してFTPやSSHの認証情報を窃取されているケースもある。

感染経路の特定には、各サイトのファイル更新日時とアクセスログを突き合わせるのが有効だ。wp-flareのファイルが設置された日時を調べ、その前後に不審なPOSTリクエストやログイン試行がないかを確認する。

感染経路の候補
プラグインの脆弱性 任意ファイルのアップロード wp-flare設置
パスワード漏洩 管理者ログイン突破 プラグインインストール
FTP・SSH認証情報の窃取 ファイル直接改ざん wp-flare設置
侵入の入口  攻撃者の行動  最終的な被害

上の図は感染に至る典型的な3つの経路を示している。どの経路であっても最終的にはwp-flareという不正プラグインが設置される点が共通している。

感染したサイトで最初に確認すべき症状

感染したサイトで最初に確認すべき症状

wp-flareに感染したサイトでは、管理画面のプラグイン一覧に「wp-flare」という名前の見慣れない項目が表示される。ただし攻撃者がプラグインの表示名を偽装している場合もあるため、一覧に表示されないこともある。

そのほか、以下のような症状が現れることがある。すべてに該当する必要はなく、1つでも当てはまれば感染を疑うべきだ。

  • サイトが知らないURLにリダイレクトされる
  • 検索結果に表示されるタイトルや説明文が書き換えられている
  • 管理画面の動作が急に重くなった
  • 見覚えのない管理者ユーザーが追加されている
  • サーバーに身に覚えのないファイルが増えている

最も確実なのは、サーバーのプラグインディレクトリ(wp-content/plugins/)を直接確認することだ。wp-flareという名前のフォルダが存在する場合は、マルウェア感染と断定してよい。

wp-flareマルウェアを駆除する手順

wp-flareマルウェアを駆除する手順

wp-flareの駆除は、プラグインファイルの削除だけでなく、データベース上の不正な登録や、設置されたバックドアの除去まで行う必要がある。以下の手順で進める。

STEP 1 サイト全体のバックアップを取得する
STEP 2 wp-flareプラグインのフォルダを削除する
STEP 3 データベースから不正な登録を削除する
STEP 4 全ファイルをスキャンしてバックドアを除去する
STEP 5 全パスワードと認証情報を変更する

この手順は上から順に実施する。途中でサイトが表示できなくなっても復旧できるよう、STEP 1のバックアップは必ず最初に行う。

wp-flareのプラグインフォルダを削除する

FTPソフトまたはホスティングのファイルマネージャーにログインし、wp-content/plugins/wp-flare ディレクトリを丸ごと削除する。管理画面からプラグインを「削除」しようとしても、プラグイン自体が無効化を妨害する仕組みを持っている場合があるため、ファイルシステム上から直接削除するのが確実だ。

削除後、管理画面のプラグイン一覧に「wp-flare」が表示されなくなることを確認する。もしプラグイン一覧にまだ表示される場合は、データベース側に登録が残っている可能性が高い。

データベースから不正な登録を削除する

WordPressのプラグイン情報は、データベースの wp_options テーブルにある active_plugins という項目で管理されている。不正プラグインがここに登録されていると、ファイルを削除しても管理画面に残り続ける。

phpMyAdminなどのデータベース管理ツールで wp_options テーブルを開き、option_nameactive_plugins の行を探す。その値の中に wp-flarewp_flare を含む文字列があれば、その部分を削除する。操作前にデータベースのバックアップを取得しておくこと。

バックドアの痕跡を全ファイルから探す

wp-flare本体を削除しても、攻撃者が別の場所にバックドア(再侵入用の隠しファイル)を設置している場合がある。主に以下の場所を確認する。

  • テーマディレクトリ内の見覚えのないPHPファイル
  • アップロードディレクトリ内のPHPファイル(画像のはずなのに拡張子がPHPになっているもの)
  • WordPress本体の wp-adminwp-includes 内の改ざんファイル
  • サイトのルート直下に置かれた小さなPHPファイル

ファイル数が多い場合は、サーバー上で find コマンドを使って直近に変更されたファイルを抽出すると効率的だ。感染が確認された日時以降に更新されているPHPファイルを重点的に調べる。

find /path/to/wordpress -name "*.php" -mtime -30

このコマンドは、指定したWordPressディレクトリの中で過去30日以内に更新されたPHPファイルを一覧表示する。感染が判明した時期に合わせて日数を調整する。

全パスワードと認証情報を変更する

駆除が完了したら、侵入経路に関係なく以下の認証情報をすべて変更する。感染中に窃取されていた可能性を考慮し、同じパスワードの使い回しは避ける。

  • WordPress管理画面の全ユーザーのパスワード
  • FTP・SSHの接続パスワード
  • データベースの接続パスワード
  • ホスティングのコントロールパネルのパスワード
  • メールアカウントのパスワード

再発を防ぐためのセキュリティ対策

再発を防ぐためのセキュリティ対策

wp-flareを駆除しても、感染経路を塞がなければ再び同じ被害に遭う。特に複数サイトが同時期に感染した場合は、サイト単体の対策だけでなく、管理環境全体の見直しが必要だ。

使用中のプラグインとテーマを棚卸しする

すべてのサイトで使用しているプラグインとテーマの一覧を作成し、以下に該当するものがないか確認する。これらが感染源になっている可能性が高い。

  • 配布元が公式ディレクトリではないプラグイン
  • 更新が1年以上停止しているプラグイン
  • サイトの機能上不要になったプラグイン
  • 正規の配布元ではないサイトから入手したテーマ

不要なプラグインは削除し、更新が停止しているプラグインは代替品への移行を検討する。どうしても使い続ける必要がある場合は、開発元のセキュリティ情報を定期的に確認する。

管理用パソコンのマルウェアスキャンを行う

複数のサイトが同時期に感染した場合、サイトではなく管理用のパソコンが感染源になっている可能性がある。FTPやSSHの接続情報を保存しているFTPソフトの設定ファイルから認証情報が窃取され、攻撃者に悪用されるケースがある。

管理用パソコンで信頼できるアンチウイルスソフトのフルスキャンを実施し、FTPソフトやパスワード管理ソフトの保存データが漏洩していないか確認する。スキャン後は、保存済みのパスワードもすべて変更するのが安全だ。

Before FTPソフトに平文で保存された認証情報が窃取される
After パスワードを変更し、FTPソフトの保存機能を使わない運用に切り替える

FTPソフトにパスワードを保存する機能は便利だが、マルウェア感染時には認証情報の流出経路になる。可能であれば、接続のたびにパスワードを入力する運用に切り替えるとリスクを減らせる。

ファイル変更の監視を導入する

感染の早期発見には、サーバー上のファイル変更を監視する仕組みが有効だ。WordPressのセキュリティプラグインには、ファイルの改ざんを検知して通知する機能を持つものがある。プラグインの新規インストールや、想定外のファイル変更があった場合にメールで知らせる設定にしておくと、被害が拡大する前に対処できる。

XML-RPCを無効化する

XML-RPCはWordPressの外部連携機能だが、総当たり攻撃やSSRF攻撃の入口として悪用されることが多い。外部サービスとの連携で使っていない場合は、無効化するのが効果的な対策になる。

セキュリティプラグインの多くにXML-RPCを無効化するオプションがある。もしくは、以下のコードをテーマの functions.php に追加する方法もある。

add_filter( 'xmlrpc_enabled', '__return_false' );

ただし、このコードは子テーマの functions.php に追加するのが基本だ。親テーマを直接編集すると、テーマ更新時にコードが消えるため注意する。

よくある質問

wp-flareは公式プラグインディレクトリに存在しないのか

存在しない。wp-flareはWordPress公式ディレクトリに登録されておらず、攻撃者が独自に設置する不正なプラグインだ。プラグイン一覧に表示される名前が同じでも、正規のプラグインと混同しないよう注意する。

管理画面からwp-flareを削除できない場合はどうするのか

管理画面からの削除ができない場合は、FTPまたはファイルマネージャーでサーバーに直接アクセスし、プラグインディレクトリからフォルダを削除する。削除後もプラグイン一覧に表示される場合は、データベースの active_plugins に残っている登録を手動で削除する必要がある。

感染したサイトのバックアップは復元に使えるのか

感染前のバックアップが確実に存在する場合は、バックアップからの復元が最も確実な駆除方法になる。ただし、バックアップ自体が感染後に取得されたものであれば復元しても意味がない。取得日時を必ず確認し、感染前のものを使う。

wp-flare対策に有効なセキュリティプラグインはあるのか

定期的なマルウェアスキャン、ファイル変更の監視、ログイン試行の制限、XML-RPCの無効化などを提供するセキュリティプラグインが有効だ。ただし、プラグインを導入するだけで完全に防げるわけではない。プラグインの棚卸しやパスワード管理など、運用面の対策と組み合わせることが重要になる。

同じパスワードを複数サイトで使い回してもよいのか

避けるべきだ。1つのサイトでパスワードが漏洩すると、同じパスワードを使うすべてのサイトが連鎖的に感染する原因になる。サイトごとに異なるパスワードを設定し、パスワード管理ソフトで一元管理するのが安全な運用だ。

この記事のポイント

  • wp-flareは攻撃者が設置する不正なプラグインだ
  • 感染経路はプラグインの脆弱性、パスワード漏洩、FTP認証情報の窃取が主な候補になる
  • 駆除はファイル削除とデータベースの掃除、バックドア除去まで行う
  • 複数サイトが感染した場合は管理用パソコンのマルウェアスキャンも必要だ
  • 再発防止にはプラグインの棚卸しとファイル変更の監視が有効だ
OptinMonsterやTrustPulseが原因でWordPressが乗っ取られた時の対処

OptinMonsterやTrustPulseが原因でWordPressが乗っ取られた時の対処

特定のプラグインをインストールしていた WordPress サイトで、管理者アカウントが勝手に作られたり、マルウェアを仕込まれる被害が広がっている。無効化した状態でも影響を受けるため、すぐにユーザー一覧とプラグインフォルダを確認しなければならない。

なぜ無効化したプラグインで侵入されたのか

なぜ無効化したプラグインで侵入されたのか

被害報告が相次いでいるのは、OptinMonster、TrustPulse、PushEngage という 3 つのプラグインだ。いずれも単体で配布されているほか、MonsterInsights Pro にバンドル(同梱)されて提供されている。注目すべきは、有効化していなくてもプラグインとして存在するだけで攻撃対象になった点だ。WordPress はプラグインを無効化しても、ファイル自体はサーバー上に残る。攻撃者はそのファイルに含まれる脆弱性を利用して外部からコードを実行し、管理者アカウントの新規作成や Cloudflare/ClearFake マルウェアの設置を行った。

無料版の Wordfence では検知できなかったケースが確認されている。シグネチャ(攻撃パターン)が更新されるまでの時間差や、攻撃手法が亜種に変化していたことが原因とみられる。そのため、目視での確認が不可欠だ。

侵入前 プラグインが無効で放置、ファイルはサーバー上に存在
侵入後 不明な管理者アカウントが追加され、不正な PHP ファイルが設置される
侵入前(ファイルはあるが無害に見える)  侵入後(管理者アカウントやマルウェアが追加される)

このデモは、プラグインファイルが放置された状態から攻撃者が侵入し、追加の不正な要素を仕込む流れを示している。

自分のサイトが影響を受けているか確認する手順

自分のサイトが影響を受けているか確認する手順

管理者アカウントの一覧を調べる

WordPress 管理画面の「ユーザー」→「すべてのユーザー」を開き、覚えのない管理者権限のアカウントが追加されていないかを確認する。アカウント名やメールアドレスに覚えがないもの、登録日時が直近のものがあれば要注意だ。

プラグインフォルダに不審な PHP ファイルがないか調べる

FTP ソフトやレンタルサーバーのファイルマネージャーで /wp-content/plugins/ 以下を開く。特に OptinMonster、TrustPulse、PushEngage のフォルダ内に、本来あるはずのない名前の PHP ファイルや、暗号化されたような文字列が書かれたファイルがないかを確認する。

プラグインをすでに削除してしまった場合でも、/wp-content/ 直下や /wp-includes/、テーマフォルダ内に不審な PHP ファイルが残っていないか、更新日時が最近のものに心当たりがないかを見ておくとよい。

STEP 1 管理画面「ユーザー」で管理者アカウントを確認
STEP 2 FTP で /wp-content/plugins/ 以下の不審ファイルを調査
STEP 3 .htaccess や wp-config.php に追記がないかも確認

管理者アカウントとファイルの両面から、侵入の痕跡を短時間で洗い出す手順を示している。

不正アクセスが発覚した場合の緊急対応

不正アクセスが発覚した場合の緊急対応

不正な管理者アカウントを即座に削除する

覚えのない管理者アカウントを見つけたら、すぐにそのユーザーを削除する。削除時に「すべての投稿を帰属させる」選択肢が出るが、攻撃者が作成した投稿や固定ページがなければそのまま削除してよい。念のため、削除前にゴミ箱や下書きに不審なコンテンツがないかも確認しておく。

不正ファイルを削除し、該当プラグインを完全に除去する

不審な PHP ファイルは必ずバックアップを取った上で削除する。OptinMonster、TrustPulse、PushEngage のいずれかがインストールされているなら、今後も脆弱性が残る可能性を考え、プラグイン自体を完全に削除するのが安全だ。同梱元の MonsterInsights Pro を利用している場合も、これらのアドオンが自動でインストールされていないか確認する。

サイト全体のマルウェアスキャンを実施する

Wordfence や Sucuri などのセキュリティプラグインで手動の詳細スキャンを実行する。無料版の自動スキャンだけでは検知漏れが起こる可能性があるため、手動でフルスキャンをかける。Sucuri のサイトチェック(外部スキャナ)を併用すると、サーバー内部からは見えにくい改ざんも検出しやすくなる。

再発防止と今後のセキュリティ対策

再発防止と今後のセキュリティ対策

使用していないプラグインやテーマは「無効化」ではなく「削除」する

WordPress では、プラグインを無効化してもファイルはサーバー上に残り続ける。今回の事例が示すように、無効状態でもファイルが存在するだけで攻撃の足場になる。今後は使わないと判断したプラグインやテーマは、面倒でも完全に削除する習慣をつけるのが鉄則だ。

プラグインの更新を常に最新に保ち、導入元を精査する

公式リポジトリ外のプラグインや、長期間更新が止まっているものはリスクが高い。どうしても必要な場合を除き、信頼できる提供元のものだけを使う。自動更新を有効にしておくと、脆弱性が公表された直後の修正パッチを適用しやすくなる。

定期的な管理者アカウントとファイルの監査を組み込む

月に一度は「ユーザー一覧」を開き、見慣れないアカウントがないかを目視点検する。あわせて、サーバーのファイル更新日時を確認し、心当たりのないタイミングで変更されたファイルがないかをチェックする。人が目で見る作業は、自動ツールの検知漏れを補う最後の砦になる。

よくある質問

無効化していてもなぜハッキングされたのか

無効化はあくまでプラグインの動作を止めるだけで、ファイルはそのままサーバーに残る。今回の攻撃はファイルの存在を前提に外部から直接コードを実行する手法だったため、有効か無効かは関係なく被害が発生した。

Wordfence が入っていれば安心なのか

今回の事案では、無料版 Wordfence で検知できなかった例がある。セキュリティプラグインに過度な期待をせず、定期的な手動確認と不要なファイルの削除を組み合わせることが欠かせない。

MonsterInsights を使っているが該当プラグインは入れていない

MonsterInsights Pro の一部バージョンでは、これらのプラグインが同梱されて自動インストールされる場合がある。プラグイン一覧を開き、OptinMonster、TrustPulse、PushEngage が存在しないか今一度確認してほしい。

すでに削除したが、まだ不安が残る場合の最終確認方法は

レンタルサーバーの管理画面で最近のアクセスログを確認し、不審な IP アドレスや POST リクエストがないかを調べる。データベースの wp_users テーブルと wp_usermeta テーブルを直接 SQL で確認し、管理者権限(wp_capabilities に administrator を含む)のユーザーに不明なものがないかを調べる方法も有効だ。

この記事のポイント

  • OptinMonster、TrustPulse、PushEngage は無効化でも攻撃対象になる
  • 管理者一覧とプラグインフォルダをすぐに目視確認する
  • 不正アカウントと不審ファイルは即座に削除する
  • 今後は使わないプラグインを無効化で放置せず完全削除する
  • セキュリティプラグインだけに頼らず定期手動監査を組み込む
WPプラグインのサプライチェーン攻撃、AIで見えてきた隠れた脅威

WPプラグインのサプライチェーン攻撃、AIで見えてきた隠れた脅威

WordPressプラグインのサプライチェーン攻撃が急速に広がっている。悪意ある攻撃者がプラグイン企業を買収し、あるいは正規のプラグインを乗っ取り、無防備なサイトへマルウェアを配信する手口だ。従来の「サイトを直接ハッキングする」という攻撃とはまったく異なるレイヤーで、静かに進行する。

Anchor Hostingの創業者であるAustin Ginder氏は、WP Tavernのポッドキャストでこの問題の全容を語った。同氏は2010年からWordPressに関わり、現在は数千のWordPressサイトを管理している。2026年に入り、長年安定していた顧客サイトでマルウェアが頻出するようになったことを受け、AIを駆使した徹底調査を開始した。

調査の結果、明らかになったのは単なる脆弱性の話ではない。正規のプラグイン更新チャンネルそのものが攻撃者に乗っ取られているという、構造的な脅威だ。本記事ではその仕組み、具体的な被害事例、そしてAIによって変わりつつあるセキュリティ対策の最前線を解説する。

サプライチェーン攻撃の実態(2つの侵入経路)

サプライチェーン攻撃の実態(2つの侵入経路)
経路1 プラグイン企業の買収(Buy-and-Weaponize)
攻撃者 プラグイン企業を買収 正規の更新チャンネル を取得
改ざん サードパーティ更新サーバー へ誘導するコードを仕込む
マルウェア配信 SEOスパム・バックドア を注入
※WP TavernのポッドキャストでAustin Ginder氏が言及した事例。攻撃者は6桁の金額を投じて企業を買収し、正規の更新フローを悪用する。
経路2 プラグインリポジトリの乗っ取り(Credential Breach)
攻撃者 作者の認証情報を窃取 作者になりすまし
悪意あるコード をプラグインに直接プッシュ
自動更新 ユーザーは気づかずに感染
※wordpress.orgのリポジトリはオープンソースで全変更履歴が追跡可能だが、事後検知になる点が課題。
攻撃者の行動  侵害された対象・被害  フローの方向

この図はサプライチェーン攻撃の2大経路を示している。いずれも、ユーザーが自動更新を有効にしている場合、まったく気づかずに感染する点が共通している。WP Tavernのポッドキャストで語られた内容を整理すると、攻撃者はこうした手法でプラグインを「武器化」し、正規更新を装いながらマルウェアを拡散している。

プラグイン買収による攻撃

WP TavernのポッドキャストでAustin Ginder氏が明かした最も衝撃的な手口は、攻撃者が実際にプラグイン企業を買収して武器化するというものだ。同氏はEssential Pluginsと呼ばれる30以上のプラグインを抱えるパッケージが売却され、その後にコード改変が行われた事例を報告した。

攻撃者は6桁の金額を投じてでも正規の配信チャンネルを手に入れる価値があると判断している。プラグインを買収すれば、更新ボタンを押すだけで何万ものサイトにコードを配信できるからだ。この手法の巧妙な点は、プラグインの本来の機能はそのまま維持されることである。ユーザーは見た目の変化に気づかない。

プラグインハイジャックによる攻撃

もうひとつの経路は、プラグインの更新先をすり替えるハイジャック型だ。攻撃者はまず正規のプラグインにサードパーティのアップデータを密かに組み込む。これはwordpress.orgのガイドライン違反だが、コードを巧妙に隠すことで審査をすり抜ける。

一度このコードが仕込まれると、以降の更新はwordpress.orgではなく攻撃者の管理するサーバーから配信される。wordpress.org側からは一切の可視性が失われ、ユーザーのサイトは知らぬ間に乗っ取られた状態になる。この手口は特に長期間気づかれにくく、過去にQuick Redirectionプラグインなどで実際に確認されている。

偶然のマルウェア除去から始まった調査

偶然のマルウェア除去から始まった調査

Austin Ginder氏がこの問題に気づいたのは、2026年2月に顧客サイトのマルウェア除去作業を行っていたときのことだ。同氏はWP Tavernのポッドキャストで「長年安全だったサイトが突然マルウェアに感染するようになった」と振り返っている。

従来のマルウェア除去は不安がつきまとう作業だった。ファイルをひとつずつ確認し、疑わしいコードを取り除いても、本当にすべてを取り切れたか確信が持てなかった。しかし同氏は、AIを使うことで状況が一変したと語る。AIがすべてのファイルを精査し、感染経路の特定から根本原因の解明までを一貫して行えるようになったのだ。

ある顧客の調査で行き着いた先はwordpress.orgのリポジトリだった。同氏はAIを使い、問題のプラグインの変更履歴を解析した。すると、正規の更新チャンネルが改ざんされている痕跡が見つかった。ここから本格的な調査が始まった。

以降、同氏は4件の詳細な調査レポートを公開した。いずれも異なるプラグイン、異なる攻撃者によるものだった。最初の1件が単発の事件ではなかったことが、ここで明らかになった。

AIが切り拓く新たな脅威検出

AIが切り拓く新たな脅威検出

ファイル単位の徹底監査

Austin Ginder氏はAIの活用について、WP Tavernのポッドキャストで具体的な方法を説明している。同氏は月額200ドルのClaude Codeサブスクリプションを使い、顧客サイトの全ファイルを1行ずつ監査している。これは人間には不可能な作業量だが、AIなら数十万行のコードを短時間で精査できる。

「1バイトの変更も見逃さない」と同氏が語るこの手法は、静的解析の域を超えている。AIはコードの文脈を理解し、単なるシグネチャマッチングでは検出できない巧妙なバックドアも特定する。あるケースでは、一見無害に見えるJavaScriptの埋め込みコードから、クレジットカードスキマーの存在を突き止めた。

バリアント検出ツールの実装

さらに同氏は、プラグインのバージョン差異を検出する独自ツールをAIで構築した。これは、インストールされているプラグインのコードがwordpress.org上の正規バージョンと異なっていないかを自動照合する仕組みだ。

このツールのテスト中、Quick Redirectionプラグインのバリアント版が12サイトで稼働していることを発見した。本来の作者が意図せず(あるいは意図的に)、多くのユーザーをハイジャック版へ誘導していた事例だ。さらに、上位2000のWordPressサイトをスキャンした際には、Scroll To Topプラグインに不正コードが仕込まれているのを確認した。このプラグインは2万サイトにインストールされていたが、攻撃者はまだ「引き金を引いておらず」、被害が表面化する前に発見できたという。

従来のマルウェア検出(Before)
シグネチャ照合 既知のパターンしか検出できない
手動監査 数千ファイルの全量確認は非現実的
未知のバックドアや巧妙に隠されたコードを見逃すリスクが大きい
AI による監査(After)
全ファイル精査 1行単位でコードの意味を理解
バリアント検出 正規版との差分を自動で特定
感染経路追跡 どこから侵入したかを逆算して特定
トリガーが引かれる前の「潜伏状態」でも異常を検出できる

AIによる監査は、コードの意味を解釈しながら異常を浮かび上がらせる。従来のシグネチャベースでは見逃していた「まだ発動していない攻撃コード」も、文脈の不自然さとして検出できる点が最大の強みだ。

過去13年間活動を続ける攻撃者の発見

Austin Ginder氏はWP Tavernのポッドキャストで、13年にわたって活動を続けている攻撃者の存在にも言及した。この攻撃者は、何度アカウントやプラグインを閉鎖されても、新しいアカウントを作り直し、別のプラグインで同じ手口を繰り返してきた。

「彼らを止めるには、単にコードを修正するだけでは足りない」と同氏は語る。攻撃のインフラそのものを無効化し、再発を防ぐ仕組みが必要だ。AIによる大規模監査が、こうした長期化する脅威への対抗手段として期待されている。

WP Beaconが目指すコミュニティの連携

WP Beaconが目指すコミュニティの連携

Austin Ginder氏は、調査結果を共有するプラットフォームとして「WP Beacon(wpbeacon.io)」を立ち上げた。これは従来の脆弱性データベースとは異なり、サプライチェーン攻撃に特化した情報を集約する場である。既存の脆弱性DBが「コードの欠陥」に注目するのに対し、WP Beaconは「悪意ある行為者」そのものの行動パターンを記録する。

同氏はWP Tavernのポッドキャストで、WP Beaconの真の目的は「セキュリティ研究者やホスティング企業が行動を起こすための情報基盤」になることだと述べた。実際、同氏が発見した攻撃者のサーバーは、協力者の手によってドメイン停止措置が取られたという。調査と対策を分業し、攻撃インフラを迅速に無力化する流れを作ることが狙いだ。

今後の対策と個人でできること

今後の対策と個人でできること

Austin Ginder氏はWP Tavernのポッドキャストの中で、個人でもすぐに実践できる対策として、自サイトのバックアップをAIで監査する方法を提案した。Claude Codeなどのツールにサイトの全ファイルを読み込ませ、「すべての行をチェックし、脆弱性やマルウェアの痕跡を報告してほしい」と指示するだけでも、高い精度の分析結果が得られるという。

「我々はデータの上に座っているが、それを使いこなせていない」と同氏は指摘する。大手ホスティング企業が保有する数百万サイト分のデータをAIで横断分析できれば、攻撃パターンの早期発見と封じ込めが可能になる。WP Beaconがそうした連携の起点となることが期待されている。

長期的には、プラグインの全コード監査を自動化し、変更が発生するたびにAIがチェックを行う仕組みが必要だ。wordpress.orgのリポジトリには6万以上のプラグインが存在するが、CSSや画像ファイルを除外し、PHPやJavaScriptの変更だけを対象にすれば、現実的な範囲でカバレッジを確保できる。

この記事のポイント

  • WordPressプラグインのサプライチェーン攻撃は、買収とハイジャックの2経路で進行する
  • ユーザーは自動更新を通じて、まったく気づかずにマルウェアを受け取る可能性がある
  • AIを使った全ファイル監査で、従来の方法では見逃していた潜伏型の脅威も検出できる
  • WP Beaconはサプライチェーン攻撃に特化した情報基盤として、コミュニティ連携を促進する
  • 個人でもClaude CodeなどのAIツールで自サイトの監査を実施できる
Google Cloud、AI脅威レポートで攻撃者によるゼロデイ発見・自律型マルウェアの実態を公開

Google Cloud、AI脅威レポートで攻撃者によるゼロデイ発見・自律型マルウェアの実態を公開

Google Cloudの脅威インテリジェンスグループGTIGが2026年5月、最新のAI脅威トラッカー報告を公開した。今回の報告では、攻撃者がAIを悪用してゼロデイ脆弱性を発見した初めての事例が確認され、また自律的に動作するマルウェア「PROMPTSPY」の詳細な分析結果が示された。

報告書はAIに関する脅威を「ツールとしてのAI」と「標的としてのAI」の2軸で整理。攻撃者は脆弱性発見の自動化や防御回避コードの生成だけでなく、AIの開発エコシステム自体を狙ったサプライチェーン攻撃も活発化しているという。本記事では、この報告書の重要ポイントを実務者向けにわかりやすく解説する。

AIが攻撃ツールに ゼロデイ発見から自律型マルウェアまで

AIが攻撃ツールに ゼロデイ発見から自律型マルウェアまで
2026年GTIG報告に見るAI脅威の二面性
ツールとしてのAI
  • 脆弱性発見の自動化とゼロデイエクスプロイト開発
  • マルウェアコードの生成や難読化による検知回避
  • 攻撃ライフサイクルの自律実行(PROMPTSPY等)
標的としてのAI
  • OpenClawスキルへの悪意あるコード混入
  • LiteLLMやGitHubリポジトリへのサプライチェーン攻撃
  • AI APIキーやクラウド認証情報の窃取

今回の報告では、攻撃者が生成AIを業務効率化ツールとして悪用する段階から、攻撃そのものの中核に組み込むフェーズへと急速に移行している実態が浮き彫りになった。

AIがゼロデイを発見 犯罪グループが初の成功事例

GTIGの観測によると、ある犯罪グループが広く使われているオープンソースのシステム管理ツールを標的に、二要素認証(2FA)をバイパスするゼロデイ脆弱性を開発した。このエクスプロイトには、AIが生成したとみられる強い痕跡が残っており、GTIGが初めて「AIによるゼロデイ開発」を確認した事例となった。ベンダーへの責任ある開示を通じて、大規模な悪用を未然に防げたという。

コードを解析すると、詳細なドキュメント文字列や幻覚(ハルシネーション)で誤ったCVSSスコアが付与されているなど、LLMが出力する典型的な「教科書的Python記法」が随所に見られた。これは従来のファジングや静的解析ツールでは検出できないタイプの脆弱性だ。LLMは開発者が暗黙的にハードコードした「信頼前提」を読み解いて、2FA実装の矛盾を突くことができる。

脆弱性発見手法の比較
従来の自動スキャン(ファジング・静的解析)
  • メモリ破損や入力値不備の検出に強い
  • 開発者の「暗黙の信頼」に気づけない
  • 大規模コードベースでは誤検知が多い
LLM(大規模言語モデル)による発見
  • コードの文脈を読み取り、意図と実装の矛盾を特定
  • 2FAバイパスのような高次ロジックの欠陥を検出可能
  • 人間のセキュリティ研究者に近い推論を実現

この能力差が、従来の防御策では防ぎきれない新たな脅威を生み出している。報告書は、攻撃者がAIを「専門家レベルの増幅器」として活用し始めたと警告する。

防御回避を自動化するAI生成のデコイコード

GTIGは、ロシアに関連するとみられる侵入活動の中で、AIが生成したデコイ(囮)コードを大量に含むマルウェア「CANFAIL」と「LONGSTREAM」を確認した。CANFAILのソースには「このコードブロックは使用されない」といったLLM特有の解説コメントが含まれており、攻撃者が意図的に無害に見せかけるためのダミー機能を要求した形跡がある。

LONGSTREAMでは、システムのサマータイム設定を32回も照会するといった、意味のない繰り返し処理が組み込まれていた。これらは振る舞い検知をかく乱し、セキュリティ製品による分析を遅らせる目的がある。AIが難読化ツールとして悪用され、マルウェアが動的に自己変形する方向へ進んでいることを示す事例だ。

PROMPTSPYにみる自律型マルウェアの脅威

Androidバックドア「PROMPTSPY」は、AIを攻撃の中核に据えた自律型マルウェアとして注目されている。ESETが初めて報告したこのマルウェアは、Gemini APIを用いて端末の画面情報を取得し、ユーザーの操作を必要とせずに不正なタップやスワイプを実行する。GTIGの追加分析によって、当初知られていた以上の拡張性と防御機能を持つことが判明した。

PROMPTSPYの自律攻撃フロー
1. 端末情報を収集
Accessibility APIで画面のUI階層をXML形式で取得
2. LLMに送信
Gemini APIにXMLを送り、動的に生成された目標に沿った操作を指示
3. 結果を受け取り実行
JSONで戻された座標とアクション種別(CLICK、SWIPE)をもとにジェスチャーをシミュレート
4. 防御機能
アンインストールボタンに透明オーバーレイを被せてタップを無効化。FCMで遠隔再起動も可能

また、PROMPTSPYは被害者の生体認証(PINやパターン)を記録して再現する機能を持ち、遠隔からデバイスへの再侵入を可能にする。C2サーバやAPIキーを動的に切り替える仕組みも備えており、防御側のブロックを回避する設計思想が随所に見られる。Googleは既に関連アカウントを無効化し、Google Play Protectで既知の亜種を自動検出できるようにしている。

AIを利用した情報工作とLLMへの大規模アクセス

情報工作の領域でもAIの悪用は進んでいる。親ロシアキャンペーン「Operation Overload」では、AIで合成された音声を使って実在のジャーナリストを装う偽動画が拡散された。こうしたコンテンツは、正規メディアの信用を乗っ取る手口として使われる。

一方で、攻撃者はLLMのプレミアム機能を不正に利用するため、アカウント登録と即時解約を自動化するスクリプトや、複数アカウントを束ねる中継サービスを駆使している。UNC6201やUNC5673といった中国関連の攻撃グループは、こうした手法で大量のAPIアクセスを確保し、不正利用の痕跡を分散させていた。LLM提供事業者は、ネットワーク情報を分析してアグリゲーターを特定し、悪用を阻止する対策を強化しつつある。

AI自身が標的に サプライチェーン攻撃の実態

AI自身が標的に サプライチェーン攻撃の実態

AIモデルそのものは依然として直接の侵害には強いが、モデルを動かす周辺のソフトウェア部品(ライブラリ、APIコネクタ、スキル設定ファイル)が新たな侵入口になっている。GTIGはこの状況を、SAIF(Secure AI Framework)のリスク分類でいう「安全でない統合コンポーネント(IIC)」と「不正な動作(RA)」に該当すると指摘する。

オープンソースのAIエコシステムが狙われる

2026年2月には、AIエージェントプラットフォーム「OpenClaw」のスキルマーケットプレイスに、悪意あるコードを仕込んだパッケージが流通していることがVirusTotalの調査で明らかになった。OpenClawは実行に高い権限を必要とするため、トロイの木馬化されたスキルをインストールしたユーザーの環境で任意のコードが実行される恐れがある。その後、OpenClawはClawHubにVirusTotalの自動スキャンを統合し、悪意あるパッケージを検出する仕組みを導入した。

TeamPCPによるLiteLLMやGitHubリポジトリへの侵害

犯罪グループ「TeamPCP(UNC6780)」は、2026年3月に複数のGitHubリポジトリをサプライチェーン攻撃で侵害したことを公言した。標的には、複数のLLMプロバイダを統合するAIゲートウェイ「LiteLLM」や、脆弱性スキャナ「Trivy」「Checkmarx」などが含まれている。被害組織のビルド環境からはAWSキーやGitHubトークンといったクラウド認証情報が窃取され、ランサムウェアグループとの連携によって金銭目的の恐喝に利用された。

この事例が示すのは、AI関連の依存関係が侵害された場合、攻撃者は単にAIシステムを操作するだけでなく、そこから企業ネットワーク全体へ横展開できるというリスクだ。LiteLLMのような広く使われるライブラリを経由して、多数の組織のAI APIシークレットが流出する可能性がある。

企業に求められるAI脅威への対策

企業に求められるAI脅威への対策

Googleは自社の防御策として、Geminiの悪用アカウントの無効化、AIエージェント「Big Sleep」による未知の脆弱性探索、そして「CodeMender」による脆弱性の自動修正など、AIを守りに使う取り組みを進めている。同時に、業界全体での対策フレームワークとしてSAIFを提唱し、CoSAI(Coalition for Secure AI)を通じてパートナーとの連携を強化している。

実務者が今すぐ着手できる対策としては、以下の点が重要だ。まず、AI関連のオープンソースライブラリやスキルパッケージを導入する際には、提供元の信頼性とコードの挙動を必ず確認する。APIキーやクラウド認証情報は短い有効期限と最小権限で管理し、定期的にローテーションする。さらに、AIを利用するアカウントには多要素認証を適用し、不審なAPI呼び出しを検知する監視体制を整えることが有効だ。

この記事のポイント

  • GTIGが2026年5月に発表した報告で、AIによるゼロデイエクスプロイト開発が初確認された
  • 攻撃者はAIを使ってマルウェアの難読化や自律的な操作を実現し、攻撃の効率を飛躍的に高めている
  • PROMPTSPYのような自律型マルウェアは、人間の介在なしに端末を操作し、防御を回避する仕組みを備える
  • AIエコシステムを狙ったサプライチェーン攻撃が急増し、APIキーや認証情報の大量窃取が現実の脅威となっている
  • 企業はAI関連の依存コンポーネントの厳格な管理と、APIアクセスの監視強化でリスクを軽減すべき