主なポイント

✓ このフィッシングキャンペーンは、AWSコンソールユーザーを狙ったもので、AWSインフラの命名規則を模倣したドメインを使用しています。
✓ 攻撃者は、認証情報をリアルタイムで捕捉し、被害者のAWSアカウントに迅速にアクセスすることが可能です。

社会的影響

! このフィッシングキャンペーンは、企業のセキュリティに対する信頼を損なう可能性があります。
! AWSを利用する多くの企業にとって、認証情報の漏洩は重大なリスクとなります。

編集長の意見

このフィッシングキャンペーンは、特にAWSを利用する企業にとって深刻な脅威です。攻撃者は、リアルタイムで認証情報を捕捉し、迅速にアカウントにアクセスする能力を持っています。これにより、企業は重要なデータやリソースが危険にさらされる可能性があります。フィッシング攻撃は、技術的な手法が進化する中でますます巧妙化しており、従業員の教育や意識向上が不可欠です。企業は、フィッシング攻撃に対する防御策を強化し、特に多要素認証（MFA）の導入を推奨します。また、AWSのCloudTrailを利用して、異常なログイン試行や認証情報の使用を監視することが重要です。今後も攻撃者は新たな手法を模索し続けるため、セキュリティ対策の継続的な見直しと改善が求められます。企業は、最新の脅威情報を常に把握し、迅速に対応できる体制を整える必要があります。

解説

AWSコンソールAiTMフィッシングが示した「MFAの壁」を越える現実

今日の深掘りポイント

タイポスクワット＋リアルタイム・プロキシでAWSサインインをそのまま中継し、OTPまで奪取しうるAiTM（Adversary-in-the-Middle）フィッシングが観測されています。
認証情報提出から20分以内にAWSコンソールへアクセスされた事例が確認され、オペレーションの即応性が高いことが特徴です。
脆弱性攻撃ではなく、正規エンドポイントの中継とセッション・トークン/OTPの奪取が軸で、TOTP型MFAは防波堤になりにくいです（FIDO2/WebAuthnの導入が肝要です）。
検知・阻止は「アイデンティティ平面」に寄せた統合設計が鍵。ConsoleLoginのふるまい分析、IdP/SSOの強制、SCPやIP制限の組み合わせで確率的防御を重層化すべきです。

はじめに

コンソールは“鍵束”です。AWSに限らず、管理コンソールの瞬間的なハイジャックはワークロード横断の高権限に直結し、復旧までの時間差が被害の大小を決めます。Datadog Security Researchが明らかにした今回のAiTMフィッシングは、古典的な「見た目を似せる」段階を超え、正規のサインインをリアルタイムでプロキシし、ワンタイムパスワード（OTP）も含めて中抜きできる点が本質です。TOTPやメールOTPに依存する運用では、ユーザ教育だけでは限界が見えます。アイデンティティ基盤側の構え直しが必要です。

参考: Datadogの詳細分析（一次情報）Behind the console: Investigating an active phishing campaign targeting the AWS console（Datadog Security Labs）

深掘り詳細

事実整理（Datadogの一次情報）

攻撃はAWSコンソール利用者を標的とし、AWSの命名規則を模したドメイン（タイポスクワット）で高忠実度のログイン画面クローンを配信します。正規UIに酷似し、静的アセットも模倣されていました。Datadog
フィッシングキットは正規のAWSサインインエンドポイントをリアルタイムでプロキシし、入力された資格情報の妥当性を即時に検証します。同フローでOTPを捕捉しうる構成が確認されました。Datadog
認証情報が入力されてから20分以内に、攻撃者が当該AWSコンソールへアクセスした事例が観測されています。オペレーションの即時性が高く、有人・自動のいずれでも迅速に侵入後アクションへ移っています。Datadog
AWS自体の脆弱性やAWSインフラ悪用ではありません。攻撃は外部の見た目・体験（フロント）を介してユーザをだまし、正規フローを中抜きしています。Datadog

補足の一次資料（防御側の前提整備）

