4.3 Detection: Inbox Rule Deleting or Moving Items to Hide Adversary Activity

The rule that makes evidence disappear

Hiding rules serve a different purpose than forwarding rules. Forwarding rules exfiltrate data: the attacker captures email they want. Hiding rules conceal activity: the attacker prevents the legitimate user from discovering the compromise. The two techniques are frequently deployed together: one rule forwards payment-related email to the attacker, and a companion rule deletes replies that would alert the user.

The hiding rule patterns in OfficeActivity: DeleteMessage set to True (permanently deletes matching emails), MoveToFolder targeting RSS Feeds, Conversation History, or other folders the user never checks, MarkAsRead combined with MoveToFolder (the email is moved and marked read, so it doesn't appear as unread even if the user opens the folder), and SoftDeleteMessage set to True (moves to Deleted Items, which many users don't monitor).

The detection logic examines the Parameters JSON payload in OfficeActivity. Every inbox rule creation or modification event includes the rule's conditions (who, what keywords) and actions (delete, move, forward) in the Parameters field. The query extracts these parameters and filters for destructive or concealment actions. The key insight: legitimate inbox rules almost never permanently delete email. They sort, categorize, move to specific folders, but automatic permanent deletion based on sender or keyword is an attacker pattern. The DeleteMessage flag alone is a high-confidence indicator.

The rule name is another signal. Legitimate inbox rules have descriptive names ("Move newsletters to Reading folder," "Forward receipts to accounting"). Attacker-created hiding rules typically have blank names, single-character names (like "."), or deliberately innocuous names designed to be overlooked during a casual rule review. The output field RuleName helps the analyst distinguish: a rule named "." that deletes emails from supplier domains is not something the user created.

Estimated time: 40 minutes.

Rule specification

Hypothesis: An attacker hiding BEC activity will create inbox rules that delete or move emails to obscure locations. The rule targets emails from specific senders (suppliers, contacts the attacker is impersonating) or containing specific keywords (payment, invoice, bank). The rule name is typically short, blank, or designed to be invisible.

Data source: OfficeActivity. Operation "New-InboxRule" or "Set-InboxRule", Parameters containing DeleteMessage, SoftDeleteMessage, or MoveToFolder with suspicious target folders.

MITRE ATT&CK: Defense Evasion → T1564.008 (Email Hiding Rules).

Severity: High (rules that delete emails are always suspicious, legitimate users rarely auto-delete).

The KQL detection query

// Hypothesis: Inbox rule designed to hide attacker activity
// ATT&CK: T1564.008 (Email Hiding Rules)
let hiding_actions = dynamic([
    "DeleteMessage", "SoftDeleteMessage",
    "MoveToFolder", "MarkAsRead"
]);
let suspicious_folders = dynamic([
    "RSS Feeds", "RSS Subscriptions",
    "Conversation History", "Junk Email"
]);
OfficeActivity
| where TimeGenerated > ago(1h)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend Params = parse_json(Parameters)
// Check for hiding action parameters
| where Params has_any (hiding_actions)
// Extract rule details
| mv-apply P = Params on (
    summarize Actions = make_bag(
        bag_pack(tostring(P.Name), tostring(P.Value)))
)
| extend
    RuleName = tostring(Actions.Name),
    DeletesEmail = Actions.DeleteMessage == "True"
        or Actions.SoftDeleteMessage == "True",
    MoveTarget = tostring(Actions.MoveToFolder),
    MarksRead = Actions.MarkAsRead == "True"
| extend SuspiciousFolder = MoveTarget in (suspicious_folders)
// High confidence: deletes email OR moves to suspicious folder
| where DeletesEmail or SuspiciousFolder
| project
    TimeGenerated,
    UserId,
    Operation,
    RuleName,
    DeletesEmail,
    MoveTarget,
    SuspiciousFolder,
    MarksRead,
    ClientIP

TimeGenerated          UserId                         Operation       RuleName  DeletesEmail  MoveTarget  SuspiciousFolder  MarksRead  ClientIP
2026-02-06T07:18:44Z   j.harrison@northgateeng.com    New-InboxRule   .         true          (empty)     false             false      185.234.xx.xx

The rule name is a single period, nearly invisible in the Outlook rules list. This is a deliberate obfuscation technique: Outlook displays inbox rules in a list, and a rule named "." appears as a barely-visible dot that users scroll past without noticing. Other common attacker rule names include empty strings (where the rule name column appears blank), single spaces, or names that mimic legitimate Outlook rules like "Clutter" or "Focused." The detection doesn't rely on rule name analysis because the name is under the attacker's control: the detection focuses on what the rule does (deletes, moves to suspicious folders), not what it's called.

DeletesEmail: true means matching emails are permanently deleted via the DeleteMessage parameter, not moved to Deleted Items. This is the most aggressive hiding pattern: the email never reaches the user's visible folders, and without the detection or a manual audit of inbox rules, the deletion is invisible. The user never sees the bounce-back notifications, the compromised account alerts, or the suspicious sign-in warnings that security teams send during an investigation. That's the purpose: the attacker uses the hiding rule to ensure the user doesn't discover the compromise by receiving security notifications.

The ClientIP matches the attacker from the preceding DET-SOC-001 and DET-SOC-008 alerts. This IP correlation across multiple detections is the evidence chain: the same attacker IP appears in the anomalous sign-in (Module 3), the forwarding rule creation (Section 4.2), and now the hiding rule creation. Three alerts from the same IP, affecting the same account, within a short time window, this is a complete BEC setup sequence.

The MarksRead: false field means the attacker didn't add a mark-as-read action. Some attackers use a subtler approach: instead of deleting the email, they mark it as read and move it to a deep subfolder. The user might eventually find the email, but the read status means it doesn't trigger the unread count badge in Outlook: the user has no visual indicator that something arrived.

