Because Practical365.com is focused on managing and administering Microsoft 365 environments, we tend to talk a lot about security issues that affect Microsoft products. This is only natural, given that 100% of our audience is using Microsoft products. But humans have known for a long time that monocultures are dangerous. In agriculture and computing, too much dependence on one crop creates vulnerabilities that a more diverse ecosystem can better resist, as with the Irish potato famine and the increasing likelihood that the Cavendish banana will disappear, but also with the rapid and uncontrolled spread of SQL Slammer and SigRed. In that spirit, it’s always a good idea to look at what you can learn from other cultures and systems, so for this column, I want to pivot away from Microsoft and look at another ecosystem that you might have in your network: VMware’s ESXi.
The Microsoft 365 Kill Chain and Attack Path Management
An effective cybersecurity strategy requires a clear and comprehensive understanding of how attacks unfold. Read this whitepaper to get the expert insight you need to defend your organization!
An Uneasy Tradeoff
VMware didn’t invent the hypervisor (that was IBM, back in the 1960s), but I don’t think you can argue against the claim that their work made it a common enterprise technology. By comparison, Microsoft was very late to the game with Hyper-V, and by some measures, you could argue that they still haven’t caught up.
To recap, there are two types of hypervisors: native hypervisors run directly on hardware and provide their own OS, and hosted hypervisors run on top of another native OS. When you run Hyper-V on Windows 11, that’s a hosted hypervisor. When you install VMware ESXi directly on a server, that’s a native hypervisor. With both types of hypervisors, you gain an additional problem: you have more surface area to secure:
- For the native hypervisor, you need to secure the hypervisor itself and the guest VMs it hosts
- For the hosted hypervisor, you need to secure the host OS, the hypervisor, and the guest VMs
This leads to an interesting tradeoff. On one hand, it might seem like maintaining the hosted configuration is more work since it appears to have 3 things to patch- but it’s also fair to say that, if you’re running a hosted hypervisor on Windows Server, you’re basically getting patching for no additional work given that you should already be patching your other Windows servers. Of course, in either case, you have to patch both the guest VM operating systems and any applications you’re running. For example, if you’re running AD FS and two on-premises Exchange servers in VMs, you have at least 3 Windows Server VMs, plus the hypervisor, plus the Exchange and AD FS applications that all need to be patched.
In exchange for this additional surface area, virtualization offers a great deal of flexibility and potential cost savings, not to mention business continuity and high-availability features that were missing from Windows for a long while. Many organizations decided that this tradeoff was reasonable, and that led directly to VMware’s explosive growth and its strong market position. (For another time: this tradeoff remains true when you’re running Windows Server VMs on AWS or Azure, it’s just that you don’t see it as much because the cloud vendor handles patching and maintaining the host OS.)
…Which Brings us to Today
Hypervisors are one of those unglamorous utility services that, in many enterprises, get minimal care and maintenance. As long as they’re working, they’re often left alone. That might sound familiar since the same is true of on-premises Exchange. We’ve covered the various vulnerabilities that have led to ProxyShell and its relatives here, but the biggest problem across all those campaigns boils down to the same thing: people not patching their servers in a timely manner. It turns out that the VMware world has exactly the same problem, witnessing the current spate of ransomware attacks against ESXi servers. The current attacks, broadly known as “ESXiargs,” started in late January 2023 and leverage a remote-code execution (RCE) vulnerability that was patched in 2021 (CVE-2021-21972). Because the vulnerability can be exploited against any VMware ESXi server that’s directly exposed to the Internet, it was simple for attackers to use tools such as Shodan to find vulnerable servers and then drop ransomware on them.
Interestingly, VMWare admitted on 6 February 2023 that these attacks don’t seem to be associated with any zero-days… meaning that applying existing patches would have prevented the attacks. So far, at least 3200 servers have been encrypted (per search data from Censys). In absolute numbers, this is quite a bit smaller than the number of affected Exchange servers, but it’s still pretty early in the life of this particular attack.
What We Can Learn
I think there are two key lessons to learn from this particular attack.
The first is that inertia and failure to patch isn’t just a problem in the Microsoft ecosystem. It’s pretty disheartening to see a two-year-old vulnerability exploited like this. In an ideal world, there would be zero unpatched servers for evildoers to attack. That is clearly unrealistic, but it also has to be said that this isn’t just a Microsoft-centric problem. When your vendors quickly and efficiently release effective patches, and then you don’t apply them, it’s hard to put blame on the vendor.
The second is that If you work in a medium- to large enterprise, the odds are good that you have VMware servers installed. If you do, the risk to the business is real—even though it may not directly impact your day-to-day work as an M365 admin, it may affect the business health of your employer, so it’s worth knowing about. This further reinforces my theory that we’re all security admins now, something I’ll be writing about in future columns. It’s never too late to improve your patch diligence!
