In this episode, we’re gonna talk about cached credentials, something that everybody talks about, but not that many people know how they actually work.
Cached credentials, or maybe we should say cached logon data, this is a piece of information that when we logon when the network is not available, we compare with this data and then this is what makes it possible to logon to the operating system.
It is absolutely important to know how they work and the reason why it’s very straightforward because we’ve heard from many different customers and so on in many different articles that what you should do is to change cached credentials to zero or one.
But seriously, in the current time, there is no reason to do it and I would love to explain how it works and 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 details, 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 logon to Windows 10 client with the password: P@ssw0rd.
The reason why 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 logon. We have, right now, actively logged on to the domain, which means that we did not use cached logon data. By the way, you can always check in the security log, what kind of logon type you used. Each logon type has it’s 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
What we will do, I just want to show you something interesting related with data protection API.
I will open Chrome Pass – one of 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, of course from the data protection API perspective, as long as you logon 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 because it’s a little bit easier to explain. It makes the situation a little bit more clear so that everybody gets, of course, the concept of the Cached Logon Data.
I’m going to restart it right now. 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 passwords hash. So this is something that was saved in the registry of, for example, Windows XP in the past. Right now, this value is more complicated, so this is MSDCC2.
10,240 is the amount 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.
So, we’ve got this. Next. Just repair your computer as usual when we are getting access offline. Troubleshoot, Advanced options and Command Prompt. At this stage, I will need to explain, of course, what kind of tools we’re going to be using here.
Changing cached credentials data
So, 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 a little bit of cooperation with Benjamin Delpy, has our own version of Mimikatz which is over here. Particularly, 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 bootkey is. Then, we do D: > Windows > system32 > config > security. The reason for ‘security’ is because this is the place where the Cached Logon Data is. Next, the parameter that is quite important over here is the /kiwi. The reason for this is because, 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.
Okay, so let’s do that.
So, that 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 that next time when we reboot, we’re going to be actually using a different Cached Logon Data here.
So, let’s have a look. File, settings. What we will do is to simulate a situation where we’re going to be logging on with no network with that, as we call it, cached credentials. So, we’ve got here, exit and we are able to close the console, of course. Here we go. Then we reboot.
At this stage, we should be able to, of course, logon with the pre-calculated value because it’s the philosophy. It’s just the thing that we’ve got in the registry. The question is: Will we be able to see the password that user stored in the browser? That is a very interesting question because we’re going to be logon, obviously, with a different password.
So, let’s have a look. We are getting there slowly. Here we go. Let’s find out. First of all, I want to logon with the password that we had before. Yeah, so password: P@ssw0rd.
This is the password, I just press Enter and as you see, this time, the password is incorrect. Yup, exactly. Because 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.
So, 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. The reason why is taking a moment, it’s 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. So, that’s the first thing. Even though someone overrides Cached Logon Data, this person is not able to get access to our data protection API protected data.
Secondly, how does it look in a case of the registry? Well, whenever we get into the registry and we want to open the security hive, we cannot open it. The reason for that is simple, here we’re just a user, so obviously, we cannot. Here, we cannot even see, basically what is happening with the permissions.
So, what we will do is to run the console.
Here is Command Prompt with administrative privileges, so I’m going to logon over here. What is really funny is I’m logging on here also with the password Mimikatz because we have overwritten all of that Cached Logon Data, including domain administrators, for example.
Obviously, we all know that domain administrator shouldn’t be logging on to the machine. It’s just the demo machine. Okay, so we got it regedit. Even though here, 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, of course. 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. Lovely.
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, of course, show you, which value this refers to in this demonstration. 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 domain controller is not available)”.
As you see, by default, it’s 10 logons. So, when we refer back to this place, it is indeed 10 logons to be cached and guys, let’s 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.
So, in this case, in security, think about comfort. It’s good to hear.