{"id":8132,"date":"2026-03-25T12:00:00","date_gmt":"2026-03-25T10:00:00","guid":{"rendered":"https:\/\/blog.eset.ee\/et\/2026\/03\/25\/virtual-machines-virtually-everywhere-but-not-all-protected\/"},"modified":"2026-03-25T12:00:00","modified_gmt":"2026-03-25T10:00:00","slug":"virtual-machines-virtually-everywhere-but-not-all-protected","status":"publish","type":"post","link":"https:\/\/blog.eset.ee\/et\/en\/2026\/03\/25\/virtual-machines-virtually-everywhere-but-not-all-protected\/","title":{"rendered":"Virtual machines, virtually everywhere \u2013 but not all protected"},"content":{"rendered":"

Twenty years ago, almost to the day, Amazon Web Services (AWS) launched<\/a> Simple Storage Service (S3). A few months later, the company\u2019s Elastic Compute Cloud (EC2) service opened<\/a> for public beta testing before rolling out officially in 2008. These events sparked the era of modern on-demand cloud storage and computing that changed how organizations of all sizes think about their IT infrastructure.<\/p>\n

Fast-forward to the present and you would be hard-pressed to find many organizations that haven\u2019t \u2018lifted and shifted\u2019 at least part of their workloads to the cloud, or aren\u2019t planning to do so soon. Indeed, some now run entirely in the cloud, while many others have paired cloud workloads, often in multi-cloud setups, with on-prem resources that won\u2019t be retired anytime soon.<\/p>\n

Of all the things that these organizations have in common, one warrants a closer look: virtual machine (VM) sprawl, or uncontrolled growth of virtual machines that are often left to fend for themselves.<\/p>\n

A sprawling problem<\/h2>\n

Public cloud service providers (CSPs) make provisioning new VMs frictionless by design; after all, this is partly what makes their offering so appealing in the first place. As many admins can attest, a new VM instance can be stood up within moments, but decommissioning it rarely gets the same urgency.<\/p>\n

In many companies, especially those with multi-cloud setups involving AWS, Azure, GCP and\/or other CSPs, this sprawl results in a growing stockpile of workloads that exist outside security operations. CSPs do provide baseline protections, but the ongoing work falls on the customer. The machines often don\u2019t even receive operating system updates; worse, they\u2019re generally unmonitored and subject to access policies that haven\u2019t changed since the day someone created the instance. This increases the risk that a virtual machine will \u2018go rogue\u2019 while remaining under the radar \u2013 until it\u2019s too late.<\/p>\n

Cloud visibility as such is a persistent problem, as only about 23% of organizations<\/a> report having a comprehensive view of their cloud footprint. Unchecked growth of assets, including fleets of VMs, is a big part of the problem. The staple attack paths \u2013 misconfigured storage buckets and exposed APIs \u2013 dominate breach disclosures, in part because they produce public-facing signals. Meanwhile, VM abuse happens more subtly and inside an environment; a managed identity querying cloud storage won\u2019t set off the same alarms as an external IP address attempting to log in.<\/p>\n

A recent report<\/a> by the Cloud Security Alliance (CSA) ranked misconfiguration and inadequate change control as the main threat for cloud resources, followed by identity and access management (IAM) weaknesses. This tracks with the identity-driven nature of cloud workloads, where both the VM itself and what it can access deserves scrutiny. According to Microsoft\u2019s 2024 State of Multicloud Security Report<\/a>, workload identities assigned to VMs and other non-human resources vastly outnumber human identities, and the gap is only widening as organizations spin up more compute resources.<\/p>\n

The reality is rather mundane \u2013 say, a machine learning engineer provisions a VM for data processing tasks. The VM is granted an identity but since scoping its permissions in keeping with the principle of least privilege would be too time-consuming, it receives broad read\/write access to data storage and other resources. The projects wrap up, but the over-permissioned VMs are \u2018left to their own devices.\u2019<\/p>\n

\"cloud-workload-protection\"<\/a><\/p>\n

Left to rot<\/h2>\n

An abandoned VM can do more than \u2018collect dust\u2019, however. Since every VM is bound to some form of identity that determines what the workload can access across the environment, forgotten instances may be exploited by bad actors to gain an initial foothold. As VMs in the same virtual private cloud (VPC) or virtual network (VNet) can often talk to each other in the \u2018east-west\u2019 direction without much restriction, a VM can probe adjacent instances, reach internal databases or storage endpoints, and exploit whatever permissions it was granted. Far too often, network micro-segmentation turns out to be too daunting a task.<\/p>\n

In hybrid environments involving hybrid identities<\/a>, things can get even more complicated. For example, when on-prem Active Directory is synced with Entra ID, a compromised VM<\/a> in Azure that\u2019s joined to an Entra ID tenant may be able to reach file shares, databases, applications or other resources that are part of the organization\u2019s core on-prem infrastructure.<\/p>\n

Examples of actual attacks involving VMs aren\u2019t hard to come by. In one campaign<\/a>, attackers moved between AWS EC2 instances over internal Remote Desktop Protocol (RDP), staged hundreds of gigabytes of exfiltrated data across multiple VMs, and unleashed ransomware inside the cloud network. Monitoring did catch the activity, but automated response wasn\u2019t properly set up to stop it and the ransomware deployment went ahead.<\/p>\n

Other attackers are exploiting the very ease with which VMs can be spun up. Microsoft has documented<\/a> a campaign in which compromised Azure accounts were misused to provision short-lived VMs as throwaway attack infrastructure. Since the traffic came from legitimate, Azure-associated IP addresses, the alerts were dismissed as false positives.<\/p>\n

Fighting deploy and decay<\/h2>\n

Chances are that your IT and security teams are small and handle security alongside other IT responsibilities, which has a lot to do with what kind of tooling works at this scale. Security products that rely on deep platform-specific expertise, complex deployment procedures and a number of tools for managing various parts of the IT infrastructure may not fit the bill. They may even miss the part of the sprawl problem that matters most.<\/p>\n

Muddying the waters further, what happens when an incident involves identity abuse? An attacker on a rogue VM may not be doing anything that looks suspicious from inside the VM alone when using its identity to access cloud or on-prem resources. Catching the anomaly requires connecting what\u2019s happening on the VM itself to what the VM\u2019s identity is doing across the wider environment. That kind of correlation hinges on integration with identity solutions like Entra ID and Active Directory.<\/p>\n

There\u2019s also the question of speed. When a compromised cloud workload can reach on-prem resources through a federated identity chain, the window between initial compromise and serious damage can be short. (Auto)isolating a VM before lateral movement begins needs to happen at any hour. It\u2019s one of the scenarios where AI-driven correlation and runtime detection earn their keep \u2013 no one can watch every workload around the clock and respond quickly enough.<\/p>\n

Successful incursions cost businesses dearly. According to a recent survey<\/a>, one in three SMBs reported being hit with substantial fines following a cyberattack. It\u2019s also a reminder that non-compliance may come with direct financial consequences. Regulatory frameworks such as NIST 800-53 and PCI DSS 4.0 are getting more specific about cloud workload security and companies are increasingly expected to ensure that the identities assigned to cloud workloads are scoped appropriately and monitored continuously. Demonstrating access controls on the servers hosting sensitive data isn\u2019t enough when the risk resides at the identity layer.<\/p>\n

Meanwhile, IBM\u2019s Cost of a Data Breach 2025<\/a> report found that 30 percent of breaches affected data strewn across multiple environments, which shows the problems that organizations face when it comes to defending their assets in various environments. A meaningful share of the resulting cost traces to the length of time between infiltration and detection, also known as dwell time. Organizations that can\u2019t see what\u2019s happening inside their environments tend to discover breaches through \u2018external\u2019 signals, such as a customer complaint, by which point the attacker has had weeks or months of access.<\/p>\n

Parting thoughts<\/h2>\n

VMs are one of the oldest and most frequently deployed modern cloud resources. VM sprawl accumulates quietly and often reveals itself after something has gone wrong. The unprotected workloads carry identities and communicate with one another and with on-prem resources in traffic patterns that not all security controls can observe and catch.<\/p>\n

For starters, every organization needs to inventory<\/a> its VM fleets across all cloud platforms, review the permissions attached to the identity of each VM, and audit their settings for unnecessary \u2018east-west\u2019 and \u2018north-south\u2019 openness. Good fences make for good neighbors, as the saying goes.<\/p>\n

For organizations running workloads across cloud and on-prem environments, the question is whether their security tooling can keep an eye on VMs with the same rigor as applied to the endpoints on employee desks and other parts of their infrastructure. Only then can they see the full picture and secure their data across various environments.<\/p>\n

Read the full analysis on WeLiveSecurity \u2192<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Cloud VMs offer unmatched speed, scale and flexibility \u2013 all of which could eventually count for little if they\u2019re left to fend for themselves<\/p>\n","protected":false},"author":5,"featured_media":8133,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2879],"tags":[],"class_list":["post-8132","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business-security"],"acf":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/blog.eset.ee\/et\/en\/wp-json\/wp\/v2\/posts\/8132","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.eset.ee\/et\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.eset.ee\/et\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.eset.ee\/et\/en\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.eset.ee\/et\/en\/wp-json\/wp\/v2\/comments?post=8132"}],"version-history":[{"count":0,"href":"https:\/\/blog.eset.ee\/et\/en\/wp-json\/wp\/v2\/posts\/8132\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.eset.ee\/et\/en\/wp-json\/wp\/v2\/media\/8133"}],"wp:attachment":[{"href":"https:\/\/blog.eset.ee\/et\/en\/wp-json\/wp\/v2\/media?parent=8132"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.eset.ee\/et\/en\/wp-json\/wp\/v2\/categories?post=8132"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.eset.ee\/et\/en\/wp-json\/wp\/v2\/tags?post=8132"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}