365（M365）では、ファイルの取得が「FileAccessed」として記録される場合がある

近年、脅威アクターのグループ（例: ShinyHunters、PEAR、HELIX など）が、フィッシングやビッシング（音声フィッシング）の手法を用いて M365 のメールアカウントへのアクセスを獲得するという傾向が顕在化しています。これらのアクターは、ID（アイデンティティ）とトークンの不正利用を通じて、Microsoft Graph API の悪用により、SharePoint、OneDrive、Microsoft Entra ID（旧 Azure AD）、およびメールデータを標的とした大規模なファイル窃取・恐喝キャンペーンを自動化してきました。

この手口の派生形には、SSO（シングルサインオン）で連携されたサードパーティ製プラットフォーム（例: Salesforce、Jira など）へのアクセスを悪用し、さらなるデータを窃取するケースも含まれます。また脅威アクターは、Microsoft 365 内の「My Apps」ページを利用することもあります。このページはユーザーが利用可能なアプリケーションを一元的に表示するもので、連携されたサービスやアプリケーションへアクセスするために脅威アクターに頻繁に悪用されています。

当社の DFIR（デジタルフォレンジック・インシデント対応）チームは、Microsoft 365 内で「リスクにさらされているデータ（data at risk）」の露出を評価する際に重要となる、あるリスク要因を特定し、独自に検証しました。すなわち、ファイルの取得（acquisition）が成功した場合でも、対応する「FileDownloaded」イベントを伴わずに、Microsoft 365 の統合監査ログ（Unified Audit Log, UAL）に「FileAccessed」として記録されることがあるという点です。管理された検証環境下で、当チームは Microsoft 365 からファイルの内容の取得に成功しましたが、その結果として記録された UAL のテレメトリは「FileDownloaded」ではなく「FileAccessed」でした。

LevelBlue DFIR による直近数か月の調査では、SharePoint および OneDrive に対するスクリプト経由・API 経由のアクセス（Microsoft Graph や Python ベースのユーザーエージェントに関連する活動を含む）を伴う、反復的なパターンが観測されています。したがって、統合監査ログ（UAL）に「FileDownloaded」が記録されていないことだけをもって、ファイルの取得が発生しなかった証拠と見なすべきではありません。防御可能な（defensible）「リスクにさらされているデータ」の評価を形づくるのは、デジタルフォレンジック上のアーティファクト全体、不正アクセスの手法、そして Microsoft 365 のロギング機能の状態の総体です。

なぜこの区別が重要なのか

Microsoft 365 の UAL は、「FileAccessed」と「FileDownloaded」といった操作を区別します。実務上、この区別により、調査担当者や法務担当（counsel）は、「FileAccessed」を「脅威アクターが単にファイルを閲覧・操作しただけ」の証拠と解釈し、「FileDownloaded」を取得が確認された場合のためのものと見なしてしまうことがあります。

当社の検証は、この解釈があらゆる状況で信頼できるわけではないことを示しています。現代の脅威アクターは、Microsoft Graph、各種 API、スクリプト、その他のブラウザ以外のクライアントを通じて、SharePoint や OneDrive とプログラム的にやり取りできます。アクセス手法によっては、ファイル内容の取得に成功しても、従来のユーザー起点のダウンロードで期待される「FileDownloaded」テレメトリが生成されない場合があります。

露出分析（exposure analysis）の観点では:

「FileAccessed」はファイルの取得を立証するものではありませんが、取得を否定するものでもありません。このイベントは、ファイルがどのようにアクセスされたか、およびその前後の活動という文脈の中で評価しなければなりません。

「FileAccessed」の重要性を高める指標

「FileAccessed」イベントが次のような状況と同時に発生している場合には、特に注意深い精査が必要です。

• Microsoft Graph またはその他の API ベースのアクセス
• Python、PowerShell、その他のスクリプト化された／非標準のユーザーエージェント
• 大量または急速に連続するファイルアクセス
• 数秒〜数分のうちに多数のファイルへアクセスしている
• 通常の対話的なユーザー行動と整合しないパターン
• 当該活動に先行するファイルの列挙・検索・偵察（reconnaissance）
• 疑わしい送信元 IP アドレスやインフラ、または
• 不正なアカウントアクセスが確認された、あるいは疑われる期間

例えば、通常のブラウザセッションで生成された単発の「FileAccessed」イベントは、侵害されたセッション中にプログラム的に生成された数百件もの連続する「FileAccessed」イベントとは、フォレンジック上・証拠上の文脈が異なります。

後者のパターンは、たとえ「FileDownloaded」テレメトリが存在しない場合であっても、ファイル取得の可能性として検討に値します。

例:

「FilePreviewed」についてはどうか？

「FilePreviewed」は別個に扱い、さらに慎重に解釈すべきです。Microsoft は、「FilePreviewed」と「FileAccessed」が、ファイルの読み取り、またはそのレンダリング（描画）された表現を生じさせるリクエストを反映し得ると説明しています。プレビュー関連のイベントは、サムネイルのレンダリングやブラウザのプリフェッチ（先読み）動作によって発生することもあります。

したがって、「FilePreviewed」だけでは、元のファイル全体が取得されたことを立証できません。ただし「FileAccessed」と同様に、イベント名だけを単独で用いて何が起きたかを判断すべきではありません。アクセス手法とその周辺のテレメトリを評価する必要があります。当社の管理された検証では、「FileAccessed」テレメトリに関連してファイル取得が成功することを具体的に確認しました。

露出評価（exposure assessment）のためのガイダンス

Microsoft 365 における潜在的なデータ露出を評価する際は、不正アクセス中に発生した「FileAccessed」の活動を、「FileDownloaded」イベントの有無のみに依拠するのではなく、証拠の総体に基づいて評価することを推奨します。

考慮すべき要因には次が含まれます:

アクセス手法 ＋ ユーザーエージェント文字列（UAS）＋ 量（volume）＋ 速度（velocity）＋ 認証コンテキスト ＋ 周辺の脅威活動。

これらの要因がスクリプト化された、あるいはプログラム的な取得を示している場合、「FileAccessed」の活動は、対応する「FileDownloaded」テレメトリがなくても、ファイル取得の可能性があるという評価を裏づけ得ます。

結論（Bottom Line）

「FileDownloaded」が存在しないことは、ファイル取得が存在しないことの証拠ではありません。「FileDownloaded」は依然としてファイル取得の有意な証拠ですが、脅威アクターがファイル内容を入手した活動を特定できる唯一の UAL イベントとして扱うべきではありません。とりわけ、Microsoft Graph、Python、スクリプト化されたツール、その他の自動化されたアクセス手法に関連する「FileAccessed」の活動については、対象ファイルが取得されなかったと結論づける前に、慎重な検討が必要です。