Blog: DFIR
BEC-ware the phish (part 1). Investigating incidents in M365
TL;DR
- Review the key artefacts to ensure the best possible telemetry is available in the case of a Business Email Compromise (BEC).
- Keep an eye on data retention, where necessary export or forward data for investigations longer than 30 days.
- Verify and enable Unified Audit Logging, its free and gives broad visibility for 180 days.
- Use Purview content search recover mailboxes for deep-dive analysis.
- Use Advanced Hunting tables generated by Defender for Cloud Apps and Defender for Office 365 for the most granular and scalable analysis.
- Fall back on host-based artefacts to rule out lateral movement to the host and fill in any gaps in the investigation.
Introduction
We’ve seen an increase in multi-stage Adversary in the Middle (AiTM) phishing BEC in M365. These usually originate from a compromised trusted party, and lead to a series of AiTM attacks and follow-on BEC activity. Often, these investigations conclude with “if only this data had been available!”
This blog post is the first of three, that look at the key steps for an effective investigation, response, and remediation to email-based threats in M365. Part two covers response actions as well as short- and long-term remediations to prevent attackers getting back in. Part three considers the native detection and prevention options in M365.
Here in part one, we’re looking at artefacts for investigating a BEC incident. Before conducting or commissioning a forensic investigation in M365, get an overview of how artefacts impact the success of an investigation, giving considering to which are on-by-default or free to enable.
Investigation questions
Once immediate containment actions have been taken, the first step is to work out the scope of the incident.
The following investigation questions commonly arise:
- What was the initial access vector?
- When did the attack occur?
- Which accounts have been accessed?
- What follow on activities has the threat actor taken?
- Has data exfiltration occurred?
- Have end user devices been compromised?
- Does the threat actor still have access to the environment?
- Who is the threat actor?
- Was the attack targeted to our organisation?
Whilst investigation questions are important for focusing analysis, consider whether answering an investigation question has a tangible impact on remediation.
Artefacts in M365 (and where to find them)
A common challenge is keeping up to date with Microsoft security products and best practices.
This can result in key artefacts not being available, which impacts the confidence with which investigation questions can be answered. For example, it is possible to discover that malicious inbox rules are present through Exchange Online PowerShell cmdlets. However, the UAL is required to have recorded when those inbox rules were created or identify rules that have been deleted.
I have recorded the most common forensic artefacts used in a standard BEC investigation into the following categories:
| Category | Investigation value | Artefact |
| Enabled by default | Telemetry available out-the-box, but not enough data to draw confident conclusions for BEC. |
|
| Essential | Free to enable and goes much further to answer investigation questions. | |
| Best case scenario | Improves the efficiency for scaled investigations. If covered by license, turn them on! | |
| Complimentary | Not to be relied on. Used when preferred data is not available or to ‘fill in the gaps’ of an investigation. |
|
How to acquire the data?
There are different approaches to collecting data between the portal, PowerShell or API. The choice usually depends on the scale of the incident, as methods face limitations on the number of records that can be exported. Two handy open-source tools for acquisition M365 artefacts include Microsoft-Analyzer-Suit and the Microsoft-Extractor-Suite.
Enabled by default
Entra logging
Entra logging is enabled by default and retained for 30 days.
- Interactive Sign in Logs
- Non-Interactive Sign in Logs
- Audit Log
- Risky Sign in Events
Interactive sign-ins records all sign-ins performed by a user. This captures data such as IP address, user agent, device, and timestamps. With this data you can identify sign ins originating from suspicious IP addresses, determine whether MFA was applied, and establish the device from which an MFA prompt was satisfied. This analysis can reveal brute force attempts or Adversary-in-the-Middle (AiTM) attacks where MFA tokens may have been intercepted and misused.
Non-interactive user sign-ins do not require the user to supply an authentication factor. Instead, the device or client app uses a token or code to authenticate or access a resource on behalf of a user. Examining non-interactive sign-ins can be used to identify sessions belonging to the threat actor, including M365 applications accessed by via the application and resource name or identifier.
From the sign-in data, Azure natively generates risky sign-in events. Use of AiTM frameworks commonly generate impossible travel or risky sign-in detections due the stealing of valid session tokens.
Within the Entra portal, analysts can review user permissions, registered devices, and OAuth Apps. The audit log records changes to applications, groups and users. This provides visibility into privilege escalation; such as creation of new user accounts, addition of a member to a role or group which indicates attempts to assign greater permissions to a compromised account. The audit log can also be used to identify follow-on actions taken by a threat actor such as Identity Provider Federation abuse or abuse of Hidden Membership Administrative Units.
Keep an eye on the log retention! Especially if bringing in a third party after the fact to investigate. For small data volumes, export data so it is not lost. For larger volumes, consider forwarding Entra data to Log Analytics or to Sentinel to extend retention to 90 days.
Inbox rules
In most BEC cases, threat actors create inbox rules to keep victims unaware of their operations. Per-user inbox rules be retrieved through Exchange Online PowerShell module and the referenced acquisition tools.
Here is a sample of Inbox rules observed in-the-wild. The rule name is randomised or a single character. The RSS Subscriptions folder is commonly used to move any replies to the phishing email by including the subject name, or any automatic replies indicating that the email was blocked or could not be delivered.
| Rule Name | Function |
| 2e3343 | If the subject or body contains ‘spam;scam;hacked;phishing’:
Move to ‘RSS Feeds’ folder and mark as read |
| a | Move to ‘RSS Feeds’ folder, mark as read |
| w | Move to ‘rss’ folder, mark as read |
| ee | Move to ‘rss’ folder, mark as read |
| 333 | Move to ‘rss’ folder, mark as read |
| as | Move to ‘RSS Feeds’ folder, mark as read |
| ss | Move to ‘RSS Feeds’ folder, mark as read |
| sss | Move to ‘RSS Subscriptions’ folder, mark as read |
| 44 | Move to ‘RSS Feeds’ folder, mark as read |
| edd | Move to ‘RSS Feeds’ folder, mark as read |
| 676 | Move to ‘RSS Subscriptions’ folder, mark as read |
| ‘ | If the message was received from any an address that contains any of the following:
Take the following actions:
|
| ‘ | If the subject line or message body includes the any of the following terms:
Take the following actions:
|
Essential
Unified Audit Log (UAL)
The UAL is a good aggregator, capturing key data from services like Exchange, SharePoint, Teams. This includes adding of mailbox permissions, creation of new inbox rules, and a record of sent and deleted messages by an owner, delegated user, or administrator. Data also extends to sign in behaviours, administrative actions and file, page, and search operations in SharePoint.
Updates to the UAL include the addition of the MailItemsAccessed and SearchQuery operations to the default logging configuration. These events provide visibility of which emails were accessed determine what data a threat actor was interested in.
Credit: https://learn.microsoft.com/en-us/defender-xdr/microsoft-xdr-auditing
The default retention for Audit (Standard) was updated from 90 to 180 days in October 2023. Older tenants should verify and enable audit logging in the web interface or with Exchange Online PowerShell commands.
//Verify status Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled //Enable UAL Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
There are a few options to analyse the UAL. The simplest is to export from the Microsoft Defender XDR Audit page or go to the Purview compliance portal, parse, and analyse offline. For a single user, it can be feasible to export all events in a desired timeframe. For more users, you’ll have to be selective about the event types exported.
Microsoft Purview content search
Microsoft’s compliance centre Content Search can be used to recover content from mailboxes. This requires the eDiscovery Manager role to be assigned. The exported .pst file can then be opened in a sandboxed environment and phishing emails analysed.
Recovery of emails from the mailbox can be used in combination with threat intelligence to determine where the campaign originates, identify the threat actor, and determine how targeted the attack is.
Where a BEC is used to conduct follow on campaigns, exporting the full mailbox will capture outbound phishing emails and their responses. The export helpfully generates a CSV summarising all inbound and outbound messages.
Granular conditions can be added, such as retrieving an email by subject or sender when the phishing email is known:
Best case scenario
Using Defender data for BEC investigations
Defender for Endpoint, Defender for Cloud Apps and Defender for Office 365 provide valuable telemetry to a BEC investigation.
It is important not to solely rely on Defender incidents to identify the full scale of the attack. Whilst Defender will do its best efforts to identify affected users, it cannot “think like an analyst”. You’ll need to interrogate the underlying data in full to find all compromised users.
If OAuth phishing is suspected, Defender for Cloud Apps app governance can be used to hunt for suspicious OAuth apps, such as those with high privileges or with risky permissions such as full access to all mailboxes.
Defender’s search function can be used to search an IOC (URL, IP, or domain, filename, hash etc. ) across any emails, device connections or URL clicks.
Defender search bar to identify URL:
Open Defender’s dedicated URL page:
Review Email’s tab to see presence of phishing URL across all emails:
Advanced Hunting
The most powerful resource is to leverage Advanced Hunting tables. Specifically, the following tables generated by Defender for Office 365 and Defender for Cloud Apps.
- EmailEvents
- EmailAttachmentInfo
- URLClickEvents
- CloudAppEvents
These are useful for identifying emails by sender, recipient, or subject. You can determine whether the email was detected as malicious and pull indicators like URLs and attachments hashes from emails.
Defender Advanced Hunting with schema:
KQL queries can be used:
- If the subject or sender of a phishing email is known, use EmailEvents to find all users who received the suspicious email.
- If a malicious URL is known, identify all users who clicked on that URL with URLClickEvents.
- Surface if any logons from risky IPs occurred after a known malicious URL click, or after a successful delivery of a phishing email.
- To retrieve all file hashes for any malicious attachments by joining EmailEvents and EmailAttachmentInfo.
- If malicious hashes are discovered from EmailAttachmentInfo, search for these hashes on host filesystems or SharePoint with DeviceFileEvents and CloudAppEvents.
- If a mailbox is compromised and used to conduct further phishing activity, identify all recipients of outbound phishing emails with EmailEvents.
- To identify suspicious mailbox or SharePoint activity such inbox rule creation captured in CloudAppEvents.
- To review Defender ThreatTypes, ThreatNames and DetectionMethods to determine to inform the update of protection policies.
Analysts can benefit from open source KQL from Microsoft, GitHub repositories, or platforms such as kqlsearch.com. For example, the following KQL summarises activity from a supplied of URL or message ID. The malicious link is retrieved from EmailEvents table and the associated IP addresses classified is classified (Proxy, Corporate, or Other.) The EmailUrlInfo and UrlClickEvents tables are joined to provide location data and determine if clicks on the URL were allowed or blocked. The EmailAttachment and Device events tables are then searched to check for any attachments and follow on activity on devices.
Complementary
Where first choice data sources are not available, there are a few artefacts to fall back on.
- If the UAL is not available, the administrator audit log can provide useful data.
- Defender’s Email & collaboration Threat Explorer can be more intuitive than the Advanced Hunting tables, though does not provide as powerful filtering and correlation of endpoint, email, cloud and logon data.
- Exchange message trace shows emails sent and received in the Exchange Admin Centre (EAC) and is a good option of Defender’s Email threat Explorer/ Advanced hunting data is not available.
Filling in gaps with host-level data
Host-level artefacts are a good fall-back option, as they are not reliant on any logging having been configured in advance. Artefacts can help identify the initial access vector or rule out lateral movement to a host, such as a victim downloading and executing a malicious document.
In our investigations, the following host level data has been used:
- System event log data has proved that devices were in sleep mode during mailbox exploitation to rule out initial access vectors.
- Web browsing activity to validate user supplying credentials to phishing pages.
- Host-based triage to eliminate lateral movement to end user devices.
If Endpoint Detection and Response (EDR) tools are already deployed, these will alert on suspicious host-based activity (based on file, command-line, network, and registry data). EDR will also support rapid acquisition of evidence, such as via a remote terminal function. This allows analysts to dig into host level artefacts without the complexity of traditional forensics. Defender has a default investigation package to collect triage artefacts from endpoints, or the live response terminal can be used to execute custom commands and scripts such as KAPE.
Which host-based artefacts to use?
Chromium-Based browsers record actions in an SQLite database such as file downloads, URL history or user input web forms, such as users entering credentials into harvesting pages.
C:\[User]\AppData\Local\Google\Chrome\User Data\[Profile]\History C:\[User]\AppData\Local\Microsoft\Edge\User Data\[Profile]\History
The existence of credentials (encrypted or otherwise) can be cross-referenced against phishing pages, to determine if a victim entered values into a phishing page. Saved credentials are stored in the Login Data database and the URLs and associated login data in the Logins table.
Review of host-based edge Web data. SQL query returns URL history proving victim browsing to phishing site:
Review of host-data from the edge Login Data database. password_value contains an encrypted blob, which is the password inputted by the victim and therefore exposed to the attacker:
Malware distributed through phishing emails will likely have required the user to enable editing or macros. For Office to remember this decision, the document is added as a Trusted Document to the TrustRecords subkey which can be examined.
HKEY_CURRENT_USER\Software\Microsoft\Office\[office_version]\Word\Security\Trusted Documents\TrustRecords HKEY_CURRENT_USER\Software\Microsoft\Office\[office_version]\Excel\Security\Trusted Documents\TrustRecords
Conclusion
Effectively investigating BEC incidents in M365 starts with enabling the right logging and managing data retention effectively. Ensure the UAL is active to capture critical events, use Purview content search to recover suspected emails for analysis, and leverage Defender’s Advanced Hunting for detailed insights into malicious activities.
Part 2 is available here.
