MITRE ATT&CK T1564.008 Hide Artifacts: Email Hiding Rules: Detecting Evasion

An attacker inside a mailbox will often create one quiet rule so that the victim never sees the reply, the bounce or the security alert that would give them away. MITRE ATT&CK T1564.008 Email Hiding Rules, a sub-technique of Hide Artifacts (T1564) under the Stealth tactic (TA0005), covers rules that move, mark as read or delete inbound mail in a compromised mailbox, and organisation-wide mail flow rules that do the same for every user. This guide is about the hiding behaviour itself: where rules live on each platform, which audit events record them, how to tell a malicious rule from a user's own housekeeping, and how to remove them without losing evidence. Forwarding rules that copy mail out are covered in the T1114 Email Collection Defensive Guide, and message trace detections in the Email Gateway and Message Trace Detection Guide. It is written for SOC analysts, detection engineers and Microsoft 365 or Google Workspace administrators, and covers defence only.

Key takeaways

• A hiding rule is a symptom of account takeover, not a standalone attack. It nearly always follows valid account use (T1078), so finding one means the whole identity needs response, not just the rule.
• Rules are stored server side and sync everywhere. Microsoft notes that reinstalling Outlook or replacing the computer does not remove a malicious rule, because it syncs back from the cloud mailbox.
• The shape of a malicious rule is recognisable. Keyword conditions such as "phish", "hack" or "invoice", a move to RSS Subscriptions, Notes or Archive combined with mark as read, or delete with no condition at all.
• Different tools create rules through different audit operations. In Exchange Online, Outlook on the web logs New-InboxRule and Set-InboxRule, while the Outlook desktop client logs UpdateInboxRules. Detections that watch only one miss the other.
• Organisation-wide rules are the high-impact variant. A mail flow (transport) rule with DeleteMessage or RedirectMessageTo can silently suppress a topic for every mailbox, so treat changes to them as privileged changes.

How T1564.008 works in ATT&CK v20

ATT&CK describes adversaries using email rules in a compromised user's mailbox to delete or move messages to less noticeable folders, to hide security alerts, command and control traffic, or replies to internal spearphishing (MITRE ATT&CK T1534 Internal Spearphishing) sent from the account. It lists Windows, Linux, macOS and Office Suite as platforms and calls out the New-InboxRule and Set-InboxRule cmdlets (PowerShell, T1059.001) as a creation path. It also notes that administrators, or an attacker holding an administrator account, can create organisation-wide rules such as Exchange transport rules that act on all mail.

ATT&CK v20 records two named groups using the sub-technique. FIN4 (G0085) created Outlook rules to delete messages containing words such as "hacked", "phish" and "malware". Scattered Spider (G1015) created rules in security staff mailboxes to delete email from vendor security products. The single mitigation mapped is Audit (M1047): review inbox and transport rules regularly.

Hiding and forwarding are often combined in one rule, so analyse every new rule for both behaviours. For the parent technique, see the MITRE ATT&CK T1564 Hide Artifacts guide.

What a malicious hiding rule looks like

Microsoft's alert classification playbook for inbox manipulation rules and its compromised account guidance list the patterns below. They are a good starting rule set for triage and for detection logic.

Benign rules can share some of these traits: newsletters moved to a folder and marked read are common. The signal is the combination of a security or finance keyword set, a low-visibility destination and an unusual session.

Telemetry and audit events by platform

Detection depends on collecting the right audit operation for each way a rule can be made. Names below are as published in vendor documentation as of November 2026; confirm current names in a real record before building a filter.

Two gaps need attention. First, Microsoft states that the default alert policy "Creation of forwarding/redirect rule" tracks only rules created in Outlook on the web or Exchange Online PowerShell, and it is about forwarding rather than hiding, so build your own detection for move and delete rules and include UpdateInboxRules. Second, the Google Workspace pages we reviewed do not list an audit event for a user creating a Gmail filter, so per-user filter state has to come from a scheduled inventory through the Gmail API (settings.filters.list) using an approved service account. Treat that service account as a privileged non-human identity: scope it to the settings read scope it needs and keep its key out of scripts (see the Google Workspace Domain-Wide Delegation Security Guide). For log onboarding and retention details, see the Microsoft 365 Unified Audit Log Guide for Detection and the Google Workspace Audit Log Detection Guide.

