Listen to Paula Januszkiewicz, a cybersecurity expert, and Jasson Casey, CTO of Beyond Identity, about the exposure passwords cause and how to fix their vulnerabilities. 

Justin Mingo

Welcome, everybody, to Password-Palooza. This is our second webinar. Here today we have special guests. Firstly, our own CTO, Dr. Jasson Casey. And also accompanying him is Paula Januszkiewicz. 

She really needs no introduction. And for that matter, if you guys have any questions or whatnot, then please enter them into the Questions tab and we will get to them at the end of the broadcast. Otherwise, please enjoy. 

With that, let me turn it right over to Paula. 

Paula Januszkiewicz

Perfect. Thank you so much, Justin. As always, very, very nice. I will share my screen first and then, of course, let's get immediately to our webinar where we are talking about passwords. And that is actually one of my favorite subjects to be sincere because there are so many places where we are able to extract them. 

And also there are so many ways how we are able to get rid of them and also how we are able to secure the process where we are actually using the password. So, very, very briefly, let me introduce myself. I'm Paula Januszkiewicz, of course. And what I'm doing for a living, I'm the CEO of CQURE, a cybersecurity consulting company that I have started 13 years ago, which sounds like quite a long time. 

But that time, of course, passes super fast and what we are doing for a living, it's penetration tests, but not only that, but as well the incident response and forensics, like, as well building the cybersecurity solutions strategy approach and so on when cooperating with very CSOs, also implementing security solutions. 

So, we are simply a cybersecurity company. My job, though, it's quite straightforward. I'm the CEO. But even though I got a business role, all the time I engage with customers with projects, and that is what I'm doing and what I've been doing for my whole life being engaged in cybersecurity. And also I am speaking at the various conferences, including, for example, conferences like RSA where I was delivering a keynote in San Francisco, or Black Hat, which are technically for all three locations in the world. 

So, like in Asia, like in U.S., and also like in Europe. I'm sharing information about our research tools and so on, various findings. So, whenever we are thinking, of course about places where we are able to extract passwords, it'll be lovely to see how sometimes easy it could be. But first, let me give you a little bit of a background regarding the impact on the cybercrime on organizations and also a little bit of a perspective on how our customers and also maybe some of the companies, you know, maybe your own company are engaged into the cybersecurity strategy and what kind of things we are observing right now regarding, of course, the pandemic situation. 

So, whenever we started, whenever the pandemic started, there is an organization called CSUN, which is actually part of the Department of Homeland Security. And as you can see that slide dates on March 6th, 2020 because this is the press or their own release from their websites that they published when the pandemic started. 

And these guys said that, "Hey, because pandemic it's starting, we're probably going to observe lots of vulnerabilities appearing, increase vulnerabilities in general, increase attacks, and phishing attempts." And definitely, whenever you are thinking seriously about cybersecurity, you should take a high-end approach to cybersecurity. 

And that is basically what we see that's technically happened. Whenever we summarize, for example, pandemic with the US FBI report, we're able to see that during the pandemics, that amount of attacks has increased in 300%, which is also quite interesting because we could be thinking that doesn't mean that we are dealing with such a serious situation right now that the attacks are more advanced and so on, or maybe the problem is somewhere else. 

And definitely, we can say that, first of all, what happened is that organizations switch overnight to the remote work, and that, of course, affected various employment situations, healthcare, education, infrastructure services, and so on. They had to rapidly transform just to function remotely. 

And some of the organizations, they maintain continuity by moving even an entire infrastructure, for example, to the remote work. So, for some of them, it was possible. For some of the organizations, it wasn't possible. But definitely, what it created, it's a huge demand for virtual processes, remote cooperation on the scale that technically we have never seen. 

And also Satya Nadella from Microsoft he was saying that their company, so Microsoft, has seen two years' worth of digital transformation into two months. And that's pretty amazing, we could say. And that kind of a performance is absolutely outstanding. But what we need to remember is that anytime a process or a function goes digital, it creates a potential cybersecurity vulnerability, especially when so many systems are implemented so quickly. 

And we have technically seen during the pandemic so many examples, one of the examples that really was shocking over there was the case of solar winds where it appeared that they have distributed, in short words, the OEM software that was unfortunately impacted by the hacker's activities. That is, of course, not good, but when we think about the reason for that, the reason was very straightforward and that was a user account with a simple password that could be guessed by performing the regular password spray. 

So, why they became a target? Couldn't they become a target, for example, two years earlier, or something like that? Maybe they could. But whenever we were dealing with situations of pandemic when people were sitting at home, then automatically hackers started to attack more systems because maybe even they had nothing to do. But when we take into consideration the Verizon's report, and this is actually one of my favorite reports that I'm always reading. 

So, this is the 2020 data breach investigations report summarizing 2020 year. Then you can see that 86% of attacks for that year, they were actually financially motivated. And which is also quite an interesting perspective taking into consideration the average salary for the successful ransomware campaign, which is approximately $90,000 per month of income for someone who sends just massively lots of emails, but not only that, also, for someone who scans companies for known vulnerabilities, known misconfigurations.

