author: CSIRT_Engineer_JP date: 2024-05-28 severity: High impact: BEC, Data_Exfiltration, Supply_Chain_Attack tags: [AiTM, Phishing, BEC, Session_Hijacking, MFA_Bypass, Microsoft_365, Entra_ID]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
緊急警告：セッションCookie窃取を伴う多段階AiTMフィッシングとBEC攻撃への対抗策
【脅威の概要と背景】
Microsoftが公表した最新の脅威動向によると、攻撃者はエネルギー、製造、ハイテク企業を標的とし、AiTM (Adversary-in-the-Middle) フィッシングにより認証情報だけでなくアクティブなセッションCookieを窃取しています。この攻撃手法は、MFA（多要素認証）を効果的にバイパスし、セッションハイジャックを通じて標的企業のExchange Online環境に侵入。最終的に機密情報の窃取やBEC (ビジネスメール詐欺) を遂行することを目的としています。この攻撃は、従来の認証情報窃取型フィッシングよりも検知が困難であり、認証フロー全体を乗っ取る高度な多段階攻撃として緊急の対応が求められます。
【攻撃シナリオの可視化】
この攻撃は、AiTMを起点とする認証フローの乗っ取りと、権限取得後のラテラルムーブメントを組み合わせた多段階キルチェーンを形成します。
graph TD
A["ユーザー認証要求"] --> B{"AiTMプロキシサイトへ誘導"};
B --> C["認証情報/MFA入力/セッション確立"];
C -->|"攻撃者プロキシ経由"| D["正規IdP/Azure Entra ID"]
D --> E["正規セッションCookie生成"];
E --> F("セッションCookie窃取/MFAバイパス");
F --> G["Exchange Onlineアクセス/永続化"];
G --> H{"悪意あるInbox Rule設定"};
H --> I["機密情報窃取/BEC実行"];
subgraph mermaid_group_9["攻撃者の活動 (初期アクセスから目的達成まで)"]
F --乗っ取り--> G;
G --> I;
end解説:
初期アクセス: ユーザーをAiTMプロキシサイトへ誘導。
認証情報の窃取: ユーザーが入力したID/PW/MFAコードを窃取。
セッションハイジャック: 攻撃者はプロキシ経由で正規の認証を完了させ、ユーザーに戻される前に確立されたセッションCookieを傍受する。
永続化: 窃取したセッションCookieを用いてMFAをバイパスし、Exchange Onlineにアクセス。
BECの実行: 侵入したメールボックスに悪意ある受信トレイ ルール（Inbox Rule）を設定し、特定のキーワードを含むメールを外部へ転送したり、上長への支払い指示を偽装したりする。
【安全な実装と設定】
AiTMフィッシングに対抗するためには、パスワードベース認証やMFAコードの再利用が不可能な、フィッシング耐性を持つ認証器の導入が必須です。
誤用（脆弱な設定）の例
レガシー認証を許可し、パスワードとTOTP（時間ベースワンタイムパスワード）のみに依存している環境はAiTMの格好の標的となります。
# 誤用例：レガシー認証をブロックせず、脆弱なMFAに依存している状態 # MFAは有効だが、AiTMによりMFAコードとセッションCookieが同時に窃取され得る。 # MFA方法がSMSやTOTPの場合、フィッシング耐性がない。 # Set-MsolDirSyncFeatures -Feature EnableLegacyAuth -Enable $True # (もし有効化されていれば致命的) Write-Host "警告: レガシー認証が有効な環境ではAiTMリスクが高い"
安全な代替案（フィッシング耐性の高い認証と設定）
セッションCookieの窃取を防ぐ最も効果的な方法は、認証時にパスワードやMFAコードの入力が必要ない、フィッシング耐性の高い認証方式 (FIDO2/パスキー) へ移行することです。
1. レガシー認証の即時ブロック (Azure Entra ID / Exchange Online)
レガシー認証（POP3, IMAP, SMTP AUTHなど）はMFAをサポートせず、ブルートフォースやAiTMのリスクを高めるため、全面的にブロックします。
# Entra ID (旧 Azure AD) Conditional Access Policyの設定例
# すべてのユーザーに対し、レガシー認証クライアントからのアクセスをブロック
# 必要な権限: Global Administrator / Conditional Access Administrator
# Azure CLIを用いたレガシー認証ブロックのポリシー設定例
az rest --method POST --uri 'https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies' --headers 'Content-Type=application/json' --body '{
"displayName": "Block Legacy Authentication",
"state": "enabled",
"conditions": {
"clientAppTypes": ["other"],
"users": {
"includeUsers": ["All"]
}
},
"grantControls": {
"operator": "All",
"details": [
{ "id": "Block", "state": "enabled" }
]
}
}'
Write-Host "成功: Conditional Accessによりレガシー認証をブロックしました。"
2. フィッシング耐性のあるMFAの強制
FIDO2セキュリティキー、またはWindows Hello for Business（WHfB）のような、秘密鍵ベースでフィッシングが原理的に不可能な認証器の利用を強制します。
# FIDO2セキュリティキーを優先する認証強度を設定（Entra ID Authentication Strengths） Write-Host "セキュリティ管理者へ: FIDO2/パスキーの登録と利用を条件付きアクセスで強制してください。" # Set-MsolStrongAuthenticationMethod -Method FIDO2Key -Enforce $True # (概念的な指示)
【検出と緩和策】
セッションCookieハイジャック後の攻撃活動を早期に発見し、被害を最小限に抑えるための対策を実施します。
検出ポイント (EDR/SIEM連携)
| 監視対象 | 検出トリガー（異常な挙動） | 優先度 |
|---|---|---|
| 認証ログ (Entra ID) | 異常な地理情報やIPアドレスからのセッションCookie再利用（Token Replay） | 緊急 |
| Exchange Online監査ログ | Set-InboxRule または New-InboxRule の実行。特に転送先が組織外ドメインの場合 |
緊急 |
| ユーザーエージェント | 通常利用しないOSやブラウザ、またはAPIクライアントによるセッション再利用 | 高 |
| セッション情報 | ユーザーが認証した時刻から著しく乖離した、長時間のセッション継続 | 中 |
| テナント設定 | 外部転送ルールの一括設定・変更（特にGlobal Admin権限を持つアカウント） | 高 |
応急的な緩和策（Workaround）
疑わしいセッションの即時無効化: 不審なセッションCookieが使用されている兆候を発見した場合、当該ユーザーのセッションを即座に無効化します。
# ユーザーのすべてのセッションを強制的に無効化し、再認証を要求 # 影響範囲: ユーザーは全てのMicrosoft 365/Entra IDサービスからログアウトされます。 $UserPrincipalName = "target.user@example.com" Revoke-AzureADUserAllRefreshTokens -ObjectId (Get-AzureADUser -ObjectId $UserPrincipalName).ObjectId Write-Host "ユーザー $UserPrincipalName のリフレッシュトークンを全て無効化しました。"
セッション期間の厳格化: 条件付きアクセスポリシーを用いて、セッションの有効期間（サインイン頻度）を短く設定し、セッションCookieの利用期間を制限します。
【実務上の落とし穴】
誤検知（False Positive）リスク
- 地理的異常: VPNやリモートアクセスサービスの利用により、正規ユーザーでもIPアドレスが頻繁に変動するため、異常なアクセス元として誤検知されるリスクがあります。組織の正規のVPN/プロキシIP帯域を監視対象から除外するチューニングが必要です。
可用性（サービス継続）とのトレードオフ
- セッション期間の短縮: サインイン頻度を厳しく設定しすぎると（例：1時間ごとに再認証）、長時間かかるスクリプトの実行や、PowerShell/CLIなどの自動化処理が頻繁に中断され、業務プロセスに重大な影響を及ぼす可能性があります。リスク許容度と業務継続性のバランスを考慮し、アプリケーションやサービスアカウントは適切な例外処理（またはマネージドIDの利用）を行う必要があります。
【まとめ】
AiTMフィッシングによるセッションハイジャックは、MFAの防御層を突破する深刻な脅威です。組織として今すぐ確認・実施すべき3つの優先事項は以下の通りです。
フィッシング耐性MFAへの移行: FIDO2セキュリティキーまたはパスキーを最優先とし、パスワードレス戦略を推進することで、AiTMによる認証情報の窃取を無力化する。
レガシー認証の完全無効化: すべてのユーザーおよびサービスアカウントに対し、条件付きアクセスを使用してレガシー認証クライアントからのアクセスを全面的にブロックする。
セッション監視とInbox Rule監査の強化: EDR/SIEMにおいて、異常な地理からのセッションCookie利用や、組織外へのメール転送設定（Set-InboxRule）の監査ログを最優先で監視・アラート化する。
参考文献
Microsoft Security Response Center (MSRC) Advisory
JPCERT/CC (関連するフィッシング動向のレポート)
Microsoft Entra ID (旧 Azure AD) Conditional Access Documentation
[Microsoft MSTIC Blog] (例: AiTM Phishing Campaign Targeting Enterprise) (注: 特定の公開ブログ記事のURLは、レポート作成時点での最新情報を元に追記してください。)
