Security teams detect spearphishing via social-engineering LLMs by correlating personalised, well-written messages with unusual sender infrastructure, account behaviour, and timing. Look for content that mimics internal tone, references current projects, or requests urgent credential or payment actions. Strengthen identity verification, mailbox controls, reporting paths, and user training focused on AI-generated persuasion.
How to spot AI-written spearphishing before the click
Detection works best when teams treat the message as one signal among several, not as proof on its own. LLM-assisted spearphishing often looks polished, context-aware, and domain-specific, so style alone is a weak indicator. The stronger pattern is a message that feels individually tailored while arriving from infrastructure, accounts, or timing that do not fit normal business communication.
The practical test is whether the content and the delivery path agree. If the wording mirrors internal tone, references current work, or pressures the recipient into urgent action, compare it with sender reputation, domain history, mailbox authentication results, and recent account activity. A message that is linguistically credible but operationally odd deserves faster scrutiny than a noisy, generic spam attempt.
Teams should also look for scale effects that humans miss. LLM-generated spearphishing can produce many slightly varied messages against the same target group, which reduces the value of exact text matching and raises the importance of pattern-based detection across multiple mailboxes, suppliers, and time windows.
Which signals matter most in mail and identity telemetry?
Start with the signals that are hardest for social engineering to fake consistently. Unusual sender infrastructure, newly registered domains, mismatched reply paths, failed or inconsistent authentication, and first-time contact from an external account are all useful clues. Combine those with identity and behaviour signals such as impossible travel, atypical login times, new forwarding rules, suspicious mailbox delegation, and a sudden shift from normal collaboration to urgent payment or credential requests.
MITRE ATT&CK Enterprise Matrix is useful for mapping the post-delivery behaviours that often follow a successful lure, especially credential access, persistence, and follow-on movement. For teams building controls around the message itself, the key is to correlate content with mailbox and identity telemetry rather than waiting for a user to report the email.
Detection improves when analysts compare the message against the recipient’s relationship graph. Requests that appear to come from a known executive, vendor, or internal peer but arrive through a new domain, a fresh account, or an unexpected channel are more suspicious than the wording alone suggests. That is particularly true when the message asks for payment, secrets, session approval, or an exception to normal process.
How should teams respond when the lure is persuasive but not obviously malicious?
When the social engineering is well written, the safest response is to verify the request out of band before the recipient can act. Mail controls should make reporting easy, block obvious lookalikes, and surface anomalies to the security team quickly enough to stop the second recipient from being targeted. If the message is already in a shared mailbox or a collaboration workflow, containment matters more than debating whether the prose sounds AI-generated.
NIST SP 800-53 Rev 5 Security and Privacy Controls supports the underlying control mix here, especially identity, audit, and access controls that help verify sender legitimacy and trace message handling. The operational goal is to make fraudulent requests harder to deliver, easier to detect, and easier to investigate after the fact.
Because the content may be highly personalised, the response process should assume that at least one user may be close to acting on it. That means preserving the original message, the headers, the delivery path, and any related authentication events so the team can determine whether it was only a lure or the start of a broader compromise.
Risk and Threat Considerations
LLM-assisted spearphishing increases the chance that a target will engage because the message can sound specific, credible, and timely without exposing the usual spelling or grammar tells. The main risk is not just one successful click, but the speed at which a convincing lure can be repeated across many recipients before defenders have time to adjust filters or warn users.
Failure mechanism: The attacker uses well-formed, context-aware text to bypass user suspicion while relying on mismatched infrastructure, account anomalies, or follow-on login behaviour to land the compromise.
Impact: Successful delivery can lead to credential theft, fraudulent payment action, mailbox takeover, or a larger identity compromise if the attacker leverages the captured account to impersonate trusted internal senders.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | Maps spearphishing delivery and credential-theft follow-on behavior. |
| Recommendation — Map lure content to phishing patterns and hunt for credential access after delivery. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Supports correlating message, identity, and mailbox events for detection. |
| IA-5 — Authenticator Management | Relevant when spearphishing seeks credentials or session access. | |
| AC-6 — Least Privilege | Limits damage if a phishing-led account compromise succeeds. | |
| Recommendation — Correlate mail, identity, and endpoint logs to spot anomalous delivery and use. Harden authenticator lifecycle controls to reduce the value of stolen credentials. Restrict mailbox and admin permissions to minimize post-compromise impact. | ||
Practitioner Guidance
What to verify: Treat any highly tailored request as suspicious until sender identity, domain reputation, and mailbox authentication all line up. If the content is urgent and the channel is unusual, verify the request through a separate known-good path before the user takes action.
What to measure: Track how often suspicious messages are caught by correlation, not by content signatures alone. The most useful measures are time to triage, reporting speed, and the percentage of incidents where unusual sender infrastructure or account behaviour was visible before user interaction.
Practitioner takeaway: The best detector for AI-written spearphishing is a joined-up view of language, infrastructure, and identity behaviour, because the prose may be perfect even when the delivery path is not.