Simply, we could name them low-hanging fruit in order to be able to, for example, log in to the organization's network by using a certain username and the password or something like that same story was happening for Colonial Pipeline. So, that later when we are in this company, we are dealing with a new approach nowadays, which is actually called a human-controlled ransomware. 

And that human-controlled ransomware might come not only from the simple password, for example, but it might also come from the situation where we've got, for example, hackers trying to get access through phishing when the user execute a certain macro, for example, or in general code that they don't know. It might come from vulnerabilities or the best part. 

This attack might also come even from the supporting company. And that was also the case of our customer during the pandemic where their infrastructure has been affected by simply the vendor. So, there was a vendor supporting their IT in general. So, they were administering partially their active directory. 

And what happened is that that company was attacked. And hackers notice that they are supporting our customer, so, eventually, they went immediately to the domain admin's access because this is the access that the vendor company had. And then eventually encrypted their data. So, this was quite a drastic situation to deal with because I can tell you for sure that that company had to actually pay half a million euros, so €500,000 for the ransom that was after negotiating it down just to get the decrypter that wasn't really working for 100% of the data that was encrypted. 

It was actually working for approximately 85%. But the problem was that, of course, it took time and so on, and I was actually working at that site at the time for fixing the hackers' code in order to make the encryptor to work on 100% of data. And we managed to do it eventually, but that was also quite an expensive operation. So, what we are observing right now are regarding various topics and the ways of how hackers are getting in. 

It's, of course, not only through passwords, but it's also for example, through phishing activities, through misconfigurations, through vulnerabilities, but passwords or maybe generically saying identity, it's definitely a number one thing to protect right now. There's nothing more important than in general identity protection. And whenever we are in the attack, in order to perform the lateral movement, in order to go further and so on, really, we are doing that by getting some kind of an identity. 

And the more passwords, of course, we use, the more misconfigurations like this, like, regard, the more or the less multi-factor authentication we got, the more hackers are able to get access to our environments. And then they are there. 

And that is also quite a big problem, which is, of course, for the different type of conversation. But in general, whenever we are thinking about the stats that are here presented by the James Comey, the former FBI Director, he said that 200, it's a median amount of days that hackers are present on the victim's network before they're getting discovered, which we could be thinking, that's quite a lot. 

But think about it. Within the Colonial Pipeline, being such a great and big company, then having hackers accessing that big company through just an insecure account just because we don't have a multi-factor authentication over there, then it clearly presents that there is a bigger problem of passwords sometimes than I think, and especially that little mistake made them to pay a couple of million dollars. 

There was also negotiation and also data recovery done, and so on, but still that was something that actually cost them quite a lot. So, question is, how many issues we got if it's about passwords? So, do we have passwords that are simply used within the organization that lead to problem? Sometimes we've got situations where passwords could not be avoided. 

And that is something that I would love to talk about because sometimes we would love to be great and do not use really passwords, but we don't have the possibility because, eventually, the passwords are just the only option to configure something. So, that is why we need to take into consideration the way of how we are using identity in our networks. So, this is what we're going to be getting to. 

Now, whenever we are thinking, of course, about the background for the passwords and, in general, like, how these talks are happening, then there are a couple of things we could at the very beginning put in there just to make sure that, of course, passwords are not the only ones or not the only method that is used by the hackers to get in. 

Yes, we got a possibility to get access through social engineering, so, phishing, fake applications, typosquatting, Wi-Fi impersonation, sometimes convincing a supplier to do something. But as well as, for example, just malware infection that's coming from somewhere. So, it could be for example, by leveraging things like that kind of a USB device, which I'm showing them to the camera right now. 

That's the Digispark. And again, I got a couple of those. So, this is the Rubber Ducky, which is a little bit simpler. So, eventually, there's so many ways how we are able to get access to, but passwords, of course, and various misconfigurations on many levels, they are the mandatory part for the attack in order to function, in order to spread. 

Yeah. So, that USB could be point of entry, phishing could be point of entry, but eventually, the next stage is passwords. So, this is what we're going to be focusing on. Okay. So, as always, let me get to demonstrations. This is also my favorite part where we're going to be discussing where we are able to extract operating system and under what conditions and that's also important to know. 

Sometimes we're trying to get access to the infrastructure from zero to hero. Sometimes a hacker is already a user. And basically, the next stage is to extract just simply more passwords. And where I would love to start with, it's going to be quite generic because whenever we are extracting the passwords from the operating system, we are actually dividing them into two spheres. 

One sphere is the passwords that are basically protected by the system. And another one it's passwords that are protected by the user. And then by the user on two levels. 

One level is going to be the local user and another level is going to be the domain user. So, anyway, let's start our adventure, if you don't mind with the passwords in order to learn where and how we are able to extract that particular data. Okay? So, let's see what we got. First of all, we're going to be getting into... So, this is simply Windows Server. 

