T1564.008: Email Hiding Rules
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 New-InboxRule or Set-InboxRule PowerShell cmdlets on Windows systems.[1][2][3][4]
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 malware, suspicious, phish, and hack) found in message bodies and subject lines. [5]
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.[6] 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).
Analyst context for executives and security teams
Email Hiding Rules matter because a compromised mailbox can be made to suppress the very messages that would alert a user, help desk, SOC, or incident response team to suspicious activity. By abusing normal mailbox or organization-wide mail rules, an adversary with valid access may move, mark read, or delete messages about security alerts, phishing responses, or incident notifications. The business risk is delayed awareness: the organization may still be receiving warning signs, but the people who need to see them may not.
Executive priority
Treat mailbox rule abuse as an identity and email-security control question, not just a mail-client feature. Leaders should ask whether the organization can audit user-level inbox rules and administrator-level transport/mail-flow rules, whether changes are reviewed for high-risk mailboxes, and whether incident communications depend on channels an attacker could silently filter. This technique is especially relevant to SOC readiness, IR communications, compliance evidence for audit logging, and resilience of executive, finance, legal, help desk, and security mailboxes.
Technical view
ATT&CK defines this as a stealth sub-technique of Hide Artifacts affecting Windows, Linux, macOS, and Office Suite environments. The supplied description highlights inbox rules created or modified through email clients and Exchange PowerShell cmdlets such as New-InboxRule and Set-InboxRule, as well as organization-wide Exchange transport/mail-flow rules. SOC and detection teams should validate visibility into rule creation, modification, deletion, and rule actions that move, delete, or mark messages as read, especially when conditions reference security-related terms such as malware, suspicious, phish, or hack. Relationship context includes DET0192 as a detection strategy and M1047 Audit as the mitigation, so the practical validation point is whether auditing captures enough rule and actor context to support triage.
Likely telemetry
- Mailbox audit logs for inbox rule creation, modification, and deletion
- Administrative audit logs for mail-flow or transport rule changes
- Email platform logs showing rule actions such as move, delete, or mark-as-read
- PowerShell or Exchange administration logs involving New-InboxRule and Set-InboxRule where available
- Authentication and account activity for the user or administrator who changed the rule
Detection direction
- Validate the DET0192-aligned detection strategy against real audit sources rather than assuming email platforms log rule changes by default.
- Alert or review rules that delete messages, move messages to obscure folders, or mark messages as read when created by unusual users, from unusual sessions, or on high-value mailboxes.
- Review organization-wide mail-flow or transport rules separately from user inbox rules because they can affect many recipients at once.
- Tune for administrative and user workflows that legitimately create filtering rules to reduce false positives, but require higher scrutiny for rules matching security, phishing, malware, incident, or help-desk-related terms.
- During account-compromise investigations, include mailbox rule review as a standard evidence step; otherwise responders may miss why alerts or replies were not seen.
Mitigation priorities
- Prioritize auditing, consistent with M1047, for mailbox rule and mail-flow rule activity across user and administrator scopes.
- Periodically review rule inventories for high-risk users, shared mailboxes, and administrative accounts.
- Restrict and monitor administrative capabilities that can create organization-wide transport or mail-flow rules.
- Include mailbox rule review in incident response playbooks for suspected valid-credential compromise and internal spearphishing scenarios.
- Use out-of-band or redundant communication paths for critical incident notifications so a compromised mailbox rule cannot become a single point of failure.
Analyst notes and limits
The relationship context shows known ATT&CK relationships to FIN4 and Scattered Spider using this technique, but that should be treated as threat-informed prioritization rather than proof of current activity in any environment. The most important local question is whether defenders can reconstruct who changed a rule, what the rule did, which messages were affected, and whether the change coincided with suspicious account activity.
MITRE provides no official detection text for this object in the supplied fields. Specific log names, default audit settings, retention periods, and detection logic depend on the email platform and local configuration. This take does not assert active exploitation, customer exposure, or guaranteed coverage.
Email Hiding Rules
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 New-InboxRule or Set-InboxRule PowerShell cmdlets on Windows systems.[1][2][3][4]
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 malware, suspicious, phish, and hack) found in message bodies and subject lines. [5]
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.[6] 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).
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1564 | Hide Artifacts | This object subtechnique of Hide Artifacts. |
Groups, software, and campaigns
G1015: Scattered Spider
Scattered Spider is a native English-speaking cybercriminal group active since at least 2022. [1] [2] The group initially targeted customer relationship management (CRM) providers, business process outsourcing (BPO) firms, and telecommunications and technology companies before expanding in 2023 to gaming, hospitality, retail, managed service provider (MSP), manufacturing, and financial sectors. [2] Scattered Spider relies heavily on social engineering, including impersonating IT and help-desk staff, to gain initial access, bypass multi-factor authentication (MFA), and compromise enterprise networks. The group has adapted its tooling to evade endpoint detection and response (EDR) defenses and used ransomware for financial gain. [3] [4] [5] Scattered Spider had expanded into hybrid cloud and identity environments, using help-desk impersonation and MFA bypass to obtain administrator access in Okta, AWS, and Office 365. [6]
G0085: FIN4
FIN4 is a financially-motivated threat group that has targeted confidential information related to the public financial market, particularly regarding healthcare and pharmaceutical companies, since at least 2013.[1][2] FIN4 is unique in that they do not infect victims with typical persistent malware, but rather they focus on capturing credentials authorized to access email and other non-public correspondence.[1][3]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 6bfc55644657… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Microsoft Inbox Rules
Microsoft. (n.d.). Manage email messages by using rules. Retrieved June 11, 2021.
Open source URL -
[2]
MacOS Email Rules
Apple. (n.d.). Use rules to manage emails you receive in Mail on Mac. Retrieved June 14, 2021.
Open source URL -
[3]
Microsoft New-InboxRule
Microsoft. (n.d.). New-InboxRule. Retrieved June 7, 2021.
Open source URL -
[4]
Microsoft Set-InboxRule
Microsoft. (n.d.). Set-InboxRule. Retrieved June 7, 2021.
Open source URL -
[5]
Microsoft Cloud App Security
Niv Goldenberg. (2018, December 12). Rule your inbox with Microsoft Cloud App Security. Retrieved June 7, 2021.
Open source URL -
[6]
Microsoft Mail Flow Rules 2023
Microsoft. (2023, February 22). Mail flow rules (transport rules) in Exchange Online. Retrieved March 13, 2023.
Open source URL -
[7]
mitre-attack T1564.008Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.