MS systems use one of the following: LanManager Hash (LM) LanManager Hash (LM) NT LanManager (NTLM) NT LanManager (NTLM) Cached passwords Cached passwords Kerberos Kerberos MS systems use one of the following: LanManager Hash (LM) LanManager Hash (LM) NT LanManager (NTLM) NT LanManager (NTLM) Cached passwords Cached passwords Kerberos Kerberos Microsoft hashes…

Weakness of LM hashes Well documented weakness explained…how to create the hash

Weakness of LM hashes

Proof that case doesn’t matter Password = E52CAC67419A9A22 4A3B108F3FA6CB6D PaSSwORd = E52CAC67419A9A22 4A3B108F3FA6CB6D Password1 = E52CAC67419A9A22 38F10713B629B565

NTLM Uses MD4 algorithm to create a hash of the mixed-case password Results in a 16 byte hash of the password (stored in the SAM…we’ll cover later) Used for any password greater than 14 characters It is possible to turn LM hash storing off in Windows systems (although this is rarely implemented)

NTLM

Proof that case DOES matter Password = F15ABD F3 348DDCCAFB677F6A PaSSwORd = 17504CE07C0A0D4A 1BD3A99A0821F957 Password1 = F9A3152D926F9FF8 Password1 = F9A3152D926F9FF898D0BAFBA0BFFD30

NTLMv1 Challenge-response mechanism that works as follows

NTLMv1

NTLMv1

NTLMv2 More complicated than version 1 Includes the use of a two different client challenges in addition to the server challenge One client challenge is a randomly generated 8 byte value The other client challenge includes the time, a random 8 byte value, and domain name Two 16 byte responses to the challenges are sent back Not covered in detail here

Local SAM and AD SAM Security Accounts Manager (SAM) is a database of the users and groups of a system and their associated password hashes Security Accounts Manager (SAM) is a database of the users and groups of a system and their associated password hashes Stored as a registry key Stored as a registry key Located in /windows/system32/config (/winnt/…for 2000) Located in /windows/system32/config (/winnt/…for 2000) Protected since NT 4 SP3 with SYSKEY Protected since NT 4 SP3 with SYSKEY SYSKEY encrypts the SAM database…easily broken now, you’ll see this with one of the tools we’ll use in the demo SYSKEY encrypts the SAM database…easily broken now, you’ll see this with one of the tools we’ll use in the demo

Local SAM and AD SAM

When Windows is running the SAM is protected by the kernel When Windows is running the SAM is protected by the kernel The process that protects the SAM is called the Local Security Authority Subsystem (LSASS) The process that protects the SAM is called the Local Security Authority Subsystem (LSASS) Password tools have been created that allow the tool do the following (fgdump): Password tools have been created that allow the tool do the following (fgdump): Use a process to force the LSASS to load a DLL Use a process to force the LSASS to load a DLL The code within the DLL is executed in the context of LSASS The code within the DLL is executed in the context of LSASS The newly unprotected password hashes are pulled using the same API that LSASS uses to access them The newly unprotected password hashes are pulled using the same API that LSASS uses to access them This works locally and remotely This works locally and remotely Requires admin access to the system Requires admin access to the system

Local SAM and AD SAM The SAM in AD is very similar to that of a local system The SAM in AD is very similar to that of a local system The AD SAM holds all AD account information including users, groups, hashes, and password history The AD SAM holds all AD account information including users, groups, hashes, and password history This requires that we run as an administrator in the domain This requires that we run as an administrator in the domain Can be completed with admin access or using service hijacking (to be covered in a different presentation) Can be completed with admin access or using service hijacking (to be covered in a different presentation)

