The first hour of a business email compromise

It always looks like a normal email

Your finance lead opens a thread they have seen a dozen times. It is a real vendor, a real invoice, a reply in a conversation that has been running for weeks. The only new thing is a line about updated bank details for this payment. Nothing about it looks wrong, so the payment goes out. That is how most business email compromise (BEC) ends: not with an alarm, but with a wire that looked routine.

BEC is the quiet, expensive attack. The FBI's Internet Crime Complaint Center (IC3) logged roughly $3.05 billion in reported BEC losses across about 24,768 complaints in 2025, making it one of the largest single loss categories the bureau tracks, behind only investment fraud. Pull the lens back and it is around $8.5 billion lost to BEC across 2022 through 2024. The average reported complaint runs to roughly $123,000. It rarely makes the news, because the damage is a transfer, not an outage.

This post walks the first hour of one of these attacks, in order, the way it actually plays out. How the attacker gets in past multi-factor authentication, how fast they hide, why the obvious fix does not work, and what decides whether you lose six figures or nothing. The short version: the outcome is set in the first hour, and it turns on whether someone is watching and allowed to act before the money clears.

It doesn't start with malware. It starts with a login

There is no virus to catch here, and that trips people up. Most account takeovers behind BEC start with a login on a page that looks exactly like your real sign-in.

The technique is called adversary-in-the-middle, or AiTM. The attacker stands up a reverse proxy that sits between the employee and the real Microsoft or Google login. The employee types their password into what looks like the real page. They get the multi-factor prompt, because it is the real page underneath, and they approve it. The attacker quietly captures the password and, more importantly, the session cookie the login produces. That cookie is proof of an already-authenticated session, so the attacker pastes it into their own browser and walks straight in. The multi-factor check happened, and it was satisfied. It just protected the wrong session.

This is not a rare, hand-crafted attack. Phishing-as-a-service kits sell AiTM as a turnkey product and run it at scale: Microsoft has tracked kits sending tens of millions of messages to hundreds of thousands of organizations a month, with one kit accounting for a majority of the AiTM phishing it blocked by mid-2025. And because it rides a session that was already authenticated, it works against accounts that had multi-factor authentication on. Proofpoint, monitoring about 63 million accounts in 2024, found that 99% of those organizations were targeted for account takeover and 62% had at least one succeed. Its own conclusion is blunt: MFA "is a good practice, but it is not an account takeover defense silver bullet."

The first few minutes: the attacker settles in and hides

Once they are in, attackers move fast, and the first thing they do is make sure you will not notice.

Hiding the evidence starts almost immediately. Malicious inbox rules can be created within seconds of takeover, and in one quarter of 2025 roughly one in ten compromised accounts had such rules set up shortly after access. The rules tend to carry junk names like a single dot or a semicolon, and they quietly move incoming mail to a folder nobody checks (Archive, Conversation History, RSS Subscriptions) or delete it outright. In one documented Microsoft case the attacker routed all incoming mail to Archive, marked it read, and deleted any message from a recipient who questioned whether the payment request was real. The legitimate owner's inbox looks normal the whole time.

Then they dig in to stay. Within about ten minutes of compromise in the same research, attackers registered a new device to mint a refresh token, giving them a durable way back in even if the original session is closed. Somewhere in here they also read the mailbox, find a live invoice or payment thread, and prepare the "updated" banking details that will go out under the employee's name.

The thing to absorb is the order of events. By the time anything looks off to a human, the attacker has usually been inside for a while, the persistence is in place, and the thread that would tip you off has already been hidden by a rule.

What you can't see, the system can

A person scanning their inbox will not catch any of this. The platform underneath it, though, is generating signals in hour one, if someone is set up to watch them.

In Microsoft 365, the tells include an impossible-travel sign-in, where one account signs in from two far-apart places in less time than the trip would take, surfaced by Entra ID Protection. A junk-named inbox rule that moves mail to Archive or suppresses notifications is a high-fidelity early-compromise signal in Defender. So is a suspicious third-party app consent grant, where the attacker tricks the account into approving an app that keeps reading mail.

