フィッシングの調査

この記事では、組織内でのフィッシング攻撃の特定と調査に関するガイダンスを提供します。 詳細な手順は、情報を保護し、さらなるリスクを最小限に抑えるために必要な修復措置を講じる際に役立ちます。

この記事は、次のセクションで構成されています。

• 前提条件: 調査を開始する前に完了する必要がある具体的な要件について説明します。 たとえば、有効にする必要があるログ、必要な役割とアクセス許可などです。
• ワークフロー: この調査を実行するために従う必要がある論理フローを示します。
• チェックリスト: フロー チャートの各ステップのタスクの一覧が含まれます。 このチェックリストは、厳しく規制された環境で、完了したことを確認したり、自分の品質ゲートとして役立ちます。
• 調査手順: この特定の調査に関する詳細なステップ バイ ステップ ガイダンスが含まれています。

前提条件

フィッシング調査を進める前に完了する必要がある一般的な設定と構成を次に示します。

アカウントの詳細

調査を進める前に、侵害されたと思われるアカウントのユーザー名、ユーザー プリンシパル名 (UPN)、またはメール アドレスを用意しておくことをおすすめします。

Microsoft 365 の基本要件

監査設定を確認する

Exchange Online PowerShell で次のコマンドを実行して、"既定でメールボックス監査をオンにする" が有効になっていることを確認します。

Get-OrganizationConfig | Format-List AuditDisabled

値 "False" は、個々のメールボックスの "AuditEnabled" プロパティの値に関係なく、組織内のすべてのメールボックスに対してメールボックス監査が有効になっていることを示します。 詳細については、「"既定でメールボックス監査をオンにする" が有効になっていることを確認する」をご覧ください。

メッセージの追跡

メッセージ トレース ログは、メッセージの元の送信元と対象のの受信者を見つけるのに役立つ貴重なコンポーネントです。 メッセージ追跡追跡機能は、https://admin.exchange.microsoft.com/#/messagetrace の Exchange 管理センター (EAC) で、またはExchange Online PowerShell の Get-MessageTrace コマンドレットで使用できます。

Note

