Anatomy of a Long-Dwell Business Email Compromise

EXEC Executive Summary

In early August 2026, an employee at a mid-size engineering consultancy ("Solandra Engineering Group," a pseudonym) discovered a reply in his own Sent Items folder that he had never written. What followed was a forensic reconstruction, led by Null Vector Lab's incident response team, that ultimately traced a single attacker session back fifteen weeks. The trail ran through three separate fraudulent vendor payment threads, a second compromised mailbox, and infrastructure spanning at least four commercial hosting and proxy providers, all without ever triggering a single multi-factor authentication prompt.

This paper documents the investigative methodology used to establish that timeline, the false leads that were pursued and correctly ruled out along the way, and the structural gaps in licensing, logging, and Conditional Access posture that allowed a stolen session token to persist undetected for over three months.

01 Background

Solandra Engineering Group is a small consultancy coordinating multi-site infrastructure and industrial projects. It runs on Microsoft 365 with default security settings: Security Defaults, no Conditional Access, and no Defender for Endpoint deployment. Like many organizations its size, its security posture relied on baseline platform defaults rather than a dedicated identity or endpoint security program.

02 Detection

The incident surfaced through simple human suspicion rather than any automated alert. A senior employee noticed a "Re: Payment" reply to an equipment vendor sitting in his own Sent Items that he had no memory of writing. He forwarded it to his organization's security contact, and Null Vector Lab's forensics team was engaged shortly after to determine scope and root cause.

No security tooling flagged anything during the entire fifteen week window. This was a detection failure by omission. The compromise was invisible to the platform's default controls, not merely missed by them.

03 Investigative Methodology

Null Vector Lab's team reconstructed the incident from three primary sources: mail flow message trace data, Microsoft Entra ID sign-in logs, and rolling Exchange mailbox audit exports pulled in successively wider windows as the investigation progressed. The approach and its course corrections are documented below, including one lead that was pursued and then deliberately retracted once independent verification disproved it.

3.1 Anchoring on the Message, Not the Mailbox

The first reliable fact in any BEC investigation is the fraudulent artifact itself. A message trace on the disputed email yielded its true submitting client IP, distinct from the Microsoft datacenter IPs that normally appear in transport headers. This single IP became the starting anchor for everything that followed.

3.2 From IP to Session

Cross referencing that IP against Microsoft Entra ID sign-in logs surfaced an interactive sign-in three minutes before the fraudulent message was submitted, from the same address. Critically, that sign-in's authentication detail showed no password or MFA challenge. Every factor was marked "Previously satisfied," meaning a pre-existing session token was being reused rather than a fresh login occurring.

This produced the investigation's true anchor: not an IP address, but a session identifier. Every subsequent finding in this case was validated against whether it shared that exact session ID, a materially stronger standard than IP matching alone.

3.3 Why IP Attribution Alone Is Insufficient

An early pass at this investigation built a list of "known attacker IPs" by observing which addresses shared the compromised session, then searched historical logs for any appearance of those same addresses. This is a common but fragile approach. Commercial proxy and hosting providers reassign and reuse IP space across unrelated customers, so a given address appearing in an earlier time window does not, by itself, prove the same actor was responsible.

The methodology was corrected mid-investigation. Rather than searching for IP membership in a list, every historical record was re-verified against the literal session identifier itself, and only hits carrying that exact session ID were retained as confirmed. This distinction, session correlation over IP correlation, is the single most important methodological point in this case study and is offered here as a general lesson for similar investigations.

3.4 Pursuing and Correctly Discarding a False Root Cause

Directory audit logs surfaced an OAuth consent event nine days into the visible attack window, granting a delegated scope consistent with persistent mailbox access. This initially appeared to be the root cause and was reported as such.

Independent verification, checking the consenting application's ID against known first-party application identifiers, revealed it to be a legitimate, ubiquitous platform integration (the standard mobile-device mail-sync connector), not an attacker-controlled application. This finding was retracted once verified, and the true compromise was subsequently shown, via strict session-ID matching, to predate that event by over a week.

