Phishing in 2025: What Gets Past Training and Filters

Everything people were taught to look for in a phishing email — bad spelling, odd grammar, a generic greeting — has stopped being a reliable signal. The advice wasn't wrong, it just described an era that ended. Here's what these attacks look like now, and what actually stops them.

Why the old advice stopped working

Poor writing was never a feature of phishing; it was a symptom of attackers working in a second language. Language models removed that constraint entirely. Phishing emails are now fluent, correctly formatted, and written in whatever tone the situation calls for.

Worse, they're specific. Public information — your website, LinkedIn, press releases, your team page — is enough to write a message that references your actual manager, your actual project, and your actual vendor. Research that used to take an attacker an hour per target now takes seconds, so the personalization that used to be reserved for large companies is now applied to everyone.

The practical consequence: "does this look suspicious?" is no longer a usable test. Staff need process-based defenses, not vigilance-based ones.

The four attacks worth understanding

1. Adversary-in-the-middle (the MFA bypass)

This is the significant one, because it defeats the control most businesses rely on.

You click a link and reach what appears to be the Microsoft sign-in page. It appears that way because it is — the attacker's server sits in the middle, relaying your traffic to the real Microsoft in real time. You type your password: relayed. Microsoft sends your MFA prompt: you approve it, correctly, on a genuine request. You sign in successfully and land in your real mailbox, because you did in fact sign in.

What you didn't see is that the attacker captured the session cookie Microsoft issued. That cookie is what proves you're authenticated, and with it they access your mailbox without ever needing your password or another MFA prompt. Ready-made kits sell this as a service.

What stops it: phishing-resistant MFA — hardware security keys or passkeys — because those cryptographically verify the site's real identity and simply won't respond to a proxy. Conditional access policies that require a managed, compliant device also break it, since a stolen cookie replayed from an unknown machine gets rejected. App-based codes and push approval do not stop this attack.

2. Business email compromise

No malware, no links, nothing for a filter to detect. Someone impersonates your owner, a vendor, or your accountant, and asks for a payment or a change to bank details. Often they've already read months of your real email after an earlier compromise, so the request arrives with correct context, at a plausible moment, in the right tone.

The most damaging version is invoice fraud: a genuine vendor relationship, a genuine outstanding invoice, and an email saying the bank details have changed.

What stops it: a rule, not a judgment call. Any change to payment details, and any unusual payment request, gets verified by voice on a number you already had on file — never a number from the email. It must apply to the owner too, and staff must know they will never be criticized for making that call.

3. Attacks that don't arrive by email

Email security has improved, so attackers moved. Text messages about failed deliveries or bank alerts. LinkedIn messages from fake recruiters. Voice calls — increasingly with cloned audio, which needs only a short sample of someone speaking publicly. Malicious ads that put a fake download at the top of search results for common software.

A growing one worth naming: help desk impersonation. Someone calls your IT provider claiming to be an employee who's locked out, and talks their way into an MFA reset. Your identity verification process for resets is a security control — treat it as one.

4. MFA fatigue

With a valid password, the attacker simply triggers push notifications repeatedly — often in the middle of the night — until the user approves one to stop the noise.

What stops it: number matching, where the user must type a number displayed on the sign-in screen. There's nothing to blindly approve. If you're on Microsoft 365 and haven't enabled it, that's a five-minute fix.

What to actually do

Rethinking training

Training still matters, but its purpose has changed. You are not trying to make people perfect spotters — against a well-built modern attack, that's not achievable, and pretending otherwise sets staff up to feel stupid when they're caught by something designed by professionals to be uncatchable.

The realistic goal is fast reporting. Someone who clicks and says so within five minutes lets you reset a session and review sign-in logs while the incident is still small. Someone who hides it for two days gives an attacker two days inside your mailbox.

That means phishing simulations should measure reporting rate, not just click rate, and nobody should ever be publicly identified for failing one. A culture where clicking is embarrassing is a culture where clicks get concealed.

If someone has already clicked

1. Reset the password and, critically, revoke active sessions — a password reset alone leaves a stolen session cookie working.
2. Re-register MFA in case the attacker enrolled their own method.
3. Check for mailbox rules that auto-forward or auto-delete. Attackers create these immediately to hide replies.
4. Review sign-in logs for unfamiliar locations, and check whether any files were downloaded.
5. If any payment information was involved, contact your bank now rather than after investigating.

Decide all of this in advance rather than during the event — that's what an incident response plan is for.