And I got a couple of things that are here misconfigured. And so let me actually get into the PsExec console over there. So, one thing, for sure, is that whenever we are thinking about the various places for the operating system, then, basically, we've got things like services, for example. And whenever we are setting up the password for the service, it is also important to know how we are able to identify where these passwords are. 

So, for example, for that one, I'm going to be putting on the password there. So, I'm going to change the configuration. Now, because we are changing configuration over there, it would be lovely if we could get into… Let me just go into the tools. And I would love to start that process monitor where within the process monitor, we will be on that stage setting up, yeah, just a regular monitoring here. 

I think let's just start with a default filter because I'll show you also how to filter out various things that potentially are not interesting for us. So, here I'm going to use a regular account. And before I had configured with managed service accounts, which is also another option, but for now let's focus on the classic account. 

And that's, by the way, a mistake that we see because I think we should call it a mistake, is actually something that is happening in pretty much every organization there. Or saying it differently, I've never seen an organization that did not have that problem. 

And I did literally hundreds of panthers in my life. And there's always something like that. Especially because in the past, so to say, it wasn't that obvious to not to have an account like this because from Windows Server 2012, we've got a group managed service accounts, and that's the moment where we are able to use them. Previously, we couldn't. Yeah. 

So, here we go. For the past 10 years, we've got more or less the possibility to configure group-managed service accounts, but not also every application might support it. So, just saying. Anyway, let's see what we got. We've got over here that account that we have configured. And at the same time, there was a process monitor running in the back demonstrating us where that data is stored. 

We can stop monitoring, of course. So, this is the setup here. So, we've got various events that are here monitored. And at that moment, we will be able to actually filter out our output here. So, hopefully, yeah, we got this, I think. 

Okay, great. So, what we're going to do. We're going to do "Category is right." Good. Add. Okay. And also we can filter out, exclude, exclude, various things that we are not interested in. 

Now, the settings for the services are stored in the registry. Of course, eventually, we're going to get to this point, but because we know, it will be easier for us to cut off all these things that are not registry-related. This repeats itself and it's definitely nothing useful here. 

And then the next stage is to analyze what as we got Explorer is definitely not engaging the service settings. And yeah, it's great. I think we found it. Yes. So, over there we've got a statement that first of all whose store services configuration is services.exe. But there's also LSASS that it's storing and that's important, that system secret in the security hive, well, exactly. 

So, over there in security hive, we don't have only the service accounts passwords. There was more than that. But that is something that you guys need to know that that particular security hive can be read and usually it's leveraged by the local system. So, in order to get the system secrets, either you need to be an admin or you need to be local system in order to be able to extract it. 

And then easy stuff. It's for that particular service. If we do have a command line over there, I'm going to use PsExec to start at that point. That local system and…the local system console and then the next part is, of course, to run the tool, which is the tool, CQSecretsDumper and then service and then PJ service. 

And then, of course, we're getting the password. Yeah? So, there are a couple of issues around it, of course, because even though you will change the account, group managed service account and so on, the password still stays there, so there are different conditions under which we are able to extract that. But within that simple approach, if we got a service running as a regular account, then here we've got a possibility to extract that password from the registry. 

Same story happens when we got, for example, scheduled task. Same story happens where we've got Wi-Fi. Same story happens, for example, where we've got IIS-related secrets. I think we can also have a look at this to show you what we mean by the system secrets and how easy is to actually extract them. 

So, here we've got application pools. So, that's within the IIS. And I've got a couple of application pools over there. One of those it's called snow.com, snow.com. And that snow.com running as Freddy Krueger, of course, has somewhere storage configuration data, which we will be able to get, by the way, by getting into, at that point, next stage, which is the IIS configuration to see whether this is in a clear text or not. 

Yeah. So, we've got a system32\inetsrv. And then we've got config folder and notepad applicationHost.config and over there, If we get into Freddy configuration over there, then you guys are able to see that this password is actually encrypted. 

It is also encrypted symmetrically. How do we know? Well, IIS. Windows activation service, Windows Process Activation Service only IIS provider. And that is also quite cool because IIS means symmetric key, which means where else is this key if not on that particular computer? 

And it is actually on that computer. And we are able to extract it by trying to understand who actually knows this password. And because IIS it's about SVC host, so an executive-level where, additionally, we run actually two services through SVC host. So, one is called World Wide Web Publishing Service, and another one is called Windows Process Activation Service. 

And having this in mind, we know that if Windows Process Activation Service is actually reading the configuration over here, then, basically, we are able to also extract that configuration by just querying the configuration of, in general, IIS by asking you the Windows Process Activation Service. 

It sounds, like, a lot, but eventually, that's a very, very simple process because in order to do it, we need to run the appcmd and then we are doing that list apppool, and then, basically, www.snow.com/text. And then we give here an asterisk to indicate that we are actually extracting all of the details from the service configuration. 

And that's it. So, long story short. Let's see. Here we've got the username, Freddy Krueger, and the password, password. Yeah. 

So, again, why is this in a clear text? Because Windows Process Activation Service loads this configuration and that's why we are having this password in use in the memory of the service. And if we just ask the service to provide us configuration, we are able to easily get it this way. Okay. So, I hope that that is clear. 

