A suspicious inbox rule is one of the most reliable takeover tells. Separate the user who
made a filing rule on Tuesday from the attacker hiding their tracks — and respond
accordingly. When the verdict is malicious, this is also the full inventory-and-remove
sweep (rules, forwarding, delegates). Work it in order:
1. Capture the rule's facts from the alert: rule name, conditions, actions (forward,
delete, move, mark-as-read), creation timestamp, and the creating client/IP/session if
present.
2. Score the malicious markers before contacting anyone: rule named ".", "..", or a single
character; actions that hide mail (move to RSS Feeds, Deleted Items, Archive, or
mark-as-read); conditions keyed on words like invoice, payment, password, security, or
helpdesk; auto-forwarding to an external address; creation from an unfamiliar IP or
during a sign-in anomaly window. Search for concurrent alerts on the same account — an
inbox rule plus a sign-in anomaly is takeover until proven otherwise.
3. Legitimacy check with the user via a verified channel (a number on file, not an address
from the ticket): "did you create a mail rule recently — what does it do?" Let them
describe it; do not read the rule to them first.
4. Verdict:
- User created it and the description matches a benign rule → document who confirmed,
when, and the rule's behavior; move to pre-closure per soc-classification-tree.
- User does not recognize it, is unreachable, or the rule carries malicious markers
regardless of the user's memory → treat as compromise: inventory ALL rules, forwarding
settings, delegates, and send-as grants on the mailbox (attackers rarely stop at one),
preserve each artifact's definition and timestamp before removing it, remove the
malicious entries, and run the account-takeover-runbook — credential rotation, session
revocation, MFA sweep included.
5. Document the decision, not just the action: the note records the rule definition, the
markers found, who confirmed what, every removal with a timestamp, and the verdict
reasoning.
Guardrails — always:
- Identity first — a mail rule is an identity artifact, not a malware problem.
- A user "confirming" a rule that hides invoice or password mail still warrants scrutiny —
users confirm things to close tickets. Malicious markers outvote a vague confirmation.
- Never close on user silence or assumption; unreachable within the severity clock →
contain fast, investigate second.
- Removing the rule without rotating credentials leaves the attacker their access — removal
and rotation travel together on the malicious path. Preserve each artifact before
deleting it.
- When in doubt, escalate — a false escalation is cheap, a missed compromise isn't.
- Defensive writing in client communications: "a suspicious mail rule was detected and
removed," not "you were hacked." Plain text only; never invent data.
Magic Library