In our previous article, we discussed the problem of hash theft – that is, extracting from a machine the password hash associated with a local or domain account, and the relative ease of ‘brute force’ attacks on these hashes to recover plain-text passwords.
There are ways of mitigating such attacks, and the focus of this article is to discuss some of them.
Password managers
One solution to the password problem is to use a password manager. A password manager stores one or more strong passwords, protected by a ‘passphrase’ which you use to unlock the store and retrieve the passwords. So you could tuck away passwords like our ‘aF6%9$t-PvWB463’ from earlier on and protect it with a passphrase like XKCD’s ‘correct horse battery staple’.
Of course, you must reach the password manager from somewhere if you’re trying to log on to your desktop machine. This is where having a mobile-device-based password manager that either store passwords encrypted on the device or in the cloud make sense.
Also, the password manager is itself a vector for attack. If the mobile device is stolen, could the attacker access the passwords? Or if stored in the cloud, how vulnerable is that to attack? Still, a password manager does provide potentially enhanced protection and is well worth considering.
Smartcards and access tokens
Some organizations believe that smart cards offer enhanced security. Typically you need both the card and a PIN to log on. With an access token, you need to validate against a numeric key that changes over time and is also different for each token. Surely this is more secure?
Not necessarily. Internally Windows still needs a fixed domain account (and password) associated with the login and it is this that is still vulnerable to attack. Additionally, this account typically is set to have a long-lived password and to allow extended failed login attempts, making it potentially more vulnerable to attack.
Other mitigations
Apart from the use of REALLY strong passwords, probably augmented by password managers, you can mitigate password hash attacks by taking the following measures:
- Don’t share passwords across local accounts on multiple machines. If administrators want a way of gaining local admin rights on machines, use Microsoft’s LAPS, which supports the storage of strong, device-specific passwords using Active Directory. Recall that, if you share a password for local accounts across multiple machines, an attacker can re-use that password to attack other machines on the network.
- Disable domain password caching on machines which are not expected to be disconnected from the corporate network. You can use Group Policy to disable the cache. If the machine is a desktop or server, expected to be always connected to the corporate intranet, do you really need the capability for offline domain login? If not, eliminate the vulnerability of cached hashes by disabling password caching.
- Use full-disk encryption on mobile devices such as laptops. Encryption solutions such as BitLocker make sure an attacker who steals a laptop can’t just read the registry and get at those precious hashes. Remember, they don’t need to login to do this, they just need to pull the disk out of the laptop and read it directly, or boot an alternative operating system from a USB key and then read the primary disk. Full-disk encryption stops them being able to do this.
- Don’t let BYOD devices join your domain. If you do, you risk credentials being cached on these devices and subsequently retrieved by an attacker, unless full-disk encryption is enabled on the device.
- Be cautious when setting services to log on with domain credentials. Some organizations believe that it is wise to set services up to log on with domain credentials. The argument is that the domain account can be given only the privileges it requires.That’s sound reasoning, but be aware that the service needs to be able to retrieve the plaintext password – not the hash – in order to log on to the domain account. An attacker can, therefore, get the actual password out of a machine’s registry – not just the hash, for these service logins. Consequently, you need to be very careful that the domain account’s permissions are tightly controlled.
- Control computer account rights carefully. Services which run in the context of a local machine account use the computer account when accessing remote resources.
Computer accounts are domain accounts, based on the name of the computer with a $ at the end.
For example, if your domain is ACME and your computer is MACHINE1234 then the domain account associated with the computer will be ACME\MACHINE1234$.
Computer accounts have a long, random password which changes every 30 days, as long as the computer is connected to the domain.
However, this random password is stored in the local machine registry and can potentially be decrypted by an attacker, who may be able to use the computer account to access resources on a remote server. Be very careful about the access privileges you assign to computer accounts.
Conclusion
You can see that it is possible to minimize the risk of hash theft by taking some simple preventative measures. If you think like the bad guys, you can make it much harder for them to slip through your perimeter defenses and steal information. Security is an ongoing challenge, best met with informed and proactive defense policies.
