You’ve probably opened a phishing email that looks flawless and then wondered why the usual red flags, typos, broken grammar, odd phrasing, didn’t appear. Large language models (LLMs) can now draft messages that read like a professional writer, erasing the clues you once relied on. This guide explains what still works, from out‑of‑band verification to hardware‑based authentication, and even how deep‑fake audio and video enter the game.
Why Traditional Typos No Longer Signal Phishing
For years, security training emphasized spotting spelling errors, awkward phrasing, or inconsistent branding. Those cues were cheap to produce, and attackers often skimped on polish. Today, models such as GPT‑4 can generate text that matches corporate style guides down to the last comma. The result is a message that passes a quick read‑through, making the old “look for mistakes” rule ineffective.
Research from the OWASP Top 10 for LLM Applications notes that language models excel at mimicking tone, jargon, and even internal acronyms when fed enough examples. Because the model can be instructed to avoid any obvious errors, the output frequently scores above 90 % on readability tests. That level of fluency means a recipient no longer feels an instinctive “something feels off.”
What changes, however, is the attacker’s cost structure. Generating a high‑quality email now costs only compute time, not a human editor. The barrier to scale drops dramatically, and campaigns can reach thousands of inboxes with the same level of craftsmanship. As a result, the signal‑to‑noise ratio of traditional clues collapses, and defenders must look elsewhere for reliable indicators.
To illustrate, imagine a threat actor who inputs a recent product launch announcement into a prompt that says, “Write a request for approval in the tone of Acme Corp’s internal memos, no spelling errors.” The model returns a four‑paragraph email that reads exactly like a genuine internal communication. A reviewer who relies on typo detection would see nothing suspicious.
Common mistake: treating every polished email as safe. The only safe assumption is that any request could be malicious until you verify its source through technical means.
LLMs Produce Grammatically Perfect Lures
When you ask an LLM to write a phishing lure, it follows the prompt literally. If you specify “use corporate tone, include a call‑to‑action, and avoid any spelling errors,” the model obeys. The output will include correctly placed commas, accurate punctuation, and even brand‑consistent terminology. This isn’t a hypothetical; several red‑team reports have demonstrated that AI‑generated emails can pass automated grammar checks without triggering alerts.
The key mechanism is the model’s next‑token prediction, which selects the most statistically likely word given the context. Because the training data includes millions of professional communications, the model internalizes the patterns of legitimate correspondence. It can also embed contextual details, like a recent product launch, if the attacker supplies those snippets.
From a defender’s perspective, the shift means that surface‑level language analysis provides little value. Instead, you must treat every message as potentially authentic until you confirm its provenance through technical means. This aligns with guidance from CISA, which advises organizations to “verify the source of unexpected requests before acting.”
Worked example: an attacker wants a finance officer to approve a wire transfer. They feed the LLM a snapshot of an internal memo and ask for a “urgent payment request” that references the same project code. The resulting email includes the exact project name, a correctly formatted table, and a polite sign‑off. When the finance officer runs the email through a grammar‑checking plugin, it receives a perfect score. Only a DMARC check or a phone call would reveal the deception.
Common mistake: relying on content‑based filters alone. Modern spam filters that focus on keyword density or spelling errors will miss these messages.
Verifying Out‑of‑Band Channels
Out‑of‑band (OOB) verification means confirming a request through a separate communication path. If an email asks you to approve a payment, call the vendor using a phone number you have on file, not the one in the message. The same principle applies to chat, SMS, or internal ticketing systems. OOB checks bypass the compromised channel entirely, removing the attacker’s ability to influence the reply.
When to Use OOB Verification
Use OOB verification for any request that involves credential changes, financial transfers, or privileged access. The FBI IC3 emphasizes that “high‑value actions should always be confirmed through a secondary channel” because attackers often hijack the primary vector.
Implementing OOB verification doesn’t require new software; it relies on existing organizational policies. However, you must train staff to recognize when a request qualifies as “high‑risk.” A simple decision tree, ask if the request changes a password, moves money, or grants admin rights, helps keep the process quick and consistent.
Worked example: an employee receives an email that appears to come from the IT department, asking for a password reset. The email includes a link to a password‑reset portal that looks identical to the official site. The employee checks the internal directory, finds the IT desk’s official phone number, and calls. The IT team confirms that no reset was requested. The employee avoids a credential‑theft incident.
Common mistake: treating the phone number in the email as trustworthy. Attackers can spoof caller ID or include a malicious number in the body. Always use a contact method stored in an independently maintained address book.
Verification tip: after a successful OOB check, log the interaction in a ticketing system. This creates an audit trail that can be reviewed later if a breach is suspected.
Inspecting the Sending Domain and Email Authentication
Domain‑based Message Authentication, Reporting & Conformance (DMARC) builds on SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to verify that an email really comes from the claimed domain. When you receive a message, compare the “From” address against the “Return‑Path” and look for a valid DKIM signature. Many email clients now surface this information in a small banner or tooltip.
If the DKIM signature fails, the message should be treated as suspicious regardless of how well‑written it appears.
Attackers can spoof the visible name, but they can’t forge a DKIM signature without access to the domain’s private key. A failed authentication flag should trigger the same caution you would apply to a typo‑laden email. NIST’s guidance on email security recommends treating any unauthenticated message as untrusted, even if the content appears legitimate.
How to check manually: open a command prompt and run nslookup -type=TXT _dmarc.example.com. The response will show the DMARC policy, such as v=DMARC1; p=reject; rua=mailto:dmarc‑reports@example.com. Next, retrieve the SPF record with nslookup -type=TXT example.com. Look for the v=spf1 string that lists authorized sending IPs. Finally, examine the email headers for a line that starts with DKIM-Signature:. If the signature is present and the Result field says “pass,” the message passed DKIM.
Worked example: an employee receives an invoice from billing@partner‑corp.com. The header shows Authentication-Results: mx.google.com; spf=pass (google.com: domain of billing@partner‑corp.com designates 192.0.2.45 as permitted sender) smtp.mailfrom=billing@partner‑corp.com; dkim=pass header.i=@partner‑corp.com; dmarc=pass. Because all three checks pass, the employee can proceed with the payment after confirming the invoice details.
Common mistake: ignoring a “softfail” SPF result. A softfail indicates that the sending IP isn’t listed but isn’t definitively unauthorized. In high‑risk scenarios, you should still verify through OOB channels.
Verification tip: configure your email gateway to quarantine messages that fail any of the three checks. This gives security teams a chance to review before the message reaches the inbox.
Treating Urgency as a Signal, Not a Trick
Phishers have always used urgency to rush users into careless decisions. AI‑generated lures now embed urgency naturally, citing deadlines, system outages, or compliance windows. The message may say, “Your account will be locked in 2 hours; click now.” Because the language is polished, the urgency feels authentic.
What still works is recognizing urgency as a risk factor. The CISA “Cyber Essentials” program lists “pressure tactics” as a hallmark of social engineering. When a request demands immediate action, pause and ask: Why is this needed now? Can the same outcome be achieved later without risk?
Steps to Counter Urgency
1. Identify the claim, what deadline or consequence is being invoked?
2. Locate an independent source, internal policy docs, official status pages, or a manager.
3. Verify through OOB channels before acting.
Worked example: a manager receives a Slack message stating, “All expense reports must be approved within the next 30 minutes or the finance system will shut down.” The employee checks the finance portal, sees no outage notice, and calls the manager’s office line listed in the internal directory. The manager confirms that no such deadline exists. The employee reports the Slack message to the security team.
Common mistake: assuming that a deadline in the subject line automatically means the request is legitimate. Attackers often copy internal calendar events to make the urgency appear real.
Verification tip: create a quick‑reference card that lists typical urgency phrases, “immediate action required,” “account will be disabled,” “last chance”, and remind staff to use the three‑step process each time such language appears.
Passkeys and Hardware Tokens: The Phishing Endgame
Passkeys, cryptographic credentials stored in a device or browser, replace passwords with public‑key authentication. When a service supports WebAuthn, the user’s private key never leaves the hardware token, and the server validates the request by checking the signature against a stored public key. Because the private key can’t be phished, credential‑theft attacks lose their primary weapon.
Hardware tokens such as YubiKey or built‑in platform authenticators (e.g., Apple Secure Enclave) provide a second factor that’s “something you have.” Even if an attacker captures a user’s username and password via an AI‑generated email, they can’t complete the login without the physical token.
FBI IC3 notes that “multifactor authentication that includes a hardware component dramatically reduces the success rate of credential phishing.” Organizations adopting passkeys benefit from a single, user‑friendly step that defeats both password‑spraying and credential‑phishing campaigns. NIST’s Digital Identity Guidelines recommend using passkeys wherever possible because they eliminate the need for shared secrets that can be replayed.
Enrollment workflow: 1) The user visits the service’s registration page and clicks “Add security key.” 2) The browser invokes the WebAuthn API, prompting the user to insert the hardware token or use a built‑in authenticator. 3) The token generates a new key pair; the public key is sent to the server and stored with the user’s account. 4) On subsequent logins, the server issues a challenge; the token signs it, and the browser returns the signed response.
Worked example: an employee sets up a passkey for the corporate VPN. Later, they receive a phishing email that asks for their VPN credentials. Even if they inadvertently type their password into a malicious site, the VPN still requires the hardware token. Because the attacker doesn’t have the token, the login fails.
Common mistake: treating a passkey as optional. Some organizations allow fallback to SMS codes, which can be intercepted. Enforcing passkey‑only authentication removes that weak link.
Verification tip: audit your identity provider’s authentication logs for any attempts that fall back to password‑only methods. Flag those accounts for mandatory passkey enrollment.
For environments that can’t yet move to passkeys, a hardware OTP generator (e.g., a TOTP app on a separate device) still adds a barrier that AI‑generated lures can’t bypass without the user’s cooperation.
Voice and Video Deepfake Pretexting
Deep‑fake technology now produces synthetic audio and video that can mimic a CEO’s voice or appear to show a live video call. Attackers combine these media with AI‑written scripts to create convincing pretexting scenarios. A deep‑fake might call a finance officer and demand an emergency wire transfer, while the visual appears to be the CFO on a video conference.
Detection hinges on two factors: (1) technical cues such as unnatural facial movements, audio clipping, or mismatched lip sync; and (2) procedural safeguards. Organizations should require a secondary verification step for any request delivered via voice or video, regardless of how authentic it looks. CISA recommends “never act on a single media channel without confirming the request through a trusted method.”
Practical Indicators of Deepfakes
– Slight delays or echo in the audio.
– Inconsistent lighting or background changes.
– Absence of a known security phrase or code word.
Technical tools can help. Microsoft’s Video Authenticator assigns a confidence score to each frame, while open‑source projects like DeepFaceLab provide forensic analysis scripts. Running a short clip through one of these tools before taking action adds a layer of assurance.
Worked example: a procurement manager receives a Zoom call that looks exactly like the CFO, complete with the company logo in the background. The manager notices a brief pause where the audio glitches, and the lighting shifts suddenly. Before transferring funds, the manager ends the call, opens a separate messaging app, and texts the CFO’s known number asking to confirm the request. The CFO replies that no call was made. The manager reports the incident, and the security team isolates the deep‑fake file.
Common mistake: assuming that a perfect‑looking video means the request is legitimate. Even with flawless visual quality, the attacker controls the content and can fabricate any scenario.
Verification tip: embed a “challenge phrase” in your internal communication policy, something that only the real speaker knows, like a recent project code or a specific password‑less token identifier. If the phrase is missing or incorrect, treat the call as suspicious.
A Practical Checklist for Real‑World Defense
Use the table below to walk through each new phishing cue before you click, tap, or call.
| Check | What to Do | Why It Matters |
|---|---|---|
| Domain authentication | Verify SPF/DKIM/DMARC pass | Ensures sender controls the domain |
| Out‑of‑band verification | Contact the requester via known channel | Bypasses compromised email |
| Urgency assessment | Ask if deadline can be extended | Reduces pressure‑induced errors |
| Passkey usage | Authenticate with hardware token or WebAuthn | Eliminates credential replay |
| Media authenticity | Check for deep‑fake cues; confirm via OOB | Prevents synthetic voice/video fraud |
Follow this checklist each time a request feels out of the ordinary. The steps are independent of the message’s language quality, meaning they remain effective even as LLMs improve. By anchoring your response to technical validation and verification policies, you neutralize the advantage that AI‑generated phishing attempts bring.
Additional tip: schedule quarterly tabletop exercises that simulate AI‑crafted phishing emails, deep‑fake calls, and compromised domains. Let participants practice the checklist in a safe environment. After each drill, review where shortcuts were taken and reinforce the habit of thorough verification.
