Something strange happened the other day. While reviewing my enterprise logs in our evaluation QRadar SIEM solution (nice plug right?) I noticed that an internal IP address was scanning the internal IP address of our firewall cluster. The source port remained the same but the destination port incremented by one with each scan. After digging deeper, I was able to determine the MAC address of the offending device and, to my surprise, it was an HP Color LaserJet 2600n printer installed on the desk of one of our VPs. I immediately told him what was going on and he preceded to tell me that this particular printer had previously resided on the desk of our CEO and had been on the network for over a year.

This was about the time my thoughts went into “incident handling” mode…

Was there a rootkit on this printer?

What about a back door or trojan?

Did this printer obtain any sensitive information and send it out to a third party?

I’ve got to get this thing into the lab, pronto!

I confiscated the printer, set it up in the lab (which has it’s own external Internet link) attached to a hub, and plugged a laptop with a packet sniffer running on it. I figured that this would buy me some time to do some more research.

The printer model in question did not, after some research, have any servers running other than the default web interface. Some models did have a telnet server available but this model did not. That made me feel a tiny bit better but still not confident that things were OK.

I stumbled upon the following article which provided step-by-step disassembly of the HP Color LaserJet 2600n. This showed me that the printer did not have a hard drive and led me to believe that if this printer had been compromised it would have probably occurred either at the factory or by someone who was able to get into the guts of the printer. I decided to search for any other similarly reported issues using Google. No one had reported factory default installations of the printer doing anything out of the ordinary.

I then, somehow, stumbled upon an article entitled Using a JetDirect box as an Nmap Idlescan Zombie. From the article:

While I’m on the topic of Nmap and JetDirect boxes, they make great bouncers for stealth Idle scans (also know as Zombie scans) since their IPIDs are incremental. Basically what happen is the Nmap scan is bounced off of the JetDirect box and any logs on the target will show the IP of the JetDirect box as being the attacker.

The author, Adrian “Irongeek” Crenshaw, also provided an example of how to run the scan:

Here is an example of Nmap being run using a JetDirect box as a bouncer. I’ve used the -P0 option so that the host running Nmap does not ping the target first, lessening the stealth value by giving away the scanners true IP.
Irongeek:~# nmap -P0 -sI 192.168.1.93 Irongeek.irongeek.com

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-09-08 17:22 EDT
Idlescan using zombie 192.168.1.93 (192.168.1.93:80); Class: Incremental
Interesting ports on 192.168.1.5:
(The 1654 ports scanned but not shown below are in state: closed|filtered)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
110/tcp open pop3
111/tcp open rpcbind
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
587/tcp open submission

Nmap finished: 1 IP address (1 host up) scanned in 35.262 seconds
Irongeek:~#

Now this sounded like a more reasonable explanation of the anomaly. I informed the “powers-that-be” and let the printer run in the lab for several days with the sniffer connected to it. I did not see any anomalous behavior. I then tried to run the above scan, using the printer as the bouncer, and the results were exactly as expected.

The printer was placed back on the network but I continue to keep a close eye on the IP/MAC in our logs because…you never know.