この記事のポイント
- 影響
- GMOイエラエが国内企業を狙った侵害事案の攻撃元でARTEXの使用を確認。観測対象には情報漏えい公表済みの企業が含まれる。国内すべての侵害の原因や使用モデルを確定した報告ではない。
- 推奨対応
- 公開資産の内部台帳との照合、保守終了環境と管理機能の公開範囲の確認、防御機器の適用範囲とログ相関の検証を行う。不審な兆候がある場合は証拠保全と影響抑制を含むインシデント対応を優先する。
- 公表日
目次
GMOサイバーセキュリティ byイエラエは2026年10月19日、日本企業を狙った侵害事案の攻撃元インフラを調査し、AIによる自律型ペネトレーションテストシステム「ARTEX」の使用を確認したと公表しました。従来のログ分析による推定から、攻撃元の調査による裏付けへ進んだ点が今回の新しい情報です。
ただし、国内で相次ぐ情報漏えいがすべてARTEXによるものだと確定したわけではありません。同社は観測できた範囲を限定しています。調査対象で使われたツールの確認、攻撃グループの評価、個々の被害企業の侵入原因は、別々の根拠を必要とします。
本記事の中心となる調査公表日は10月19日、情報確認日は日本時間10月20日です。公表日を攻撃の開始日とは扱いません。国内の新たな調査結果を整理した後、Web開発者・運営者が優先する作業を、本サイトの提案として説明します。
スポンサーリンク
今回確認されたのは攻撃元のツールと標的の傾向
同社の報告によると、最初に調査した攻撃元インフラは、観測範囲ではほぼ日本を標的としていました。調査を広げると、日本企業を主な標的とするAI利用の攻撃インフラをさらに6台発見したとしています。
標的として確認した国内企業のうち、9〜10月に情報漏えいを公表済みの企業が8社あるというのが報告の範囲です。この数字を国内全体の被害件数、侵入の成功率、全標的で情報が盗まれた証拠へ置き換えてはいけません。
GMOサイバーセキュリティ byイエラエ：攻撃元でのARTEX使用確認（2026年10月19日）
ARTEXという名前だけで攻撃者やモデルは決まらない
ARTEXは侵入テストを自動化するエージェント型のツールとして報告されています。AIモデルの名称そのものではなく、外部のモデルや各種の処理を組み合わせて使う仕組みです。正規の検証に使うことと、無断で他社へ攻撃することは区別されます。
CrowdStrikeの10月7日の調査は、9月下旬から10月上旬に韓国の金融機関を狙った活動を扱っています。同社は攻撃元の公開ディレクトリーから、セッション履歴やARTEX設定などを分析しました。特定の名前の攻撃者には帰属しておらず、中国語話者で金銭目的との評価にも確信度を付けています。
これは日本の調査とは別の観測です。韓国側の記録に登場したモデル名を、そのまま国内攻撃の使用モデルとして紹介できません。中国で開発されたツールが使われたことだけから、国家の関与や攻撃者の国籍も確定できません。
CrowdStrike：韓国金融機関を狙ったARTEX関連の調査（2026年10月7日）
スポンサーリンク
AIの関与が分かっても個別の侵入原因は別途調べる
GMOイエラエは、韓国と同じ手口で日本企業も攻撃されている可能性に言及しています。しかし、その見立てと、すべての事案で同じ脆弱性を使ったという結論は異なります。自社の事故を調べる場合は、入口、実行権限、閲覧されたデータ、外部送信の有無を個別に確認する必要があります。
JPCERT/CCの10月8日公開・9日更新の注意喚起も、技術情報が限定的・断片的であると明記し、すべての事案で同一手法が使われたことを示すものではないとしています。この文書だけを、国内のすべての侵害がAI攻撃だったという証拠にはできません。
調査報告を社内へ共有するときは、「調査会社が確認した事実」「調査会社の評価」「自社で未確認のこと」を分けることを提案します。ニュースに登場したツール名を、原因欄の仮の答えとして先に埋めないことが重要です。
JPCERT/CC：国内組織における不正アクセスの注意喚起（10月8日公開・9日更新）
防御側が見直すべきなのは確認できていない空白
GMOイエラエの前回資料は、CVE情報だけに頼る管理、外部からの資産確認、WAFなどの防御機器に関する盲点を挙げています。URLには10月14日という数字が含まれますが、ページ上の公開日・更新日は10月15日です。本記事ではページに表示された日付を採用します。
同資料は、サポート終了版では影響調査や修正情報が十分に出ない場合があること、外部調査だけでは版が判別できないこと、WAFがあっても更新が不要になるわけではないことを指摘しています。これらは特定企業一社の原因を断定した説明ではありません。
GMOサイバーセキュリティ byイエラエ：不正アクセスに備える3つのポイント（ページ表記10月15日）
スポンサーリンク
第一に外部からの見え方と内部の台帳を照合する
ここからは本サイトの提案です。まず、公開中のドメイン、サブドメイン、API、管理機能、委託先の環境を確認し、それぞれの所有者と実装を社内の台帳へ対応付けます。外から製品の版が見えないものを、そのまま安全と分類しないでください。
例えば、外部診断が「製品不明」とした検証サイトについて、社内では古いCMSだと把握している場合があります。外部の結果と、構成管理・配布記録・契約情報を合わせることで、公開範囲と保守状態の両方を判断できます。これは説明用の仮想例で、今回確認された被害構成ではありません。
優先するのは、担当者不明、保守終了、管理機能の公開、機微情報への接続が重なる場所です。全資産を同じ順番で更新するのではなく、到達可能性、扱う情報、権限、代替策を組み合わせて着手順を決めます。
第二に更新できない環境の継続条件を決める
CVEに自社の版が明記されていないことと、影響がないと評価されたことは別です。ベンダーのサポート情報を確認し、版が古くて評価対象外なのか、調査済みで対象外なのか、まだ判断できないのかを区別します。
すぐ更新できない場合は、その理由、担当者、次の判断期限、暫定措置を記録します。不要機能の停止、管理経路の限定、接続権限の縮小などを構成に合わせて検討し、暫定措置を適用したことだけで脆弱性の修正済みとは扱いません。
CVSSや悪用確認は重要な材料ですが、単独で自社の順番を決めるものではありません。情報が足りない環境ほど、低リスクと決めつけず調査担当を置きます。逆に、AIが関与したという理由だけで、影響条件を調べずすべてを最優先にすると実作業が進みません。
第三にWAFの有無ではなく防御の範囲を確かめる
GMOイエラエは前回資料で、複数の送信元を使って制限を避ける動きなどを報告しています。ここから得られる実務上の論点は、単一のIPアドレスの回数だけで、対象機能への全体的な不審活動を説明しきれるかということです。
本サイトでは、WAF、認証、アプリケーションの各ログを、対象機能や時刻、利用者の文脈で照合することを提案します。送信元が異なっても、同じ管理操作の失敗や通常使わない機能への要求が続く場合は、関連を確認できる状態にします。
ただし、共通点が一つあるだけで同一攻撃者とは判定できません。共有回線や正規の自動処理もあります。特定のUser-Agentや過去のIPを一括で永久拒否するだけに頼らず、どの条件で検知し、誰が例外を判断するかを運用へ落とし込みます。
防御機器の外にある経路も確認する
WAFを通しているはずのサイトでも、別のホスト名や直接接続できる配信元が、同じ機能へ到達する経路として残っていないかを確認します。これは今回の全事案に共通する侵入経路を示したものではなく、防御の適用範囲を検証するための提案です。
業務上不要な管理機能の公開は、設定を変えた後に外部から許可外の接続が拒否されることまで確認します。正規の連携や監視が必要な場合は、認証と権限を残したうえで接続範囲を設計し、見えなくするだけで安全としないでください。
制限によって業務を止める可能性もあるため、所有者と変更内容、検証結果、切り戻し条件を共有します。急な対策ほど、変更前の状況と実施内容が記録に残っていることが、後の原因調査にも役立ちます。
スポンサーリンク
不審な兆候がある場合は更新と侵害調査を分ける
すでに不明な管理者、設定変更、見慣れない処理や送信がある場合は、修正パッチの適用だけで対応を完了しないでください。影響の抑制と証拠の保全を、組織の手順に従って並行して進めます。攻撃者のサーバーへ自分でアクセスして調査する必要はありません。
ログの保存先、保存期間、時刻のずれ、参照できる担当者を確認します。要求本文やトークンを無制限に記録すると、ログ自体が秘密情報の集積場所になるため、必要な追跡情報と保護方法を選びます。調査のために本番の個人情報を外部AIへ投入することも避けます。
資格情報の漏えいが疑われる場合は、失効や差し替えの対象と業務影響を確認します。入口を閉じたことと、追加された権限や残存する接続が消えたことは別の確認事項です。判断できない範囲を無被害と書かず、記録不足として引き継いでください。
検証の合格条件を作業前に決める
対応の確認では、「設定を変えた」「検査を一回実施した」ではなく、何が拒否され、何が継続できるかを合格条件にします。許可されたテスト環境で、管理経路の到達制限、認証失敗時の処理、権限外の操作、失効後のアクセスを確認します。
正規利用の検証も必要です。制限を強めた結果、問い合わせ送信や外部連携が失敗していないか、アラートが通知されるか、夜間でも担当者へ引き継げるかを調べます。本番データの一括取得や攻撃ツールの無断実行を、安全確認の代わりにしてはいけません。
AIを防御に使う場合も、ログ整理や確認項目の作成を補助させることと、遮断や権限変更を無審査で実行させることは分けます。調査結果の要約は元の記録と照合し、推定が確定情報へ変わっていないかを人が確認します。
スポンサーリンク
今回のニュースを対応につなげる
今回新たに公表されたのは、国内の攻撃元調査でARTEXの使用が裏付けられたことです。AI攻撃という呼び名だけを追うより、自社の公開資産、保守できない箇所、防御が届いていない経路、異常時に取り出せる記録を具体化する方が行動につながります。
まず所有者不明の公開資産と保守終了環境を確認し、次に管理機能と資格情報の範囲、最後に検知から初動までを点検することを提案します。すでに侵害の兆候がある場合は、この通常の改善順ではなくインシデント対応を優先してください。
今後の調査で標的や手法の評価が変わる可能性があります。本記事は10月20日に確認できた資料の整理であり、個別企業の事故原因や攻撃者を独自に特定したものではありません。追加情報は各調査元の公式発表を確認してください。
出典・一次情報
本記事は以下の公開情報をもとに作成しています。最新の状況は各リンク先で確認してください。
