AI worm in an IoT printer: three firewall rules that hold

Friday, 21:47. An MSP partner of ours forwarded a Sentinel alert: a Konica Minolta multi-function printer in a 40-person legal office was opening outbound TLS connections every 90 seconds to a host none of us recognised. The printer should be sending one thing to the internet, ever: a firmware-check call to the vendor. By midnight, what looked very much like the foot end of an AI-driven worm was sitting on its print spooler.

The night that followed turned out to be a tidy little case study in why printers are still the soft underbelly of the office network, and what stops a worm once it has landed there. Below is the walkthrough, the three firewall rules that contained the incident, and a note on what shifts when the worm doing the pivot is wired to a small language model.

What the printer was actually doing

The first twenty minutes were unglamorous. We pulled the printer's outbound flow from the pfSense box, resolved the destination IP, and got a fresh Let's Encrypt cert on a .top domain registered nine days earlier. The TLS SNI matched. The user agent on the rare HTTP fallback was a stock curl/8.5.0. That ruled out the vendor.

The printer had been compromised through its embedded web admin. Default credentials had been changed years ago, but the device exposed an unpatched IPP endpoint on TCP/631 to the office LAN, and a file-upload bug in the spool handler let any LAN-side caller drop a file into the print spooler with execute bits. The chain is depressingly familiar: there are dozens of CVE-listed IPP issues across MFP vendors over the past two years that follow the same pattern. From there, a small ELF binary was running as the print daemon's user, beaconing to its C2 every 90 seconds, and waiting.

What it was waiting for, we worked out by 02:00. Each beacon got back a tiny JSON instruction. Most were no-ops. Two were not. One asked the printer to scan its own /24 for hosts answering on TCP/445. The other asked it to attempt an authenticated SMB connection using a list of usernames the printer had cached, earlier, from the Active Directory print-queue metadata it kept in plaintext.

That is the pivot. The printer is the beachhead. Active Directory is the prize.

Why a printer is the perfect pivot point

If you were designing an attack surface for an attacker, you would build a printer. It runs a full Linux userland with a kernel from somewhere around 2018. It has credentials for the file server (for scan-to-folder), credentials for the mail server (for scan-to-email), and a service account in Active Directory (for secure print release). It sits on the office LAN. It is rarely patched. It is almost never monitored.

And it has been this way for a decade. The Zero Day Initiative's Pwn2Own contest has had a dedicated printer category since 2021, and every year competitors land pre-auth RCE on the major vendors inside the time-box. ZDI's writeups are worth a read if you want to lose your faith in firmware. The HP, Lexmark, Canon, and Konica fleets each ship multiple high-severity advisories per year; a casual search on NVD for "printer" returns hundreds of results, the vast majority post-2022.

The endpoint protection market knows this. Almost none of it ships an agent that runs on a printer. EDR coverage on the office floor stops at the workstations and the file server. Your MFP is, in security terms, an unsupervised Linux box that holds credentials for the systems your EDR is paid to protect. The same is true of the IP camera in reception, the voice gateway in the comms room, and the badge-reader controller in the kitchen ceiling. None have EDR. All have credentials for something they reach across the LAN.

None of this is new. What is new is that as of 2026, the C2 on the other end of that beacon does not need to be a person at a desk choosing the next command. It can be a small model with a goal, a tool-use loop, and a memory of what worked on the last fifty networks it landed on.

The AI-worm era is here, quietly

Researchers at Cornell Tech and the Technion published a proof-of-concept called Morris II in early 2024, a worm that propagated through GenAI-powered email assistants by smuggling adversarial prompts inside their own outputs. The 2026 variant we are watching does something simpler and meaner: it leaves the device dumb and puts the brain in a small model on the C2 end. The implant on the printer was 84 KB. The worm logic was not in the binary. It was in the conversation between the printer and the C2, in JSON, in English.

The printer ran the foot soldier. The model ran the brain. The bandwidth cost of a beacon-plus-instruction was under 2 KB per round trip. We could have missed it for months if the EDR had not flagged the destination domain as new. The thing that should bother you is that the same architecture works on every other unmanaged Linux box on your office floor. The model does not care which one it lands on.

The three firewall rules that hold

We have a habit, when we audit a client's network, of writing exactly three rules for the printer VLAN and watching how many are already in place. Almost never all three. Sometimes none.

Here they are, in iptables form so they read like an instruction rather than a vendor screenshot. Adapt the syntax to your edge: pfSense, OPNsense, Fortigate, Meraki, whatever. The point is not the syntax. It is the three directions of traffic.

Rule 1: printers do not initiate egress, except to the vendor

# Allow firmware checks to the vendor's published API host
iptables -A FORWARD -s 10.50.20.0/24 -d konica.api.example.com \
  -p tcp --dport 443 -j ACCEPT

# Allow DNS and NTP to the internal resolver only
iptables -A FORWARD -s 10.50.20.0/24 -d 10.50.10.53 -p udp --dport 53  -j ACCEPT
iptables -A FORWARD -s 10.50.20.0/24 -d 10.50.10.53 -p udp --dport 123 -j ACCEPT

