THREAT RESEARCH BLOG POST
Detecting Pass-The-Hash with Windows Event Viewer
December 20, 2017 | | Eviatar Gerzi
In this article, we explain how to detect a Pass-The-Hash (PTH) attack using the Windows event viewer and introduce a new open source tool to aid in this detection. PTH is an attack technique that allows an attacker to start lateral movement in the network over the NTLM protocol, without the need for the user password. We evaluated a number of legitimate and illegitimate scenarios for (PTH) NTLM connections to see the differences and how each of these can be distinguished. Based on our findings, CyberArk Labs created a freely available tool (Ketshash) that detects live PTH attempts. (Note: Over-Pass-The-Hash (OPTH) is out of scope in this example, and it can be more accurately detected via other methods.)
Authentication without password
The Windows operating system stores different types of hashes, derived from the user’s password, to allow access to different services without the need to reenter the password. One of those hash types is an MD4 hash of the password also known as the NTLM hash.
The NTLM protocol uses the NT hash for authentication and does not ‘salt’ the password, which in turn means that if one grabs the hash value, authentication can be made without knowing the actual password.
When an NTLM connection takes place, Event ID 4624 (“An account was successfully logged on”) with Logon Type 3 (“A user or computer logged on to this computer from the network”) and Authentication Package NTLM (or by logon process name NtLmSsp) is registered on the target machine. See Figure 1.
Figure 1 – Event ID 4624 with indication for NTLM connection
Malicious actors could also authenticate without a password by passing the hash. When considering PTH, there are two main options:
- Inject the hash to LSASS.exe and open session with the injected hash.
- Implement part of the NTLM protocol for the authentication with the hash and send commands over the network with protocols like SMB, WMI, etc.
The major difference between passing the hash to a legitimate NTLM connection is the use of a password. Searching for legitimate user logons, where the password was used prior to the NTLM connection, can help to filter out all the legitimate logons and leave only the suspicious one.
Legitimate connections from event viewer
Event viewer contains a number of logs that indicate interactive logons:
- 4768 – A Kerberos authentication ticket (TGT) was requested
- 4769 – A Kerberos service ticket (TGS) was requested
- 4648 – A logon was attempted using explicit credentials
- 4624 – An account was successfully logged on
Logon types: 2 (Interactive), 7 (Unlock), 10 (RemoteInteractive) or 11 (CachedInteractive).
Checking that each NTLM connection had an interactive logon with the same account prior to the connection, based on the above logs, can help to distinguish between an attacker using the hash and a normative user using the password.
Some NTLM connections are riskier than others
A logon session created via an NTLM connection with a non-privileged account is less risky than one with a privileged account. For example, Event ID 4672 (“Special privileges assigned to new logon”) let’s us know when a privileged account logs on. Creating correlation between the NTLM connection and event ID 4672, will filter all the privileged NTLM connections that can make changes in the target computer. See Figure 2.
Figure 2 – Correlation between Event ID 4624 and 4672 based on Logon ID
Putting all the pieces together, we can search for privileged NTLM connections and check if they had legitimate logon prior to the NTLM connection by correlating to known good event IDs. To help illustrate how this approach can be effective, we have built a tool (Ketshash) which will demonstrate the above idea.
The demo in the video showcases how this approach (with the help of Ketshash) is effective in detecting PTH attacks utilized by PTH-winexe, Mimikatz, WCE and Invoke-SMBClient. In the coming weeks, we will publish the full research on this approach with all the technical details. Watch this space.
Editor’s note: The research paper referenced above is now available on CyberArk’s website.