Clone phishing is a phishing technique in which an attacker copies a legitimate email, replaces or adds a malicious link or attachment, and resends it from a lookalike or spoofed sender. The copied content lowers suspicion because recipients remember the original message and assume the update is harmless.
Expanded Definition
Clone phishing is a replay tactic that weaponises familiarity. An attacker takes a message the recipient has already seen, preserves the brand voice and layout, and changes only the part that matters most: the link, file, or sender path. In NHI environments, this often targets shared mailboxes, service notifications, approval workflows, or vendor-to-system communications where recipients are trained to trust routine updates.
Definitions vary across vendors on whether clone phishing is treated as a distinct phishing class or a subtype of spear phishing, but the operational distinction is useful: the victim is not persuaded by novelty, but by recognition. That matters in identity-heavy environments because a cloned message can be the bridge from human trust to non-human compromise, especially when a callback URL, OAuth consent flow, or attachment launches an agent action. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that awareness, access control, and recovery need to be handled together rather than as separate tasks.
The most common misapplication is treating clone phishing as ordinary spam, which occurs when defenders focus on message volume instead of message similarity and replay risk.
Examples and Use Cases
Implementing detection for clone phishing rigorously often introduces user-friction and mail-flow tuning, requiring organisations to weigh faster validation against fewer interruption events.
- A finance team receives a copied invoice approval email with one replaced attachment, and the malicious file is opened because the thread appears familiar.
- An IT helpdesk receives a “follow-up” message that mirrors a prior vendor exchange and directs staff to a fake login page that captures session tokens.
- A workflow owner sees a cloned “permission update” request and approves a malicious OAuth consent screen, enabling token theft similar to the pattern described in CoPhish OAuth Token Theft via Copilot Studio.
- A security operations queue receives a near-perfect resend of an internal alert, causing analysts to miss that the sender domain has been spoofed and the link redirects outside expected controls.
- A supplier notification is cloned to lure a service account owner into resetting credentials through a counterfeit portal, which is why mail authentication and URL inspection should be paired with sender validation under NIST Cybersecurity Framework 2.0.
Clone phishing is especially effective when organisations rely on memory rather than verification, and when repeated business workflows train users to accept familiar-looking requests without re-checking the destination or authority chain.
Why It Matters in NHI Security
Clone phishing matters in NHI security because the endpoint is often not just a human account compromise but a downstream compromise of secrets, tokens, or delegated access. Once a user approves a malicious resend, attackers can pivot into service accounts, automation runners, or agent tooling that inherits trust from that user. NHI Management Group research shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage, and clone phishing is one of the easiest paths into that outcome when approval-based systems are weak. The same risk lens applies when a cloned message induces a person to trust a fake recovery workflow, as seen in cases like the Poland Military Breach.
Industry guidance is still evolving on where email anti-phishing controls end and identity governance begins, but the practical answer is clear: if a cloned message can trigger credential use, token grant, or agent action, it is an identity event, not just a mail event. The term becomes operationally unavoidable after a user has approved the wrong request, at which point incident response must trace both the message and every non-human identity it exposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AT | Clone phishing exploits user trust, making awareness and training a core control area. |
| OWASP Agentic AI Top 10 | A2 | Phishing can drive malicious prompts or approvals that trigger unsafe agent actions. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Clone phishing often leads to token theft, secret exposure, or unauthorized NHI access. |
| NIST SP 800-63 | Identity assurance guidance helps distinguish legitimate authentication from spoofed requests. | |
| NIST Zero Trust (SP 800-207) | Zero trust reduces the impact of a successful cloned-message compromise. |
Assume every email-driven request is untrusted until the user, device, and destination are independently verified.
Related resources from NHI Mgmt Group
- How should security teams reduce the risk of clone phishing in email-heavy organisations?
- What is phishing-resistant authentication and how does it relate to NHI security?
- How should security teams respond to voice phishing that targets Okta accounts?
- Why do MFA and password resets fail to stop consent phishing?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
