When the Honeypot Caught Something Nobody Expected
A mid-sized financial services firm deployed a low-interaction honeypot on their internal network segment in 2023 as a quick project after a security audit flagged gaps in detection coverage. The honeypot sat quietly for eleven days. Then it caught a lateral movement attempt originating from a compromised workstation that had passed every perimeter control cleanly. The workstation belonged to a finance team member whose credentials had been harvested weeks earlier through a credential stuffing campaign. The honeypot generated the only alert that mattered. Everything else in the detection stack had produced nothing actionable.
That outcome was accidental. The team had no formal process for analyzing what the honeypot captured, no integration with their SIEM, and no playbook for following up on honeypot alerts. They got lucky. The attacker probed a fake file share the honeypot was mimicking, and a junior analyst happened to be reviewing the dashboard that morning. The intelligence gathered from that interaction was largely lost because nobody had built the workflow to capture and act on it.
This article is about building honeypot programs that produce structured, actionable threat intelligence on purpose rather than by chance. The difference between a honeypot experiment and a honeypot program is the operational scaffolding around it.
What Honeypots Actually Produce When Deployed Correctly
A honeypot is fundamentally a detection and collection asset. Any traffic reaching it is suspicious by definition because there is no legitimate reason to interact with a system that serves no production function. That signal clarity is the primary value proposition. Unlike IDS rules that must distinguish between legitimate and malicious traffic in production systems, honeypots operate in an environment where the noise floor is essentially zero.
The types of intelligence honeypots generate fall into several categories that are directly useful for defenders:
- Attacker tooling fingerprints: Command sequences, exploit payloads, and scanning tool signatures that reveal what tools adversaries are carrying and how they operate.
- Infrastructure indicators: Source IP addresses, ASNs, and behavioral patterns that can enrich threat feeds or validate existing blocklists.
- Credential testing patterns: Usernames and passwords attempted against exposed services, which reveal what credential lists attackers are using and which services they prioritize.
- Timing and campaign data: Attack timing, dwell patterns, and scanning frequency that help characterize whether activity is automated, manual, or a hybrid of both.
- Lateral movement indicators: When internal honeypots catch post-compromise behavior, they reveal attacker tradecraft that would otherwise be invisible until significant damage had occurred.
The intelligence value depends heavily on what type of honeypot is deployed and where it sits in the network. Perimeter-facing honeypots produce a high volume of internet-background-noise activity. Internal honeypots produce low-volume, high-confidence signals. Both have legitimate roles, but they answer different questions.
Selecting the Right Honeypot Architecture for Your Environment
The honeypot landscape ranges from purpose-built research platforms to quick-deploy open source tools. Choosing the wrong type for your goals creates a program that produces either overwhelming noise or no signal at all.
Low-Interaction Honeypots
Low-interaction honeypots emulate services without running actual vulnerable software. Tools like Cowrie (SSH/Telnet emulator), Dionaea (malware capture), and OpenCanary (multi-service emulator) fall into this category. They are lightweight, safe to deploy, and relatively easy to manage. The tradeoff is fidelity. Sophisticated attackers who probe deeply will recognize the emulation. For capturing automated scanning activity, credential spray campaigns, and initial access attempts, they are highly effective. They produce structured logs that integrate cleanly into SIEM platforms.
The VBScript campaign currently being distributed through WhatsApp to deploy RMM software is a good example of the kind of automated, opportunistic activity that low-interaction honeypots catch well. The initial delivery mechanism varies, but the follow-on behavior, attempting to establish persistence and pull down remote management tooling, produces distinctive command sequences that honeypot logs can capture if the honeypot mimics a plausible Windows host.
High-Interaction Honeypots
High-interaction honeypots run real operating systems and real services, either as physical machines or as carefully isolated virtual machines. Attackers can fully compromise them, which means you capture complete attacker behavior including post-exploitation tooling, command-and-control communication, and lateral movement attempts. The intelligence value is significantly higher. The risk is also significantly higher. Containment failures can result in the honeypot becoming a platform for attacking other systems or other organizations. High-interaction honeypots require dedicated network isolation, continuous monitoring, and staff who understand how to safely analyze live attacker sessions without disrupting the collection.
Deception Technology Platforms
Commercial deception platforms like Attivo (now part of SentinelOne), Illusive Networks, and Deception Grid extend honeypot concepts into enterprise environments with management interfaces, automatic decoy generation, and SIEM integration built in. They scatter fake credentials, fake network shares, and fake endpoints throughout the production environment. Any interaction with a decoy generates an alert. These platforms are expensive but dramatically reduce the operational burden of running a deception program at scale. For organizations protecting OT environments, which face the specific challenge of legacy systems that cannot be patched or easily monitored, deploying decoy PLCs or fake engineering workstations alongside real ones creates detection capability where none existed before.
Placement Strategy and What Each Position Reveals
Where you put honeypots determines what questions they can answer. Treating placement as an afterthought produces a program that generates alerts without context.
Internet-Facing Honeypots
Honeypots exposed directly to the internet function as threat feed generators. They collect mass scanning activity, exploitation attempts against common vulnerabilities, and credential stuffing campaigns at scale. The FortiBleed campaign that exposed credentials for over 73,000 FortiGate systems involved attackers actively scanning for FortiGate devices with specific configuration weaknesses. An internet-facing honeypot configured to mimic a FortiGate management interface would have caught that scanning activity and provided early warning of the campaign before organizational assets were targeted. The value here is campaign awareness and attacker tool fingerprinting rather than internal threat detection.
Running internet-facing honeypots requires careful network segmentation. They belong in a dedicated VLAN or cloud environment with no routing paths back to production infrastructure. Outbound connectivity should be restricted to logging destinations only.
DMZ and Perimeter Honeypots
Honeypots placed in DMZ segments alongside legitimate externally accessible services catch attackers who have achieved initial access to those segments. They are particularly effective at catching automated post-exploitation frameworks that sweep DMZ ranges looking for additional targets after compromising one service. Place these to mimic the types of systems you actually run in the DMZ so that automated tools do not immediately identify them as out-of-place anomalies.
Internal Network Honeypots
Internal honeypots produce the highest-confidence alerts in the entire detection stack. Any system that reaches an internal honeypot has either bypassed perimeter controls or represents an insider threat. These honeypots should mimic high-value assets: domain controllers, file servers, database servers, and backup systems. Make them look real. Populate them with fake but plausible content. A honeypot file share with realistic-looking filenames and a reasonable directory structure is far more likely to attract attacker attention than an obviously empty share.
For organizations running OT environments, internal honeypots that mimic PLCs, HMIs, or historian servers are especially valuable. Modern threat actors targeting industrial systems, as the ongoing coverage of legacy OT security risks makes clear, use protocols like Modbus, DNP3, and EtherNet/IP during reconnaissance. A honeypot that responds to those protocol queries provides immediate detection capability for attacks that most IT security tools are not equipped to catch.
Cloud Environment Honeypots
Cloud honeypots deserve specific mention given current threat patterns. Attackers compromising cloud credentials through supply chain attacks, which the emerging AI supply chain threat landscape illustrates well, often move laterally through cloud environments by querying metadata services, enumerating S3 buckets, or attempting to access EC2 instances. Deploying honeypot EC2 instances, honeypot S3 buckets with plausible names like company-backup-2024 or internal-credentials, and honeypot IAM roles creates a detection layer inside cloud environments where traditional network monitoring has limited visibility. AWS GuardDuty can be configured to generate high-priority alerts when honeypot resources are accessed, and this approach integrates with existing cloud security tooling without significant additional infrastructure.
Building the Intelligence Pipeline Around Honeypot Data
The honeypot itself is the collection mechanism. The intelligence program is everything that happens afterward. Most teams that deploy honeypots without a surrounding pipeline end up with log files they review irregularly and indicators they never operationalize.
Structured Logging and SIEM Integration
Every honeypot interaction should produce structured log output, ideally in JSON, that feeds directly into your SIEM. Configure the SIEM to treat honeypot alerts as high-priority events requiring human review within a defined SLA. For internal honeypots, that SLA should be short. An attacker interacting with an internal honeypot is already inside your network. The detection value evaporates if the alert sits in a queue for four hours.
Cowrie, one of the most widely deployed open-source honeypots, outputs structured JSON logs that include session IDs, source IP addresses, all commands executed, credentials attempted, and files downloaded. Parsing this output and forwarding it to a SIEM like Splunk or Elastic takes about an hour to configure correctly. The investment is minimal relative to the detection improvement.
Indicator Extraction and Enrichment
Every honeypot session produces potential indicators of compromise. Automated extraction pipelines should pull IP addresses, domains contacted, file hashes, user-agent strings, and credential pairs from honeypot logs and feed them into your threat intelligence platform. Enrich these indicators against existing reputation data immediately. An IP address that your honeypot has never seen before but that resolves to a known malicious ASN or that appears on multiple threat feeds warrants different handling than a completely unknown IP.
Credential pairs harvested from honeypot SSH or RDP interactions are particularly useful. They reveal what password lists attackers are using in active campaigns. Cross-referencing these against your actual user accounts (safely, through hash comparison without exposing real credentials) tells you whether your users have passwords that appear in attacker wordlists. This is actionable remediation intelligence that most organizations do not extract from honeypot data.
Campaign Correlation
Individual honeypot interactions have limited intelligence value. Patterns across multiple interactions reveal campaigns. Configure your SIEM or threat intelligence platform to cluster honeypot interactions by attacker infrastructure, tool fingerprint, and timing. A series of SSH brute force attempts using the same wordlist from different IP addresses across the same /24 subnet, occurring in the same two-hour window, represents a coordinated campaign rather than random background noise. That correlation is worth investigating and may correspond to a campaign already documented in public threat intelligence.
The threat intelligence report landscape, including regular publications like the weekly roundups from threat intelligence vendors, frequently references scanning campaigns targeting specific services. Comparing your honeypot data against these public reports validates your collection and sometimes reveals that you are catching activity that threat intelligence vendors have not yet documented, which is genuinely useful intelligence your team can contribute back to the community.
Operational Considerations That Programs Often Skip
Legal and Policy Review
Before deploying any honeypot that actively engages with attackers, review your legal position. In most jurisdictions, passively collecting interaction data from systems you own is clearly lawful. Active engagement, sending attacker traffic to controlled sinkhole environments, running attacker-provided code in sandboxes for analysis purposes, or honey-potting in ways that involve your network actively communicating with third-party systems, requires legal review. The line varies by jurisdiction and organizational context. Cloud environments add another layer: some cloud providers restrict certain honeypot techniques in their acceptable use policies. Review these before deployment.
Preventing Honeypots from Becoming Attack Platforms
A poorly secured honeypot creates risk. High-interaction honeypots that are fully compromised can be used to attack other systems, including systems outside your organization. This is particularly serious in cloud environments where outbound connectivity is easy to establish. Implement egress filtering that blocks outbound connections from honeypot systems to anything except your logging infrastructure. Monitor outbound traffic from honeypots as carefully as you monitor inbound. If you see outbound connections to unfamiliar destinations, the honeypot may have been turned into a relay.
For honeypots designed to capture malware samples, use dedicated analysis infrastructure that is fully isolated. The pickle deserialization vulnerabilities and cross-tenant execution risks that have been demonstrated in AI model serving platforms are a good reminder that seemingly safe data can execute in unexpected contexts. Malware captured by honeypots should be handled with equivalent caution.
Avoiding Detection by Sophisticated Attackers
Skilled attackers check for honeypot indicators before proceeding. Common detection techniques include checking for virtualization artifacts, verifying that system binaries have realistic timestamps and file sizes, looking for expected user home directory contents, and probing network behavior that differs from real operating systems. Low-interaction honeypots that emulate SSH will fail these checks if an attacker runs them. For catching opportunistic and automated attackers, this rarely matters. For catching targeted attackers, high-fidelity deception requires genuine effort in honeypot hardening.
One practical approach is deploying real decommissioned hardware as internal honeypots with actual operating systems, realistic user profiles, and populated home directories. These systems look real because they largely are real. Remove production data and credentials, then populate with fake but plausible content. This approach is more labor-intensive but produces higher-fidelity deception than software emulation.
Staff Training and Playbook Development
Honeypot alerts require different handling than IDS alerts. When an internal honeypot fires, the default assumption should be active compromise. The response playbook for internal honeypot alerts should include immediate isolation of the network segment the attacker reached from, identification of the path through which the attacker reached the honeypot, and forensic investigation of all systems in the vicinity. Teams that receive honeypot alerts without a defined response playbook waste time deciding what to do while the attacker continues operating.
Integrating Honeypot Intelligence with Broader Security Operations
Honeypot data should feed into threat hunting workflows, not just alert queues. Indicators extracted from honeypot interactions should be used to run retroactive searches across production logs. If your honeypot captures an SSH brute force tool leaving a distinctive banner on port 22, search your SSH logs for connections that produced that banner on production systems. This turns honeypot intelligence into active threat hunting across your environment rather than passive detection at a single sensor.
For organizations participating in information sharing communities such as ISACs or using platforms like MISP, honeypot-derived indicators are valuable contributions. Sharing observed campaign infrastructure, credential lists, and tool signatures helps other defenders and builds the collective intelligence picture. This is particularly valuable when your honeypots are catching activity that aligns with emerging campaigns, such as purchase scam operations targeting large events, where early indicator sharing provides maximum defensive benefit to the community.
Treat honeypot data as one input into a threat intelligence cycle rather than a standalone detection mechanism. Combine it with threat feeds, vulnerability scan data, SIEM correlations, and analyst assessments. A honeypot interaction that aligns with a known threat actor's TTPs from public reporting, confirmed by infrastructure overlap and tool fingerprinting, is a significantly more confident attribution than any single data source alone.
Measuring Whether the Program Is Working
Honeypot programs without metrics drift. Teams lose enthusiasm for maintaining systems that appear to produce nothing actionable, and the program quietly dies. Define success metrics before deployment and review them quarterly.
Useful metrics include: number of unique campaigns detected per quarter, time between honeypot alert and analyst response, number of indicators operationalized into production controls, number of production threats identified through retroactive hunting triggered by honeypot data, and coverage of critical internal network segments by at least one honeypot sensor.
The last metric is particularly important. Internal honeypot coverage should map to your network segmentation. Every segment containing high-value assets should have at least one honeypot. Segments without honeypot coverage are blind spots that attackers who have done network reconnaissance will recognize and exploit. Regular coverage reviews prevent those blind spots from persisting unnoticed.
Starting Practical and Expanding Deliberately
The correct approach for most organizations is to start with a small, well-instrumented deployment rather than attempting to build comprehensive deception infrastructure immediately. Deploy two or three internal honeypots mimicking your most common high-value asset types, connect them to your SIEM with proper alerting, write a basic response playbook, and operate them for ninety days. Review what you collected, identify gaps in the intelligence pipeline, and expand based on what you learned.
OpenCanary is a practical starting point for organizations without dedicated deception tooling. It runs on Python, emulates multiple services including SSH, FTP, HTTP, MySQL, and SMB, generates structured logs, and requires minimal maintenance. Deploying it on a Raspberry Pi or a low-spec virtual machine on each internal VLAN gives you broad internal honeypot coverage at minimal cost. The alerts it generates will not be sophisticated, but they will be accurate. Any alert from an internal honeypot is worth investigating.
From that foundation, teams can evaluate whether commercial deception platforms provide enough additional value to justify the investment, whether high-interaction honeypots make sense for specific research goals, and whether cloud honeypot deployments should be added to cover gaps in cloud visibility. The program grows based on demonstrated value rather than theoretical capability, which is the model that produces sustainable security programs rather than impressive-looking deployments that nobody maintains.
