Ghosts in the Hypervisor: Dissecting TTPs Behind Ransomware Attacks on Virtualization Infrastructure

I'm Austin Gaton. I'm the CTO and co-founder of a company called Valley Cyber. And there's a lot of hot topics in cyber security. Cloud security. LMS are always big in the news. But today we're going to be talking about something that's older. It's an older technology that all these other technologies run on top of. So you've got LMS, you've got virtual machines in the cloud running on top of something called a hypervisor. So a hypervisor is a system that is used to run virtual machines. It's typically deployed as an appliance. And so that's all it's supposed to do. It's only supposed to run virtual machines. And so we're going to talk about how attackers can go after

that layer to do really nasty stuff to these workloads particularly in private clouds and in VMware powered private clouds. So just a little bit about me. Um I got my start in the security space at the US Air Force Academy. I was a member of the academyy's competitive hacking team. We did CTF competitions. I specialized in now reverse engineering and binary exploitation. I went to MIT for grad school. I worked on a DARPA program while I was there. DARPA is the Defense Advanced Research Projects Agency. And we worked on something called hacks. And hacks was all about autonomously finding and destroying botnetss. And the approach that we took was really to build a botnet that went around

destroying other botnets. And so part of that was about developing automatic automatically generated exploits. And so that's what I was focused on automatic exploit generation. I focused a lot on targeting Linux systems. So I was doing a lot of offensive Linux security. After that the Air Force sent me to Kirtland Air Force Base in Albuquerque, New Mexico. And I worked on security for satellites, satellite ground system, satellites in orbit. And it turns out nation satellites really run Linux operating systems a lot. So I was doing a lot of defensive Linux security. we ran into challenges with some of the commercially available tools for defending them. And so, Valley Cyber got started as a Linux and then eventually a

hypervisor security company. And so, that's why I'm standing before you talking today about hypervisors. And despite it being a pretty old technology, I think it's been targeted much more heavily within the past 3 four years. And so, Huntress put out some really interesting research late last year about a 700% increase that they saw in ransomware attacks against CSXi. So, there are a couple groups that are pretty active. One of them is called Scattered Spider. Scattered Spider was super active early in the year in 2025. And then later in the year, there were a lot of attacks by the Akira ransomer group. And so, these attacks are really devastating. They cause these massive impacts to revenue and and damages

because you can imagine a company that's very reliant on a private cloud. Most of their workloads run on a private cloud. And what happens in these ransomware attacks is all that private cloud infrastructure goes down all at once. The virtual machines get encrypted and then you're kind of out of luck. You can't really do anything until you get the VMs back online either from a backup or some other method. And some of these companies had their backups impacted too, which is really really not a good situation. So the talk is is definitely focused on ransomware actors, but we're also going to talk about these nation state sort of espionage campaigns as well. And so in addition to getting onto

the hypervisor and trying to encrypt the virtual hard disks, another sort of attack is just to try and export them and take the virtual hard disks and then analyze them in your own attacker infrastructure. Try to find secrets and source code and keys inside of those virtual hard discs because the data that's inside of a VM is also inside that virtual hard disk. So if you can export it out of the environment, you can read a lot of interesting information. And so there's an attack called Brickstorm that was uh reported on by CISA and the NSA late last year that's pretty interesting. And there have been a couple attacks that led up to Brickstorm that were very similar. So

that's also something that's been going on for a few years. So with that, let's talk about sort of the the market for hypervisor security and why we're so focused on VMware. So VMware in terms of private cloud is the most dominant hypervisor out there and they've been acquired by Broadcom. A lot of people are kind of happy about the way Broadcom has changed things with VMware and there's been sort of narratives out there that everyone's moving off of VMware because of what Broadcom has done. This actually hasn't been the case over the past few years. Broadcom's revenue share has increased significantly. And so there are a lot of people running VMwarebased private clouds. And so as a result, this is what

attackers are trying to go after. You could have you tanix or proxmox or some other hypervisor that might be Linux based. Maybe you're using Microsoft HyperV. But the most common one is VMware. And so that's what attackers are going to put their energy and their effort into targeting. I think it's also interesting there was some research put out by Google Mandant late last year. And so they did their annual prediction for what they thought was going to be interesting or impactful in security in 2026. One of the things they called out was infrastructure attacks and attacks against virtualized infrastructure. They talk about how scattered spiders playbook requires a fun fundamental shift in defensive strategy moving