When we are thinking about some other options, how we are able to extract the password, then we've got even more possibilities and more and more. So, technically, every single time you store a password somehow in the operating system, we are able to extract it. And that is also the rule of thumb that if you store it somewhere, it's probably extractable and store it, meaning that it's not stored in a kind of like a hash value or something like that. 

It means it's stored in order to be used later. Yeah? So, that service account is a perfect example for that. But that's, of course, not everything. If we got various places for that user account to put on, we've got over here, that centralized certificate option. And that centralized certificate option over here, we can go to the Edit feature setting. 

So, that's the enabled centralized certificates option. And over there, we've got a possibility to configure the password, private key password. That password...it's for certificates. And these certificates can be centrally used in IIS for the HTTPS website. So, again, just another example where the passwords are, and then we're going to switch to the user analysis. 

So, here what we can check for, again, we can go to the ProcMon. And from the ProcMon perspective, we can again start monitoring. This time, we are monitoring only for the right access. So, that's why we got only 17 events showing up out of 138,000. So, it's a pretty good filter that we got. 

And over there within the IIS we're going to specify the password. And as simple as this, whatever the password is. Then here, we are able to see that, let's stop it, IIS particularly is engaged. And that password, you can see that it's actually stored in the registry. 

So, that's this private key password. And that private key password we can jump to. And over there, private key password is basically here. Yeah. So, it looks like Base64, looks like, yeah, but eventually, it's not Base64. Yeah. 

Well, it is for now Base64, but if you decode it, it won't show you the password in a clear text. It's not that easy. But it's also quite easy because knowing what kind of provider is used within the IIS, so cryptographic provider, we're able to extract the password. So, the next stage for the research over there comes to… And let me get into the PowerShell. Comes to the situation where we technically have to play with, well, the PowerShell to, first of all, use the cryptographic provider. 

And I've got a script over there. And then, basically, the next part is to use the keys or to first extract and use the keys that are stored within the IIS. Yeah. So, that's going to be the setup. Okay. So, a couple of comments here. Well, that's not really a script. 

It's just a set of commands that everybody can run. But what is important for us at that stage is that we, first of all, extract the keys that we're going to be using within the cryptographic provider. So, how to use that. And at that point, we're going to go to the Windows folder, Microsoft.Net, Framework64, version of framework. 

So, here we go. And then I'm going to a tool that is more often used by developers and IT pros, which are called aspnet_regiis. And then over there, we've got an option called -px. And that -px option, it's for the exporting of the private keys or, in general, keys from the IIS for, for example, immigration. 

So, if you want to remove the keys from one server to another, and so on, then you can do it and that's basically with option px. But before we actually use it, let me show you the full tool. And the tool has lots of features. But the second kind of portion of the tool, it's related to the configuration encryption options. So, again, encryption, again passwords. 

So, there's plenty of things we're able to use within the tool. Now leveraging the option -px, which is… Let me select it [inaudible] in the -px container file. So, we get an export and RSA keypair and so on. We've got a possibility to first of all name the container. So, this is IIS, Windows Activation Service key. 

And basically, the next part is going to be the file. So, we are exporting this to the C. And let's see what path is that. text.xml. So, let's do it. test.xml. And -pri for the export of the private key as well. 

And then eventually, that succeeded. So, long story short, over there, we've got a possibility to use that and export the private key that is used by the IIS in order to work on the configuration within the IIS. So, what will be the next stage? 

The next stage we can switch to the script already and/or to the set of commands. And first of all, what we're going to do, we're going to import the key, so the test.xml. Let me show you this one at this point because it will be great for you to see how this key looks like. And it looks like this. 

So, nothing that can be directly read over there. But we're going to specify our provider. That's System.Security.Cryptography.RSACryptoServiceProvider this time. From XML string, we are putting the key into the provider. We are reading the value from the registry. So, this is also good. And then we are converting it to the byte array. 

Why byte array? And that's because of the ways of how things are read or written to in Windows. Sometimes, it's from left to right. Sometimes, it's from right to left. And in this case, we will need to revert that string. That's why I'm converting this one to the byte array. But of course, if you're interested how that password is going to look like when it's decoded from Base64, then you are able to see that that password basically looks like this. 

So, it's nothing really meaningful, exactly, because even though we decode it from Base64, it's still not the case. But no worries about that because the decryption of the password is crazy easy. First of all, we will need to revert that particular byte array. And then, we're going to use that within our cryptographic service provider. And then, we're going to display it. 

And here we go, the password comes out. And again, we've got a password coming out in the cleartext. So, yet, then there's another identity that we are managing over here or actually not really managing where the password is extracted where the password is stolen. Question is, could hackers use it and leverage it for the further steps of the attack? So, we got that. 

Now, the best part for the end. So, whenever we are thinking about identity and the ways how it's used in the organization, in the attack, and so on, again, from the pen tester's perspective, it's crucial, of course, to do our job. So, the more passwords, the more users I've got, the more I'm able to use them within the attack. The more complex it becomes, the more difficult for you is to find what actually happens during the attack. 

