ブラウザが主要なサイバー戦場となった経緯

つい最近まで、過去10年ほどの最大規模の情報漏洩事件におけるサイバー攻撃者の手法は、かなり一貫していました：

• ソフトウェアの脆弱性を突いたり、ユーザーにマルウェアを実行させるソーシャルエンジニアリングによってエンドポイントを侵害する。
• ネットワーク内で横移動し、特権IDを侵害する方法を見つける。
• 必要に応じてこれを繰り返し、最終的に目的の攻撃を実行する—通常はファイル共有からのデータ窃取、ランサムウェアの展開、あるいはその両方。

しかし、ネットワークの進化とともに攻撃手法は根本的に変化しました。エンタープライズITのSaaS化により、コア業務システムは従来のようにローカルに導入・集中管理されるものではなくなりました。代わりに、インターネット経由でログインし、ウェブブラウザを通じてアクセスする形になっています。

攻撃はローカルネットワークから、従業員のウェブブラウザを通じてアクセスされるSaaSサービスへとシフトしています。

共有責任モデルの下では、SaaSサービスを利用する企業側に残される部分は、主にID管理—つまりアプリが従業員によってアクセス・利用される手段—に限定されます。これが攻撃者の格好の標的となっているのは当然のことです。

ここ数年の大規模な情報漏洩事件でもこの傾向が繰り返し見られ、特に2024年の大規模なSnowflakeキャンペーンや、2025年のScattered Spiderによる犯罪波がその代表例です。

これらの攻撃が非常に成功している理由は、攻撃者がエンタープライズITの変化に合わせて進化している一方で、セキュリティ側が十分に追いついていないためです。

ブラウザは新たな戦場—そしてセキュリティの死角#

攻撃者が組織を狙う際の最初の目標は従業員IDの乗っ取りであり、その攻撃がユーザーに対して行われる場所がブラウザです。なぜなら、ここでデジタルIDが作成・利用され、認証情報やセッショントークンが存在するからです。これこそが攻撃者の狙いです。

盗まれた認証情報は、標的型攻撃やより広範なクレデンシャル・スタッフィング（既知のユーザー名とパスワードの組み合わせを様々なアプリやプラットフォームで試す）に利用され、盗まれたセッショントークンは認証プロセスを回避してアクティブなセッションに直接ログインするために使われます。

攻撃者がこれらのIDにアクセスするための手法はいくつかあります。攻撃者は様々な場所から盗まれた認証情報を収集します—情報漏洩データのダンプ、大規模な認証情報フィッシングキャンペーン、インフォスティーラーログ、さらには従業員にインストールさせた悪意あるブラウザ拡張機能などです。実際、サイバー犯罪エコシステム自体がこれに対応する形で変化し、ハッカーが認証情報の収集やアカウントアクセスの確立を専門に担うようになっています。

2024年の注目されたSnowflakeの情報漏洩は、ID主導型漏洩への転換点となりました。攻撃者は盗まれた認証情報を使い、数百の顧客テナントのアカウントにログインしました。攻撃に使われた認証情報の主な出所は2020年に遡るインフォスティーラーログで、パスワードがローテーションされていなかったり、MFAが導入されていなかったりしたものです。

インフォスティーラーは、エンドポイントマルウェア攻撃として特筆すべきもので、認証情報やセッショントークン（主にブラウザから）を収集し、攻撃者が自分のウェブブラウザからそのサービスにログインできるようにします。つまり、今日のエンドポイント攻撃でさえ、攻撃者はID—今やデータや機能が集約されているオンラインアプリやサービスへの鍵—を得るために再びブラウザに戻ってきているのです。

ブラウザ内の攻撃 vs. ブラウザ自体への攻撃#

ブラウザ内で発生する攻撃と、ブラウザ自体を標的とした攻撃には重要な違いがあります。

ブラウザは新たなエンドポイントであるという認識が広がっています。しかし、このアナロジーは完全ではありません。実際、ウェブブラウザの攻撃対象領域は従来のエンドポイント（たとえばGoogle ChromeとWindows OSを比較するようなもの）に比べて限定的です。

