Attackers tend to set up their own rules rather than touch the ones a user already had. The Vectra MDR team researched this across customer environments, and here is what our analysts' everyday decisions, read together, add up to, and what a SOC can do with it.
As an MDR team, we triage detections from many customer environments every day. One of them, our Microsoft 365 Suspicious Mailbox Rule detection, flags inbox rules that warrant a second look. Most of these detections resolve one of two ways: an analyst closes it as benign, or escalates it to the customer to validate. Individually, these are routine calls. Taken together, drawn from customer environments across regions and industries and grounded in what customers confirm when cases are escalated, they turned out to encode something valuable: a precise, shared picture of how attackers actually use inbox rules.
Why mailbox rules are worth the attention
Inbox rules are a normal productivity feature: they forward, move, flag, or delete mail automatically.

The same feature is a favorite of attackers after an account takeover, because it lets them control a mailbox silently, with no malware and no process on any endpoint. Two abuses dominate: forwarding mail out to an external address (exfiltration, MITRE ATT&CK T1114.003), and moving or deleting incoming mail to hide security notices and replies (evasion, MITRE ATT&CK T1564.008).

Why not just study the attacks?
A fair question: if you want to understand attackers, why not simply study your confirmed attacks? Studying attacks in isolation shows you what attackers do, but not how often the same action turns up in ordinary, benign use, and that contrast is exactly what makes a behavior worth acting on. A rule that deletes incoming mail looks alarming in a pile of attacks; only alongside everyday activity do you see that it is genuinely rare, and therefore a signal. Understanding what is normal in order to recognize what isn't is a familiar idea in detection. We applied it to a different kind of "normal": the everyday decisions analysts make about a detection. That benign majority is not clutter to discard. Every benign close is a judgment about what isn't an attack, and read together, those judgments are knowledge that studying the attacks alone would throw away.
The profile our data drew
Taken together, the analysts' decisions sort each behavior somewhere between "routine" and "worth a closer look." Moving mail into a folder is the most common thing we see attackers do with a rule, with forwarding and deleting behind it, though, as it turns out, how common a behavior is, tells you little about how much it should worry you. Here is what stood out.
They create; they don't rewrite. Across the attacks we have confirmed, the malicious rules are the attacker's own, created and then changed, often in a single burst, rather than a customer's long-standing rule repurposed. The pattern is consistent: attackers bring their own rules. Where we can measure the routine side most cleanly is mail moved to a folder: changing a long-standing move-to-folder rule, in the cases where analysts could see exactly what the change did, is almost never worth escalating. Everyday housekeeping and an attacker's fresh setup look nothing alike.
Delete is rare, and loud. Very few mailbox rules delete incoming mail, but when an analyst sees one, it is escalated far more often than the everyday norm, and our confirmed cases say that instinct is right. Deletion to bury replies and security notices is a hiding move, and it behaves like one in the data. Where changing an old move-to-folder rule is noise, deletion is signal.
Forwarding is the grey zone. Forwarding sits in the middle: neither rare nor routine, with a real share of confirmed-malicious cases behind it. Not everything separates cleanly, and forwarding is where care matters most rather than where attention can be relaxed. Saying that honestly is part of the point.
How attackers give themselves away. Two tells recurred in our confirmed cases. Attacker-created rules disproportionately carry odd, minimal names, single letters, a stray dot or two, the kind of throwaway label a person would not choose. And when attackers move mail, they lean on standard default folders rather than anything bespoke. Neither is proof alone, but together they tighten the picture.
What a SOC can do with this
A profile like this can be put to work two ways at once: to quiet the routine, and to sharpen the real. The way scoring works in the Vectra AI Platform makes doing so safe: Every detection carries a severity based on what the rule does, and that severity feeds, alongside other factors, into a single account-level score that reflects everything active on the same account. So, the severity a routine pattern contributes can be turned down without creating a blind spot: an account that also shows an unusual login, or any other independent signal, still rises to the top. The routine gets quieter; the genuinely suspicious combination stays loud.
Crucially, none of this is automatic. A pattern that looks routine in our history is a hypothesis, so we validate each piece of the profile against our own confirmed attack cases before it informs anything, and any change to how a detection scores would go through security review, not straight into production.

What this makes better
The point of a profile like this is not the profile itself, but what it lets the detection and the service around it become. Instincts that once lived only in an experienced analyst's head become something explicit and reusable, so the same judgment does not have to be rediscovered case by case. Routine behavior can be turned down while genuinely suspicious combinations stay loud, which means less time lost to false alarms and more attention on what actually warrants it. And the everyday work of triage stops being a cost that disappears into a backlog and starts becoming a feedback loop, each validated pattern making the next round of detection a little sharper. The result is a service that gets quieter where it should and louder where it must, and gets better at telling the two apart the longer it runs.
The specific profile is useful. The method behind it matters more. Every SOC sits on a history of analyst decisions that quietly encodes hard-won knowledge about attacker behavior, and almost none of it is written down. Treating that history as a source of insight, rather than only as a backlog, turns everyday triage into a feedback loop that sharpens detections and gives analysts time back.
The Vectra AI Difference
The mailbox rule profile described here is just one example of how Vectra AI continuously improves behavioral detection. Every detection is informed by ongoing security research, real-world attacker observations, and feedback from our MDR team. This combination of AI, behavioral analytics, and human expertise helps security teams spend less time investigating noise and more time responding to the threats that matter.
Learn how the Vectra AI Platform uses AI-driven behavioral detection to stop hybrid attacks across identities, cloud, SaaS, endpoints, and networks.
.jpeg)