Decoy · Device

Network printer decoy

Printers sit on every office network and are rarely watched. This decoy poses as PRN-FLOOR2, an HP LaserJet MFP with an embedded web server, the usual print ports, Telnet and SNMP.

Start free trial All decoys

What it emulates

Poses as: Office network printer.

Staff print through the print server, not by logging into a printer. So a login attempt, a Telnet session or an SNMP query against it is not normal office traffic.

HTTP 80
An HP-style embedded web server login page that records every username and password.
JetDirect 9100
The raw print port. Records the first bytes of anything sent to it.
TFTP 69/udp
Records every packet that arrives. Never replies.
LPD 515
The old Unix print port. Records the first bytes of anything sent to it.
IPP 631
Looks like CUPS. Shows a "Ready" printer page and records any print or admin request.
Telnet 23
Shows a login prompt, records every username and password, then refuses. There is no shell.
FTP 21
Records every username and password tried and every command sent. Never lets anyone in.
SNMP 161/udp
Answers basic SNMP read queries and records the community string, which works like a password. Replies are capped per address so it cannot be used to flood anyone. It reports itself as an HP LaserJet with a firmware version and serial number unique to this decoy.

What it catches

Every touch, explained in plain English.

Each event gets a plain-English explanation. Related events from the same source become one incident with a recommended action.

Network scans that sweep the office VLAN
Logins to the printer admin page and Telnet
SNMP queries with guessed community strings
File requests over TFTP, a common way to pull device configs

MITRE ATT&CK

Techniques come from a fixed table, not from AI, so the same activity always maps the same way.

T1046Network Service Discovery
T1059Command and Scripting Interpreter
T1110Brute Force
T1190Exploit Public-Facing Application
T1552.001Unsecured Credentials: Credentials In Files
T1552.005Unsecured Credentials: Cloud Instance Metadata API

Incidents go to email, Slack, your SIEM or a signed webhook. Kandaro and your SOC

Safe by design

Built to be attacked. Never a way in.

A decoy only listens and answers with fake data. It never runs code and only connects out to Kandaro, so it can never become a way into your network.

It runs nothing
The sensor has no way to run a command, load code or update itself. Every command an intruder types gets a fake text answer.
It connects to one place only
Its only outbound connection is HTTPS to the Kandaro API address set at install time. Nothing Kandaro sends can change that address.
Kandaro can only send it settings
Which decoy to imitate, which services to turn off, which addresses to ignore. There is no field for code, files, commands or updates.
It holds no real secrets
Passwords, keys and records it shows are fake. Its only credential is its own key, which can send events for your organisation and nothing more.
It cannot be used to attack others
It never forwards traffic, never fetches a URL and never serves scripts or programs. Its only UDP replies (SNMP) are rate-limited per address.

Non-root, read-only container with signed images. How we secure sensors

Where to put it

Place it where an intruder will look.

Put it in your office or user VLAN, where real printers sit. It looks normal to anyone browsing the network.

Installs in about a minute with Docker, Kubernetes, Ansible, a VM or a Raspberry Pi, and needs outbound HTTPS only. Deployment guide · Where to put your first decoys

FAQ