SharLdapRealyScan is a tool to check Domain Controllers for LDAP server protections regarding the relay of NTLM authentication, and it's a C# port of LdapRelayScan.
If you're interested in WHY I develped this, check out the relative blog post.
If you're interested in the specifics of the error-based enumeration, see the explaination below.
For details regarding what can be done when you identify a lack of LDAP protections, see the references section.
NOTE: Cube0x0 just released a C#/BOF version of the tool using SASL authentication which works amazingly. Check it out HERE!
Note: DNS needs to resolve properly. If you are routing through SOCKS or running on a non-domain-joined host, ensure this is working.
The tool has two methods, LDAPS (the default), and BOTH. LDAPS only requires a domain controller IP address, because this check can be preformed unauthenticated. The BOTH method will require a username and password or NT hash.
The Active Directory domain is not required, it will be determine via anonymous LDAP bind.
Note: Tested against Windows Server 2016 and Windows Server 2019
SharpLdapRelayScan.exe -d 10.0.0.20 -u domainuser1 -p badpassword2
SharpLdapRelayScan.exe -d 10.0.0.20 -u domainuser1 -p badpassword2 -m LDAPS
DISCLAIMER: The following sections are cloned from https://github.com/zyn3rgy/LdapRelayScan#readme
On a Domain Controller that has been patched since CVE-2017-8563, the capability to enforce LDAPS channel binding has existed. The specific policy is called Domain Controller: LDAP server channel binding token requirements and can be set to either Never, When supported, or Always. This is also not required by default (at the time of writing this).
Decrypting and monitoring LDAP over SSL/TLS traffic on a Domain Controller allowed for the identification of a difference in errors during bind attempts when channel binding is enforced versus when it's not. When attempting a bind to LDAP over SSL/TLS using invalid credentials, you will recieve the expected resultCode 49, and in the error message contents you will see data 52e. However, when channel binding is enforced and the LDAP client does not calculate and include the Channel Binding Token (CBT), the resultCode will still be 49, but the error message contents will contain data 80090346 meaning SEC_E_BAD_BINDINGS or that the client's Supplied Support Provider Interface (SSPI) channel bindings were incorrect.
Note: Mentions of the
data 8009034error during LDAP over SSL/TLS binding [1] [2] [3] [4] [5]
This specific error makes it easy enough to account for when the Domain Controller: LDAP server channel binding token requirements policy is set to Always. Simply attempt an NTLM-based LDAPS bind using a client that does not support channel binding and look for the data 80090346 within the error in response. But what about when the policy is not set to Always, what about when it's set to When supported? The answer is: bind to LDAPS with NTLM-based authentication and purposefully miscalculate the channel binding information.
First, we need an LDAP client that supports channel binding. SkelSec's implementation of this in msldap will be used to implement a PoC. Channel binding appears as an AV_PAIR value during the NTLM challenge/response process, specifically within the Type 3 or AUTHENTICATE_MESSAGE. Here's another look at some decrypted LDAPS traffic on a Domain Controller to see what a bind attempt from a client supporting channel binding will look like:
Intentionally miscalculating this value, when the policy in question is set to When supported, will produce the same data 80090346 error. This gives us the ability to differentiate between all possible settings for this policy as it currently exists, from an unauthenticated perspective.
On a Domain Controller, the policy called Domain Controller: LDAP server signing requirements is set to None, Require signing, or it's just not defined. When not defined, it defaults to not requiring signing (at the time of writing this). The error which identifies this protection as required is when a sicily NTLM or simple bind attempt responds with a resultCode of 8, signifying strongerAuthRequired. This will only occur if credentials during the LDAP bind are validated.
A few invaluable resources for contextualization of this material and how it fits into common attack scenarios.
- @HackAndDo - NTLM relay
- @_nwodtuhs - NTLM relay mindmap
- @_dirkjan - PrivExchange, the ADCS ESC8 write up, the NTLM relay for RBCD write up, and more
- @domchell - implementation of Farmer and explanation
- @elad_shamir - thorough explanations of abusing RBCD in multiple scenarios, and shadow credentials
- @tifkin_ & @topotam77 - NTLM authentication coercion methods
- @skelsec - msldap w/ support for channel binding