The Sigma equivalent

title: Inbox Rule Deleting or Hiding Email
id: det-soc-009
status: production
description: |
  Detects inbox rules that delete emails or move them to
  obscure folders (RSS Feeds, Conversation History).
  Defense evasion — attacker hides evidence of BEC activity
  from the legitimate mailbox owner.
author: Ridgeline Cyber Detection Engineering
date: 2026/05/17
tags:
  - attack.defense_evasion
  - attack.t1564.008
logsource:
  product: m365
  service: exchange
detection:
  selection:
    Operation:
      - 'New-InboxRule'
      - 'Set-InboxRule'
  filter_delete:
    Parameters|contains:
      - 'DeleteMessage'
      - 'SoftDeleteMessage'
  filter_suspicious_move:
    Parameters|contains: 'MoveToFolder'
  condition: selection and (filter_delete or filter_suspicious_move)
falsepositives:
  - Newsletter management rules (move to folder)
  - Users auto-deleting notification emails from known senders
level: high

PowerShell: investigate what the hiding rule targeted

When a hiding rule is detected, the analyst needs to understand what emails it was targeting, this reveals what the attacker wanted to conceal:

$upn = "j.harrison@northgateeng.com"
# 1. Get all inbox rules with full condition details
Get-InboxRule -Mailbox $upn | ForEach-Object {
    [PSCustomObject]@{
        Name              = $_.Name
        Enabled           = $_.Enabled
        From              = ($_.From -join "; ")
        SubjectContains   = ($_.SubjectContainsWords -join "; ")
        BodyContains      = ($_.BodyContainsWords -join "; ")
        DeleteMessage     = $_.DeleteMessage
        MoveToFolder      = $_.MoveToFolder
        ForwardTo         = ($_.ForwardTo -join "; ")
        MarkAsRead        = $_.MarkAsRead
    }
} | Format-List
# 2. Check Recoverable Items for deleted emails
#    (emails deleted by rules may be in Recoverable Items)
Search-Mailbox -Identity $upn `
    -SearchQuery 'subject:"invoice" OR subject:"payment"' `
    -TargetMailbox "DiscoverySearchMailbox" `
    -TargetFolder "Harrison-Recovery" `
    -LogLevel Full

Name            : .
Enabled         : True
From            : *@acme-suppliers.com; *@globalparts.co.uk
SubjectContains : invoice; payment; wire; bank details; remittance
BodyContains    :
DeleteMessage   : True
MoveToFolder    :
ForwardTo       :
MarkAsRead      : False

The rule conditions reveal the attacker's target: emails from NE's two primary suppliers (acme-suppliers.com, globalparts.co.uk) containing payment-related keywords. The attacker is running a BEC operation targeting NE's supplier payment workflow. The hiding rule prevents Harrison from seeing supplier replies when they question the fraudulent payment instructions the attacker sent from Harrison's account. The eDiscovery search (step 2) attempts to recover the deleted emails from Recoverable Items. Exchange retains deleted items for the retention period (default 14 days) even when rules delete them.

Entity mapping

The entity mapping connects the Account (the mailbox owner or the compromised account that created the rule), the Mailbox entity (the target mailbox where the hiding rule was created), and the IP entity (the source IP of the rule creation, external IPs creating inbox rules are high-confidence indicators of remote BEC activity). The IP entity is particularly valuable for correlation: the same attacker IP that created the hiding rule should match the anomalous sign-in (Module 3), the forwarding rule (Section 4.2), and subsequent BEC emails (Section 4.8). Three or more detections from the same IP confirm a coordinated BEC campaign.

[
  {
    "entityType": "Account",
    "fieldMappings": [{
      "identifier": "FullName",
      "columnName": "UserId"
    }]
  },
  {
    "entityType": "IP",
    "fieldMappings": [{
      "identifier": "Address",
      "columnName": "ClientIP"
    }]
  }
]

False positive profile and tuning

Email management applications (clean.email, SaneBox, Unroll.me) create inbox rules programmatically when users configure cleanup or filtering preferences. These rules often mark-as-read, move, or delete emails matching specific criteria, particularly newsletter and promotional email. The initiating client (ClientInfoString in OfficeActivity) identifies the application. SaneBox rules typically filter by sender domain to a "SaneLater" folder. Clean.email rules may use bulk delete actions on promotional categories. Maintain an exclusion list of known email management application client strings, but never exclude rules with DeleteMessage on keywords like "security," "password," "reset," or "suspicious", those are the patterns an attacker uses to hide security notifications.

Corporate mail flow rules deployed by IT sometimes create user-level inbox rules during migration or onboarding. These originate from admin accounts with known UPNs. Exclude known admin service accounts from the detection.

Outlook mobile app creates inbox rules (focused inbox, sweep rules) that can trigger the detection. These rules use standard Outlook client strings and perform non-suspicious actions (move to folder, not forward or redirect). Filter by action type: rules that forward, redirect, or delete should always alert. Rules that only move to folders are lower priority.

// Add after the Parameters filter to exclude known clients
| where ClientInfoString !has_any (
    "Client=OWA",
    "Client=OutlookMobile",
    "SaneBox", "clean.email")
// Keep DeleteMessage rules regardless of client — always alert
    or Params has "DeleteMessage"

The tuning preserves the highest-confidence signals: any rule with DeleteMessage always alerts regardless of client. The client-based exclusion only applies to move and mark-as-read operations, where legitimate email management applications are a known FP source. This reduces noise from Outlook mobile and email management services without missing the destructive rules that are almost never legitimate.