AWSはFIDO2/WebAuthn（セキュリティキー）によるMFAをIAMユーザーでサポートしています。TOTPと比較してフィッシング耐性が高いです。AWS IAM: FIDOセキュリティキーのMFA設定
CloudTrailはConsoleLoginイベントを記録し、MFA使用有無や結果を追加データに含めます。検知・調査の軸になります。AWS CloudTrail: コンソールサインインイベント
NIST 800-63Bは「フィッシング耐性の高い認証子」としてFIDO2/WebAuthnやPKIベースの手段を位置づけています。NIST SP 800-63B

編集部インサイト（なぜ今、何が厄介か）

OTPは“見せかけの二段目”に過ぎないです。AiTMはOTPの「時間的価値」を熟知し、リアルタイムに中継・利用します。FIDO2/WebAuthnの“オリジンバインディング”だけが、このタイプの中抜きに対して本質的な堰き止めになります。TOTP偏重の環境は、もはや高確率で抜かれる前提で考えるべきです。
20分以内の侵入は、「初動の短さ＝損害の上限」が直結することを意味します。従来の“ユーザ報告→SOC着手→封じ込め”の人手中心フローでは、初動が間に合いません。CloudTrailとIdPログの相関、IP・デバイス異常の自動隔離、強制再認証など、反応を機械的に前倒しする設計が要ります。
コンソール侵入は“権限の連鎖”に波及します。AssumeRoleやクロスアカウントの権限委譲は、攻撃者にとって「跳躍台」になりやすいです。結果として、最初に侵害されたアカウントの境界を軽々と越え、組織・環境全体のBlast Radiusを広げます。権限境界とセッションの短命化は、横展開のコストを上げる最優先カードです。
メトリクス全体像からは、この話題が“すぐ効く・すぐ刺さる・避けにくい”性質を持ちながらも、目新しさより運用負債の照射に価値があることが読み取れます。つまり、個々のIoC追いだけでは足りず、認証方式・IdP強制・SCP/ポリシーの土台を組み替える意思決定が、現場で最もリターンが大きいです。

脅威シナリオと影響

以下はDatadogの観測を基に、MITRE ATT&CKで整理した仮説シナリオです（技術要素は代表例であり、実行の有無は都度検証が必要です）。

資源調達／偽装
- T1583.001 Acquire Infrastructure: Domains（AWS風ドメインを取得）
- T1036 Masquerading（正規UIに酷似した見た目・ブランド偽装）
初期侵入
- T1566.002 Phishing: Spearphishing Link（メールやメッセージで偽サイトへ誘導）
認証情報・セッション奪取
- T1111 Multi-Factor Authentication Interception（仮説：AiTMによりOTPをリアルタイム回収）
- T1539 Steal Web Session Cookie（仮説：プロキシ経由でセッショントークン／クッキーの窃取）
認証回避・横展開
- T1078 Valid Accounts（奪取済み資格情報で正規ログイン）
- T1078.004 Cloud Accounts（クラウドアカウント固有）
- TA0005 Defense Evasion（異常の目立たないユーザエージェントや地域を選ぶ、短時間の活動で痕跡最小化）
- TA0008 Lateral Movement／TA0003 Persistence（仮説：AssumeRoleや長命セッションの取得、アクセスキー発行）
影響
- 機密データ閲覧・スナップショット複製、IAM権限の後付け、KMSキーや監視の改変など、事業継続・規制リスクに直結します。初回アクセスが短時間でも、セッション延命や別経路の資格情報発行に成功すると、検知・追跡は一段と難しくなります。

セキュリティ担当者のアクション

優先度順に、すぐ効く構造的対策から実装することを勧めます。