Now, whenever we think about what is needed, a user or admin, like, what will be best to start with, actually, it doesn't really matter. So, I'm not saying that being a user, always we'll be able to access certain domain admin credentials. But what we are trying to say is that what is important to monitor nowadays, it's an anomaly of how your identity is used regardless whether it's a privileged identity or not, because it's not only about being a domain admin, but, of course, it's also about the access to data. 

And the human controls run somewhere. There's a need to be a domain admin. It's just enough to have access to data. So, the point of entry could be regular user. Just for this example, let me use the example of the Irish healthcare where simply one of the employees clicked on the link in the email and the patient's data, so the hospital-related data has been encrypted. 

And hackers, you know, they said, "No hard feelings. Nothing personal. We're just a businessman. If you're going to pay us $20 million, we're going to give your database." So, this was their proposal. Now, just because of that simple situation, it happened. So, what's my point over there? 

Is that we've got a possibility to extract users' credentials only if, at the very first moment, of course, only if we are running this as a user, running applications as user or putting it from a different perspective. If you are logged in as yourself… So, let's use the Freddy Krueger's example over there. I'm going to log in the desktop. 

Now I'm logged in. Have a look. We have all kind of password I'm doing this. So, this is a domain user password. If you are logged in as yourself or Freddy is logged in as himself, then the rule of thumb is really simple. Here we've got a possibility to extract passwords for the applications with any other application, or saying it differently, if you store passwords. 

If you store passwords, for example, in the browser or if you store passwords in Outlook or if you've got certificates or, in general, like, if you store passwords in the applications in Windows and so on, most probably you are doing this with the DPAPI. So, that's the cryptographic platform of Windows. 

Now, not to really brag about it, but happy to tell you everything about it if you guys are going to have questions because our team is, as far as we know, the only and the first team in the world that fully reverse engineered that platform. And it took us over two years to do it. So, quite a lot of things to decrypt, but right now, under certain conditions, we're able to decrypt everything that moves in the operating system. 

So, let's see, basically, what we got. First of all, we've got a ChromePass. And ChromePass is a simple NirSoft application. So, it's from NirSoft. So, you can download it for free. But what we are trying to show you is that here ChromePass it's not Chrome. And Chrome is extracting passwords for LinkedIn and for Google Chrome. 

So, why is this possible? Well, because that's the rule that we mentioned. Every app that you run as yourself, it's capable to access any secrets that's protected by any other app. So, technically, 7-Zip could extract passwords for Outlook. Yep. 

And some other portable apps, untrusted apps, could extract passwords for Firefox and all these details. Yes. So, in general, if you store some secrets in the operating system, then they can be accessed by anything else that you run. And this is where that identity gets violated on many levels. Now, let's make it worse. So, what are we going to do over there, I would love to show you, first of all, that this particular password that we are looking at depends on the user that we are logged in with. 

So, that depends on our account. So, what I'm going to do. I'm going to actually do a little bit of a situation where I'm going to be logging on to this operating system with the cached log-on data. That's something that people call cached credentials, which is completely not true. We should not call them credentials because they're not credentials. 

This is just a value that's pre-calculated and stored in the registry that you only compare with, but you cannot log on with it. So, just for the reference because credentials, cache credentials I'm hearing all the time, but this has nothing to do with credentials. That's for sure. Anyway, if you go Next, then Repair Your Computer. 

I'm going to be overriding cache log-on data, because this is how it's supposed to be called, by changing the volume in a registry so that the domain user can log in with that cache log-on data. And how does log-on process looks like? See. I'm disconnecting this machine from the network, which means I will be logging on with the cache log-on data. 

And in the registry, I'm going to store the value that is basically generated by myself right now in a moment. And I'm going to compare it with the value, the password that the user is going to be typing in at the log-on process. Sounds may be quite complex, but I will describe it in a moment in a little bit of a picture here. 

So, here we go. First of all, I'm going to override cache log-on data. And that means we will need to go to the CQTools, KiwiCQUREEdition, mimikatz. And this is a Mimikatz secure edition written by Benjamin Delpy. But our edition is not recognized also by antivirus. Lsadump, it's our module here. Cache. 

And then I'm going to use it against d:\windows\system32\config\SYSTEM d:\windows\system32\config\SECURITY, and then /kiwi. Okay. So, we are overriding cache log-on data. Now, it's also good for forensic, but it's a different subject. So, here I can like Jack, J. 

Smith, Freddy Krueger. Yeah. Awesome. That's what we want. And that cache logon data is going to be overwritten in the registry by the value that is calculated as follows. And let me use this reboot opportunity to explain what the cache logon data is so that you guys get an idea. What is stored within the registry, that's the value that is called MSDCC2. 

And that MSDCC2 leverages the function which we call PBKDF2. This is like an industry standard. It's not only Microsoft. And over there, we've got the HMAC-SHA1. So, this is, let's call it random value. We got a username. 

