ブログ(脅威調査)

Obscured by Clouds:Office 365攻撃の洞察とMandiant Managed Defenseの調査方法

ビジネスメール詐欺侵害(BEC)が減少の兆しを見せない中、セキュリティアナリストにとって、Office 365(O365)の侵害を理解し、どのようにして適切に調査するかの重要性がますます高まっています。本ブログでは、O365 BEC対策を試しにやってみようという人向けで、マイクロソフトのCloud Productivity Suiteと、調査担当者に役立つ様々なログとデータソースについての速習講座を提供します。また、BEC に対応する際に観察した一般的な攻撃者の戦術を説明し、Mandiant Managed Defense のアナリストが PowerShell と FireEye Helix プラットフォームを使用してお客様の調査にどのようにアプローチしているかを説明します。

Office 365

Office 365は、マイクロソフトが提供するMicrosoft Officeスイートのクラウドベースのサブスクリプションサービスです。Office 365は、以下のような日常業務に密接に組み込まれた数多くのアプリケーションから構築されています:

  • Exchange Online(メール)
  • SharePoint(Intranet Portalとドキュメント共有)
  • Teams および Skype for Business(インスタント・メッセージ)
  • OneDrive(ファイル共有)
  • Microsoft Stream(ミーティングおよびプレゼンテーションの録画・共有)

ニーズに合わせてマイクロソフトのクラウドベースのサービスを採用する組織が増えているため、これらのO365環境への不正アクセス、つまりマイクロソフトの言葉で言うところのテナントは、意欲的な攻撃者にとってますます有利なものになってきています。現在のO365の採用率が高いということは、攻撃者がプラットフォームの利用や悪用について多くの経験を積んでいることを意味しています。多くの戦術は、私たちが初めて観察したときからほとんど変わっていませんでしたが、セキュリティを意識しているユーザーにも有効な技術の進化を目の当たりにしました。

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

  • ビジネスメール詐欺(BEC)
  • APTまたは国家主導の侵入

これまでの経験に基づき、BECはどの組織のO365テナントにとっても共通の脅威となっています。「BEC」という用語は、通常、金銭的動機の攻撃者によって行われる詐欺の一種です。BECのアクターは、ソーシャルエンジニアリングに大きく依存して、そのスキームを実行し、最終的には組織や人事すらも詐取してしまいます。

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

スタッフの個人財務も攻撃者にとっては聖域ではないのです。攻撃者が被害者のアカウントからW-2情報(源泉徴収表)を求めるリクエストを人事にリクエストするW-2詐欺のいくつかのケースを観察しました。一度取得したこの個人情報は、後に税務詐欺に利用されます。

逆に、APT侵入は通常、より洗練されており、国家が支援する脅威アクターによって行われています。APTアクターは通常、金銭的利益ではなく、スパイ活動、データ盗難、または破壊の目的でO365テナントを侵害する役割を担っています。任意の組織の O365 テナントに格納されている豊富な機密情報を考えると、APT アクターは、ミッションを完了するためにエンドポイントに触れる必要がない場合もあり、組織が実装して投資してきた多くのセキュリティ管理を回避することができます。

O365ログおよびデータソース

このセクションでは、O365調査に関連するフォレンジックデータを含む多数のログやポータルに触れます。

O365ケースの調査を開始する前に、私たちはクライアントと協力して、必要なフォレンジックデータを取得するために必要な役割を持つ「Investigator」アカウントをプロビジョニングします。本ブログ記事の目的のために、Investigatorアカウントに必要な役割を簡単にリストアップしますが、実際にManaged Defenseによる調査の際には、担当Managed Defenseコンサルタントがアカウントのプロビジョニングに関する詳細なガイダンスを提供します。

少なくとも、Investigatorアカウントは以下の役割を持つ必要があります:

Exchange Adminの役割

  • 表示専用監査ログ
  • 表示専用設定
  • 表示専用受信者
  • メールボックス検索
  • メッセージ追跡

eDiscovery Rights

  • eDiscovery Managerの役割

Azure Active Directoryの役割

  • グローバルリーダー

Unified Audit Log (UAL)

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

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

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

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

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

この記事を書いている時点で、マイクロソフトは先日、攻撃者がアクセスしたEメールについて調査者に洞察を与える、監査機能の強化に関するAdvanced Auditing情報を公開しています。通常のユーザーアカウントでこのレベルのログが利用できるのは、Office 365 E5 サブスクリプションを使用している組織でのみです。Advanced Auditingが有効になると、メールアクセスアクティビティは、UALとMALの両方でMailItemsAccessed操作の下に記録されます。

管理者監査ログ

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

Azure ADログ

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

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