EDRbased threat hunting to proactive infrastructurecentric defense. Part of the reason why these attacks can be so successful is because they go under a lot of the security tools that we have in our virtual machine workloads. So you don't have any sort of EDR or runtime security in those workloads. The attacker can get onto the hypervisor. It's usually something that's sort of a black box from the defender's perspective. they're not paying attention to the activity and the behavior in that environment. Okay, so common ways attackers attack these systems are going to be cred credential compromise. That's a big one for scattered spider just stealing administrative credentials getting onto systems that way. misconfigurations and we'll talk about misconfigurations

particularly in a campaign that happened a couple years ago uh affecting SLP services and it was related to misconfigurations in firewalls and network segmentation and then of course just CDEs there have been some very interesting escape to host exploits especially last year that we'll discuss as well I think something else worth mentioning is that the MITER attack framework in in 2025 added ESXi VMware ESXi as a new platform. So it's sort of on the same level as Linux, as Windows, as Mac, a platform, a type of system that attackers are are targeting very heavily. And so there are some ESXi or VMware specific tactics, techniques, and procedures that got added into version 17 of the MITER attack framework. And

this of course can then have compliance flow down because compliance frameworks will borrow from frameworks like the MITER attack framework. And then there's more compliance requirements for organizations that are running VMwarebased private clouds. And it's also worth noting that MITER themselves were breached in their VMware environment in May of 2024. So there was a report. It's very public. It's all all above board, but we'll be talking about that breach. It's sort of related to the espionage stuff that I was talking about with scattered spider. And the traditional way to defend these environments is to use perimeterbased defense. So you sort of build a wall around the hypervisor and then you just really hope someone doesn't get it. And

the problem that we see a lot are identity based attacks where attackers are stealing credentials for a system system administrator and then traversing through the cloud environment or environments that aren't typically monitored by tools like EDR. And then once they have that credential to get on to what's called VSCenter which is the management console for VMware then they can actually do a lot of nasty things. They can turn on SSH to the hypervisor. they can log into the hypervisor. And so they're not necessarily hacking their way in and using all these sophisticated exploits to get into these environments. They're more logging in and they're just using the standard protocols and procedures that would be used by a

system administrator. And that's because your firewall, your identity based security, it has to allow those system administrators to work with these systems in the first place, otherwise they wouldn't be able to do their job. So if an attacker can effectively mimic those identities, then they can do potentially some some nasty things in the environment. Now that said, the first thing we're going to be talking about is an exploit that was part of the ESX campaign. And so this CVE came out in 2021, but it was widely exploited in 2023. So there were a lot of unpatched systems out there that were publicly accessible on the internet. That's a very, very nasty, bad combination. and it was particularly impactful to VMware

ESXi 6.7 systems. And so the exploit itself is there's a version of it that's available on GitHub. The version that is on GitHub is not a very reliable exploit. If you want it to be reliable, you have to work on the heap grooming a little bit and make it more straightforward. But it's essentially a two-step exploit. So you have an information leak and after information is leaked about the address space for a vulnerable process then you have actual memory corruption and so what the attacker is trying to do is use this memory corruption to run arbitrary code in the context of the SLP Damon that runs on the ESX system and then from there they can do a sandbox escape to

escape a sandbox that that that Damon runs in and then they try to run their malware and their ransomware on that host. So and see an example of this in action. So this is an ESXi 6.7 system that we're looking at here. It is vulnerable to this CVE and it's going to have a couple VMs on it. Gandalf, Froto, and Gimly. So these are the VMs that we're going to try to encrypt in this attack. And basically what we're going to do is the attacker has set up a netcat listener. So the netcat listener is going to listen for a connection that will be initiated by the exploit. And the exploit again is it's a derivative

of the one that's available on GitHub. Just some changes to make it a little bit more reliable. And essentially what it does is first it will make a series of network requests to the SLP service. Those network requests will shape the heap in a very specific way. So as that heap is being shaped, it will try to leak addresses out of the address space. And the goal of the exploit is to run this series of commands where basically we are launching a reverse shell. So the reverse shell will connect to that net listener and allow us to run arbitrary commands on the victim system. So the goal of the information leak is to leak out an address from the context of the

SLP process. The reason we want to do that is to bypass address space layout randomization, which is a protection that's available even on these older versions of ESXi. And so it takes a little bit of time to run through all the different requests, but essentially we're setting up the heap the way we want it so that we can launch the exploit and then do the memory corruption. The memory corruption part runs quite a bit faster because the heap is already set up the way that we want it to launch that exploit. And so now what we've done is we have all of our addressive addresses. We have our lipsy based address, system address, environ address, all these addresses that you