We got a DCC1, which I will explain what that is. And we've got over there also 10,240 iterations on 16 blocks. So, DCC1 has been used in Windows XP and below. And this is Windows Vista and up. 

So, Windows XP and below. I had stored in the registry. MD4 of the username joined together with the MD4 on the top of the user's password. So, this is basically what we got in here. Now, the next part, it's quite straightforward because this value, as you can see, it's not reversible. So, over there, we are actually trying to compare with the registry what we got on the top of password. 

So, MSDCC2. It's the wrong one because in the registry we got MSDCC2 now stored for the password that's called Mimikatz. And that is something that we are leveraging here. Okay. 

So, almost there. Now, we're going to see right now when I'm logging in with a different password whether I get access to the user secret or not, and that's that ChromePass. And waiting, waiting, waiting, waiting. My current password's hash on top of Mimikatz isn't really allowing me to decrypt the master keys that are responsible for protecting secrets in Windows. 

That's why it takes such a long time and, eventually, we are not getting the password. So, it's a good news. Eventually, it's a good news. But of course, it's not that beautiful. The problem is that master keys that are protecting secrets for all of the domain users for all of them are actually the ones that are also, also protected in different methods. 

So, there are two methods to protect them. And that different method to protect them, it's called the Master Key. Actually, it's like a key that you use that is on the top of the domain. And this is what we call the domain backup key. But eventually, this is the part of certificates that is stored within the domain. 

And this is something that we have discovered. And this is something that I would love to show you what's the meaning of that certificate so that you go and see why managing identity in organization it's a completely crucial process. And I'm really serious about that regardless on what kind of context we're going to be showing this. So, please have a look. 

And we're going to get into the tools over there. Next part is to go to the toolkit for the data protection API. And right now we are on a domain controller. So, who has the possibility to extract that certificate? It's not only domain admins, but it's someone who has access to NTDS.dit. And it's also someone who has a permission on the top of the domain of replicating directory changes all and replicating directory changes. 

And that is the misconfiguration, by the way, for the sharp point accounts, for example. So, CQLsassSecretsDumper allows us to export that keypair, which is not stored in any container. It's just stored as a… It's just a data blob in NTDS.dit. So, we found we were analyzing what's in the NTDS.dit, we found, like, some entry, we're like, "Does this have any meaning?" 

And then basically, we found that. And that exported PFX. Once we import it, we don't have to, but I just want to show you. Display password. Secure okay. Next. Next. 

And Finish. And we got this certmgr.msc. That certificate looks like this. So, what I'm trying to say... Not available. Cool. Everybody, all of you guys, if you're working in a domain environment, million percent, you got that certificate in your environment. 

Now, what's not cool is that that certificate for, I bet, most of you already expired. And if you had not set up domain in 2020, then this certificate already expired. Now, if you had set up your domain in 2003 or something, this expired. Yeah? 

Could you, like, renew it? No. Could you do something about it? No. What if it leaks? You've got a big, big drama issue because this is something that you cannot fix. That's why monitoring identity in the organization is crucial so that you know that your infrastructure security isn't violated. 

And don't get me wrong. We have so many attacks during the pandemics, so many. And we've never had that many projects like during the pandemics on incident response. Customers' networks were attacked. There were domain admins taken over and all that stuff. And we've got a list internally of, like, four key steps to follow when your domain gets compromised. 

Reset passwords, reset the password of KRBTGT account. Reset the KDS root keys and all that stuff. Okay. Awesome. This is all the stuff you can do. But you cannot do this. This remains, unfortunately, forged. 

So, for example, what if you had a bad domain admin five years ago and that domain admin kept NTDS.dit somewhere, then it's already a leaking point. So, that's why it's important to manage privileged access. Let me show you what you can do to the certificate, and then I'm giving the stage immediately to Jasson. So, here we go. 

We've got over here Windows 10 client. We're trying to get access to this Freddie's password. So, how do we do that? Well, first of all, what we're going to do. We're going to decrypt the master key corresponding with this password over there with that PFX from the domain and then we're going to encrypt it with our current password hash. 

That's it. So, having this PFX, you can do a lot. And let me tell you in a moment what kind of stuff. First, we're going to do DPAPI blob searcher to find where Google stores secrets. And we know it's going to be somewhere in a user's profile. So, we can go AppData\Local. 

And then for that one, we can do Google\Chrome. And then a recursive search output to see CQ tools. Yep. And I think it will be best to actually do it within the notepad. Actually, let me just put it into dpapi.txt because it's going to be not that big file, but not very convenient to see in a console. 

So, yeah, dpapi.txt over there. Perfect. We're able to see that master key responsible for protecting Google Chrome secret is this guy. So, we have to get this guy. But it's not accessible now because we were not able to decrypt it with our current password's hash. Awesome. 

So, let's decrypt it with that private key from the domain. So, %appdata%. Microsoft, Protect, CD, B55. This is where we find the users' master keys. Don't delete them. It's a bad idea and definitely a bad joke for someone. What we're going to do, shift, right-click, copy as path. 

