performing-adversary-in-the-middle-phishing-detection について
Adversary-in-the-middle フィッシングを対象とする、セキュリティ評価とインシデント対応向けの検知ガイドです。耐フィッシング MFA、条件付きアクセス、SIEM アラート、プロキシ監視を扱います。
主な機能
- 01耐フィッシング MFA の導入
- 02条件付きアクセスの設定
- 03AiTM 検知ルールの作成
- 04Web プロキシ指標の監視
- 05侵害後の活動の検知
活用シーン
- 01不審なログインとセッション再利用の調査
- 02MFA と条件付きアクセス制御の検証
- 03フィッシング後のメールボックスやクラウドドライブ活動の検知
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/performing-adversary-in-the-middle-phishing-detectionを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
LICENSEassets/template.mdreferences/api-reference.mdstandards.mdworkflows.mdscripts/agent.pyprocess.py詳細
中間者型フィッシングの検出
概要
中間者型（AiTM）フィッシング攻撃では、リバースプロキシのインフラストラクチャを利用して、被害者と正規の認証サービスの間に入り込み、認証情報とセッション Cookie の両方をリアルタイムで傍受します。これにより、攻撃者は多要素認証（MFA）を回避できます。2025 年に最も広く使われている PhaaS キットには、Tycoon 2FA、Sneaky 2FA、EvilProxy、Evilginx があります。2025 年 1 月から 2 月だけで、100 万件を超える PhaaS 攻撃が検出されました。リンクを配布する手段として、これらの攻撃は QR コードから HTML 添付ファイルや SVG ファイルへと進化しています。
使用するタイミング
- 中間者型フィッシングの検出を含むセキュリティ評価を実施する場合
- 関連するセキュリティインシデントのインシデント対応手順に従う場合
- 定期的なセキュリティテストや監査を実施する場合
- 実地テストを通じてセキュリティ制御を検証する場合
前提条件
- Azure AD / Entra ID の条件付きアクセス ポリシー
- 認証ログを取り込む SIEM（Azure AD サインインログ）
- SSL インスペクションと URL カテゴリ分類に対応した Web プロキシ
- エンドポイント検出・対応（EDR）ソリューション
- FIDO2／フィッシング耐性 MFA 機能
主要な概念
AiTM の仕組み
- 被害者が、攻撃者の管理下にあるドメインへのリンクを含むフィッシングメールを受信します
- 攻撃者のドメイン上で、正規のログインページを模倣するリバースプロキシが稼働します
- 被害者がプロキシ経由のページで認証情報を入力し、通信中に認証情報が取得されます
- リバースプロキシが認証情報を実際の認証サービスに転送します
- 被害者に MFA チャレンジが送信され、被害者はプロキシ経由のページで MFA を完了します
- 攻撃者が正規のサービスから返されたセッション Cookie を取得します
- 攻撃者がセッション Cookie を再利用し、MFA を使わずに被害者のアカウントにアクセスします
主な AiTM キット（2025 年）
| キット | 種類 | 主な標的 | 回避手法 |
|---|---|---|---|
| Tycoon 2FA | PhaaS | Microsoft 365、Google | CAPTCHA、Cloudflare turnstile |
| EvilProxy | PhaaS | Microsoft 365、Google、Okta | ランダム URL、IP ローテーション |
| Evilginx | オープンソース | あらゆる Web アプリケーション | カスタム phishlet |
| Sneaky 2FA | PhaaS | Microsoft 365 | ボット対策チェック |
| NakedPages | PhaaS | 複数 | 最小限のインフラストラクチャ |
検出指標
- ユーザープロファイルと一致しない、見慣れない IP からの認証
- 認証時とは異なる IP／デバイスからのセッション Cookie の再利用
- Microsoft／Google 以外のインフラストラクチャから配信されるログインページ
- フィッシングドメインから正規の認証プロバイダーへの CDN リクエスト
- 認証時とセッション使用時の間で発生する不可能な移動
ワークフロー
ステップ 1：フィッシング耐性 MFA を導入する
- 重要度の高いアカウントに FIDO2 セキュリティキーまたは Windows Hello for Business を導入します
- 管理者にフィッシング耐性 MFA を必須とするよう条件付きアクセスを構成します
- 可能な場合は、証明書ベースの認証を有効にします
- 特権アカウントでは SMS および音声による MFA を無効にします
- 認証がオリジンドメインにバインドされるため、AiTM は FIDO2 を傍受できません
ステップ 2：条件付きアクセス ポリシーを構成する
- 機密性の高いアプリケーションへのアクセスに、準拠済み／管理対象デバイスを必須とします
- 匿名プロキシおよび Tor の出口ノードからの認証をブロックします
- トークンバインディングを適用して、セッション Cookie の再利用を制限します
- リアルタイムのトークン失効に備え、継続的アクセス評価（CAE）を構成します
- リスクの高いサインイン時に再認証を要求するサインインリスク ポリシーを導入します
ステップ 3：AiTM 検出ルールを作成する
- サインイン後 10 分以内に異なる IP からセッションが発生した場合にアラートを出します
- プロキシ IP がユーザーの想定される場所と一致しない認証を検出します
- セッションの使用状況で不可能な移動パターンを監視します
- 認証直後に作成された受信トレイルール（侵害後によく見られる動作）をアラートします
- 不審なサインインから登録された新しい MFA 方法を検出します
ステップ 4：AiTM インフラストラクチャ向けの Web プロキシを監視する
- 新たに登録されたドメインへの DNS クエリを記録して分析します
- 既知の PhaaS インフラストラクチャの IP への接続を検知します
- 正規の CDN からプロキシドメイン経由で読み込まれた認証ページの背景画像を検知したらアラートを出します
- 企業のログインページを模倣したドメインに発行された SSL 証明書を監視します
- 脅威インテリジェンスを使って、既知の EvilProxy/Evilginx インフラストラクチャへのアクセスをブロックします
ステップ 5：侵害後の検知を実装する
- 不審な認証の後に作成されたメールボックスの転送ルールを検知したらアラートを出します
- AiTM によるサインイン後の OAuth アプリの同意を検知します
- BEC の後続活動を示すメール送信パターンを監視します
- セッションハイジャック後の SharePoint/OneDrive での大量ダウンロードを検知したらアラートを出します
- 侵害されたアカウントからのラテラルムーブメントを追跡します
ツールとリソース
- Microsoft Entra ID Protection：リスクベースの条件付きアクセス
- Azure AD Sign-in Logs：認証イベントの分析
- Okta ThreatInsight：IdP レベルでの AiTM プロキシ検知
- Sekoia TDR：AiTM キャンペーンの追跡とインテリジェンス
- Evilginx（防御目的）：検知のための攻撃メカニズムの理解
検証
- フィッシング耐性のある MFA がテストシナリオでの AiTM セッションの取得をブロックします
- 条件付きアクセスが別のデバイス/IP からのセッション再生を拒否します
- SIEM がシミュレートされた AiTM サインインパターンに対してアラートを発します
- Web プロキシが既知の PhaaS インフラストラクチャへの接続をブロックします
- 侵害後のルールが不審な認証後の受信トレイルールの作成を検知します
コメント
Markdown 対応