Data Centre Security Assessment: Hypervisors, Management Controllers and the Way Back From Ransomware

Infrastructure Security

Moving workloads to the cloud did not empty the data centre. What stayed on premises is usually the most sensitive part of the estate: domain controllers, core databases, the backup system and the network backbone. Ransomware groups have also learned that encrypting one hypervisor takes down every virtual machine on it at once. A data centre security assessment should therefore start where an attacker would: the management plane underneath everything else.

What a data centre security assessment covers

A useful data centre security assessment looks at physical and logical controls together, because an attacker who gets past one usually needs the other. The table shows the layers and what typically goes wrong in each.

Why attackers go for the hypervisor

Encrypting servers one at a time is slow and noisy. Encrypting the hypervisor's datastores stops every virtual machine on that host in one step, including the ones with endpoint protection the attacker never had to touch. Recent campaigns show three different ways in.

The lesson is not about one product. Whatever hypervisor you run, the questions are the same: who can administer it, from where, how quickly it is patched, and what an attacker who already holds a domain admin account can do to it.

One attack path, step by step

Public advisories from Microsoft and CISA describe the same sequence again and again. The path below is a composite of those patterns rather than a single incident, with the control that breaks each step.

Hypervisor hardening: what we check

Hypervisors that run domain controllers need particular care. Microsoft's guidance is that you must manage the host where you run virtual domain controllers "as carefully as you would a writeable DC". In tiering terms, that host and whatever manages it belong with the directory itself. It also helps to keep at least one domain controller that does not depend on the same virtualisation platform, so the directory survives the loss of the platform.

Baseboard management controllers: the server's second computer

Almost every server has a baseboard management controller (BMC): HPE iLO, Dell iDRAC, or a generic IPMI interface. It runs independently of the operating system and can power the server on and off, open a remote console, mount virtual media and update firmware. Whoever controls it controls the server, below the reach of any security software running on it.

BMCs are also among the most neglected devices in a data centre. They are set up once at installation and rarely revisited, so assessments find default or shared passwords, firmware years out of date, and interfaces on the same network as ordinary servers or users.

• IPMI has a protocol-level weakness. The IPMI 2.0 specification has the controller send a salted hash of a user's password before the client has authenticated, so anyone who can reach the interface and guess a valid username can collect a hash to crack offline. Some implementations have also accepted any password when "cipher zero" is enabled.
• BMC firmware is a target in its own right. In December 2021, researchers at the Iranian security firm Amnpardaz reported a rootkit, dubbed iLOBleed, hidden in HPE iLO firmware. It was used to wipe servers, faked firmware upgrades so that it survived them, and persisted across operating system reinstalls. HPE said it exploited flaws patched in 2018.
• Government guidance is clear. In June 2023, CISA and the NSA published joint guidance on hardening BMCs, noting that "hardened credentials, firmware updates, and network segmentation options are often overlooked, leading to a vulnerable BMC." Their advice: change default credentials as soon as possible, limit the systems that can talk to BMCs to a dedicated administrative network, and check for firmware updates routinely. It follows that a BMC should never be reachable from the internet.

A BMC hardening baseline to assess against:

• Unique credentials for every controller, stored in a password vault, with factory defaults removed.
• Dedicated management ports connected only to the management network, never to user or server networks, and never reachable from the internet.
• Unused protocols disabled: IPMI over LAN where it is not needed, legacy SNMP versions, and unencrypted web or console access.
• Firmware on a regular update cycle, checked against the vendor's security advisories.
• Remote console and virtual media restricted to named administrators, with logs forwarded to a central system.

The management network

Hypervisor, BMC, storage and network device interfaces should all sit on a management network that ordinary users and servers cannot reach. In assessments this is often true on the diagram and false in practice: a firewall rule added for a contractor, a route left from a migration, or an admin's laptop that sits on both networks.

The test is direct. From a user workstation and from an ordinary server, try to reach the management interfaces. Then check how administrators actually get in: through a hardened jump host with MFA, or straight from their everyday laptop. A firewall review of the rules into the management network usually explains every gap the test finds, and a network architecture review designs the separation properly.

Detecting attacks on the management plane