And then over there, we're going to be leveraging it in the toolkit. So, we are almost done. First thing we will do, it's a CQHashCalc mimikatz. That's my current password hash. And then we are ready to rock by using the CQMasterKeyAD. Now file. 

We are working on that master key. And we are, pfx, decrypting it with this private key. And then newhash. We are encrypting it with this password hash. So, we're almost home. Done. So, now we have to just replace these guys. 

So, I'm going to rename it into at that stage GOOD or something. And then this admodified we are putting in here. One more thing, though, this icon kind of is blank. Yeah. You see that. So, we're going to do attrib for system and hidden. So, we are giving it an attribute of system and hidden, Enter. 

And then please have a look. In ChromePass, whatever we couldn't see, we can see. And that confirms us a statement here that whoever is in a position of this private key has access to every user secret in a domain. So, if you're working in a bigger company and you've got, I don't know, 100,000 people working or 10,000 people working, if you got that PFX, you are definitely a king over there because you are able to decrypt everybody's passwords, everybody's secrets in a whole organization endlessly till the end of a lifetime of that company because that's the certificate that you cannot delete. 

You cannot renew it, you cannot... Just say you cannot do anything. Whatever you're going to ask, the answer is no, you cannot. So, that is basically the situation we are left with. So, domain admins' credentials or, in general, privilege access is nowadays more important than ever. And it has always been, though, after this kind of discoveries, we're even more certain that we've got a possibility to violate identity on that level. 

And of course, whenever we're thinking about the perspective over here, we've got an option to monitor identity, we've got an option to approach this from the monitoring perspective, also from the prevention perspective. And this is something that Jasson is going to be talking about. 

So, if you guys have any questions, absolutely, at your service. And at that moment, I'm giving the stage back to Jasson. So, here we go. 

Jasson Casey

May I unmute myself? That was actually pretty cool. 

So, yeah. I'm going to spend a little bit of time to talk about Beyond Identity and some of the things that we actually do. So, on that note, Justin, do you have a slide you're putting up in the background? So, we're an identity platform and we're a cloud-based identity platform. 

And the difference between us and solutions that you've had before is we're an identity platform that's based on something called a platform authenticator. So, the authentication cycle in our system is not based on, like, symmetric secrets. It's actually based on asymmetric cryptography. 

So, we create keypairs and you basically authenticate yourself by using a private key to kind of sign a challenge, right? Very classic. And a bunch of people are saying, "Hey, that's not new. I do that all the time. That's like my Git flow." And you're right. So, some of the things that are new and that we actually do that's unique is a lot of devices today, in fact, most devices that you can purchase since 2016 to '17 ship with these things called TPMs or various enclave technologies. 

And so these technologies enable you to create an asymmetric credential that's physically rooted in a device. So, in our system, our platform authenticator, it actually runs on the device that you're using to authenticate from. So, every device has a unique credential that's bound to your identity. That private key is actually constructed inside of that trusted module, right, that TPM or other technology depending on the underlying hardware. 

And so one of the interesting properties that then happens is the key doesn't move, right? So, keys can't actually be lifted out of the system. These are signing keys. They're not encryption keys, right? So, signing keys in the TPM you can construct them in a way where they physically can't leave the TPM module. And they can be constructed with authorization policies, authorization policies that say certain things have to be true for the signing key to even be used to sign a challenge that you present. 

So, we build a layer up on this with something called policy and we kind of let our customers write policy that helps them do things like understand not just the risk of the claimed identity is who they say they are, but also the security posture of the device itself at the time of access or the time of data retrieval. 

And we can push that into a policy. So, for instance, assigning of a certain high-trust key may only work if the OS actually has the right checksum and the bootloader that loaded the OS had the right checksum and the BIOS that loaded the bootloader had the right checksum. 

And we can also do certain types of cloud policies that do similar things like, "What is the status of the device? Is my EDR running on that device? Is it running the policies I expect? Is vulnerability management running? Are there any vulnerabilities on this system that I'm worried about that would kick it down from a high-trust environment to a low-trust environment?" So, that's on the activation and the prevention. 

In terms of the monitoring, because we're in the middle of every transaction, every access attempt, every data retrieval, we have an ability to actually collect a really interesting data stream about not just the identity, but also the operation they're trying to drive and the security posture of the machine at the time they're actually trying to drive that operation. 

And so that presents really interesting opportunities to understand, what does normal access look like? What does abnormal access look like? And help security operation staff really try and draw their focus to things that do not look normal and occur outside of the norm and possibly even write policies that end up doing things like dynamic step up. 

So, when Joe tries to run an action that he hasn't really run in quite some time, maybe we actually raised the threshold on Joe to complete that action. So, it's not just the possession of the account and possibly a pin on lock, but maybe a biometric as well as certain expectations on the posture of their device at that moment in time. 

The core of us is we're an identity platform. We plug into the back of your existing SSO. We have two services that we offer today, secure work and secure DevOps… Sorry, three services. And sign-on. So, with secure work, we can plug into the back of your existing SSO whether it's Okta, Ping, ForgeRock, etc., and immediately add this platform authentication experience to your end customers. 

