「なぜ正規アカウントが奪われたのかまでは分からない」の原因 〜フィッシング？ ClickFix？〜：「個人向けのセキュリティ対策」を従業員にも

2025年11月26日開催の「ITmedia Security Week 2025 秋」で、ポッドキャスト「セキュリティのアレ」を主宰するセキュリティリサーチャーの3人が「認証認可唯我独尊 第参章」と題して講演した。

[宮田健，＠IT]

　SBテクノロジーの辻伸弘氏、脅威情報分析チームLETTICEのpiyokango氏、インターネットイニシアティブの根岸征史氏の3人にとっては今回で3回目の「認証認可」に関わるセッションだが、口をそろえるのは「まだまだ語り尽くせない」という事実だ。サイバーセキュリティの根幹を成す普遍的な課題ながら、見過ごされる場合もまだ多いトピックだ。今回の「参」という数字は、この領域における脅威が決して過去のものではなく、むしろ形を変えながら進化し続けている現実を物語っている。

• 第壱章：InfoStealerにクッキーを盗まれるとログイン不要の正規侵入が起こる――「セキュリティのアレ」の3人が明かす、認証認可を狙う新たな手口の現状とは：ITmedia Security Week 2025 春
• 第弐章：誰とも代わることのできない“唯我独尊”であるが故に――「セキュリティのアレ」の3人は認証認可をどう見るか：ITmedia Security Week 2024 夏

　各リサーチャーが、特に注目すべき事例や数字を追いかける内容となった講演の内容を要約する。

左からSBテクノロジーの辻伸弘氏、脅威情報分析チームLETTICEのpiyokango氏、インターネットイニシアティブの根岸征史氏

海外含め、なぜ正規アカウントが奪われたのかまでは「分からない」が多数

　まず、認証認可を悪用された事例を取り上げ、その原因にスポットライトを当てるという。その目的は、事象の表面をなぞることではなく「原因」という深層にまで潜り、その構造を白日の下にさらすことにある。

　それに従い、まずはpiyokango氏が最近の事例を数値でまとめ、2025年に公表された事案を、振り返りを含めてまとめた表を提示する。piyokango氏がまとめた日本国内で公表済みのインシデント件数は約900件。そのうち、“原因が記されたもの”のみにフォーカスを当てる。複数の組織で報告されているインシデントなどを除くと、そのうちの83件が、今回のテーマでもある認証認可を悪用された事例だ。

（講演資料から引用）

　piyokango氏は集計していく上で一つの特徴を見つけたという。認証認可に関連するインシデント公表内容は「管理者のアカウントを悪用された」「不正ログイン被害に遭った」といった記載が中心となるが、「では、その管理者アカウントはなぜ奪われたのかという、非常に気になるところの記載は数える程度しかない」（piyokango氏）。その多くは「悪用された」「悪用の可能性があった」という推定にとどまっている。

　続けて、この83件の内容をpiyokango氏は精査していく。悪用に至る“いきさつ”の内訳では、最も多いのが「リスト型攻撃」だった。2025年夏から秋にかけて発生した、特定のサービスを利用している組織がリスト型攻撃の被害に遭い、サービスを利用する複数の組織から公表されていた。この事例を除けば「やはり原因が書かれていない、あるいは特定できていないことが突出している」と指摘する。認証情報が悪用されているが、多くの組織で“真の原因”が明らかになっていないことが分かる。

　「認証認可を悪用するという動きがあることは見て取れる。しかし、対策を考えるに当たって『では、どうしたらいいのか』にまでつながりづらい状況にあるのが、2025年の現状をまとめて見えてきたことだ」（piyokango氏）

　根岸氏は、海外でも同様の傾向があり、認証情報の悪用が原因の上位にあることを指摘する（第弐章参照）。正規アカウントを使った攻撃が、米国政府機関を対象とした調査でも原因として大きく取り上げられていたものの、「なぜ正規アカウントが奪われたのかまでは分からないのが問題だ」と根岸氏。「調べたけど分かりません」「調べようがない」といったことはあるかもしれないが、それがはっきりしないことには、根本的な対策ができない。「どういう教訓を得ればいいのか」が分かりにくいことが問題だ。