Detections worth building

1. Keyword hiding rule: any New-InboxRule, Set-InboxRule or UpdateInboxRules record whose parameters contain a security or finance keyword list and a move, delete or mark-as-read action. Keep the keyword list in a lookup so you can tune it.
2. Low-visibility destination: move to RSS Subscriptions, Notes or Junk Email combined with mark as read. In Gmail, a filter that removes the INBOX label and the UNREAD label, or adds TRASH, from a match on a security keyword.
3. Delete-all or no-condition rule: any rule with no conditions and a delete or move action. Alert, do not just log.
4. Rule after risky sign-in: rule creation within an hour of a sign-in flagged as risky, from a new country, new ISP or hosting provider IP, or after a token replay alert. This catches rules with innocent-looking keywords.
5. Rules on high-value mailboxes: any new rule on security team, finance, payroll, executive and shared mailboxes that receive vendor security alerts. Scattered Spider targeted exactly these.
6. Mail flow rule change: any transport rule created or changed with DeleteMessage, RedirectMessageTo, BlindCopyTo, Quarantine or SetAuditSeverity set to DoNotAudit, outside a change record. Microsoft documents that DoNotAudit prevents incident reports and message tracking entries for matches.
7. Effect without a rule event: a burst of inbound messages delivered straight to Deleted Items or RSS Subscriptions for one user, detected from message trace. This catches rules created through paths your audit pipeline does not see.

Correlate each hit with the account's sign-in history, MFA method changes, OAuth consents and sent items before deciding severity. The Anomalous Sign-In Detection Guide covers the sign-in side.

Prevention controls

You cannot stop users creating rules, because legitimate users rely on them. Prevention therefore means making account takeover harder and making rule abuse visible quickly.

How to implement

1. Confirm collection (week 1): check that mailbox audit records for New-InboxRule, Set-InboxRule and UpdateInboxRules reach your SIEM. Create a test rule from Outlook on the web and one from the Outlook desktop client in a pilot mailbox and time how long each takes to arrive.
2. Take a baseline (week 1 to 2): run a read-only tenant-wide export of inbox rules including hidden rules, transport rules and, for Google Workspace, user filters. Microsoft's archived Get-AllTenantRulesAndForms.ps1 script is read only; its page says to remove lines 154 to 158 because that connection method was deprecated in July 2023.
3. Review the baseline: sort by the suspicious patterns table, starting with high-value mailboxes. Treat any confirmed malicious rule as an account compromise (see response below).
4. Deploy detections in alert-only mode (weeks 2 to 4): start with detections 3, 5 and 6 (low volume, high value), then add keyword and risky sign-in correlation. Tune keyword lists against the baseline.
5. Schedule the inventory: our recommendation is a daily diff for high-value mailboxes and a weekly diff for everyone else, alerting on new rules that match the suspicious patterns.
6. Roll back safely: detections are read only, so rollback means disabling a noisy rule in the SIEM. Never bulk-delete rules from a baseline: disable suspect rules first so they can be restored if a user relied on them.

Responding to a hiding rule

Microsoft's compromised account guidance orders the response as: block sign-in, revoke sessions, review MFA methods, review consented applications, review admin roles, then review forwarding and inbox rules, then investigate. In practice:

• Preserve first: export the rule with Get-InboxRule -Identity ... -IncludeHidden | Format-List, the audit record with its source IP and the contents of the destination folder before you change anything. The hidden messages are often the best evidence of what the attacker was protecting.
• Contain the identity: block sign-in or reset the password, revoke sessions and refresh tokens, and remove attacker-added MFA methods and app consents. Removing the rule alone leaves the attacker able to recreate it.
• Disable, then remove: Disable-InboxRule while you investigate, then Remove-InboxRule. For mail flow rules, disable and record the full rule definition before deletion.
• Read what was hidden: the destination folder shows which suppliers, banks, colleagues or security tools the attacker wanted silenced, and so who else to warn.
• Hunt sideways: search for the same IP, ISP, rule name or keyword set across the tenant. Rules with identical names in several mailboxes indicate a campaign.

