フィッシングの調査
この記事では、組織内でのフィッシング攻撃の特定と調査に関するガイダンスを提供します。 詳細な手順は、情報を保護し、さらなるリスクを最小限に抑えるために必要な修復措置を講じる際に役立ちます。
この記事は、次のセクションで構成されています。
- 前提条件: 調査を開始する前に完了する必要がある具体的な要件について説明します。 たとえば、有効にする必要があるログ、必要な役割とアクセス許可などです。
- ワークフロー: この調査を実行するために従う必要がある論理フローを示します。
- チェックリスト: フロー チャートの各ステップのタスクの一覧が含まれます。 このチェックリストは、厳しく規制された環境で、完了した項目を検証したり、自分の品質ゲートとして役立ちます。
- 調査手順: この特定の調査に関する詳細なステップ バイ ステップ ガイダンスが含まれています。
前提条件
フィッシング調査を進める前に完了する必要がある一般的な設定と構成を次に示します。
アカウントの詳細
調査に進む前に、侵害されたと思われるアカウントのユーザー名、ユーザー プリンシパル名 (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 日後に上書きされるため、Microsoft Sentinel、Azure Monitor、または外部のセキュリティ情報およびイベント管理 (SIEM) システムを使用することをお勧めします。
必要な役割とアクセス許可
Microsoft Entra ID のアクセス許可
調査を行うアカウントは、少なくともセキュリティ閲覧者にすることをお勧めします。
Microsoft 365 のアクセス許可
Microsoft Defender ポータルまたは Microsoft Purview コンプライアンス ポータルのセキュリティ閲覧者役割により、関連するログを検索するための十分なアクセス許可を得ることができます。
使用する役割がわからない場合は、「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 ファイルとしてダウンロードすることもできます。
調査手順
この調査では、フィッシングメールのサンプルまたはメールの一部を取得しています。 たとえば、送信者のアドレス、電子メールの件名、または調査を開始するためのメッセージの一部があるとします。 また、「 Prerequisites 」セクションで推奨されるすべての設定が完了し、有効になっていることを確認します。
電子メールを受信したユーザー (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.csvExchange 管理センター (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 つの方法があります。
- Exchange 管理センターと Exchange Online PowerShell です。 手順については、「メール フロー ルールの表示または変更」をご覧ください。
- Exchange 管理センターのExchange トランスポート ルールレポート。 手順については、「Exchange Online の Exchange トランスポート ルール レポート」をご覧ください。
新しいルールまたは変更されたルールを探して、メールを外部ドメインにリダイレクトします。 ルールの数は既知であり、比較的少ない必要があります。 監査ログ検索を実行すると、ルールを作成した人物とその作成場所を特定できます。 異常な内容が表示された場合は、作成者に連絡して、それが正当であるかどうかを判断してください。
ユーザーがメールボックスにアクセスした最新の日付を取得する
Microsoft Defender ポータルまたはMicrosoft Purview コンプライアンス ポータルで、未確認の監査ログに移動します。 ドロップダウン リストの [アクティビティ] で、[Exchange メールボックスのアクティビティ] によってフィルター処理できます。
侵害されたユーザーを一覧表示する機能は、 Microsoft Defender ポータルで利用できます。
このレポートには、メールボックスが不正にアクセスされていることを示す可能性があるアクティビティが表示されます。 これには、作成または受信したメッセージ、移動または削除されたメッセージ、コピーまたは消去されたメッセージ、代理送信またはメールボックス所有者として送信を使用して送信されたメッセージ、およびすべてのメールボックス サインインが含まれます。データには、日付、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) レコードを手動で確認できます。
コマンド プロンプトを開きます ([スタート] > [実行] > [コマンド])。
コマンドを次のように入力します:
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 評判の例をいくつか次に示します。
IP アドレスと URL を調査するときに、IP アドレスを検索して、セキュリティ侵害のインジケーター (IOC) または他のインジケーターに関連付け、その出力または結果に応じて、敵対者からのソースの一覧にそれらを追加します。
ユーザーはメール内のリンクを選択しましたか?
ユーザーが電子メール内のリンクをクリックした場合 (目的に応じて)、通常、このアクションによってデバイス自体に新しいプロセスが作成されます。 これが実行されたデバイスに応じて、デバイス固有の調査を実行する必要があります。 たとえば、Windows と Android と iOS です。 この記事では、一般的なアプローチと、Windows ベースのデバイスに関するいくつかの詳細について説明します。 Microsoft Defender for Endpoint (MDE) を使用している場合は、iOS と間もなく Android でも使用できます。
Microsoft Defender for Endpoint を使用してこれらのイベントを調査できます。
VPN / プロキシ ログ プロキシと VPN ソリューションのベンダーによっては、関連するログを確認する必要があります。 イベントを SIEM または Microsoft Sentinel に転送するのが理想的です。
Microsoft Defender for Endpoint を使用 これは、Microsoft の脅威インテリジェンスと自動化された分析を使用して調査を行うことができるため、ベストケースのシナリオです。 詳細については、「 Microsoft Defender for Endpoint でアラートを調査する方法を参照してください。
アラート プロセス ツリーでは、アラートのトリアージと調査が次のレベルに進み、同じ実行コンテキストと期間内に発生した、集計されたアラートと周囲の証拠が表示されます。
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 モジュールをダウンロードすることもできます。
Server 2016 以降
既定では、Windows Server 2016 の ADFS では基本的な監査が有効になっています。 基本的な監査では、管理者が表示できるイベントは、1 つの要求に対して 5 つ以下です。 ただし、次のコマンドを使用して、監査レベルを上げたり下げたりすることができます。
Set-AdfsProperties -AuditLevel Verbose
詳細については、「 Windows Server での ADFS の機能強化の監査を参照してください。
Microsoft Entra Connect Health がインストールされている場合、危険な IP レポートも確認する必要があります。 失敗したサインイン アクティビティのクライアント IP アドレスが、Web アプリケーション プロキシ サーバーを介して集計されます。 危険な IP のレポートの各項目は、指定されたしきい値を超える、失敗した AD FS サインイン アクティビティに関する集計情報を示しています。
詳細については、 Risky 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 をご覧ください。
マネージド シナリオ
調査している 1 人以上のユーザーの 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 aaaabbbb-0000-cccc-1111-dddd2222eeee -UserObjectId aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb -CsvOutput
または、AzureADIncidentResponse PowerShell モジュールから次のコマンドを使用できます。
Get-AzureADIRSignInDetail -UserId johcast@Contoso.com -TenantId aaaabbbb-0000-cccc-1111-dddd2222eeee -RangeFromDaysAgo 29 -RangeToDaysAgo 3
ソース IP アドレスを調査する
Microsoft Entra サインイン ログまたは ADFS/Federation Server ログ ファイルで見つかったソース IP アドレスに基づいて、トラフィックの発生元を確認するためにさらに調査します。
マネージド ユーザー
マネージド シナリオの場合、サインイン ログを確認し、ソース IP アドレスに基づいてフィルター処理を開始する必要があります。
または、AzureADIncidentResponse PowerShell モジュールから次のコマンドを使用できます。
Get-AzureADIRSignInDetail -IpAddress 1.2.3.4 -TenantId aaaabbbb-0000-cccc-1111-dddd2222eeee -RangeFromDaysAgo 29 -RangeToDaysAgo 3 -OutGridView
結果の一覧を調べるときに、 Device info タブに移動します。使用するデバイスに応じて、さまざまな出力が表示されます。 次に例をいくつか示します。
例 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 を確認する方法のスクリーンショット。](media/incident-response-playbook-phishing/ir-managed-scenario-1.png)
アプリケーション (および ID) とリソース (および ID) の違いに注意してください。 アプリケーションが関連するクライアント コンポーネントであるのに対し、リソースは Microsoft Entra ID のサービスまたはアプリケーションです。
この AppID を使用して、テナントで調査を実行できます。 次に例を示します。
Get-MgApplication -Filter "AppId eq '00001111-aaaa-2222-bbbb-3333cccc4444'"
Id AppId DisplayName
3af6dc4e-b0e5-45ec-8272-56f3f3f875ad 00001111-aaaa-2222-bbbb-3333cccc4444 Claims X-Ray
この情報を使用すると、エンタープライズ アプリケーション ポータルで検索できます。 [すべてのアプリケーション] に移動し、特定の AppID を検索します。
追加のインシデント対応プレイブック
これらの他の種類の攻撃を特定して調査するためのガイダンスを確認します。
インシデント対応のリソース
- 新規担当者および経験豊富なアナリスト向けの Microsoft セキュリティ製品およびリソースの概要
- セキュリティ オペレーション センター (SOC) の計画
- Microsoft Defender XDR のインシデント対応
- Microsoft Defender for Cloud (Azure)
- Microsoft Sentinel のインシデント応答
- Microsoft インシデント対応チーム ガイドでセキュリティ チームとリーダー向けのベスト プラクティスを共有
- Microsoft インシデント対応ガイドは、セキュリティ チームによる疑わしいアクティビティの分析で役に立つ