雲に隠れる: Office 365 への攻撃に関する洞察と、Mandiant Managed Defense による調査方法

obscured365 news

ビジネス メール侵害 (BEC)が減速の兆しを見せていないため、セキュリティ アナリストが Office 365 (O365) の侵害を理解し、それらを適切に調査する方法がますます重要になっています。このブログ投稿は、まだ O365 BEC に足を踏み入れていない人を対象としており、Microsoft のクラウド生産性スイートと、調査担当者に役立つさまざまなログとデータ ソースに関する短期集中コースを提供します。また、BEC への対応中に観察した一般的な攻撃者の戦術についても説明し、Mandiant Managed Defense のアナリストが PowerShell と FireEye Helix プラットフォームを使用してお客様の調査にどのようにアプローチしているかについての洞察を提供します。

オフィス 365

Office 365 は、Microsoft Office スイート向けの Microsoft のクラウドベースのサブスクリプション サービスです。これは、今日の従業員の生活にしっかりと組み込まれている数十のアプリケーションから構築されています。

  • Exchange Online、電子メール用
  • SharePoint、イントラネット ポータルおよびドキュメント共有用
  • インスタント メッセージング用の Teams と Skype for Business
  • OneDrive、ファイル共有用
  • 記録された会議とプレゼンテーション用の Microsoft Stream

ニーズを満たすために Microsoft のクラウドベースのサービスを採用することを決定する組織が増えるにつれて、これらの O365 環境 (Microsoft の用語で言えばテナント) への不正アクセスは、動機付けられた攻撃者にとってますます儲かるようになっています。 O365 の現在の採用率が高いということは、攻撃者がプラットフォームの使用と悪用について十分な経験を積んでいることを意味します。多くの戦術は、最初に観察されてから何年もの間、ほとんど変わっていませんが、セキュリティ意識の高いユーザーに対しても効果的な技術の進化も目の当たりにしています.

一般に、私たちが対応した O365 の侵害は、次の 2 つのカテゴリに分類されます。

  • ビジネスメール侵害 (BEC)
  • APTまたは国家が支援する侵入

私たちの経験に基づくと、BEC はあらゆる組織の Office 365 テナントにとって一般的な脅威です。 「BEC」という用語は、通常、金銭目的の攻撃者が犯した一種の詐欺を指します。 BEC アクターは、ソーシャル エンジニアリングに大きく依存してスキームを実行し、最終的に組織や人員をだます.

一般的な BEC スキームの 1 つは、フィッシングを介して経営幹部のアカウントを侵害することです。被害者が無意識のうちに正規の Office 365 ログイン ポータルになりすました Web フォームに資格情報を入力すると、攻撃者はログインし、組織内の他のユーザーに電信送金を行うように指示します。 .ただし、攻撃者が財務状況にある人を侵害し、支払期日に関する電子メール通信が開始されるまで辛抱強く待つという、より効果的なスキームも観察されています。攻撃者は、侵害されたユーザーに代わって、支払いを担当する別の被害者に改竄された請求書 (以前に盗まれた正当な請求書に基づく場合もあります) を送信することで、この機会を利用します。これらの電子メールは通常、攻撃者が作成した Outlook メールボックス ルールにより、侵害されたユーザーから隠されています。多くの場合、数日または数週間後にスキームが必然的に発見され理解されるまでに、お金は取り戻せません。

スタッフの個人的な財政も、攻撃者の立ち入りが禁止されているわけではありません。私たちは、W-2 詐欺の事例をいくつか観察しており、攻撃者が被害者のアカウントから W-2 情報を求める要求を HR に送信します。この個人を特定できる情報は、取得されると、後で税金詐欺を行うために使用されます。

逆に、APT による侵入は通常、より高度で、国家が支援する攻撃者によって実行されます。 APT アクターは通常、金銭的利益のためではなく、スパイ活動、データの盗難、または破壊の目的で O365 テナントを侵害する任務を負っています。特定の組織の O365 テナントに大量の機密情報が格納されていることを考えると、APT アクターは、組織が実装および投資してきた多くのセキュリティ制御を回避して、ミッションを完了するために 1 つのエンドポイントに触れる必要さえないかもしれません。

O365 ログとデータ ソース

このセクションでは、O365 調査に関連するフォレンジック データを含む多数のログとポータルについて説明します。

