Windows XP Password Encryption and How Tools Like Mimikatz Work

Summary:  Microsoft states that they encrypt passwords in memory with "reversible encryption”.  However, we know that this encryption is easy to overcome as the operating system itself allows for decryption to occur when tools are allowed access to the memory storage locations and automatically retrieve, and the operating system automatically decrypts, the encrypted password.  Mimikatz accomplishes “cleartext” password retrieval by invoking a windows sub module called “LsaUnprotectMemory”, which is available to the Mimikatz and other credential harvesting programs when they have access to the debug features of Windows. 

Suggested Mitigation: If we remove the wdigest and tspkg support in Windows XP (and later versions of Windows) and limit access to the debug function that allows for the system call that enables the reverse decryption of the encrypted kerberos, wdigest, and tspkg password entries, then we essentially have mitigated most of the risk.

Windows Authentication FAQ:

Q:  Does Windows store credential information in memory?

A:  Yes, Windows stores multiple copies of credential information in the LSASS (Local Security Authority Subsystem Service) portion of memory for each authentication protocol used on the system.  In a typical XP system there are authentication protocols for wdigest (older IE6 based), tspkg (Terminal Services), and Kerberos (normal Windows authentication) services.  In all there could be up to 5 copies of windows credentials for each user logged into a system stored in LSASS.

Q:  Does Windows Encrypt Passwords in Memory?

A:  Yes.  All Windows credentials stored in LSASS are encrypted – but in a “reversible” way.

In “Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques" from Microsoft (attached), on page 34.

"Note: Windows operating systems never store any plaintext credentials in memory or on disk, only reversibly encrypted credentials. When later access to the plaintext forms of the credentials are required, Windows stores the passwords in encrypted form that can only be decrypted by the operating system to provide access in authorized circumstances.”

So, technically it is encrypted, but it is the decryption process, which is embedded in the OS that allows mimikatz and other credential harvesting tools to work.  This feature cannot be disabled or isolated in XP (it is how the operating system works) and the best approach I’ve found so far is to limit the debug mode of the local users (including Administrator and SYSTEM) and domain users and removing support for the other, less commonly needed, credential handling protocols; wdigest and tspkg.  

Q: How do tools like Mimikatz and Windows Credential Editor extract “cleartext” passwords from systems?

A: By taking advantage of a flaw in Microsoft OS that allows the automatic decryption of passwords in memory.

Specifically, when tools like Mimikatz and Windows Credential Editor (WCE) are used to extract “cleartext” passwords from a Windows operating system they do it by establishing a session in LSASS (the area where authentication is brokered and credentials are stored in Windows) and:

• Query the LSASS process for active (or recorded since last reboot) logon sessions in the memory.  The commands used for this is lsasrv!LogonSessionList & lsasrv!LogonSessionListCount, included in the query results are the LUID's (locally unique identifier) generated by the Operating system to represent the various forms of authentication and users logged into the system.
• The output information is searched and the various authentication protocols (wdigest, kerberos, tspkg, etc.) are parsed out.
• The output of that search is queried for User identifiers, tokens, and “reversably encrypted” password values.
• The tools use a Windows LSASS command called LsaUnprotectMemory, which automatically calls a windows LSASS function called LsaEncryptMemory, which has access to the symmetric encryption keys (also stored in memory), to automatically decrypt the data that the tool gathered.
• The result is “cleartext” passwords.

From Benjamin Delpy author of Mimikatz. 

The encryption used for each authentication protocol vary, but in Windows XP they are going to be based a combination of RC4 and DESx.  In newer Windows operating systems 3DES and AES are utilized.   This is a minor point because in un-patched and unsupported versions of Windows (as is Windows XP), there is no separate subsystems where authentication and decryption occurs, the keys are kept in the same memory as the encrypted files.  It’s like sending a .zip file along with the password.

Q: Are Token Authenticators more secure?

A: For the most part.  Although token values and PIN codes are stored in LSASS, they have a much shorter time to live as they change constantly and the credential will only be valid as long as the login session remains logged in.  PIN Codes are exposed, which means physical security of the token devices is critical.

Q: How about certificate based authentication?

