24,650 BMCs Leaking IPMI Hashes: Is Your Management Plane Exposed?
Just came across the report regarding 24,650 internet-exposed BMCs leaking password hashes before login. We've talked about IPMI risks for years, but seeing these numbers in 2026 is alarming. The issue stems from specific implementations where the RAKP authentication mechanism discloses the password hash (often SHA1 or MD5 based) to the client for verification before authentication is complete.
This effectively allows attackers to harvest credentials offline without triggering account lockouts. Once they have the hash, it's just a matter of time before they crack it and gain full access to the baseboard—giving them the ability to re-image servers, inject keyloggers, or modify the firmware.
If you manage server infrastructure, you need to audit your perimeter immediately.
You can scan your ranges using Nmap to check for exposed IPMI services and weak cipher suites:
nmap -sU -p 623 --script ipmi-version,ipmi-cipher-zero -Pn
If you are automating this check across your asset inventory, here is a quick Python snippet to identify if port 623 is accepting connections:
import socket
def check_ipmi(ip):
try:
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.settimeout(2)
result = sock.connect_ex((ip, 623))
sock.close()
return result == 0
except Exception as e:
return False
print(check_ipmi("192.168.1.100"))
Mitigation is straightforward but strict: move BMCs to an isolated management VLAN and disable IPMI over LAN if remote management isn't strictly necessary. Never expose port 623/UDP to the public internet.
How is everyone handling legacy hardware that forces IPMI 1.5? Are you segmenting it off or decommissioning it entirely?
We decommissioned any hardware that couldn't disable IPMI 1.5 years ago. It’s just too big a risk. For everything else, we enforce a strict 'no IPMI on the internet' policy. All our iDRAC and iLO interfaces sit on an Out-of-Band (OOB) VLAN that is only accessible via a VPN bastion host. It adds a slight latency to management, but the security trade-off is worth it.
Great post. From a SOC perspective, we've started monitoring for outbound UDP/623 traffic. We shouldn't see our BMCs talking to anything outside the management subnet. If we do, it's an immediate indicator of compromise or misconfiguration.
DeviceNetworkEvents
| where RemotePort == 623 and Protocol == "UDP"
| summarize count() by SourceIP, DestinationIP
Don't forget that you can often crack these hashes with Hashcat using mode 7300. If an attacker gets the hash, they don't even need the BMC interface to stay online to get in—they can wait until they have the password. If you can't patch, consider using the 'lan plus' interface only over SSH tunnels rather than raw web interfaces.
To proactively identify vulnerable systems before they are exposed, we aggressively scan internal management subnets for legacy IPMI configurations. Relying solely on firewall rules isn't enough if a VLAN is misconfigured.
Here’s a quick Nmap command to identify BMCs and their versions so you can prioritize patching or isolation:
nmap -sU -p 623 --script ipmi-version 192.168.100.0/24
Has anyone else noticed this issue appearing on newer iDRAC9 firmware that was simply misconfigured during provisioning?
While scanning is crucial, verifying if a specific BMC is actively leaking the hash is a solid next step for triage. You can use Metasploit's auxiliary/scanner/ipmi/ipmi_dumphashes to confirm the issue remotely during your internal assessment.
use auxiliary/scanner/ipmi/ipmi_dumphashes
set RHOSTS
run
If you can't decommission hardware immediately, check if you can restrict cipher suites to force IPMI 2.0-only with HMAC-SHA2, though not all vendors support this patch. It won't stop the leak in 1.5, but it limits the scope.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access