CAPEC-90 Reflection Attack in Authentication Protocol: How the Attack Pattern Works and How to Defend

A reflection attack lets an adversary pass a challenge-response login without ever holding the key, by tricking the server into answering its own challenge. MITRE CAPEC catalogues it as CAPEC-90, a Standard-level pattern rated High for both likelihood and severity, and ties it to two weaknesses: CWE-301 (Reflection Attack in an Authentication Protocol) and CWE-303 (Incorrect Implementation of Authentication Algorithm). The pattern sounds academic, but it keeps returning: in Windows NTLM and Kerberos relays back to the originating host, in TLS 1.3 deployments that share one external pre-shared key across a group, and in device and service fleets that authenticate with a single shared secret. This guide is for protocol designers, application security engineers and identity architects who build or review machine-to-machine authentication. It explains the mechanism at a defensive level, how to spot protocols that are exposed, how to fix them, and how to detect attempts. For the catalogue itself and how CAPEC entries are structured, see the MITRE CAPEC Guide.

Key takeaways

• The root cause is symmetry. If initiator and responder use the same key and the same response format, a response produced in one role is valid in the other, and the server can be made to compute it.
• Three design fixes close the class. CAPEC-90 lists them: the server issues the challenge first, the response binds both challenges with an HMAC, and every connection carries a fresh nonce. CWE-301 adds distinct keys or challenge types per direction.
• Identity binding matters as much as cryptography. A response must say who produced it and for whom, otherwise a group key only proves group membership, the point RFC 9257 makes about the TLS 1.3 Selfie attack.
• Windows reflection is a live variant. NTLM reflection was patched path by path from MS08-068 in 2008 onwards, and the June 2025 reflective Kerberos relay (CVE-2025-33073) is in the CISA KEV catalogue. Enforced SMB signing breaks the relay step.
• Shared secrets across non-human identities are the main exposure. Fleets of devices, services or VPN peers sharing one key are exactly the condition CAPEC-90 needs, so per-identity credentials are the durable fix.

How the attack pattern works

CAPEC-90 describes an adversary who abuses an authentication protocol that is susceptible to reflection, gaining access "without possessing the requisite credentials". The precondition in the CAPEC entry is a handshake in which the client initiates and the server will compute a keyed response to whatever challenge it is sent. The flow, as CAPEC describes it, has three phases:

1. Explore: the adversary looks for a handshake where the client sends the first challenge, so that the server will encrypt or sign attacker-chosen data with the shared key.
2. Experiment: the adversary opens connection one with an arbitrary challenge. The server returns a keyed response plus its own challenge, C. The adversary cannot answer C, so it opens connection two and sends C as its own opening challenge. The server, seeing a fresh session, dutifully returns C processed with the shared key.
3. Exploit: the adversary returns that value on connection one. Because the server uses the same key for both roles, it accepts the response and authenticates the adversary.

The CAPEC entry notes the adversary needs direct access to the target, and that an intermediary such as a proxy which handles the exchange on the client's behalf gets in the way. Skills required are rated Medium: the adversary needs to understand the exchange and manage two concurrent connections, not break any cryptography. The consequences listed are gaining privileges, bypassing protection mechanisms and reading data. CAPEC places the pattern as a child of CAPEC-114 Authentication Abuse and CAPEC-272 Protocol Manipulation.

The CAPEC example is a single sign-on system that uses a fixed pre-shared key with its clients to protect the opening exchange; a reflection attack lets an attacker pose as a trusted client. The general lesson is that encryption of the challenge is not the same as authentication of a party.

Reflection compared with related patterns

Reflection is often confused with replay and relay. The distinctions matter because the fixes differ.

Where reflection shows up in real systems

Windows NTLM and Kerberos

