The Deployment Logic Most Teams Use Is Backwards
The prevailing assumption in many security teams is that honeypots exist to catch attackers in the act — a kind of digital mousetrap that triggers an alert when someone steps on it. That framing is not wrong, but it severely underestimates what a well-designed honeypot deployment can do for your threat intelligence program. Teams that treat honeypots purely as detection tools end up with noisy alert queues and shallow data. Teams that treat them as intelligence collection systems end up with attacker behavior profiles, infrastructure maps, and tactical indicators that feed every other layer of their defenses.
The difference between those two outcomes is not the honeypot technology itself. It is the intent behind the deployment, the architecture around the collection pipeline, and the discipline applied to analyzing what gets captured. This article walks through how to build a honeypot deployment that actually serves a threat intelligence function, using real attacker behavior patterns that security teams are observing right now.
Why the Current Threat Landscape Makes This Urgent
Ransomware attacks have continued rising through 2024 and into 2025, with threat actors showing increasingly automated initial access behaviors. Researchers tracking these campaigns have documented widespread scanning activity targeting exposed RDP, SMB, and SSH services within hours of new vulnerabilities being announced. The pace of exploitation after the weaponization of flaws like the WinRAR vulnerability against Ukrainian organizations demonstrates that attackers are running industrialized scanning and exploitation pipelines, not manual reconnaissance.
Separately, the discovery of malware distribution ecosystems built on click hijacking, traffic distribution systems, and impersonation infrastructure shows that modern threat actors coordinate their operations across multiple stages. Understanding how those pipelines work, which infrastructure they use, and how they probe targets before launching full campaigns is exactly the kind of intelligence a properly operated honeypot can surface.
When Netherlands law enforcement seized 800 servers connected to cybercriminal infrastructure in 2025, investigators had visibility into how those servers were being used partly because defenders had been collecting connection data from deceptive infrastructure for months. That is threat intelligence informing real-world action.
Defining What Intelligence You Actually Need Before You Deploy Anything
Before standing up a single honeypot node, your team needs to answer a concrete question: what decisions will this intelligence inform? Vague goals produce vague results. The following are specific intelligence requirements that honeypots can realistically address.
- Initial access technique tracking: Which vulnerabilities or services are being actively exploited against your industry vertical right now, as opposed to what the last vendor report said six months ago?
- Attacker tooling identification: What malware families, exploit frameworks, or post-exploitation tools are threat actors dropping on newly compromised hosts in your sector?
- Command-and-control infrastructure mapping: What IP ranges and domains are being used for C2 callbacks from the malware that lands on your honeypot nodes?
- Credential harvesting patterns: Which username and password combinations are being tried against your fake authentication surfaces, and how do those relate to credential dumps circulating in criminal forums?
- Timing and automation signatures: How quickly after exposure does scanning begin, and what does the timing pattern tell you about whether you are dealing with automated scanning infrastructure versus targeted reconnaissance?
Picking two or three of these as primary objectives will shape every architectural decision that follows. A team trying to track attacker tooling will deploy differently than a team trying to map C2 infrastructure.
Architecture Choices That Determine Intelligence Quality
Honeypot architecture is where many deployments go wrong. The instinct is to deploy something quick, point some logs at a SIEM, and move on. That produces shallow data with limited analytical value. The architecture decisions below have a direct impact on the quality of intelligence you can extract.
Placement and Network Segmentation
Honeypots placed exclusively inside your perimeter catch internal lateral movement but miss the enormous volume of external scanning activity that reveals which vulnerabilities attackers are actively weaponizing. A combination of internet-facing low-interaction honeypots and internal medium-interaction systems gives you visibility at both stages of the attack lifecycle.
Internet-facing nodes should sit in a dedicated network segment with no route to any production infrastructure. The routing rules for this segment are not optional — any path from a honeypot to production systems creates a pivot opportunity for sophisticated attackers who recognize they have landed on a decoy and decide to use it anyway. Use a dedicated out-of-band management interface for your honeypot infrastructure so that management traffic never traverses the same segment as capture traffic.
Interaction Level Selection
Low-interaction honeypots emulate services without providing a real operating environment. They are easy to scale, safe to operate, and excellent for volume collection of scanning data, initial exploitation attempts, and credential stuffing patterns. Tools like Cowrie for SSH/Telnet, Dionaea for malware capture, and Glutton for PHP-based web application emulation give you deployable surfaces that require minimal maintenance.
Medium and high-interaction honeypots give attackers a more realistic environment to operate in, which produces richer behavioral data. When an attacker gets a responsive shell, you learn what commands they run first, what they look for, what tools they pull down, and what staging infrastructure they use. The operational cost and risk are higher, but for a threat intelligence team trying to profile specific threat actor groups, that depth is worth it.
The choice between interaction levels should follow your intelligence requirements. If you are tracking ransomware initial access patterns at scale, low-interaction nodes deployed across multiple cloud regions will produce more statistically meaningful data than a single high-interaction system. If you are trying to attribute a specific campaign targeting your organization, a higher-interaction deployment that captures complete attacker sessions is more valuable.
Cloud-Based Honeypot Nodes
Deploying honeypots across multiple cloud providers and regions gives you geographic distribution that reflects where attackers are scanning from relative to different network origins. A node in AWS us-east-1 will see different scanning patterns than one in a European region or an Asia-Pacific zone. Cross-referencing what each node sees gives you a richer picture of campaign scope and attacker infrastructure distribution.
Be aware of the risk highlighted in recent research around cloud logging abuse. Attackers who recognize they are in a monitored environment have been observed attempting to blind logging pipelines by abusing or exhausting cloud-native logging services. Your collection pipeline should not rely solely on cloud-native logging. Run local capture at the honeypot node level and ship logs to an independent collection point that the honeypot's cloud environment cannot access or modify.
Building the Collection Pipeline
A honeypot with poor data collection is an expensive distraction. The collection pipeline needs to capture enough context to make the raw interaction data analytically useful.
What to Capture
At minimum, every honeypot interaction should produce the following fields: source IP and port, destination port and service, timestamp with millisecond precision, full session transcript where applicable, any files or payloads delivered, and any outbound connection attempts made by the attacker after initial access. That last item is particularly important for C2 infrastructure mapping.
For web-based honeypots, capture the full HTTP request including headers, user-agent strings, and request bodies. User-agent strings in automated scanning traffic often contain identifiable signatures from specific exploit frameworks or scanning tools. These signatures correlate with tool sets observed in other campaigns and can help you track specific threat actor infrastructure over time.
Enrichment at Ingestion Time
Raw honeypot data without enrichment produces a list of IP addresses and payloads. Enrichment at ingestion time transforms that into intelligence. For every source IP that interacts with your honeypots, your pipeline should automatically add ASN and hosting provider data, geolocation at the city level, existing reputation data from threat intelligence feeds, prior interaction history from your own honeypot network, and WHOIS registration data for the source ASN.
This enrichment should happen at ingestion, not at analysis time. Analysts reviewing data days later should be looking at pre-enriched records, not running manual lookups on every interesting IP. The operational efficiency difference is significant, particularly during high-volume campaigns where hundreds of unique sources may interact with your honeypots in a single day.
Correlating Honeypot Data With Production Telemetry
The most actionable intelligence comes from correlating what your honeypots see with what your production environment sees. If an IP that interacted with your honeypot yesterday shows up in your production firewall logs today, that correlation changes the priority of both data points. Your SIEM or threat intelligence platform should be configured to run this correlation automatically and flag any matches for immediate analyst review.
This correlation workflow is particularly valuable for catching the pre-attack reconnaissance phase of ransomware campaigns. Groups running industrialized ransomware operations typically scan broadly before selecting high-value targets. Your honeypots will see their scanning infrastructure before your production systems do. If you can identify those IPs and block them proactively, you may interrupt the targeting process before it reaches your real assets.
Practical Honeypot Profiles for Common Threat Intelligence Goals
Tracking Ransomware Initial Access
Deploy low-interaction honeypots emulating RDP (port 3389), SMB (port 445), and exposed VPN interfaces. Log every connection attempt with full credential data. Within 24 to 72 hours on a public IP range, you will begin seeing credential stuffing activity. The username and password combinations being tried reflect what is circulating in current credential markets and what groups with specific targeting profiles prefer to try first.
Correlate the credential patterns against known breach data. When attackers try credentials that appeared in a specific data breach, you have a signal about which breach data is currently being operationalized. That information is immediately useful for your own user account risk prioritization.
Capturing Malware Samples for Analysis
Dionaea and similar malware-capturing honeypots emulate vulnerable services and collect any exploit payloads or malware dropped by attackers. Run these alongside a sandboxed analysis environment so that every captured sample is automatically detonated and analyzed. The behavioral analysis from those detonations produces indicators of compromise that you can push directly into your production detection stack.
Given the active exploitation of flaws like the WinRAR vulnerability observed in recent campaigns, maintaining a web-facing honeypot that emulates file processing endpoints can yield samples of malicious archives being used in active campaigns. Attackers reuse delivery infrastructure, and capturing samples early gives your team time to build detections before those samples reach your production users.
Mapping Active C2 Infrastructure
When malware executes on a higher-interaction honeypot, it will attempt to call back to its command-and-control infrastructure. Capturing those outbound connection attempts gives you C2 IP addresses and domains that are active right now, not six months ago when a threat report was published. Submit these indicators to your threat intelligence platform and check them against your production DNS query logs and proxy logs immediately.
The malware distribution ecosystems built around traffic distribution systems and impersonation infrastructure documented in recent research typically use C2 infrastructure that rotates frequently. Honeypot captures give you the current rotation rather than historical data, which is the difference between a useful indicator and a stale one.
Operational Security for Your Honeypot Program
Sophisticated attackers, particularly nation-state groups and established ransomware affiliates, fingerprint honeypot environments. If your decoy is obvious, what you capture reflects behavior calibrated to a known honeypot rather than genuine attacker tradecraft. This matters more for high-interaction deployments than low-interaction ones, but the principle applies across all tiers.
Make your honeypots look like realistic systems. Give them plausible hostnames, realistic service banners, and some simulated activity in their logs. An SSH honeypot that has never had a successful login in its history does not look like a real server. A web application honeypot with no existing content and a default configuration looks exactly like what it is. Invest in making the environment believable, particularly for the services that sophisticated attackers will probe after initial access to determine whether they are in a real environment.
Rotate your honeypot IP addresses periodically but not on a predictable schedule. Attackers who catalog and track honeypot infrastructure will avoid known decoy IPs, skewing your collection sample toward less sophisticated actors. Regular rotation, combined with deploying on new IP ranges from diverse providers, helps maintain a realistic collection sample.
Turning Collected Intelligence Into Team Action
Intelligence that sits in a database and never reaches the people who can act on it has zero operational value. The final and most commonly neglected part of a honeypot program is the dissemination and action workflow.
Define intelligence products at the start of your program. A daily digest of new credential combinations observed across your honeypot network, formatted for your identity team, is a concrete intelligence product. A weekly report on new malware families captured and analyzed, with detection rules attached, is a concrete intelligence product. A real-time feed of C2 indicators formatted for your firewall and proxy blocking pipeline is a concrete intelligence product.
Each intelligence product should have a named owner, a defined consumer, and a feedback loop. The consumer should be telling the owner whether the intelligence is actionable, accurate, and arriving at a useful cadence. Without that feedback loop, intelligence products drift away from what is actually useful and toward what is easiest to produce.
For ransomware defense specifically, your honeypot intelligence should feed directly into your vulnerability prioritization process. If your internet-facing RDP honeypots are seeing active exploitation attempts against a specific vulnerability, that vulnerability moves to the top of your patching queue regardless of where it sits on your standard risk scoring model. Real-world exploitation data from your own collection network is more accurate for your specific exposure than any published CVSS score.
Measuring Whether Your Program Is Working
Honeypot programs are difficult to measure by traditional security metrics because preventing an attack that was never attempted is not a visible outcome. The metrics that actually reflect program health are different from standard security KPIs.
- Intelligence lead time: How many hours or days before an observed attack campaign did your honeypots first see activity from the same infrastructure?
- Indicator activation rate: What percentage of IPs and domains extracted from honeypot captures subsequently appeared in your production telemetry?
- Sample-to-detection time: How long does it take from capturing a new malware sample on a honeypot to having a detection rule in production?
- Credential overlap rate: What percentage of credentials observed in honeypot capture sessions match active credentials in your identity environment?
These metrics tell you whether your program is generating intelligence that connects to real risk. A high indicator activation rate means your honeypots are seeing the same actors targeting your production environment, which validates their placement and configuration. A low credential overlap rate means either your credential hygiene is strong or your honeypots are not attracting the threat actors relevant to your environment.
Starting Small and Scaling With Purpose
A program that starts with two well-placed, well-instrumented honeypots and a clear collection and analysis workflow will outperform a program with twenty honeypots and no analytical discipline. Start with the services most relevant to your threat model. For most organizations in 2025, that means internet-facing SSH, RDP, and a web application honeypot targeting whatever framework your production applications use.
Run the program for 30 days before expanding. At the end of that period, review what you captured, whether the intelligence was actionable, and what gaps exist. That review will tell you where to expand next, whether that means additional geographic distribution, higher-interaction deployments for specific services, or better enrichment in your collection pipeline.
The goal is not to build the most comprehensive honeypot network possible. The goal is to maintain a persistent, low-cost collection capability that continuously feeds your threat intelligence program with current, relevant data about how attackers are operating against targets like yours. Done with that discipline, honeypots stop being an interesting experiment and become a practical intelligence asset your team actually relies on.
