Loading AttackTrace...
Loading AttackTrace...
Email Hiding Rules (T1564.008) is a MITRE ATT&CK technique associated with Stealth . Adversaries may use email rules to hide inbound emails in a compromised user's mailbox.
Email Hiding Rules (T1564.008) is a MITRE ATT&CK technique associated with Stealth. Adversaries may use email rules to hide inbound emails in a compromised user's mailbox.
Attackers use Email Hiding Rules because it provides a reliable way to advance their objective within the Stealth tactic, often with a favorable balance of impact versus detectability on Windows, Linux, macOS, Office Suite environments. Defenders should assess this behavior in the context of the affected platform and adjacent activity rather than treating it as a standalone indicator.
Adversaries may use email rules to hide inbound emails in a compromised user's mailbox. Many email clients allow users to create inbox rules for various email functions, including moving emails to other folders, marking emails as read, or deleting emails. Rules may be created or modified within email clients or through external features such as the <code>New-InboxRule</code> or <code>Set-InboxRule</code> PowerShell cmdlets on Windows systems.(Citation: Microsoft Inbox Rules)(Citation: MacOS Email Rules)(Citation: Microsoft New-InboxRule)(Citation: Microsoft Set-InboxRule)
Adversaries may utilize email rules within a compromised user's mailbox to delete and/or move emails to less noticeable folders. Adversaries may do this to hide security alerts, C2 communication, or responses to Internal Spearphishing emails sent from the compromised account.
Any user or administrator within the organization (or adversary with valid credentials) may be able to create rules to automatically move or delete emails. These rules can be abused to impair/delay detection had the email content been immediately seen by a user or defender. Malicious rules commonly filter out emails based on key words (such as <code>malware</code>, <code>suspicious</code>, <code>phish</code>, and <code>hack</code>) found in message bodies and subject lines. (Citation: Microsoft Cloud App Security)
In some environments, administrators may be able to enable email rules that operate organization-wide rather than on individual inboxes. For example, Microsoft Exchange supports transport rules that evaluate all mail an organization receives against user-specified conditions, then performs a user-specified action on mail that adheres to those conditions.(Citation: Microsoft Mail Flow Rules 2023) Adversaries that abuse such features may be able to automatically modify or delete all emails related to specific topics (such as internal security incident notifications).
No universal command represents Email Hiding Rules. Capture the exact command line, arguments, parent process, account, host, and execution time from the investigated environment; do not operationalize unverified examples.
| Event ID | Log Channel | What It Indicates |
|---|---|---|
| Environment-specific | Relevant Windows channel(s) | Correlate authentication, process, object-access, and configuration events with the observed execution context. |
| Sysmon Event ID | Name | Why It's Relevant Here |
|---|---|---|
| Environment-specific | Validate configured telemetry | Use process, network, file, registry, DNS, or image-load telemetry only when relevant and enabled. |
No MITRE detection guidance published for this technique.
Relevant ATT&CK Data Sources: N/A
A universal Sigma rule would create unreliable results because this technique has no single guaranteed observable. Build detection logic from a documented behavior and supported data source, scope it to the affected platform, and validate it against benign administrative activity before deployment.
Start with the data sources named in the detection section. Scope searches by asset, identity, and time window; correlate the primary behavior with preceding access and subsequent actions. A portable query is intentionally not provided where the technique lacks a universal schema or observable.