Every week, Content Security is engaged to do Internal Penetration Tests. We go in and find ourselves on a totally unknown network, usually with thousands of hosts and think, “Where do I even start?”. Of course, we first do the usual port scanning and host enumeration. However, a key part of this initial process is to find a way to get valid Domain usernames as they can be used later for a Password Spray attack as a potential entry point.
Connecting to SMB with a null session is one of the first things we try, but this is getting less and less likely to succeed. What else do we have? Open shares? SNMP? Printers? All valid potentials, but not very reliable. What else could we try? Hey how about NTLM Relay!
Background of NTLM Relay
NTLM Relay (previous known as SMB Relay) is not a new attack. It has been given substantial research time and has been heavily explored. For example HERE and HERE in recent times. However, the earliest known instance of a practical SMB Relay attack was back in 2001, 17 years ago! Originally only used against the SMB protocol, researchers discovered that anything that uses NTLM for authentication (HTTP, MSSQL, LDAP, etc…) could be susceptible. Hence the name was changed to “NTLM Relay”.
For details of how NTLM Relay works the articles above describe it quite well, but the gist of it is this:
- An attacker, “Alice”, wants access to a target server. She wants to use NTLM Relay to do this, so she spins up a special SMB service on her machine.
- Alice then tricks a victim, “Vicky”, into connecting to Alice’s SMB service (maybe through phishing or Name Poisoning).
- Vicky’s machine sends a connection request to Alice; and Alice passes that connection request to the target server.
- The target server replies with a random challenge string (called a nonce) back to Alice. Alice passes that nonce to Vicky.
- Vicky’s machine will encrypt that nonce with her password (NTLM) hash and sends that response to Alice.
- Alice passes that response to the target server and closes the connection with Vicky.
- Since Vicky’s account is a Domain account and the target server is joined to that Domain, the target server accepts the authentication as valid!
- Alice now has an authenticated connection with the target server, with the context of Vicky’s privileges.
At this stage, if Vicky was an admin of the target server, Alice could send commands and compromise the server completely.
Microsoft has acknowledged this is a problem and has release patches (MS08-068) to try and mitigate this vulnerability. But unfortunately, the main solution, SMB Signing, remains disabled by default on most Windows hosts (more on this later). This allows us, as attackers, to continue using NTLM Relay.
Even Low Privileges Are Helpful
At this point, you might be thinking, “How does this help me get usernames?” . Well, even with a low privilege Domain account we can query for a lot of useful Active Directory information. We can obtain Domain usernames, groups, group memberships, password policy and more! This data can be used to know who has elevated privileges and where as well as knowing how many login attempts we can make without locking accounts.
So, if we’re using NTLM Relay and a user connects to us, we can relay that connection and request usernames from a target server. Some things to note:
- The user that connects to us does not have to be an admin. Any valid Domain account will work;
- The server we are relaying to must have SMB Signing disabled. We can get the status of “SMB Signing” without any authentication (using CrackMapExec, for example);
- The server we relay to does not have to be the Domain Controller, but does have to be a Domain member if we want Domain usernames.
Provided the above requirements are met, this attack should work!
Introducing : RidRelay
To install it, follow the instructions in the URL above and run the following command to start RidRelay (replacing the IP with the target server IP):
|python ridrelay.py -t 10.0.0.50|
At this point, RidRelay will wait for an incoming SMB connection on port 445. Once it has that connection, it will perform the attack described above and return a list of Domain usernames and the password policy.
How do we get that connection in the first place? That question is a bit out of scope for this post, but here are some suggestions:
- LLMNR / NBNS Poisoning using Responder;
- Adding a SCF file to an SMB Share as described HERE;
- Using a previously compromised MSSQL instance and executing the xp_fileexist or xp_dirtree stored procedure targeting the RidRelay server.
Of course, if you find a bug in RidRelay please let me know either at my github page or on Twitter (@skorov8)
If you’re a defender, there are multiple things you can do to protect against this attack.
Firstly, make sure “SMB Signing” is enabled for ALL machines on the Domain. This must include workstations. You can apply this through group policy by enabling it in the following location:
|Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (always)|
Secondly, it is highly recommended to disable SMB version 1. This should already be disabled by default on Windows 10 and Server 2016 operating systems. As for the rest, follow the instructions in THIS very nice, detailed Microsoft post.
Keep in mind that the above two mitigations might break access to old SMB servers (such as some NAS devices), but highly worth the trade-off to fix this vulnerability.