In this episode, we’re going to talk about cached credentials and how they actually work.
Cached credentials, or cached logon data, is a piece of information – in case we log on, when the network is not available, data is compared, so it is possible to log on to the operating system.
It is absolutely important to know how they work and the reason why it’s very straightforward. We’ve heard from many different customers and so on in many different articles advice that what you should do is to change cached credentials to zero or one.
However, at the current time, there is no reason to do it and I would love to explain how it works. The very important factor is that we are the first thing out there that reverse-engineered the whole mechanism and we would like to talk about it in detail, and if there’s someone you can ask the question to, it’s definitely us.
In this episode, I will show you how cached logon data works, what is inside, how we’re able to overwrite it, and what kind of threat it exposes.
Above is how my screen looks like right now. I have here a user, Freddy Krueger, that’s going to log on to Windows 10 client with the password: P@ssw0rd.
I’m showing you this is because we’re going to be, obviously, working on the password. The first step is quite simple, and that is to log on. We have, right now, actively logged on to the domain, which means that we did not use cached login data. By the way, you can always check in the security log, what kind of logon type you used. Each logon type has its own number. If you are interested, then you can always search the MSDN for the logon type and you’re going to find appropriate information.
Explaining cached logon data
I show you something interesting related to data protection API.
I will open Chrome Pass – one of the NirSoft tools, which is quite simple but very nice. Here, we can see that Freddy, of course, saved his password in the browser when he was logging on to. Whenever we are thinking about logging on with Cached Logon Data from the data protection API perspective, as long as you log on with the same password it doesn’t really make a difference. The first thing I would like to show you is that, whenever the password changes, it makes a difference. The second thing, however, is if our cached logon data password is really safe.
So, let’s have a look. First of all, at a certain point, we’re just going to close it and reboot this machine.
Over here, as you see, I have Windows Installation Media connected and we’re going to reboot this machine from the installation media. We could do it online, it doesn’t have to be offline – please remember that. The only reason why I’m showing it this way is that it’s a little bit easier to explain.
I’m going to restart it right now and we’re going to boot from the Windows installation media in order to be at the stage where we are able to overwrite a Cached Logon Data. That’s going to be another situation. I’m just going to press any key and we’re going to be getting to Windows PE where I’m going to launch the custom tool to overwrite the value in the registry which is the Cached Logon Data.
Now, what you see in the back, or just behind the virtual machine, represents how Cached Logon Data looks like when they are decrypted. This is clearly a value in the registry, which I will show you. We call this value MSDCC2 and this value is absolutely not reversible. If you’re thinking if we can, for example, crack it, the answer is: yes you can but that is actually quite a long process because one of the components of MSDCC2 is something that we call DCC1. DCC1 is a hash that is calculated on top of the username and the user’s password hash. So this is something that was saved in the registry of, f.e. Windows XP in the past. Right now, this value is more complicated, so this is MSDCC2.
10,240 is the number of iterations that we’re running this function. Basically, it’s quite a complex value but on the other hand, there is nothing against generating rainbow tables but it’s just going to be a lot of data.
The next step is to repair your computer as usual when we are getting access offline. Troubleshoot – Advanced Options – Command Prompt. At this stage, I will explain what kind of tools we’re going to use here.
Changing cached credentials data
I’m going to get into the D: drive, CQTools and over here we’ve got CQUREMimikatz and as you know, our team, due to cooperation with Benjamin Delpy, has our own version of Mimikatz which is over here. We are really proud of it, in the case of a Cached Logon Data (cached credentials), because our team reverses engineered them and this is something that you’ve got right now in Mimikatz.
Moving forward, I need to use the lsadump::cache. We are specifying the place where the Cached Logon Data is in order to overwrite them. So, we do Windows > System32 > config > system. The reason for this because of the place where the boot key is.
Then, we do D: > Windows > system32 > config > security. The reason for ‘security’? This is the place where the Cached Logon Data is. Next, the parameter that is quite important over here is the /kiwi. If you don’t put it the tool will just display data about logon data you’ve got there. Of course, as we mentioned already, without a password, you cannot really get that. What /kiwi does is, by knowing the algorithm, which you have displayed on the screen right now, it generates it’s own value and then puts it in the registry.
Kiwi created us a pre-calculated value, MSDCC2, that has been encrypted, not directly but indirectly with the boot key, and put in the registry so the next time when we reboot, we’re going to be actually using a different Cached Logon Data here.
So, let’s have a look at file settings. What we will do is to simulate a situation where we’re going to log on with no network with that, as we call it, cached credentials. We’ve got here, exit and we are able to close the console. Then reboot.
At this stage, we should be able to log on with the pre-calculated value because it’s the whole philosophy in it. It’s just the thing that we’ve got in the registry. The question is: will we are able to see the password that the user stored in the browser? That is a very interesting question because we’re going to log on with a different password. Let’s find out. First of all, I want to log on with the password that we had before: password: P@ssw0rd.
Press Enter and as you see, the password is incorrect. This is the file that we changed. Mimikatz is going to be the new password as you see and at this stage, we are logging on. So, Cached Logon Data can be overwritten. If it’s about cracking it, you need a really long time. Currently, this is a solution that is considered safe.
First of all, let’s have a look at if we can see the user’s secrets by running Chrome Pass. That takes a moment because we are looking for an appropriate master key that will be able to decrypt. Unfortunately, our password does not allow for that because it’s a Mimikatz password, not a P@ssw0rd password.
That’s why this value over here is empty. Even though someone overwrote Cached Logon Data, this person is not able to get access to our data protection API protected data.
Secondly, how does it look in the case of the registry? Whenever we get into the registry and we want to open the security hive, we cannot. The reason is we’re just a user, so obviously, we cannot. Basically, we cannot even see, what is happening with the permissions.
What we have to do is to run the console. Open Command Prompt with administrative privileges and log on over here. The funny thing is I’m logging on here also with the password Mimikatz because we have overwritten all of that Cached Logon Data, including domain administrators.
We all know that the domain administrator shouldn’t be logging on to the machine. It’s just the demo machine. We got it regedit. Even though, I’m not able to get access to security and if we find out permissions, we can see that administrators have special permissions. The system has full control. I could take over that particular registry hive but let’s not do it this way. It’s not a very good practice.
We’re going to get into CQTools and that’s the place where we’ve got psexec, -s -i -d cmd.exe, to elevate to the local system. That takes a little moment.
That is where we are able to run the registry, so regedit. We could use it also to switch around the two of them but let’s keep it clean.
From the local system perspective, you are able to get access to cached logon data over here.
That is the place where we can see that NL$1, 2, and 3 contain Cached Logon Data. So, that is what we were talking about and that value over here, yes, as we see it, is an encrypted Cached Logon Data by the indirect boot key. That’s why system hive was absolutely necessary in order to get access to the decrypted value but of course, we are not decrypting the password.
At the very end, let’s go to policy secpol.msc. It doesn’t matter if it’s local or domain, the value is basically the same. When the policy opens, I will show you, which value refers to it. So, in the group policy settings, in the local policies, in the security options, we’ve got here a value that says, “Interactive logon: Number of previous logons to cache (in case the domain controller is not available)”.
As you see, by default, it’s 10 logons. When we refer back to this place, it is indeed 10 logons to be cached. Remember that because we’ve heard so many different stories about Cached Logon Data as I mentioned: everybody’s really talking about but nobody really understands 100%, how it works. This is quite unfortunate and people here in the policy changed this value to 0 or 1, or whatever. It doesn’t matter, really. Don’t forget that I can always create the Cached Logon Data for myself, so, even though you say zero, it doesn’t matter because I can create this value and then logon with my data. Or I can overwrite this value, it really doesn’t matter.
Why wait to find out what data an attacker could extract from your hard drive? Investigate for yourself by taking our intensive new training: User & System Secrets: Cybersecurity Data Extraction.