IDを侵害する手段としてブラウザ自体を狙う攻撃は、実際にはそれほど多くありません。明らかなベクトルの一つは悪意あるブラウザ拡張機能の利用です。つまり、ユーザーが以下のいずれかの状況にある場合です：

• すでに悪意ある拡張機能をインストールするよう誘導された場合
• 後に攻撃者によって乗っ取られた拡張機能を利用している場合

しかし、悪意ある拡張機能の問題は一度解決すれば済む話です。現実的には、ユーザーが無作為に拡張機能をインストールすべきではなく、リスクを考慮すれば：

• 必要最低限の拡張機能のみ許可するよう環境を制限する。
• 信頼している拡張機能が侵害された兆候を監視する。

これは、ユーザーに好きな拡張機能を自由にインストールさせている環境には当てはまりません。しかし、ブラウザが新たなエンドポイントであるなら、これは全ユーザーがローカル管理者権限を持っているようなもので、問題を招くことになります。組織内で拡張機能を制限することは、たとえばChrome Enterpriseのようなネイティブツールを使えば実現可能です。ユーザーを一度監査し、必要なものだけを承認し、新しい拡張機能のインストールには追加承認を求めましょう。

狙いはID、舞台はブラウザ—そしてフィッシングが主な武器#

それでもなお、最も深刻なID主導型漏洩を引き起こしている手法は？それはフィッシングです。認証情報、セッション、OAuth同意、認可コードを狙ったフィッシング。メール、インスタントメッセンジャー、SNS、悪意あるGoogle広告など、すべてがブラウザ内で発生するか、ブラウザへ誘導されます。

どの配信チャネルであっても、すべてのフィッシング攻撃は最終的にブラウザに行き着きます。

そして現代のフィッシング攻撃はかつてないほど巧妙です。現在、フィッシングは産業規模で行われており、様々な難読化や検知回避技術を駆使してメールやネットワークのセキュリティツールによる遮断を逃れています。今日最も一般的な例は、ボット対策（CAPTCHAやCloudflare Turnstileなど）の利用で、正規のアンチスパム機能を使ってセキュリティツールをブロックします。

Cloudflare Turnstileは自動解析を防ぐシンプルな方法であり、インシデント対応者には警戒が必要です。

最新世代の完全カスタマイズ型AitMフィッシングキットは、ウェブページを読み込むコードを動的に難読化し、カスタムCAPTCHAや実行時のアンチ解析機能を実装することで、検知をますます困難にしています。リンクの配信方法も高度化し、配信チャネルが増え、正規のSaaSサービスをカモフラージュに利用するケースも増えています。

また、最新の傾向として、攻撃者は強化されたIdP/SSO構成に対応し、MFAやパスキーを回避する代替フィッシング手法を利用しています。最も一般的なのは、フィッシング可能なバックアップ認証方法にダウングレードさせる手法で、下記の動画でその様子が見られます。詳細はこちらをご覧ください。

IDは攻撃者にとって最も狙いやすい標的#

現代の攻撃者の目的、そしてあなたのビジネスのデジタル環境への最も簡単な侵入口は、IDの侵害です。フィッシング攻撃、悪意あるブラウザ拡張機能、インフォスティーラーマルウェアのいずれであっても、目的は同じ—アカウントの乗っ取りです。

組織は、以下のような広大かつ脆弱な攻撃対象領域に直面しています：

• 数百のアプリケーションと数千のアカウントがアプリ資産全体に分散している。
• MFAバイパスフィッシングキットに脆弱なアカウント（フィッシング耐性のないログイン方法を使用している、またはログイン方法がダウングレード可能な場合）。
• 弱い、再利用された、または漏洩したパスワードかつMFA未設定のアカウント（たいていはゴーストログインの放置が原因）。
• APIキー作成、アプリ固有パスワード、OAuth同意フィッシング、クロスIdPなりすましなどの機能を悪用し、認証プロセス自体を回避してフィッシング耐性のある認証方法をすり抜ける。

1,000人規模の組織では、さまざまな設定や脆弱性を持つ15,000以上のアカウントが存在します。

