Pass-the-Hash has been around for years<\/p>\n
The post on\u00a0Alex Ionescu\u2019s blog, The Evolution of Protected Processes Part 1: Pass-the-Hash Mitigations in Windows 8.1<\/a>, describes the latest mitigation techniques Microsoft is incorporating in the latest versions of Windows.<\/p>\n He describes the importance of LSASS in his post<\/a>: In Windows, local user accounts are hashed using a well-known algorithm (NTLM<\/a>) and stored in a database called the SAM <\/a>(Security Accounts Manager), which is in itself a registry hive file. Just like with other operating systems, a variety of offline, and online attacks exist in order to obtain, reset, or otherwise reuse the hashes that are stored in the SAM, going from the usual \u201cPassword Reset\u201d boot emergency disks<\/a>, to malicious privilege escalation. Additionally, a variety of other cryptographic data is also stored in the SECURITY database, yet another registry hive file. This data includes information such as secrets, saved plain-text passwords, and more.<\/p>\n A process called the Local Security Authority<\/a> (LSASS) manages the run-time state of this information, and is ultimately responsible for all logon operations (including remote logon over Active Directory). Therefore, in order to obtain access to this data, two primary mechanisms are used:<\/p>\n 1) File-based attacks: the SAM\/SECURITY hives are accessed, either offline, or online through tricks such as using Volume Shadow Copies<\/a>, and the hashes + secrets extracted. This mechanism has disadvantages in that the storage formats can change, detailed registry knowledge is needed, and LSASS will often obfuscate much of the data (such as plain-text cached passwords).<\/p>\n 2) Process-based attacks: since the hash and secret data from #1 above is neatly loaded by LSASS in readable form (and accessible thanks to easy-to-use query APIs<\/a>), it is often much more preferable to simply inject code into the LSASS process itself, which is then used to dump hashes or secrets, as well as to create tokens based on those hashes. Additionally, researchers such as Gentil Kiwi<\/a> have even discovered that LSASS contains plain-text passwords using reversible symmetric cryptography (with the key stored in the LSASS process itself). Tools now exist today to not only pass-the-hash<\/a>, but to also pass-the-pass. In a default Windows 8 installation, both the local user account password, as well as the Microsoft Live Services password, is available in a plaintext-retrievable way.<\/strong><\/p>\n Obviously, both this file and the process are protected such that only the SYSTEM account can access them. But once running as Administrator, this is a simple hurdle \u2014 and since most users still run as Administrators (albeit with UAC, but that\u2019s not a security boundary), exploits only have to escape whatever local sandbox they\u2019re running in, get admin rights, get a system token, and inject into LSASS. And of course, in a shared computer environment, another admin on the machine can get the passwords of all the users.<\/p>\n What\u2019s changed in Windows 8.1? Run Mimikatz or other pass-the-hash attacks and they still work out-of-the-box. But on a Windows 8.1 RT system (supposing one can compile for ARM), they won\u2019t \u2014 in fact, even attempting to attach a debugger to the LSASS process will fail, regardless of user-mode permissions.<\/p>\n The title of this blog post gives it away: in Windows 8.1 RT, LSASS is now a protected process light<\/i>. And with Registry Editor and the right key\/value pair, your Windows 8.1 installation (non-RT) can take advantage of this too.<\/p><\/blockquote>\n Read the rest of Alex\u2019s post here<\/a>.<\/p>\n References:<\/p>\n
\n(emphasis\/bold text is my own)<\/p>\n\n
The LSASS Process<\/h3>\n