In this newsletter, we will see how passwords are managed by Windows and how an attacker can use the password hashes without knowing them.
How Windows stores password
Originally, Windows used the LM hash format to store user’s password on the computer. This hash has several weaknesses; the hash method truncates the password to 14 characters, uppercases it and divides the password into two parts of 7 characters. Then Windows use the DES ciphering function to cipher each part. Finally, the two parts are concatenated in order to form a 16-bytes value called LM hash. This kind of hash is still usable on Windows but is disabled by default since Windows 2008.
Windows then decided to change LM hash for the NTLM hash, but despite the lack of security of the LM hash, Windows decided to keep the compatibility with it. The NTLM hash is a simple Unicode MD4 hashed representation of the password. It is still the one used on Windows 10 and Active Directory. The NTLM Hash should not be mixed up with the NTLM Authentication, which is a completely separate mechanism.
On a workstation, hashes of logged on users, including Active Directory ones, are stored in the memory of the process “Lsass.exe”. All local hashes are stored in the local SAM (security account manager) database, which is stored in the file %SystemRoot%/system32/config/SAM and is also mounted in registry on HKLM/SAM.
The attack
Someone able to retrieve these hashes may bruteforce them to retrieve the clear text value. However, there is a quicker way to exploit it. It is possible to use directly the NTLM hash instead of the clear text password. Even if it is not permitted by standard windows commands (net use, ) Custom clients tools permit the direct authentication with the NTLM or LM password hash in order to authenticate to any windows resource (SMB, FTP, RPC, HTTP…).
This technique, first published in 1997 by Paul Ashton, consists in stealing the hash of user in order to log onto other computers. This method is powerful because most of the time, on Windows environment, the local Administrator account shares the same password on all Windows machines.
When the attacker possesses this hash, he can log onto other computers on the network where the user has rights. Pass the Hash is a basic of lateral movements.
The right of the user and the type of account affects the scope:
•If it is the hash of a domain user, the attacker gains access to the view and rights of the user.
•If it is the hash of the local administrator, the attacker has access to all computers with the same Administrator account and the same password. However, since windows 8.1 this attack works only if the local administrator has the UID 500 (the build-in Administrator).
Defense
Natively since Windows 8.1, and with configuration on Windows 7 running March 2014 patch 2871997 (https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/2871997), only the original built-in local administrator with the UID 500 can perform a pass the hash. To avoid this behavior, it is possible to create another administrator and disable the first one. With this new administrator, it is impossible for an attacker to perform a “pass the hash” attack with local credentials.
To prevent this kind of attack and go further to avoid lateral movements, Microsoft provides a tool named LAPS (Local Administrator Password solution – https://technet.microsoft.com/en-us/mt227395.aspx). This tool addresses most of the issues. It allows computers to have different passwords for each local administrator. All passwords are stored on the Active Directory and protected by ACL.
Moreover, all passwords are periodically changed automatically. This method forbids the connection onto another computer because local administrator’s password is never the same.
Detection
There are several methods in order to detect a pass the hash execution looking at the security log in both the domain controller and the workstation.
When a user performs a pass the hash, a logon type 3 (through network) with the event ID 4624 and is generated and leaves some exploitable artefacts in Security ID, Hostnames, KeyLength field.
Another method is to check on the workstation security log the deletion of a job. In fact, when an attacker uses the PSExec tool, a job is created on the victim machine and deleted after. The deletion of the job can be found via the event log 141. Furthermore, in some cases the service can have a random name, which is more suspicious.
As the PSExec tool installs itself as a service, another way to detect PSExec is to look for a remote service registration and execution that creates an Event with the ID 7045.
Conclusion
It is possible to configure Microsoft environments to avoid Pass The Hash attacks, but the NTLM hash is not perfect and other passwords or ticket based authentication attacks are still possible on Windows.