Salted versus Unsalted Password Hashes We’re not talking about popcorn… We’re not talking about popcorn… An unsalted hash is one that simply uses the same key (or the same static value) on every system An unsalted hash is one that simply uses the same key (or the same static value) on every system An example would be LM and NTLM hashes stored in the SAM database (the static value is An example would be LM and NTLM hashes stored in the SAM database (the static value is For example, if we both run Windows XP systems, and both of our passwords are “apple” then the password hash on both systems would be the same For example, if we both run Windows XP systems, and both of our passwords are “apple” then the password hash on both systems would be the same

Salted versus Unsalted Password Hashes A salted password hash is one that uses some other value, in addition to the static value, as a modifier A salted password hash is one that uses some other value, in addition to the static value, as a modifier For example, UNIX systems use salt in the storage of their password hashes For example, UNIX systems use salt in the storage of their password hashes If we both had the same password again, “apple”, and if our system used the system hostname as the salt, then unless our systems have the same hostname then the password hash on the two systems would be different If we both had the same password again, “apple”, and if our system used the system hostname as the salt, then unless our systems have the same hostname then the password hash on the two systems would be different Keep in mind the salted value either needs to be shared or available before the hash in plaintext so other system knows what it was salted with. Keep in mind the salted value either needs to be shared or available before the hash in plaintext so other system knows what it was salted with.

What does it matter? The SAM file is unsalted which means: The SAM file is unsalted which means: We can pre-compute the possible password hashes in advance and do a simple look up for the hash….or We can pre-compute the possible password hashes in advance and do a simple look up for the hash….or We can use rainbow tables (more efficient way of pre- computing) We can use rainbow tables (more efficient way of pre- computing) Microsoft also uses something called a cached password which we’ll examine next Microsoft also uses something called a cached password which we’ll examine next

MS Cached passwords If you’re system is a member system of a Microsoft Active Directory domain (drop down in the login) what happens if you’re not connected to the network? Can you still log in using the AD username and password? If you’re system is a member system of a Microsoft Active Directory domain (drop down in the login) what happens if you’re not connected to the network? Can you still log in using the AD username and password? Yes you can, all thanks to cached credentials on the system Yes you can, all thanks to cached credentials on the system These are stored (and protected) in the registry (depending on your systems settings, normally the last 10) These are stored (and protected) in the registry (depending on your systems settings, normally the last 10) HKEY_LOCAL_MACHINE\SECURITY\CACHE\NL$ HKEY_LOCAL_MACHINE\SECURITY\CACHE\NL$1 - 10

MS cached passwords So if they are stored can’t we get them and crack as we would a normal SAM file? So if they are stored can’t we get them and crack as we would a normal SAM file? Yes, we can get them, and since they are salted, no, we cannot just crack them as we would a SAM file password hash Yes, we can get them, and since they are salted, no, we cannot just crack them as we would a SAM file password hash This uses a “password verifier and not the actual password itself This uses a “password verifier and not the actual password itself How is it salted? With the username: How is it salted? With the username: The user’s NTLM hash is added to the username The user’s NTLM hash is added to the username Re-run the NTLM hash of the new salted value Re-run the NTLM hash of the new salted value When we get access to the cached password we get the salt used (the username) and the hash of the username + NTLM hash… When we get access to the cached password we get the salt used (the username) and the hash of the username + NTLM hash… This leads us to only brute force as a cracking mechanism…unless? This leads us to only brute force as a cracking mechanism…unless?

MS cached passwords What is the standard name for the administrator account in Windows? What is the standard name for the administrator account in Windows? Couldn’t we just build our pre-computed tables with that as the known username and salt? Couldn’t we just build our pre-computed tables with that as the known username and salt? Microsoft and the government have done this already…I’m trying to get a copy Microsoft and the government have done this already…I’m trying to get a copy

Kerberos Developed by MIT, adopted and reworked by Microsoft and put into Windows 2000/2003/2008 Developed by MIT, adopted and reworked by Microsoft and put into Windows 2000/2003/2008 Used for authentication between end systems and the Active Directory domain controller Used for authentication between end systems and the Active Directory domain controller Uses concepts we will not cover in detail, however, it does not transmit the user’s hash, or response to a challenge, over the wire directly Uses concepts we will not cover in detail, however, it does not transmit the user’s hash, or response to a challenge, over the wire directly