A: Not as secure as tokens.  Although the same vulnerability exists for SmartCards, it is not a password that is stored but and NT Hash value of the certificate that is stored (along with the plaintext PIN), from the article:

"If the user logs on to Windows using a smartcard, LSA will not store a plaintext password, but it will store the corresponding NT hash value for the account and the plaintext PIN for the smartcard. If the account attribute for smartcard required for interactive logon is enabled, a random NT hash value is automatically generated for the account instead of the original password hash. This password hash that is automatically generated when the attribute is set does not change.”

In “Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques" from Microsoft (attached), on page 75.

"Will using smartcard logons mitigate the risk of the problem? 

No, not significantly. While smartcard logons can enhance security to mitigate credential theft by removing the need for a user to know their account password, underlying password hashes and Kerberos tickets can still be stolen and re-used for network connections” 

To mitigate this threat, the toggling off and on of the “Smartcard Required” user attribute changes the NT hash value.

Mitigation against Mimikatz, WCE, PTH, PTT, Etc.

Mimikatz and Active Directory Kerberos Attacks

https://adsecurity.org/?p=556

Nice Overview of Mimikatz and the many ways it can be used to steal, mimic, create, and bypass credential management in Windows.

Password-Stealing Tool Targets Windows; Evades Antivirus

https://www.duosecurity.com/blog/password-stealing-tool-targets-windows-evades-antivirus

To protect against pass the hash attacks, Microsoft recommended two methods that aren’t viable or practical, from Aorato.com’s perspective:

• Implement smart card authentication (smart cards are expensive and difficult to deploy throughout an enterprise)
• Remove the weaker encryption algorithm from the systems (this requires removing its use throughout the enterprise, which can prevent users from accessing older systems)

Malware Lateral Movement: A Primer

https://www.fireeye.com/blog/threat-research/2015/08/malware_lateral_move.html

What can you do to detect and contain the threat actors creeping around in the dark space of your network?

First, you need to be able to shine a light into that dark space and get visibility into what you are missing. Below are some recommendations that will help you do just that:

• Gathering Threat Intelligence about the tools, tactics and procedures of the malicious actors and their campaigns
• Have a threat analytics platform to identify and consolidate the information that will give your analyst the ability to do more proactive hunting for these types of techniques 
• Proactively perform forensics and sweeping of endpoints for indicators of compromise 
• Harden the devices that are on your network by removing any non-required applications or services and preforming proactive application and system configuration management and logging 
• Implement tighter controls and proactive monitoring of credentials and applications, utilizing whitelisting and multifactor authentication methods. 
• Perform data exfiltration identification and monitoring by utilizing full packet analysis and monitoring tools.

Defending Against Pass-The-Ticket Attacks

http://www.identityweek.com/defending-against-pass-the-ticket-attacks/

Pass-the-Ticket Countermeasures 

In general, Pass-the-Ticket exploits can’t be blocked by standard cyber security defenses because compromised tickets aren’t invalidated when local or domain passwords are changed. And while multifactor authentication is typically a sound verification practice, Pass-the-Ticket exploits bypass it altogether.

Instead, protecting against Pass-the-Ticket requires a different approach on the part of IT. Here are three steps in a Pass-the-Ticket defense process:

1. Stabilize the IT Environment: As stated above, Pass-the-Ticket attacks exploit the default authentication in Windows domains, allowing hackers to impersonate users or processes to gain lateral movement on a network. To counter this attack, you need to reduce the attack surface of your network. That involves enforcing frequent,  automated credentials updates and secure escalation to impede lateral movement. Start by removing weak, shared local administrator logins. Replace them with cryptographically complex and unique credentials that are frequently changed. And then audit access to the credentials.

2. Enforce Secure Privileged Escalation: Further reduce your attack surface by minimizing the presence of highly privileged logins that attackers can use to gain control of your network. Consider a privileged identity management solution that grants users delegated privileged access, and gives authorized administrators temporary membership in pre-defined groups with elevated privileges. These measures limit the ability of cyber attackers to access additional network resources after they’ve exploited a computer or impersonated a user through Pass-the-Ticket.

