6時間で数千件。攻撃側がAIに手綱を渡した日、防御側の持ち時間が消えた

まず初めに

セキュリティの世界には、長らく暗黙の前提があった。攻撃には人手がかかる、という前提だ。標的を調べ、侵入経路を探し、失敗したらやり直す。どれも人間の時間を食う。だから防御側にも、気づいて動くための猶予があった。

その猶予が、いま削られている。攻撃者が自分で手を動かすのをやめて、手順ごとAIに預け始めたからだ。人間が休んでいる間も作業は進む。夜中も、休日も、こちらが会議をしている間も。

働き方改革の恩恵を、まず攻撃側が受け取った。皮肉な話である。※個人の感想です

「6時間未満で数千件」が意味すること

報告で挙げられた事例のうち、数字として明確なのが「6時間未満で数千件の認証情報が侵害された」というものです。

認証情報とは、利用者を確認するための情報です。IDとパスワードの組み合わせが代表的ですが、サービスへのアクセスに使う鍵情報も含まれます。これが第三者の手に渡ると、その人になりすましてサービスを使われる恐れがあります。

ここで注目すべきは件数そのものより、時間との組み合わせです。数千件という規模だけなら、過去にも例があります。しかし6時間未満という速度は、防御側の対応の前提を変えます。

一般的な組織の対応を考えてみてください。異常を検知する。担当者が確認する。上長へ報告する。影響範囲を調べる。関係先へ連絡する。この一連の流れは、多くの組織で数時間から数日かかります。攻撃が6時間で完了するなら、こちらが最初の会議を終える頃には、すでに終わっているということです。

エージェント型への移行とは何か

報告は、先進的な攻撃者が「基本的なプロンプトの利用」から「エージェント型のAIワークフローやAIを活用した自動化」へ移行していると指摘しています。

これまでのAI悪用は、多くが道具としての利用でした。攻撃者が自分で考え、AIに文章を書かせたり、コードの一部を作らせたりする。判断は人間が握っていました。

エージェント型では、この関係が変わります。目的を与えると、AIが手順を分解し、順に実行し、結果を見て次を決めます。人間は最初と最後にだけ関わります。

攻撃の文脈でこの違いが効いてくるのは、試行回数と速度です。人間が一つずつ試していた作業を、AIが並行して大量に回せるようになります。失敗しても人間の疲労は蓄積しません。夜間も稼働します。

同時に、報告が指摘するのは「人間が介入する時間の短縮」です。攻撃が速くなるということは、防御側が対応に使える時間が削られるということでもあります。この二つは同じ現象の表と裏です。

ソフトウェアのサプライチェーンが標的になる

報告でもう一つ挙げられているのが、ソフトウェアのサプライチェーンへの攻撃の増加です。ここにはAIコーディングアシスタントやオープンソース部品が含まれます。

サプライチェーンとは、ソフトウェアが作られて利用者に届くまでの一連の流れです。現代のソフトウェアは、ゼロから書かれることはほとんどありません。公開されている部品を組み合わせ、開発を支援する道具を使い、自動化された仕組みで配布されます。

攻撃者から見ると、完成した製品を一つずつ攻めるより、その手前の工程に入り込むほうが効率が良いという発想が成り立ちます。多くの製品が同じ部品を使っているなら、その部品を汚染すれば影響は広がります。

AIコーディングアシスタントが名指しされている点も重要です。開発を支援する道具は、その性質上、ソースコードや認証情報が集まる場所で動きます。そこが狙われるということは、開発環境そのものが守るべき対象になっているということです。

Googleが示している対応

Googleは、モデルの安全対策、脅威情報の収集、レッドチーム演習を含む多層的な防御に取り組んでいるとしています。レッドチーム演習とは、攻撃側の視点で自社のシステムを試験し、弱点を見つける取り組みです。

また9月2日には、防御側の専門家に向けたAIモデルGemini 3.8 Flash Cyberの提供を開始しています。攻撃側がAIで速くなるなら、防御側もAIで速くする、という方向です。

IT Postの見方――速度が問題なら、速く直せる場所から直す

IT Postでは、この報告から取り出すべき教訓は「AIが怖い」ではなく、「6時間で終わる攻撃に対して、数日かかる対応手順を持っている」という不釣り合いのほうだと考える。

不安をあおる話にしたくないので、はっきり書いておく。攻撃がAIで速くなったからといって、破られる仕組みが根本から変わったわけではない。侵害された数千件の認証情報という表現が示す通り、入口は依然として認証だ。新しい魔法で扉が溶かされたのではなく、鍵の試し方が速くなっただけである。

だとすれば、優先順位ははっきりする。速度で殴られている場所を、速度で直す必要はない。そもそも殴っても開かない扉にすればいい。使い回しのパスワードをやめる。多要素認証を入れる。パスキーに移す。どれも新しい話ではないが、攻撃の自動化が進んだ分だけ、対策を先延ばしにした場合の代償が大きくなっている。

そのうえで、組織にとっての宿題は検知と初動の時間短縮だ。6時間で終わる攻撃に対して、報告の連鎖に半日かける体制のままでは、どれだけ優秀な担当者がいても間に合わない。判断を待たずに実行してよい対応をあらかじめ決めておく。たとえば、認証情報の無効化に上長の承認を要らなくする。それだけでも持ち時間は変わる。

日本の読者にとって、何をすればよいか

個人でできることは、実は多くない。だが効果は大きい。

第一に、パスワードの使い回しをやめる。今回の事例が示すのは、認証情報が大量かつ高速に試される状況だ。一つのサービスで漏れたIDとパスワードの組み合わせを、他のサービスで試す攻撃は以前から存在する。使い回しをやめれば、この連鎖は止まる。パスワード管理ソフトを使えば、覚える必要はない。

第二に、多要素認証を有効にする。メール、金融、SNS、仕事で使うサービス。この順で入れていけば十分だ。パスワードが漏れても、もう一段の確認があれば侵入は難しくなる。

第三に、パスキーに対応しているサービスでは、パスキーへ移行する。パスワードそのものを使わない仕組みなので、盗まれる対象が減る。

企業で働く人は、これに加えて一点。自社が使っている開発ツールや業務ツールの認証情報が、どこに、いくつあるかを把握しているか確認したい。棚卸しされていない鍵は、誰も無効化できない。

よくある疑問

Q. AIを使わなければ、狙われませんか。 そうではありません。報告が指摘しているのは攻撃側のAI利用であり、狙われる側がAIを使っているかどうかとは別の話です。

Q. 6時間で数千件というのは、どこかの企業が被害に遭ったということですか。 報告では、確認された事例として時間と件数が示されています。特定の被害組織を指す情報として本記事で扱える内容はありません。

Q. 個人にできることは本当にありますか。 あります。認証情報が攻撃の入口である以上、使い回しをやめる、多要素認証を入れる、パスキーへ移行するという三つは、攻撃が自動化されても有効です。むしろ自動化が進むほど、使い回しの危険度は上がります。

攻撃側が手綱をAIに渡した以上、こちらも手順を見直す時期に来ている。難しい技術の導入より先に、使い回しのパスワードを一つ減らすほうが効く。地味だが、効くほうを選びたい。