want when you're actually doing a memory corruption exploit. And so now we can launch a few more requests to this service and get access to it. So what we should see here on the left is a shell that pops up and we can actually thatame- a command that we had queued up. It runs. It sees that we're running on the ESXi67 system. And so now what we're going to do is we're going to download and run the same ransomware that was used in this campaign. It's called ESX. And if I can time it right, I'll try to pause it really quick and show you something as the ransomware runs. So that first little bit of output it gave

us kill VMX is a very important step in ransomware attacks that get launched against these hypervisors. While a virtual machine is running, virtual machines run through the VMX process. So the VMX process locks the VMDK file. So if you try to mess with it, you try to encrypt it or access it, it's not going to let you. So what the attacker first does is they kill all the VMs on the system. After they kill all the VMs on the system, then they can just use tools that are available natively on the ESXi host to encrypt it. Could also download ransomware too. But it often OpenSSL is used to do the encryption in these sort of script-based attacks. And so if we

take a look at the Gimly VM, we can see that it was encrypted. It's got that.orgs extension. Now it has been encrypted by the ransomware. Okay. So at the time of this exploit, well, I guess we'll go ahead and try to power one of these guys on. If we power it on, we get the nasty red message. That's because it's been encrypted. So this is a bad day if you're a system administrator for this host. So, at the time that this attack happened, there were like 19,000 systems vulnerable to this CVE that were publicly accessible on the internet. And so, this was a scan done by Rapid 7. Really, really nasty stuff. And what happened after this this

campaign occurred is people did a much better job with network segmentation. They took these systems off the public internet and we don't see that many systems that have this sort of CVE or vulnerability against them in the wild today. Except that isn't true at all. If you go on Showdown, you can see that there are still like 20,000 systems that are VMware ESXi systems publicly accessible on the internet. Many of them still have this same vulnerable version of ESXi. In fact, if you do some real digging, you can see some that have actually been ransomed. Like the the web page that gets returned is a ransom note instead of the normal ESX web page. And so, the

truth hurts. Sometimes we don't learn our lessons in security and we make the same mistakes over and over again. One of the key things that you do want to do with your hypervisors is effective network segmentation. But of course, we've talked about these identity attacks and so this isn't the only thing that you need to do, but it's a good step and it prevents attacks like this. And so another thing specific to this exploit, the SLP service is what was used and what was abused by the attack. You could disable that service on your ESX systems. A lot of people don't really need that service to be available, so you can just turn it off

or uh implement the firewall rule or disable the firewall rule. So it's not accessible. So patching, network segmentation, all that is good stuff. Disabling the service is good. And then there are security tools like firewalls that can do something called virtual patching. So essentially what they'll do is they'll look for behavior or for network traffic that is associated with an exploit and they will block those requests or that behavior on a system. This can be effective way to prevent these exploits even if you are running a vulnerable version of ESX. And sometimes companies have to do this. We've run into companies in our experience that have to have a vulnerable version of ESX that they're running because it's

supporting some old software that they need to do their business logic. Okay. So, the next breach that we're going to be talking about is MGM Resorts. So this happened in late 2023 and this is a scattered spider breach. So scattered spider also had a bunch of nasty attacks in early 25. They work pretty much the same way as what happened with MGM. There was $100 million worth of damage. It's also a really significant lawsuit that came out of this. Something that we've seen from these high-profile ransomware attacks is that the ransomware itself is very destructive and cost a lot of money. But then you get these class action lawsuits, these lawyers that want to make money off of the actual breach.

launch these class action lawsuits and that can then defending that for the company can then cost tens of millions of dollars. Okay, so the way scattered spider tends to go after these environments is first they will target a third-party IT help desk and so what they do is they will do a SIM swap attack. So they'll mimic the cell phone number of assisted administrator. Now, with AI, what they're also doing is if they find like a YouTube video of you or something like that, they'll try to steal your voice and mimic your voice. So, it's a very sophisticated, very good fishing attack to the third party help desk. And those third party help desks are dealing with