3. Rapid Remediation Process: Establish, in advance, a process to remove attackers’ access to compromised systems. This can be accomplished through a system that changes passwords twice on potentially compromised machines. The two password resets force immediate replication of changed credentials everywhere on the domain to block the use of compromised tickets.The password resets can be used in conjunction with automatic, chained reboots of managed machines after user escalation, or after changes to systems are implemented using escalated credentials. Privileged access management vendor Lieberman Software calls this process a Security DoubleTap™. It clears the system memory of hashes and passwords on compromised machines to curtail further access.

Lieberman Software’s Security Double-Tap™ Defeats Golden Ticket Cyber Attacks

http://www.liebsoft.com/Security-Double-Tap-Defeats-Golden-Ticket-Cyber-Attacks/

While PTH is a more widely known threat, the related PTT attack is just as dangerous. PTT attacks target Kerberos, the default authentication protocol in Windows domains. These attacks exploit Kerberos by hacking the server that stores a secret key protecting authentication. Once the attacker obtains this secret key, he gains unrestricted access throughout the IT environment – essentially a “Golden Ticket”. The attacks are launched using tools freely available online, such as WCE and Mimikatz.  

Removing Pass-the-Ticket Access from Compromised Machines

ERPM now provides an automated double password reset specifically designed to combat the Golden Ticket attack. The two password resets – a Security Double-Tap - force rapid replication of the changed credentials throughout the domain, to block the use of compromised accounts. In conjunction with this process, ERPM can also force an automatic chained reboot of target system to clear memory of hashes and passwords, and prevent memory scraping.  

Practical Attacks Against Multifactor

http://www.irongeek.com/i.php?page=videos/derbycon5/stable22-practical-attacks-against-multifactor-josh-stone

"Multifactor authentication will keep the bad guys out" is the hue and cry of hardeners everywhere, so what is the pen-tester to do? This talk will present a variety of practical attacks against multifactor authentication, ranging from basic configuration oversights to attack strategies that might work forever even if they configure it right. Multiple technologies will be presented. Many people trust their MFA implicitly, as if it's a magic talisman of keeping hackers out, but there is much a pen-tester can do (and thus, much the other kind of hacker can do), and it's important to discuss and illustrate the risks. This talk should be useful for you if you're a pen-tester, but also if you are a defender trying to get the most out of your MFA.

Dumping WDigest Creds with Meterpreter Mimikatz/Kiwi in Windows 8.1

https://www.trustedsec.com/april-2015/dumping-wdigest-creds-with-meterpreter-mimikatzkiwi-in-windows-8-1/

The Windows patch that corrects the wdigest issue of storing passwords in clear text, and how to bypass it.

Microsoft’s Local Administrator Password Solution (LAPS)

https://www.praetorian.com/blog/microsofts-local-administrator-password-solution-laps

Microsoft networks remain amongst the most vulnerable and exploited due to the way in which Active Directory is typically deployed: A base image is created with a standard local administrator password, which is duplicated on all workstations in the environment.  When an attacker compromises any workstation, the local administrator password hash can be obtained and used to access every other workstation using the classic Active Directory exploit Pass-the-Hash (PtH). This methodology is described in detail in FireEye/Mandiant M-Trends 2015 case studies.  

On May 1 Microsoft released a new tool, Local Administrator Password Solution (Security  Advisory 3062591), which provides a solution to the Pass-the-Hash exploit. Local Administrator Password Solution (LAPS) changes each local administrator password to a unique value, preventing reuse. LAPS also provides complementary end-user software to  manage local administrative accounts from a centralized server.

Why You Want Two-factor Authentication

http://l.avala.mp/blog/why-you-want-two-factor-authentication/

Most importantly, 2FA is a tool to ameliorate the security pandemic that is the password. Password re-use, weak password complexity, and insecure credential storage are the harbingers of doom for corporate networks. If you’ve never had the pleasure of using Mimikatz then give it a whirl and enjoy the sinking feeling in your stomach as you realize how your passwords are rarely adequately secured. Even if you use a password manager with long, unique passwords for everything that you log into, you stand to benefit by requiring 2FA as well.