O365 ケースの調査を開始する前に、クライアントと協力して、必要なフォレンジック データを取得するために必要な役割がプロビジョニングされた「Investigator」アカウントを取得します。このブログ投稿の目的のために、Investigator アカウントに必要なロールを簡単にリストしますが、アクティブな Managed Defense 調査中に、指定された Managed Defense コンサルタントがアカウント プロビジョニングに関する詳細なガイダンスを提供します。

Investigator アカウントには、少なくとも次の役割が必要です。

Exchange 管理者の役割

  • 表示専用の監査ログ
  • 表示専用構成
  • 閲覧のみの受信者
  • メールボックス検索
  • メッセージ追跡

電子情報開示の権利

  • 電子情報開示マネージャーの役割

Azure Active Directory の役割

  • グローバルリーダー

統合監査ログ (UAL)

統合監査ログは、Office 365 スイート内のさまざまなアプリケーションからのアクティビティを記録し、O365 の主要なログ ソースと見なすことができます。 UAL のエントリは JSON 形式で保存されます。 UAL は、 protection.office.comにある Office 365 セキュリティ & コンプライアンス センターから取得することもできますが、PowerShell コマンドレットSearch-UnifiedAuditLogを使用して UAL をクエリすることをお勧めします。このログ ソース (および管理者監査ログ) を利用するには、監査ログ検索機能が有効になっていることを確認してください。

UAL には、考慮すべき重要なニュアンスがいくつかあります。さまざまな O365 アプリケーションにわたるアクティビティの高レベルの要約を提供しますが、包括的なメールボックス アクティビティを記録しません (そのために、メールボックス監査ログを取得します)。さらに、UAL にはいくつかの制限があります。

  • 1 つのクエリの結果は 5000 件に制限されています
  • 90 日間のアクティビティのみが保持されます
  • イベントが検索可能になるまでに最大 24 時間かかる場合があります

メールボックス監査ログ (MAL)

Exchange Online の一部であるメールボックス監査ログは、メールボックス内のオブジェクトに対して実行された追加のアクションをキャプチャします。そのため、PowerShell コマンドレットSearch-MailboxAuditLogを使用して、影響を受ける各ユーザー アカウントの MAL を取得して分析することをお勧めします。 MAL のエントリは (デフォルトで) 90 日間保持され、タイムスタンプはユーザーのローカル タイム ゾーンに基づくことに注意してください。 MAL の保存期間は、PowerShell コマンドレットのSet-MailboxAuditLogAgeLimitパラメーターを使用して、いつでも増やすことができます。

この記事を書いている時点で、Microsoft は最近、攻撃者がどの電子メールにアクセスしたかについて調査者に洞察を与える強化された監査機能に関する情報をリリースしました。通常のユーザー アカウントのこのレベルのログ記録は、Office 365 E5 サブスクリプションを持つ組織でのみ利用できます。高度な監査が有効になると、メール アクセス アクティビティは、UAL と MAL の両方のMailItemsAccessed操作でログに記録されます。

管理者監査ログ

監査ログ検索機能が有効になっている場合、この補足データ ソースは、管理者が実行したすべての PowerShell 管理コマンドレット (コマンド ライン引数を含む) を記録します。管理者アカウントが侵害された疑いがある場合は、このログを見逃さないでください。 PowerShell コマンドレットSearch-AdminAuditLogを使用してこれらのログを照会しますが、監査ログ検索機能を有効にする必要があり、同じ 90 日間の保持制限が適用されることに注意してください。

Azure AD ログ

Azure AD ログには、Azure Active Directory サービスの下の Azure ポータル ( portal.azure.com ) からアクセスできます。 Azure AD サインイン ログには、認証の発生方法と O365 アプリケーションの使用状況に関する詳細情報が含まれています。 Azure AD 監査ログも貴重な情報源であり、パスワードのリセット、アカウントの作成、ロールの変更、OAuth 付与などの記録が含まれており、疑わしいアクティビティを示している可能性があります。 Azure AD ログは 30 日間しか利用できないことに注意してください。

クラウド アプリ セキュリティ ポータル

OAuth の悪用が確認された場合、クラウド アプリケーションに関する情報は、Microsoft の Cloud App Security ポータル ( portal.cloudappsecurity.com ) で確認できます。このポータルへのアクセスには、E5 ライセンスまたはスタンドアロンのクラウド アプリ ライセンスが必要です。 OAuth の悪用に関する背景情報については、ブログ記事「 Shining a Light on OAuth Abuse with PwnAuth 」をご覧ください

