How Mimikatz is used to exploit your network and what you can do about it.
For this blog post I wanted to highlight a common attack vector that we often use in our penetration testing. My goal is to run through the process at a high level, and then cover some of the steps you can take to mitigate your risk. Specifically, this post will cover a memory scraping utility known as Mimikatz.
Mimikatz has been out in the wild for roughly five years now, but its ability to obtain passwords is still relevant today. The tools effectiveness is in large part due to the service it takes advantage of. Mimikatz scrapes data in memory tied to a core windows component that has large ramifications if altered improperly. That service is LSASS, or “Local Security Authority Subsystem Service”. Its major function for Windows Domain Networks is facilitating Single Sign On which allows users to navigate shared folders and connect to domain resources without having to enter their credentials hundreds of times a day. Without going into too much detail, the LSASS service acts as an operator that responds to authentication requests, and replies with the appropriate authentication package.
Sounds great; however, to handle this functionality, LSASS was originally designed to hold credentials in memory in clear text for all users that have logged onto the system since the last reboot event. You don’t have to be technical to understand this is a very bad thing. Once Mimikatz hit the wild, it became a trivial process to acquire local admin, and in many cases domain admin credentials within seconds of infecting a machine.
Using a lab environment, I am going to show you what Mimikatz looks like from our end, as well as walk through one “fix” that Microsoft implemented. The quotes mean that there’s a caveat here folks. After the run through I will also detail some other steps, as well as design philosophies that you can consider implementing to protect yourself. I pull much of this information from Windows white papers on credential theft, which I have included at the end of this post. I encourage your IT staff to dive into these white papers to understand the breakdown of credential theft at higher level than I will be covering. Well, let’s get started!
To set the stage, this demonstration begins in the post exploitation phase. Meaning at this point a domain user has already clicked a link in an email, or navigated to a malicious website that downloaded some form of malicious code, giving us some level of system access.
The images below show an Empire agent, running on Workstation200 in the TESTLAB domain under the user zbrannigan.
The system information for this user is seen above. For purposes of this lab I will be using Windows 7 to better cover the knowledge base (KB) article that Microsoft released to remediate this issue. In addition to this, we still see more Windows 7 machines than Windows 10 in the corporate landscape.
We start by running Mimikatz (Local Admin rights are required, but I will touch on that later in the defensive section of the post) and the following information is returned.
The image above shows the users hash, and in the third row the cleartext password that is being stored in memory. As this machine was recently rebooted only the active user account is seen. In many instances rebooting daily is not feasible. However, I would like to point out this is one way to help mitigate credential harvesting.
Moving along, I am going to set up a quick story here to provide an example of how credentials can spread in a network.
Mr. Brannigan while working at his desk really wants some motivation to help him through the work week, and he reaches out to one of the IT admins, Mr. Frye. He tells the IT admin, “You know, I would really like a nice funny cat wallpaper, I think it will really help me through my day. I could not help but notice though when I try to change it I was not able to.”
The Admin lets him know this is due to policy, however he would be happy to change it for him. The admin then signs on to the user machine and grants his request.
A satisfied Mr. Brannigan resumes works, still unknowingly infected by the engineer. Knowing that we had a new login event let’s go back and check Mimikatz again. With this example you can see how Mimikatz effectiveness can escalate quickly in environments.
A key security updated was pushed out by Microsoft to combat this exact issue. Reading at a glance, this update appears to be a silver bullet fix for everything I just demonstrated. The update prevented every Microsoft Authentication package from storing credentials in cleartext, except for WDigest which has some extra steps.
“So, 10-D if we push this update and make the registry change, we are done here, right?”
Nope, because unfortunately as I mentioned in the start of this post, changes to the LSASS process can have wide sweeping effects on your network. Because of this, the KB2871997 was a two-part patch. (If you have done an Internal Scan with us before, you have heard that one before). The second step requires a registry key that is created when the patch is installed to be modified to a value of “0” in order for this patch to be effective. This still does not prevent passwords hashes from being easily obtained either.
The first example was performed on a system with this KB installed, however the registry change was not in place. There are a lot of machines out there like our lab with this protection halfway installed, and thus still at risk. It’s important to understand these kinds of patches exist. In fact, it is so important we wrote a previous blog on this very subject.
Let’s look at Mimikatz now with the registry modified via group policy.
I also went ahead and erased the credentials in our cache so this will be a fresh look at Workstation200. As you can see below we now only see the hash values for the infected user. While obtaining a password hash still presents its own problems, we can see now that the hacker is going to have to spend significant more time obtaining the full password in cleartext.
Now to the issue with this KB. First, since this change is considered potentially impactful, Windows set the Registry key to provide admins a level of control over how WDigest behaves in case you experience any issues. Which means this change is reversible on a live system, without needing a reboot. I will demonstrate that now.
Behind the scenes the engineer has used a shellcode inject to acquire a meterpreter shell on the infected host. The engineer then takes advantage of Pipe Impersonation, which allows one to impersonate a process communicating with a shared memory resource called a Pipe Server (often at a higher security level). This allows the engineer to run as System and drop into a shell, and run the following command.
Now the registry key has been set back to “1” or enabled, and we are back to square one, any new or active sessions will be recorded in clear text for the purposes of Single Sign On functions in Windows. In fact, let’s quickly remote back in with the admin and run Mimikatz again.
Alright 10-D, so you just showed us how one section of a key patch pushed out to combat this issue is significantly hampered when an educated and motivated attacker is on the network. What options do we have outside of this?
To best answer this question, I am going to break it down into two sections.
The biggest take away from Mimikatz is that it is effectiveness can waver greatly depending on how many users are logging into the same machine. Mimikatz serves as a great warning to why we always steer clients away from daily driver accounts that have elevated privileges. The single best way to protect yourself in our opinion is by layering your administrative access. For example; Sally is the IT Admin. In many environments we encounter this means her account ‘Sally@company.com’ is a Domain User, and a Domain Admin. Since her role is also administrating the Windows domain it is a fair assumption to make that at some point in time she will have logged into most of the systems on the Domain. Which would mean that the majority of systems on the Domain potentially have Domain Admin credentials sitting in clear text right now. This means that as an attacker you don’t even have to worry about tricking an IT employee, instead if you acquire a shell through compromising a customer service rep through spear phishing you can potentially have immediate access to admin passwords.
Back to layered accounts, and how we can reduce the impact. Instead of one daily driver let’s propose that Sally sets up three accounts, ‘Sally’, ‘SallyIT’ and ‘SallyDA’. Let’s propose that ‘Sally’ was only used for daily business functions, email, working on document, etc. Furthermore, ‘SallyIT’ is used for assisting with non-Domain admin tasks on member servers and workstations, and has a higher privilege level to handle installing software, and making changes. Finally, ‘SallyDA’ is used to log into Domain Controllers ONLY! When following the layered account approach this means that a full domain admin credentials would never be exposed through Mimikatz unless the attacker had access to a Domain Controller already.
Configuration and Patching
I focused on one part of KB2871997, but Microsoft has implemented further steps to help you prevent credential theft. They fall under the same caveat as before; however, as an educated attacker with local admin will be able to still carry out “pass-the-hash”, or password cracking on the hashes stored in memory.
The second part of the KB that applies specifically to Mimikatz style attacks was a new login procedure for RDP access. This new login can be initiated by adding the switch “/restrictedadmin”. When using this switch the user will not have their credentials stored in memory on the remote machine. This switch is also only available to members of Local Admins, not Remote Desktop users. This login method is still susceptible to pass-the-hash and pass-the-ticket style attacks, so it is one that should be researched by IT staff before determining the benefits versus its own inherent risks.
The last section I wanted to talk about in this post is covering Windows Protected Users. Introduced in Windows 8.1 and Server 2012 R2 (backported via KB2871997 to Windows 7, Server 2008 R2 and Server 2012) Protected Users serves to add another layer of credential theft protection to domain users. Domain controller protection for members of protected users will only work on Server 2012 R2 functional level or higher. The exact details of how Protected Users work are beyond the scope of this post, but I encourage you to read Microsoft’s paper on the feature which is included in the additional reading. Essentially it changed the default behavior for all Microsoft Authentication Methods, and disables WDigest without a registry change for users that are a member of Protected Users.
Protected users sound like an end-all solution to the problem, but as we have seen with many of the Microsoft patches it has limitations. Protected users still have their hashes displayed when Mimikatz is ran. This means that password cracking and pass the hash attacks are still on the table. That said any account you want to protect I would advise placing in this group. Please do this during testing windows to ensure it does not break any day to day functionality.
At the end of the day, the only true solution to Mimikatz is reducing your password footprint by reducing higher privilege levels to accounts that don’t need it, and implementing a layered account approach.
Authored By: Greg Peterson, CEH