Back to SETEC LABS
The Printer That Knew Too Much
By: CryptK

The call came in on a Tuesday, which is when the city does its worst work. SsSnake patched it through to my terminal around half past ten. A law firm. The kind that handles cases powerful people would rather not see in print. One of their people had noticed something wrong on the wire — traffic leaving the building at three in the morning, heading somewhere it had no business going. Small packets. Quiet. The kind of quiet that only looks peaceful until you know what to listen for.

SsSnake put it on my desk because encrypted traffic is my territory. Always has been. I pulled the client's captures and spread them out under the lamp. Small payloads, 200 to 400 bytes apiece. TLS 1.3, proper certificate pinning, no obvious seam to pry open without keys I didn't have yet. Whoever had built this hadn't been sloppy. Sloppy I can dismiss in an afternoon. This was the work of someone who knew what they were doing, which meant it was worth knowing what they were doing it for.

The source was a printer. Multifunction. High-end. The kind of machine that sits in a corner and pretends it's furniture until someone needs a cover sheet. The client had given it network access because that's what you do when the leasing company hands you a device and the IT checklist says "add to domain." Nobody audits the printer. Nobody watches the printer. The printer just sits there, warm and slightly humming, holding its secrets behind a plastic bezel.

This printer had a lot of secrets.

They let me in on a Wednesday morning. I didn't travel light — I never travel light — but the device couldn't leave the building. Attorney-client privilege. Documents stored in the printer's memory constituted protected work product. Fair enough. The case had to be cracked on-site, in a conference room that smelled like burnt coffee and old carpet, with a logic analyzer, a JTAG adapter, and whatever patience I could scrape together before noon.

The machine had a service port running serial. I jacked in and pulled the firmware. Standard RTOS underneath, manufacturer application layer on top. Print spooler, scan engine, fax module — yes, this firm was still using fax, and no, I did not editorialize, because the fax module was not the problem. The problem was what sat next to it in the process table. A kernel module, unsigned, unlisted in any documentation the manufacturer had ever published. It had loaded at boot. It had hooked itself into the print spooler. It had been there since the last firmware update, silent as a man reading your mail over your shoulder on a crowded train.

Every document that passed through that printer — printed, scanned, copied — passed through the module first. OCR extraction. Compression. Then encryption, AES-256-GCM, proper nonce handling, the whole respectable architecture. The kind of implementation that would make a cryptographer nod with professional approval right up until they asked what the key was derived from.

The key was derived from the printer's serial number.

Using HKDF, which is correct. Derived from the serial number, which is printed on a sticker, on the back of the unit, readable by anyone with working eyes and the ability to walk around a piece of office furniture. Textbook-perfect authenticated encryption, keyed with information printed on the outside of the goddamn box. I sat with that for a moment. Two moments. Some revelations require a beat of silence before you can write them down in your case notes without the pen tearing through the paper.

I derived the key. I decrypted the captures. Then I read them, and what I read was everything — case files, correspondence, attorney work product, the full recorded life of a law firm that handles cases sensitive enough that powerful people hire quiet men to know things about them. All of it, packaged neatly, transmitted to a server that gh0stwire traced back through the infrastructure to a company providing "data analytics services" to multiple government agencies. I will stop there, because I am choosing my words carefully and the careful choice is to stop there.

The report was written in my own cipher. Delivered in person on an air-gapped machine that was wiped in the parking lot before I drove away. The client filed an emergency motion. Legal proceedings are their domain. Mine is knowing when a printer has been turned into an intelligence asset and by whom.

Disclosure went to the manufacturer. Four weeks of silence, then a response: the module was a "diagnostic feature" inadvertently included in a firmware update, not intended for production devices. Patch issued. No explanation of who wrote the module. No explanation of who operated the receiving server, or what agreements existed between that company and the agencies it served. The server went dark three days after my disclosure. The domain expired. The hosting account closed. Someone on the other end had been watching the inbox.

The firm uses different printers now. Hardware I inspected personally, firmware I verified against known-good images, installed on a network gh0stwire designed with the kind of care he usually reserves for infrastructure that really matters. Outbound connections from the print subnet: none permitted. Not to update servers. Not to manufacturer portals. Not to anywhere. The printers print documents. The documents stay in the building. This is all a printer is required to do, and it is the hill I will be buried on if it comes to that.

There's a lesson in all of this, if you want one. A cipher is only as strong as its key management. A key management scheme is only as strong as its worst assumption. And a manufacturer that ships OCR-and-exfiltrate capabilities in production firmware and calls it a diagnostic accident when caught is telling you everything you need to know about who they really work for, and no press release is ever going to unfuck that.

The printer knew too much. Now I know more.

— CryptK, 2026

Back to SETEC LABS