```html ``` 31,325 Exposed BMCs Hand Out Password Hashes Before You Log In. There Is No Patch. The Biggest Owners Are Hosting Companies Renting You Bare Metal.
top of page

31,325 Exposed BMCs Hand Out Password Hashes Before You Log In. There Is No Patch. The Biggest Owners Are Hosting Companies Renting You Bare Metal.

  • Writer: Patrick Duggan
    Patrick Duggan
  • 1 hour ago
  • 5 min read

Our exposure censuses usually end with a subtraction. When we counted 1,479 internet-facing Ivanti EPM boxes in June, the useful finding was that three-quarters of them were cloud VPS noise, and the number that mattered was much smaller than the number that got reported.


We ran the same subtraction on baseboard management controllers this afternoon and it came out the other way. The hosting concentration is not the noise. It is the finding.



The numbers


Pulled from Shodan today: 31,325 hosts responding on UDP 623, the IPMI port. 31,029 of them serving an IPMI banner. Reporting this week puts roughly 24,650 of those in the population that will hand an attacker a password hash before authentication — about four in five.


By country: United States 12,805, Germany 2,786, China 2,370, Netherlands 1,419, Romania 1,153, United Kingdom 1,114, South Korea 984, India 557, Brazil 534, Italy 518.



There is nothing to patch


This is the part that separates a BMC census from an ordinary "go patch your edge appliance" story, and it is why the number matters more than usual.


The hash disclosure is not a bug in someone's implementation. It is how the protocol works. IPMI 2.0's RAKP authentication handshake returns a salted HMAC of the user's password to anybody who asks for it, before the requester has proven anything at all. That is by design, it has been publicly documented for over a decade, and there is no vendor update that changes it, because changing it would mean not speaking IPMI.


So the usual advice does not apply. You cannot patch this. Rotating the password does not help — a new password produces a new hash that gets handed out just the same. The only controls that work are the ones that stop the port being reachable: put the BMC on a management VLAN, firewall UDP 623, or take it off the internet.


And the thing on the other side of that port is not a web app. A BMC sits below the operating system with its own processor, its own network stack and its own power. It can mount virtual media, reinstall the host, read the console, and power-cycle the machine. It keeps running when the server is off. Compromise it and you own the hardware in a way that survives a wipe, and you do it somewhere the host's EDR cannot see.



Now the subtraction


Here is what the ownership actually looks like. Top organisations by exposed BMC count:


HostPapa 1,422. HostDime 1,026. Contabo 1,005. WholeSale Internet 751. Korea Telecom 580. China Mobile 553. CNServer 551. Tier.Net Technologies 533. EGIHosting 532. Psychz Networks 503. NexonHost 380. OSOLABS 350. Netversor 348. Internet Utilities Europe and Asia 328. And one entry that describes itself, at 322: the entire subnet is used for shared hosting.


Thirteen of the top fifteen are hosting and dedicated-server providers. They account for a little over 8,000 exposed BMCs between them, and that is only the head of the distribution — the long tail is more of the same.


On the Ivanti census we treated that concentration as noise, and we were right to: a management console sitting on a rented VPS is usually a test box or a researcher's scratch host, not an enterprise's production estate. A BMC is the opposite. A hosting provider does not run a BMC for itself. It runs one per customer machine.


So when a bare-metal provider leaves management controllers on the public internet, the exposure does not belong to the provider in any meaningful sense. It belongs to whoever is renting that server — a person who almost certainly believes their exposure is the ports they chose to open, who never configured the BMC, may not know it exists, and cannot see it from inside their own operating system. They did their hardening correctly. The out-of-band channel was never theirs to harden.


That is a supply-chain exposure wearing an infrastructure costume, and it is the reason this census reads differently from the last one. The concentration is not measurement error to subtract away. It is a small number of companies holding the keys to a much larger number of other people's machines.



What to do tonight


If you rent a dedicated or bare-metal server, this is the action item and it takes five minutes. Ask your provider two questions: is my server's BMC reachable from the internet, and what is the credential on it. You are entitled to both answers. If the BMC is exposed, ask for it moved behind their management network or a VPN. If the answer is vague, treat that as a no and price the risk accordingly. Do not assume your provider's default is private — the numbers above say that for thousands of machines it is not.


If you run your own hardware, scan yourself. UDP 623 from outside your perimeter, on every range you own, including the ranges you forgot you own. BMCs get connected during a rack build, on whatever cable was nearest, and never revisited. Then get them onto a dedicated management VLAN with no route to the internet, and treat access to that VLAN as equivalent to physical access to the datacenter — because it is.


If you are a hosting provider, you already know whether you are on the list above. The fix is not a customer education problem; it is a default. Management interfaces should not be routable, and every one of your customers who did everything right is currently depending on you for a control they cannot see or verify.


Everyone: assume any exposed BMC has already had its hashes collected. They are offline-crackable, the collection requires no exploit and leaves no failed-login trail, and the population has been enumerable for years. This is not a race you are early to.



What we are not going to do with this list


We are not putting these 31,325 addresses into our blocklists.


They are victims, not threats. A defender who ingests an exposure census as an indicator feed ends up blocking a hospital, a small hosting customer, or a university — and calls it security. Our feed carries attacker infrastructure. An exposure census is a map of who needs help, and those are different artifacts with different jobs. Anyone publishing the second as the first is selling you a liability.


We hold this at 95 percent. The Shodan totals are a point-in-time reading from this afternoon and will drift; the roughly 24,650 hash-disclosing subset comes from this week's reporting rather than our own probe, and we did not authenticate to anything to confirm it — that would be someone else's machine. The organisational breakdown is the top of the distribution, not a complete accounting, so treat the hosting share as directional and firm rather than exact.


What is not directional: there is no patch coming, and the port is either reachable or it is not. That part you can check yourself in about a minute, which is roughly 31,325 minutes less work than the internet has collectively been willing to do.




Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.


bottom of page