Pass-the-hash attacks exploiting Windows operating systems aren’t anything new, in fact they’ve been around for donkey’s years; however, despite the exploit being nearly two decades old, still not much is known about the attack vector. So, in this post, I’ll cover what a Pass-the-hash (PtH) attack is, some of the resources for mitigation and how you can use your LogRhythm SIEM to detect PtH resultant lateral movement from machine to machine.
But, first of all, what the heck is a PtH attack? Well, let’s imagine a fun fair but not just any fun fair. At this particular fun fair proprietors are really concerned about their ride security and can only go on rides they’re authorized to ride on. The whole authentication mechanism for each ride starts at the entrance, on their way in they present their two sets of ID and, in return, they’re given a scrambled token comprising the two IDs. So far, so good. Now they’ve got their token they look forward with glee to accessing all the rides of the fair, merrily presenting it for validation to each individual resource; however, a problem occurs in that everywhere an individual uses their token, a copy gets left behind at the ride stall. Even worse, the token is not a one-time use it will last all night. What if some unscrupulous person were to get a copy of a proprietors token? This person could access all the fun of the fair, hopping from ride to ride without true authorization and even start gathering even more tokens!
And that is my highly untechnical analogy for PtH attacks; however, fortunately for all of us there are highly technical people on the interwebs including cleverer people who can explain PtH in far more technical terms—here’s Microsoft’s description on the whole PtH matter:
The Pass-the-Hash (PtH) attack and other credential theft and reuse types of attack use an iterative two stage process. First, an attacker must obtain local administrative access on at least one computer. Second, the attacker attempts to increase access to other computers on the network by:
- Stealing one or more authentication credentials (user name and password or password hash belonging to other accounts) from the compromised computer.
- Reusing the stolen credentials to access other computer systems and services.
This sequence is often repeated multiple times during an actual attack to progressively increase the level of access that an attacker has to an environment.
Well, there you go. Scary stuff! This type of attack was first discovered in ’97 by Paul Ashton. ’97—the good old days—the days when you could leave your digital door unlocked with the key in the door and allow your neighbors in without fear. But it’s not the good ‘ol times anymore, the lack of a salted NTLM hashed password value ultimately means you don’t need to crack a password in Windows, all you need to do is simply dump the hashed value from memory and pass that to a remote system.
Fortunately there are mitigations, lots of mitigations and best practices which should be adopted as mandatory in an enterprise. These vary in detail, such as disabling NTLM and going pure Kerberos (which is open to Pass the Ticket attacks, but that’s another blog post) or rebooting systems when you’ve accessed them with privileged credentials, etc… In fact there’s a 80 page document from Microsoft on the topic of mitigation. 80 pages! Odds are, most companies will be vulnerable to this exploit in some manner. Now even everyone’s favorite three lettered initialism of a security agency—the NSA—has a fantastic document on Windows Event log collection including a section on detecting PtH from log data (and yes, the posts finally going somewhere SIEM related!).
To quote section 4.15:
The successful use of PtH for lateral movement between workstations would trigger event ID 4624, with an event level of Information, from the security log. This behavior would be a LogonType of 3 using NTLM authentication where it is not a domain logon and not the ANONYMOUS LOGON account.
A failed logon attempt when trying to move laterally using PtH would trigger an event ID 4625. This would have a LogonType of 3 using NTLM authentication where it is not a domain logon and not the ANONYMOUS LOGON account.
That’s mildly interesting! We can easily take that information and create LogRhythm SIEM correlation rules around these activities and give them a whirl. Here’s our Correlation rule to detect successful PtH attacks. We’re using a LogRhythm list of valid Domains we’d expect to see authentication activities from.
But first… what do these hashes actually look like? Well, Blue Peter style, here are some I prepared earlier from our compromised host (not real hashes by the way, they’ve been altered as to not put passwords out on the internet!):
Now amongst the list, is our test account appropriately named – “christest”
Let’s show an example of using the above hash to authenticate to another system on the network where we don’t know the password (and can hopefully get some more hashes!).
Well, that went well. But what actually just happened? Using the hash value extracted from memory on our first compromised host we then successfully authenticated to another server in the network without ever knowing the underlying password.
SmartResponse Alarm Indicating Successful PtH Attempt
So let’s try the same out for a failed PtH attempt:
SmartResponse Alarm Indicating Failed PtH Attempt
Now one question you may be asking—why did the above example fail? There could be several reasons, such as the local account we’re trying to access via a remote machine doesn’t exist, it has a different password (hence different hash), perhaps they’re running Windows 8/2012 on-wards, maybe the destination system has installed KB2871997 (which is a good thing to do), or someone couldn’t use metasploit properly. Either way it’s all interesting to know about.
And there we have it. A brief overview of how you can start to use log data to detect activities that could otherwise be extremely difficult to detect. I’d highly encourage you to read up on pass-the-hash detection, pass-the-ticket mitigation and golden ticket attacks. These attack vectors aren’t as well known to most folks but are frequently used by malicious actors, APT and even by penetration testers. As always. defense in depth layers should help pick up hashdump utilities but prevention eventually fails so detection is key.