メッセージ トレースは、Microsoft Defender ポータル (https://security.microsoft.com) の [メールとコラボレーション]>[Exchange メッセージ トレース] でも利用できますが、これは EAC のメッセージ トレースへのパススルー リンクにすぎません。

メッセージ追跡機能のいくつかのコンポーネントは見てすぐにわかるものですが、Message-ID はメール メッセージの一意の識別子であり、十分に理解する必要があります。 重要なメールの Message-ID を取得するには、生のメール ヘッダーを調べる必要があります。

監査ログ検索

統合監査ログを検索し、Microsoft 365 組織内のユーザーと管理者のすべてのアクティビティを表示します。

サインイン ログや監査ログは外部システムにエクスポートされるか

ほとんどの Microsoft Entra ID サインインと監査データは 30 日または 90 日後に上書きされるため、Sentinel、Azure Monitor、または外部のセキュリティ情報およびイベント管理 (SIEM) システムを使用することをおすすめします。

必要な役割とアクセス許可

Microsoft Entra ID のアクセス許可

調査を行うアカウントに対しては、次の役割のメンバーシップをお勧めしています。

• グローバル閲覧者
• Security Reader
• 最後の手段として、常に全体管理者または社内管理者の役割にフォールバックすることができます

Microsoft 365 のアクセス許可

一般に、Microsoft Defender ポータルまたは Microsoft Purview コンプライアンス ポータルのグローバル閲覧者またはセキュリティ閲覧者の役割グループは、関連するログを検索するための十分なアクセス許可を付与する必要があります。

Note

Microsoft Defender ポータルまたは Microsoft Purview コンプライアンス ポータルのみの表示限定の監査ログまたは監査ログの役割グループのメンバーであるアカウントは、Microsoft 365 監査ログを検索できません。 このシナリオでは、Exchange Online でアクセス許可を割り当てる必要があります。 詳細については、「監査ログの検索の前に」をご覧ください。

使用する役割グループがわからない場合は、「Exchange コマンドレットを実行するために必要なアクセス許可を見つける」を参照してください。

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint (MDE) がある場合は、このフローに使用する必要があります。 詳細については「シグナルの共有と機械学習によるフィッシングへの対処」をご覧ください。

システム要件

ハードウェア要件

システムで PowerShell を実行できる必要があります。

ソフトウェア要件

クラウド環境の調査には、次の PowerShell モジュールが必要です。

• Azure AD PowerShell for Graph モジュール。 詳細については、「Azure Active Directory PowerShell for Graph のインストール」をご覧ください。

  MSOnline (v1) Azure AD モジュールで以前のコマンドレットが必要な場合は、「Microsoft Entra ID (MSOnline)」をご覧ください。

• Exchange Online PowerShell モジュール: インストール手順については、「Exchange Online PowerShell モジュールのインストールとメンテナンス」をご覧ください。

• Microsoft Entra インシデント応答 PowerShell モジュール: インストール手順については、「Microsoft Entra Incident Response PowerShell モジュール」をご覧ください

ワークフロー

![フィッシングの調査のワークフロー]

さらに、以下を実行できます。

• フィッシングやその他のインシデント対応のプレイブックのワークフローを PDF としてダウンロードする。
• フィッシングやその他のインシデント対応のプレイブックのワークフローを Visio ファイルとしてダウンロードする。

チェック リスト

このチェックリストは、調査プロセスを評価し、調査中にすべての手順を完了したかどうかを確認する際に役立ちます。

	最初のフィッシング メールを確認する
	この電子メールを受信したユーザーの一覧を取得する
	ユーザーがメールボックスにアクセスした最新の日付を取得する
	委任されたアクセスがメールボックスに構成されているか
	メールボックスに転送ルールが構成されているか
	Exchange メール フロー ルールをレビューする (トランスポート ルール)
	メール メッセージを検索する
	ユーザーはそのメールを読んだ、または開いたか
	同じ電子メールを他に誰が受信したか
	メールに添付ファイルが含まれていたか
	添付ファイル内にペイロードが存在したか
	電子メール ヘッダーで送信者の真のソースを確認する
	攻撃者またはキャンペーンへの IP アドレスを確認する
	ユーザーはメール内のリンクを選択しましたか?
	どのエンドポイントで電子メールが開かれたか
	添付ファイルのペイロードは実行されたか
	宛先の IP または URL はアクセスされた、または開かれたか
	悪意のあるコードが実行されたか
	フェデレーション シナリオのアカウントで発生したサインインは何か
	マネージド シナリオのアカウントで発生したサインインは何か
	ソース IP アドレスを調査する
	検出したデバイス ID を調査する
	各アプリ ID を調査する

また、フィッシングやその他のインシデント プレイブックのチェックリストを Excel ファイルとしてダウンロードすることもできます。

調査手順

この調査では、調査を開始するために、サンプルのフィッシング メール、または送信者のアドレス、メールの件名などその一部、またはメッセージの一部のいずれかがあることを前提としています。 また、「前提条件」セクションで推奨されているすべての設定を完了または有効にしていることを確認してください。

このプレイブックは、Microsoft のすべてのお客様およびその調査チームが調査対象のテナントで完全版の Microsoft 365 E5 または Microsoft Entra ID P2 ライセンス スイートを使用できる、または構成済みであるとは限らないと考えて作成されています。 ただし、必要に応じて、他の自動化機能について説明します。

電子メールを受信したユーザー (ID) の一覧を取得する

最初の手順として、フィッシング メールを受信したユーザー (ID) の一覧を取得する必要があります。 この手順の目的は、追加の調査手順において繰り返し処理するために後で使用する、潜在的なユーザー (ID) の一覧を記録することです。 この調査中に従う必要がある手順の概要フロー図については、「ワークフロー」セクションをご覧ください。

このプレイブックには、潜在的なユーザー (ID) のこの一覧を記録する方法に関する推奨事項はありません。 調査の規模に応じて、Excel ブック、CSV ファイル、または大規模な調査向けにデータベースも使用できます。 特定のテナントで ID の一覧を取得する方法は複数あり、いくつかの例を次に示します。

Microsoft Purview コンプライアンス ポータルでのコンテンツ検索の作成

収集したインジケーターを使用して、コンテンツ検索を作成して実行します。 手順については、「コンテンツ検索を作成する」をご覧ください。

検索可能なメール プロパティの完全な一覧については、「検索可能なメール プロパティ」をご覧ください。

次の例では、2022 年 4 月 13 日から 2022 年 4 月 14 日の間にユーザーが受信し、件名に "action" と "required" という単語を含むメッセージが返されます。

(Received:4/13/2022..4/14/2022) AND (Subject:'Action required')

次のクエリの例では、chatsuwloginsset12345@outlook.com によって送信され、件名に「アカウント情報を更新してください」という語句がそのとおり含まれているメッセージが返されます。

(From:chatsuwloginsset12345@outlook.com) AND (Subject:"Update your account information")

詳細については、組織内でメッセージを検索および削除する方法に関する記事をご覧ください。

Exchange Online PowerShell で Search-Mailbox コマンドレットを使用する

Exchange Online PowerShell で Search－Mailbox コマンドレットを使用すると、関心のある対象メールボックスに対して特定のクエリを実行し、その結果を無関係の宛先メールボックスにコピーできます。

次のクエリの例では、Jane Smith のメールボックスで、件名に Invoice という語句を含むメールを検索し、その結果を IRMailbox の "Investigation" という名前のフォルダーにコピーします。

Search-Mailbox -Identity "Jane Smith" -SearchQuery "Subject:Invoice" -TargetMailbox "IRMailbox" -TargetFolder "Investigation" LogLevel Full

このコマンドの例では、クエリは、すべてのテナント メールボックスで、件名に "InvoiceUrgent" という語句を含む電子メールを検索し、その結果を IRMailbox の "Investigation" という名前のフォルダーにコピーします。

Get-Mailbox | Search-Mailbox -SearchQuery 'InvoiceUrgent vote' -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full

構文とパラメーターの詳細については、「Search-Mailbox」をご覧ください。

委任されたアクセスがメールボックスに構成されているか

次のスクリプトを使用して、委任されたアクセスがメールボックスに構成されているかどうかを確認する方法をご覧ください。https://github.com/OfficeDev/O365-InvestigationTooling/blob/master/DumpDelegatesandForwardingRules.ps1。

このレポートを作成するには、すべてのユーザーの一覧を取得する小さい PowerShell スクリプトを実行します。 次に、Get-MailboxPermission コマンドレットを使用して、テナント内のすべてのメールボックス委任の CSV ファイルを作成します。

通常とは異なる名前またはアクセス許可付与を探します。 何か異変を認めた場合は、メールボックス所有者に連絡して、それが正当なものであるかどうかを確認してください。

メールボックスに対して転送ルールが構成されているか

メールボックス転送 (SMTP 転送とも呼ばれます) または外部受信者 (通常、新しく作成された受信トレイ ルール) にメール メッセージを転送する受信トレイ ルールについて、識別された各メールボックスを確認する必要があります。

• メールボックス転送についてすべてのメールボックスをチェックするには、Exchange Online PowerShell で次のコマンドを実行します。

  Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize unlimited | Format-Table -Auto MicrosoftOnlineServicesID,ForwardingSmtpAddress,DeliverToMailboxAndForward | Export-csv C:\Temp\Forwarding.csv -NoTypeInformation
  

• 指定した日付の間にメールボックスに作成された受信トレイ ルールをチェックするには、Exchange Online PowerShell で次のコマンドを実行します。

  Search-UnifiedAuditLog -StartDate 12/16/2021 -EndDate 03/16/2022 -ResultSize 5000 -RecordType exchangeadmin -Operations New-InboxRule | Export-csv NoTypeInformation -Path c:\temp\Inboxrulesoutput.csv
  

• Exchange 管理センター (EAC) で自動転送メッセージ レポートを使用することもできます。 手順については、「Exchange Online での自動転送メッセージ レポート」をご覧ください。

  注:

  • 通常とは異なるターゲットの場所や、あらゆる種類の外部アドレス指定がないか探します。
  • "件名に invoice という単語を含むすべてのメール" などの条件で、通常とは異なるキーワードを含む転送ルールを探します。 メールボックス所有者に連絡して、それが正当なものであるかどうかを確認します。

受信トレイ ルールを確認する

受信トレイ ルールの削除を確認し、調査から時間が経っていないタイムスタンプを考慮に入れます。 例として、次の Exchange Online PowerShell コマンドを使用します。

Search-UnifiedAuditLog -StartDate 12/16/2021 -EndDate 03/16/2022 -Operations Remove-InboxRule | Export-CSV NoTypeInformation -Path c:\temp\removedInboxRules.csv

Exchange メール フロー ルール (トランスポート ルール)のレビュー

組織内の Exchange メール フロー ルール (トランスポート ルールとも呼ばれます) の一覧を取得するには、次の 2 つの方法があります。

1. Exchange 管理センターと Exchange Online PowerShell です。 手順については、「メール フロー ルールの表示または変更」をご覧ください。
2. Exchange 管理センターのExchange トランスポート ルールレポート。 手順については、「Exchange Online の Exchange トランスポート ルール レポート」をご覧ください。

新しいルール、またはメールを外部ドメインにリダイレクトするように変更されたルールを探します。 ルールの数は既知であり、比較的少ない必要があります。 監査ログ検索を実行すると、ルールを作成した人物とその作成場所を特定できます。 何か異変を認めた場合は、作成者に連絡して、それが正当なものかどうかを確認してください。

ユーザーがメールボックスにアクセスした最新の日付を取得する

Microsoft 365 セキュリティ/コンプライアンス センターで、統合監査ログに移動します。 ドロップダウン リストの [アクティビティ] で、[Exchange メールボックスのアクティビティ] によってフィルター処理できます。

侵害されたユーザーを一覧表示する機能は、Microsoft 365 セキュリティ/コンプライアンス センターで使用できます。

このレポートには、メールボックスが不正にアクセスされていることを示す可能性があるアクティビティが表示されます。 これには、作成または受信したメッセージ、移動または削除されたメッセージ、コピーまたは消去されたメッセージ、代理送信またはメールボックス所有者として送信を使用して送信されたメッセージ、およびすべてのメールボックス サインインが含まれます。データには、日付、IP アドレス、ユーザー、実行されたアクティビティ、影響を受ける項目、およびすべての拡張された詳細が含まれます。

Note

このデータを記録するには、メールボックス監査オプションを有効にする必要があります。

ここに含まれるデータの量は非常に多くなる可能性があるため、侵害された場合に影響が大きいユーザーに検索の焦点を当てます。 怪しい時間帯や通常とは異なる IP アドレスなどの異常なパターンを探し、さらに大量の移動、消去、または削除などのパターンを探します。

ユーザーはその電子メールを読んだ、または開いたか

次の 2 つの主なケースがあります。

• そのメールボックスが Exchange Onlineにある。
• そのメールボックスがオンプレミスの Exchange (Exchange ハイブリッド) にある。

Exchange Online ユーザーがメールを開いた

Exchange Online PowerShell で Search－Mailbox コマンドレットを使用すると、関心のある対象メールボックスに対して特定の検索クエリを実行し、その結果を無関係の宛先メールボックスにコピーできます。

次のクエリの例では、Janes Smith のメールボックスで、件名に Invoice という語句を含む電子メールを検索し、その結果を IRMailbox の Investigation という名前のフォルダーにコピーします。

Search-Mailbox -Identity "Jane Smith" -SearchQuery "Subject:Invoice" -TargetMailbox "IRMailbox" -TargetFolder "Investigation" LogLevel Full

次のサンプル クエリは、すべてのテナント メールボックスで、件名に InvoiceUrgent という語句を含む電子メールを検索し、その結果を IRMailbox の Investigation という名前のフォルダーにコピーします。

Get-Mailbox | Search-Mailbox -SearchQuery 'InvoiceUrgent vote' -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full

ユーザーが Exchange ハイブリッドでメールを開いた

Get-MessageTrackingLog コマンドレットを使用して、メッセージ追跡ログに格納されているメッセージ配信情報を検索します。 次に例を示します。

Get-MessageTrackingLog -Server Mailbox01 -Start "03/13/2022 09:00:00" -End "03/15/2022 17:00:00" -Sender "john@contoso.com"

構文とパラメーターの詳細については、「Get-MessageTrackingLog」をご覧ください。

同じ電子メールを他に誰が受信したか

次の 2 つの主なケースがあります。

• そのメールボックスが Exchange Onlineにある。
• そのメールボックスがオンプレミスの Exchange (Exchange ハイブリッド) にある。

ワークフローは基本的に、「電子メールを受信したユーザーまたは ID の一覧を取得する」セクションで説明されているものと同じです。

Exchange Online でメールを検索する

Search-Mailbox コマンドレットを使用して、関心のある対象メールボックスに対して特定の検索クエリを実行し、その結果を無関係の宛先メールボックスにコピーします。

次のサンプル クエリは、すべてのテナント メールボックスで、件名に InvoiceUrgent という語句を含む電子メールを検索し、その結果を Investigation という名前のフォルダー内の IRMailbox にコピーします。

Get-Mailbox | Search-Mailbox -SearchQuery "Subject:InvoiceUrgent" -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full

オンプレミス Exchange でメールを検索する

Get-MessageTrackingLog コマンドレットを使用して、メッセージ追跡ログに格納されているメッセージ配信情報を検索します。 次に例を示します。

Get-MessageTrackingLog -Server Mailbox01 -Start "03/13/2018 09:00:00" -End "03/15/2018 17:00:00" -MessageSubject "InvoiceUrgent"

構文とパラメーターの詳細については、「Get-MessageTrackingLog」をご覧ください。

メールに添付ファイルが含まれていたか

次の 2 つの主なケースがあります。

• そのメールボックスが Exchange Onlineにある。
• そのメールボックスがオンプレミスの Exchange (Exchange ハイブリッド) にある。

メッセージに Exchange Online の添付ファイルが含まれているかどうかを確認する

メールボックスが Exchange Online にある場合は、次の 2 つのオプションがあります。

• 従来の Search-Mailbox コマンドレットを使用する
• New-ComplianceSearch コマンドレットを使用する

Search-Mailbox コマンドレットを使用して、関心のある対象メールボックスに対して特定の検索クエリを実行し、その結果を無関係の宛先メールボックスにコピーします。 次に例を示します。

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery attachment:trojan* -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full

構文とパラメーターの詳細については、「Search-Mailbox」をご覧ください。

もう 1 つのオプションは、New-ComplianceSearch コマンドレットを使用することです。 次に例を示します。

New-ComplianceSearch -Name "Investigation" -ExchangeLocation "Research Department" -ContentMatchQuery "from:pilar@contoso.com AND hasattachment:true"

構文とパラメーターの詳細については、「New-ComplianceSearch」をご覧ください。

メッセージにオンプレミス Exchange の添付ファイルが含まれているかどうかを確認する

Note

Exchange Server 2013 では、この手順には累積的な更新プログラム 12 (CU12) 以降が必要です。 詳細については、 こちらの記事をご覧ください。

Search-Mailbox コマンドレットを使用して、メッセージ追跡ログに格納されているメッセージ配信情報を検索します。 次に例を示します。

Search-Mailbox -Identity "Jane Smith"-SearchQuery AttachmentNames:attachment_name -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full

構文とパラメーターの詳細については、「Search-Mailbox」をご覧ください。

添付ファイル内にペイロードが存在したか

添付ファイル内の悪意のある可能性のあるコンテンツを探します。 たとえば、PDF ファイル、難読化された PowerShell、その他のスクリプト コードなどです。

脅威に対する保護状態レポートの [メール > マルウェアによるデータの表示] ビューには、組織に対するマルウェアが含まれているとして検出された受信および送信メッセージの数が表示されます。 詳細については、「脅威保護の状態レポート: メール > マルウェアによるデータの表示」をご覧ください。

電子メール ヘッダーで送信者の真のソースを確認する

メッセージ トレース機能の多くのコンポーネントは見てすぐにわかるものですが、Message-ID については十分に理解している必要があります。 Message-ID は、電子メール メッセージの一意の識別子です。

関心のある電子メールの Message-ID を取得するには、生の電子メール ヘッダーを調べる必要があります。 Microsoft Outlook または Outlook on the Web (旧称 Outlook Web App または OWA) でこれを行う方法については、「Outlook でインターネット メッセージ ヘッダーを表示する」をご覧ください。

電子メール ヘッダーを表示する場合は、読みやすくするためにヘッダー情報をコピーして、MXToolbox や Azure によって提供される電子メール ヘッダー アナライザーに貼り付けることをお勧めします。

• ヘッダーのルーティング情報: ルーティング情報は、コンピューター間で転送される電子メールのルートを提供します。

• Sender Policy Framework (SPF): スプーフィングの防止または検出に役立つ電子メール検証。 SPF レコードでは、ドメインに代わってメールを送信できる IP アドレスとドメインを特定できます。

• SPF = Pass: SPF TXT レコードにより、ドメインに代わって送信者が送信することが許可されると判断されました。

  • SPF = Neutral
  • SPF = Fail: ポリシー構成により、メッセージ センダー IPの成果が決定されます
  • SMTP メール: これが正当なドメインであるかどうか検証します

  SPF の詳細については、「Microsoft 365 で SPF を使用してスプーフィングを防ぐ方法」をご覧ください 。

• 一般的な値: 最も一般的に使用および参照されるヘッダーとその値の内訳を次に示します。 これは重要な情報であり、脅威エクスプローラーの [検索] フィールドで使用できます。

  • 送信元アドレス
  • 情報カテゴリ
  • メッセージ ID
  • 宛先アドレス
  • Return-path アドレス

• Authentication-Results: 電子メールが送信されたときに電子メール クライアントが認証した内容を確認できます。 これにより、SPF および DKIM 認証が提供されます。

• 送信元 IP: 元の IP を使用して、IP がブロックリストに登録されているかどうかを判断し、地域の場所を取得できます。

• スパムの確実性レベル (SCL): これにより、受信電子メールがスパムである可能性が特定されます。

  • -1: 信頼できる差出人、安全な受信者、またはセーフ リストに登録された IP アドレス (信頼されたパートナー) からのほとんどのスパム フィルタリングをパイパスする
  • 0、1: メッセージがスキャンされ、クリーンであると判断されたため、スパムではない
  • 5、6: スパム
  • 7、8、9: スパム (確実性が高い)

SPF レコードは DNS データベース内に格納され、DNS 検索情報と共にバンドルされます。 nslookup コマンドを使用して、ドメインの Sender Policy Framework (SPF) レコードを手動で確認できます。

1. コマンド プロンプトを開きます ([スタート] > [実行] > [コマンド])。

2. コマンドを次のように入力します: nslookup -type=txt"、1 つのスペース、その後にドメインまたはホスト名。 次に例を示します。

    nslookup -type=txt domainname.com
   

Note

-all (それらを拒否または不合格にする - 何かが一致しない場合は電子メールを配信しない) を使用することをお勧めします。

Microsoft 365 のカスタム ドメインで DKIM が有効になっているかどうかを確認する

ドメイン キーで特定されたメール (DKIM) を追加するすべてのドメインに対して、2 つの CNAME レコードを発行する必要があります。 DKIM を使用してカスタム ドメインからの送信メールを検証する方法をご覧ください。

ドメイン ベースのメッセージ認証、レポート、および適合性 (DMARC) を確認する

この機能を使用して、Microsoft 365 の送信メールを検証することができます。

攻撃者またはキャンペーンへの IP アドレスを確認する

前の調査手順で特定された IP アドレスを確認または調査する場合は、次のオプションのいずれかを使用できます。

• VirusTotal
• Microsoft Defender for Endpoint
• 公開されているソース:
  • Ipinfo.io - 地域の場所を取得する無料のオプションがあります
  • Censys.io - インターネットの受動的スキャンによって把握される内容に関する情報を取得する無料のオプションがあります
  • AbuseIPDB.com - 何らかの位置情報を提供する無料のオプションがあります
  • Ask Bing と Google - IP アドレスで検索する

URL の評価

SmartScreen テクノロジを利用する Windows 10 デバイスおよび Microsoft Edge ブラウザーを使用できます。

サードパーティによる URL の評価の例をいくつか次に示します

• トレンドマイクロによるサイトの安全性の確認
• Google 透明性レポート
• Talos Intelligency

IP アドレスと URL を調査するときに、IP アドレスを検索して、セキュリティ侵害のインジケーター (IOC) または他のインジケーターに関連付け、その出力または結果に応じて、敵対者からのソースの一覧にそれらを追加します。

ユーザーはメール内のリンクをクリックしたか

ユーザーが電子メール内のリンクを (意図的に、または意図せずに) クリックした場合、通常、このアクションによってデバイス自体に新しいプロセスが作成されます。 これが実行されたデバイスに応じて、デバイス固有の調査を実行する必要があります。 たとえば、Windows と Android と iOS です。 この記事では、一般的なアプローチと、Windows ベースのデバイスに関するいくつかの詳細について説明します。 Microsoft Defender for Endpoint (MDE) を使用している場合は、iOS に対してもこれを利用できます (Android は近日中)。

Microsoft Defender for Endpoint を使用してこれらのイベントを調査できます。

1. VPN / プロキシ ログ プロキシと VPN ソリューションのベンダーによっては、関連するログを確認する必要があります。 このイベントを SIEM または Microsoft Sentinel に転送しているのであれば理想的です。

2. Microsoft Defender for Endpoint を使用 これは、Microsoft の脅威インテリジェンスと自動化された分析を使用して調査を行うことができるため、ベストケースのシナリオです。 詳細については、「Microsoft Defender for Endpoint でアラートを調査する方法に関する記事をご覧ください。

   アラート プロセス ツリーでは、アラートのトリアージと調査が次のレベルに進み、同じ実行コンテキストと期間内に発生した、集計されたアラートと周囲の証拠が表示されます。

3. Windows ベースのクライアント デバイスプロセス作成イベントのオプションが有効になっていることを確認します。 また、コマンドライン トレース イベントも有効にすることをお勧めします。

   調査の前に上記の監査イベントが有効になっている Windows クライアントでは、監査イベント 4688 を確認し、電子メールがユーザーに配信された時刻を確認することができます。

   

   

どのエンドポイントで電子メールが開かれたか

ここでのタスクは、前の調査手順「ユーザーは電子メール内のリンクをクリックしたか」と類似しています。

添付されたペイロードは実行されたか

ここでのタスクは、前の調査手順「ユーザーは電子メール内のリンクをクリックしたか」と類似しています。

宛先の IP または URL はアクセスされた、または開かれたか

ここでのタスクは、前の調査手順「ユーザーは電子メール内のリンクをクリックしたか」と類似しています。

悪意のあるコードが実行されたか

ここでのタスクは、前の調査手順「ユーザーは電子メール内のリンクをクリックしたか」と類似しています。

アカウントでどのようなサインインが発生したか

アカウントで発生したさまざまなサインインを確認します。

フェデレーション シナリオ

監査ログの設定とイベントは、オペレーティング システム (OS) レベルと Active Directory フェデレーション サービス (ADFS) サーバーのバージョンによって異なります。

さまざまなサーバー バージョンについては、次のセクションをご覧ください。

Server 2012 R2

既定では、セキュリティ イベントは Server 2012 R2 では監査されません。 ファーム内の各 ADFS サーバーでこの機能を有効にする必要があります。 ADFS 管理コンソールで、[フェデレーション サービスのプロパティの編集] を選択します。

また、OS 監査ポリシーを有効にする必要があります。

コマンド プロンプトを開き、管理者として次のコマンドを実行します。

auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable

詳細については、「トラブルシューティングのために ADFS サーバーを構成する方法」をご覧ください。

次の場所から ADFS PowerShell モジュールをダウンロードすることもできます。

• GitHub
• Microsoft scriptcenter

Server 2016 以降

既定では、Windows Server 2016 の ADFS では基本的な監査が有効になっています。 基本的な監査では、管理者が表示できるイベントは、1 つの要求に対して 5 つ以下です。 ただし、次のコマンドを使用して、監査レベルを上げたり下げたりすることができます。

Set-AdfsProperties -AuditLevel Verbose

詳細については、「Windows サーバーでの ADFS の監査の機能強化」をご覧ください。

Microsoft Entra Connect Health がインストールされている場合、危険な IP レポートも確認する必要があります。 失敗したサインイン アクティビティのクライアント IP アドレスが、Web アプリケーション プロキシ サーバーを介して集計されます。 危険な IP のレポートの各項目は、指定されたしきい値を超える、失敗した AD FS サインイン アクティビティに関する集計情報を示しています。

詳細については、「危険な IP のレポート」をご覧ください。

Server 2012 R2

イベント ID 342 – ADFS 管理ログの "ユーザー名またはパスワードが正しくありません"。

実際の監査イベントについては、セキュリティイベントログを確認する必要があります。また、ソースが "AD FS の監査" である、"クラシック、失敗の監査" のイベント ID 411 のイベントを検索する必要があります。 また、認証が成功したときのイベント ID 412 を探します。

イベント ID 411 - "SecurityTokenValidationFailureAudit トークン" の検証に失敗しました。 詳細については、内部例外をご覧ください。

イベントを対応するイベント ID 501 と関連付けることが必要になる場合があります。

Server 2016 以降

実際の監査イベントについては、セキュリティ イベント ログを確認する必要があります。また、成功した認証イベントに関するイベント ID 1202 および失敗に関する 1203 のイベントを探す必要があります。

イベント ID 1202 の例:

イベント ID 1202 FreshCredentialSuccessAudit フェデレーション サービスは、新しい資格情報を検証しました。 詳細については XML をご覧ください。

イベント ID 1203 の例:

イベント ID 1203 FreshCredentialFailureAudit フェデレーション サービスは、新しい資格情報を検証できませんでした。 エラーの詳細については、XML をご覧ください。

OS レベルごとの ADFS イベント ID の完全な一覧を取得するには、GetADFSEventList をご覧ください。

マネージド シナリオ

調査しているユーザーの Microsoft Entra サインイン ログを確認します。

• Microsoft Entra 管理センター > サインイン画面に移動します。
• サインイン アクティビティを確認します
• GitHub の PowerShell 関数を確認します

Microsoft Entra 管理センターで、[サインイン] 画面に移動し、次の図に示すように、前の調査手順で見つけた期間の表示フィルターを追加または変更し、さらにユーザー名をフィルターとして追加します。

Graph API を使用して検索することもできます。 たとえば、ユーザー プロパティをフィルター処理し、lastSignInDate と共に取得します。 特定のユーザーを検索して、そのユーザーの最後のサインイン日を取得します。 たとえば、https://graph.microsoft.com/beta/users?$filter=startswith(displayName,'Dhanyah')&$select=displayName,signInActivity のように指定します。

または、PowerShell コマンド Get-AzureADUserLastSignInActivity を使用して、オブジェクト ID の対象となるユーザーの最後の対話型サインイン アクティビティを取得できます。 この例では、実行ディレクトリ内の日付と時刻のスタンプ付き CSV ファイルに出力を書き込みます。

Get-AzureADUserLastSignInActivity -TenantId 536279f6-1234-2567-be2d-61e352b51eef -UserObjectId 69447235-0974-4af6-bfa3-d0e922a92048 -CsvOutput

または、AzureADIncidentResponse PowerShell モジュールから次のコマンドを使用できます。

Get-AzureADIRSignInDetail -UserId johcast@Contoso.com -TenantId 536279f6-1234-2567-be2d-61e352b51eef -RangeFromDaysAgo 29 -RangeToDaysAgo 3

ソース IP アドレスを調査する

Microsoft Entra サインイン ログまたは ADFS/フェデレーション サーバーのログ ファイルで見つかったソース IP アドレスに基づいて、トラフィックが発生した場所をさらに調査します。

マネージド ユーザー

マネージド シナリオの場合、サインイン ログを確認し、ソース IP アドレスに基づいてフィルター処理を開始する必要があります。

または、AzureADIncidentResponse PowerShell モジュールから次のコマンドを使用できます。

Get-AzureADIRSignInDetail -IpAddress 1.2.3.4 -TenantId 536279f6-1234-2567-be2d-61e352b51eef -RangeFromDaysAgo 29 -RangeToDaysAgo 3 -OutGridView

結果リストを見て、[デバイス情報] タブに移動します。使用するデバイスに応じて、さまざまな出力が表示されます。 次に例をいくつか示します。

• 例 1 - アンマネージド デバイス (BYOD):

  

• 例 2 - マネージド デバイス (Microsoft Entra 参加またはMicrosoft Entra ハイブリッド参加)

  

[デバイス ID] を確認します (存在する場合)。 OS とブラウザーまたは UserAgent 文字列も確認する必要 があります。

"相関 ID"、"要求 ID"、および timestamp を記録します。 確認結果を他のイベントに関連付けるには、"相関 ID" と timestamp を使用する必要があります。

フェデレーション ユーザーおよびアプリケーション

フェデレーション サインイン シナリオで提供されているのと同じ手順に従います。

"デバイス ID、OS レベル、相関 ID、要求 ID" を探して記録します。

識別されたデバイス ID の調査

この手順は、Microsoft Entra ID に対して既知であるデバイスのみに関連しています。 たとえば、前の手順で考えられるデバイス ID が 1 つ以上見つかった場合は、このデバイスでさらに調査できます。 "デバイス ID" と "デバイスの所有者" を見つけて記録します。

各 AppID を調査する

ここでの開始点は、サインイン ログと、テナントのアプリ構成またはフェデレーション サーバーの構成です。

マネージド シナリオ

前に検出されたサインイン ログの詳細で、[基本情報] タブの "アプリケーション ID" を確認します。

アプリケーション (および ID) とリソース (および ID) の違いに注意してください。 アプリケーションが関連するクライアント コンポーネントであるのに対し、リソースは Microsoft Entra ID のサービスまたはアプリケーションです。

この AppID を使用して、テナントで調査を実行できます。 次に例を示します。

Get-MgApplication -Filter "AppId eq '30d4cbf1-c561-454e-bf01-528cd5eafd58'"

Id                                       AppId                                    DisplayName

3af6dc4e-b0e5-45ec-8272-56f3f3f875ad     30d4cbf1-c561-454e-bf01-528cd5eafd58     Claims X-Ray

この情報を使用すると、エンタープライズ アプリケーション ポータルで検索できます。 [すべてのアプリケーション] に移動し、特定の AppID を検索します。

その他のインシデント対応プレイブック

次の追加の種類の攻撃を特定して調査するためのガイダンスを確認してください。

• パスワード スプレー
• アプリへの同意
• Microsoft Microsoft インシデント対応チームのランサムウェアのアプローチとベスト プラクティス

インシデント対応のリソース

• 新規担当者および経験豊富なアナリスト向けの Microsoft セキュリティ製品およびリソースの概要
• セキュリティ オペレーション センター (SOC) の計画
• Microsoft Defender XDR のインシデント対応
• Microsoft Defender for Cloud (Azure)
• Microsoft Sentinel のインシデント応答
• Microsoft インシデント対応チーム ガイドでセキュリティ チームとリーダー向けのベスト プラクティスを共有
• Microsoft インシデント対応ガイドは、セキュリティ チームによる疑わしいアクティビティの分析で役に立つ