MFAがなかったせいで——盗まれた認証情報とクラウドデータ基盤の大規模侵害

2024年、クラウドデータ基盤を襲った連鎖的なデータ侵害

2024年、クラウド時代のセキュリティの本質を突きつける大規模なデータ侵害が発生しました。大手クラウドデータウェアハウスのSnowflakeのプラットフォームを利用する多数の顧客企業が、相次いでデータ侵害を公表したのです。この一連の事案は、「クラウドを使うこと」と「クラウドを安全に使うこと」の間にある大きな溝を、多くの企業に痛感させました。

侵害されたのはプラットフォームではなく「顧客のアカウント」

重要なのは、侵害されたのはSnowflakeのプラットフォームそのものの脆弱性ではなかったという点です。攻撃者は、システムの欠陥を突いたのではなく、各顧客企業のアカウントに対して正規の認証情報（ID・パスワード）を使ってログインしたのです。つまり、攻撃者は「正規ユーザー」として堂々と正面玄関から入ってきました。

この攻撃キャンペーンの影響を受けた企業は、調査報告によれば100社以上に及んだとされ、大量の個人・顧客データが窃取され、恐喝（データを公開すると脅して金銭を要求する手口）に悪用されました。セキュリティ企業の調査では、この一連の攻撃は金銭目的の攻撃グループによるものとされています。

「プラットフォームは侵害されていない。侵害されたのは顧客の認証情報とアカウント設定だった」
この事案の本質は、クラウドの責任共有モデルにあります。クラウド事業者はインフラの安全性に責任を持ちますが、認証・アクセス制御・アカウント設定は利用者側の責任範囲です。プラットフォームがどれほど堅牢でも、利用者が認証情報を守れず、MFA（多要素認証）を設定していなければ、攻撃者は正規の鍵を使って中に入れてしまいます。「クラウドに預ければ安全」という誤解を打ち砕いた事案でした。

情報窃取型マルウェア（インフォスティーラー）という起点

では、攻撃者はどうやって「正規の認証情報」を手に入れたのでしょうか。その起点となったのが、インフォスティーラー（情報窃取型マルウェア）です。

インフォスティーラーとは何か

インフォスティーラーは、感染した端末から機密情報を抜き取ることに特化したマルウェアです。具体的には、ブラウザに保存されたパスワード、Cookie、セッショントークン、暗号資産ウォレット情報などを窃取します。代表的なマルウェアファミリーが多数存在し、その多くはMaaS（Malware-as-a-Service）——マルウェアをサービスとして貸し出すビジネスモデル——として地下市場で流通しています。技術力の低い攻撃者でも、月額料金を払えば高機能な窃取ツールを使えてしまうのです。

感染経路——BYODと業務端末の私的利用が侵入口

インフォスティーラーの主な感染経路は、偽ソフトウェア、海賊版ソフト、悪性広告（マルバタイジング）、そしてフィッシングです。特に、個人所有端末（BYOD）や、業務端末の私的利用が侵入口になりやすい点が問題です。従業員が私用でダウンロードした偽ソフトから感染し、その端末に保存された業務用の認証情報まで一緒に抜き取られる、というシナリオが典型です。

数年前に盗まれた認証情報が「今」使われた

2024年の事案では、数年前に従業員や委託先の端末がインフォスティーラーに感染して窃取された認証情報が、MFA未設定のクラウドアカウントに対して使われたとされています。つまり、攻撃の「材料」はずっと前から地下市場に流通しており、それが放置されたアカウントに対して発火したのです。

「古い認証情報の棚卸し」と「強制ローテーション」の欠如が被害を拡大

窃取された認証情報の一部は数年前のものでした。にもかかわらず、パスワードが変更されず、MFAも未設定のまま放置されていたことが、被害を決定的に拡大させました。認証情報は一度盗まれると長期間にわたって悪用され続けます。「古い認証情報の棚卸し」と、定期的な「強制ローテーション（パスワード変更の強制）」を怠っていたことが、致命的な隙となったのです。

なぜ「MFA未設定」が致命傷になったのか

この事案を一言で表すなら、「MFAがなかったせいで」に尽きます。ここでは、なぜMFAの有無が明暗を分けたのかを構造的に整理します。

攻撃の成立条件は「2つ」だった

正規の認証情報を使ったログイン攻撃が成立する条件は、極めてシンプルです。

① 正しいID・パスワードを知っていること（＝インフォスティーラーで達成済み）
② MFAが無いこと（＝アカウント設定の不備で達成済み）

逆に言えば、MFAさえ設定されていれば、パスワードが漏れても、それ単独ではログインできなかったのです。MFAは「パスワードが漏れることを前提とした最後の砦」として機能します。この砦がなかったことが、多数の企業に共通する致命傷でした。

ただし、すべてのMFAが安全なわけではない