a lot of different requests. The request that these attackers give is, "Hey, I lost my password. Can you reset it for me?" And these IT help desks, they're dealing with hundreds, thousands, tens of thousands of these requests a day. And so eventually one of them gets through that shouldn't have gotten through. And so once the attacker has those initial credentials, they use that access to access cloud services, particularly a AWS services within the enterprise environment. They find their way and they move laterally to the VMware environment. And this is where they target the Vsenter system. So Vsenter is the management console for VMware ESXi. And Vsenter is kind of the brain for everything. So if you get

access to it, you can do pretty much whatever you want. So we'll see an example of that in the next little demo. So you assume we're an attacker that has credentials to the system. And what they're going to do now that they have access to VSCenter is they're just going to try to modify the services that are turned on on this ESX host. So, if we go to the services, we're just going to look for the SSH service and we're going to turn it on. Very straightforward, simple to do. And this is a typical thing that an administrator might try to do on the system. In this demo, we're going to be going after this

Walter White VM here. So, we're going to be trying to encrypt that VM. And what these attackers do once they have this credential access, they just walk in the front door. They just turn on SSH. They log in over SSH. And now what we're going to do is CD over to the VMFS file system where all the VMDK files live. We are going to try and run some ransomware on it. I'll pause here because this command is a little bit long. I'll explain it. So this is a living off the land attack. We're not actually going to download malware onto the system. We're going to use GP to list out the files that are available for this virtual

machine. We're going to use OpenSSL to make encrypted copies of these files. Then we're going to use RM to do the deletion. And so that series of commands allows us to really execute a ransomware attack without ever downloading any ransomware onto the system. And so this is why it's a living off the land attack. And again, OpenSSL, GRE, RM, all those utilities and tools are available on ESX by default. They're all installed there by default. And so is Netcat, by the way, from the previous demo. Netcat's on there, too. So there's a lot of great tools for hackers to use. So we're going to run that series of commands. And what we get now are the

encrypted DMDKs. They have this little nuclear sign extension on them. If we try to run one of the virtual machines, same nasty red error message. It's a bad day if you're the CIS administrator for this host. So, this is a little bit more challenging to deal with if you're a defender because it's an identity based attack. Fishing happens a lot. Fishing is hard to stop. There, of course, many good identity tools out there that can help, but it's not easy. Another kind of similar breach that happened in 24 was this the CVE that was related to Active Directory. And so, essentially there's a group in Active Directory called ESX admins. And so if a user was a member of

that group, they could just log into any ESX host that they wanted. And so this was again if they they had access to this group, it was an identity problem, kind of a privilege problem in these environments. They could log into these systems and then do whatever they want. And so we can see in this next video there is a user Billy Jean inside of the active directory and we're going to log into their virtual machine. We are going to take a look at the active directory itself. We're going to try to find the ESX admins group. There it is. And we'll just add ourselves to it. So when we add ourselves to it, this

user doesn't need any special credentials or anything outside of their Active Directory credentials to then access the VMware environment. So now that we've made this change, now we can just log into the ESX host that's joined to this active directory and we're able to do this without any sort of challenges or problems.

And so now that we have access, we can go ahead and see that we're running as a domain Active Directory user. And we'll go ahead and just turn on SSH again. login over the system over SSH and we're going to launch our ransomware. We can change passwords for the root account. So what's being done now? So we're doing a lot of stuff in the guey in these demos, but often these attacks use Power CLI. Power CLI is the API for VMware. So it just allows you to automate this stuff and do it across a lot of systems at once. But just for illustration purposes, for demo purposes, it's a little bit easier to see it all through the UI. And yes, now

we can go on and we can run our ransomware once again. So we'll run that same command. We'll encrypt the files. And it's a bad day for the administrator. So it's if you look at the documentation for VMware, it talks about how to set up Active Directory connections and Active Directory integrations with your VMware environment. I would recommend and the security guide recommends having a separate AD for VMware. So you have your main active directory, you have a separate AD for VMware specifically so that if someone gets access to the active directory, if they get access to this group, they're not going to be be able to easily and automatically log into all your ESX systems. Again, this

is about separation of privileges and making sure that the users in your environment have the right privileges so that they are not able to access systems that they're not supposed to be able to access. So now we're going to move on from ransomware and we're going to talk more about attacks that are focused on espionage and on stealing data off of systems. So to do this we're going to look at the minor breach. The minor breach happened in May of 2024 and essentially what the attackers did is they installed malicious vibs. So vib is a vsspere installation bundle. It's how you install software on an ESX host. And the reason an attacker might want to