This sequence is included deliberately. A credible forensic process has to be willing to propose, test, and discard its own conclusions when the evidence doesn't hold up under stricter scrutiny.

3.5 Bounding the Window

With session-ID correlation established as the standard, historical audit exports were pulled in successively earlier windows: July, then May through June, then March through April, then January through February, until the session identifier stopped appearing entirely. This produced a defensible, evidence-bounded compromise window rather than an assumed one. First confirmed activity was April 21. Zero activity appeared in January or February, which confirmed the outer bound.

04 Attack Timeline

05 Findings Summary

• Compromise duration: at least 15 weeks (April 21 to August 2), one continuous session token, never re-authenticated.
• Infrastructure: at least 41 distinct IP addresses across commercial hosting and proxy providers, concentrated in one company operating under two separate autonomous system numbers.
• Fraudulent activity: at least three separate vendor payment threads targeted across the window, plus reconnaissance-only access for the first several weeks before any action was taken.
• Lateral access: the stolen session was also used to access a second employee's mailbox through delegated permissions, exposing confidential project and contract documents.
• Persistence mechanism: multiple mail-filtering rules created and refined over the campaign, each configured to quietly redirect legitimate vendor replies away from the account owner's visible inbox.
• Root cause: not conclusively determined. A plausible false lead was identified, tested, and ruled out. Log retention limits (native 30-day sign-in log retention) prevented full reconstruction of the original access event.

06 Indicators of Compromise

07 MITRE ATT&CK Mapping

Null Vector Lab maps observed behavior to ATT&CK to support detection engineering and cross-team communication. The mapping below reflects confirmed technical evidence only; initial access is intentionally left unmapped since the precise mechanism was not conclusively determined.

08 Remediation Actions

Working alongside the client's internal IT lead, Null Vector Lab's team executed the following containment steps:

1. Full session and refresh token revocation on the affected account.
2. Removal of all attacker-created mail rules.
3. Independent verification of the secondary, delegate-accessed mailbox.
4. Out-of-band phone verification with all affected external vendors to confirm no payment or banking details were altered.
5. Organization-wide sweep for the same infrastructure signature across other accounts.

09 Recommendations

For organizations running on baseline Microsoft 365 security defaults, this case illustrates several concrete gaps worth closing proactively.

Conditional Access with sign-in frequency and Token Protection. This directly closes the exact replay mechanism observed here. Security Defaults alone does not support either control.

Device compliance requirements. None of the attacker sessions originated from a managed or compliant device. This alone would likely have blocked the entire campaign.

Restricted user consent for third-party applications. This reduces the risk of the illicit-consent-grant pattern generally, even though it was not the mechanism confirmed in this case.

Extended audit and sign-in log retention. This investigation was materially limited by native retention windows. A SIEM or an exported log pipeline would have allowed direct reconstruction rather than inference.

Endpoint detection coverage. No endpoint telemetry existed for the affected user, which closed off an entire investigative avenue.

Out-of-band verification as standard practice. Apply this to any payment or banking instruction change, regardless of how legitimate the request appears in-thread.

10 Conclusion

This case is a reminder that the most damaging compromises are often the quietest ones. No malware, no obviously malicious email, no failed login attempts to alert a SOC. A single persistent session, replayed patiently across rented infrastructure, was enough to sit inside a mailbox for over three months, harvest sensitive correspondence, and run concurrent fraud attempts against multiple business relationships, all without a single fresh password or MFA prompt.

The defenses that would have stopped it are neither exotic nor expensive relative to the exposure. Session binding, device compliance, and sign-in frequency policies close this specific attack path directly. The harder lesson is procedural: forensic conclusions should be built on the strongest available correlation, which in this case was session identity, tested against alternative explanations, and revised without hesitation when the evidence demands it.