「うちは銀行でも大企業でもないから、まず狙われない」。そう考えていた会社ほど、今回の発表は読み飛ばさないほうがいいと思います。GMOサイバーセキュリティ byイエラエが10月19日に公表した調査では、AIの攻撃ツール「ARTEX」が動いていた攻撃用サーバー1台が日本企業約20社を狙っていました。うち9社は同じ業種のサイトです。同じように日本企業を狙うAI攻撃のサーバーがほかに6台見つかり、狙われていた業種はデジタルギフト、ポイント、教育、印刷、EC、物流などでした。
9月から続く不正アクセスの少なくとも一部は、AIが偵察から攻撃までを肩代わりする形で行われていた、ということです。私の結論は単純で、AI対策の新製品を探すより先に、自社のスマホアプリやWebサービスが外へ見せているAPIと管理機能を点検するべきです。公表された手口を工程ごとに並べると、AIが速くしたのは「アプリの中身を読んで、突けるAPIを見つける」部分だと分かるからです。
ARTEXは、侵入テストの段取りを丸ごとAIに任せるツール
ARTEXは中国の開発者がGitHubで公開していたオープンソースの侵入テスト（ペネトレーションテスト）ツールです。piyologのまとめによると、READMEでは「AI 自主渗透测试系统」と名乗り、Plannerと呼ぶAIが次の作業を決め、Workerが実行して結果を記録する構成でした。調べた資産の関係図、通信を記録するプロキシ、ツール実行を許可・拒否する承認の仕組みまで備えています。AnthropicやOpenAI、その互換APIを持つLLMをつなげて動かします。
経緯も短期間です。2026年7月26日に最初の版が公開され、9月3日には中国の攻防コンテストで優勝しました。悪用が報じられた後、開発者は10月8日にクローズドソース化を表明し、翌9日の時点でリポジトリは見られなくなっています。ただ、それまでに取得されたコードが手元から消えるわけではありません。公開停止で攻撃が止まると考えるのは楽観的だと私は見ています。
実際の悪用は韓国で先に報告されました。CrowdStrikeの10月7日の分析によると、9月下旬から10月上旬にかけて韓国の金融機関が狙われ、攻撃者のARTEXはDeepSeek v4.1-flashを主なLLMとして使い、GLM-5.3やGrok 4.6も補助に使っていました。攻撃者の公開ディレクトリからはClaude Codeのセッション履歴と中国語の侵入テスト用プロンプトも見つかっています。標的として報告されたのは、融資の進み具合を仲介業者が照会するサービスや、社員向けのモバイル業務システムでした。銀行の看板サービスではなく、周辺の業務用サービスが狙われている点に注目してください。
日本で確認された手口は「アプリを読んでAPIを突く」
国内の被害について、JPCERT/CCは10月8日の注意喚起で4つの手口を挙げています。標的ごとに既知の脆弱性を探して設定ファイルを盗む手口、スマホアプリを解析して見つけたAPIを悪用する手口、BIツールMetabaseのSQLインジェクション脆弱性（CVE-2026-72898）を突く手口、アプリケーションサーバーにWebシェルを置く手口です。
AIの関与については、JPCERT/CCが10月15日のブログで、攻撃者がAIを使って既知の脆弱性のスキャンやAPI経由の攻撃をしていたことを確認したと書いています。Androidアプリの配布ファイル（APK）をjadxやBlutterといった解析ツールで読み、アプリが通信しているAPIを特定したうえで、SSRFなどの弱点がないかを調べていた痕跡があったそうです。NICTも10月13日の注意喚起で、この「アプリ解析からのサーバ攻撃」を情報漏えいの原因の一つとして挙げています。
アプリの解析自体は昔からある手口です。変わったのは手間でした。APKを開き、通信先と仕様を読み取り、それに合わせた攻撃を組み立てる作業は、これまで専門知識と時間を要しました。ここをAIが肩代わりすると、攻撃者は1社ずつ丁寧に調べる必要がなくなり、同じ業種の会社を一気に並べて試せます。GMOが見つけた「1台で約20社、うち9社が同業種」という狙い方は、まさにこの形に見えます。
WAFとIP遮断だけでは足りない理由
GMOの前回の記事には、防御側にとって耳の痛い指摘が2つあります。1つは、攻撃者がAIでCVE情報とソースコードを突き合わせ、公式には影響ありと書かれていない版の弱点まで探せること。もう1つは、数百のIPアドレスを切り替えながらアクセスし、WAFのレート制限をすり抜けていたことです。
つまり「怪しいIPを止める」「1つのIPからの回数を制限する」だけでは間に合いません。アプリの中に埋め込んだ鍵で誰でもAPIを呼べる、ログインしていれば他人のデータもIDを変えるだけで取れる、管理用のAPIがインターネットから見える。こうした作りそのものの穴は、入口の装置では塞げないからです。
攻撃の工程ごとに、先に塞ぐ場所
公表された手口を工程に分け、JPCERT/CC、NICT、IPAが挙げた対策を対応づけました。並べ方と優先順位、レート制限の単位などの補足は私の整理です。
| 工程とAIで速くなったこと | 先に塞ぐ場所 |
|---|---|
| 偵察：アプリを解析し、通信先のAPIと仕様を特定する | アプリにAPIの秘密鍵や長期間有効な認証情報を埋め込まない。使っていないAPIを止める |
| 弱点探し：既知の脆弱性や、公式の対象外の版の弱点を探す | 修正パッチの適用。管理機能や管理用APIをインターネットから見えなくする |
| API悪用：他人のIDの指定、インジェクション、SSRFを試す | 認可はサーバー側で毎回確認する。外部URLを取りに行くAPIは接続先を限定する |
| 防御の回避：多数のIPを使い分けて回数制限を逃れる | レート制限をIP単位だけでなくアカウント・トークン単位でもかける。利用地域が限られるなら接続元の地域を絞る |
| 侵入後：Webシェルを置き、内部で活動を広げる | 直近のログとアカウントを確認し、作った覚えのないアカウントや再び有効になったアカウントを探す |
表の上ほど、攻撃者がAIで量をこなしている工程です。上の段を塞ぐほど、下の段まで進まれる確率が下がります。
小さな会社が今週やる順番
専任のセキュリティ担当がいない会社を想定して、手をつける順番を決めました。IPAの10月9日の注意喚起の点検項目を土台に、今回の手口に合わせて並べ替えています。
- 外部から触れるものを一覧にする。Webサイトだけでなく、スマホアプリが通信するAPI、管理画面、委託先が作った予約・照会・ポイントのサービスも含めます。韓国の例のように、目立たない周辺サービスが入口になります。
- アプリ開発の委託先に、配布しているアプリにAPIの秘密鍵、管理用のURL、長期間有効なトークンが含まれていないかを確認してもらう。含まれていれば鍵を作り直し、サーバー側で認証する作りへ移します。
- テスト用のアカウントを2つ作り、片方でログインした状態で、もう片方の会員IDや注文番号を指定して情報が取れないかを検証環境で確かめてもらう。取れてしまうなら、今回の「API悪用」に最も直結する穴です。
- ログを直近1か月分確認し、問題がなければ3か月分に広げる。エラーの急増、深夜の大量アクセス、普段使われないAPIへのアクセスが目安です。IPAも、まず1か月、その後3か月という順番を示しています。
- クラウドやSaaSの管理画面でアカウントを棚卸しする。作った覚えのないアカウント、削除したはずなのに有効なアカウントがないかを見ます。
- 使っていない個人情報を消す。盗まれる前提で、持っている量そのものを減らします。
2と3は、自社でアプリやAPIを持たず、既製のECサービスだけを使っている会社なら飛ばせます。その場合は4と5、特に管理者アカウントの多要素認証を先に固めてください。
点検の途中で異常が見つかったら、慌ててサーバーを作り直したりログを消したりしないことです。証拠が消えると、どこから何が漏れたのか分からなくなります。IPAは10月16日に不正アクセス特別相談窓口を開設しており、企業・組織からの相談を電話（03-6759-5760、平日9時30分〜17時30分、昼休みを除く）とメール（incident-support@ipa.go.jp）で受け付けています。被害の可能性についての助言や、対応できる専門業者の紹介を受けられます。
APIの鍵が漏れたと分かった場合、生成AIのAPIキーなら失効と利用上限の設定が最初の手当てになります。手順はOpenCodeのAPIキー流出で今やることで、OpenAI・Anthropic・Geminiの管理画面ごとにまとめています。
利用者側の被害は、別の手口で広がっている
10月19日には日本郵政の「ゆうID」で249件の会員情報が見られた可能性があると報じられました。報道によると、これは日本郵政のシステムから漏れたのではなく、外部で流出したIDとパスワードの組み合わせを使ったなりすましログインとみられています。ARTEXのようなサーバーへの侵入とは別の手口です。
ただ、この2つはつながっています。どこかのサービスから盗まれた認証情報は、別のサービスへのログインに使い回されます。利用者として自分を守る手段は、サービスごとにパスワードを変えること、パスキーや多要素認証が使えるサービスでは有効にすることです。運営側としては、ログイン失敗の急増や、普段と違う地域・時間帯からのログインを監視の対象に加えておくと、リスト型の攻撃にも早く気づけます。
AIで守る前に、AIに読まれて困るものを減らす
今回の件を受けて「AIによる防御」をうたう製品の案内が増えると思います。それ自体は否定しません。ただ、公表された手口を見る限り、攻撃者のAIが見つけていたのはアプリに残った鍵や、サーバー側で確認していない認可のような、昔からある作りの穴でした。製品を入れても、この穴は残ります。
当サイトは攻撃ツールを動かしておらず、ここに書いた内容はGMO、CrowdStrike、JPCERT/CC、NICT、IPAの公表資料に基づく整理です。それでも、今週中にできることは明確です。自社アプリが通信しているAPIの一覧を委託先に出してもらい、その中に「ログインなしで呼べるもの」と「他人のIDで呼べるもの」がないかを聞いてみてください。答えがすぐ返ってこない場合、そこがいちばん先に塞ぐべき場所です。
コメント