do this is one for persistence. You want your malware to persist on ESX. You need to install it with a VIB because the file system for VMware, it's an in-memory file system. So once you reboot the host, all the files go away unless it's inside a data store. But in most cases, the files will disappear after you reboot reboot the host. The other reason why you want to have a VIB is a protection. There's a protection on ESX called Exec installed only. So what exec installed only does is it prevents you from running unsigned code on the ESX system. And so there's something called an acceptance level in ESXi. And VIBs that are community supported VIBs,

they don't have to be signed, but the default configuration setting for ESX is to have partner supported VIBs is what they're called be allowed. And anything with a a acceptance level higher than partner supported is allowed to run. And anything that's partner supported or above is supposed to be signed digitally signed and certified by VMware itself. So as long as you don't have access to VMware's private keys, you're not going to be able to launch one of those VIBs or create one of those VIBs for yourself. So then the key question is how do we get one of these community vibes to run on the system with the protections in place that are available and one of the other key protections

that you can use is secure boot. If you have secure boot turned on we'll create a trust chain that allows this uh sort of cryptographic and and certificatebased security to work for signing your executables. And so to demonstrate this, we'll go ahead and log in to an ESX system. We're just going to copy some malware over there. We are going to SSH and we are going to try to install the malware. And so if we try to install our malicious VIB, we get this nasty warning about VIB failing some extensibility checks. And now we can try to force the install. We try to force the install. Also doesn't work. And it talks about the vib's acceptance level. The ac the

acceptance level on this vib is community. And the default again is partner. So we're not high enough. And you can try to use ESX CLI which is the command that allows you to change a lot of configuration settings on ESX. You can try to use that to change the acceptance level to community supported. But that doesn't work either because secure boots on. So we're kind of stuck here. Secure boots preventing us from installing this community supported vib. It's which is also what's allowing us to run our malware. So the attacker seems to be prevented from doing what they want to do here. And I think the problem that we need to recognize is what a vib is. So a vib is really a

targzip file that's got some XML metadata that describes where the file should be placed inside the vib. what permissions they should have, what persistence levels they should have, so on and so forth. And if you just try to run an executable on the host without a vib that has the exec installed only protection turned on, we'll try to copy the Aira ransomware directly onto it. And if we run that ransomware, we're going to see a message in the logs over there on the right. So the the log on the right is the VM kernel log. So it gives us a message about trying to exec an uninstalled file. And so this is why we need a vib. It needs to be installed

through a vib for us to be able to run the executable itself. And if we take a look at the code that implements ESX CLI, there's a check in there that looks for secure boot being turned on or being turned off. And if secure boot is turned on, it gives us that message that it gave us before where it says, "Hey, secure boot's turned on. I'm not going to allow you to set the the acceptance level to community supported." But there's a little detail in here where when it tries to set or get the host acceptance, it's really running a subcommand underneath it. So, it's running this advanced configuration command under the hood. And so if you look at the details

on what this command actually is, it's something called config store client or a command line interface that allows you to modify the config store. And so the config store on VMware is the runtime configuration for the system. So it's a JSON data structure. And if you run another script called backupsh, it will save that data so that it becomes persistent across reboots. But when we try to get the acceptance level for this host, we see it is currently partner supported. And so instead of using ESX CLI to try to change the acceptance level, we're just going to use the config store CLY command directly. And so what we did is we echoed the appropriate acceptance level

that we want. We want it to be community supported into a JSON file. And then we tell Config Store Clyde to load it. And so this is with all the latest and greatest protections turned on on ESX. It runs on the latest version. This this works on the latest version of ESX as well. So we'll go ahead and after we've loaded that new configuration file, we can see that we've successfully changed the acceptance level to community supported. And so from here, now that the acceptance level is community supported, we can install our unsigned VIB. And even with that exec installed only protection turned on, we can actually run our malware. Now, it goes through and it encrypts all the

files like we've seen a couple other times. So, this is a problem because ESX's security model says you should only run signed code. This is a way to pretty easily run unsigned code. And this has been disclosed to VMware. We disclosed it a few months ago and they're working on fixing it. The reason it's not a severe issue is because of the living off the land problem. So you don't really have to run or install unsigned code on ESX to do a lot of damage. You can just use those living off the land commands that I was talking about earlier like OpenSSL or like Netcat to do some pretty nasty things. So the next attack that we're going to