　辻氏は「悪用に至る“いきさつ”の内訳」のうち、フィッシングがわずか1件だったことに言及する。「フィッシングなら原因調査もしやすいのではないか」と推察するが、これが原因とされる報告が少なく、辻氏は「企業に来るフィッシング攻撃はあまり注目されていないのではないか？」とも考える。

　「自分の肌感覚では、個人だけでなくMicrosoft 365やGoogleアカウントのような、グローバルで使われているクラウドに対しても、フィッシングが行われているというイメージが強い」と指摘。海外のベンダーによるグローバルのレポートでは報告も多く、「1件という数字に惑わされ、足をすくわれないようにしてほしい」と強調する。

認証認可情報はどう奪われるのか？　フィッシング・ClickFix対策の本質

　第壱章、第弐章では認証認可が奪われた“後”の被害をどう防ぐかという話をしてきた3人だが、今回はスタート地点に立ち返り、改めて入り口部分を考えていく。辻氏は、認証認可を奪われる攻撃の入り口になり得る2つの事例を紹介する。

　1つ目は「フィッシング」だ。フィッシングとは何かという点に加え、今回辻氏はその独自視点の分類を紹介する。ここでは、本物のサイトの見た目やページ遷移を模倣する「通常のフィッシング」、それに加えて攻撃者がリアルタイムに入力を監視し、その裏で本物のサイトへの入力を行って多要素認証も突破する「リアルタイムフィッシング」、ユーザーと本物のサイトの間に入り込み、本物のサイトとの通信を中継してプロキシのようにシステム化した「AitM」（Adversary in the middle）をピックアップする。

（講演資料から引用）

　多くの場合、フィッシングの分類を意識することは少ない。しかし、国内証券会社のインシデントでは、当初は通常のフィッシングによる“なりすまし”被害が報告されたが、対策が進むことでリアルタイムフィッシングに移行していった。AitMも、既にオープンソースでツールが出ている。その現状を踏まえると「これはリアルな脅威。フィッシングの分類や違いをちゃんと認識しておかないと、組織に何が必要か、今の対策がどの攻撃をカバーできているのかが分からない」と根岸氏は警鐘を鳴らす。辻氏も「ベンダーに『これは大丈夫か？』と聞くためにも、この分類を活用してほしい」とした。

　特に注目したいのが「AitM」だ。フィッシングサイトが正規のサイトのプロキシのように動作することで、IDとパスワードが攻撃者にわたり、被害者は正規のサイトへのログインを許してしまう。二要素認証が完了した後、自分が誰かを証明した後に首から提げる通行証のようなもの、つまり「認可」がクッキーとして利用者に渡されるが、プロキシとして動いているフィッシングサイトを通じ、攻撃者にも認可情報が渡ってしまう。攻撃者はIDとパスワードがなくても「認可」としての通行証を持っているので、不正にサービスを利用できる状態になる。

（講演資料から引用）

　辻氏が紹介する2つ目の事例は「ClickFix」だ。「攻撃者がメールやメッセージでアクティブに連絡する」「正規のサイトを改ざんしてスクリプトによって悪意あるサイトにリダイレクトする」といった方法がある。その先で、巧妙な文言で被害者が自ら、悪意あるスクリプトをダウンロードし、実行させるというものだ。

（講演資料から引用）

　ユーザーがClickFixのサイトに入った段階で、実は悪意あるコマンドがコピーされてクリップボード上にひそかに入り込んでいる。わざわざクリップボードの中身を確認することはほとんどないので、攻撃に気が付けない。

　この対策の一つに、「Windows」キー＋「R」キーによるコマンドボックスの表示を制限することがあるが、攻撃者はさらにその上をいく。「FileFix」という攻撃では、同様の作業を、OSに備わるファイルの「エクスプローラー」を使って行う。普段の業務でも使うエクスプローラーを制限するわけにもいかないので、対策が難しい。

