技術者ブログ

AIエージェントによる攻撃を観測しました

皆様おそらくご存知のとおり、2026年9月頃からウェブサイトやウェブアプリケーションで立て続けに情報漏洩が報告されています。マクニカさんやJPCERT/CCから情報が出されています。

Scutumでは10月10日の夜より、これらの攻撃がAIエージェントによるものなのかを調べる仕組みを導入し、監視を実施しました。その結果、10月14日までに、少なくとも3つのIPアドレスからAIエージェントによる日本の企業のウェブサイトへの攻撃が実施されていることを確認しました。

AIエージェントによる攻撃を特定する手法

どのように「攻撃元がAIエージェントかどうかを見分けるのか」については公表してしまうと対策されてしまうため詳細についてはここではご説明できません。この点については申し訳ありません。

基本的には以下を踏まえ開発された手法です。

• AIエージェントはcurlやsqlmap、あるいは自身が生成したPython等のコードを使って攻撃してくる
• その際、それらの具体的なプロセスが実行された結果や出力(ウェブサーバ側の反応)を読み取り、必要に応じて次のアクションを軌道修正する
• AIエージェントは賢く柔軟性がある
• AIエージェントは目的を達成しようとする強いモチベーションがある
• AIエージェントの判断は速い

これらの点を逆手に取り、従来(AI以前)の「シンプルに決められたリクエストを単に連続して送ってくるタイプ」の攻撃ツールや単純にcurlやsqlmapを実行するだけの場合とは異なる流れが発生するよう、WAFの挙動を変更しました。

本番に投入する前に、手元の開発環境でこの仕組みでAIエージェントを検出できるかを確認したところ、試した8種類のモデルすべて（どれも最近リリースされた高性能のもの。Qwen 3.8 Flash NextやGLM-5.3 Flash Nextを含む)でうまく検出できました。モデルが賢いほど、今回の仕掛けはうまく動作するようになっています。攻撃者が実際に使っているモデルが何なのかという情報は取得できませんが、今回の仕組みが検知した場合、攻撃者がAIエージェントを使っていることは断定できる(false negativeはあるかもしれないが、false positiveはほぼない)ロジックになっています。つまり「漏れなくAIエージェントを列挙することはできないが、もし検知した場合は間違いなくAIエージェントである」という性質の仕組みです。

IPアドレス

具体的に検出されたIPアドレスは以下の3つです。

• 38.54.56[.]121
• 185.196.220[.]130
• 192.236.229[.]229

これらのIPアドレスは、WAFによる検知時点で攻撃元として利用されていたものですが、正規の通信で利用されている可能性もあることにご注意ください。

これらのIPアドレスから行われていた攻撃はそれぞれ次のような内容でした。

38.54.56[.]121

/.well-known/security.txt、 /admin/index.html、 /.git

などのファイルやディレクトリの存在を探す、多くが404になるアクセスの連続（1000件程度）。これに続いて、別のツールに切り替えたり、異なる攻撃の段階へと変わった様子はありませんでした。つまりAIエージェントを使ってはいるが、実際に発生していたのは非常に古くからあるタイプの、大量のスキャンのみでした。

185.196.220[.]130

こちらは複数のツールを切り替えて段階的に攻撃が変化していく、AIエージェントで典型と見られる攻撃でした。

フェーズ	相対時刻	件数(約)	内容	使用されたUser-Agent
1 スキャン第1波	T+0:00 〜 T+14:18	330	トップ、robots.txt、sitemap.xml への疎通確認後、/ のパラメータに XSS、UNION SELECT … SLEEP(5)、../../etc/passwd、.git、.env、.hg、phpmyadmin等のスキャン、約30秒で約90種の管理画面やバックアップファイルのスキャン	curl/8.5.0、Fuzz Faster U Fool v2.1.0-dev、Chrome/120 のほか Googlebot、iPhone Safari、Chrome/126、Chrome/78、curl/8.0 等 10 種を混ぜたランダム
2 スキャン第2波	T+35:47 〜 T+39:25	70	特徴的なRangeヘッダ付きのスキャン。ステータスコード206が見られる。/.git/HEAD等へのアクセス	...Chrome/120.0.0.0 Safari/537.36、curl/8.5.0
3 スキャン第3波	T+44:46 〜 T+1:02:52	800	毎分約44件で数百の存在するディレクトリに .git/HEAD、.env、.env.bak、backup.zip、db_backup.sql、.htaccess、web.config等を組み合わせた約 800 パスの網羅スキャン。大小文字、エンコード、クエリ付加などのパターンが混在	curl/8.5.0、Fuzz Faster U Fool v2.1.0-dev
4 スキャン、SQLインジェクション	T+1:30:46 〜 T+1:34:26	30	.git/HEAD、.env、backup.zip、BackupFiles、wp-admin、phpinfo.php等のスキャン。末尾にシングルクォートの付加などもあり	curl/8.5.0
5 問い合わせフォームの連投	T+1:39:30 〜 T+2:23:31	210	存在する問い合わせフォームに正規の流れに沿って自動化されたPOSTを連続で試行。XSSやSQLインジェクションも混在	curl/8.5.0