discuss is called Brickstorm. Brickstorm was an attack that happened happened really it started over a year ago but it was detailed it was reported on late last year and so CISA did some reporting on it. NSA did some reporting on it as well and this was a nation state level attack where the threat actors first got access to VMware environments through F5 big IP network appliances and that was a supply chain attack. They basically breached the supply chain at F5 networks to get onto those devices that gave them initial access to the network. And this is something that we've seen in a number of VMR breaches as well where the way the attacker gets initial access to the

network is through breaching a vulnerable network appliance or a firewall or something like that. And there's been a new iteration of Brickstorm that was reported on by Google Mandant early this year which used a Dell appliance. So it's the same sort of attack but just a different network appliance that they're targeting to get initial access to the network. And once they have this access they use stolen credentials to log into the vsenter system and into the ESX system. And from there they launched a payload which was a Golang program. That Golang program was intended to steal data off of the system and steal VMDKs off the system. So in this example, what we're going to

see is a workload that has a file that we want to read. It has some secret data in it. Um just uh some dummy data. So if we c that super secret password ABC123, that's the data that we're going to try to get access to in this demo. And so from here, what we're going to do is run the ESX login script, which is going to just log into the ESX host. And something that the attackers did to be stealthy when they were launching these attacks is they wanted the VMs to keep running. They didn't want anyone to notice that they were on these systems. And so they would make clones of the discs. You can do this with a tool

called VM KFS tools. So you can just make a clone of the VMDK file itself. After you've made that clone, now you can actually do analysis on it and you can start to do forensics on the VMDK file itself. And so what the attackers were doing once they got to this stage is they had a statically compiled sevenzip executable and they would extract the img files out of the VMDK. The img files allow you to get better access to the data inside the VMDK. So now you can sort of search through them for secrets and things like that. And so in this case, we're going to be looking for that super secret password inside of the extracted img files from

the BMDK.

So to do this, we're just going to do something super simple here. We're going to use said to look for that string. Takes a couple seconds because it's a large file, but once it pops up, we'll see that in fact our super secret password is in that img file. And this is because the VMDK is unencrypted. So you can set up your virtual machines so that the hard drives, the virtual hard drives are encrypted by default. And that's good. That's good for these sort of data exfiltration attacks that we're seeing with Brickstorm, but it's not necessarily enough because if an attacker has access to VSCenter, they can do things like modify the key store, modify the keys that are used to encrypt

the VMKS, which could allow them to use their own keys. The other thing that this does not defend you from if you're encrypting your VMK files is ransomware because ransomware can just encrypt the already encrypted VMDK and you're not able to get through whatever layer of encryption they added. So you don't have access to your data. Now if you were able to exploit or export the full VMDK file, you can see an example of how to extract it here. So what we're going to do is have a mount script. And so what the mount script does is pretty straightforward. It uses kimu to mount the VMDK as a block device in that first KU command

that we have there. Then it uses a couple different commands to scan and recognize the type of file system that's used for the VMDK. In this case, it's an LFS file system because this is a Rocky Linux virtual machine that we're dealing with. And then after we have identified the proper types for the different file systems within that VMDK, then we'll mount it and we can just access the files directly. And so what the attackers were doing is some level of analysis on the clones of the VMDKs inside the ESX workloads, but they were also exporting them out into their own environment. And so what they were looking for were Active Directory virtual machines were a big target.

Domain controllers were a big target. they would use access to those virtual machines to steal secrets, steal credentials and identities out of the system. And so we can see as we traverse through the file system, we have access to that same demo note file that we created earlier in the demonstration. Okay, so encrypting VMDKs is definitely an important thing if you want to protect yourself from these sorts of espionage or or data theft attacks. Again, it doesn't really help you with ransomware, but it's an important step to make sure that the data can't be read directly from the hypervisor level. So, we'll talk about a couple different types of attacks now and some of the

good research that's been done on VMware security. One of the types of attacks that you have to worry about are VM escape. So, this is where the attacker has the ability typically they have administrative access inside of a workload or virtual machine. They use that access to exploit a memory corruption vulnerability in the hypervisor and then gain access to the hypervisor itself. And so there were two sets of vulnerabilities that came out in 2025 that were pretty impactful. One of them came out in March which was related to uh just a announcement by Broadcom that there was an actively exploited virtual machine escape vulnerability. There was also a breach in the summer of 2025 and that was related to the pone to