メッセージのトレース

メッセージ追跡は、ユーザーが送受信した電子メールを記録します。調査中に、関心のあるすべての電子メール アドレスについてレポートを実行します。メッセージ トレース レポートには、詳細なメール フロー情報、件名、元のクライアント IP アドレス、およびメッセージ サイズが含まれます。メッセージ追跡は、侵害されたアカウントから攻撃者によって送信された電子メールを識別するのに役立ちます。また、フィッシングが最初のアクセスに使用された場合、最初のフィッシング メールを識別するのにも役立ちます。実際の電子メールを取得するには、コンテンツ検索ツールを使用します。

Get-MessageTrace PowerShell コマンドレットで利用できるのは、過去 10 日間のアクティビティのみです。古いメッセージの履歴検索は、 Get-HistoricalSearchコマンドレットを使用して実行できます (既定では最大 90 日) が、通常、履歴検索ではレポートが利用可能になるまで数時間かかります。履歴レポートは、セキュリティおよびコンプライアンス センター内で生成することもできます。

電子情報開示のコンテンツ検索

コンテンツ検索ツールを使用すると、調査担当者は、Office 365 テナントに保存されている電子メール、ドキュメント、およびインスタント メッセージの会話を照会できます。コンテンツ検索クエリを頻繁に実行して、攻撃者によって送信された電子メールのコピーを見つけて取得します。コンテンツ検索は、Microsoft によってインデックスが作成されたものに限定されるため、最近のアクティビティがすぐに表示されない場合があります。さらに、最新の 1000 項目のみがプレビュー ウィンドウに表示されます。

O365 BEC の構造

前述のように、BEC は、今日の Managed Defense で見られる、O365 テナントに対する最も一般的な脅威の 1 つです。 Mandiant のアナリストは、同じ 1 週間以内に顧客の複数の BEC ケースに対応することがあります。この最前線での経験に基づいて、一般的に観察される戦術とテクニックのリストをまとめて、読者が予想すべき活動の種類についてアドバイスしました。これは決して O365 攻撃の包括的なリストではなく、BEC アクターが目的を達成するために取る通常のルートに焦点を当てていることに注意してください。

フェーズ 1: 初期侵害

  • フィッシング: 認証情報収集フォームへのリンクが記載された電子メールが被害者に送信されます。侵害されたビジネス パートナーのアカウントから送信されることもあります。
  • ブルート フォース: 関心のあるアカウントに対して試行されたパスワードの大規模な辞書。
  • パスワード スプレー: 既知のユーザー アカウントのリストに対して試行される、一般的に使用されるパスワードの辞書。
  • 資格情報ダンプへのアクセス: ユーザーの以前の侵害から使用された有効な資格情報。
  • MFA バイパス: MFA ポリシーをバイパスする従来の認証プロトコル (IMAP/POP など) を利用するメール クライアントの使用。攻撃者はまた、ログインを繰り返し試行することで被害者にプッシュ通知をスパム送信する可能性があり、最終的には被害者がプロンプトを誤って受け入れることにつながります。

フェーズ 2: 足場を確立する

  • さらなるフィッシング: Outlook のグローバル アドレス リストから内部/外部の連絡先に送信される追加のフィッシング詐欺。
  • より信頼性の高いルアー: 侵害されたユーザーの OneDrive または SharePoint アカウントにアップロードされ、被害者の同僚と共有される新しいフィッシングルアー。
  • SMTP 転送: 被害者のメールボックスで SMTP 転送が有効になり、すべての電子メールが外部アドレスに転送されます。
  • 転送メールボックス ルール: すべてまたは特定のメールを外部アドレスに転送するために作成されたメールボックス ルール。
  • メール クライアントの使用法: 攻撃者が使用する Outlook またはサード パーティのメール クライアント。パスワードのリセットが発生した後、メールはしばらくの間同期を続けます。

フェーズ 3: 回避

  • 回避メールボックス ルール: メールを削除したり、一部またはすべての受信メールを「RSS 購読」などの Outlook であまり使用されないフォルダーに移動したりするために作成されたメールボックス ルール。
  • 手動回避: 受信メールと送信メールを手動で削除します。攻撃者は、メールボックス ルールを完全に無視する可能性があります。
  • メール転送: メールを外部アドレスに転送するメカニズムが以前に設定されていた場合、攻撃者はログインせずにメールにアクセスします。
  • メール クライアントの使用法: 攻撃者が使用する Outlook またはサード パーティのメール クライアント。メールは、攻撃者のマシンにローカルで同期され、後でアクセスされる可能性があります。
  • VPN の使用: 検出を回避し、条件付きアクセス ポリシーを回避するために使用される VPN サーバー。

