Every Phishing Marker You Trained People On Is Gone

The training slide has been the same for a decade: look for poor grammar, look for "Dear Customer", and hover over the link to check where it really goes. Those were reasonable heuristics because they described what mass phishing actually looked like.

What they really described was cost. Bad English meant an attacker working at volume in a second language. A generic greeting meant one template sent to a hundred thousand addresses. A suspicious link meant infrastructure the attacker had to host somewhere. Every marker was a symptom of doing this cheaply at scale.

That cost collapsed and the markers went with it, so the training that teaches them now produces confidence rather than caution.

The problem

Consider the message a security lead might receive today. It is in fluent English. It refers to the ISO 27001 surveillance audit scheduled for next month, because that is public in a certification directory. It matches the sender's usual register, because the sender writes publicly and there is enough text to imitate. It contains no attachment and no link. It asks a plausible question about which entity to invoice.

There is nothing to hover over and nothing to detonate in a sandbox. The domain is a week old and otherwise clean. Every marker in the training deck is absent, and the request itself is the attack.

The person receiving it did not fail training. They passed it, and the training was measuring the wrong thing.

Why it's different with AI

The economics inverted, and the FBI's Internet Crime Complaint Center captured it in a single pair of numbers. In 2025, phishing and spoofing complaints fell from 193,407 to 191,561, about one percent. Reported losses in that category rose from $70,013,036 to $215,843,126, an increase of 208 percent [1]. So there were fewer reports and roughly three times the money.

That divergence is what a shift from volume to precision looks like. One campaign aimed at a million people became a thousand campaigns aimed at a thousand people each, and the per-target quality that used to be reserved for high-value fraud became affordable everywhere. Business email compromise in the same report accounted for $3,046,598,558 across 24,768 complaints, an average near $123,000 per incident [1].

Three specific things changed for the defender.

Language stopped being evidence. Fluency was never a security property. It was a proxy for attacker effort, and the proxy broke.

Context became cheap. Assembling a profile from a conference programme, a certification registry, and a public post used to take an hour of an operator's time, so it was reserved for large targets. It is now a step in a pipeline.

The payload became optional. If the goal is a bank detail change or an approval, no malware is needed. The technical controls that scan attachments and reputation-check URLs still work as well as they did; they are simply not in the path.

A fourth change gets less attention because it has nothing to do with the message itself. Reply handling used to be a bottleneck: a convincing first email is worth little if the attacker cannot sustain the conversation that follows, in the right register, at the right hour, about details they do not know. That constraint is largely gone. A thread can now run for days without the attacker being fluent, awake, or familiar with your invoicing process. Advice built on the idea that engaging with a suspicious sender will expose them has stopped being true without anyone announcing it.

What actually works

Stop asking people to judge the writing, and start with controls that hold regardless of it.

Verify the request instead of the message. Set a fixed rule: any request to change payment details, move funds, or supply a credential is verified through a channel established beforehand, using a number already on file and never the number in the message. The rule works whether the request arrives as flawless prose or as obvious nonsense, and that is why it holds up.

Make the credential worthless. Phishing-resistant authentication removes the value of a stolen password. This is deterministic and it does not degrade as the attacker's writing improves.

Train on the ask. Replace the markers with a short list of requests that always trigger verification. That list is stable and teachable, and it does not need updating each time the attacker's tooling improves.

Fuse signals the reader cannot see: domain age, whether you have corresponded with this address before, whether authentication records align, and whether the writing deviates from that sender's history. These are for systems to evaluate. Deploy them first where a false positive is cheap, on user-reported messages and then post-delivery, before anything blocks inline.

The ordering of that last one has real operational consequences. Scoring inbound mail with a model has a false-positive cost measured in blocked legitimate business, so it has to earn its way in instead of arriving switched on. Start where a mistake costs nothing: messages users have already reported, where the model is triaging a queue rather than making a delivery decision. Move next to post-delivery action, where a message can be pulled back after the fact and the damage of a wrong call is an apology rather than a lost order. Only after you have measured the false-positive rate against real traffic does anything block inline.

The same ordering applies across the list, with deterministic controls first and probabilistic detection last. A model that scores intent is worth having, and it is also the layer that degrades without warning as the attacker gets better, which is why it belongs behind the controls that do not.

What doesn't work

Updating the markers doesn't help. Some advice has moved on to "watch for messages that are too well written". That tells people nothing useful and teaches them to distrust their competent colleagues.

Simulated phishing makes a poor metric. Click rates on simulations measure how well staff recognise simulations. Campaigns built from the same template library the attacker abandoned are measuring an old threat.

Waiting for the filter to catch it rarely works. A message with no link and no attachment, from a domain with no history and correct authentication records, gives content filtering very little to work with. The controls that catch this sit in the payment process, outside the mail path.

Blaming the recipient backfires. When a message passes every check a person was taught to apply, the training failed and the person did what they were told. Treating it otherwise suppresses reporting, which is the one signal that still works well.

Detecting "AI-generated text" is a dead end. Classifiers that claim to identify machine-written prose are unreliable in both directions, and the question they answer is the wrong one anyway. Plenty of legitimate business mail is drafted with a model. Whether a message was generated says nothing about whether the request in it is fraudulent.

Where to start

• Write the verification rule down and apply it to payment changes, fund transfers and credential requests. Keep it to one page, name the channel, and say the number comes from your records.
• Audit the exceptions to that rule. Urgency and seniority are the two that get used, and they are what the attacker imitates.
• Move to phishing-resistant authentication for anyone who can approve payments or reach production.
• Rewrite the awareness deck around requests rather than markers. It gets shorter and it stops going stale.
• Change the phishing metric. Volume blocked measures the thing that got cheaper, so add loss per incident and time to report beside it.
• Make reporting frictionless and consequence-free. When the visible markers are gone, a person's unease is a real signal and often the only early one. Anything that makes reporting feel like admitting a mistake removes it.

The uncomfortable part is that the remaining detectable signal has largely moved out of the message and into the context around it: who this counterpart is, whether you have dealt with them, whether this request fits the relationship. People under time pressure are poorly placed to evaluate that, and a process is better placed.

Sources

1. 2025 Internet Crime Report, FBI Internet Crime Complaint Center: https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf