An attack technique where the visible sender name is copied from a real person or internal contact while the underlying domain is unrelated or malicious. Because display names are not authenticated, they can create false familiarity even when the technical sender identity is suspicious.
How Display-Name Impersonation Works
Display-name impersonation exploits a simple trust shortcut: people often read the visible sender name first and inspect the underlying address later, if at all. The attack succeeds when the name matches a colleague, executive, supplier, or help desk contact closely enough to feel routine.
What makes this technique effective is that the visible name is presentation data, not proof of identity. An attacker can pair a familiar display name with an unrelated domain, disposable mailbox, or compromised account and still trigger a fast, low-friction response from the recipient.
Why It Is Effective in Email and Messaging
This attack is especially useful in channels where speed and skim-reading are normal, such as email, chat, ticketing systems, and collaboration tools. The name field gives the message a social veneer even when the technical sender identity, reply path, or domain reputation does not support it.
It also works across organisational boundaries. A display name that resembles a real internal contact can be enough to bypass casual scrutiny, even when the address is external or the account has no legitimate relationship to the organisation.
Common Attack Patterns and Abuse Cases
Display-name impersonation is often used as the first step in phishing, fraud, and business email compromise attempts. The attacker may imitate finance, HR, IT support, a vendor, or a senior leader to increase the odds that the recipient opens a message, follows instructions, or starts a conversation.
It is also useful for follow-on social engineering. Once a target replies, the attacker can steer the exchange toward credential capture, payment diversion, malicious attachment delivery, or the disclosure of internal information that can be reused in a broader intrusion.
Where messages are relayed through modern identity and collaboration stacks, organisations should assume that familiar-looking names can appear in otherwise legitimate workflows. In those environments, sender identity and message provenance matter more than the display string alone, as reflected in RFC 8693: OAuth 2.0 Token Exchange for delegated identity flows and NIST SP 800-63 Digital Identity Guidelines for stronger authentication foundations.
How Organisations Reduce Exposure
Defence starts with making the visible name less trustworthy on its own. Mail and messaging controls should surface the actual sender domain, external-user markers, authenticated headers, and suspicious reply-to differences so recipients are not forced to infer trust from the name field.
Operationally, organisations also need clear identity hygiene for internal contacts, executive profiles, and high-risk functions that are commonly impersonated. Consistent naming conventions, verified contact directories, and user education about sender verification all reduce the chance that a copied display name will pass as routine traffic.
For identity-heavy environments, stronger verification and tighter audience scoping help reduce the blast radius of spoofed or reused identities. Guidance such as NIST Cybersecurity Framework 2.0 and NIST Privacy Framework can support broader governance over identity presentation, trust signals, and user-facing verification practices.
Risk and Threat Considerations
Display-name impersonation matters because it turns familiarity into an attack surface. The technique does not need technical exploitation to succeed, only a moment of misplaced trust, which makes it scalable across phishing, invoice fraud, and internal impersonation campaigns.
Failure mechanism: The recipient trusts the visible name and delays checking the real sender identity, allowing an unrelated or malicious account to borrow the credibility of a real person or team.
Impact: The attacker can drive credential theft, payment redirection, malicious link clicks, data disclosure, or further impersonation inside the organisation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines stronger authentication and identity assurance relevant to spoofed sender trust signals. |
| Recommendation — Use phishing-resistant authentication and verified identity signals to reduce reliance on display names. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Display-name impersonation exploits weak trust in identity presentation and authentication cues. |
| Recommendation — Strengthen identity and authentication controls so users verify the real sender before acting. | ||
| MITRE ATT&CK | T1585 — Establish Accounts | Attackers commonly create or use accounts that present a trusted-looking persona. |
| Recommendation — Hunt for account creation and persona-building activity that supports impersonation campaigns. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The subject centers on abusing weakly trusted identity signals rather than verified identity. |
| Recommendation — Require authenticated sender identity before any privileged or sensitive workflow proceeds. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Controls over who can present as trusted internal users reduce impersonation opportunities. |
| Recommendation — Restrict and review who can create or modify high-trust identity presentations. | ||
Practitioner Guidance
What to watch for: Treat any request that depends on urgency, secrecy, payment, or account action as suspect until the actual sender identity is verified through an independent channel. Display names are useful for readability, but they are not a reliable trust control.
Governance implication: Ownership should sit with messaging, identity, and security teams together, because reducing this abuse requires both technical controls and user-facing trust design. The most effective programmes make verification cues obvious before they make users responsible for spotting deception.
Related resources from NHI Mgmt Group
- Why do autonomous agents need cryptographic identity instead of display-name trust?
- Why does domain spoofing create more risk than display name spoofing for enterprise communications?
- How should security teams reduce the risk of email phishing when attackers use display-name spoofing and mobile clients hide full headers?
- What happens when business email compromise uses a spoofed display name and an urgent request?