PRIMARY CATEGORY → KERBEROS
Components ⟡
Theory
This attack vector usually stands out or appears on AD Enviroments where NTLM Relay cannot be performed due to the following scenarios →
- NTLM Authentication disabled on the Target Server (e.g. ADCS HTTP Server)
- Some Relay Protection measures (e.g. Session Signing, MIC or Channel Binding) applied on the Target Server
It should be noted that, whether over SMB, HTTP or DNS, Kerberos Authentication that receives the Relay Server (Attacker), can only be relayed (at the time) to an HTTP endpoint that does not require Session Signing if the client supports it (e.g. ADCS HTTP)
That is, an attacker cannot perform a cross-protocol relay by relaying a Kerberos Authentication over SMB/HTTP/DNS to an LDAP server (e.g. DC ) in order to carry out actions such as adding a computer account (LDAPS required), enabling RBCD on the service account itself, or performing a Shadow Credentials attack. The latter is only feasible if the authentication principal is a Computer Account and its msDS-KeyCredentialLink attribute is empty (if not, flushing is required)
This is because, by default, any LDAP Server running on a domain-joined Windows machine (e.g. any DC) requires Session Packets to be signed during a client-server communication if the client enables/supports signing, which is always the case with HTTP and SMB Windows clients that use the Kerberos SSP/mechanism for the authentication
Zoom In
The Negotiate Signing value ensures that, after a succesfull authentication, the subsequent network packets must be signed with a key derived from the principal’s secret key if the client supports/enables signing
So, as mentioned, both clients (HTTP and SMB), supports