A common technique to leverage once a user's credentials have been harvested is passing the hash; how does that differ from "overpassing the hash?" What are some considerations to have from the defender and attacker perspectives? Read on to find out.
What is a hash?
A hash is the encrypted version of a user's password. Depending on the environment and on the authentication protocols being used, it may be stored using NTLM hashing and/or AES256 encryption.
Hashes can be collected if an attacker is able to use a tool such as Mimikatz with the sekurlsa module on an endpoint.
What is pass the hash?
Passing the hash is as straightforward as it sounds. The attacker "passes" the hash to a remote server for the purposes of authentication. This allows the attacker to impersonate that user within the target environment and does not require hash cracking/clear text credentials. Again, one could use the ever-versatile Mimikatz tool to execute this type of attack.
What is overpass the hash?
Overpassing the hash is a little more complicated in the sense of what's happening behind the scenes. When performing an overpass the hash attack, the attacker is leveraging the target user's compromised credentials to request a ticket granting ticket (TGT) from the Kerberos Domain Controller (KDC). The TGT can then be used to request access to other services on the domain. You can also access any machine on the domain where the compromised user's account has privileges.
Tools that can execute this type of attack are Mimikatz and Rubeus.
Which one should I use when?
Passing the hash is only viable in networks using NTLM authentication as a protocol. Overpassing the hash is useful in networks where Kerberos is the only authentication protocol being used.
From the defender perspective...
Disable NTLM authentication in your environment if at all possible. Kerberos replaced NTLM authentication as the Microsoft's preferred protocol for Windows domains primarily due to the increased security that accompanies it. If you absolutely can't live without NTLM authentication in your network, make sure all systems are patched regularly and implement mitigations like the ones explained here. Additionally, watch the authentication patterns in your network. NTLM authentications for users (as opposed to machine accounts) may stick out like a sore thumb amongst authentication traffic.
From the attacker perspective...
Enumerate your target network carefully and characterize which authentication protocols are enabled. When harvesting/dumping credentials, and both an NTLM hashed password and AES256 encrypted password are available for a user, lean towards using the AES256 encrypted password for an overpass the hash attack. This provides an operational security (opsec) advantage because it allows you to blend in with normal Kerberos traffic associated with user activity and also avoids generating an anomaly amongst NTLM traffic. In environments where both are enabled, user authentication is normally reliant on Kerberos, not NTLM. Seeing a user account "forcibly" authenticating with NTLM is out of the norm and could raise red flags.
Also, during enumeration, make sure that the user being exploited is an active one, or at least not a stale account. Checking the number of logons per domain account is useful in this instance and again offers an opsec advantage. One could use a tool such as PowerView to enumerate the users within the domain and filter down to the number of logons associated with each samaccountname.
Comments