own competition. So pone to own competition really focused on VMware last year and they found several escape to host exploits and huntress did some very interesting research that they released late last year and it was related to essentially an exploit toolkit that was used by attackers to exploit a lot of different versions of ESX. It went all the way down to I think version five all the way up through the latest version of 8 and it used those CVEes from March. There's evidence to suggest that those that exploit kit had been developed over a year before the patches were actually available. That was due to some of the time stamps that were on files and

directories within the toolkit itself. But it's kind of funny. They went through all this effort to build this toolkit that had all of these different uh exploits for different versions of ESX, but the name of the actual payload file was exploit.exes.exe. So, they didn't do a lot to really obiscate the payload itself. And I think the reason for that is it's kind of hard to detect VM escapes from inside the guest workload. It's because the behavior that they execute is very vulnerability specific. It's not a very generic behavior like calling open SSL or calling netcat that you might want to look out for. It was it usually involves the instantiation of some sort of malicious device driver on the guest

workload that interacts with the hypervisor and exploits a memory corruption vulnerability in the hypervisor itself. In this case, what the exploit toolkit was doing is it was modifying the inet configuration. So inet is the SSH demon on ESX and if you send it a Sikup signal it will restart. It will run whatever is inside of this varet inetd.com file. So the attackers would modify that file to put in their malware and they would create a very small executable inside varun called just a was the name of the file and that that file set up a vox puppet. So a Vsox puppet is a basically a little executable that will allow you to communicate with the hypervisor through

a a VSet which is a device that allows you to communicate to the hypervisor from a guest workload. And so this is how they were able to establish command and control from the guest workload into the hypervisor using one of these exploits. So some other good research in this space one of them is called hypervisor hangover. was done by some threat intellig intelligence members of the Valley Cyber team and essentially it focuses on ESX persistence techniques and so if you want to go take a look at that scan the QR code they talk through different files that you can modify on VMware systems to gain persistence and modify persistent settings they also look at techniques like sim link

hijacking esxi uses big bus by box to execute most of its commands and so the way bybox works is there's an executable has a lot sim links to it and it will determine what actual program it wants to run based on the the name that you give it when you call it and you give it a name using a sim link to the actual executable file itself. We talked a little bit about abusing Power CLI in this presentation but we didn't actually show it. So if you want a good talk and demo that shows you how to use Power CLI for fun and profit you can definitely look at this talk by Anders Olsen. He's a member of the trusk

team that does incident response for VMware systems. And essentially there are two really key things that he talks about. One of them is the ability to modify and create user accounts on the ESX system using the Power CLI itself. And then there's the ability to start and stop services. So it's a very similar workflow to what we saw with the scattered spider exploits where you would modify some user credentials or you would steal some user credentials. You would turn on SSH and log into the systems. You can automate all of that using Power CLI and do it very quickly. And as a result, the ransomware attacks that we see recently on VMware infrastructure are very fast. Once the

attacker has access to the infrastructure, they'll use Power CLI to automate the attack across all the different hypervisors. They'll log in very quickly. They'll do their ransomware, whether it's slipping off the land or maybe they bring their own malware itself. And from there, they take down your private cloud, which is a very bad date. Another very interesting technique is the use of a rogue VM. So a rogue VM is where you instantiate a virtual machine from the command line on the hypervisor. So you're not actually trying to run a virtual machine like from Power CLI or the GUI. You're doing it under the hood. And the reason this is so cool is because it doesn't show up in the UI. So

you can basically run a VM in the environment that no one really knows about unless they scan for it on the network. And this is a very stealthy technique that allows you to gain persistence on the system. It also allows you to launch further attacks into the network from that guest virtual machine. So if you want to learn about rogue VMs, it's a very good talk by a guy named Christian Moan from a company called ProAT. And that's one of the specific commands that you can use to just run a virtual machine on an ESX system. So, we've talked a whole lot about attacks and I want to dedicate a little bit of time to talking about

defensive resources and how you can defend your environment. So, the first thing are the hardening guides themselves. Broadcom puts out hardening guides for VMware that are very, very good. So, I recommend taking a look at those. One of the key protections that they rely on for the hypervisor is called exec installed only, which we've talked about in this presentation already. And I would not view exec installed only as something that's really going to stop attacks. It will slow them down. It slows them down because you can disable exec installed only by changing a setting on the command line and then rebooting the host. And so it just adds an extra step for attackers to encrypt your systems,

