Investigating BEC at two speeds

What happened?

BEC can be tricky precisely because much of the underlying activity looks so ordinary. Once an attacker is operating through a legitimate cloud identity or authenticated session, they can use functionality that Microsoft 365 provides to every normal user. Understanding the incident therefore depends heavily on the surrounding behaviour as context. One event rarely tells the whole story, and both of these cases became much clearer once we stopped looking at the individual actions in isolation.

The first BEC case: access followed quickly by abuse

In the first investigation, suspicious access was followed shortly afterwards by malicious mailbox activity. The compromised user had permission to send emails as a trusted shared mailbox associated with a sensitive business function. That existing SendAs permission gave the attacker an immediately useful identity to operate through, without requiring administrative privileges or any special mailbox configuration of their own.

Audit records showed messages being sent through the shared mailbox. Sent messages and incoming responses were subsequently deleted, which made the wider sequence particularly interesting from an investigative perspective. The attacker was using the trust attached to an existing business function and then removing some of the activity that could have alerted the legitimate user.

The authentication side of the investigation required a little more care. We saw a mixture of successful and failed access attempts. Some requests encountered MFA requirements, whereas other application access succeeded without a new MFA challenge being visible in the telemetry available to us. One possible explanation was the use of an existing authenticated session. Session theft was therefore something we considered during the investigation, although we did not have enough evidence to establish that this was the initial-access method.

That uncertainty is important. Seeing successful access without a fresh MFA prompt does not automatically mean that an attacker bypassed MFA. The request may have relied on a previously satisfied authentication claim or an existing session. Conditional Access decisions can also differ between requests. To understand what happened, we therefore had to examine the authentication at request and session level rather than treating "MFA enabled" as an answer in itself.

The second BEC case: a much longer gap

The second investigation took a different shape. We first had confirmed malicious mailbox activity: access from unfamiliar infrastructure was followed by the creation of an inbox rule and phishing emails being sent through the compromised account. From there, we worked backwards through the identity history.

That retrospective review surfaced another suspicious login approximately seven days earlier. At the time it occurred, the event was difficult to interpret with confidence. It came from unfamiliar infrastructure, but unfamiliar infrastructure is hardly rare enough to prove that an account is compromised. People travel, networks change and consumer VPNs do their best to make identity telemetry more colourful than analysts would sometimes prefer.

There was another reason to be careful. The IP address from the earlier login differed from the infrastructure involved in the confirmed mailbox abuse. We therefore could not say that the login seven days earlier represented the start of the same attack. Still, once we knew that the account had subsequently been compromised, that authentication event deserved another look. It gave us a useful investigative lead and, more importantly for detection engineering, raised a question about how we correlate this kind of behaviour in the first place. If the earlier login was related, would a detection looking for suspicious authentication followed by mailbox abuse within 24 hours ever have connected the two events? It would not.

And that is where putting these two investigations next to each other becomes useful. The first shows what happens when the attacker moves from access to abuse quickly. The second shows what can happen when potentially relevant activity sits much further back in the identity history. In one case, the pressure is on detection and response speed. In the other, it is on how long we retain context and when we decide to revisit it.

The attack objective can be very similar. The timeline does not have to be.

Technical aside: ATT&CK mapping

From an ATT&CK perspective, the investigations touched several techniques associated with cloud identity abuse and mailbox manipulation. Some behaviours were directly observed, while others remained hypotheses that we considered while reconstructing the incidents (particularly around the possible use or theft of authenticated sessions).

The ATT&CK mapping helps us describe the actions we observed and the techniques we considered. What it cannot tell us is how much time an attacker will leave between them, and that became one of the most useful lessons from these investigations.

Reconstructing the incidents

For our analysts, both investigations required more than reviewing the event that initially looked suspicious. We combined authentication records with Microsoft 365 audit activity and then used email events to reconstruct what had happened around the affected identities.

In the first case, that meant tracing the activity into the trusted shared mailbox and understanding how the existing delegated permissions had been abused. It also meant digging into the mixed authentication results instead of concluding that MFA had simply "failed". Looking at the individual requests allowed us to assess the possibility of session-based abuse without claiming more certainty than the telemetry supported. We also investigated the potential scope beyond the mailbox. In the telemetry available to us, we found no evidence of SharePoint or OneDrive access. That reduced the assessed likelihood of wider data theft, although there is an important difference between saying that no such access was observed and saying that none occurred. Audit coverage always places limits on what can be established afterwards, so that distinction remains important when communicating findings.