Microsoft bulletin MS08-068 (November 2008) addressed an SMB credential reflection issue: when a user connected to an attacker's SMB server, the attacker could replay the user's NTLM credentials back to the user's own machine. The bulletin states that SMB did not correctly opt in to NTLM credential reflection protections, and the update changed how SMB authentication replies are validated. Its listed workarounds were blocking TCP 139 and 445 at the perimeter or enabling SMB signing. Analysis by Synacktiv notes that Microsoft then closed further reflection paths one at a time (HTTP to SMB, DCOM to DCOM) rather than the whole class.

CVE-2025-33073, a Windows SMB client elevation of privilege flaw disclosed in June 2025 and described by researchers as a reflective Kerberos relay, which let a low-privileged domain user reach SYSTEM on domain-joined hosts that did not require SMB signing for incoming connections. Microsoft released fixes in its June 2025 security updates, and CISA added the CVE to the Known Exploited Vulnerabilities catalogue on 20 October 2025. Researchers who analysed the flaw reported that enforcing SMB signing prevents exploitation. Practical steps are in the SMB Signing Guide and the NTLM Deprecation and Elimination Guide.

TLS 1.3 with shared external PSKs

RFC 9257 (Informational, July 2022) describes the Selfie attack in section 4.1 as a special case of a rerouting, identity misbinding attack. When a group of nodes shares one external PSK and each node acts as both client and server, an attacker can reroute a node's outbound connection back to the same node's server role. The RFC's diagnosis is that a shared PSK lets TLS authenticate only group membership, not a specific peer. Mitigations it gives: check that the SNI matches the node's own identity (partial), put globally unique node identifiers in the RFC 9258 ImportedIdentity context and compare them with the expected peer, exchange identifiers after the handshake, and otherwise restrict a PSK to two logical nodes, one per role. See the How TLS Works Guide for the handshake background.

Home-grown and embedded protocols

The pattern reappears in custom device pairing, licence checks, industrial controllers and service-to-service handshakes that encrypt a nonce with one fleet key. These are rarely written by cryptographers and rarely reviewed, which is why CWE-303 (an incorrect implementation of an otherwise sound authentication algorithm) sits beside CWE-301 in the CAPEC entry.

Spotting an exposed protocol in review

Use these questions in design review or threat modelling. Any "yes" in the first column needs a fix before release.

For a structured way to run these questions, see the Threat Modelling Guide.

How to fix and harden

CAPEC-90 lists three mitigations: the server initiates by issuing the challenge; the response is an HMAC over the client's challenge, the server's challenge and the pre-shared secret, so only a key holder can combine them; and a random nonce is introduced on every connection. CWE-301 adds two design rules: use different keys or a different challenge type for initiator and responder, and let the initiator prove its identity before going further. A practical order of work:

1. Inventory the handshakes. List every protocol where a shared symmetric secret authenticates a peer: internal service calls, device enrolment, VPN peers, licence servers, legacy NTLM paths. Record who initiates and how many parties hold each key.
2. Prefer standard protocols. Replace custom challenge-response with TLS 1.3 using certificates (mutual TLS) or a vetted protocol. TLS 1.3 derives separate client and server traffic secrets and produces role-specific Finished messages, which removes the symmetry reflection depends on. See the mTLS Guide.
3. Where a custom protocol must stay, change the message format. Add a direction label and both party identifiers into the MAC input, cover both nonces, and derive per-direction keys from the shared secret.
4. Break up group keys. Move from one fleet secret to per-identity credentials. For workloads this means issued identities such as SPIFFE SVIDs or cloud workload identity federation, see the SPIFFE and SPIRE Guide.
5. On Windows estates, enforce signing. Require SMB signing on servers and clients and LDAP signing and channel binding, after auditing compatibility, and apply vendor security updates promptly.
6. Test before rollout. Add negative tests that open two concurrent sessions and feed one session's challenge into the other; the second must fail. Run them in CI for every protocol change, and roll back by keeping the old handshake version behind a feature flag until clients have moved.

Choosing between fixes

