A recent trend has emerged where threat actor groups (e.g., ShinyHunters, PEAR, HELIX, etc.) have been leveraging phishing and vishing techniques to gain access to M365 email accounts. Through identity and token abuse, these actors have then automated large-scale file exfiltration and extortion campaigns targeting SharePoint, OneDrive, Microsoft Entra ID (formerly Azure AD), and email data through abuse of the Microsoft Graph API.
Variations of this playbook have also included leveraging SSO-connected access to third-party platforms (e.g., Salesforce, Jira, etc.) to exfiltrate additional data. Threat actors may also leverage the My Apps page within Microsoft 365, which provides a centralized view of applications available to the user and is frequently used by threat actors to access connected services and applications.
Our DFIR team has identified and independently validated an important risk factor when assessing data at risk exposure within Microsoft 365: Successful file acquisition may be recorded in the Microsoft 365 Unified Audit Log (UAL) as “FileAccessed” without a corresponding “FileDownloaded” event. Through controlled testing, our team successfully retrieved file content from Microsoft 365 while the resulting UAL telemetry recorded “FileAccessed” rather than “FileDownloaded.
LevelBlue DFIR’s investigations in recent months have observed a repeating pattern involving scripted and API-based access to SharePoint and OneDrive, including activity associated with Microsoft Graph and Python-based user agents. Accordingly, the absence of “FileDownloaded” written to the Unified Audit Log (UAL) should not, by itself, be treated as evidence that file acquisition did not occur. It is the totality of digital forensic artifacts, method of unauthorized access, and the state of Microsoft’s 365 logging capabilities that define a defensible assessment of data at risk.
Why the Distinction Matters
Microsoft 365 UAL differentiates between operations such as “FileAccessed” and “FileDownloaded”. In practice, this distinction can lead investigators and counsel to interpret “FileAccessed” as evidence that a threat actor merely viewed or interacted with a file, while reserving “FileDownloaded” for confirmed acquisition.
Our testing demonstrates that this interpretation is not reliable in all circumstances. Modern threat actors can interact with SharePoint and OneDrive programmatically through Microsoft Graph, APIs, scripts, and other non-browser clients. Depending on the access method, successful retrieval of file content may not generate the “FileDownloaded” telemetry expected from a conventional user-initiated download.
For purposes of exposure analysis:
“FileAccessed” does not establish file acquisition, but it also does not exclude it. The event must be evaluated in the context of how the file was accessed and the surrounding activity.
Indicators That Increase the Significance of “FileAccessed”
Particular scrutiny should be given when “FileAccessed” events coincide with:
- Microsoft Graph or other API-based access;
- Python, PowerShell, or other scripted/non-standard user agents;
- High-volume or rapid sequential file access;
- Access to numerous files within seconds or minutes;
- Patterns inconsistent with normal interactive user behavior;
- File enumeration, search, or reconnaissance preceding the activity;
- Suspicious source IP addresses or infrastructure; or
- A confirmed or suspected period of unauthorized account access.
For example, an isolated “FileAccessed” event generated through a normal browser session carries a different forensic and evidentiary context than hundreds of sequential “FileAccessed” events generated programmatically during a compromised session.
The latter pattern warrants consideration as potential file acquisition, even in the absence of “FileDownloaded” telemetry.
Example:
Figure 1. Isolated “FileAccessed” example.
What About “FilePreviewed”?
“FilePreviewed” should be treated separately and interpreted with additional caution. Microsoft indicates that “FilePreviewed” and “FileAccessed” can reflect requests resulting in a read of a file or a rendered representation of it. Preview-related events may also result from thumbnail rendering or browser prefetch behavior.
Accordingly, “FilePreviewed” alone does not establish that the complete underlying file was acquired. As with “FileAccessed,” however, the event name should not be used in isolation to determine what occurred. The access method and surrounding telemetry should be evaluated. Our controlled testing specifically validated successful file retrieval associated with “FileAccessed” telemetry.
Guidance for Exposure Assessments
When assessing potential data exposure in Microsoft 365, we recommend that “FileAccessed” activity occurring during unauthorized access be evaluated based on the totality of the evidence, rather than relying solely on whether a “FileDownloaded” event exists.
Relevant factors include:
Access method + user agent string (UAS) + volume + velocity + authentication context + surrounding threat activity.
Where these factors indicate scripted or programmatic retrieval, “FileAccessed” activity may support an assessment of potential file acquisition even without corresponding “FileDownloaded” telemetry.
Bottom Line
The absence of “FileDownloaded” is not evidence of the absence of file acquisition. “FileDownloaded” remains meaningful evidence of file acquisition, but it should not be treated as the only UAL event capable of identifying activity in which a threat actor obtained file content. In particular, “FileAccessed” activity associated with Microsoft Graph, Python, scripted tooling, or other automated access methods warrants careful review before concluding that the underlying files were not acquired.
