Email Hiding Rules
Adversaries employ email hiding rules in order to cover their tracks and avoid alerting victims to their activity.
#5
Overall Rank
9.0%
Customers Affected
610
Threats Detected
Why do adversaries abuse email hiding rules?
When an adversary compromises an email inbox and uses it to send or intercept emails, they often cover their tracks by moving, hiding, or otherwise deleting suspicious email messages, thereby concealing them from their victim. Rather than manually deleting sent emails, which runs the risk of neglecting to cover some of their tracks, an adversary may utilize the native automation offered by Outlook inbox rules to hide their activity so as not to alert the victim of their actions.
How do adversaries abuse email hiding rules?
The difference between the Email Hiding Rule ATT&CK technique and its sibling Email Forwarding Rule lies in how they handle incoming messages and their intended purposes. In short, an email hiding rule affects the visibility and organization of emails in the same mailbox, while an email forwarding rule sends emails to another mailbox entirely.
The mechanism by which an adversary uses Outlook inbox rules to cover their tracks is identical to the mechanism for creating a forwarding rule but the configuration will differ slightly. An adversary may set one or more of the following inbox rule properties that would distinguish it specifically as a potential hiding rule:
- The DeleteMessage property is set to
True. Setting this option sends the target message to the Deleted Items folder, resulting in the victim being unlikely to see messages that an adversary wants to hide as they are unlikely to closely inspect the contents of their deleted email folder. - The MarkAsRead property is set to True. This will mark the target message as read, which benefits an adversary by not incrementing the unread email count for messages they want hidden from the victim.
- The MoveToFolder property is set to any one of the following built-in Exchange folders. These folders are less likely to be inspected by the victim:
ArchiveConversation History(frequently abused by adversaries)Deleted ItemsJunk EmailRSS Feeds(frequently abused by adversaries)RSS Subscriptions(frequently abused by adversaries)
- When the message subject or email body contains words related to phishing or a security incident—e.g., “phishing,” “hack,” “spam,” etc. Adversaries most often specify terms like these using the SubjectOrBodyContainsWords property.
How adversaries abuse email rules
An email hiding rule affects the visibility and organization of emails in the same mailbox, while an email forwarding rule sends emails to another mailbox entirely.
An Exchange Online administrator can globally disable inbox rule creation via the Outlook web UI by running the following PowerShell cmdlet:
Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -RulesEnabled $FalseNow, when a user attempts to create an inbox rule, they will be prevented from doing so, as seen in the image below. Note that this only disables rule creation via the web UI. It does not disable rule creation via PowerShell cmdlets. Be sure to still audit inbox rule creation and apply additional scrutiny to any rule creation.
Application Log
For most organizations, MITRE Data Source DS0015: Application Log will provide the visibility necessary to detect suspicious email forwarding rules. The details of what activity is visible may differ between platforms such as Google Workspace or Microsoft Office 365 (on and off premise), but login activity and email rule creation are both actions that should be logged by whichever email application your organization uses.
For Office 365, this would include the Unified Audit Log (UAL). If you’re running an on-premise Exchange server, it’s a little less straightforward, but you can likely collect relevant logs from a combination of Mailbox Audit Logging and Exchange Admin center, and you can hunt for email rules using PowerShell cmdlets and by monitoring other log sources.
For Google Workspace users, the Security Investigation Tool will be your starting point and suspicious email rules can be observed by obtaining user Gmail settings through the Gmail API.
The following is a sample raw UAL New-InboxRule operation event:
{
"AppAccessContext": {
"AADSessionId": "eabaadb1-aa03-4af7-953f-54c535ac3ae9",
"IssuedAtTime": "2024-12-16T21:17:03",
"UniqueTokenId": "eCTQGv3TEUqoAMRpXqGWeQ"
},
"CreationTime": "2024-12-16T21:23:44",
"Id": "05ecde39-e0c1-4033-b0be-c6ecd890ecf8",
"Operation": "New-InboxRule",
"OrganizationId": "27ba49f0-e3fb-4697-847c-4607fc845d30",
"RecordType": 1,
"ResultStatus": "True",
"UserKey": "victim@contoso.onmicrosoft.com",
"UserType": 2,
"Version": 1,
"Workload": "Exchange",
"ClientIP": "150.120.122.49:29866",
"ObjectId": "VictimUser\\...",
"UserId": "victim@contoso.onmicrosoft.com",
"AppId": "fb78d390-0c51-40cd-8e17-fdbfab77341b",
"AppPoolName": "MSExchangeAdminApiNetCore",
"ClientAppId": "",
"CorrelationID": "",
"ExternalAccess": false,
"OrganizationName": "contoso.onmicrosoft.com",
"OriginatingServer": "SJ0P220MB0558 (15.20.8251.004)",
"Parameters": [
{
"Name": "MarkAsRead",
"Value": "True"
},
{
"Name": "Name",
"Value": "..."
},
{
"Name": "Mailbox",
"Value": "victim@contoso.onmicrosoft.com"
},
{
"Name": "MoveToFolder",
"Value": ":\\Conversation History"
}
],
"RequestId": "a0959e54-79ae-4711-91ec-b23a5cfae265",
"SessionId": "eabaadb1-aa03-4af7-953f-54c535ac3ae9"
}
This event could be summarized as follows:
“At 2024-12-16T21:23:44, within Entra ID tenant ID 27ba49f0-e3fb-4697-847c-4607fc845d30, the user victim@contoso.onmicrosoft.com created a inbox rule named ... for their own mailbox using the Microsoft Exchange REST API Based Powershell (ID: fb78d390-0c51-40cd-8e17-fdbfab77341b) app from IP address 150.120.122.49. The inbox rule marks all incoming messages as read and moves them to the built-in Conversation History folder.”
In the above event, the fields are of particular value:
AppAccessContext.UniqueTokenId– the unique token identifier for the logon session. This value can be used to correlate the UAL event to a non-interactive sign-in event in the AADNonInteractiveUserSignInLogs table via theUniqueTokenIdentifierfieldCreationTime– the datetime that the event occurredOperation– indicates that a new inbox rule was createdOrganizationId– the Entra tenant ID within which the event occurredUserKey– the identity that created the inbox ruleAppId– the application ID of the service principal that created the inbox rule on behalf of the userParameters– the inbox rule parametersMailbox– the mailbox that the rule was created for. This will matchUserKeyif the user created the inbox rule for their own mailbox. These fields will not match if the user created an inbox rule for another mailboxSessionId– a unique identifier that correlates activity from the same logon session. This field allows a defender to build out a contextual timeline of events that the actor performed
Start by ensuring that New-InboxRule events are collected. Other inbox rule events exist (Set-InboxRule, Remove-InboxRule, Disable-InboxRule, UpdateInboxRules, Set-Mailbox) but they are less likely to be used by adversaries for establishing hiding rules.
Assuming you expect legitimate inbox rule creation in your environment, collecting New-InboxRule events is insufficient to discern legitimate from suspicious events. A detection strategy would begin by focusing on any of the following event properties being set as described above:
Additional scrutiny can be applied to new inbox rules by considering:
- If the rule name contains only special characters or only a few non-sensical characters, e.g.
@,;,...,k,zzx, etc. - If the rule originated from a suspicious IP address, e.g., from a VPN, unexpected geographic region, or Tor exit node.
- The
AppIdused deviates from expected usage. In order of highest frequency to least, we often see the followingAppIdsused with inbox rule creation:
| Application ID | Resolved app name |
5d661950-3475-41cd-a2c3-d671a3162bc1 | Microsoft Outlook |
00000002-0000-0ff1-ce00-000000000000 | Office 365 Exchange Online |
d3590ed6-52b3-4102-aeff-aad2292ab01c | Microsoft Office |
9199bf20-a13f-4107-85dc-02114787ef48 | One Outlook Web (aka OWA) |
fb78d390-0c51-40cd-8e17-fdbfab77341b | Microsoft Exchange REST API-based Powershell |
View the atomic test for T1564.008: Email Hiding Rules.
The following example shows how to use the ExchangeOnlineManagement PowerShell module to create a suspicious email hiding rule:
Connect-ExchangeOnline -UserPrincipalName 'USER@INSERT_TENANT.onmicrosoft.com'
New-InboxRule -Mailbox 'USER@INSERT_TENANT.onmicrosoft.com' -Name '...' -MarkAsRead $true -MoveToFolder ':\Conversation History'
# Cleanup
Remove-InboxRule -Mailbox 'USER@INSERT_TENANT.onmicrosoft.com' -Identity '...' -Confirm:$FalseThis test will create an inbox rule named ... that marks all messages as read and moves them to the built-in Conversation History folder.
Security gaps? We got you.
Get curated insights on managed detection and response (MDR) services, threat intelligence, and security operations—delivered straight to your inbox every month.