706 attacks. Five months. Two mailboxes.

When the customer asked us to look at “some strange behavior” on a couple of accounts, we expected to find a successful phish that had been remediated weeks ago. What we found instead was a sustained Business Email Compromise campaign that had been operating against two specific user mailboxes for over five months.

706 individual attack events. Twelve different attacker IPs. Three countries. Twenty-eight days of undetected access before the customer noticed anything was wrong.

This is what that engagement looked like.

The setup

Two users at the customer organization. Both worked on the financial side — handling invoices, purchase orders, and quote documents. Their email accounts had access to the kind of correspondence that, if intercepted and quietly altered, would let an attacker insert themselves into payment flows.

That’s exactly what happened.

The campaign opened with what looked like routine sign-ins from a foreign country. Standard MFA was required by Conditional Access — but at some point, the attacker had captured credentials AND solved the MFA challenge (almost certainly via an adversary-in-the-middle phishing kit). From then on, the session cookie they captured was enough.

The persistence move

Day 4 of the campaign, around 14:00 customer-local time, an attacker IP created a new inbox rule on one of the compromised mailboxes. We’ve redacted the rule’s exact name and target from this writeup, but the pattern was textbook:

• Match incoming mail by subject containing “Invoice,” “Quote,” “PO,” “wire,” or similar payment-process terms
• Move the matching message to a low-traffic folder the user never opens
• Mark as read so the unread-count badge never changes

That’s the entire trick. The user kept seeing their normal inbox. The attacker received a silent copy of every financial conversation. For the next 28 days, nothing alerted the customer that anything was wrong, because nothing visible to the user changed.

What they did with the access

We mapped the activity into four buckets:

Document interception — The attacker watched financial threads land in the redirected folder, then quietly modified document attachments inside the mailbox. Invoices were edited. Quotes were edited. One specific high-value purchase order was modified and resent from the compromised mailbox to look like it originated normally.

Intelligence gathering — Calendar metadata was read. Meeting communications were modified. The attacker built up a picture of the customer’s vendor relationships, executive schedules, and active procurement cycles. This is what differentiates a casual scammer from a professional BEC operation: the patience to gather context before making a move.

Document theft — Beyond the payment-fraud track, the attacker pulled proprietary technical documents from the mailbox. We saw references to design files and specifications dating across multiple projects. Those documents now exist in someone else’s hands and we have no way to retrieve them.

Evidence destruction — Roughly three weeks in, the attacker began using HardDelete operations to wipe certain messages from the mailbox AND the recoverable-items dumpster. Standard SoftDelete leaves a recovery path. HardDelete does not. This is exactly the technique used to scrub the audit trail before the campaign moved to its next target.

The infrastructure

Twelve IP addresses across one /24 block in a major European city, plus a small secondary range in a second city, plus a single Canadian source IP used for what looked like external file-share operations.

Each IP played a specific role:

• One IP for new authentications
• One IP for document modifications
• One IP for the HardDelete cleanup operations
• Separate IPs for the persistence-establishment events vs. the routine read operations
• One IP that only showed up at quote/PO modifications

That’s not a hobby operation. That’s professionals who’d built role-separated tooling and used non-standard ports for proxy traversal. The same campaign almost certainly hit other targets we never saw.

Why it survived 28 days

Three things made this campaign invisible:

1. The customer’s existing SIEM had no alert on inbox-rule creation. That single event on Day 4 would have flagged the entire compromise if anyone had been looking at the directory audit log.

2. The inbox rule made the user’s experience indistinguishable from normal. No bounced mail. No missing notifications. No new unread items in the inbox. The compromise was deliberately designed to be invisible to the human at the keyboard.

3. MFA was on — but the AiTM kit had already captured a session cookie. Every subsequent sign-in looked legitimate to Conditional Access because it was carrying a valid claim that MFA had been satisfied (at the moment the kit relayed the real challenge through the proxy).

What ultimately surfaced it

A vendor receiving payment for a real invoice noticed that the bank routing information had changed on a modified invoice they’d received from the compromised mailbox. They called the customer to confirm. The customer’s AP team didn’t recognize the changed routing. That phone call started the investigation that eventually surfaced everything above.

In other words: a human spotted the fraud, not a system. By that point the attacker had been inside for 5+ months.

What you can check in your own tenant today

Three things, all free, all fast:

1. Search your directory audit log for “New-InboxRule” events. Any rule that forwards externally, deletes from internal senders, or moves financial-keyword threads to a low-traffic folder deserves immediate review.

2. Audit current inbox rules on every mailbox. Microsoft Graph: GET /users/{id}/mailFolders/inbox/messageRules for each user. Look for rules pointing to “RSS Feeds,” “Archive,” “Old Mail,” or any folder the user doesn’t actively read.

3. Cross-reference HardDelete operations against sign-in geography. If an account had HardDelete operations from an IP outside the user’s normal sign-in region during the same window, treat it as confirmed compromise until proven otherwise.

What you should require going forward

• MFA enforced on every account, every sign-in — including service accounts and shared mailboxes. Anything with accountEnabled=true and no isMfaRegistered is a finding.
• Phishing-resistant MFA on finance and admin accounts — FIDO2 or Windows Hello, not SMS. AiTM kits defeat phone-based MFA; they don’t defeat hardware-bound keys.
• Conditional Access with Sign-in Frequency and no persistent browser — kills stolen session cookies on a schedule.
• Out-of-band verification on all payment-detail changes — vendor calls a known phone number before changing routing info. Period.
• Inbox-rule-creation alerting — any new auto-forward, auto-delete, or auto-move rule should generate an alert that a human reads within 24 hours.

The attack that hides longest is the attack that changes nothing the user can see.

---

This case has been fully anonymized per our marketing policy. The 706 figure and the 28-day window are real; the customer name, vertical, geography, specific user identities, exact dates, and specific document names have all been generalized.

Run the free Envyously Risk Score → — surfaces inbox-rule creations, HardDelete operations, and sign-in geography anomalies across your tenant in about six minutes via OAuth.