OAuthの悪用が確認された事例については、マイクロソフトのCloud App Securityポータル(portal.cloudappsecurity.com)にクラウドアプリケーションに関する情報が掲載されています。このポータルにアクセスするには、E5ライセンスまたはスタンドアロンのクラウドアプリライセンスが必要です。OAuth不正使用の背景については、当社のブログ記事をご覧ください。

メッセージ追跡

メッセージ追跡は、ユーザーが送受信したメールを記録します。調査中に、対象のメールアドレスのレポートを実行します。メッセージ追跡レポートには、メールフローの詳細情報に加えて、件名、元のクライアントIPアドレス、メッセージサイズが含まれます。メッセージの追跡は、危険なアカウントから攻撃者によって送信されたメールを識別するのに便利で、フィッシングが初期アクセスに使用された場合、初期のフィッシングメールを識別するのにも役立ちます。実際のメールを入手するには、コンテンツ検索ツールを使用します。

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

eDiscoveryコンテンツ検索

コンテンツ検索ツールでは、調査員がOffice 365テナントに保存されているEメール、文書、インスタントメッセージの会話を検索することができます。当社では、攻撃者が送信したメールのコピーを見つけて取得するために、コンテンツ検索クエリを頻繁に実行しています。コンテンツの検索は、マイクロソフトがインデックスしているものに限定されているため、最近の活動がすぐに表示されない場合があります。さらに、プレビューペインには最新の1000アイテムのみが表示されます。

O365 BECの構造

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

フェーズ1:初期の侵害

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

フェーズ2:足場確立

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

フェーズ3:回避

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

フェーズ4:内部偵察

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

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

  • 銀行口座振込:被害者の銀行振込口座情報を更新するために人事部門に送信されるリクエスト。支払いをBECアクターに変更する
  • W-2詐欺:人事部に送られたW-2フォームの依頼で、税金詐欺のためにPIIを採取するために使用される
  • 電信送金:未払い請求書、今後のM&A、慈善事業などのために依頼された電信送金
  • 第三者アカウント悪用:企業の特典サイトへのアクセスなど、侵害されたユーザーの第三者アカウントやサービスへの特権アクセスを悪用したもの

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

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

調査の多くのステップは、PowerShell を使ったログのクエリに依存しています。これを行うには、まず、Exchange Online へのリモート PowerShell セッションを確立します。以下のマイクロソフトのドキュメントでは、この2つの方法についてのガイダンスを提供しています:

 

広範なスコープ

私たちは、統合監査ログ(UAL)の不審な活動に対して広範なクエリを実行することから調査を開始します。金銭的動機のBECよりも悪質なものが疑われる場合にはとりわけ重要な、OAuthの活動もレビューします。FireEye HelixEメール・セキュリティなどのFireEye機器は、Office 365から得られるデータを増強するために活用されます。

以下は、Managed Defenseの開始時に通常実行するいくつかの初期スコープクエリです。

最近のメールボックスルールの活動をスコープする

大規模なテナントであっても、最近のメールボックスルールアクティビティをすべて取り消しても、通常、管理できない数の結果が生成されることはなく、攻撃者が作成したルールは、他のノイズから目立つ傾向があります。

Helixのすべてのメールボックスルールのアクティビティに対してUALを取得:

class=ms_office365 action:[New-InboxRule, Set-InboxRule, Enable-InboxRule] | table [createdtime, action, username, srcipv4, srcregion, parameters, rawmsg]

PowerShell で新しいメールルールのアクティビティの UAL を取得:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -ResultSize 5000 -Operations "New-InboxRule","Set-InboxRule","Enable-InboxRule" | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8

SMTP転送アクティビティのスコープ

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

HelixでのSMTP転送のためのUALを取得:

class=ms_office365 action=Set-Mailbox rawmsg:ForwardingSmtpAddress | table [createdtime, action, username, srcipv4, srcregion, parameters, rawmsg]

PowerShellでのSMTP転送のUALを取得:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -ResultSize 5000 -FreeText "ForwardingSmtpAddress" | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8

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

テナントの調査が終わったら、侵害に関与していると思われる個々のユーザーに注目してみましょう。特定された侵害ユーザーに関連するすべてのO365ログを取得します。これにはユーザーのUAL、Mailbox Audit Log(MAL)、Admin audit log(ユーザが管理者の場合)などを含まれます。これらのログから異常なアカウント活動を確認し、攻撃者のIPアドレスとユーザーエージェントの文字列のリストを作成します。このリストを使ってテナントの範囲をさらに広げていきます。