• Small teams: do not patch a custom protocol; replace it with mutual TLS and per-service certificates, which removes the class rather than one instance.
• Large or constrained estates: where devices cannot run TLS, the minimum we recommend at NHI Mgmt Group is per-device keys plus a MAC over both nonces, both identities and a direction label, with the server challenging first.
• Shared PSK groups you cannot split yet: apply the RFC 9257 identifier checks as a stopgap and set a date to retire the group key.

Where identity fits

Reflection is a non-human identity problem more often than a human one. Pre-shared keys between services, VPN peers configured with one site key, IoT fleets provisioned with a single secret, and service accounts whose NTLM authentication can be coerced are all machine identities whose secret proves only "one of us". The durable fix is unique, short-lived, verifiable credentials per workload. See the Workload Identity Federation Guide and the IPsec Security Guide for VPN peer authentication.

Detection and measurement

Reflection rarely leaves a dedicated log line, so detection relies on its side effects: two near-simultaneous sessions from one source where the second session's opening challenge equals a value the server just issued, and authentications that loop back to the host that originated them.

• Protocol logs: in custom services, log issued server challenges (hashed) and alert when a received client challenge matches a recently issued server challenge. This check is cheap and specific.
• Windows: network logons (event 4624, logon type 3) where the source address is the target host itself or loopback, for accounts that are not expected to do that, deserve review alongside coercion signals described in the MITRE ATT&CK T1557.001 Adversary-in-the-Middle guide.
• Network: paired short-lived sessions to the same service from one peer, where one is abandoned mid-handshake.

Metrics that show progress:

1. Percentage of inventoried handshakes that use per-identity credentials rather than group secrets.
2. Number of custom challenge-response protocols remaining, with a retirement date for each.
3. Percentage of Windows servers and clients with SMB signing required.
4. Reflection negative tests present in CI for each in-house protocol (target 100 percent).
5. Mean time to apply vendor fixes for authentication protocol issues listed in CISA KEV.

Framework mapping

Common failure patterns

• Encrypting a nonce and calling it authentication. Encryption with a shared key proves nothing about which party did it.
• One key for the whole fleet. Every device or service can impersonate every other, and reflection becomes trivial.
• Symmetric message formats. Identical request and response structures with no role label let a response cross roles.
• Fixing one path at a time. As the Windows history shows, closing one reflection route leaves others; remove the shared condition (enforce signing, split keys) instead.
• Signing in audit mode for ever. SMB or LDAP signing left at "if the client agrees" does not stop reflective relays.

Practitioner checklist

• Inventory every handshake that authenticates a peer with a shared symmetric secret, and record who initiates.
• Make the server issue the first challenge in any in-house protocol.
• Compute responses as an HMAC over both nonces, both identities and a direction label.
• Use distinct keys per direction, or derive them with role-specific labels.
• Replace group secrets with per-identity credentials or mutual TLS certificates.
• Apply RFC 9257 identifier checks wherever a TLS external PSK is shared.
• Require SMB signing and LDAP signing on Windows estates and apply vendor security updates promptly.
• Add a two-session reflection negative test to CI for every in-house protocol.
• Alert on received challenges that match recently issued server challenges.

Standards and references

• MITRE CAPEC: CAPEC-90 Reflection Attack in Authentication Protocol
• MITRE CWE: CWE-301 Reflection Attack in an Authentication Protocol
• MITRE CWE: CWE-303 Incorrect Implementation of Authentication Algorithm
• IETF: RFC 9257 Guidance for External Pre-Shared Key (PSK) Usage in TLS
• Microsoft: Security Bulletin MS08-068
• CISA: Known Exploited Vulnerabilities Catalog
• Microsoft Security Response Center: CVE-2025-33073
• NIST NVD: CVE-2025-33073

Related NHI Mgmt Group resources: MITRE CAPEC Guide · NTLM Relay Guide · SMB Signing Guide · mTLS Guide