Deploying a honeypot in your company: the complete guide
Where to place your honeypots, which services to simulate, how to route alerts to the SOC. A practical deployment guide, from first decoy to full coverage.
A badly deployed honeypot detects nothing: dropped into a segment nobody visits, with a generic banner and alerts landing in a dead mailbox, it mostly provides a false sense of security. Conversely, a well-planned deployment turns a few lightweight VMs into a very low-noise intrusion detection system. Here is the method we apply, step by step.
Step 1: map the attack paths
Before placing a single decoy, think like an attacker: once a first workstation is compromised, where would they go? The zones to cover first:
- The server VLAN: the final destination of most intrusions.
- User VLANs: where lateral movement begins.
- The DMZ: to spot a pivot from an exposed service.
- Cloud environments (VPC, VNet): east-west movement is often less monitored there.
- Administration segments: bastions, hypervisors, backups; the most critical targets.
The practical rule: at least one decoy per segment an attacker could transit through. Coverage beats the sophistication of any single lure.
Step 2: choose credible personas
A honeypot must look like what an attacker expects to find in that segment:
- In the office VLAN: a fake file server (SMB) or a network printer.
- Next to business applications: a fake database, MySQL or MSSQL.
- In the IT segment: a fake admin appliance (a firewall- or NAS-style web interface).
- In the DMZ: a web or SSH service consistent with your actual usage.
Realism lives in the details: a hostname matching your internal convention (SRV-FILE-04 rather than honeypot-01), plausible service versions, consistent banners, accounts and shares named like yours. We covered the fingerprinting techniques attackers use in a dedicated article; the short version is that a generic decoy gets spotted within minutes by an experienced operator.
Step 3: plant breadcrumbs
A honeypot must be found. Rather than waiting for a scan to stumble upon it, guide the discovery with breadcrumbs: fake clues planted on real systems.
- Credentials saved in connection managers (RDP, PuTTY).
- Shell-history entries pointing to the decoy.
- Network shares referenced in scripts or GPOs.
- Honeytokens: fake API keys, fake password files, trapped documents.
An attacker who steals credentials from a compromised workstation and replays them against the decoy triggers an alert that tells you which machine was compromised and which credentials leaked.
Step 4: route alerts where people actually read them
A honeypot alert is almost always actionable: there is no legitimate traffic on a decoy. It deserves priority treatment:
- SIEM as the first choice (Syslog, CEF or JSON depending on your stack: Splunk, Sentinel, QRadar, Elastic...), with a dedicated high-severity correlation rule.
- Webhook to your on-call tool or a monitored Slack/Teams channel.
- Email as a safety net, never as the only channel.
Prepare a short runbook: who investigates, which sources to cross-check (EDR on the source host, AD logs), and when to isolate the machine behind the interaction.
Step 5: filter legitimate noise
The only legitimate interactions with a honeypot come from your own tools: vulnerability scanners, inventory solutions, monitoring probes. Allowlist their addresses on day one; it is the only structural "false positive" in deception, and it takes five minutes to handle.
Step 6: test the whole chain
A detection system that has never been tested does not exist. Validate the chain end to end:
- Run an nmap scan from an internal workstation: the alert must reach the SIEM within seconds.
- Attempt an SSH or SMB login on the decoy with fake credentials.
- Use a honeytoken (open the trapped document, replay the fake API key).
- Leverage your next pentest or red team exercise: if the auditors cross the network without touching a single decoy, your placement needs rework.
Step 7: maintain over time
Deception is a process, not an installation:
- Revisit placement whenever the network evolves (new segment, new application, cloud migration).
- Update simulated banners and versions to track your real estate.
- Rotate honeytokens periodically and check that breadcrumbs are still in place.
- Measure: alert count, reaction time, segment coverage. The dwell time you avoid is your real success metric.
How long does deployment take?
With a dedicated platform, the first decoy is live within minutes: Trapster ships ready-to-run VMs, preconfigured personas and native SIEM integrations, and centralizes honeypots and honeytokens in a single dashboard. Starting from open-source tools, expect a few days to reach the same level of integration; our comparison of open-source honeypots will help you pick a starting point.
Want to see a full deployment under real conditions? Book a 30-minute demo with our team.