Skip to content

Security awareness · 9 min read · 4 August 2026

AI-Powered Phishing: Could Your Team Recognise the Attack?

The advice to watch for spelling mistakes and awkward phrasing has stopped working. What replaces it is not better instinct, it is better process.

For years, awareness training taught a reliable shortcut. Phishing was often written quickly, at scale and in a second language, leaving grammatical errors, generic greetings and strange formality. Employees learned to notice the seams.

Generative tools have removed many of those seams. A message can be fluent, matched to a company's tone and personalised with public information about the recipient. If a message can no longer be judged by how it reads, it must be judged by what it asks for and how that request can be independently confirmed.

What AI changes, and what it does not

An official Microsoft summary of its 2025 Digital Defense Report said AI-augmented phishing achieved click-through rates as high as 54%, compared with 12% for traditional phishing in the referenced testing. The practical lesson is not that every AI-written message is unusually successful. It is that language quality is becoming a poor screening mechanism.

AI improves the wrapper, not the mechanism. The message still needs a person to enter a password, approve a payment, change a supplier bank account, open a document or grant access. The persuasion is better; the ask has not changed.

54% vs 12%

Click-through rates reported by Microsoft for AI-augmented versus traditional phishing in its 2025 defence-report summary.

$568m

Reported US losses attributed to business email compromise in the FBI IC3 2025 report.

Three messages, one decision

The fictional messages below use the same supplier-payment situation. Message A is legitimate, Message B is the obvious phish most training still describes, and Message C is a polished impersonation. Read the final request in each, not just the tone.

Three fictional emails, one business request

A · Legitimate

Anneke Vos <[email protected]>

Invoice MC-4471 - query on delivery line 3

The unit price still reflects the old schedule. Account details are unchanged. I can raise a credit note if that is easier.

Specific shared context, no payment change, no pressure.

B · Conventional phishing

Accounts <[email protected]>

URGENT: Outstanding Payment Notice!!

Update payment to our new bank account within 24 hours to avoid suspension and legal action.

Lookalike domain, generic greeting, threat, unexplained bank change.

C · AI-assisted

Anneke Vos, reply-to: [email protected]

Re: Invoice MC-4471 - delivery line 3

Our banking moved after the group restructure. Please use the updated account before Friday's month-end run.

Natural tone and plausible context, but the reply-to and the request fail verification.

The legitimate message contains specific shared history and explicitly says the bank details are unchanged. The conventional phish relies on a lookalike domain, generic language and a threat. The AI-assisted example uses a plausible project, a calm tone, a soft deadline and an offer to call. Its structural signals are the mismatched reply-to address and the request to change banking details.

Beyond the inbox

Business email compromise

Business email compromise uses email as a delivery mechanism but may contain no malicious link or attachment at all. It often impersonates a supplier or senior leader and asks someone to change bank details, release an urgent payment or keep a request confidential. The FBI's 2025 Internet Crime Report recorded $568,048,472 in reported losses attributed to business email compromise. Filters designed only to detect malware will not solve a fraud based on authority and process.

Fake login pages and session theft

Modern credential-harvesting pages can closely reproduce a genuine service. Some relay the interaction in real time, allowing the attacker to capture a working session after the victim responds to an MFA prompt. FIDO and WebAuthn credentials are resistant to this pattern because they are cryptographically bound to the genuine site.

QR codes, voice and video

A QR code moves the interaction from a monitored computer to a phone where the destination is less visible and corporate controls may not apply. Codes can appear in email images, PDF attachments, printed notices and stickers placed over legitimate signs. A useful rule is simple: never scan a code to reach a login page.

Synthetic audio or video can reinforce a fraudulent request already made by email or chat. A recognisable voice or face is no longer sufficient authentication for a high-impact decision. The answer is not to become an expert in detecting deepfakes; it is to use callback procedures, dual approval and pre-agreed verification phrases.

How to inspect a request safely

Start with what the message wants

Four categories warrant verification every time: a change to bank details; an unexpected or urgent payment; a request to sign in or re-authenticate; and a request to install software, approve an application or grant access. If the stakes are high, no amount of familiarity substitutes for a check.

Display names are decorative. Expand the sender details and compare the actual address with the reply-to address. Read domain names from the right, treat shortened links as unknown, and reach important services by typing the known address or using a saved bookmark. A password manager refusing to autofill can be a meaningful warning because it recognises the real domain.

Treat attachments as claims

If a document is unexpected, confirm it through another channel before opening it. Never enable macros or editing in an unsolicited file. Judge a login page by how you reached it, not by how accurately it reproduces the genuine brand.

Verification is a business process

Individual vigilance does not scale and eventually fails when someone is rushed or tired. Process scales. Any change to payment details should be verified by calling a number already held in supplier records, never a number supplied in the request. Higher-value transactions should require a second approver who independently confirms the payee.

Reporting must take seconds and must not punish uncertainty. Ask people to report suspicion, not certainty, and to report immediately after a click. The minutes after a mistake are when session revocation and containment are most effective. Thanking someone for reporting a false alarm protects the organisation far better than creating silence.

Request-verification checklist

  • Does the request involve money, credentials, access or changed payment details?
  • Does the real sender address match the display name, and does the reply-to match?
  • Am I being pushed to act quickly, secretly or outside the normal process?
  • Would I reach this login page by navigating there myself rather than following the link?
  • Have I verified the request using contact details from my own records?
  • For a payment change, was the callback completed and recorded?
  • For a verbal request, was an agreed verification phrase used?
  • If I am uncertain, have I reported it immediately?

The question has changed

"Does this look suspicious?" was reasonable when attackers left visible seams. It is now a weak question because the answer can be no while the message is still fraudulent. The better question is narrower and more durable: what is this asking me to do, and how would I confirm it through a channel it did not give me?

Sources and further reading

  1. 1.Microsoft - Digital Defense Report
  2. 2.FBI Internet Crime Complaint Center - Internet Crime Report
  3. 3.CISA - Implementing Phishing-Resistant MFA
  4. 4.ENISA - Threat Landscape
  5. 5.NIST SP 800-63B - Authentication and Authenticator Management