# Drop everything else outbound
iptables -A FORWARD -s 10.50.20.0/24 -j DROP

The C2 beacon we caught would have died on the first hop with this rule in place. The printer has no business reaching Let's Encrypt-fronted .top domains, ever. Default-deny egress on the printer VLAN turns the device into a bottle. Whatever lands on it stays on it. The fact that the worm uses HTTPS does not matter; the rule is on the IP and port, not on the payload.

Rule 2: printers cannot initiate east-west, except to the print server

# Allow the printer VLAN to reach ONLY the print server on the spool port
iptables -A FORWARD -s 10.50.20.0/24 -d 10.50.10.25 \
  -p tcp --dport 9100 -j ACCEPT

# Block all other lateral traffic from printers to internal subnets
iptables -A FORWARD -s 10.50.20.0/24 -d 10.50.10.0/24 -j DROP
iptables -A FORWARD -s 10.50.20.0/24 -d 10.50.30.0/24 -j DROP
iptables -A FORWARD -s 10.50.20.0/24 -d 10.50.40.0/24 -j DROP

This is the rule that stops the SMB scan. The printer tried to find any 10.50.x.x host answering on 445. With east-west deny in place, the scan returns nothing and the worm has nothing to pivot into. The print server is the single allowed neighbour, and only on the spool port. If your fleet uses scan-to-folder or scan-to-email, add the file server and mail relay as named exceptions on the specific ports they actually need. Two extra lines. Not the whole subnet.

Rule 3: workstations and servers do not initiate connections back to printers

# Allow only the print server to push jobs and status queries to printers
iptables -A FORWARD -s 10.50.10.25 -d 10.50.20.0/24 -p tcp --dport 9100 -j ACCEPT
iptables -A FORWARD -s 10.50.10.25 -d 10.50.20.0/24 -p tcp --dport 631  -j ACCEPT

# Block everything else from internal hosts toward printers
iptables -A FORWARD -d 10.50.20.0/24 -j DROP

This rule is the one people forget. If a worm runs the other direction, say, off a compromised workstation looking for printer firmware to backdoor as a persistence cache, the only host with a path in is the print server. That is one box to harden, not forty. It also kills the casual reconnaissance pattern where an attacker who has landed on a user workstation pings the entire printer subnet to map what is out there.

Three rules. Two prevent the printer being used as a pivot. The third prevents the printer being used as a persistence cache. Together they would have collapsed the incident into "device beacons to C2, fails, gives up". The investigation log would have read like nothing happened.

What the agent on the C2 actually does

It is worth being precise about the role of the language model in this attack, because the security press tends to overcook it. The model is not doing zero-day discovery. It is not writing shellcode. It is doing what models do well: reading a structured description of an unfamiliar environment, picking the most useful next action from a short menu, and learning across runs which menu items pay off on networks that look like yours.

The printer reports, in plain text, what it sees: open ports on neighbours, response banners, cached credentials, the contents of /etc/passwd if it can read it. The model picks one of perhaps thirty pre-canned sub-routines: scan_subnet, try_smb_login, exfil_file, drop_persistence. The choices are dull. The thing that has changed is that there is no longer a human latency in the loop. The pivot from foothold to lateral movement used to take an attacker days. With a model in the driver's seat, it takes minutes.

This is why firewall posture matters more, not less, in the AI-worm era. Detection windows are shrinking. The defences that hold are the ones that do not require detection at all.

What a five-minute audit looks like

You do not need a SIEM to know whether you are exposed. Pick the printer VLAN at your largest office and run three commands.

# 1. From a non-print-server workstation: can you reach printers on risky ports?
nmap -sS -p 80,443,445,631,9100 10.50.20.0/24

# 2. From the printer (SSH or device debug shell): can it reach the internet?
curl -m 5 -o /dev/null -w "%{http_code}\n" https://cloudflare.com

# 3. From the printer: can it reach a non-print-server host on SMB?
nc -zv -w 3 10.50.10.40 445

If the first command returns open ports anywhere outside the print server's direction, rule 3 is missing. If the second returns 200, rule 1 is missing. If the third connects, rule 2 is missing. Five minutes of work and you know exactly how much exposure you are carrying.

Closing

The Konica we started with got pulled, reflashed, and put back on a VLAN with all three rules. The client paid an invoice for the night. They have not had a repeat. The interesting part is that the rules cost nothing: their existing pfSense was capable of all three from day one, and the day-one config was "allow any any" because that is what the vendor's quick-start guide produces. The fix was a configuration change, not a purchase order.

When we built the network triage agent for one of our MSP clients last quarter, the thing we kept hitting was that the model is fast at flagging anomalous flows but slow at writing the firewall rule that actually contains them. We ended up shipping the agent with a library of pre-validated rule snippets, keyed by device class, so the human on call could read, sanity-check, and paste in under a minute. Printers were entry one in the library.

Pick the noisiest device on your network this afternoon. Run the three commands. See how many of the three rules you already have.