When the Honeypot Worked Perfectly and Still Failed the Team
A mid-sized financial services firm deployed a low-interaction SSH honeypot on an unused internal subnet in early 2024. Within 72 hours, it captured credential stuffing attempts, a port scan originating from a residential ISP block in Southeast Asia, and what appeared to be automated reconnaissance consistent with Kimsuky-affiliated tooling — the same North Korean threat group recently linked to PebbleDash-based intrusion campaigns targeting financial and government organizations. The honeypot logs were thorough. The problem was that nobody had built a pipeline to act on them. The data sat in a flat log file on a VM that only one analyst knew how to access, and that analyst was on leave.
This scenario repeats itself across organizations of every size. Honeypots are genuinely powerful tools for threat intelligence gathering, but the gap between deploying one and extracting operational value from it is wider than most teams anticipate. This article walks through what makes honeypots useful, what architectures work in practice, and how to build the surrounding processes that turn captured traffic into actionable intelligence rather than archived noise.
What a Honeypot Actually Does — and What It Cannot
A honeypot is a deliberately exposed system, service, or resource designed to attract unauthorized access. Its value comes from the fact that any interaction with it is inherently suspicious, because legitimate users have no reason to touch it. This gives defenders a near-zero false positive rate on the detections themselves, which is a significant advantage over signature-based detection tuned against production traffic.
Honeypots come in several forms, each with different intelligence yields:
- Low-interaction honeypots simulate services at the protocol level without running actual software. Tools like Honeyd, Cowrie (for SSH/Telnet), and Dionaea (for SMB, FTP, and HTTP) fall into this category. They are fast to deploy, low-risk, and good for capturing automated scanning and exploit attempts at scale.
- High-interaction honeypots run real operating systems and services inside controlled environments. They allow attackers to execute code, pivot, and reveal toolchains in detail. The intelligence yield is substantially higher, but so is the operational overhead and risk of containment failure.
- Honeytokens are not systems at all — they are fake credentials, documents, API keys, or database records embedded in real environments. When accessed or used, they trigger an alert. Given the recent spike in supply chain and credential-based attacks, honeytokens have become one of the most cost-effective early warning mechanisms available.
- Honeynets are networks of interconnected honeypots designed to simulate an entire environment, including routing, DNS, and application tiers. They are most useful for advanced persistent threat research and are typically operated by security vendors or academic institutions rather than enterprise defenders.
What honeypots cannot do is replace perimeter defenses, patch vulnerable systems, or detect threats that never interact with them. A threat actor performing passive reconnaissance against your external attack surface from a rented cloud IP will not trigger a honeypot unless you have placed one in a location they are likely to probe.
Threat Intelligence Honeypots Are Gathering Right Now
The current threat landscape makes honeypot deployment particularly relevant. Automated scanning infrastructure has grown dramatically, and groups across the sophistication spectrum are using it. When OceanLotus (APT32) was recently suspected of using PyPI to deliver the ZiChatBot malware, defenders with honeypot package repositories or fake developer credentials would have had early warning of the campaign's targeting patterns before public disclosure.
Similarly, the widespread exploitation of WordPress plugin vulnerabilities — including the recent Funnel Builder plugin bug used to steal payment card data — follows a predictable pattern: automated scanners identify exposed installations, then drop payloads or skim credentials. A honeypot WordPress instance with realistic but fake e-commerce data will attract these scans and reveal the specific exploit patterns and C2 infrastructure in use before they reach production sites.
Modern honeypots routinely capture the following intelligence categories:
- IP and ASN attribution data: Which address ranges are actively scanning, which hosting providers are being abused, and whether traffic originates from residential proxies, datacenter blocks, or TOR exit nodes.
- Credential lists: Brute force attempts reveal which username/password combinations attackers are cycling through, which is directly useful for auditing your own authentication systems for those exact combinations.
- Exploit signatures: Honeypots capture CVE exploitation attempts in real time, often days or weeks before public proof-of-concept code is widely circulated. This is especially relevant given the volume of Active Directory Certificate Services escalation techniques currently in circulation, which are being used to chain privilege escalation in Windows environments.
- Malware samples: High-interaction honeypots and purpose-built malware honeypots like MHN (Modern Honey Network) capture binaries dropped by automated payloads, enabling reverse engineering and indicator extraction.
- Lateral movement patterns: Internal honeypots placed on segments that legitimate users never access will detect post-compromise pivoting and reveal the tools and techniques attackers use once inside a network.
Deployment Architecture for Practical Environments
The most common deployment mistake is placing a single honeypot on the external DMZ and treating it as a passive sensor. Useful honeypot deployments are distributed across multiple trust zones and tuned to the threats most relevant to the organization's environment.
External Perimeter Honeypots
Deploy low-interaction honeypots on IP addresses in your allocated but unused ranges. SSH (port 22), RDP (port 3389), and SMB (port 445) are consistently among the most scanned services globally. Cowrie is the standard choice for SSH and Telnet emulation; it captures session keystrokes, logs attempted credentials, and can be configured to report to centralized collection infrastructure via syslog or direct API integration.
For web-based threat capture, a lightweight WordPress or Apache honeypot with realistic but inert content will attract automated exploit kits targeting CMS vulnerabilities. Configure these to log full HTTP request bodies, not just headers, because the payload often contains the C2 address, obfuscated shellcode, or the specific vulnerability string being tested.
Internal Network Honeypots
Internal honeypots carry a different purpose: detecting lateral movement after a perimeter breach. Place fake Windows hosts in Active Directory with names that suggest privileged access (backup-server, finance-db, it-admin-ws). These machines should appear legitimate in network discovery but should have no real services or data. Any connection attempt to them from an internal host is high-confidence evidence of post-compromise activity.
Given the current prevalence of AD CS escalation techniques being packaged into toolkits that automate certificate-based privilege escalation, a honeypot certificate authority or fake ADCS endpoint can surface these attacks at the reconnaissance phase before they succeed.
Honeytoken Deployment in Real Systems
Honeytokens scale to environments where full honeypot systems are impractical. The most effective implementations include:
- Fake AWS IAM credentials committed to internal code repositories, monitored via AWS CloudTrail for any usage attempt.
- Synthetic user accounts in Active Directory with realistic names but no legitimate login history. Alert on any successful or failed authentication.
- Decoy files named with high-value labels (payroll_2026.xlsx, customer_data_export.csv) placed in shared drives, with file access auditing enabled and alerts configured.
- Fake API keys embedded in configuration files stored in locations that attackers are likely to enumerate during credential harvesting.
The 0ktapus campaign that breached over 130 organizations demonstrated that attackers operating at scale use automated tooling to harvest and test credentials rapidly. Honeytokens seeded in realistic locations would have flagged the credential usage attempts within minutes of harvest, providing an early warning window that post-hoc log review does not.
Building the Collection and Analysis Pipeline
Raw honeypot logs have limited value without a structured pipeline to enrich, correlate, and surface actionable intelligence. The pipeline has four stages: collection, enrichment, correlation, and dissemination.
Collection
Centralize logs from all honeypot sensors into a dedicated collection tier. Avoid routing honeypot logs through the same SIEM pipelines used for production infrastructure, because honeypots generate large volumes of noisy, high-cardinality data that can consume parsing and storage resources. A dedicated Elasticsearch or OpenSearch cluster, or a separate workspace in your SIEM, keeps honeypot intelligence accessible without degrading production alerting performance.
Use structured logging from the start. Cowrie outputs JSON natively. For custom honeypots, build structured output into the logging layer rather than parsing unstructured text downstream. Fields that matter most: source IP, timestamp, destination port, protocol, payload excerpt, and session duration.
Enrichment
Every captured IP should be automatically enriched with ASN information, geolocation data, and reputation context from threat intelligence feeds. Enrichment should run at ingest time so that analysis can begin immediately without manual lookups. Note that geolocation data for cloud and proxy IPs is often inaccurate at the city level, so treat country-level attribution as directional rather than definitive.
Cross-reference captured credential pairs against your own password audit data. If attackers are actively testing a specific username format against your SSH honeypot, check whether that format exists in your real user directory. Cross-reference captured exploit strings against your vulnerability management system to identify whether the targeted CVE is present in your production environment.
Correlation
Honeypot intelligence becomes significantly more powerful when correlated with production security data. A source IP that probes your external honeypot and then appears in your web application firewall logs or authentication logs within the same session window is a high-confidence indicator of targeted reconnaissance. Build correlation rules that join honeypot source IPs with production log sources on a rolling 24 to 72 hour window.
Malware samples captured by high-interaction honeypots should feed into your threat hunting workflow. Extract file hashes, network indicators, and behavioral patterns, then run these against endpoint telemetry and network flow data. This is how honeypots transition from passive capture to active hunting enablement.
Dissemination
Intelligence that stays inside the security team has limited impact. Establish a lightweight process for sharing relevant indicators with adjacent teams: network operations, cloud infrastructure, and application security. For organizations participating in sector-specific information sharing programs (FS-ISAC, H-ISAC, etc.), high-confidence indicators from honeypot captures are shareable contributions that improve collective defense.
Format shared indicators in STIX/TAXII where possible for compatibility with downstream tools. For internal use, a weekly threat intelligence brief summarizing honeypot observations — top attacking ASNs, new credential patterns, exploit attempts by CVE — gives non-technical stakeholders visibility into the threat landscape without requiring raw log access.
Legal, Ethical, and Operational Constraints
Honeypot operators routinely underestimate the legal complexity of capturing attacker activity. The core issues are jurisdiction-specific but broadly consistent: you can legally capture data from systems you own and operate, but actively engaging attackers (hackback), intentionally enticing attacks beyond passive exposure, or retaining personally identifiable data captured from honeypots may create liability depending on your jurisdiction and sector.
Consult legal counsel before deploying high-interaction honeypots that allow attackers to execute code, because the stored binaries and captured credentials may have handling requirements. Some jurisdictions treat honeypot-captured malware samples as controlled materials requiring specific storage and destruction procedures.
Operationally, the primary risk with high-interaction honeypots is containment failure: an attacker escaping the honeypot environment and pivoting into adjacent production systems. Enforce hard network segmentation between honeypot infrastructure and production networks. Use separate physical hardware or dedicated cloud accounts where budget allows. Monitor outbound connections from honeypot hosts and block all non-logging traffic by default.
Measuring Whether Your Honeypot Program Is Actually Working
Teams that deploy honeypots without defined success metrics tend to either over-invest (treating every scan as a major incident) or under-utilize (reviewing logs only during audits). Useful metrics for a mature honeypot program include:
- Mean time to indicator: How quickly does a new exploit or credential pattern captured by the honeypot result in a detection rule, firewall update, or vulnerability remediation in production?
- Threat hunt yield: How many threat hunting investigations were initiated based on honeypot intelligence, and what percentage resulted in confirmed findings in production environments?
- Indicator sharing volume: How many indicators per month are being contributed to external sharing programs, and how many shared indicators from partners are being validated against honeypot data?
- Coverage gap identification: Which attack techniques captured by honeypots were not detected by existing production controls, and has that gap been remediated?
The Kimsuky group's current use of PebbleDash-based tools illustrates why the coverage gap metric matters. If your honeypot captures command-and-control behavior consistent with PebbleDash but your endpoint detection platform has no signature for it, that gap is measurable and actionable. Without the honeypot, the gap exists but is invisible.
Starting Small Without Starting Useless
Organizations with limited resources can build meaningful honeypot capability without significant infrastructure investment. A single Cowrie instance on a cloud VM costs roughly $5 to $15 per month to operate, captures thousands of attack sessions weekly, and provides immediate value for credential pattern analysis and IP reputation enrichment. The T-Pot platform bundles 20 plus honeypot sensors into a single deployable appliance image and is a practical starting point for teams that want breadth across multiple protocols without building each sensor individually.
The higher the interaction fidelity, the higher the operational cost and risk. Start with low-interaction deployments, build the collection and analysis pipeline, and demonstrate value to leadership with concrete examples before requesting budget for high-interaction infrastructure. A honeypot program that produces a monthly threat brief with actionable indicators is far more valuable than an elaborate high-interaction deployment whose logs nobody reads.
Honeypots work best as one layer in a defense-in-depth architecture, not as a standalone capability. Their intelligence should feed into threat hunting, detection engineering, vulnerability management, and external sharing simultaneously. When those connections are built and maintained, a honeypot program transforms from a passive sensor array into one of the most cost-effective sources of ground-truth threat intelligence available to enterprise defenders.