フィッシング耐性のあるMFAへ移行する
- ルートユーザーおよび特権ロールはFIDO2/WebAuthnのセキュリティキーを必須化します。TOTPやメールOTPは補助にとどめます。AWS IAM: FIDOキーMFA、NIST 800-63Bの位置づけを参照します。
- パスキー／WebAuthn対応のIdP（またはAWS IAM Identity Center）でSSOを強制し、IAMユーザーのコンソール利用を原則廃止します（コンソール用パスワードを未設定にし、API専用に限定）。
アイデンティティ平面のガードレール整備
- 組織SCPやIAMポリシーで、重要アクションに aws:MultiFactorAuthPresent 条件を義務づけます（例：IAM変更系、キー管理、横断リソース列挙など）。
- 信頼できる出口IP（Egress）以外からの高リスク操作をDenyするIP制限を併用します（SCPや条件キーの現実解）。ゼロトラスト方針がある場合はIdP側のデバイスポスチャ条件と組み合わせます。
- セッション寿命を短く設定し、特権昇格は都度昇格（Just-in-Time）に。ロール連鎖の数や経路も制限して、攻撃者の移動半径を物理的に狭めます。
入口の減災（ユーザ側ハードニング）
- ブラウザの自動入力は正規オリジン（aws.amazon.com 等）のみ許可するパスワードマネージャ設定にし、IDNや新規登録ドメイン（NRD）のブロックをSWG/メールゲートウェイで有効化します。
- ドメイン許可リスト運用（EUC/VDI含む）と、企業内DNSでのタイポスクワット検知（例：正規ドメインのPermutation監視）を継続的に回します。
監視・検知（CloudTrail/IdPログを中心に）
- CloudTrailのConsoleLogin（signin.amazonaws.com, eventName=ConsoleLogin）を常時可視化し、以下の異常を組み合わせて相関します。AWS CloudTrail: サインインイベント
  - いつもと異なるAS/国・時間帯、初見のユーザエージェント
  - MFAUsedがYesでも疑わしい地理・デバイスの場合は高優先度（AiTMはOTPを突破しうるため）
  - 初回成功ログイン直後の権限変更、長命クレデンシャル発行、AssumeRoleの連鎖
- GuardDutyやIdPのリスクシグナル（不審なサインイン、Impossible Travel）と連携して、自動で該当プリンシパルを隔離・強制再認証するプレイブックを定義します。
インシデント対応の即応テンプレート
- コンソール侵害を疑う場合の初動（推奨）：対象IAMユーザー無効化（またはパスワード強制リセット）、アクティブアクセスキーの失効、直近ConsoleLoginのsourceIPAddressからのトラフィック遮断、当該プリンシパルでの直近AssumeRole/権限変更の全追跡とロールバック、セッションの最短化（SSO利用時は強制サインアウト）。
- 影響範囲の証跡固定化（S3/スナップショット複製、Secrets/KMSアクセス、CloudTrail改変の有無）を優先度高でレビューし、教訓をSCP/IdPポリシーに反映します。
組織的ガバナンス
- 「MFA=安全」の固定観念を捨て、フィッシング耐性（Phishing Resistance）という軸でKPIを再定義します。FIDO2の普及率、SSO経由率、TOTP依存度の縮小、IdPのデバイスポスチャ適用率など、運用メトリクスをダッシュボード化します。
- 委託先・開発ベンダーを含む外部IDにも同等の基準を適用します。境界の外にある“弱い鍵”が、最短距離の侵入口になるためです。

最後に。今回の観測は、技術的な奇をてらうより、アイデンティティの基本設計に戻るべきだと教えてくれます。FIDO2の段差を越え、SSOに交通整理し、ログを見る目を「失敗の数」から「ふるまいの違和感」へ。泥臭いけれど堅い道を、今日から一歩進めたいです。

参考情報

Datadog Security Labs（一次情報）: Behind the console: Investigating an active phishing campaign targeting the AWS console
AWS IAM: FIDOセキュリティキーでMFAを有効化
AWS CloudTrail: コンソールサインインイベントのログ
NIST SP 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management

背景情報

i Datadog Security Researchによると、このフィッシングキャンペーンは、AWSコンソールのユーザーを狙ったもので、タイポスクワッティングされたドメインを使用しています。攻撃者は、リアルタイムの中間者攻撃を利用して、認証情報を捕捉し、セッション情報を取得します。
i フィッシングページは、AWSの管理コンソールのサインインページの高忠実度クローンであり、正規のAWSサインインUIを模倣した静的アセットを提供します。これにより、被害者は本物のAWSのサインインページとほとんど区別がつかない状態になります。

メトリクス