An Attacker Got Valid M365 Credentials. Here’s What Happens Next.

No malware. No ransomware popup. Just a quiet login at 2am that changes everything.

Most people picture a cyberattack as something loud. A ransomware splash screen. A locked-out system. An obvious, dramatic breach that sets off alarms.

That’s not how most attacks start anymore.

What actually happens is quieter, slower, and far more dangerous because by the time something visible occurs, the attacker has already been inside for days, sometimes weeks. And they got in through the front door.

Let me walk you through what it actually looks like when an attacker gets hold of valid Microsoft 365 credentials. Not in theory. Not from a vendor slide deck. From the attacker’s perspective.

Step 1: The Login That Doesn’t Look Wrong

The attacker has a username and password. Maybe they phished it. Maybe they bought it from an initial access broker. Maybe they ran an adversary-in-the-middle attack and captured a session token, which means MFA didn’t even slow them down.

They log in.

Here’s the problem: from Microsoft’s perspective, this looks like a legitimate authentication event. The credentials are valid. If it’s a token replay, the session is already trusted. If the attacker is using a residential VPN, the IP address is geographically plausible.

No alarm fires. No alert triggers. The user’s mailbox opens.

The first thing most teams miss: the attacker is now inside an identity, not a device. Your EDR won’t see this. Your firewall didn’t block it. Your antivirus has nothing to scan. The perimeter was never breached the identity was.

Step 2: Quiet Reconnaissance

Attackers aren’t in a hurry. Once inside the mailbox, they read. They search. They learn.

They’re looking for patterns. Who approves invoices? Who handles wire transfers? Who communicates with the CEO? What does the internal language look like when someone authorises a payment?

They’ll search for keywords: “payment,” “invoice,” “bank details,” “transfer,” “PO number.” They’re mapping the financial workflows of the organisation from inside.

At this point, nothing has been altered. Nothing has been created. Nothing has been deleted. The attacker is simply reading email, and unless someone is actively monitoring for unusual mailbox access patterns, there’s zero indication of compromise.

Ask yourself: would your current security stack detect someone reading email from a slightly unusual IP address at an odd hour? For most organisations, the answer is no.

Step 3: Establishing Persistence

Now the attacker needs to make sure they don’t lose access. This is where it gets subtle.

They create inbox forwarding rules. Not obvious ones, rules that silently forward copies of specific emails to an external address. Emails containing “invoice” or “payment confirmation” get quietly copied out. The user never sees the rule. It doesn’t appear in their Outlook client unless they go looking for it.

Or they register an OAuth application with delegated permissions. This gives them persistent access to the mailbox and potentially SharePoint, OneDrive, and Teams even if the password gets changed. Token-based persistence survives a credential reset. Most IT teams don’t check OAuth consent grants as part of their incident response playbook.

Some attackers go further. They create a new global admin account in Entra ID. A quiet one, named something that blends in. If your environment doesn’t have monitoring on admin role assignments, this goes unnoticed. And now the attacker doesn’t just have access to one mailbox. They have the keys to the entire tenant.

Here’s the question that should keep you up at night: if a new global admin appeared in your M365 environment at 2am, who would know and what would happen next?

Step 4: The Business Email Compromise

With persistence established and financial workflows mapped, the attacker executes.

They might impersonate an executive and send an internal email requesting an urgent wire transfer to a “new vendor.” The language is perfect because they’ve spent days reading how the real executive communicates.

Or they intercept an existing conversation between the organisation and a supplier. They wait for an invoice to come through, then reply from the compromised mailbox with updated bank details. The supplier thinks they’re talking to their contact. The payment goes to the attacker’s account.

Or they use the compromised identity to send phishing emails to the organisation’s clients and partners, leveraging the trust of a legitimate email address to expand the attack.

None of this involves malware. None of it triggers an EDR alert. None of it looks like a “cyberattack” in the way most people imagine.

Step 5: The Discovery (Too Late)

The breach gets discovered days or weeks later. Maybe a supplier calls to ask why their invoice hasn’t been paid. Maybe someone notices an unfamiliar forwarding rule during a routine check. Maybe the bank flags a suspicious transfer.

By then, the attacker has extracted what they need. The blast radius the total impact across financial loss, data exposure, trust damage, and operational disruption is already fully expanded.

And here’s the part that makes this particularly painful: the forensic investigation often reveals that the initial compromise happened weeks before anyone noticed. The dwell time the gap between initial access and detection is where all the damage happens.

The Uncomfortable Truth

This entire attack chain exploits one fundamental gap: the space between prevention and detection.

The organisation in this scenario might have had a firewall, antivirus, email filtering, and even MFA. All prevention tools. All valuable. But prevention addresses the question of “can we stop them getting in?” It doesn’t address “what happens when they’re already inside?”

The locks were on the doors. But once someone got in through the window, there were no cameras and nobody was watching.

Identity has become the control plane of the modern business. Email, file storage, collaboration, admin access it all flows through M365 identities. When an attacker compromises an identity, they don’t need to deploy malware. They don’t need to move laterally across networks. They just use the tools and permissions that are already there.

This is what “living off the land” looks like in a cloud-first world.

The Shift That Matters

The question isn’t whether your prevention stack is good enough. It might be excellent. The question is: what’s your detection and response capability for identity-based attacks?

Can you detect an inbox forwarding rule created at an unusual hour? Can you spot a new OAuth consent grant? Can you identify a login from an anomalous location in the context of the user’s normal behaviour? Can you see a new global admin being created and respond before the attacker uses it?

And critically who owns that response at 2am on a Saturday?

If you can answer those questions clearly, you’re ahead of most. If you can’t, the scenario I just walked through isn’t theoretical. It’s the most common attack pattern targeting SMBs and mid-market businesses right now.

Prevention reduces noise. Detection reduces damage. Response reduces dwell time.

The organisations that understand this and build accordingly are the ones that turn a potential catastrophe into a contained incident.

What’s the biggest identity visibility gap in your environment right now?