Login and Mimikatz

How Windows stores passwords

Let’s take a look at what happens when a user logs in. How does Windows know that you are who you say you are? You supply a password. But how does Windows know that it’s the right password? We saw in the cryptography chapter that systems that need to authenticate users should store password hashes, not the passwords themselves. Sure enough, Windows stores user password hashes, not the passwords themselves. Windows does this using a hashing algorithm called NTLM. Windows uses NTLM to generate a hash of the password that the user supplies at login time and compares it to the hash that’s been stored for that user. If it’s a local account, the known-good hash is stored on that computer. If it’s a domain account, then the computer will ask the domain controller whether the supplied hash is the right one.

When else is the password needed?

It’s needed when you access domain resources like shared drives. It would be awkward if you had to type in your password every time you accessed any domain resource. So Windows keeps your password hash in memory and sends it whenever you need to access domain resources. The domain controller verifies the password hash; and if it matches the domain controller grants access. This makes for a smooth user experience. But are there security implications? Well, one implication is that the password hash has to remain in memory. That implication is the basis for a tool called Mimikatz.

Mimikatz

Mimikatz is a tool that reads the password hashes that Windows keeps in memory. Due to the way that Windows stores these passwords, any user with administrator-level access to a Windows computer can read the password hashes of any other users that are logged in at the same time. And in earlier versions of Windows, such as Windows 7 and Windows 8.1, Mimikatz could also read the plaintext passwords of any logged-in users.

Let’s think about what a tool like Mimikatz enables an attacker to do. Let’s say that an attacker can execute code as a local admin on a Windows computer on a network. This capability might come from stolen credentials or from a software vulnerability. The attacker can then run Mimikatz and get the password hashes of any other users who are logged in. If any of those users are domain users, then the attacker can run commands as those users on other machines in the domain using the Pass the Hash attack. And if any of those users are local admins on the other computers, then the attacker can run Mimikatz on that second population of computers and possibly steal more password hashes and expand out to another set of computers. If any of these computers have domain admins logged in, then the attacker can steal domain admin password hashes, which generally results in a complete compromise of the domain.

Joe asks: What is the pass the hash attack?

We’ve seen that Windows keeps user password hashes in memory to allow a logged-in user to access domain resources. Windows allows users to authenticate themselves to remote Windows computers by sending a valid password hash over TCP port 445, which is the SMB port. So if a password hash is stolen with Mimikatz, the attacker can use that hash to impersonate the users on other computers. This is the Pass the Hash attack.

For a more detailed explanation, see pass-the-hash attacks: Tools and Mitigation by Ewaida and Boeynaems.

It’s worth noting that while Mimikatz makes it easier to accomplish this attack, the underlying problem would be there regardless of whether Mimikatz existed or not. If Mimikatz did not exist, it would be necessary to invent it.

Defenses

So how do we prevent this attack on our network?

Patching

We have a number of defenses available to us, the first of which is to keep up-to-date on patching. As long as we’re on Windows 8.1 or newer, Mimikatz should only be able to steal password hashes, not passwords themselves. In the chapter on patching, we focused on incremental security bug fixes as the main benefit to keeping up-to-date on patches. But there are also systemic improvements like this one. There is a registry setting that would make Windows store the actual passwords, not just the hashes, in memory. But you won’t have this enabled by default. And as your security posture improves, you’ll add endpoint monitoring to prevent settings like this from being enabled or to at least warn you if they’re changed.

Network segmentation

Another defense against Mimikatz is better network segmentation. The workstations on your network should not generally need to communicate with each other via SMB on port 445. So block that at the router level. Then even if one workstation is compromised, the attacker won’t be able to jump from workstation to workstation looking for one with logged-in domain admins. There’s still need for domain administrators to use port 445 to administer machines on your network, so you’ll want to enable port 445 for communication initiated by admins; just block port 445 for communication initiated by other computers.

Since the attacker’s target is domain admin credentials, make those credentials harder to find by using them less often. If the domain admin credentials are only used when they’re absolutely needed, fewer machines will have domain admin credentials in memory and for shorter periods of time. This also provides a layer of defense against phishing. Domain admins aren’t immune to phishing attacks. If they always use their regular domain user to check email, then even if they get phished, they’ll only provide a regular domain account, not a domain admin account.

This gives us three different levels of access that administrators in your organization will need to have:

• Regular domain user for doing their day-to-day work, reading email, and so on
• Domain admin user for doing work that requires domain admin access, things like editing domain policies
• Local admin on other people’s workstations for administration and troubleshooting purposes

So you’ll want your domain administrators to use a separate account for each of these three access levels. The first two are straightforward, but a couple of other options are available for the third account.

One option for domain administrators who need local administrator access to workstations for troubleshooting and support is to use Microsoft’s Local Administrator Password Solution, or LAPS. The idea behind LAPS is that it manages the local administrator account on each machine in the domain for you. So each machine has a unique local administrator password. So even if the local administrator’s password hash (or even the password itself) on one computer is compromised, the attacker can’t use it on any other computer. The other nice thing it does is automatically rotate the local administrator passwords, which minimizes the impact of a stolen local administrator password.

Another approach is to create a local admins group in Active Directory. Then put that group in the Local Administrators group on each workstation in your organization. Make this a part of your standard workstation image.

                                                 Q U I Z