So, secure work helps secure your workforce. We let you basically write policy against strong offer every access no matter who is trying to access what data, where they are in the world, whether they're using a company-managed device. 

It's very, very simple. We look like a delegate identity provider to your existing SSO. In secure work, that's more focused on DevOps software engineers and IT personnel. And the problem that we're helping you solve there has to do with the integrity of software that you're pushing into your build system or your CI/CD. 

So, everyone signs their builds coming out of their CI/CD in terms of this is what I...this is what I certify as my genuine builds to my downstream customers. But no one really pays attention to what goes into the sausage-making. How do I know that this commit object was actually committed by Jasson and not someone else? How do I know that this commit object was committed by Jasson from a machine that actually adheres to our security posture requirements? 

So, secure DevOps, our platform authenticator actually provides GPG key construction, again, inside of those enclaves where those keys can't be moved. We see or sign those keys over your corporate identity for things like integrity and non-repudiation. This key, in fact, does belong to my corporate identity of Jasson Casey at Beyond Identity. 

And we have a signing agent that it's trivial for when you type git commit with a message, you add a specific flag and it will actually invoke our signing agent to sign that commit object. So, now in your repository, you actually have commit objects that are integrity-sealed to corporate identities that actually produced them. 

And if you, so choose, to writing policy in a certain way, it can not only seal the identity, but also seal information about the security posture of the device, the risk of the identity at the time, and other sorts of environment. So, in your CI and CD, you can do anything from break the build for any of these commit objects that don't satisfy whatever your thresh tolerances have to be to just generating a set of warnings that you can hand over to compliance or your security department to review to kind of understand your risk in that release. 

And then finally, our sign-on offering is the same product that we actually talked about in secure work, that rather than presenting an application and a UI, we present a series of SDKs for our cloud operations as well as libraries that you can build your own applications around. So, for instance, you can get the same login experience except without having to go to the SSO, without having to have that redirection at all just kind of happens native and seamlessly. 

So, that is the extent of my bit. 

Justin

Thank you very much, Jasson. That is awesome. At this point, we will open it up to questions. And we have a few loaded up already. If anyone has any further questions, please do put them in the Questions tab. Jasson, did I catch you off or were you trying to say anything else? 

First question is... I think this one is for Paula. With your credential cache attack, surely, does something like a BitLocker would guard against this? And do you also have bypasses for encrypted drives? 

Paula

Good question. Because I was showing it based on the offline access. We could also do it online, by the way. So, this attack works on both levels online and offline. So, for that one, of course, BitLocker would help, but for the online network, it won't. Regarding the BitLocker, BitLocker it's brute force level. But let's be not so optimistic about it because underneath it uses AES-256, which currently is considered a good standard, but it's good, for example. 

So, just to mention that if someone really, really wants to get to your drive, then it's just a matter of amount of probes, which is a lot. But still. And if it's about the DPAPI-NG, so the new generation sort of sits protected BitLocker drives, which is a bit of a different way of using BitLocker than we do because we have reverse engineered DPAPI-NG as well. 

Justin

Okay. Thank you. And second question, probably for Jasson. Does Beyond Identity also guard against service and IIS credentials as shown earlier in the webinar? In other words, can you plug the hole that we saw hacked earlier? 

Jasson

Can we plug the hole that we saw earlier? So, a couple things. Number one, our system isn't really based on any sort of shared secrets, right? So, the first thing that's unique about our system is blast radius reduction. The second thing is they're not symmetric secrets. They're asymmetric keys that are managed in hardware, right? So, the real question is, how would you then get access to those keys and satisfy those authorization policies, right? 

And then the third thing is you would have to satisfy those policies given the security posture requirements, as well as some kind of offline analytics. And what we integrate with the way that you would use us, we generally our first applications on the secure work or any sort of SSL application, so Azure AD. So, we plug in the back of Azure AD. 

We can also plug into just AD by itself using things like the WS-Fed for local federation. And then we actually are introducing Azure AD plugins here soon. So, you can use it for services, cloud services, as well as local services. We don't have a machine-to-machine model or product today. 

So, that's not something covered in our offering. 

Justin

Okay. Thank you. And last question I had before we cut off is, does MFA prevent the kind of hacks like we saw in Colonial Pipeline? I guess we'll start with Jasson and then Paula you can give your thoughts as well. 

Jasson

Does MFA prevent... So, when you're not using secrets that can be carried over from one service to another or one machine to another, you're clearly changing the model, right? And it's not necessarily saying that a particular adversary couldn't necessarily produce a similar end result, but it certainly cutting off the low-hanging fruit or the easy way. 

Justin

Okay. Thank you very much. So, at this point, we're out of time. I would like to thank both of our presenters. Thank you, Paula. And thank you, Jasson. To all of you watching, we will be making this broadcast available on-demand because we'll be sending that out to you shortly, probably sometime later on today or tomorrow. 

Thank you very much.