IDの脆弱性の主な要因は、アプリごとにアカウントの設定可能性が大きく異なることです。IDの可視性やセキュリティ制御の集中度もアプリごとに異なります。たとえば、あるアプリはSAML経由のSSOログインのみを許可し未使用パスワードを自動削除できますが、別のアプリはログイン方法やMFA状態の制御・可視性が一切ありません（これも昨年のSnowflake漏洩の大きな要因でした）。残念ながら、これはプロダクト主導の成長や新たなSaaSスタートアップの登場によってますます悪化しており、状況がすぐに改善する見込みはありません。

その結果、IDは誤設定され、セキュリティチームからは見えず、一般的な攻撃ツールによって日常的に悪用されています。攻撃者の主な標的となっているのも当然です。

ゴーストログイン、AitMフィッシング、ダウングレード攻撃、アプリレベルの設定問題がIDベースの漏洩を加速させています。

解決策：ブラウザをテレメトリー源かつ制御ポイントに#

ID攻撃がブラウザ内で展開されるため、セキュリティチームがこれらの攻撃を観察・遮断・阻止するのに最適な場所がブラウザです。

ブラウザには、IDを観察・保護できる他の場所に比べていくつかの利点があります：

• IdPに直接接続されたアプリやID（従業員IDのごく一部）に限定されません。
• 把握・集中管理しているアプリだけでなく、ブラウザを通じて行われるすべてのログインを観察できます。
• ログイン方法やMFA方式など、ログインの全プロパティを観察できます。これらの情報はAPIが提供されていて、かつ特定データの取得が可能な場合に限りAPI経由で取得できますが、多くのアプリでは標準化されていません。

ここまで述べてきた通り、すべてのID脆弱性を修正するのは非常に困難です—SaaSエコシステム自体が障害となっています。だからこそ、ID攻撃の検知と対応が不可欠です。ID侵害はほぼ必ず、ユーザーにブラウザ上で何らかの行動をさせるフィッシングやソーシャルエンジニアリングを伴うため（例外は最近見られたScattered Spider関連のヘルプデスク攻撃など）、攻撃の監視・遮断にも最適な場所です。

ブラウザ内では、ページの挙動やユーザー入力など、リスクシナリオのリアルタイム検知・遮断に使える深い文脈情報を収集できます。フィッシングページの例を挙げましょう。Pushはブラウザ内で動作するため、すべてを把握できます：

• ページレイアウト
• ユーザーの遷移元
• 入力されたパスワード（ソルト付き短縮ハッシュとして）
• 実行中のスクリプト
• 認証情報の送信先

ブラウザ内にいることで、フィッシングページの活動やユーザー行動を比類なき可視性で把握できます。

結論#

ID攻撃は今日のセキュリティチームが直面する最大の未解決課題であり、セキュリティ侵害の主因です。同時に、ブラウザはIDベースの攻撃を防止・検知・対応するためのすべてのツールをセキュリティチームに提供します—ID脆弱性の発見と修正による予防的対策、ユーザーへのリアルタイム攻撃の検知と遮断による事後対応の両面で。

組織は、MFA証明やID管理ダッシュボード、従来型のメール・ネットワーク型アンチフィッシングツールに頼る旧来のIDセキュリティから脱却する必要があります。そして、これらの攻撃を阻止する最適な場所はブラウザ以外にありません。

詳細はこちら#

Push Securityのブラウザベースのセキュリティプラットフォームは、主要な侵害原因に対する包括的な検知・対応機能を提供します。Pushは、AiTMフィッシング、クレデンシャル・スタッフィング、パスワードスプレー、盗まれたセッショントークンによるセッションハイジャックなどのID攻撃をブロックします。また、ゴーストログイン、SSOカバレッジのギャップ、MFAギャップ、脆弱なパスワード、リスクのあるOAuth連携など、従業員が利用するアプリ全体のID脆弱性の発見と修正にも活用できます。

Pushがどのようにブラウザ内で攻撃を検知・阻止するのか詳しく知りたい方は、弊社チームによるライブデモをご予約ください。