Trapsters Enterprise

A Trapster is a dedicated honeypot node on your network. It is not a lightweight agent installed on an existing server. Each Trapster runs as its own VM or container with a real IP address, hostname, and MAC address on the network segment where you place it.

Trapsters have no legitimate business purpose. Anything that connects to them (a port scan, a login attempt, a breadcrumb credential replay) is suspicious by definition.

What a Trapster is at the network level

Property	Behavior
Identity	Appears as a standalone machine with its own IP, hostname, and network interface
Traffic	Listens on configured ports; never initiates outbound connections to your assets
Deployment	VM (Proxmox, VMware, Hyper-V, KVM) or container (Docker, Kubernetes)
Management	Connects outbound to your dashboard over HTTPS for config sync and event forwarding

On VM deployments, the Trapster gets a normal network presence: DHCP or static IP, DNS, gateway, and optional domain join for SMB. Docker deployments typically use host networking so the node can bind service ports directly.

Service emulation

When an attacker connects to an emulated service (SSH, SMB, HTTP, RDP, and others), Trapster presents a convincing protocol facade. The default behavior is:

1. Accept the connection and present a realistic banner or login prompt
2. Capture the interaction (source IP, username, password, client details)
3. Generate an incident for internal sources
4. Close the session without granting real access

The goal is a believable surface, not a fully functional production service. Trapster does not host real data or allow attackers into your network.

Emulation depth by protocol

Protocol	What the attacker sees	What Trapster captures
SSH	SSH banner and login prompt.	Every username/password attempt; optional interactive session
SMB	Fake Windows file share with configurable share name and NetBIOS identity	Connection attempts, usernames, passwords (including NTLM)
HTTP/HTTPS	Configurable login page skins (Apache, Fortigate, custom)	Connection, query, and credential attempts
RDP, FTP, LDAP, databases	Protocol-appropriate handshake and auth challenge	Credentials and source metadata

Some services go deeper than others. SSH can optionally simulate a full shell session (see SSH honeypot). SMB can join a real Active Directory domain for more realistic authentication. Most services stop at the authentication boundary: log the attempt, alert your team, and deny access.

See Detection Modules for per-protocol configuration.

Internal vs. external Trapsters

Trapster labels each device Internal or External automatically. You do not set this manually.

Use the Internal / External tabs on the Trapsters page to filter your fleet. The label reflects how the Trapster is being reached and how alerts are prioritized:

	Internal Trapster	External Trapster
Typical placement	User VLANs, server segments, near file servers	DMZ, cloud edge, internet-facing subnets
Incidents	Full incidents for connections, logins, breadcrumbs, and port scans	One Info-level "exposed to internet" incident when first hit from the public internet
Internet login attempts	N/A (sources are internal)	Logged and aggregated in statistics; not raised as individual incidents
Alert priority	Every internal hit is high-signal (lateral movement, credential reuse)	Internet background noise is de-prioritized so internal hits stand out

The Internal/External filter on the Trapsters page is a convenience view based on this automatic classification. The meaningful difference is alert fidelity: internal hits are treated as potential compromise signals; external hits are expected on internet-facing decoys and handled differently to reduce noise.

Deploying a Trapster

1. Open Trapsters in the sidebar
2. Click the + card to open Deploy a new Trapster
3. Choose your platform : VMware ESXi, Proxmox, Hyper-V, Azure, Docker, or Kubernetes

Hypervisor images (VMware, Proxmox, Hyper-V) download immediately when you click the platform. Docker and Kubernetes show an example configuration to copy. Azure opens in-wizard instructions for your tenant.

Platform guides:

• Deployment overview : full download table and process
• Proxmox
• VMware
• Hyper-V
• Docker
• Kubernetes
• Cloud (Azure)

After the node boots, it appears as a pending registration in your dashboard. Accept to add it to your fleet, or Reject if you do not recognize it.

Accepting and rejecting registration

Accept marks the Trapster as active, applies the default service template for its platform, and starts config sync.

Reject permanently sets the device to Denied. The node can no longer authenticate or send events. Rejecting is for dismissing an unknown pending registration, it is not a temporary snooze. To use the same hardware again, redeploy it (which creates a new device record).