フェーズ 4: 内部偵察

  • Outlook 検索:攻撃者が関心のある電子メールを照会する被害者のメールボックス。監査ログには記録されませんが、攻撃者によって削除されていなければ、 エクスポートできる可能性があります。
  • O365 検索: SharePoint およびその他の O365 アプリケーション内で関心のあるコンテンツを検索します。監査ログには記録されませんが、SharePoint と OneDrive のファイル操作は UAL に記録されます。
  • メール クライアントの使用法: 攻撃者が使用する Outlook またはサード パーティのメール クライアント。メールは、攻撃者のマシンにローカルで同期され、後でアクセスされる可能性があります。

フェーズ 5: ミッションを完了する

  • 直接預金の更新: HR 部門に送信され、被害者の直接預金情報を更新し、支払いを BEC アクターにリダイレクトします。
  • W-2 詐欺: 税務詐欺の PII を収集するために使用される W-2 フォームを求めて人事部に送信されるリクエスト。
  • 電信送金: 未払いの請求書、今後の M&A、慈善団体などのために要求される電信送金。
  • サードパーティのアカウントの悪用: 侵害されたユーザーの、サードパーティのアカウントやサービスへの特権アクセス (企業の報酬サイトへのアクセスなど) の悪用。

Managed Defense が O365 BEC にどのように対応するか

このセクションでは、Managed Defense が典型的な O365 BEC ケースを調査する方法について説明します。

調査の手順の多くは、PowerShell を使用したログのクエリに依存しています。これを行うには、まず Exchange Online へのリモート PowerShell セッションを確立します。次の Microsoft ドキュメントでは、これを行うための 2 つの方法に関するガイダンスが提供されています。

obscured365

広い範囲

疑わしいアクティビティの統合監査ログ (UAL) に対して幅広いクエリを実行することから調査を開始します。 OAuth アクティビティも確認します。これは、金銭目的の BEC よりもさらに悪質なものが疑われる場合に特に重要です。 FireEye Helix や Email Security など、利用可能な FireEye 機器はすべて、Office 365 から利用できるデータを強化するために活用されます。

以下は、Managed Defense エンゲージメントの開始時に通常実行する最初のスコーピング クエリです。

最近のメールボックス ルール アクティビティのスコープ

大規模なテナントであっても、最近のすべてのメールボックス ルール アクティビティを元に戻しても、通常、手に負えない数の結果が生成されることはなく、攻撃者が作成したルールは残りのノイズから際立っている傾向があります。

Helix でのすべてのメールボックス ルール アクティビティについて UAL をクエリします。

class=ms_office365 action:[New-InboxRule, Set-InboxRule, Enable-InboxRule] |テーブル [createdtime、アクション、ユーザー名、srcipv4、srcregion、パラメーター、rawmsg]

PowerShell で新しいメール ルール アクティビティについて UAL を照会します。

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -ResultSize 5000 -Operations “New-InboxRule”,”Set-InboxRule”,”Enable-InboxRule” | Export-CSV pathtofile.csv –NoTypeInformation -Encoding utf8

SMTP 転送アクティビティの範囲設定

SMTP 転送は、メールボックス ルールとは別の UAL 操作の下に表示されるため、見落とされることがあります。このクエリは、SMTP 経由でメールを転送するパラメーターを含むSet-Mailbox操作を探します。これは、OWA から自動転送が有効になっていることを示しています。

Helix での SMTP 転送の UAL のクエリ:

class=ms_office365 action=Set-Mailbox rawmsg:ForwardingSmtpAddress |テーブル [createdtime、アクション、ユーザー名、srcipv4、srcregion、パラメーター、rawmsg]

PowerShell での SMTP 転送の UAL のクエリ:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -ResultSize 5000 -FreeText “ForwardingSmtpAddress” | Export-CSV pathtofile.csv –NoTypeInformation -Encoding utf8

侵害されたユーザーのログを分析する

テナントの範囲を特定したら、侵害に関与していると思われる個々のユーザーに注意を向けます。識別された侵害されたユーザーに関連するすべての O365 ログを取得します。これには、ユーザーの UAL、メールボックス監査ログ (MAL)、および管理者監査ログ (ユーザーが管理者である場合) が含まれます。これらのログで異常なアカウント アクティビティを確認し、攻撃者の IP アドレスとユーザー エージェント文字列のリストを作成します。このリストを使用して、テナントの範囲をさらに絞り込みます。