For the full incident flow, see the Business Email Compromise Response Playbook and the Microsoft 365 Tenant Compromise Playbook.

Decision guidance

• Small organisation, no SIEM: rely on built-in alert policies, add a custom alert for New-InboxRule and UpdateInboxRules on finance and admin mailboxes, and run a monthly scripted inventory of all rules including hidden ones.
• Large SOC: stream audit data to the SIEM, build all seven detections, score rules by pattern and session risk, and automate disabling of rules that match the delete-all or security keyword pattern on high-value mailboxes after analyst approval.
• Hybrid Exchange: on-premises mailboxes need PowerShell logging on management servers and the same scheduled inventory, because cloud audit events do not cover them.
• Google Workspace: the filter inventory through the API is the primary control, supported by admin audit events for Gmail setting changes and the external forwarding event.

Detection and measurement

• Audit coverage: percentage of mailboxes where rule creation events from both web and desktop clients reach the SIEM. Target 100 percent.
• Inventory freshness: age of the latest rule inventory for high-value mailboxes. Target under 24 hours.
• Time to detect: median time from a test hiding rule being created to an alert, measured with a scheduled, authorised test.
• Unexplained mail flow rule changes: transport rule changes per month without a change record. Target zero.
• Linked response rate: share of confirmed malicious rules where sessions were revoked and the full identity review completed. Target 100 percent.

Common failure patterns

• Watching only New-InboxRule: rules made in the Outlook desktop client arrive as UpdateInboxRules and are missed.
• Deleting the rule and closing the ticket: the attacker still holds a session, token or app consent and recreates the rule the next day.
• Skipping hidden rules: reviewing rules in the Outlook interface or without -IncludeHidden leaves some rules unseen.
• Ignoring organisation-wide rules: transport rules are reviewed as mail routing configuration, not as a security control, so a DeleteMessage rule targeting incident notification subjects goes unnoticed.
• Single-channel alerting: vendor security alerts that go only to one analyst's mailbox can be hidden by one rule, as Scattered Spider did.

Framework mapping

Practitioner checklist

• Confirm New-InboxRule, Set-InboxRule, UpdateInboxRules and Set-Mailbox records reach the SIEM, tested from both web and desktop clients.
• Run a tenant-wide inventory of inbox rules including hidden rules, transport rules and Gmail filters, and review it against the suspicious patterns table.
• Alert on delete-all rules, low-visibility folder moves with mark as read, and security or finance keyword rules.
• Correlate new rules with risky or unfamiliar sign-ins in the hour before creation.
• Apply stricter monitoring to security, finance, executive and shared alert mailboxes.
• Treat every transport rule change with DeleteMessage, RedirectMessageTo, BlindCopyTo or DoNotAudit as a privileged change needing a change record.
• Send vendor security alerts to the SIEM or ticketing system as well as email.
• On a confirmed rule, preserve evidence, contain the whole identity, then disable and remove the rule.
• Scope any Gmail API inventory service account tightly and manage its key as a secret.

Standards and references

• MITRE ATT&CK: Hide Artifacts: Email Hiding Rules (T1564.008)
• Microsoft Learn: Alert classification for suspicious inbox manipulation rules
• Microsoft Learn: Audit log activities
• Microsoft Learn: Responding to a compromised email account
• Microsoft Learn: Detect and remediate Outlook rules and custom forms injection attacks
• Microsoft Learn: Mail flow rule actions in Exchange Online
• Google for Developers: Managing filters (Gmail API)
• IETF: RFC 5228 Sieve: An Email Filtering Language

Related NHI Mgmt Group resources: T1114 Email Collection Defensive Guide · Email Gateway and Message Trace Detection Guide · ATT&CK Stealth and Defense Impairment Tactics Guide · Account Takeover Response Playbook