Wilfried Becard lightning talk: Playing with reflective relay to discover new vulnerabilities.

### Overview In this lightning talk, Wilfried Becard presents a vulnerability discovered in March while researching Kerberos relaying and reflective relaying techniques. While attempting to relay a machine back to itself, Becard observed unexpected behavior involving NTLM fallback and privileged local authentication, which allowed reflective relaying leading to full machine compromise. The vulnerability was patched by Microsoft just three days prior to the presentation.

### Key Topics - **Reflective Relaying Research**: Testing Kerberos relaying primitives originally documented by James Forshaw, which rely on registering specially formatted DNS records containing a marshaled target structure. - **Authentication Protocol Fallback**: Investigating unexpected NTLM negotiation when coercing machine authentication using hostnames rather than IP addresses. - **Reverse Engineering LSASS**: Analyzing the DLLs loaded by the Local Security Authority Subsystem Service (LSASS) using IDA to understand how target names and local authentication checks are evaluated. - **Local Token Handling & Privilege**: Dissecting why the reflected authentication succeeds with SYSTEM privileges. - **Impact, Mitigations, and Patching**: How attackers could exploit this across domains where SMB signing is not enforced, and Microsoft's fix.

### Technical Details Becard began by testing Kerberos relaying using a technique demonstrated by James Forshaw, which involves creating a DNS record prefixed with the target hostname followed by a marshaled structure. Reflective relaying directly back to the same machine was previously believed not to work. However, when forcing authentication to a controlled host using hostnames, an error occurred indicating an unsupported MIC type because NTLM was being used instead of Kerberos.

Analyzing network captures with Wireshark and reverse engineering the DLLs loaded by LSASS (with assistance from colleague Yom) revealed the underlying execution path: 1. The SMB client initiates authentication by calling `InitializeSecurityContextW`. 2. The target name is passed in the format of the service name followed by the target hostname and the marshaled structure. 3. The function `CheckMarshaledTargetInfo` (or `check martial target info`) removes the marshaled structure, leaving the target name as the service name followed by the target hostname (e.g., `server1`). 4. LSASS verifies whether authentication originates from the local host by checking if the target matches the machine's hostname, fully qualified domain name (FQDN), or the string `localhost`. 5. Because the unmarshaled record matched the server's local hostname, the authentication was accepted as a valid local authentication. 6. For local authentication, LSASS includes the client token in the NTLM message. Since LSASS operates with SYSTEM privileges, a SYSTEM token was embedded. When forwarded to the server portion of LSASS, this token was extracted and utilized, granting privileged access (such as dumping registry hives).

Exploitation required adding a marshaled `localhost` DNS record—an action permitted to standard domain users by default in Active Directory—and coercing target machines where SMB signing was not enforced. The talk also notes that the vulnerability worked with the Kerberos protocol as well.

### Takeaways - **Enforcing SMB Signing**: Enforcing SMB signing blocks this attack and remains an important defensive measure against relay-based vulnerabilities. - **Microsoft Patch**: Microsoft released a security patch that checks whether the target name contains a marshaled structure on the client side; if present, authentication is halted. Consequently, this fix also breaks the Kerberos relay primitive discovered by James Forshaw. - **Research Mindset**: Becard emphasizes testing boundaries, investigating unexpected error messages, and digging deeper into unexpected authentication outcomes.