O365 の調査は、異常検出に大きく依存しています。多くの場合、BEC アクターはユーザーと同時にアクティブになることさえあります。侵害されたアカウント内での正当なユーザー アクティビティと攻撃者のアクティビティを正確に区別するには、正当なアクティビティの参照として使用するために、できるだけ多くのデータを取得することをお勧めします。 Helix クエリを使用すると、 groupby < [srccountry,srcregion]groupby < useragent が変換されます groupby < srcipv4 最も一般的でない位置情報、ユーザー エージェント文字列、および IP アドレスを強調表示するものも、結果の異常を特定するのに役立ちます。

Helix でユーザーの UAL を照会する:

クラス = ms_office365 ユーザー名 = user@client.com |テーブル [createdtime、アクション、ユーザー名、srcipv4、srccountry、srcregion、useragent、rawmsg] | groupby < [srccountry,srcregion]

PowerShell でユーザーの UAL を照会する:

Search-UnifiedAuditLog -StartDate mm/dd/yyyy -EndDate (Get-Date) -ResultSize 5000 -UserIds user@client.com | Export-CSV pathtofile.csv –NoTypeInformation -Encoding utf8

PowerShell でユーザーの MAL を照会する:

Search-MailboxAuditLog -Identity user@client.com -LogonTypes Owner,Delegate,Admin -ShowDetails -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) | Export-CSV pathtofile.csv –NoTypeInformation -Encoding utf8

PowerShell で特定の日付内のすべてのイベントの管理者監査ログをクエリします。

検索-AdminAuditLog -StartDate mm/dd/yyyy -EndDate mm/dd/yyyy | Export-CSV pathtofile.csv –NoTypeInformation -Encoding utf8

新しいリードで UAL をクエリする

疑わしい IP アドレス (または CIDR 範囲全体) とユーザー エージェント文字列のリストを作成したので、UAL 全体に対して新しいクエリを実行して、侵害された他のユーザー アカウントを特定しようとします。新しく識別されたユーザー アカウントごとに、この手順と前の手順を繰り返します。

PowerShell よりも FireEye Helix プラットフォームを使用する利点の 1 つは、CIDR 範囲全体をクエリできることです。これは、同じアドレス ブロック内で IP アドレスを動的に割り当てる VPN または ISP からの攻撃者を観察するときに役立ちます。

通常、攻撃者の User-Agent 文字列のクエリは、IP アドレス検索よりも多くのノイズを生成してふるいにかけます。実際には、ユーザー エージェント クエリは、攻撃者が一般的でないブラウザーまたはブラウザーのバージョンを使用している場合にのみ有益です。 Search-UnifiedAuditLogコマンドレットの制限により、FreeText パラメーターを使用して単純な文字列を検索することが最も成功しています。

ヘリックスで:

class=ms_office365 (srcipv4:[1.2.3.4, 2.3.4.0/24] または useragent:Opera) |テーブル [createdtime、アクション、ユーザー名、srcipv4、srccountry、srcregion、useragent、rawmsg] |ユーザー名でグループ化

PowerShell で IP とユーザー エージェントの UAL を照会します。

Search-UnifiedAuditLog -StartDate mm/dd/yyyy -EndDate (Get-Date) -ResultSize 5000 -IPAddresses 1.2.3.4, 2.3.4.5 | Export-CSV pathtofile.csv –NoTypeInformation -Encoding utf8
Search-UnifiedAuditLog -StartDate mm/dd/yyyy -EndDate (Get-Date) -ResultSize 5000 -FreeText “Opera” | Export-CSV pathtofile.csv –NoTypeInformation -Encoding utf8

メッセージ追跡の分析

PowerShell を使用して、特定した侵害されたユーザーのメッセージ トレースを照会します。メールが過去 10 日以内に送信されたものである場合は、 Get-MessageTraceコマンドレットを使用します。これにより、すぐに結果が返され、チームが IP アドレスをクエリできるようになります。古い電子メールの場合は、 Start-HistoricalSearchコマンドレットを使用し、後でセキュリティ & コンプライアンス センターの [メール フロー] セクションからレポートをダウンロードします。

PowerShell で、被害者から送信された過去 10 日間のメールのクエリ:

Get-MessageTrace -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date) -SenderAddressvictim@client.com | Select-Object Received、SenderAddress、RecipientAddress、Subject、Status、FromIP、Size、MessageID | Export-CSV pathtofile.csv –NoTypeInformation -Encoding utf8

PowerShell での古いメール (最大 90 日) のクエリ:

Start-HistoricalSearch -ReportTitle “Mandiant O365 調査” -StartDate mm/dd/yyyy -EndDate mm/dd/yyyy -ReportType MessageTraceDetail -SenderAddressvictim@client.com

メッセージ トレースの結果を確認するときは、IP アドレスに注意して、攻撃者によって送信された電子メールを特定する必要があります。フィッシングが最初の侵害経路の疑いがある場合は、最初の侵害日から数日以内に受信した受信メールについてクエリを実行し、疑わしい送信者のアドレスや件名を探すこともお勧めします。

関心のある電子メールを取得する

メッセージ追跡から特定された不審な電子メールのリストを使用して、Office 365 セキュリティおよびコンプライアンス センターで利用可能なコンテンツ検索ツールを使用して、電子メールの本文を取得し、フィッシングのルアーで使用されたドメインを学習します (フィッシングが存在する場合)。コンテンツ検索はわかりやすい GUI を使用して実行され、結果はブラウザでプレビューするか、EML ファイルとして個別にダウンロードするか、PST ファイルとして一括ダウンロードすることができます。

最終的なスコーピング

調査のこの時点では、BEC はテナント内で十分にスコープされている必要があります。後続のアクティビティが発生していないことを確認するために、すべての攻撃インジケーターを取得し、UAL 全体で最終的なクエリを実行します。

そうは言っても、攻撃者のアクティビティが O365 ログに表示されないエッジ ケースはまだあります。たとえば、別のユーザーが資格情報をフィッシング ページに送信した可能性がありますが、攻撃者はまだそれらを使用してログインしていません。このアクティビティを見逃さないようにするために、特に攻撃者のフィッシング インフラストラクチャに関連する IP アドレスとドメインについて、利用可能なネットワーク ログ全体で追加のスコープを実行します。また、Endpoint Security プラットフォームなどの他の FireEye 製品を活用して、ホストの Web ブラウザー履歴に存在するフィッシング ドメインを検索します。

結論

O365 テナントへの不正アクセスは、組織だけでなく、そのスタッフやビジネス パートナーにも脅威をもたらします。 O365 でセキュリティ管理が強化されていない組織は、BEC を経験するリスクが最も高くなります。しかし、多要素認証がますます一般的になるにつれて、ますます熟練した攻撃者による MFA バイパスの試みが増加するのを目の当たりにしてきました。

ソーシャル エンジニアリングが BEC 全体で主要な役割を果たすことを覚えておくことが重要です。一般的な侵害ベクトルである資格情報収集フォームを特定する方法について、ユーザーがトレーニングを受けていることを確認します。 BEC 侵害の最中に、チームは、調査の進行中に銀行振込または電信送金に関連する要求を処理する際に特別な注意を払うように、人事および財務関連の役割の担当者に速やかに警告することをお勧めします。

このブログ投稿で取り上げた例は、Office 365 の侵害を調査する際に Managed Defense が実行することのほんの一例です。 BEC を防止するためにプロアクティブなアプローチを取るには、次のベスト プラクティスが O365 テナントに実装されていることを確認してください。さらに、FireEye Email Security はフィッシングに対する保護を提供し、Helix プラットフォームの O365 ルールセットは、異常なアクティビティが発生するとすぐにアラートを出すことができます。

推奨されるベスト プラクティス

  • すべてのアカウントでメールボックス監査ログが有効になっていることを確認する
  • レガシー認証プロトコルを無効にする
  • 多要素認証 (MFA) を有効にする
  • 強力なパスワードとパスワードの有効期限ポリシーを適用する
  • O365 監査ログを一元化されたログ プラットフォームに転送して保持期間を延長
  • Azure/オンプレミスの Active Directory でアカウント ロックアウト ポリシーを適用する
  • 外部ドメインへのメール転送を制限する

謝辞

Doug Bienstock、Glenn Edwards、Josh Madeley、Tim Martin のこのトピックに関する調査と支援に特に感謝します。

参照: https://www.mandiant.com/resources/blog/insights-into-office-365-attacks-and-how-managed-defense-investigates

Comments

Copied title and URL