192.236.229[.]229

こちらでは長時間(8時間弱)にわたって多くのツールを切り替えて攻撃が実施されていました。

フェーズ	相対時刻	件数(約)	内容	使用されたUser-Agent
1 低速スキャン	T+0:00 〜 T+0:23	50	トップやログイン画面へのアクセス、XSS／SQLi／パストラバーサル混入、Bitrix、WordPress、SharePoint、Axis2、Struts等の既知の脆弱性	Chrome/140、129に存在しないOS名「SS」を組み合わせたもの、Firefox 130、python-requests/2.32.3等、35種類程度のランダム
2 高速スキャン 第1波	T+0:50 〜 T+0:55	10000	毎分約2,100件（毎秒約35件）で大量のファイルをスキャン。404を連発する	...Chrome/87.0.4280.88 Safari/537.36のみ
3 高速スキャン 第2波	T+0:58 〜 T+1:00	1200	大量の404が発生する、上の行に似たスキャン	Chrome/87固定ではなくなり、Safari/Firefox等で数十種のランダム
4 既知の脆弱性への攻撃	T+1:15 〜 T+1:24	850	Elasticsearch（PUT /_snapshot/、POST /_search）、Consul、Facelets/JSF等、非常に多数	Firefox 78/125/141、マイナーなUA（ConnectPC等）、OS欄がDebian/Knoppix等のパターンのランダム
5 Nmap	T+3:18 〜 T+3:21	15	HEAD、PROPFIND、OPTIONS等	Nmap Scripting Engine、curl/8.14.1、AnyConnect等
6 フォームへのアクセス	T+4:43 〜 T+4:58	20	ヘッドレスブラウザによるパスワード再設定フォームや新規登録フォームなど正規の機能へのアクセス	...Chrome/124.0.0.0 Safari/537.36
7 WebLogicのスキャン	T+5:01 〜 T+5:03	15	少数のWebLogic特有のURLへのスキャン	Mozilla/5.0
8 ログイン総当り	T+5:08 〜 T+5:41	250	ログイン画面へのGETとログイン試行のPOSTの繰り返し	Mozilla/5.0 (Windows NT 10.0; Win64; x64)
9 既知の脆弱性への攻撃	T+6:03 〜 T+6:41	40	Struts（/*.do）、/WEB-INF/web.xml、F5 BIG-IP、GraphQL等既知の脆弱性の少数のスキャン	...Chrome/124.0.0.0 Safari/537.36、curl/8.14.1
10 トップページやフォームへのアクセス	T+7:01 〜 T+7:46	10	トップページやログインのフォームなどに少数のHEAD、GET、POSTでのアクセス	curl/8.14.1、Mozilla/5.0

3つのIPはそれぞれ特徴が異なる攻撃をしており、別のアクターである可能性があるように思えます。また、大きな被害を出しているA2B攻撃で見られるような「User-Agentにスマホアプリの文字列が入っている」ケースは、これら3つのIPからの攻撃においては見られませんでした。

対策をどうするべきか

ウェブアプリケーションやウェブサイトにおけるセキュリティ対策は、攻撃者がAIエージェントを使っているかどうかによって大きく変わることはありません。事前に漏れなく(アプリケーションのバックエンドのAPIなども含めて)脆弱性がない状態にする。必要に応じてScutumのようなシグネチャのみに依存しない、分類の性能がよいWAFを導入することが有効です。株式会社セキュアスカイ・テクノロジーでは今回の一連の攻撃を踏まえこちらの実践ガイドを公開しておりますので、ぜひ参考にしてください。

また、筆者は2026年10月23日のSecurityDays 2026秋（東京）でAI時代のWAF論について講演させていただきますので、興味がある方はぜひ参加いただければと思います。

今後のウェブセキュリティ

「AIエージェントが日本のウェブサイトへの攻撃に使われているかどうか」を議論する段階は終わりました。AIエージェントを開発や脆弱性診断に利用している人からすれば当たり前の感覚ですが、「AIエージェントはあまりにも便利で優秀なので、攻撃者が使わないわけがない」と言えるでしょう。今後はほぼすべての攻撃者がAIエージェントを使うようになると推測できます。そのときの対策は前項に書いたように大きくは変わりませんが、個人的には現在のScutumを、よりAIエージェント駆動の攻撃に合わせてチューニングしていきたいと考えているところです。また何か新しいことがわかったら、このブログでお伝えしたいと思います。この記事についてのご指摘や感想などありましたら@kinyukaまで。