During a technical exchange, a client raised a rather common viewpoint:
“Our hypervisors are deployed on an isolated management internal network, separate from the business network, and are completely inaccessible from the outside, so they are very secure and will not be attacked.”
Placing core infrastructure in an isolated network is indeed the first step in security construction and a very correct approach. It is like building a solid “moat” around our data center. However, in the face of today’s highly complex network attack landscape, we must ask ourselves: can we really rest easy just relying on this “moat”?
The answer may not be so simple. Behind this viewpoint lies a classic yet increasingly dangerous security assumption: “There is a distinction between internal and external; the internal network is trusted.” In reality, once an attacker crosses the boundary and enters the seemingly secure “internal network,” this “trusted zone” may become their playground due to a lack of vigilance.
The Attackers’ “God View”: How Do They Bypass the Walls?
Modern network attacks are no longer simply about “direct assaults”; they resemble a precision special operation. If the target is a high-value asset like a hypervisor, attackers rarely attempt to launch an attack directly from the internet. Instead, their roadmap usually looks like this:
Step 1: Find the Weakest Entry Point to Access the “Internal Network”
Attackers are well aware that the management network of hypervisors is difficult to reach directly. Therefore, they choose relatively weak “boundary points” as their breakthrough. These points may include:
- A web server providing external services
- A carefully forged phishing email
- A compromised VPN account
- A third-party software in the supply chain
Note that at this stage, the attackers’ goal is not the hypervisor, but merely to gain a “foothold” in the internal network.
Step 2: Core Tactic – Lateral Movement
Once attackers have a foothold in the internal network (for example, by controlling a web server or an employee’s PC), the real attack has just begun. They will patiently gather information and move laterally, like a ghost silently traversing your internal network.
At this point, the initial “network isolation” strategy will face severe tests:
1. “Jump Point” – Compromised Operations Management Terminal
This is the most common and deadly path. Consider which machine can legitimately access the hypervisor management network?The answer is the operations engineer’s management computer. If attackers control this computer through phishing or other means, they effectively obtain a “VIP ticket” to the core area. In this case, network isolation becomes meaningless because the attackers are using legitimate “people” and legitimate “machines” to cross the isolation boundary.
2. “Bridge” – Unintentional Network Configuration
Ideal network isolation is perfect, but in reality, due to business needs, temporary debugging, or human negligence, there are always some “forgotten corners.” A rule configured for temporary convenience, such as an “any-to-any” rule, if forgotten to close later, becomes a “highway” for attackers to cross the isolation zone.
3. “Pass” – Stolen Credentials
Attackers will use various tools (like Mimikatz) within the internal network to extract login credentials for other systems from the memory of compromised machines. If your vCenter or ESXi uses an account system integrated with domain control (AD), once the domain admin’s credentials are stolen from any machine in the internal network, the attackers gain the highest privileges over the entire virtualization platform.
A Real Attack Scenario Simulation
Let’s imagine a complete attack chain:
- Infiltration – The attacker exploits a website vulnerability to control a web server in your DMZ area.
- Reconnaissance – The attacker scans the internal network through this server, discovers a file server, and exploits a system vulnerability to gain access.
- Persistence – On this file server, the attacker sniffs and captures the domain account password of a regular employee.
- Lateral Movement – The attacker logs into a public test machine in the internal network using this account and finds that this machine has saved an IT operations personnel’s SSH connection configuration and key.
- Privilege Escalation – The attacker uses this key to successfully log into the operations personnel’s bastion host.
- Final Stage – On the bastion host, the vCenter management address is prominently listed. The attacker initiates a ransomware script, connects to vCenter, and issues encryption commands to all ESXi hosts.
Throughout the entire process, the attacker never directly attacked the hypervisor management network. They merely walked step by step to the hypervisor within what you thought was a “secure” internal network. The “network isolation” wall lost its meaning because the “doors” inside were easily opened.
Conclusion: Moving from “Boundary Defense” to “Defense in Depth”
Isolating hypervisors on a network is absolutely necessary, but this is just the starting point for building a security system, not the endpoint. True security is based on the concepts of Zero Trust and Defense in Depth.
This means we must abandon the illusion that “internal network = trusted” and take more comprehensive measures:
- Assume Breach – Design security strategies based on the premise that “attackers are already in the internal network.”
- Strengthen Internal Access Control – Even within the internal network, implement micro-segmentation and strictly limit unnecessary access between any two points.
- Enhance Identity Authentication – Enable multi-factor authentication (MFA) for all critical management entry points (like vCenter).
- Monitor Anomalous Behavior – Conduct rigorous monitoring and auditing of operation logs for hypervisors and vCenter.
- Ensure Clean Operations Terminals – Ensure the highest security for operations management terminals, dedicated for specific use.
In summary, while your hypervisors are in the internal network, they are not an island. In today’s interconnected world, any seemingly unrelated weak point could become the “first domino” that collapses the entire data center. Security protection requires us to take a holistic view and examine every “hidden corner.”