Endpoint detection and response agents sit on operating systems. Baseboard management controllers sit underneath them, on a separate chip with its own network interface, its own credentials and its own firmware. A coverage model built around the host leaves this layer outside the picture.
What the BMC actually controls
A baseboard management controller provides out-of-band management through a dedicated hardware channel. Intel IPMI 2.0, Dell iDRAC, HPE iLO and the Redfish API are the interfaces most commonly exposed. The capability set is broad by design: power cycling a machine that is not responding, mounting virtual media, and viewing a remote console through KVM redirection. The controller has its own power and network path, so it keeps working when the host is powered off or has crashed.
That independence is the feature, and it is also the security problem. Nothing the operating system does, including loading an EDR agent or enforcing a boot policy, constrains the controller's own network services.
What a research effort found
NVIDIA's Offensive Security Research team published an analysis of data centre BMC firmware that produced 18 vulnerabilities and nine working exploits. Several findings share a theme worth extracting.
IPMI authentication still suffers from CVE-2013-4786, the hash disclosure issue, where an attacker who knows a valid username can request a password hash. Username comparison in the affected code used a memcmp call, which creates a timing side channel that supports username enumeration before the hash step is even reached.
The user database is managed through Redis, and the encryption key needed to read stored passwords sits in the same storage as the records it protects. An API exists that can read and write virtual memory in the IPMI service with no region or size validation, and the process runs without address space layout randomization.
A shared telemetry library carries a pre-authentication stack overflow, built on a strcpy call followed by an immediate function pointer call. The affected firmware lacks data execution prevention, stack cookies, address space layout randomization, control flow integrity and sandboxing.
The consequences reach further than the management network. A bootloader parameter can be changed through the BMC KVM to obtain a host shell when Secure Boot is disabled. When Secure Boot is enabled, the same path can reach UEFI settings to turn it off if the firmware setup has no password. An exposed API also allows reading and writing the host SPI flash, which puts NVRAM changes and Secure Boot configuration within reach. The vendor AMI coordinated on the fixes.
Why this belongs in a detection strategy
None of these techniques require an exotic implant. They use the management plane the way an administrator would, which is why host-based detection does not see them and why the resulting account behaviour can look legitimate.
Three practices reduce the gap. Isolate the management network so controllers are not reachable from user segments or the internet. Patch BMC firmware on a schedule, because this layer is often updated only when a server is commissioned. Monitor the controller's own logs for authentication events, configuration changes and firmware updates, then treat a new privileged helper or a changed boot order as an alert rather than a maintenance note.
The broader point concerns where trust boundaries sit. An organization that hardens operating systems while leaving controllers on a flat management VLAN has protected one layer and left the layer underneath it open. Auditing the management plane is part of host security, not separate from it.
Top comments (0)