Why Is Your Print Server a Domain Admin?

# Why Is Your Print Server a Domain Admin? Sit down. Stop staring at that dashboard for five minutes. The colors don't mean anything. All that matters is if you can kill a process on a remote host without a system you didn't know existed shouting permission denied in your face. It's Saturday afternoon, September 5, 2026. Your peers are making weekend plans, and you and I are watching the wire, and it shows the people running our infrastructure are still making mistakes we saw in 2003. The real story isn't about the biggest number. It's PaperCut. Attackers use authentication bypasses and remote code execution flaws to walk into schools and universities and steal credentials. Why is that a shock? Because it's a print server. In a sane world, a print server is a utility like a water fountain, and you put it in a VLAN where it can talk to a few printers and some users. But someone twenty years ago wanted integration with the rest of the network. They gave the service account too much power, left it on the same segment as database servers, and likely haven't audited permissions since the Obama administration. If an attacker pops a print server and immediately gets credentials for the whole university, that isn't sophisticated. It's bad hygiene. I hate seeing that word in post-incident reports. When a CISO or vendor calls an attack sophisticated, they're usually hiding the fact they propped the back door open with a brick. What does this cost you on a Tuesday? If your print server is a gateway to the domain controller, it costs you everything. You aren't losing PDFs. You're losing the identity of every faculty member and student on campus. The usual argument is that these environments are too complex for perfect segmentation, and they say moving a print server to another VLAN breaks half the labs. Fine. Don't give the server a service account with domain-level permissions then; treat it as compromised from day one. If you haven't priced in the cost of your print server being a beachhead, you aren't managing risk, and you're just hoping for the best. Which brings us to the second disaster on the pile: Babuk and VMware vCenter. Babuk is hitting companies in over 40 countries right now by using CVE-2026-59310. This part is what should worry you: hackers started using this flaw just five days after Broadcom told everyone about it. Five days. That isn't a window of time. It's a crack in the door. I still think about NotPetya; I remember watching global networks go dark in hours because people trusted one update system. It's the same problem here with a single point of failure. vCenter is the brain of your virtual setup. If Babuk gets into vCenter, they haven't just hit one server. They have every single VM on those hosts. The ripple effect is what kills you. Your backups are often gone too if they're running as VMs on that same cluster. You aren't restoring from tape here. You're wondering where the hardware manuals went. Insurers will love this because so many firms shoved their entire stack into one virtual bucket without any air-gapped way to recover. If your patch process takes two weeks for testing, you already lost. With a five day exploit window, containment is the only thing that works. Can't patch in 48 hours? Isolate those management interfaces from the rest of the world right now. Then there's the identity mess. The FBI is looking into a breach affecting just under 170 million people in North America. Some reports say it's 153 million driver's license records, and now IDScan, an identity verification company, is facing a lawsuit. It's ironic that a vendor paid to protect IDs leaked them. These companies sell trust. They tell you their service proves who is on the other side of a deal, and by leaking 153 million records, they just built a gold plated directory for every fraudster around. People getting identities stolen is bad enough. But think about the thousands of businesses that used IDScan to verify customers, and every account "verified" through that system is now suspect. If I have 150 million real licenses, I don't have to hack you. I just pretend to be your customer and pass the check with stolen data. The trust chain is broken at the root. Why focus on the big numbers? You see 170 million here or DaVita paying over $15 million in a settlement, but don't get distracted by the money. Look at the common thread. Technology changes. We went from Code Red hitting IIS servers to Babuk hitting vCenter and Iranian officials like Amir Yaryab targeting critical infrastructure; the US government wants $10 million for info on him, but money doesn't stop a packet. What stops the packet is a blunt refusal to let everything talk to everything. The numbers for this week tell the story, and technology and Government are the biggest targets, with tech taking over 320 hits. It makes sense because that's where the aggregated data sits, and these criminals aren't looking for a single person. They want the bucket. They're after the IDScan bucket, the vCenter brain, or the university credential dump. How do you survive this? Stop worrying about "threat actors" and start thinking about blast radius. If some attacker pops your print server on a Tuesday morning, what happens next? Do they end up in a room with no windows, or do they get the keys to the kingdom? If the answer is the keys, then you aren't an analyst; you're just a spectator watching a slow-motion wreck. I'm heading out for some coffee. While I'm gone, you should take a look at your network map. Find every device that does just one thing (printers, scanners, power managers, ID verifiers) and ask yourself why on earth it has a route to your most sensitive data. Start cutting those routes. Don't wait for the patch. The patch is always too late.