Most of these attacks leave signals in places a SOC does not watch by default. Make sure these reach your SIEM, and that the logs leave the host before anything can delete them.

Our guide to detection engineering covers how to turn signals like these into detections that stay useful.

Storage: where the data actually lives

Storage arrays and NAS devices hold the virtual machine disks, file shares and often the backups. Check that SAN zoning and LUN masking limit each host to the storage it needs, that array and NAS admin interfaces are on the management network with individual accounts, and who can delete snapshots. An attacker with array admin access does not need to encrypt anything: deleting volumes and snapshots is enough. Some arrays can protect snapshots from deletion for a set period, or require a second administrator to approve it; where that exists, turn it on for the volumes that hold virtual machines and backups.

Backups: keep the way back out of reach

Ransomware operators look for the backups early, because recovery without paying depends on them. The most common weakness is shared trust: a backup server joined to the production domain, backup consoles administered with domain admin accounts, or backup storage that the same credentials can delete.

CISA's #StopRansomware Guide warns that "many ransomware variants attempt to find and subsequently delete or encrypt accessible backups", and recommends keeping offline, encrypted backups of critical data and regularly testing their availability and integrity. Backup vendors say the same about trust: Veeam's security guidance puts it as "a data protection system should not rely on the environment it is meant to protect in any way!" In practice, that means at least one copy that cannot be changed or deleted for a set period even by an administrator, backup infrastructure with its own credentials outside the production directory, and restores that are tested, timed and recorded. Our guide to setting RTO and RPO you can meet after ransomware covers how fast those restores need to be, and a ransomware readiness assessment tests whether the whole recovery chain holds when the hypervisor is the target.

Physical and environmental controls

Physical access still bypasses most logical controls: someone in the room can plug into a console port, remove a disk or attach a device to the management network. Assess access control configuration and its logs, CCTV coverage and blind spots, the visitor and contractor process, and rack and cage locks. ISO/IEC 27001:2022 groups its 93 Annex A controls into four themes, and 14 of them are physical controls covering perimeters, entry, secure areas, monitoring, equipment, utilities and cabling, so physical findings map directly onto them.

In practice, physical testing means:

• Comparing the access control list with HR records, to find leavers and contractors whose badges still work.
• Reviewing access logs for out-of-hours entry and doors held or forced open.
• Observing, with authorisation, whether tailgating through controlled doors is challenged.
• Mapping CCTV coverage against entrances, cages and rack rows, and checking how long footage is kept.
• Checking how rack keys, spare badges and removable media are controlled, and how failed disks are destroyed.

In a colocation facility, physical security is shared. The provider is responsible for the building and its perimeter; you are responsible for your cage, your equipment and who you authorise to enter. Use the provider's independent audit reports for their side, and assess your own.

Environmental resilience is a separate question. Uptime Institute's Tier classification, from Tier I to Tier IV, rates a facility's site infrastructure for availability, and ANSI/TIA-942, revised as TIA-942-C in 2024, sets infrastructure requirements for data centres. A high tier rating tells you the power and cooling are designed to keep running; it does not tell you the servers inside are secure.

Redundancy is usually described as N+1, one more component than the load needs, or 2N, a complete duplicate of every component. The question to assess is whether it has been tested: would the loss of one power feed, one cooling unit or one network path actually be absorbed? That is part of BCDR planning, and it is worth testing before an incident does it for you.

How the assessment runs

Preparing for the assessment

• Network diagrams, including the management network and how administrators reach it.
• An inventory of hosts, management servers, BMCs, storage arrays and backup systems, with versions.
• Read-only access to the management server, backup console and storage management for configuration review.
• The physical access control policy, the current access list and recent access logs.
• Backup design documents and the records of recent restore tests.
• For colocation, the provider's latest independent audit reports.

Data centre security checklist

Frequently Asked Questions

Click any question to expand the answer.

Related reading

For the directory that so often holds the keys to the hypervisor, see Active Directory security: hardening against modern attacks. For the wider ransomware picture, the ransomware defence playbook for India. For the network devices at the edge of the same estate, what recent edge-device zero-days say about your perimeter.

Sources