ここで注意が必要なのは、MFAにも「強度の差」があるという点です。SMSやTOTP（時間ベースのワンタイムパスワード）を用いたMFAは、フィッシングやリアルタイム中継攻撃（AiTM：Adversary-in-the-Middle）によって突破されうることが知られています。攻撃者が偽サイトを経由してユーザーとサービスの間に割り込み、入力されたワンタイムパスワードをその場で正規サイトに中継してしまうのです。

MFAの方式別に見た「強度」の違い

一口にMFAといっても、その耐性は方式によって大きく異なります。以下に代表的な方式を整理します。自社が導入しているMFAがどの段階にあるかを確認する材料としてご活用ください。

MFA方式	パスワード漏洩への耐性	フィッシング/AiTMへの耐性	評価
SMS OTP（ショートメッセージ）	あり	低い（中継・SIMスワップで突破されうる）	最低限だが不十分
TOTP（認証アプリのワンタイムコード）	あり	低い（AiTMで中継されうる）	SMSより堅牢だが限界あり
プッシュ通知承認	あり	中程度（承認疲労攻撃のリスク）	設定次第で改善可能
FIDO2/パスキー	あり	高い（オリジンにバインドされ偽サイトで不成立）	フィッシング耐性MFAの本命

フィッシング耐性MFA（FIDO2/パスキー）という解

この弱点を根本から解決するのが、フィッシング耐性MFA、すなわちFIDO2/パスキーです。FIDO2認証では、認証処理がオリジン（正規のドメイン）にバインドされているため、偽サイト上では認証そのものが成立しません。ユーザーが誤って偽サイトにアクセスしても、認証が働かないため、中継攻撃（AiTM）にも耐性を持ちます。

NIST SP 800-63B、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）、FIDO Allianceはいずれも、フィッシング耐性のある認証方式への移行を強く推奨しています。また、クラウドサービス側でも、MFAをデフォルトで有効化し、強制する流れが加速しています（Snowflakeも本事案後にMFA強制ポリシーを強化したと報じられました）。

盗まれた認証情報の地下経済——ダークウェブとIABの実態

なぜ認証情報の悪用がこれほど組織的に行われるのか。その背景には、盗まれた認証情報を売買する成熟した「地下経済」が存在します。

認証情報の流通ルート

インフォスティーラーなどで窃取された認証情報は、ダークウェブのマーケットプレイスやTelegramチャンネルなどで活発に売買されています。数百万件規模の認証情報が「ログ」として束で取引され、攻撃者は目的の企業のドメインを含む認証情報を検索・購入できます。

IAB——初期アクセスを専門に売買する犯罪者

この地下経済で重要な役割を果たすのが、IAB（Initial Access Broker：初期アクセスブローカー）です。IABは、企業への侵入手段——VPN・RDP（リモートデスクトップ）・クラウドの認証情報など——を専門に売買する犯罪エコシステムのプレイヤーです。ランサムウェアグループはIABから初期アクセスを購入し、それを起点に侵入・暗号化を行うという分業体制が確立しています。認証情報の窃取から実際の攻撃までが、専門業者による分業で効率化されているのです。

クレデンシャルスタッフィングと使い回しの罠

もう一つの脅威がクレデンシャルスタッフィングです。これは、漏洩したID/パスワードの組み合わせを、大量の別サービスに対して自動的に試行する攻撃です。パスワードの使い回しを悪用する手口であり、1つのサービスからの漏洩が、使い回された他のすべてのサービスの侵害につながります。

そして最も厄介な特性が、認証情報は「一度盗まれると回り続ける」という点です。漏洩したデータは何年にもわたって再利用され、再販され、繰り返し攻撃に使われます。2024年の事案で数年前の認証情報が使われたのは、まさにこの特性の表れでした。

パスワードの使い回しは「1サービスの漏洩」を「全サービスの侵害」に変える
パスワードの使い回しは、クレデンシャルスタッフィング攻撃の温床です。1つのサービスからパスワードが漏洩すると、同じパスワードを使っている他のすべてのサービスが芋づる式に侵害されます。特に、企業アカウントと私的アカウントで同じパスワードを使うことは極めて危険です。私的サービスの漏洩が、企業システムへの侵入口になりかねません。

対策——フィッシング耐性MFAとアイデンティティ中心の防御

2024年の事案が示した教訓は明確です。クラウド時代の防御の中心は、もはやネットワークの境界ではなく「アイデンティティ（ID）」にあります。攻撃者が「正規の鍵」を持って正面から入ってくる以上、鍵そのものを守り、鍵の使われ方を検証する仕組みが不可欠です。具体的な対策を以下に整理します。

実装すべき6つの対策