O365の調査は、アノマリー検出に大きく依存しています。多くの場合、BECの攻撃者はユーザーと同時に活動していることさえあります。漏洩したアカウント内の正規のユーザー活動と攻撃者の活動を正確に区別するためには、できるだけ多くのデータを引き出して正規の活動の参考にすることをお勧めします。Helixのgroupby < [srccountry,srcregion]、groupby < useragent、groupby < srcipv4のtransformクエリを使用すると、最も使われていないジオロケーション、ユーザエージェント文字列、およびIPアドレスが強調表示され、アノマリーな結果を特定するのにも役立ちます。

HelixでユーザーのUALを取得:

class=ms_office365 [email protected] | table [createdtime, action, username, srcipv4, srccountry, srcregion, useragent, rawmsg] | groupby < [srccountry,srcregion]

PowerShellでのユーザーのUALを取得:

Search-UnifiedAuditLog -StartDate mm/dd/yyyy -EndDate (Get-Date) -ResultSize 5000 -UserIds [email protected] | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8

PowerShellでのユーザーのMALを取得のクエリ:

Search-MailboxAuditLog -Identity [email protected] -LogonTypes Owner,Delegate,Admin -ShowDetails -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8

PowerShellで特定の日付内のすべてのイベントの管理監査ログを取得:

Search-AdminAuditLog -StartDate mm/dd/yyyy -EndDate mm/dd/yyyy | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8

新しいリードでUALを取得

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

FireEye HelixプラットフォームをPowerShellよりも使用する利点の1つは、CIDRの範囲全体をクエリできることです。これは、同じアドレスブロック内でIPアドレスを動的に割り当てているVPNやISPからの攻撃者を観察する際に便利です。
攻撃者のユーザーエージェント文字列のクエリは、通常、IPアドレス検索よりも多くのノイズをふるいにかけます。実際には、ユーザーエージェントのクエリは、攻撃者が一般的ではないブラウザやバージョンのブラウザを使用している場合にのみ有益です。Search-UnifiedAuditLogコマンドレットの制限のため、FreeTextパラメータを使用して単純な文字列を検索する方法が最も効果的でした。

Helixでは:

class=ms_office365 (srcipv4:[1.2.3.4, 2.3.4.0/24] OR useragent:Opera) | table [createdtime, action, username, srcipv4, srccountry, srcregion, useragent, rawmsg] | groupby username

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 \path\to\file.csv –NoTypeInformation -Encoding utf8
Search-UnifiedAuditLog -StartDate mm/dd/yyyy -EndDate (Get-Date) -ResultSize 5000 -FreeText "Opera" | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8

メッセージ追跡の分析

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

被害者から送られてきた10日間のメールを PowerShell で検索しています:

Get-MessageTrace -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date) -SenderAddress [email protected] | Select-Object Received, SenderAddress, RecipientAddress, Subject, Status, FromIP, Size, MessageID | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8

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

Start-HistoricalSearch -ReportTitle "Mandiant O365 investigation" -StartDate mm/dd/yyyy -EndDate mm/dd/yyyy -ReportType MessageTraceDetail -SenderAddress [email protected]

メッセージ追跡の結果を確認するときは、IPアドレスに注意して、攻撃者が送信したEメールを特定する必要があります。フィッシングが最初の感染経路であると疑われる場合は、最初の感染日の数日前に受信したメールを検索し、怪しい差出人のアドレスや件名を探すこともお勧めします。

調査したいメールを取得する

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

最終的なスコープ

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

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

結論

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

BEC全体を通して、ソーシャルエンジニアリングが主要な役割を果たしていることを覚えておくことが重要です。一般的な侵害手段となる悪意のあるクレデンシャル取得フォームを識別する方法について、ユーザーがトレーニングを受けていることを確認してください。BECの侵害が発生した場合、調査中に銀行や電信送金に関連した要求を処理する際には、特に注意を払うよう、人事・財務関連の担当者に速やかに注意を促すことが必要です。

本ブログ投稿で取り上げられている例は、Office 365の侵害を調査する際にManaged Defenseが実行することのサンプルにすぎません。BECの防止に積極的に取り組むために、O365のテナントでは以下のベストプラクティスを実施してください。さらに、FireEye Eメール・セキュリティはフィッシングに対する保護を提供し、HelixプラットフォームのO365ルールセットは、異常な活動が発生するとすぐに警告を発することができます。

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

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

謝辞

このトピックに関する調査と支援をしてくださった Doug Bienstock、Glenn Edwards、Josh Madeley、Tim Martin に多大な感謝の意を表します。

 

本ブログは、米FireEyeが公開した July 30, 2020「Obscured by Clouds: Insights into Office 365 Attacks and How Mandiant Managed Defense Investigates」(英語)の日本語抄訳版です。

日本語版:Reviewed by Toru Tanimura