Containment included resetting the affected password and revoking active sessions. Those actions address different parts of account compromise. Changing the credential protects future authentication with that password, whereas revocation is intended to terminate access that has already been established. Where existing sessions may be involved, treating the password reset as the entire containment step can leave part of the problem unresolved.

The second case demonstrates another part of the process particularly well. Once we had high-confidence malicious mailbox behaviour, we used that confirmed activity as a reason to revisit the identity's earlier authentication history. That is how the suspicious login from approximately seven days earlier became relevant to the investigation. At the time of the login, the available evidence was insufficient to establish malicious intent. The later mailbox abuse gave us more context to assess it, even though we could not confirm a connection between the two events. For detection engineering, this raised an important question about how far back our detections should look when stronger evidence of compromise emerges.

When the correlation window becomes part of the problem

A lot of detection logic relies on fixed periods of time. Imagine, for example, that we look for suspicious authentication followed by inbox-rule creation within 24 hours. That can be a useful BEC detection because the combination of those events is much stronger than either one on its own. The 24-hour window also contains an assumption about how the attacker is going to behave. It assumes that the authentication event and the mailbox activity we care about will happen within the same day. The second investigation gave us a good reason to question that assumption. If the login from seven days earlier was part of the same intrusion, a 24-hour rule would never connect it to the later mailbox activity. All the relevant telemetry could be available and the relationship between those events could still remain invisible to that particular detection.

Extending every correlation window to a week or two is tempting, but that introduces another problem. Identity environments are noisy over longer periods. Users appear from new networks and different devices. Mobile connections change frequently, and VPN infrastructure can produce plenty of unfamiliar IP addresses without an attacker being anywhere near the account. The wider the window becomes, the more unrelated activity gets pulled into the same analysis.

Rather than continuously correlating weak identity signals across increasingly large windows, stronger evidence can trigger a retrospective search through earlier activity. This gives us two complementary approaches to correlation:

• Forward correlation: A suspicious event occurs, and we watch for related behaviour within a deliberately chosen period.
• Retrospective correlation: High-confidence malicious behaviour is identified, prompting us to look back at earlier activity to determine whether weaker signals now carry additional meaning.

Shorter correlation windows remain useful for catching fast transitions into mailbox abuse. Retrospective correlation can help uncover activity associated with slower intrusions without assigning high severity to every unfamiliar login from the previous two weeks. This is one reason detection capability cannot be assessed solely by counting rules or measuring alert speed. It also depends on whether sufficient historical context remains available to reconstruct and reassess earilier activity when later evidence changes its meaning. After all, the value of telemetry is not necessarily fixed at the moment it is generated. An authentication event that initially seemed unremarkable may become significant once subsequent mailbox abuse is confirmed.

This also has implications for how we improve our detections. By examining which signals were useful immediately and which only gained significance later, we can make better decisions about our correlation logic. That includes determining how much historical telemetry needs to remain available and which high-confidence events should trigger a retrospective search. Findings from investigations can then inform detection rules and investigation workflows, giving analysts a better starting point when similar behaviour appears again.

The lesson is that effective detection engineering depends on recognising suspicious behaviour when it happens, but also on retaining enough context to understand what earlier activity means in light of new evidence.

What defenders should take from this

These investigations show why identity detections need enough context to handle attack chains that develop at different speeds.

Final thoughts

What made these cases interesting was not that BEC looked radically different in each one. In many ways, the later mailbox abuse was familiar. Legitimate identities were compromised and ordinary Microsoft 365 functionality became useful to an attacker. The interesting part was how differently the activity developed over time.

The first investigation showed why speed matters. Once suspicious access is followed quickly by mailbox abuse, analysts need to connect the behaviour early enough for containment to make a difference. The second case showed the other side of the problem. Potentially relevant activity may have happened days before the account does something that finally makes the compromise obvious, which means earlier telemetry needs to remain available for investigation. There will always be a trade-off in how we approach this. Correlate too narrowly and slower attack chains may fall outside the detection window. Look too broadly and analysts spend their time untangling unrelated user activity. Real incidents help us understand where that balance lies and how our detection logic can be improved.

In these two cases, the biggest lesson was that the clock itself was part of the detection problem. Good BEC detection therefore requires enough historical context to revisit earlier activity when new evidence emerges. More broadly, detection does not always happen in chronological order: a weak signal may become meaningful only after stronger evidence appears days later. Mature detection engineering therefore needs to work in both directions: forward, to catch attackers quickly, and backward, to reinterpret earlier activity when new evidence changes the picture. Because understanding how an attack unfolds also means understanding when its signals become meaningful.