KDS Root Keys and Where to Find Them

This talk will be about on premises Active Directory, so I apologize that we won't mention word cloud in this session. And there also won't be no AI mentioned in this session. Well, actually would be, because a lot of the research I did was done using AI, and AI helped me be be faster, specifically GPT codecs and OpenAI cyber model, you know, the model which doesn't have any ethical boundaries ideal for working with KDS root keys. Okay. So let's let's dig into that, and let's look at the agenda. So I will give you a very, very brief introduction to to KDS root keys. Actually, please, who's already worked with KDS root keys? Who's worked with that technology? Okay. Thank you. Thank you. I'm especially happy that people from Microsoft have have raised their their hands. Well, I wouldn't have thought otherwise. Who has already created a new KDS root key in an Active Directory environment? Okay, thank you. Not too many hands. Well, you don't do that on daily basis, right? In most environments, you do it once, tops. Well, we'll talk about that. Then we are going to talk about some attacks against managed service accounts, so we are going to look at golden GMSA, golden DMSA with some twists in compared to what was previously published. And then we are also going to look at Group Data Protection API or DP API NG, which also uses KDS root keys to encrypt BitLocker and DNSSeg and asp dot net secrets and so on. So let me let me first look at some introduction to KDS root keys. So this is where KDS root keys are stored in Active Directory. It's in the configuration partition, so anyone who wants to modify anything there needs to be an enterprise admin in an Active Directory environment. Yes, so it's hidden here in configuration configuration services and so on. There's another location there, group key distribution service server configuration, where you can change the cryptography, where you can change the defaults, which are then used for key derivation. And I'm I'm really really curious. Has anyone changed the default? Has anyone changed the cryptographic defaults? No. Nobody. And and I I didn't think so. May I ask you, Steve, Linda, have you seen anyone actually change the defaults? Has anyone seen No. Yeah. Nobody changes that. Okay. Thank you. Then there is a service related to KDS root keys running on each and every domain controller, which is called Microsoft Key Distribution Service, which implements an RPC interface, an RPC protocol, and that protocol only has one single call, and it's called get key, which clients service can call over the network and it has a lot of lot of parameters which play some role in key derivation from from the master keys, from the KDS root keys. First, the most important parameter is which KDS root key to use, the ID of the KDS root key. Then who would be the target, who would be able to decrypt the data. So there would either be a security descriptor or just security identifier, a set of the target. And then you have three numbers, layer zero key ID, layer one key ID, layer two key ID, and these are derived from the current time, from the current timestamp, basically, and there is just a mathematical function which drives those three numbers from the timestamp timestamp at the at the generation or at the at the calling at the time of calling the function, typically. And then you have some output, which is a key derived from that KDS root key with all those parameters. And now how could someone get a KDS root key? Well, the most obvious approach would be using the LDAP protocol. If you are an enterprise admin or if you are a domain admin and easily elevate yourself onto an enterprise admin, you can get the clear text value of a KDS root key. And so it depends on on the security of of Active Directory. If you are an enterprise admin, you can obviously do anything with AD. Another approach would be using the desysync attack, using the replication protocol where it can also replicate KDS root keys from DC. Administrators, domain controllers have this permission, but I've also seen SharePoint Enterprise having the permission, the replicating directory changes all permission and it could then grab the KDS root keys, clear text value. And the worst case scenario is when an attacker gets hands on a backup of your domain controller, the NTDS dit file, well, the keys are stored in clear text in that database file. So we obviously need to protect those as well. Here is an example of what you can do with the ds internals PowerShell module of mine where you run this command, get ADDB KDS root key, you give it a path to the NTDS database, and it shows you some info about the KDS root key. This is the clear text value of that key, and below that you you see some cryptographic parameters, some crypto algorithms. But the key, the clear text value is the most important one. Okay. So this was the the introduction, very brief introduction. Now let's imagine the attacker has already compromised the Active Directory or a backup of Active Directory to some extent. They already have the KDS root keys. Now what can they do with them? And as already mentioned, one of the things they can do is deriving managed passwords. Passwords of group managed service accounts or of delegated managed service accounts. Some research on this topic was previously published by Semperis themselves by Yuval Goran, and their approach was online over the over the LDAP protocol. So I extended it a little bit and I can do offline attack against that. Using the get ADD, get active directory database service account, you give it a path to an NTDS DIT file, and what it returns to you is the information about all group managed service accounts and delegated managed service accounts, including some information about the passwords, some some metadata when it was generated last time, the parameters, input parameters for the key derivation, the layer key IDs, the KDS root key which was used to derive the managed password of this account, but most importantly, it does an online calculation and here you see the anti hash and Kerberos keys at the current time. And one of the optional parameters to to this command is the actual timestamp, actual instance where you'd like to do the calculation for. So you can ask it, what will be the password of this service in two years, basically. But by default, it tells you the current value, the currently calculated value. Here is a modification of that. You take a backup, a very old backup of an entity as did file, a ten year old backup, And since then, the company might have created new group managed service accounts. So you get the information about the accounts from Active Directory over LDAP protocol, which a regular user can do. You get the managed password IDs and combine it with the cryptographic value with the KDS root key from the Active Directory database, and you get the current value. The results were the same as previously. We just use different data source for that. Okay. So this was a minor twist on the golden GMSA and golden DMSA attack. Now let's look at group data protection API. Some research on this topic was previously done by secure and specifically by Paula Yamushkevich. So dpAPI next generation allows you to encrypt some data. It's a Windows API which applications and some Windows components can use, And you can configure multiple recipients, multiple decryptors, like who can then decrypt the data, who can who can see the clear text values of the data. And one of the protectors, one of the protector types there are security identifiers, which will be our main scope. And the most known, the best known feature of Windows which uses that are PFX files. When you are exporting certificates with private keys in Windows, it allows you to to say which groups or users would be then able to import the certificate. It then uses dpapi ng to encrypt a random password, which is then used to encrypt the certificate, which is then used to encrypt the pfx file. Very nice feature, would recommend you to use that feature because yeah, it's better than passwords which are typically like not randomly generated by users. I've seen organizations use the same password for each and every certificate they have backed up, so that would be a terrible idea. So yeah, use that feature. On the other hand, be aware that if you have access to KDS root keys, the passwords can be decrypted, they can be unprotected. So here is a partial command which first fetches all PFX files from a directory and then pipes it into my own partial command which decrypts them using provided KDS root keys. And those KDS root keys can be fetched again over LDAP, DC sync from NTDS DIT file, doesn't matter. What you get is the output as the result are the clear text passwords which you then copy and which you then can can use to decrypt the private keys, you then can can use to decrypt those certificates. Yeah, so as easy as that. Another feature of Windows which uses dpapi ng optionally is labs, Windows labs. Who uses Windows labs? Most of you, thank you. Those who have not raised their hands, you should consider using Windows Labs. Yeah, it's a it's a great feature. We love that feature. But you should be aware of the security of that feature and what the limitations of that are. Yeah, so it can be used to encrypt local admin passwords or domain controller or directory services restore mode passwords. And then if you have the right permissions in Active Directory, you can use the Active Directory using the computer's console to get the current password, current admin password, and also username for a target computer, for a target system. Internally, several attributes in Active Directory are used to store the lab's data, including the MSLabs encrypted DSR and password, and so on. And you see some value there, but the value is encrypted using data protection API n g, which serves as a second layer of protection. Yeah? So first layer of protection is permissions, like who has the read permissions to read those attributes, yeah? It's hidden to regular users, to regular authenticated users. By default, you need to be an admin, but then there is a second layer configurable by group policy where you can say who can then decrypt the data once they were able to read the data. And if you have the right access, if you have the administrative permissions, you can query LDAP to fetch all the accounts, all those attributes related to labs. And if you also have permissions to access the KDS root key, you can use this command of mine which then shows you all the labs data including the cleartext passwords decrypted from Active Directory. It does it on the fly automatically. Or you might have access to an NTDS DIT file. An NTDS DIT file contains both the encrypted data and the keys used to encrypt them, the the KDS root keys. So again, the tool can automatically combine the data and shows you show you the Cleatex password. Last but not least, we have the DC sync attack. We can use the replication protocol to replicate computer accounts from Active Directory, again, including the lab's related attributes, and the tool then automatically uses the replication protocol to also replicate the KDS root keys which are currently missing in its cache, and as soon as it fetches them, it again decrypts all the data and shows you those clear text values. Okay, so that was Windows Labs. Another Windows component or like Microsoft component is ASP dot NET Core, which can encrypt, optionally encrypt connection strings and other secrets in application configuration files. And one of the technologies that can be used for that is again, data protection API NG. So let's look at a typical application settings dot JSON file of an ASP dot Core application. What you would see there would be a secret section, and here we see some Oracle database connection string, but we don't see the clear text value of that connection string, we see some encrypted data there. Luckily, well, with the majority of applications, you would actually see the clear text data, which wouldn't be good. But this is a properly configured application. And you also see the data protection API ng descriptor, meaning what permissions you need to have, what groups you need to be a member of to be able to decrypt that configuration file, to decrypt the connection string. Then you will find another file on the file system called encryption key file. It's again a JSON file which contains a key which encrypts the connection string and this key is then actually encrypted using data protection API NG. So there are there are multiple encryption layers like like an onion. What can you do then? You can use this PowerShell command of mine, unprotect dpi ng data, where you would paste just the blob from that file we've seen previously. It automatically fetches the required KDS root keys and shows you the clear text encryption key then. And then you can use this tool, secret tool, you give it the clear text encryption key, you give it the data retrieved from the application settings JSON file, and what you get in the end is the connection string including the username and password for connecting to the Oracle database. Yeah, that's what the attacker is looking for. Okay, so this was the unofficial way, unsupported way of decrypting the connection strings. Okay. Let's look at another technology which uses KDS root keys, and that would be BitLocker. Who has ever used BitLocker SID Protector? Has anyone ever used that capability of Windows? Thank you. Thank you very much. So if you are using failover clusters, if you are using cluster shared volumes on those failover clusters and you want to encrypt the disks using BitLocker, then the sitprotector would be your only option, or it it at least used to be the the only option in the old times. And if you then launched a built in tool in Windows, manage BDE, manage BitLocker disk encryption, it would have shown you the list of available ways of protecting the hard drive and next to the TPM, TPM plus PIN code password and so on, you would also see Active Directory account or group which you can use to encrypt the hard drive. And in the background, it uses data protection API NG. So let's see how it works from the view of a person, from the perspective of a person who has access, physical access to a hard drive, which is encrypted this way. You plug it into the computer and you see it's encrypted using BitLocker. Use the manage b d e tool to list the protectors and it shows that one of the protectors is the seed protector and we see the group which protects the hard drive. Based on the rate, do you know what group that is in this specific case? What is 512? Domain admins. Yeah, right. Thank you. So, but then you try another command, manage bd unlock. You try to unlock the hard drive with that specific SID, and you get a response telling you that it failed to unlock the hard drive, that you are unable to decrypt the hard drive because you are not a member of that particular group, you are not a member of a domain admin. At the same time, it also generates this event in Windows event log telling you that the unprotected key operation failed and it used the seed protector, it tried to use the seed protector. When you then click into the details of the event, you would see information, a binary data structure telling you the specific key ID which is encoded in the metadata of of the BitLocker hard drive. And you can then use this PowerShell command of mine to decode that data structure and to tell you some information about the protection. And here it tells you which root key ID is required to decrypt that hard drive, And it also shows you those other parameters, the key IDs from which domain and forest that hard drive originates and so on. Next, you can use those parameters, combine them with the KDS root key, derive a second layer key from that, and cache the key in an undocumented location in your user profile. Okay? So in your user profile, there is application data local Microsoft crypto KDS key and some IDs, private key, another ID, and you save the key to this location using undocumented APIs. And this is a place where Windows caches the derived keys. Okay? So we we have manually pre cached the derived key. And we can then try to rerun the manage bd unlock tool, the built in command in Windows, what do you get as a response is successfully unlocked, successfully decrypted the hard drive, and you would also see in control panel that the hard drive is decrypted and you can then access the files on the hard drive. And the the computer you are running this on doesn't need to be joined to an Active Directory domain. It it also, the the APIs work in a work group. You just need to place the derived key in the right directory and the BitLocker component will automatically find it there or the data protection API NG engine will find the keys in the right directory. Okay. Let's now look at the DNS zones and add DNSSEC. Does anyone use DNSSEC in Active Directory environments? Couple couple of hands. Thank you, thank you very much. So we know that Active Directory is very tightly integrated with DNS, and you can store DNS data, all sorts of DNS data in Active Directory databases. It helps with replications, permissions, and so on. And I created a couple of commands which you can run and extract all the DNS related data from an Active Directory database. And it shows you all the DNS records which are contained there. And you can even use that in disaster recovery scenarios because you can export it into DNS zone files and run them on Linux or BSD servers without Active Directory at all. If your AD is not running for some reasons or you are waiting for Active Directory to get recovered. So this is something which can be extracted from the Active Directory database. But I'm specifically interested in DNSSEC related keys in zone signing keys and key signing keys. And they are all stored in the domain properties or DNS zone properties in an attribute called MSDS signing keys. Again, it's some binary structure and I've created a command called export ADDV DNS server signing key. You give it path to the database, a path to the output directory, and it decrypts all those keys and saves them into that directory structure. So again, you can then launch your own DNS server, provide paths to those keys, maybe convert the format of those keys to to some Linux supported format, and you have your own DNSSEC enabled zone and you can sign whatever you wish to sign and spoof, maybe. Okay. So this was DNSSEC. Any questions so far? Okay, so what you should remember from this talk? Well, you don't need to remember the exact commands which shown there. If you are interested in that, obviously it's open source, there is public documentation for that, but that's that's not the not the key message, that's not the main message. You should remember the technologies, the Windows components which use KDS root keys, obviously. You should be aware of these attacks. You should be aware that KDS root keys belong to the crown jewels of your Active Directory domain together with CUP, TGT, and some some other other sensitive secrets. And their security, they are only as secure as your Active Directory itself. So you should definitely protect them and monitor who accesses those keys if any malicious actors are trying to access them. Second thing you should do is doing rollovers, periodic rollovers of KDS root keys. Because otherwise, you might have very old backups to which people who no longer work in your organization might still have access. They are still able to decrypt some of the data, they are still able to derive the managed passwords for your systems. If it's a managed password for a SQL server, let's say, you can then use it to perform the silver ticket attack and you can authenticate as anyone against that SQL server. So the data is really sensitive and you should periodically generate new KDS root keys so that Windows starts using the new keys, so that the knowledge of the old keys doesn't pose such a huge risk. Some organizations do it on a yearly basis, some organizations do it on a quarterly basis like every three months. That makes a lot of sense to me. Some organizations tied to kerpt g t reset. So anytime you do, you you invoke kerpt g t reset, you also run the add k d s root key command, the built in partial command, which generates a new k d s root key in your Active Directory. Don't be afraid of that. I haven't seen any performance impact of you having multiple KDS root keys. But having said that, please never delete the old KDS root keys. Okay? That's one of the key messages you should also remember from this talk. Why? Because even if you generate a new KDS root key, Windows doesn't start using that new key automatically. Any data which is already encrypted, PFX files, BitLocker protected hard drives, they still keep using the old key. And if you delete the old key, you lose access to the data. With group managed service accounts, the default password rollover there is thirty days a month. And you still need to have the previous password valid as well. So if we were only talking about GMSAs, you should wait at least sixty days before you delete the old KDS root keys. But please don't delete them, ever. Yeah, that's the best practice. Some organizations who want the managed password rollover to happen sooner change the managed password interval from thirty days to seven days, I've seen an organization having a daily frequency of that, but I'm not sure if if that's the best idea. But the week, seven days, that made a lot of sense to me. So that the new KDS root keys start applying sooner than the default. And that's it. That's what I wanted to tell you about KDS root keys. Amazing.