The Attack That Does Not Trip Any Alarms

A firm loses about $400,000 to a wire fraud and the forensic report contains no malware. This is not unusual. It is close to the standard shape of the incidents that actually damage professional services firms, and almost nothing sold as cybersecurity is designed to catch it.

Here is the sequence. Someone clicks a link to what looks exactly like their normal sign-in page. They enter the password. The system asks for the second factor, as it always does, and they approve it. Everything behaves correctly, because it is the real sign-in page — relayed through a server the attacker controls. The login genuinely succeeds. The attacker keeps the session cookie issued at the end of it.

From that point they do not need the password or the second factor again. They replay the cookie and they are inside a session the identity provider considers fully authenticated — because it is. They read email for eleven days, create one inbox rule that moves any message mentioning a wire transfer into a folder nobody opens, then reply inside a real thread and change the account numbers.

The question worth sitting with

Which of your security tools would have said anything?

Antivirus looks for known-bad files. There were none. It would have stayed silent for eleven days and been working perfectly the entire time.

Endpoint detection and response — EDR — is the better answer, and it is the tier that most cyber insurance questionnaires now ask about. It watches the endpoint for unfamiliar behavior. But in this incident the endpoint behaved normally throughout, because the attacker never touched it. They were in a browser session, logged in as a legitimate user. EDR would also have stayed silent, and would also have been working perfectly.

This is the part that gets missed. The tool named on your insurance form is a level behind the attack pattern that is actually taking money out of firms like yours. It is not that EDR is bad. It is that it is pointed at the wrong layer.

But we have MFA

This is the right objection, and it is usually where the conversation stops. It should not.

Multi-factor authentication genuinely killed the simple version of this attack. Nobody gets far on a reused password alone any more, and any firm still relying on passwords by themselves has a more urgent problem than this article. What replaced it is a technique that treats your MFA as part of the process rather than an obstacle to it.

Relaying the login page is the common one, and it is the sequence described above. The user is not careless. They did everything they were trained to do, on a page that behaved exactly as it should, and the second factor worked correctly. It simply worked for somebody else as well.

The variations are cheaper than they sound. Push notifications repeated at two in the morning until somebody approves one to make it stop. A phone number ported to a new SIM so the text arrives elsewhere. A session token lifted off a personal laptop by commodity malware that never touches your network at all.

None of it trips anything, for the same reason as before. No malware on the endpoint. A valid session. A credential that was correct at the moment it was used. MFA was satisfied — just not by the person you think.

What changes the outcome is MFA that cannot be relayed. Passkeys and hardware security keys are bound to the real domain, so a proxy sitting in the middle has nothing it can pass along. Short of that, it is access policy that cares about the device as well as the identity, and detection that notices a session appearing somewhere the account has never been.

Where the attack was visible

The incident above left a trail, just not on any single system. A sign-in from an unfamiliar location. A session that did not match the account’s usual hours. A new inbox rule created within minutes of that sign-in. Eleven days of mail access with no corresponding calendar activity, no document edits, none of the ordinary noise that account generates every week.

Individually each of those is unremarkable. People travel. People make inbox rules. Any one of them, in isolation, would be a false positive that a busy team learns to click past.

Together they are a sentence that no longer parses.

That correlation — across identity, email, endpoint and cloud, treated as one picture rather than four dashboards — is what extended detection and response does, and it is the only layer at which this particular attack is visible at all. The acronym is XDR, and the acronym is the least interesting thing about it.

Why firms end up here

Almost nobody chooses to be underprotected. They answer a questionnaire.

The insurance renewal asks whether the firm has EDR. The firm asks its IT provider. The provider says yes. The box gets ticked, the policy renews, and everyone reasonably concludes the matter is handled. The questionnaire was never a security assessment — it was an underwriting instrument, written to be answerable at scale, and it lags the threat by design.

Meanwhile the attacker has no interest in your endpoints. They want a mailbox, because a mailbox contains the context needed to write a convincing email about money that is already moving.

The three questions to ask

If you take nothing else from this, take these. Ask your current provider, and notice how long the answer takes.

1. What did your security operations center see at 2am last Tuesday? A provider running genuine monitoring can tell you. A provider running an alerting tool will describe the tool.

2. If one of our accounts was signed into right now from an unfamiliar location, how would anyone find out — and how long would that take? The honest answer at a lot of firms is "when someone notices something odd", which is not detection.

3. Who is watching outside business hours, and are they employed or automated? Attacks are timed for when nobody is looking. That is not a coincidence, it is the plan.

None of those questions require technical knowledge to ask, and all of them are difficult to answer vaguely. That is precisely why they are worth asking.

The uncomfortable conclusion

A firm can hold a current cyber insurance policy, satisfy every question on the renewal form, run reputable security software on every machine, and still be blind to the attack most likely to hit it.

That gap is not caused by negligence. It is caused by measuring security against a questionnaire instead of against an adversary. The questionnaire is a floor. Most firms have quietly turned it into a ceiling.