Honeypots
A sensor can run decoy services, called honeypots, while it isn't scanning. Anything that connects to them is recorded on the Honeypots page: who connected, which credentials they tried, which commands they ran and which files they tried to download. You can be alerted by email or webhook when a new attacker appears. Honeypots run on your own sensors only. Cloud scanners don't run them. You can also build your own decoys — a script, a canary file or account, or the AD CS decoy — and send what they catch here. See Custom honeypots. Turn on honeypots on a sensor Only people who manage sensors can change honeypot settings: the Administrator role, organisation owners and admins, and personal accounts. Go to Sensors, open a sensor and select the Honeypot tab. You can also go to Honeypots > Sensors and select a sensor. Turn on Run honeypots. Under Listen on, choose the interfaces. Honeypots answer only on the addresses of the interfaces you choose. If you choose none, nothing listens. Under Services, choose the services to imitate, and the ports for each. Only the ports you tick are exposed. Optional: under How they present themselves, set the names attackers see (see Names and devices). Select Save. The sensor applies the settings straight away, or when it next reconnects if it's offline. You must choose at least one interface and one port. How a sensor runs honeypots: They pause during scans. Honeypots stop while a scan runs on the sensor and start again afterwards. The sensor opens only the chosen ports. It opens exactly those ports in the host firewall while the honeypots run. You can expand Show rules to see the rules it added. Ports already in use are skipped. If the host already uses a port (for example, its own SSH on port 22), that port is skipped and marked port in use. Nothing on the host is stopped. Honeypots can't connect out. They can't reach into your network or out to the internet. Download attempts record the URL, but the file is never fetched. Services Service Ports What it records SSH / Telnet 22, 23 Interactive SSH and Telnet: logins with passwords, commands typed, files attackers try to download. Windows & databases 21 (FTP), 135 (Microsoft RPC), 445 (SMB), 1433 (Microsoft SQL Server), 1723 (PPTP VPN), 1883 (MQTT), 3306 (MySQL), 27017 (MongoDB), 69/udp (TFTP) Connections, logins and exploit attempts, such as worms spreading over SMB. Credential catcher 110 (POP3), 143 (IMAP), 465 (SMTPS), 993 (IMAPS), 995 (POP3S), 1080 (SOCKS5 proxy), 5432 (PostgreSQL), 5900 (VNC) Which usernames and passwords attackers try. Mail (SMTP) 25, 587 An SMTP server that looks like an open relay: spam and credential attempts. Industrial (ICS) 2404 (IEC 60870-5-104), 161/udp (SNMP) An industrial controller. Redis 6379 An unauthenticated Redis server: the commands attackers run. Elasticsearch 9200 An open Elasticsearch: queries and exploit attempts. Android debug (ADB) 5555 An exposed Android Debug Bridge: commands and payloads. Web (HTTPS) 443 A web server that answers like commonly exploited products: requests and exploit attempts. Service status Next to each service and port, the tab shows what the sensor reports: Status Meaning listening The service is running. paused for a scan A scan is running on the sensor. starting The service is starting. stopped The service is turned off or not selected. port in use Another program on the host already uses the port. blocked The service is listening, but the sensor's own test couldn't reach it. error Hover over the badge to see the detail. If the sensor reports a problem, it's shown at the top of the tab. Names and devices By default, the honeypots use the sensor's own host name, so anything that scans the sensor sees one consistent machine. You can change: Host name and Domain. These are the names shown in the mail server's greeting, the shell prompt, the Windows file server and domain, and the Elasticsearch node. SSH / Telnet looks like. The device the SSH and Telnet honeypot imitates…
OrbitalCyber documentation