① フィッシング耐性MFA（FIDO2/パスキー）を全アカウントに強制：特にクラウド管理者・データ基盤へのアクセスには必須です。SMS/TOTPでは不十分であり、AiTM攻撃にも耐えるFIDO2への移行を進めます。
② クラウドアカウントの棚卸しとMFA強制ポリシー：MFAが未設定のアカウントを検出し、是正します。「MFA未設定を許さない」ポリシーを組織全体で徹底します。
③ 認証情報のライフサイクル管理：定期的なローテーション、退職者・委託先アカウントの確実な無効化、そして放置アカウントの棚卸しを継続的に実施します。使われていないアカウントは、攻撃者にとって格好の的です。
④ 端末保護（インフォスティーラー対策）：EDR（Endpoint Detection and Response）による端末の監視・検知を導入し、私的端末での業務アカウント利用を制限します。感染源そのものを断ちます。
⑤ 条件付きアクセス（ゼロトラスト）：デバイス・場所・振る舞いのリスクに応じてアクセスを動的に制御します。正しいパスワードとMFAがあっても、不審な状況下でのアクセスは拒否・追加検証する仕組みです。
⑥ ダークウェブ監視：自社の認証情報が地下市場に流出していないかを継続的に監視し、漏洩を早期に検知して先手を打ちます。

フィッシング耐性MFAへの移行はKeyperで

Net PeaceのKeyperは、FIDO2/パスキーによるフィッシング耐性認証を実現します。パスワード漏洩・インフォスティーラー・AiTM攻撃を無効化し、クラウド・SaaS・特権アクセスを統合的に保護します。まずは無料相談から。

Keyperの詳細を見る無料相談を申し込む

KeyperとUPAS ZTAでクレデンシャル悪用を封じる

Net Peaceは、2024年のクラウドデータ基盤侵害が突きつけた「アイデンティティ中心の防御」を、KeyperとUPAS ZTAという2つの製品で実現します。攻撃の成立条件そのものを崩し、たとえ認証情報が漏れても侵入を許さない多層防御を構築します。

Keyper——認証情報の漏洩を「無害化」する

Keyperは、FIDO2/パスキーによるフィッシング耐性認証を提供します。認証がオリジンにバインドされるため、パスワード漏洩・インフォスティーラーによる窃取・AiTM攻撃を根本から無効化します。仮に攻撃者がパスワードを入手しても、FIDO2の認証器（デバイスに紐づく秘密鍵）がなければログインは成立しません。クラウド・SaaS・特権アクセスを統合的に認証し、「MFAがなかったせいで」という事態を構造的に防ぎます。

UPAS ZTA——未承認端末からのアクセスを遮断

UPAS ZTAは、接続端末のデバイス認証を行い、未承認の端末——インフォスティーラー感染の疑いがある私的端末など——からのアクセスを遮断します。デバイス・場所・リスクに応じた条件付きアクセスを実現し、正しい認証情報を持っていても、信頼できない端末からのアクセスは許可しません。BYODや業務端末の私的利用という、インフォスティーラーの主要な感染経路に対する防御層となります。

ID棚卸しと放置アカウント検出の支援

Net Peaceは、2024年の事案で被害を拡大させた「古い認証情報の放置」に対応するため、ID棚卸しと放置アカウントの検出を支援します。退職者・委託先の未削除アカウント、長期間使われていないアカウントを可視化し、認証情報のライフサイクル管理を実践できる体制づくりをサポートします。

クラウド時代の侵害は、脆弱性ではなく「認証情報」から始まります。攻撃者に正規の鍵を渡さない——そして渡ってしまっても使わせない。Net Peaceは、その両輪でお客様のクラウド基盤を守ります。まずは無料相談からお気軽にお問い合わせください。

よくある質問（FAQ）

クラウド利用企業のセキュリティ担当者から寄せられることの多い質問と、その考え方を整理します。

Q1. すでにMFAを導入していれば安心ですか？

MFAの導入は大きな前進ですが、方式によって耐性が異なります。SMSやTOTPによるMFAは、フィッシングやAiTM（中継）攻撃で突破される可能性があります。より確実に守るには、認証がオリジンにバインドされるフィッシング耐性MFA（FIDO2/パスキー）への移行が推奨されます。特にクラウド管理者やデータ基盤へのアクセスは優先的に強化すべきです。

Q2. 「クラウドに預けているから事業者が守ってくれる」のではないですか？

クラウドには責任共有モデルがあり、事業者はインフラの安全性に責任を持ちますが、認証・アクセス制御・アカウント設定は利用者側の責任範囲です。2024年の事案でも、プラットフォーム自体は侵害されず、侵害されたのは各顧客のアカウントでした。「クラウドを使う」ことと「安全に使う」ことは別問題であることを認識する必要があります。

Q3. 数年前に漏れた認証情報まで気にする必要がありますか？

必要です。窃取された認証情報は地下市場で何年も再利用・再販され続けます。2024年の事案でも、数年前にインフォスティーラーで盗まれた認証情報が、MFA未設定のまま放置されたアカウントに対して使われました。定期的なパスワードローテーション、放置アカウントの棚卸し、ダークウェブ監視による漏洩の早期検知が有効です。

Q4. BYOD（私的端末）の利用はどう管理すべきですか？

私的端末や業務端末の私的利用は、インフォスティーラーの主要な感染経路です。EDRによる端末保護、私的端末での業務アカウント利用の制限、そしてUPAS ZTAのようなデバイス認証・条件付きアクセスによって、信頼できない端末からのアクセスを遮断することが重要です。