As reported by The Hacker News, researchers have identified over 36,000 Baseboard Management Controller (BMC) interfaces exposed directly to the public internet — and of those, nearly 24,650 are actively leaking IPMI password hashes to unauthenticated requestors. This isn't a novel zero-day. It's a decades-old protocol weakness colliding catastrophically with chronic misconfiguration at scale.
Why This Is Far Worse Than It Sounds
IPMI's pre-authentication hash disclosure isn't new — the vulnerability has been publicly documented since at least 2013, when Dan Farmer's landmark research exposed fundamental flaws in the IPMI 2.0 specification. The fact that we are still seeing nearly 25,000 systems leaking hashes in 2025 isn't a technology failure. It's an operational failure — one that speaks directly to how organizations manage out-of-band infrastructure.
BMCs operate beneath the operating system. They persist through reboots, OS reinstalls, and even hardware power cycles. An attacker who compromises a BMC doesn't just own a server — they own it at the firmware level. That means:
When the hash is disclosed pre-authentication, an attacker can conduct offline brute-force or dictionary attacks against the IPMI credential without ever triggering a lockout. Default or weak BMC passwords — which are disturbingly common in data center deployments — can fall within minutes.
Who Is Most at Risk
This exposure pattern is most prevalent in environments where BMCs were provisioned for remote management and never hardened post-deployment. The highest-risk profiles include:
- Colocation and bare-metal hosting customers who configure IPMI for remote access without network segmentation
- Mid-market enterprises running on-premises server hardware without a dedicated network operations or security team monitoring OOB interfaces
- Legacy data centers using older Dell iDRAC, HP iLO, or Supermicro IPMI implementations with known IPMI 2.0 weaknesses
- Managed service providers who manage fleets of customer hardware remotely via IPMI without isolating those interfaces on dedicated VLANs
Nation-state actors and ransomware operators alike have demonstrated interest in BMC-level access. Firmware implants such as iLOBleed (targeting HPE iLO) underscore that this attack surface is actively weaponized — not theoretical.
The Systemic Problem: IPMI Was Never Designed for Internet Exposure
IPMI 2.0's RAKP (Remote Authenticated Key-Exchange Protocol) mechanism was designed with the assumption that the management network would be isolated and trusted. The hash disclosure behavior is effectively a feature of the protocol — the server sends the salted hash to the client as part of the authentication handshake, so the client can verify server authenticity. On an air-gapped management network, the risk is tolerable. On the public internet, it's catastrophic.
Shield53 Assessment: Any BMC interface reachable from the public internet should be treated as a compromised endpoint until proven otherwise. The exposure of pre-auth hashes reduces the attack complexity to near-zero for motivated adversaries.
Shield53 Recommendations
Immediate Actions
- Audit exposure immediately: Use Shodan, Censys, or your ASM platform to identify any IPMI/BMC interfaces (UDP/623, TCP/623, TCP/443 for web UI) exposed on public IPs belonging to your organization.
- Block internet access to all BMC interfaces now: BMC management ports should never be reachable from the public internet. Apply firewall rules or ACLs at the perimeter to block UDP/623 and associated web management ports.
- Rotate all BMC credentials immediately on any system that was or may have been internet-exposed. Assume hashes have been captured and are being cracked offline.
- Change all default credentials: Many BMC deployments ship with known default passwords (e.g.,
ADMIN/ADMIN,root/calvin). These must be replaced with long, randomly generated passwords stored in a privileged access management (PAM) solution.
Architectural Hardening
- Isolate BMCs on dedicated OOB VLANs with strict ACLs permitting access only from jump hosts or bastion infrastructure.
- Disable IPMI over LAN where not operationally required — many workloads don't need remote IPMI access at all.
- Implement multi-factor authentication on jump hosts used to access BMC interfaces.
- Enable BMC firmware integrity verification and monitor for unauthorized firmware updates using vendor-specific tooling (e.g., Dell iDRAC Secure Boot, HPE Silicon Root of Trust).
- Log and alert on BMC authentication events — forward BMC syslog output to your SIEM and alert on failed logins or unusual access patterns.
Detection Guidance
- Query your external attack surface for UDP/623 responses — any response indicates an exposed IPMI interface.
- Monitor network traffic for RAKP handshake captures from unexpected source IPs on internal management VLANs.
- Consider deploying deception technology (honeypot BMC interfaces) on management VLANs to detect lateral movement attempts.
The scale of this exposure — nearly 25,000 systems leaking credentials pre-auth — reflects an industry-wide failure to treat out-of-band management infrastructure with the same rigor applied to perimeter-facing systems. BMCs are the most powerful attack vector most security teams aren't monitoring. That needs to change today.
