Every system that acts on a claimed identity, whether a person, a server, a signed file or a workload, can be fooled if that claim is not verified. MITRE CAPEC catalogues this as CAPEC-151 Identity Spoofing, a Meta-level attack pattern: the adversary assumes the identity of another entity, human or non-human, and uses it to reach a goal. Because it is a meta pattern, CAPEC-151 sits above more specific patterns such as phishing, pharming, signature spoofing and token impersonation. This guide uses CAPEC-151 as a map: what the pattern covers, how its child patterns differ, which control verifies identity at each layer, how to detect spoofing that gets through, and how to decide where to invest first. It is for security architects, identity teams and detection engineers. For how CAPEC is structured, see the MITRE CAPEC Guide.
Key takeaways
- Identity spoofing changes who, not what. CAPEC separates it from CAPEC-148 Content Spoofing: here the adversary changes the apparent identity of a message or resource, not its content.
- The root weakness is unverified claims. CAPEC maps the pattern to CWE-287 Improper Authentication, and its only listed mitigation is strong authentication such as multi-factor authentication.
- Non-human identities are in scope. The CAPEC definition names human and non-human entities. Spoofed servers, forged tokens and stolen signing keys are the same pattern as a spoofed email sender.
- Each layer has its own verification control. Email has DMARC, websites have TLS and certificate validation, software has code signing, workloads have mutual authentication, and people need out-of-band verification.
- Stolen credentials feed spoofing. CAPEC lists credential attacks such as credential stuffing, pass the hash and pass the ticket as patterns that can precede identity spoofing, so credential hygiene is spoofing defence.
What CAPEC-151 covers
CAPEC defines identity spoofing as assuming the identity of some other entity (human or non-human) and then using that identity to accomplish a goal, either by crafting messages that appear to come from a different principal or by using stolen or spoofed authentication credentials. The extended description adds two points that shape defence:
- Interception and re-attribution: an adversary may intercept a legitimate message and make it appear to come from them without changing the content, which can be used to hijack credentials.
- Resources, not just messages: any resource associated with an identity, such as a file with a signature, can be targeted by changing its apparent identity.
| CAPEC attribute | Value for CAPEC-151 |
|---|---|
| Abstraction | Meta |
| Likelihood of attack | Medium |
| Typical severity | Medium |
| Prerequisite | The identity associated with the message or resource must be removable or modifiable in an undetectable way |
| Skills and resources | No specialised resources required |
| Consequences | Gain privileges (access control, authentication, confidentiality, integrity) |
| Related weakness | CWE-287 Improper Authentication |
| Listed mitigation | Use strong authentication processes, such as multi-factor authentication |
The prerequisite is the most useful line for defenders. Identity spoofing works only where the identity can be altered without detection. Every control in this guide removes that condition for one channel.
The child patterns and what defeats each
CAPEC lists five standard patterns beneath CAPEC-151, each with detailed patterns of its own. The table shows them with the verification control that removes the prerequisite and, where CAPEC records one, the related ATT&CK technique.
| CAPEC pattern | What is spoofed | Detailed examples (CAPEC) | Primary verification control |
|---|---|---|---|
| CAPEC-194 Fake the Source of Data | The origin of data or a service, for example a forged email From field | CAPEC-598 DNS Spoofing; CAPEC-697 DHCP Spoofing (T1557.003); CAPEC-633 Token Impersonation (T1134); CAPEC-543 Counterfeit Websites (T1036.005) | Sender authentication (SPF, DKIM, DMARC), DNSSEC validation, DHCP snooping, token integrity checks |
| CAPEC-195 Principal Spoof | A person in an interaction, by written, verbal or visual message | Phishing and pharming attempts to appear legitimate | Out-of-band verification of requests, caller authentication at help desks |
| CAPEC-473 Signature Spoof | A cryptographic signature from an authoritative source | CAPEC-474 Signature Spoofing by Key Theft (T1552.004); CAPEC-479 Malicious Root Certificate (T1553.004) | Signing key protection in HSMs, signature and chain validation, trust store control |
| CAPEC-89 Pharming | A trusted site, by redirecting users to an impostor | Redirection without a malicious link | DNS integrity, TLS with certificate validation, phishing-resistant authenticators |
| CAPEC-98 Phishing | A trusted sender, to obtain information or credentials | CAPEC-163 Spear Phishing; CAPEC-164 Mobile Phishing; CAPEC-656 Voice Phishing | Email authentication, user reporting, phishing-resistant MFA |
For each channel there is a deeper guide: DMARC, SPF and DKIM Guide, DNSSEC Deployment Guide, Code Signing Security Guide and Phishing Guide. This page connects them under one model rather than repeating them.
Verification controls by identity type
A practical way to apply CAPEC-151 is to list every kind of identity your systems trust and ask how each is verified. Gaps show up quickly.
| Identity type | How it is commonly spoofed | Control that verifies it | Standard or reference |
|---|---|---|---|
| Email sender domain | Forged RFC5322.From header | DMARC with aligned SPF or DKIM, policy at quarantine or reject | RFC 7489, now obsoleted by RFC 9989, 9990 and 9991 |
| Website or service endpoint | Lookalike domains, DNS or DHCP manipulation | TLS with full certificate validation, DNSSEC, DHCP snooping, certificate transparency monitoring | NIST SP 800-53 SC-8, SC-23 |
| User signing in | Stolen password or relayed OTP | Phishing-resistant authenticators bound to the verifier name | NIST SP 800-63B-4 (phishing resistance required at AAL3) |
| Person making a request | Caller claims to be an employee, executive or supplier | Call-back to a number on record, manager approval, identity proofing for resets | NIST SP 800-53 IA-2, IA-8 |
| Software or update | Stolen signing key, rogue root certificate | Keys in HSMs, signature and chain validation, controlled trust stores | NIST SP 800-53 SI-7 |
| Workload or service | Stolen API key, forged token | Mutual TLS, workload identity federation, short-lived tokens with audience restriction | NIST SP 800-53 IA-9 |
| Device | Cloned identifiers, rogue access points | Certificate-based device authentication | NIST SP 800-53 IA-3 |
NIST SP 800-63B-4 states that passwords, look-up secrets, out-of-band authenticators and one-time passwords are not phishing-resistant, and that cryptographic authenticators are phishing-resistant only if they meet its additional requirements. See the Phishing-Resistant MFA Guide.
Where identity fits: non-human identities
CAPEC's explicit inclusion of non-human entities matters because machine identities usually authenticate with a single factor: a key, token or certificate. Whoever holds it is that identity. The spoofing paths are well known:
- Stolen static secrets: an API key or service account password copied from code, logs or a CI system lets an adversary act as the workload. See the Service Account Security Guide.
- Forged tokens: if a token signing key or a federation trust is compromised, the adversary can mint identities. See the Golden SAML and Federation Trust Abuse Defence Guide.
- Weak workload attestation: a workload that proves identity with a shared secret rather than platform attestation can be impersonated by any process that obtains the secret. See the Workload Identity Federation Guide.
The control direction is the same as for people: bind identity to something that cannot be copied (hardware keys, platform attestation, mutual TLS) and keep any copyable credential short-lived. See the Non-Human Identity (NHI) Guide.
Detection
Verification controls stop most spoofing. Detection is for the attempts that get through, or for spoofing done with genuine stolen credentials, where verification succeeds.
- Email: DMARC aggregate reports (rua) show who sends mail as your domain. Unknown sources passing or failing alignment are either shadow senders to fix or spoofing to block.
- Domains and certificates: monitor certificate transparency logs for certificates issued for your names and for lookalikes. See the Certificate Transparency Monitoring Guide for Web Teams.
- Sign-ins: impossible travel, new device and new location for a known account, and token reuse from a different network than the one that obtained it.
- Help desk and finance requests: log every password reset, MFA re-registration and payment detail change with the verification method used, and alert on resets followed quickly by MFA changes.
- Machine identities: a workload credential used from an unexpected network, at an unexpected rate or against resources it never touched before. See the ITDR Guide.
- Signed software: alerts on new root certificates in trust stores and on binaries signed by certificates outside your expected publisher list.
Implementing a spoofing defence programme
- Inventory trusted identity types. Use the identity type table above as a starting list and add your own (partner APIs, IoT devices, AI agents).
- Record the current verification method for each. Mark any identity that is accepted on a claim alone (a From header, a caller's name, a static key).
- Fix the highest-value gaps first. In our experience the quick wins are DMARC moving from p=none to enforcement, phishing-resistant MFA for administrators, and call-back verification for help desk resets and payment changes.
- Pilot in monitor mode. DMARC p=none with reporting, conditional access in report-only mode and certificate pinning in report mode let you measure impact before enforcing.
- Enforce in rings. Move from pilot groups to all users, and from quarantine to reject, with a rollback path (revert the DNS record or policy) documented before each step.
- Replace copyable machine credentials. Move workloads from static keys to federation or mutual TLS, starting with the most privileged.
- Test. Include spoofed sender, help desk pretext and forged token scenarios in red team and phishing simulation work.
Decision guidance
- Small organisations: DMARC enforcement, phishing-resistant MFA for admins and a written call-back rule for resets and payments cover most of the exposure at low cost.
- Large organisations: add certificate transparency monitoring, workload identity federation, help desk identity proofing tooling and identity threat detection.
- Verification versus detection: where a strong verification control exists (DMARC, FIDO2, mTLS), invest there first; detection is the fallback for channels without one, such as voice.
Detection and measurement
- DMARC enforcement: share of sending domains, including parked domains, at p=quarantine or p=reject.
- Phishing-resistant coverage: percentage of privileged accounts using phishing-resistant authenticators only.
- Verified resets: percentage of help desk resets with a recorded out-of-band verification.
- Static machine credentials: number of workloads still authenticating with long-lived static secrets, trended monthly.
- Lookalike response: median time from detection of a lookalike domain or certificate to takedown request.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE CAPEC | CAPEC-151 and children CAPEC-194, CAPEC-195, CAPEC-473, CAPEC-89, CAPEC-98 | The pattern hierarchy |
| CWE | CWE-287 Improper Authentication | The weakness CAPEC links to the pattern |
| MITRE ATT&CK | T1566 Phishing; T1134 Access Token Manipulation; T1553.002 Code Signing; T1606.002 SAML Tokens; T1078 Valid Accounts | Enterprise techniques that implement identity spoofing |
| NIST SP 800-53 Rev. 5 | IA-2, IA-3, IA-8, IA-9, SC-8, SC-23, SI-7 | Authentication of users, devices, services and sessions; integrity of software |
| NIST CSF 2.0 | PR.AA-01; PR.AA-03 | Credential management and authentication of users, services and hardware |
Common failure patterns
- Help desk resets on a claimed identity. The Marks and Spencer 2025 cyberattack began with impersonation of a third-party user; the lesson is to verify identity before any password or MFA reset, including for contractors.
- DMARC parked at p=none. Monitoring without enforcement leaves the domain spoofable indefinitely. Set a date to move to quarantine.
- MFA that can be relayed. One-time codes and push approvals verify a person but not the site they are typing into, so AiTM proxies spoof the site and relay the session. See the AiTM Phishing Guide.
- Machine identity by shared secret. A long-lived key accepted from any network makes every leak a full impersonation.
- Trust stores nobody owns. Unreviewed root certificates on endpoints or in containers let a malicious root sign anything.
Practitioner checklist
- List every identity type your systems accept and record how each is verified.
- Move all sending and parked domains to DMARC enforcement with aggregate reporting.
- Require phishing-resistant authenticators for privileged and remote access.
- Enforce out-of-band verification for password resets, MFA changes and payment detail changes.
- Keep signing keys in HSMs and review trust stores on a schedule.
- Replace static workload secrets with federation, mutual TLS or short-lived tokens.
- Monitor certificate transparency for your domains and lookalikes.
- Alert on machine credentials used from new networks or at unusual rates.
Standards and references
- MITRE CAPEC: Identity Spoofing (CAPEC-151)
- MITRE CWE: Improper Authentication (CWE-287)
- MITRE CAPEC: Content Spoofing (CAPEC-148)
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- IETF: RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Phishing (T1566)
Related NHI Mgmt Group resources: CAPEC-148 Content Spoofing · MITRE CAPEC Guide · Phishing-Resistant MFA Guide · Deepfake and AI Impersonation Guide