Diary Entry #1
Today, I Learned That I Don’t Even Need a Password
What if I told you that, in many cases, the length and complexity of your password is completely irrelevant? That the constant trainings, the ever-increasing minimum length requirement and those little “password strength” meters that tell you just how Strong! your password really is, are entirely useless? To hackers, there might be no difference between “Password123” and that 30-character pass phrase your IT department finally got you to start using. Sad and maybe even scary, isn’t it?
As ethical hackers, we might try to “guess” your password, we might even try to “crack” it if we manage to obtain some encrypted or hashed version of it. But honestly, we’d really rather not. Password guessing and password cracking rely on luck and historically, I’m not a very lucky guy. The good news (for hackers, that is) is that unless your organization has configured each and every system on your network securely, we might not have to do any of that.
In a traditional Microsoft-based environment with Active Directory, Windows servers and Windows endpoints, there are multiple ways an attacker might be able to simply “relay” that hash to another system on the network. This would allow them to authenticate on behalf of the account whose credentials were relayed, without ever having known the password. In principle, the following attack techniques work regardless of whether the password hash belongs to a user or a computer account. We need to understand the service over which we obtained the password hash, as well as the service to which the password hash will be relayed. Let’s start with the most common instances we see and then dive into an edge case from a genuine PKFOD penetration test.
Note: this technique should not be confused with a “pass-the-hash” attack. Here, we are relaying network-level NTLM authentication (i.e., NetNTLMv1 or v2) while a “pass-the-hash” attack uses a plain old NTLM password hash to authenticate instead of a password. NTLM is the format of password hashes as they are stored on disk within a Windows operating system.
Credential Relay Basics
The typical services over which network password hashes are obtained are SMB and HTTP, depending on the technique. This is true for user account hashes via standard techniques like IPv6 and name resolution protocol abuse, as well as for direct authentication coercion against a target computer. Now, the most important thing is understanding where these credentials can be relayed to and under what conditions.
This is nowhere near a complete list of all relay targets and conditions and specifics of each scenario (including other scenarios like relays Active Directory Certificate Services) will be covered in future entries. But overall, this means that if the conditions for a given relay are met, attackers can simply send NetNTLMv2 hashes gathered via any technique to the appropriate service on a different system and authenticate on behalf of the relayed account. No need to crack passwords!
The impact of a successful relay attack is entirely dependent on the service to which the credentials were relayed and the permissions of the relayed account. However, access to any system or service in an authenticated context can lead to information disclosure at a minimum and code execution or complete system/network compromise in a worst (best?) case scenario.
Here is a quick example of one of the most common methods to obtain and relay a user’s account credentials. We can start with a tool like Responder, which is capable of abusing multicast name resolution protocols and we wait for a user’s endpoint to make a specific abusable request. The details of what is actually going on here are outside the scope of this specific entry, but it ultimately makes the system we are interacting with send the logged-in user’s account credentials back to us.
Now, we have two options. We can try to crack this password hash and get the user’s plaintext password, or we can try and relay it to another service on the network. Technically speaking, we can (and should) try both. Since we can see this password hash came over the HTTP protocol, we can reference the table above to determine our potential relay targets and the circumstances surrounding that technique.
In this test environment, LDAP signing is disabled (the default setting). That means we can relay this user account hash to the LDAP service on one of the domain controllers. Executing the attack again leveraging NTLMRelayX to conduct a relay attack results in the successful authentication to the LDAP service as the PKFOD.local\PKFOD user account and we still don’t know their password! An authenticated LDAP session like the shown below can lead to significant information disclosure almost always and complete domain compromise if the relayed user or computer account is highly privileged.
A Relay Edge Case
The PKFOD ethical hacking team recently found themselves in a unique situation on a client penetration test. A highly privileged account (domain administrator) was periodically authenticating directly to our penetration testing device via PowerShell. It was later attributed to a poorly configured network scanner that was trying to log into every system on the network (even untrusted systems).
Penetration testers and hackers alike often stand on the shoulders of giants and the broader open-source community when it comes to tool development. But in this case, there was no readily available tool to perform relay attacks against the Windows Remote Management protocol (WinRM i.e., PowerShell remoting). Because we already knew that LDAP signing on the domain controller was disabled, this unsolicited authentication was a significant vulnerability in the client’s environment. The team was determined to demonstrate the risk associated with this weakness. But with no readily available tools to deploy for exploitation, what was a hacker to do?
Well, after a little research into WinRM, it turns out that this is essentially an HTTP-based protocol. What if we just treated this authentication like any other HTTP authentication? This would only require us to somehow force this authentication to a local port on our penetration testing device where NTLMRelayX was already listening, rather than the standard WinRM port (5985). Port forwarding to the rescue!
A simple local port forwarding configuration would allow us to take that WinRM-based authentication and forward it to local port 445, where NTLMRelayX was already listening for inbound connections.
Then, we waited for the next network scan to run and let NTLMRelayX handle the rest.
As noted above, the team was able to successfully capture this WinRM based authentication, forward it to a port where NTLMRelayX was listening and relay those credentials to the LDAP service on the organization’s domain controller. Because this was a highly privileged account, we let NTLMRelayX create us a new user account on the domain with elevated privileges. This attack vector, with a little bit of ingenuity, resulted in complete domain compromise without ever knowing a single password.
What to Do Next
To eliminate the risk associated with this type of attack vector, it’s critical that organizations eliminate relay targets across their infrastructure. In the context of the techniques outlined here, that means:
- Enable and enforce SMB signing on all systems with exposed SMB services. This will eliminate the ability for an attacker to relay any credentials to SMB.
- Enable LDAP signing and LDAPS channel binding on all domain controllers. This will eliminate the ability for an attacker to relay any credentials to LDAP services.
And you’d be surprised how often we find network scanning tools simply giving us credentials on client penetration tests. If you’ve got a vulnerability scanner or other network enumeration tool that is configured to authenticate to every system on your network, you should probably stop doing that. Instead, configure those systems to scan only known and trusted hosts to prevent accidentally giving away privileged access to your network.
Do these attack vectors exist in the environment you are testing or defending, right now?