　辻氏は「対策が進んだことで、マルウェアが添付されたメールや、パスワード付きZipファイルなどはその多くがブロックできるようになり、外部から取得したMicrosoft Office文書のマクロについてもデフォルトでブロックされるようになった。しかし、ClickFix／FileFixはユーザーに直接届きやすく、Office系文書のマクロから呼ばれるPowerShell]といった明らかな異常とも言えるプロセスツリーとは異なり、ユーザーが自ら実行しているためそのPowerShellがエクスプローラーのプロセスツリーに入り、区別がつきにくい」と指摘する。

　さらに「合わせ技として、サポート詐欺とClickFixを組み合わせた事例もある」と辻氏。サポート詐欺として電話をかけ、そこから直接ClickFixサイトに誘導されるなど「さまざまなバリエーションに応用できる」ことに注意を促した。

認証情報の漏えい検知は「難しいものだ」という前提で、改めて確認する

　根岸氏はここまでの議論を踏まえ、認証情報の窃取と悪用を防ぐための対策を、2つの観点で紹介する。1つ目は、認証情報を取られないようにする直接的な対策だ。

　根岸氏は「まずは典型的なフィッシングと、巧妙なClickFix／FileFixを考える必要がある」と指摘する。多要素認証すらも突破される今、フィッシング耐性のあるパスキーやセキュリティキーなどを利用し、パスワードマネジャーを導入するなども検討する。「特にパスワードマネジャーが組織での導入がまだ進んでいない点には課題がある」と、3人は口をそろえる。

　個人向けのセキュリティ対策としてよく指摘される「公式アプリを活用する」「ブックマークからクリックする」といった方法もある。相手の誘いに乗らない手法が組織でも有効であり、これを従業員に徹底する。ソーシャルエンジニアリング対策の再認識、PowerShellの停止や、PCのマルウェア感染対策、ブラウザによるアカウント同士の連携の禁止なども重要だ。

　2つ目は、“真の原因”の特定に必要な対策だ。“いきさつ”が分からない、または特定できないことを問題視し、「原因が追えないと、同じことがまた繰り返されてしまう。まだ事件が起きていない組織は、認証認可情報の悪用が起きたときに、どこから漏れたか特定・追跡する方法としてログが残っているかどうかを確認する。例えばエンドポイントから漏れているなら「それをEDR（Endpoint Detection and Response）で捕捉できる」と自信を持って言えるかどうかを改めて考えてほしい」と呼び掛けた。

（講演資料から引用）

　根岸氏は保険的な対策として、仮に防げなかったとしても「例えばダークWebのサイトやインフォスティラーのログなどを監視しているベンダーもある」と指摘。自社の認証情報が漏れたときに、できるだけ早く気付くための仕組みがあれば「漏えいは防げなくても、悪用を止めることができるかもしれない」とした。

　認証情報の漏えい検知は、3人のリサーチャーにとっても「難しいものだ」とこぼす。漏れる量が多過ぎること、アカウント情報が漏れたことが分かっても、どのパスワードか分からない場合もある。先述の仕組みはあくまで保険として考えておき、「やはり本質的には、どこから漏れても、ちゃんと特定できることが望ましい」とまとめた。

　「今回の話が、認証認可について考えるヒントや見直す機会になってほしい。フィッシングについても、自分たちの対策がどこまでできているかを確認する機会になれば幸いだ」（辻氏）

---

　根岸氏、辻氏、piyokango氏という専門家たちの知見が交差することで、認証認可という古くて新しいテーマは今も多層的な課題を含むことが分かる。自社のアカウントを、どう守っていくのか？　窃取されたことに、どうすれば気付けるのか？　その被害をどうやって阻止することができるのか？　即効性のある解答はないかもしれないが、3人と共に「大いに悩む」40分間は、またとない出発点になるはずだ。デジタル社会における自己の存在証明そのものといえる認証認可と、ぜひ真摯（しんし）に向き合ってほしい。