During the week of February 20, 2023, Sophos X-Ops MDR team received two separate requests for threat hunts related to unusual activity in two customers’ Microsoft 365 (formerly Office 365) environments. This prompted an investigation into sets of Microsoft Graph security events forwarded to Sophos XDR, to identify whether suspicious or malicious activity occurred. Microsoft Graph handles dataflow and access in Microsoft’s cloud (ie., 365, Windows, and Enterprise Mobility + Security); its Security API can connect multiple security providers and lets them operate in a federated fashion as needed.
In this article, we will provide a detailed walkthrough of each step in the attack flow, along with the purpose of each attack technique and the query by which each is identified in XDR. Sophos MDR concluded that email account compromise took place in both cases, using remarkably similar tactics, techniques, and procedures (TTPs). Cross-referencing data from both cases showed that the two compromises may be related to the same (unknown) threat actor.
(Please note that the queries and examples below refer to ‘CompromisedAdmin@example.com’, ‘TargetUser@example.com’, and so forth. These are placeholders and should be replaced in your queries with your own admin and user email addresses. As an obfuscation measure, we do not differentiate in this writeup which appearances of “example.com” are connected to which customer’s incident.)
Microsoft 365’s MITRE ATT&CK Matrix
The operating environment of Microsoft 365 is unique enough that a specific subset of adversarial TTPs are required to conduct threat hunts and investigations within these cloud environments. Figure 1 shows a screenshot of MITRE’s ATT&CK Matrix for Office 365. (MITRE is so far using Microsoft’s previous name for the service.) This article will focus on a subset of these TTPs relevant to email account compromise, and show how they were leveraged to identify the adversarial activity exposed in this double threat hunt. (Links to each of the MITRE tactics and techniques cited are provided at the end of this article.)
Initial Access: TA0001
In both cases, the initial compromise took place approximately 90 days prior to any observed malicious execution. It is possible this delay was purposeful — to wait out the default 90-day logging period for Microsoft 365 to roll over, or perhaps due to a handover from an Initial Access Broker (IAB) to another threat actor. The threat actor accessed multiple accounts on the targeted systems, in one case changing the phone number associated with a specific account to a different phone number. We’ll examine this specific technique in the Account Manipulation section below.
Valid Accounts: Cloud Accounts (T1078.004)
External Logins
Multiple external IP addresses were used to log into accounts, which the actor compromised or created after gaining initial access by unknown means (see Persistence section below). Three of these IP addresses were observed to be identical in both cases.
Analysis of these three IP addresses produced the following results:
104.161.20[.]102
- Seven counts of IP abuse reports on AbuseIPDB
- Domain name of ioflood[.]com, which is a dedicated-server hosting provider
- Exposed ports: FTP (21/TCP), RPC (135/TCP), SMB (445/TCP), RDP (3389/TCP)
20.232.202[.]245
- Hosted in Microsoft Azure Cloud (EastUS region)
- Exposed ports: RDP (3389/TCP)
185.241.149[.]122
- 25 counts of IP abuse reports on AbuseIPDB
- Domain name of ipxo[.]com, which is an IP-address marketplace leasing IP resources
- Exposed ports: RPC (135/TCP), SMB (445/TCP), RDP (3389/TCP)
ioflood.com and ipxo.com, both legitimate companies, were contacted by MDR in connection with this observed abuse of their services.
Sophos XDR Query
SELECT creation_time, user_id, operation, client_ip
FROM xdr_identity_o365
WHERE lower(user_id) IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com)
AND operation IN ('UserLoggedIn', 'UserLoginFailed')
Persistence: TA0003
Create Account: Cloud Account (T1136.003)
During the early days of the compromise, the threat actor created an account or accounts on the targeted system to establish persistence, and then (as mentioned) waited months before acting further on their objectives.
One such admin-level account was created during the first week of December; it was then used to create another account in late February, nearly eighty days later and a few days before Sophos was called in on the case. (Logs before the creation of the global admin account were not available to investigators.)
Sophos XDR Query
SELECT creation_time, user_id, operation, object_id, modified_properties FROM xdr_identity_o365 WHERE operation LIKE 'Add user.'
Account Manipulation (T1098)
User Updates
The threat actor added a new phone number to a compromised user account, likely to perform and intercept phone calls directly or via Microsoft Teams. There are various reasons the attacker might have done this, including social-engineering purposes, masquerading, or MFA subversion. Interestingly, this phone-number change happened nearly three weeks prior to further attacker activity.
Exchange Operation: ‘Update User’.
Sophos XDR Query
SELECT creation_time, user_id, operation, client_ip, target, modified_properties FROM xdr_identity_o365 WHERE lower(user_id) IN (‘CompromisedAdmin@example.com’, ‘CompromisedAdmin@example.com’) AND operation LIKE ‘Update user.’
Account Manipulation: Additional Email Delegate Permissions (T1098.002)
The threat actor leveraged their privileged account to grant themself full access to other users’ mailboxes. They also used this privilege to “send as” (i.e., send email from other users’ accounts) – potentially leading to further attack efforts at companies with which these two customers do business. Emails were also deleted.
Exchange Operations: ‘Add-MailboxPermission’, ‘Add-RecipientPermission’
The following table gives an example of permission modification for full access as seen at this stage.
| User | operation | object_id | access | name |
| CompromisedAdmin@eample.com | Add-MailboxPermission | TargetUser | “FullAccess” | “AccessRights” |
Figure 2: Expanding permissions for an abused account
Sophos XDR Query
SELECT creation_time, user_id, operation, object_id, JSON_EXTRACT(parameters, ‘$[2].Value’) AS Access, JSON_EXTRACT(parameters, ‘$[2].Name’) AS Name, JSON_EXTRACT(parameters, ‘$[1].Value’) AS Source, parameters FROM xdr_identity_o365 WHERE lower(user_id) IN (‘CompromisedAdmin@example.com’, ‘CompromisedAdmin@example.com’) AND operation LIKE ‘%Permission%’
Account Manipulation: Additional Cloud Roles (T1098.003)
SharePoint Modifications
The threat actor added the compromised administrator account to the target organization’s SharePoint with the “site admin” role. In addition, they also enabled “share using anonymous links,” allowing the actor to create links to files that did not require authentication to access.
Exchange Operations: ‘SiteLocksChanged’, ‘SiteCollectionCreated’, ‘SiteCollectionAdminAdded’
The following table gives examples of cloud roles changed to grant full access as seen at this stage
| User | Operation | Object ID | Modified Properties |
|---|---|---|---|
| CompromisedAdmin@example.com | SiteLocksChanged | https://sharepoint.com/<user_page> | [{“OldValue”:”True”,”NewValue”:”False”,”Name”: “SiteAccess”}] |
| CompromisedAdmin@example.com | SiteCollectionAdminAdded | https://sharepoint.com/<user_page> | [{“OldValue”:””,”NewValue”:”CompromisedAdmin@example.com”, “Name”:”SiteAdmin”}] |
| CompromisedAdmin@example.com | SharingPolicyChanged | https://sharepoint.com/<user_page> | [{“OldValue”:”False”,”NewValue”:”True”,”Name”: “ShareUsingAnonymousLinks”}] |
| CompromisedAdmin@example.com | SharingPolicyChanged | https://sharepoint.com/<user_page> | [{“OldValue”:”Disabled”,”NewValue”:”Enabled”, “Name”:”ShareUsingAnonymousLinks”}] |
Figure 3: Altering roles to give the attacker-controlled account full access
Sophos XDR Query
SELECT creation_time, user_id, operation, client_ip, object_id, modified_properties FROM xdr_identity_o365 WHERE lower(user_id) IN (‘CompromisedAdmin@example.com’, ‘CompromisedAdmin@example.com’) AND operation IN (‘SiteLocksChanged’, ‘SiteCollectionCreated’,’ SiteCollectionAdminAdded’)
Collection: TA0009
Email Collection: Remote Email Collection (T1114.002)
After giving themselves full permissions to other users’ mailboxes, the threat actor proceeded to read users’ emails to learn more about the users and the organization. This level of access may also be used to gain personal and sensitive data surrounding banking, business operations, verifying MFA configuration, and much more, including activity related to the phone-number change mentioned in the Account Manipulation section. That user’s emails were at this point accessed approximately 20 days prior to this phase, likely for further in-network reconnaissance.
The threat actor could also access, create, respond, and send emails from the compromised admin account, masquerading as the targeted user whose mailbox they were interacting with. It’s also possible that the phone number added to the account mentioned in Account Manipulation was used to masquerade as the account owner, following access of the user’s emails from another account owned by that user.
Some interesting headers and email creations included responses to passcode requests, banking-related emails (as shown in the table below), and responding to internal project emails.
Exchange Operations: ‘Update’, ‘Create’, ‘SendAs’.
The following table gives an example of the attack-controlled account masquerading as another account as seen at this stage.
| user | operation | mailbox_owner | subject |
| CompromisedAdmin@example.com | SendAs | TargetUser@example.com | “Accepted: [BANK NAME REDACTED] Passcode” |
Figure 4: The attacker-controlled account is adjusted to masquerade as another user
Sophos XDR Query
SELECT creation_time, user_id, operation, client_ip, mailbox_owner_upn, modified_properties, JSON_EXTRACT(item, '$.Subject') AS Subject, item
FROM xdr_identity_o365
WHERE lower(user_id)
IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’)
AND operation IN ('SendAs', 'Create', 'Update')
Email Collection: Email Forwarding Rule (T1114.003)
Transport Rules
In both cases, the threat actor implemented transport rules or edited existing rules. These transport rules follow names related to blocking suspicious activity such as “Block Spoofing” or “[REDACTED] Compromise.”
These rules were used to redirect emails containing certain headers related to “admin” or “OnlineBanking” to the compromised user’s mailbox.
Other rules were added to delete the emails in these transport rules (Indicator Removal: Clear Mailbox Data / T1070.008) so that mail is forwarded to the compromised account and deleted from the user’s mailbox instantaneously.
Exchange Operations: ‘New-TransportRule’, ‘Set-TransportRule’, ‘Enable-TransportRule’.
Transport Rule Example 1
This rule enabled the actor to control which emails would be delivered to a target user’s mailbox by abusing the ModerateMessageByUser feature of Exchange Online.
[
{ "Name": "Name",
"Value": "Block Phishing"
},
{.
"Name": "ModerateMessageByUser",
"Value": "CompromisedAdmin@example.com"
},
{
"Name": "SubjectOrBodyContainsWords",
"Value": "Exchange admin privilege;Global Administrator;AddMailboxPermission;Add Mailbox Permissions;Add-MailboxPermission;User at risk detected;Risky sign-in;Mailbox Permission Changed;High-severity alert;[REDACTED BANKING SUBJECT LINE]"
},
{
"Name": "DeleteMessage",
"Value": "False"
}
]
Transport Rule Example 2
This rule enabled the actor to delete emails with specific subject or body content to avoid raising suspicion of administrators and users of the target organization.
[
{
"Name": "Name",
"Value": "Display name spoofing"
},
{
"Name":"SubjectOrBodyContainsWords"
"Value":"Exchange admin privilege;A user account has been created or modified;Suspicious Inbox Rule;AddMailboxPermission;Add Mailbox Permissions;Add-MailboxPermission;High-severity alert;InsightIDR Incident Alert;Granted mailbox permission;New-InboxRule;CompromisedAdmin@example.com ",
},
{
"Name":"DeleteMessage"
"Value":"True",
},
{
"Name":"RedirectMessageTo"
"Value":"",
},
{
"Name":"ExceptIfFrom"
"Value":"",
},
{
"Name":"HeaderMatchesMessageHeader"
"Value":"",
},
{
"Name":"HeaderMatchesPatterns"
"Value":"",
}
]
The following table provides a list of transport rule names observed at this stage, with some redactions to protect customer identity.
| object_id |
| Block Spoofing |
| Block Phishing |
| Copy of WarnAuditHigh-RiskPhishingPatterns |
| WarnAuditHigh-RiskPhishingPatterns |
| [REDACTED // BANKING] |
| Display name spoofing |
| Bypass SPAM Filter |
| [REDACTED] Compromise |
| redirect [REDACTED] email to DC |
Figure 5: A selection of indicators supporting the hunters’ conclusion that this is T1114.003 in action
Sophos XDR Query
SELECT creation_time, user_id, operation, client_ip, object_id, parameters FROM xdr_identity_o365 WHERE lower(user_id) IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’) AND operation LIKE '%Transport%'
Defense Evasion: TA0005
Impair Defenses: Disable or Modify Tools (T1562.001)
TenantAllowBlockListSpoofItems
In both cases, the threat actor leveraged the Exchange Online function “TenantAllowBlockListSpoofItems” to add spoofed sender entries to the tenant allow list, enabling them to bypass spoofed sender rules and send emails to targets from spoofed domains.
In one of the cases, the threat actor went a step further and added a few additional domains as well as an IP address to the Tenant Allow/Block list:
- iad3a.emailsrvr[.]com
- continental-database[.]com
- “104.161.20[.]102”
Note that the IP in this rule was used in both cases to log into compromised accounts.
Exchange Operation: ‘New-TenantAllowBlockListSpoofItems’.
TenantAllowBlockListSpoofItems Example
[
{
"Name": "Identity"
"Value": "default",
},
{
"Name": "SpoofType"
"Value": "External",
},
{
"Name": "Action"
"Value": "Allow",
},
{
"Name": "SpoofedUser"
"Value": "impersonated-email-account.com",
},
{
"Name": "SendingInfrastructure"
"Value": "botasso.cl",
}
]
Sophos XDR Query
SELECT creation_time, user_id, operation, client_ip, object_id, parameters FROM xdr_identity_o365 WHERE lower(user_id) IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’) AND operation LIKE '%Spoof%'
Indicator Removal: Clear Mailbox Data (T1070.008)
Email Deletion
Deletion of emails was used as a tactic in both cases. Some deletions occurred due to transport rules that the attacker added (Email Collection: Email Forwarding Rule / T1114.003).
Deleted emails can provide context into the purpose of the attack. In one of the cases, we observed emails created regarding passcodes (including for online banking), as well as deleted emails revealing that a passcode had been reset. Further activity was observed, such as “lockouts” and “password resets,” making it clear the actor had likely compromised authentication for the targeted users.
The actor also deleted emails that were received from Microsoft 365 Security, likely to prevent third-party security controls from notifying the victim of the threat.
Exchange Operations: ‘MoveToDeletedItems’, ‘HardDelete’, ‘SoftDelete’.
The following table provides a list of email deletion rules observed at this stage, with some redactions to protect customer identity.
| User | Operation | Mailbox Owner | Subject |
|---|---|---|---|
| CompromisedAdmin@example.com | MoveToDeletedItems | TargetUser@example.com | “Microsoft 365 security: You have messages in quarantine” |
| CompromisedAdmin@example.com | HardDelete | TargetUser@example.com | “Reset your Online Banking password” |
Figure 6: Manipulating the rules to re-route emails that might potentially alert the targeted user to the attacker’s presence
Sophos XDR Query
SELECT creation_time, user_id, operation, client_ip, mailbox_owner_upn,
JSON_EXTRACT(affected_items, '$[0].Subject') AS Subject, affected_items
FROM xdr_identity_o365
WHERE lower(user_id)
IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’)
AND operation IN ('MoveToDeletedItems', 'HardDelete', 'SoftDelete')
Recommendations
There are many options available to combat email account compromises such as the two discussed here. Your best choice will depend upon your business operations, cost, risk model, and requirements.
We’ll put forth some basic suggestions here. However, we strongly recommend prevention and detection mechanisms, tailored to your environment and based on the tactics and techniques detailed in this article (i.e. XDR detections and regular threat hunts).
- Enable MFA for privileged users (or all users, if possible).
- Regularly conduct audits of user account creations and administrator accounts.
- Allowlist IPs of an approved range for authentication (e.g., your VPN subnet) and block non-approved ranges.
- Purchase extended data retention for your XDR product to maintain logging past the default 90-day retention period (or consider event forwarding / logging solutions).
Indicators of Compromise (IOCs)
A list of indicators of compromise associated with this investigation is available on our GitHub.
All the ATT&CK techniques and sub-techniques discussed above are documented on MITRE’s site. Links to each description are provided below for reader convenience.
Acknowledgements
Imane Ismail was instrumental in the investigation of these cases.