Google Workspace has its own version of all this. The login audit log flags suspicious sign-ins and retains six months of events, the alert center raises admin alerts for suspicious login activity, and the security investigation tool lets an admin pull the thread on what an account actually did.

Both platforms can see the attack as it happens. The catch is that seeing is not stopping. An alert fires into a console or an inbox, and then everything depends on whether a person notices it and is allowed to do something about it. That gap, between the signal existing and someone acting on it, is where most of these go wrong.

Why resetting the password doesn't end it

The universal first instinct, the moment an account looks compromised, is to reset the password and move on. It feels like the fix. It is not, and this is the part most advice gets wrong.

A password change, on its own, does not invalidate a session the attacker already stole. In Microsoft 365 the access token they are riding lasts about an hour, and as long as the refresh token behind it is still valid, it keeps minting fresh access tokens. Microsoft's own guidance on revoking access is explicit that a password reset alone does not invalidate existing sessions; you have to revoke them directly, and its AiTM and BEC response guidance says plainly that a password reset is not an effective standalone fix, because you also have to revoke the active session cookies and delete the attacker's inbox rules.

Google Workspace works the same way. Resetting a user's password does not by itself sign them out of active sessions; an admin has to reset the sign-in cookies as well. Suspending the user is what resets those cookies and OAuth tokens, and even then it can take up to an hour for current Gmail sessions to end. OAuth tokens auto-revoke on a password change, but app-specific passwords have to be revoked by hand.

And here is the part that bites quietly even after a careful reset: the malicious inbox rules survive it. A new password does nothing to a rule. It keeps archiving, deleting, and hiding mail until a human finds it and removes it, which means the fraud can keep playing out in an account everyone believes is now clean.

The hour that decides the money

All of this is a race against one event: the wire clearing. Up to that point you can still win. After it, recovery gets hard fast.

The FBI runs a Recovery Asset Team that coordinates with banks to freeze fraudulent transfers, and its repeated message is that "time is of the essence." The numbers back that up. Reported quickly, the team held funds on about 66% of domestic complaints in 2024. The odds drop the longer the money sits in motion. So hour one is not just about the inbox. It is detect, contain, and warn finance and the bank before the transfer goes through.

If you stop the attack inside that hour (sessions revoked, rules deleted, account locked, finance warned), the most likely outcome is no loss at all. Miss it, and you are into a clawback that may or may not land. The whole game sits in a narrow window, which is exactly why detection without the authority to act in that window is not much use.

What "response" has to mean

This is where a lot of well-defended companies quietly come up short. They have multi-factor authentication on, a clean compliance posture, and a tool generating alerts. What they do not have is someone watching those alerts at the moment one fires and the standing authority to act on it. Monitoring without the authority to act is, in practice, a notification service. It tells you the building is on fire and then waits for you to call someone.

Real response means the access and the go-ahead are arranged before anything goes wrong. So when an account is taken over at 2am, the people watching can revoke the stolen sessions, delete the inbox rules, and lock the account in the first hour, across your email and identity provider, whether that is Microsoft 365 or Google Workspace. Then they tell you what they did and why. That is the difference between someone defending the company and someone describing what is happening to it.

There is also a layer that runs before any of this. A lot of these attacks never get their first hour because the prevention controls were on: impersonation protection, anti-phishing, blocked auto-forwarding, the audit log. We wrote about those in the Microsoft 365 settings most growing companies never turn on. Turning them on closes the easy doors. Watching what they generate, and acting fast when one fires, is what catches the attack that still gets through.

Keeping the Microsoft 365 or Google Workspace baseline hardened, and watching it afterward, is the work our Collaboration Security and Managed Detection and Response teams do together. The hardening keeps the easy attempts out. The watching, with the authority to contain, is what handles hour one.