Pass the hash!

Pass the hash!
No, this isn't about sharing a hallucinogen-laced bong for a smoke. The "hash" we're referring to here is the one that Wikipedia aptly but unhelpfully defines as "a derivation of data, notably used in cryptographic hash functions". Passing the hash is a form of login credential theft that is quite prevalent. In it, an attacker captures the encoded session password (the "hash") from one computer, and then re-uses it to illicitly access another computer. On (most configurations of) the Microsoft Windows operating system, this "hash" can be used as an equivalent stand-in for the original password, hence if an attacker obtains the "hash" of a privileged account, this has the exact same immediate consequences as when the attacker had gotten his hands on the password of same account. Pass-the-Hash (PtH) exploitation has been involved in many of the recent high profile breaches, and the issue is big enough of a problem that Microsoft have set up a dedicated top level web page http://www.microsoft.com/pth to get the word out. They also provide two quite decent documents, "Mitigating Pass-the-Hash and Other Credential Theft v1" and "v2" on that page, with 60+ pages each, which is certainly an indication that this is not a trivial problem to understand and mitigate. One pre-requisite for PtH to work is that the attacker must obtain local administrator privileges on at least one computer in your organization. So, if you are still generously letting your users work and surf the web as "admin", here's one more reason to stop that. Another particularity of PtH is that whenever a higher privileged administrator logs on to a lower privileged device, he/she creates a privilege escalation opportunity for whoever controls that lower device. If you have some type of admin privileges in your windows AD domain, think about when you "RDP" into other devices to "check something out" or "fix something". Doing so places your "hash" onto that device, and the hash can be harvested by someone with admin rights on that device, and re-used to impersonate you for as long as you do not change your associated password. Sounds bad? Yup. Potentially, it is. Because what seems to be happening quite frequently is that attackers breach one single user workstation (through malware in drive-by web or email based attacks). Then, the attackers try to get admin privileges on that workstation. If the user already has local admin privs, they won, if not, they need to find some local exploit (missing patch, weak password, etc). Once they ARE local admin, they extract all "hashes" that they can find locally on that workstation. With a bit of luck, some IT Helpdesk person who has admin privileges across ALL workstations in the firm had recently connected to that particular PC, and "left the hash" behind. Thus, the attacker ends up with admin privs across all workstations. Next step, find the workstation of a server or domain administrator, and hope to locate an even more privileged hash on there. If found: game over. All of this can be and has been automated, and can happen in a matter of minutes. The not so good news is: Even though Microsoft have posted two 60+ page documents on the issue, there is no real rock solid mitigation. There are just mitigations that make the problem less likely to occur. But that's at least a start -- there is no better option, short of maybe giving up security entirely, and smoking that other hash ;). So, if you never heard of PtH attacks before, or you didn't bother to look at the recommended mitigation measures, I suggest you spend some time and do so. Start with the document marked "v1". [Edited to add: And if you thought that Kerberos or Smartcard Auth helps much, think again, and read "v1" anyway!]	Daniel 380 Posts ISC Handler Mar 18th 2015
Thread locked Subscribe	Mar 18th 2015 6 years ago
You can prevent your server admin and domain admin accounts from interactively logging into your workstations. This can be done for free with Group Policy and will prevent a workstation from storing administrative hashes which in turn prevents a workstation compromise from being an easy domain compromise. For your IT helpdesk accounts (ie: local admins), you can prevent these from logging into your servers so the local admin (helpdesk) accounts can only access workstations. Furthermore, you can prevent PtH from workstation to workstation by not allowing your workstations to connect to each other over port 139/445 for file and printer sharing. Network logins, such as mapped drives, aren't interactive and don't store the hash upon login so you can set your workstations to only 139/445 traffic from your servers. This will allow you to still access your workstations from your servers for administrative purposes using the local admin account. In short, restrict your admin accounts to only login to the machines they need to login to. Domain admin accounts should only be able to login to domain controllers (and maybe a couple of other highly sensitive servers such as your CA). Any application servers should have their own unique admin accounts that can only login to that specific app server so that a compromise of one app server doesn't result in the compromise of all app servers. Finally, all local workstation admin accounts should only be allowed to login to workstations and not any servers. You can still login to the workstation from the servers as the local admin account. This is the only way I've found to keep sensitive hashes from being stored on the wrong systems and it seems to work well for us. Notable Group Policy Settings: Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / User Rights Assignment: - Deny log on as a batch job - Deny log on as a service - Deny log on locally - Deny log on through Terminal Services Computer Configuration / Policies / Windows Settings / Security Settings / Restricted Groups: - BUILTIN\Administrators I believe Server 2012 and beyond will have authentication silos which should also address this. The silo will basically be a group of machines designated as being at the same security level. There is still an issue of passing the hash among machines in the same silo, but at least we can prevent easy escalation from one silo to another (eg: from workstations to app servers or infrastructure servers).	Justin 8 Posts
Quote	Mar 20th 2015 6 years ago
I posted a bit on PTH attacked and detecting them with Sagan some time back. If you are interested in this sort of this and detecting it via log analysis, check out: https://quadrantsec.com/about/blog/detecting_pass_the_hash_attacks_with_sagan_in_real_time/	Justin 9 Posts
Quote	Mar 22nd 2015 6 years ago