Registration typically completes within a few minutes of first boot, provided the Trapster has outbound HTTPS access to <domain_id>.trapster.cloud on port 443.

License limits and device status

Your license counts active fleet slots: every Trapster whose status is not Denied or Deleted. That includes devices waiting in Pending until you accept or reject them.

Status	Counts toward license?	Effect
Pending	Yes	Waiting for you to accept or reject
Accepted (online/offline)	Yes	Normal fleet member
Denied (rejected registration)	No	Slot freed (you can register another Trapster)
Deleted (removed from dashboard)	No	Slot freed (incident history is kept)

Practical implications:

• Delete an accepted Trapster from Settings on the device page to archive it and free the slot. Past incidents remain on the Incidents page.
• If all slots are in use, new registrations fail until you reject, delete, or upgrade your license.
• A Denied record cannot be accepted later. Redeploy to obtain a fresh pending registration.

See Licensing for allocation and renewal.

Default service template on accept

When you accept a new Trapster, Trapster applies a starter template automatically. You can change it afterward from the Identity tab.

Platform at registration	Template applied	Port scan plugin
Docker, Kubernetes, or Podman	Debian Server	No
All other platforms (VM, cloud, physical, and so on)	Microsoft Windows Server 2022	Yes

Debian Server

• Identity: generic Linux
• Services: FTP (banner (vsFTPd 2.3.4)), SSH, HTTP (Apache skin default_apache)

Windows Server 2022

• Identity: Microsoft Windows Server 2022
• Services: FTP (Microsoft FTP Service), HTTP (IIS skin default_iis), SMB (Windows Server 2022), RDP (2022)

These defaults match what container and VM deployments typically expose on the network. Pick a different role from the template catalogue on the Identity tab. See Detection Modules.

Container vs VM templates

Container deployments receive the Linux template because port scan detection and some services are not available on containerized deployments. VM deployments get the full Windows 2022 profile including SMB and port scan detection.

Breadcrumbs and IP changes

Breadcrumbs are fake credentials or shortcuts placed on real machines. They embed the Trapster's IP address and port so that if someone uses the decoy, they connect to your honeypot.

When a breadcrumb is created, Trapster records the Trapster IP at that moment. If the Trapster's IP later changes (for example, after switching from DHCP to static, or a network reconfiguration), any active breadcrumb still pointing at the old IP will no longer reach the honeypot.

Trapster automatically marks those breadcrumbs as Stale and can send a digest email listing affected breadcrumbs. Regenerate and redeploy breadcrumbs after an IP change.

Multiple Trapsters: deployment pattern

There is no fixed minimum, but coverage improves with placement, not raw count. One Trapster alone is useful; multiple Trapsters on different segments give broader visibility.

Recommended pattern:

• One Trapster per network segment you want to monitor (VLAN, subnet, or cloud VPC)
• Place them where attackers look: user VLANs (lateral movement), near NAS/file servers (credential reuse), server VLANs (targeted attacks), DMZ (inbound attackers)
• Ensure each Trapster is reachable from the hosts on that segment

All Trapsters report to the same dashboard. Use namespaces to organize them if you manage multiple sites or teams.

Deployment constraints

Some services require a full VM and are not available on Docker or Kubernetes:

Feature	VM	Docker / Kubernetes
SMB service	Yes	No
Kerberos service	Yes	No
Port scan plugin	Yes	No
All other services	Yes	Yes

Plan your platform choice before deploying if you need these services.

Configuration reference

From a Trapster's detail page you can manage:

• Identity: hostname, workgroup or domain-joined mode
• Network: DHCP or static IP, DNS, gateway
• Services: enable and configure emulated protocols; generate breadcrumbs from a service row
• Settings: enable plugins (port scan, LLMNR) and whitelist IPs
• Breadcrumbs: view history and stale status for decoys tied to this Trapster

See Network Configuration for static IP setup on VM deployments.

Next steps

• Detection Modules: Configure emulated protocols
• Plugins: Port scan and LLMNR detection
• Breadcrumbs: Plant decoys on real machines
• Incidents: Triage alerts and use the Threat Graph
• Networking Requirements: Placement strategy and firewall rules