An inbox rule files finance replies into a rarely-opened folder and forwards them out — why is the rule record itself your evidence?

## Why a rule beats a message as evidence Mail is easy to argue about. A suspicious message may have been forwarded by the user, planted, or misread. A **rule** is different: it is a configuration change to a mailbox, and hosted platforms record configuration changes as audited operations with an actor, a time, a client address and the parameters supplied. It is the difference between a rumour and a signed receipt. That is why an interviewer hands you the rule rather than the phish. They want to see you treat a mailbox as an estate with a change log. ## What the record gives you, field by field - **Operation** — the rule was *created* (or modified). Creation is the strong one: nothing about the mailbox's normal use produces it accidentally. - **Actor** — the account the operation ran as. Note it does not prove a person: it proves a credential or a token was accepted and used. - **Timestamp** — the anchor for your timeline. - **Client address / client info** — the pivot. It ties the operation to a session, and it lets you sweep the whole tenant for other accounts touched from the same address. - **Parameters** — the rule's semantics: which messages it matches, where they go, whether they are marked read or deleted, and any external forwarding target. ## Reading the intent out of the parameters A takeover rule is written to solve the intruder's problem, which is that the legitimate owner is still reading the mailbox. The classic shape does three things at once: 1. **Match narrowly** on the thread that matters — keywords such as invoice, payment, wire, bank, or a specific counterparty domain. 2. **Hide** — move matches to a folder nobody opens (RSS Subscriptions, Conversation History, an empty folder named with a space) and mark them read, so no unread badge appears. 3. **Keep a copy flowing** — forward externally, or simply leave the intruder to read the folder over their own session. A rule that only deletes is not weaker evidence; in fraud cases it is often stronger. Silently deleting the supplier's "that is not our bank account" reply is precisely what makes the fraud work, and it means the exfiltration is happening *inside the thread* rather than out of band. ## Dating the rule against the rest of the trail This is the analytical move the question is really testing. Take the rule's creation time and place it against: - the mailbox's session activity, so you can say which session created it; - the sign-in records for that session, giving you the credential event, the address and the client; - the message trace, so you can list which messages the rule would have matched between creation and discovery — that is your exposure set; - the folder's contents and the mailbox audit's move operations, to check the rule actually fired. Two directional cautions. First, rule creation is a **lower bound**: the intruder may have been reading quietly for weeks before deciding to automate. Second, an authenticated operation attributes to a *credential*, not to a human — the owner themselves, an authorised delegate, or a helpdesk account with mailbox rights are all live hypotheses until the client address and session say otherwise. ## Scope: the mailbox rule versus the tenant rule The same idea exists at two very different blast radii, and they are recorded in different trails. | Change | Scope | Recorded in | |---|---|---| | Inbox rule | One mailbox | Mailbox audit trail | | Mailbox forwarding setting | One mailbox | Mailbox / admin audit | | Transport or journaling rule | Every mailbox in the tenant | Tenant admin audit trail | If you find a mailbox rule, you check the mailbox. If you find a transport rule copying outbound mail to an external address, you are looking at an administrative compromise, the affected population is everyone, and the actor to investigate is an admin account. A good answer names both and says which trail carries which. ## Remediation implications The rule is server-side configuration. Resetting the password does not remove it, and neither does the user changing their client or device. Eradication means: delete the rule, remove any mailbox forwarding setting and external contact it depends on, terminate live sessions, and then re-enumerate rules across the tenant — an intruder who planted one has usually planted more, and their next account is often reachable from the same client address you already have. Finally, sweep for the *pattern*, not the string. A hunt for rules that forward externally, that write into a small set of low-traffic folders, or that were created from an address no other account uses, will find the next one; a hunt for that exact rule name will not.