but it requires them to reboot, which gives you a little bit more time to respond. And you can also look for those commands and the logs that relate to disabling exec installed only. That's a good way to detect early behavior before right before ransomware is about to launch. Uh network segmentation is key. Make sure you're using firewalls to block off the hypervisors. The only people that should have network access to the hypervisors would be the system administrators and ideally you're using a jump host to access them. So a jump host can be used. You can put MFA on that jump host and then you SSH in the jump host. From there you access the virtual the the hypervisors themselves.

The guest VMs should be on their own network. They shouldn't be able to talk to the hypervisor. They should be on their own network plane. This allows the hypervisors to be sort of segregated from everything else. Then you can also do MFA for VSCenter. You can do that through active directory or a number of different tools that will allow you to do this. The way to actually get runtime monitoring on the ESX system. One of the ways to do it is through CIS log. So you can just export the SIS log logs from VSCenter and from ESX and do detections in your seam or your sore based on that. I have seen a lot of problems though

with scale. So if you have a large VMware environment, there are issues with scale and and the seams ability to ingest all the logs because the logs can be very noisy. So way to cut that down so that you're not just looking at all the SIS log data because there's just a lot of generic data about VMs starting and stopping and performance is look at specific logs. So the O log, the VODB log, the shell.log, those are logs that have a lot of security relevant data in them. So definitely take a look at those. And we talked about active directory. Don't use your main active directory for your VMR management. Set up a separate active directory. And there are some

tools coming out that are sort of agent-based tools that will run on the ESX system. So there's some companies that have them out. There's some companies that are developing and and releasing them soon. I think these are worth taking a look at as well. And I would say for an agent-based solution to be viable on ESXs ESXi system needs to be really focused on prevention because you're sort of at the last line of defense. The attacker has gotten through your identity protections. They've gotten through your network protections. They're about to do something really really bad and they can do it very quickly from the hypervisor level. So if you're looking for some sort of agent-based protection on the

hypervisor, make sure it's focused on prevention and not necessarily just detecting something and responding because you can get that from SIS log already. And so if you want to use Showdown to scan your own VMware network and see if you have hypervisors that are publicly accessible, these are different uh QR codes that will take you to different queries that you can use. And Showdown is pretty nice because it's free. All you have to do is create an account if you want to do the more advanced scans. And let's say you work for Walmart. It can actually look for specific machines based on your domain. So you work for Walmart, you can look for machines within the Walmart domain.

So with that, I think that's it for the talk. And this QR code here allows you to review the talk. So if you have any feedback, I'd love to hear it. But I will take any questions that anyone might have. Yes, sir. Um, I have a question regarding the VM escape because you mentioned there's a sock 5 like that kind of reminds me of like a Docker escape where you can like if the Docker socket was active you could talk to it and like spin the dump container and I'm kind of questioning is there I because I just don't use VMware I don't know is there like a concept of like a privileged container versus like a

unprivileged using the Docker language but like VM or privileged VM where you can like make it so they don't wouldn't be able to talk to the socket in general or is that just something that isn't >> that's not something that's supported so there's no concept of like a virtual machine that runs at a lower privilege level. The VMX process in VMware runs in a sandbox. So that helps a little bit. But the VSOC socket is kind of like what you were saying. It allows the the attacker to communicate with the host from the guest and that's why they use it in this exploit to get that command and control into the host itself. So the

question is the exec installed only protection that I was talking about that only allows you to run sign code on the host. Is that kernel based? It is kernel based. It's it's code that runs in the kernel and it relies really heavily on secure boot. So if secure boot is turned off, it's pretty easy to disable that setting. But if secure boot is turned on, it requires a reboot to disable that setting. So definitely it's it's a pretty strong protection, but the problem with it is that it doesn't do anything for living off the land attacks because all those tools like OpenSSL and RM are already natively installed on the ESX host and so you can use them to do

some nasty things. So it's good for preventing new executables from being added and at least slowing someone down. so that they have to do a reboot to add a new executable. It's not so good for stopping living off the land attacks. Any other questions? I guess kind of a follow up on that. So then I'm assuming the main reason somebody would want to use a script and be able to run it is for persistence reasons. Um so you can have you can install a script that is always calling up something. Is that why? >> Yes. So certainly you can use a script for persistence reasons. Um another reason to use a script is just to do

ransomware. So you like that command I ran where we did open SSL and RM and all those different commands to encrypt, you can do that to launch ransomware on ESX because all those are natively installed. Okay, cool. Well, it's been a good conference. I hope you enjoy the closing and thank you so much for your time.