What is the difference between clone phishing and business email compromise?

Why This Matters for Security Teams

Clone phishing and business email compromise are often grouped together because both exploit trust, but the defender’s problem is not the lure alone. The critical difference is where the message originates and how much legitimacy the attacker can borrow. Clone phishing usually depends on a convincing external copy, while BEC uses a real or compromised account to speak from inside the trusted channel. That distinction changes detection, response, and recovery priorities.

Security teams that miss this difference often tune controls for message appearance instead of sender legitimacy and transaction verification. In practice, that means a cloned invoice may be caught by filtering, while a compromised mailbox can still authorize payment changes, reset passwords, or forward internal threads. NHIMG’s 52 NHI Breaches Analysis shows how quickly credential abuse turns into broader access when trust is anchored to identity alone. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that identity assurance and transaction controls must work together, not separately.

In practice, many security teams encounter BEC only after a mailbox has already been used to move money or reset access, rather than through intentional monitoring of trusted-account abuse.

How It Works in Practice

Clone phishing is a replay attack against the visual and contextual cues of a message. The attacker copies a known email, imitates formatting, and swaps in a malicious link or attachment. Because it often arrives from an external or spoofed source, email security tools may still have a chance to flag domain mismatch, suspicious infrastructure, or attachment detonation artifacts.

BEC is more dangerous because it abuses a legitimate communication path. The attacker may use a stolen mailbox, a lookalike internal account, or a compromised supplier account to request payment, alter banking details, or pressure a target into acting quickly. That makes the message harder to question, especially when the thread contains prior context. NHIMG’s TruffleNet BEC Attack — Stolen AWS Credentials illustrates the same trust problem in a different environment: once stolen credentials are accepted as authentic, the attacker can operate as if they belong there.

Effective defence usually combines controls at three layers:

• Mail security that inspects sender reputation, domain alignment, and attachment or URL risk.
• Identity controls that detect impossible travel, mailbox forwarding changes, OAuth abuse, and suspicious login patterns.
• Business process controls that require out-of-band verification for payments, supplier changes, and password resets.

For organisations handling high-value transactions, current guidance suggests treating BEC as an identity and process integrity issue, not just a phishing problem. Where automated workflows are tied to email approval chains, the model breaks down because a single compromised mailbox can authenticate both the request and the approval.

Common Variations and Edge Cases

Tighter email verification often increases friction for users, so organisations have to balance speed against resilience. That tradeoff matters because not every suspicious message is malicious, but every high-trust workflow is a potential target.

Some cases blur the line. A cloned phishing email sent from a compromised supplier account can look like BEC because the sender is now trusted, even if the attacker started externally. Likewise, a real internal mailbox used to send a copied malicious attachment may resemble clone phishing in content but BEC in execution. The operational question is less about the email’s visual style and more about whether the sender identity is genuine, compromised, or impersonated.

This is also where AI-assisted phishing is changing the baseline. Attackers can generate more convincing clones, but the strongest indicator of BEC remains trusted-account misuse. NHIMG’s DeepSeek breach and Ultimate Guide to NHIs — Why NHI Security Matters Now both reinforce the broader pattern: once credentials or trusted identities are exposed, the attacker no longer needs to rely on obvious spoofing.

Best practice is evolving toward continuous verification of sender identity, transaction context, and behavioural anomalies rather than assuming that a familiar name or thread history is inherently safe.

Related resources from NHI Mgmt Group

• What is the difference between prompt injection risk and identity abuse in agents?
• What is the difference between SAST and DAST for security teams?
• What is the difference between phishing detection and behavioural email security?
• What is the difference between a browser-based attack and a traditional email phishing campaign?