No, this isn't about sharing a hallucinogen-laced bong for a smoke. The "hash" we're referring to here is the one that Wikipedia aptly but unhelpfully defines as "a derivation of data, notably used in cryptographic hash functions".

Passing the hash is a form of login credential theft that is quite prevalent. In it, an attacker captures the encoded session password (the "hash") from one computer, and then re-uses it to illicitly access another computer. On (most configurations of) the Microsoft Windows operating system, this "hash" can be used as an equivalent stand-in for the original password, hence if an attacker obtains the "hash" of a privileged account, this has the exact same immediate consequences as when the attacker had gotten his hands on the password of same account.

Pass-the-Hash (PtH) exploitation has been involved in many of the recent high profile breaches, and the issue is big enough of a problem that Microsoft have set up a dedicated top level web page http://www.microsoft.com/pth to get the word out. They also provide two quite decent documents, "Mitigating Pass-the-Hash and Other Credential Theft v1" and "v2" on that page, with 60+ pages each, which is certainly an indication that this is not a trivial problem to understand and mitigate.

One pre-requisite for PtH to work is that the attacker must obtain local administrator privileges on at least one computer in your organization. So, if you are still generously letting your users work and surf the web as "admin", here's one more reason to stop that. Another particularity of PtH is that whenever a higher privileged administrator logs on to a lower privileged device, he/she creates a privilege escalation opportunity for whoever controls that lower device. If you have some type of admin privileges in your windows AD domain, think about when you "RDP" into other devices to "check something out" or "fix something". Doing so places your "hash" onto that device, and the hash can be harvested by someone with admin rights on that device, and re-used to impersonate you for as long as you do not change your associated password.

Sounds bad? Yup. Potentially, it is. Because what seems to be happening quite frequently is that attackers breach one single user workstation (through malware in drive-by web or email based attacks). Then, the attackers try to get admin privileges on that workstation. If the user already has local admin privs, they won, if not, they need to find some local exploit (missing patch, weak password, etc). Once they ARE local admin, they extract all "hashes" that they can find locally on that workstation. With a bit of luck, some IT Helpdesk person who has admin privileges across ALL workstations in the firm had recently connected to that particular PC, and "left the hash" behind. Thus, the attacker ends up with admin privs across all workstations. Next step, find the workstation of a server or domain administrator, and hope to locate an even more privileged hash on there. If found: game over. All of this can be and has been automated, and can happen in a matter of minutes.

The not so good news is: Even though Microsoft have posted two 60+ page documents on the issue, there is no real rock solid mitigation. There are just mitigations that make the problem less likely to occur. But that's at least a start -- there is no better option, short of maybe giving up security entirely, and smoking that other hash ;). So, if you never heard of PtH attacks before, or you didn't bother to look at the recommended mitigation measures, I suggest you spend some time and do so. Start with the document marked "v1".

[Edited to add: And if you thought that Kerberos or Smartcard Auth helps much, think again, and read "v1" anyway!]

Daniel

380 Posts
ISC Handler

Mar 18th 2015

You can prevent your server admin and domain admin accounts from interactively logging into your workstations. This can be done for free with Group Policy and will prevent a workstation from storing administrative hashes which in turn prevents a workstation compromise from being an easy domain compromise.

For your IT helpdesk accounts (ie: local admins), you can prevent these from logging into your servers so the local admin (helpdesk) accounts can only access workstations. Furthermore, you can prevent PtH from workstation to workstation by not allowing your workstations to connect to each other over port 139/445 for file and printer sharing. Network logins, such as mapped drives, aren't interactive and don't store the hash upon login so you can set your workstations to only 139/445 traffic from your servers. This will allow you to still access your workstations from your servers for administrative purposes using the local admin account.

In short, restrict your admin accounts to only login to the machines they need to login to. Domain admin accounts should only be able to login to domain controllers (and maybe a couple of other highly sensitive servers such as your CA). Any application servers should have their own unique admin accounts that can only login to that specific app server so that a compromise of one app server doesn't result in the compromise of all app servers. Finally, all local workstation admin accounts should only be allowed to login to workstations and not any servers. You can still login to the workstation from the servers as the local admin account.

This is the only way I've found to keep sensitive hashes from being stored on the wrong systems and it seems to work well for us.

Notable Group Policy Settings:
Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / User Rights Assignment:
- Deny log on as a batch job
- Deny log on as a service
- Deny log on locally
- Deny log on through Terminal Services
Computer Configuration / Policies / Windows Settings / Security Settings / Restricted Groups:
- BUILTIN\Administrators

I believe Server 2012 and beyond will have authentication silos which should also address this. The silo will basically be a group of machines designated as being at the same security level. There is still an issue of passing the hash among machines in the same silo, but at least we can prevent easy escalation from one silo to another (eg: from workstations to app servers or infrastructure servers).

Justin

8 Posts

I posted a bit on PTH attacked and detecting them with Sagan some time back. If you are interested in this sort of this and detecting it via log analysis, check out:

https://quadrantsec.com/about/blog/detecting_pass_the_hash_attacks_with_sagan_in_real_time/

Justin
9 Posts