Back in December of 2013, the NSA released a paper titled “Spotting the Adversary with Windows Event Log Monitoring” (http://1.usa.gov/1q6t5WV). This is a great paper with a lot of resources about finding attackers using Windows Event Log analysis techniques. On page 32 of the NSA paper, it discusses detecting “Pass the Hash” (PTH) through network logs. This type of attack is difficult to detect using traditional IDS/IPS, but is sometimes detectable via log analysis. I’ll get into the reason why it is “sometimes” detectable later.
Once a network has been compromised, it is common for an attacker to use PTH to gain access to other resources within a network.
The technique works like this: When a normal Windows user logs into the network, the password that the user enters is never sent “in the clear” over the wire. Instead, the user is prompted to enter the clear text password and Windows makes an API call to convert the password into a “hash”. The “hash” is then sent to the domain controller as part of a challenge/response during authentication. This means that technically, the attacker does not need the user’s clear-text password, but can use the “hash” as a means to authenticate. After a machine is compromised, an attacker can harvest “hashes” using several different methods. For example, by dumping the local SAM database, collecting “hashes” via packet sniffing, and dumping “hashes” that are in the memory of the compromised system. To the attacker, the “hashes” are just as valuable as the “clear-text” passwords and typically leads to privilege escalation for the attacker. This technique is also difficult to defend against due to the nature of Microsoft Windows authentication. To help defend against such attacks, you can disable Windows credential cache storing, disallow administrators from logging into possibly compromised machines, etc. More information can be found at: http://en.wikipedia.org/wiki/Pass_the_hash since defending against PTH attacks is outside of the scope of this blog posting. Instead, we want to detect, in real time, when a PTH attack occurs.
Although the NSA paper is very good, like other papers that cover log analysis, it mainly focuses on detecting PTH “after” the event took place. The idea is that you go through your logs at a certain point in time (Daily? Weekly? Monthly?) and apply these techniques to see if a PTH attack happened within your network, which in itself is the problem. If I detect a PTH attack 24 hours or more after the event took place, the attacker might have already obtained what they wanted. There is also the possibility, since we don’t know what the attacker is doing, that they are now deeper into the network than we might realize.
To address this, we attempt to detect PTH attacks in real time. The key to detecting these events in real time is the following rule:
alert syslog $HOME_NET any -> $EXTERNAL_NET any (msg: “[WINDOWS-AUTH] Pass-The-Hash detected!”; pcre: “/ 4624: | 4625: /”; content: “Logon Type|3a| 3 “; content: “Authentication Package|3a| NTLM “; content:!”ANONYMOUS LOGON”; meta_content:!”Domain|3a| “,$WINDOWS_DOMAINS; meta_nocase; program: Security|Security-Auditing; parse_src_ip: 1; classtype: successful-user; reference: url,wiki.quadrantsec.com/bin/view/Main/5002017; reference: url, http://en.wikipedia.org/wiki/Pass_the_hash; sid: 5002017; rev:2;)
The way this rule functions is exactly as described on page 32 of the NSA’s “Spotting the Adversary with Windows Event Log Monitoring”. The “pcre” (Perl Compatible Regular Expressions) looks for Windows event IDs 4624 and 4625. Windows event ID 4624 means “An account was successfully logged on”. Windows event ID 4625 means “An account failed to log on”. We monitor for both in order to detect both successful and unsuccessful “pass the hash” attempts. The “program” field lets Sagan only analyze Windows events from “Security” or “Security-Auditing”. Sagan monitors for only interactive logins by looking for “Logon: 3 “. Sagan also monitors for the authentication method/package “NTLM” and makes sure that the login is not related to an “anonymous” logon. The “meta_content” allows Sagan to make sure the “Domain” is not related to a real, local domain. This means that in order for this rule to function properly, you will need to populate the $WINDOWS_DOMAINS variables via the sagan.conf with your valid Windows domains. The “parse_src_ip” sets the “source” of the attack’s IP address.
This type of PTH detection has been outlined in not only the NSA “Spotting the Adversary with Windows Event Log Monitoring”, but also in various other white papers as well. It is true that as long as the attack falls within the criteria of this rule, it will be detected.
At Quadrant, back when we were discussing and experimenting with this rule, a fairly obvious question came up: Does the attacker have to specify a fake or false Windows domain? The meta_content:!”Domain: “, $WINDOWS_DOMAINS; does the brunt of the detection. This meta_content detects when the Windows Domain is not something you would expect in your environment.
The logical question is: is there a technical reason the attacker would set the Windows Domain to something not used locally?
The answer is, unfortunately, no, which means that if the attacker’s PTH is using a valid Windows Domain, this rule will not trigger. This is not a Sagan issue; if you follow the advice from the NSA “Spotting the Adversary with Windows Event Log Monitoring” or the countless other white papers, a pass the hash attack with a valid Windows Domain will NOT be detected.
If a valid Windows Domain is used, then the Windows event will look exactly like a valid login. One “valid login” event will be indistinguishable as a “pass the hash” event!
We noticed in our research, that tools like “Metasploit” do not allow you to set the Windows Domain in a PTH attack, which means that if an attacker, or penetration tester, uses Metasploit to PTH, Sagan will detect it in real time using this example rule.
However, if an attacker uses the “Pass the hash toolkit” which allows you to manually set the Windows Domain, the Sagan rule and the entire PTH detection technique will fail!
This technique might detect an attacker who simply neglects to properly set the Windows Domain or when certain tools are used during a PTH attack.
As we always hear; security is accomplished through layers. If an attacker has made it to the point where they are attempting PTH attacks, you are already in trouble! While this technique and rule might help, detection and mitigation before an attack gets to this level is critical.