From the Field: When a Scary Alert Turns Out to Be Nothing

Not every alert that looks like a compromise is a compromise. A mailbox rule alert came in that had all the markings of a business email compromise, and the actual work was resisting the urge to treat it like one before the evidence said so.

Here’s what happened and why “case closed” was the right call.

The Ticket

A client forwarded an alert from Microsoft Purview. Their internal IT team had received it but couldn’t view the details, likely a permissions issue on their end. So the ticket landed with me to investigate.

I logged in and pulled up the alert. A mailbox rule had been created on a user’s mailbox. The rule targeted email from one specific internal sender and bounced it back, so messages from that one coworker never landed in the inbox where the rule lived.

That’s a strange rule. And mailbox rules are a classic indicator of business email compromise. When an attacker takes over a mailbox, one of the first things they often do is create rules to hide their activity, auto-forward mail externally, or quietly delete security notifications. So the instinct is to treat this as an incident until proven otherwise.

Reading What the Evidence Actually Said

Here’s where it gets interesting. The rule didn’t fit the threat actor pattern.

If this were an attacker, why build a rule that hides mail from exactly one internal coworker? Compromised mailboxes usually get rules that serve the attacker: forwarding to an external address, deleting anything containing words like “invoice” or “password reset,” that kind of thing. A rule scoped to bounce one specific colleague’s email reads a lot more like interpersonal drama than data theft.

The evidence backed that up:

• Purview attributed the rule creation to the user themselves.
• Our EDR showed no unusual logins on the account.
• Email monitoring flagged no excessive outbound mail, which is what we typically see when someone falls for a phish, and their credentials get used.

Everything pointed to the legitimate user creating this rule. We still don’t know why, and since we don’t interact with end users for this client, we didn’t need to. The “why” wasn’t ours to solve; the “is this a compromise?” was, and the answer was no.

Removing the Rule

The internal team asked me to remove it, so I installed the Exchange Online PowerShell module and pulled the rules on the mailbox:

Get-InboxRule -Mailbox "user@domain.com" -IncludeHidden

The -IncludeHidden flag matters here. Attackers frequently create hidden inbox rules specifically so they won't show up in a normal review. Even though Purview had already attributed this to the user, I wanted to confirm there was nothing lurking that the alert hadn't surfaced. Running the investigation properly doesn't stop just because the first answer looks benign.

I found two rules matching that internal sender. I removed both:

Remove-InboxRule -Mailbox "user@domain.com" -Identity "RuleNameHere"

There were other rules on the mailbox, spam filters, and the like, that were clearly legitimate and stayed untouched. Two rules in, two rules out, nothing hidden. Done.

The Takeaway

The skill here wasn’t technical. Installing a PowerShell module and removing an inbox rule is trivial. The skill was reading an alert that looked like BEC and not forcing it into that box when the details didn’t line up.

A good analyst lets the evidence drive the conclusion. The alert type raises the question. The behavior, the login data, the outbound mail patterns, and the attribution: those answer it. Pattern matching on “mailbox rule equals compromise” would have turned a five-minute fix into a manufactured incident.

Sometimes, case closed really is case closed.

What’s the most benign explanation you’ve talked yourself out of too quickly on an alert that looked worse than it was?