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!]

SANS Posters rule! The malware geeks Jake Williams and Alissa Torres have created a new REM poster that focuses on malware memory forensics, and covers the Volatility and Rekall frameworks, as well as important artefacts. Depending on your location, you can get a printed copy mailed to you .. or you can download and print on your own: http://www.sans.org/security-resources/posters/dfir-memory-forensics-2015-65