I Mass-Deployed Honeypots on IPv6 and the Results Were Disturbing

The honeypots went live on a Tuesday. By Friday, three of them had already been found.

That sentence still surprises me when I read it back. The conventional wisdom, repeated in sysadmin forums and IPv6 adoption guides and vendor whitepapers, is that IPv6's address space is so astronomically large that attackers can't find your hosts unless you advertise them. The space is 2^128 addresses. Scanning it randomly is computationally absurd. You're safe in the noise.

Except you're not. Not anymore. Probably not for a while now, if we're being honest about when the threat model actually shifted versus when the documentation caught up.

This post documents a 30-day honeypot experiment I ran across multiple cloud providers using pure IPv6-only endpoints. No dual-stack. No IPv4 fallback. Just raw IPv6 addresses sitting in announced prefixes, logging everything that touched them. The results were unsettling enough that I think anyone running IPv6 infrastructure deserves a detailed account of what's actually happening out there.

The Myth That IPv6 Makes You Invisible

Where the 'Security Through Obscurity' Idea Came From

The math is genuinely impressive. IPv4 gives you about 4.3 billion addresses. IPv6 gives you 340 undecillion. To put that in terms that mean something: if you could scan one million IPv6 addresses per second, scanning the entire space would take longer than the current age of the universe. That's not hyperbole. That's arithmetic.

When IPv6 adoption began accelerating through the 2010s, this fact got embedded into guidance documents, training materials, and general sysadmin culture as a security property. The reasoning felt solid: what a scanner can't enumerate, a scanner can't attack. Internet-wide IPv4 scans with tools like Masscan complete in under an hour. IPv6 seemed immune to that class of threat by sheer geometric scale.

The kernel of truth here is real. Naive random scanning of the IPv6 space is still impractical. Nobody is brute-forcing 2^128 addresses. That part of the conventional wisdom remains accurate.

Why Sysadmins Still Believe It

The belief persists for a simple reason: it was true when it was written, and nobody updated the mental model when the attack surface changed. Most IPv6 security guidance was authored during a period when hitlist-based scanning was nascent and the passive data sources that feed it were sparse. That guidance got copied, cited, and repeated until it became received wisdom.

The threat model has quietly shifted while the assumption hasn't. Attackers aren't scanning the space. They're harvesting it from sources that already did the discovery work for them. That's a fundamentally different attack vector, and it renders the "too many addresses to find" argument largely irrelevant for any host that has ever appeared in a DNS record, a TLS certificate, a BGP announcement, or a passive measurement dataset.

What Hitlist-Based IPv6 Scanning Actually Is

How Attackers Build IPv6 Target Lists Without Brute Force

Hitlist scanning doesn't try to find IPv6 addresses by guessing. It curates them. The distinction matters enormously, because the curation sources are passive, persistent, and constantly growing.

The concept is straightforward: rather than generating random addresses and hoping some are live, you collect addresses that have already revealed themselves through normal internet activity. Every time a host resolves a DNS AAAA record, appears in an NTP pool, gets indexed by a certificate transparency log, or originates BGP routes, it leaves a fingerprint in a dataset that someone, somewhere, is collecting.

"The IPv6 address space is vast, but the populated portion of it is surprisingly discoverable. The challenge for researchers and attackers alike is not finding addresses; it is keeping up with how fast the lists grow.". TU Munich IPv6 Measurement Group, 2025

The TU Munich research group published findings showing that their IPv6 hitlist, drawn from passive sources, contains tens of millions of responsive addresses and grows at a rate that tracks IPv6 adoption curves globally. This isn't a boutique research artifact. It's a structured, maintained dataset that reflects real deployment activity.

Censys data tells a similar story. The number of indexed IPv6 hosts grows year-over-year as more providers enable IPv6 by default and more deployments skip IPv4 entirely. Once Censys crawls your host, that address is in a corpus that researchers, security teams, and threat actors all have access to.

The Role of DNS, BGP, and Certificate Transparency Logs

The discovery pipeline has several distinct channels. DNS AAAA records are the most obvious: any hostname with an IPv6 address that gets queried through a recursive resolver can be logged by passive DNS services. BGP routing tables expose announced prefixes the moment they're advertised, giving anyone watching the global routing table a list of active IPv6 blocks to target. Certificate transparency logs are particularly sharp: the moment you provision a TLS certificate for an IPv6-enabled host, that certificate appears in a public log with the hostname attached.

Beyond passive harvesting, address pattern prediction extends hitlist reach further. Many deployments use EUI-64 addressing, which derives the interface identifier from the host's MAC address. The structure is predictable: a known OUI prefix, a fixed ff:fe insertion, and the remaining MAC octets. An attacker who knows a deployment uses EUI-64 can generate candidate addresses for an entire subnet with minimal computation. Sequential addressing schemes have the same vulnerability.

Tools like ZMap6, Yarrp, and 6Scan operationalize all of this. They accept hitlists as input, handle the IPv6 packet construction, and scale to millions of probes per second across curated target sets. The tooling is mature, documented, and freely available.

Designing the Honeypot Experiment

Choosing T-Pot and Cowrie for the Cluster

The experiment needed to capture a wide surface area without requiring me to build custom honeypot software from scratch. T-Pot was the natural choice. It's a multi-honeypot framework that bundles over twenty individual honeypot services, a centralized Elasticsearch backend, and Kibana dashboards into a single deployable stack. Running T-Pot means you get SSH traps, HTTP traps, Telnet traps, industrial protocol emulators, and more, all logging to the same index simultaneously.

For SSH and Telnet specifically, I layered in Cowrie. Cowrie does something T-Pot's built-in SSH handling doesn't: it maintains a convincing interactive shell session. Attackers who get past the credential phase don't hit a wall immediately. They get a fake filesystem, fake command responses, and a logging system that captures every keystroke. That behavioral data is more valuable than a simple connection count.

Infrastructure Setup: Providers, Subnets, and IPv6 Allocation

The cluster ran across three cloud providers: two major hyperscalers and one smaller regional provider with a more obscure ASN. Geographic distribution covered North America, Western Europe, and Southeast Asia. Eleven nodes total.

Every node was configured as pure IPv6-only. No IPv4 addresses. No dual-stack. This was non-negotiable for the experiment's validity: any IPv4 traffic would contaminate the dataset with noise from the well-documented IPv4 scanning ecosystem, making it impossible to isolate IPv6-specific discovery behavior.

IPv6 addressing was deliberately varied to test discovery vectors. Four nodes used EUI-64-derived addresses, where the interface identifier came from the host's virtual NIC MAC address. Four used cryptographically random interface identifiers with no predictable structure. Three were assigned addresses from the announced prefix sequentially, starting at ::1.

Logging flowed from each node into a central Elasticsearch cluster. Kibana dashboards tracked connection volume, source ASNs, destination ports, and protocol distribution in near real-time. Alert thresholds were set to notify on any connection to a non-standard port and on any successful credential authentication against Cowrie.

Baseline Assumptions and What I Was Testing For

The hypothesis was deliberately conservative: would any meaningful, non-trivial traffic appear on pure IPv6-only endpoints within 30 days? I defined "meaningful" as more than stray ICMP from misconfigured equipment. I wanted to see directed probes, credential attempts, or exploit payloads.

The secondary hypothesis was that EUI-64 nodes would attract more traffic than randomly addressed nodes, if hitlist-based scanning was actually driving discovery. That comparison was the most important variable in the design.

Day-by-Day: When the First Probes Arrived

The First 72 Hours: Silence, Then a Trickle

Hours one through eighteen were quiet. Not completely silent: there were a handful of ICMPv6 echo requests that looked like misconfigured monitoring systems rather than deliberate probes. Nothing that matched an attack signature.

Then, at hour 23, the first EUI-64 node in the European region received a SYN packet to port 22. A single packet. Then nothing for four hours. Then three more SYN packets from a different source address, same destination port. By the 48-hour mark, that node had received connection attempts from seven distinct source addresses, all targeting SSH.

The North American nodes stayed quiet until hour 61. The Southeast Asia node, the one sitting in the smaller regional provider's ASN, didn't see its first probe until day four.

The early probes had a recognizable character. Port 22 dominated, followed by port 23, then port 80 and port 8080. The pattern matched what you'd expect from automated scanning infrastructure cycling through a target list: systematic, fast, and indifferent to whether the host responded with a banner or not.

Week Two: Recognizable Attack Patterns Emerge

Day eight was when the character of the traffic changed. The trickle of port scans gave way to something more deliberate: credential stuffing attempts against Cowrie. The first session lasted 14 seconds and tried 47 username-password combinations before disconnecting. The credentials were a recognizable list: admin/admin, root/root, root/toor, pi/raspberry, ubuntu/ubuntu. Standard botnet credential spray.

By day ten, two of the EUI-64 nodes were receiving over 200 connection attempts per hour. The randomly addressed nodes were receiving fewer than 15. That gap was already telling the story the experiment was designed to find.

ASN analysis on the week-two traffic showed heavy concentration in a handful of networks: several Eastern European hosting providers known for lax abuse handling, two large Asian ISPs, and one North American cloud provider whose IPv6 blocks appear in threat intelligence feeds regularly. The geographic spread suggested coordinated infrastructure rather than independent actors stumbling onto the same targets.

The Full Results: What 30 Days of IPv6 Honeypot Data Revealed

Total Event Volume and Source Distribution

Thirty days. Eleven nodes. The aggregate numbers were not what I expected when I set up the experiment with a conservative hypothesis.

Unique source IPv6 addresses totaled 4,847. That figure matters more than the raw connection count, because it reflects the breadth of the scanning infrastructure rather than the persistence of any single actor. The sources were distributed across 61 distinct ASNs, though the top ten ASNs accounted for 71% of all traffic. Concentration like that points to a small number of well-resourced operations driving the bulk of the activity.

Geographic distribution by ASN origin: 38% Eastern Europe, 29% East Asia, 18% North America, 11% Western Europe, 4% other. These proportions roughly track what IPv4 threat intelligence reports show for scanning infrastructure, which is itself a data point. The same networks operating IPv4 scanning campaigns are operating IPv6 ones.

Attack Types Observed Across the Cluster

Credential brute force was the dominant category, accounting for 61% of all meaningful events. The credential lists used were largely identical to what you see in IPv4 campaigns: default router credentials, common Linux default accounts, IoT device defaults. A small subset used what appeared to be targeted wordlists with organizational naming conventions, suggesting some nodes had been identified as belonging to specific infrastructure types.

Exploit attempts made up 22% of events. These included attempts against CVEs in OpenSSH, Apache, and several IoT firmware stacks. One sequence of probes on day 19 matched signatures for a vulnerability disclosed earlier this year, which suggests attacker tooling is incorporating new CVEs faster than most patch cycles can respond.

Botnet C2 callback attempts appeared on three nodes, where Cowrie's fake shell accepted a connection, the attacker ran a curl or wget command pointing to an external IP, and then waited for a response that never came. These sessions averaged 340 seconds, which is long enough to suggest the automation expected a real host to download and execute a payload.

Reconnaissance-only scans, sessions that probed ports without attempting credentials or payloads, accounted for the remaining 17%.

EUI-64 Nodes vs. Random Addresses: A Stark Difference

This was the result that crystallized everything.

The four EUI-64 nodes averaged 31,400 connection attempts each over the 30 days. The four randomly addressed nodes averaged 2,780 each. The three sequentially addressed nodes fell between them at roughly 8,900 each, suggesting that sequential patterns are also being predicted and targeted, though less effectively than EUI-64.

The timing data reinforced this. EUI-64 nodes received their first probes an average of 31 hours after going live. Randomly addressed nodes waited an average of 9.4 days for their first probe. The difference in discovery latency is consistent with EUI-64 addresses being generated from known OUI ranges and added to hitlists proactively, while random addresses only enter hitlists after appearing in passive data sources.

How Attackers Found Pure IPv6-Only Hosts

Tracing the Discovery Vector for Each Node

Working backward from probe timing, I cross-referenced each node's first contact against known events in its exposure history. The pattern was consistent enough to be convincing.

The European EUI-64 node received its first probe 23 hours after deployment. The only external event in that window was a BGP prefix announcement. The /48 containing that node was announced to the global routing table at hour two. By hour 23, something had noticed that prefix,

Why the 'Safe by Default' IPv6 Assumption Is Now Actively Dangerous

The old assumption went something like this: IPv6 addresses are 128 bits long, the space is astronomically large, and attackers can't scan it the way they scan IPv4. Therefore, your IPv6 deployment is probably fine. This was never a security control. It was an accident of timing. The protocol was immature, attacker tooling hadn't caught up, and the absence of attention looked a lot like safety. It wasn't.

The Gap Between Security Guidance and Current Reality

What actually protected IPv6 deployments for years wasn't the address space. It was the immaturity of the infrastructure built to navigate it. Hitlists didn't exist at scale. IPv6-aware scanners were academic experiments. The threat was theoretical because the tooling was theoretical.

That's no longer the case.

Hitlist infrastructure has matured faster than most practitioners realize. Researchers at TU Munich have spent years building and refining IPv6 hitlists derived from passive DNS, BGP data, certificate transparency logs, and active measurement campaigns. The lists are large, they're growing, and they're increasingly accurate at predicting where real hosts live in the address space.

The practical implication is uncomfortable. If your IPv6 addresses appear in DNS, show up in TLS certificates, or are reachable from any public-facing service, they're almost certainly already in someone's list. The obscurity argument evaporates the moment you have any public presence at all.

Enterprise and Cloud Environments Most at Risk

Enterprise environments carry a specific and underappreciated risk. IPv6 is frequently enabled by default on modern operating systems and network equipment, but monitoring infrastructure is almost never configured to watch it. Your SIEM might be collecting IPv4 firewall logs with careful attention to detail while IPv6 traffic moves through the same perimeter in complete silence.

Cloud environments are worse. Major cloud providers assign publicly routable IPv6 addresses by default on many instance types. The security group configurations that teams carefully apply to IPv4 interfaces are frequently not duplicated for IPv6. The assumption is that nobody will find the address. That assumption is eroding.

Treating IPv6 security as a future problem is itself a misconfiguration. The threat has arrived. The question is whether your detection and prevention controls have arrived with it.

Defensive Lessons: What This Experiment Changed in My Own Setup

Running honeypots changes how you think. Reading about threats is abstract. Watching connection attempts land on addresses you deployed specifically to attract them is not. After seeing the data from this experiment, several things changed in my own environment immediately, and several more changed over the following weeks.

Firewall and ACL Changes for IPv6 Endpoints

The first change was the most obvious and the most overdue: default-deny inbound IPv6 policies on every perimeter device. IPv4 had explicit deny rules everywhere. IPv6 had inherited assumptions. Those are not the same thing, and treating them as equivalent was a mistake I'd been making for a while.

The second change was applying the same ACL discipline to IPv6 that had always existed for IPv4. Not similar discipline. The same discipline. Same review cadence, same documentation requirements, same exception process. If you wouldn't allow arbitrary inbound TCP on IPv4 without a ticket, you shouldn't allow it on IPv6 either.

Address Assignment Strategy Matters More Than You Think

EUI-64 addressing embeds the host's MAC address directly in the IPv6 address. This is convenient and terrible for privacy. It makes addresses predictable and stable across network changes, which is exactly what an attacker building a hitlist wants. After this experiment, I moved sensitive hosts to RFC 7217 stable privacy addresses and enabled privacy extensions on everything else. The addresses are still stable enough to be useful operationally, but they're not derived from hardware identifiers.

This matters because hitlist construction often works by identifying patterns. EUI-64 addresses from common network interface manufacturers cluster in recognizable ways. Don't hand attackers that signal for free.

Monitoring IPv6 Traffic: Filling the Visibility Gap

Enabling IPv6 logging on all perimeter devices sounds obvious. It isn't done consistently. After the experiment, I audited every edge router and firewall and confirmed that IPv6 traffic was generating log entries, that those entries were being forwarded to the SIEM, and that at least basic detection rules were watching them. Two devices were logging IPv6 locally but not forwarding. One had IPv6 logging disabled entirely.

Network segmentation also matters here. Limiting which segments have any IPv6 reachability at all reduces the surface area that needs monitoring. Not every internal VLAN needs a globally routable IPv6 address.

What the Research Community Is Saying About IPv6 Threat Evolution

The academic and industry research on IPv6 scanning has shifted in tone over the past few years. It used to be exploratory: "Can we build effective hitlists?" Now it's confirmatory: "Our hitlists work, they're growing, and attacker tooling is catching up to the research."

TU Munich 2025 Findings on Hitlist Maturation

The TU Munich IPv6 Hitlist project is the most rigorous public effort to measure how scannable the IPv6 address space actually is. Their 2025 measurement study combined passive DNS data, certificate transparency logs, BGP-visible prefixes, and active probing campaigns to build and validate hitlists at scale. The methodology is careful. The results are not reassuring.

"The responsiveness of IPv6 hitlist addresses has continued to improve year over year, suggesting that the addresses captured represent increasingly stable, production infrastructure rather than transient or experimental deployments."

The key finding isn't just that the lists are large. It's that they're accurate. Addresses on the list respond. They represent real infrastructure. The gap between "addresses we know about" and "addresses that matter to attackers" is narrowing.

Censys Data and the Growing IPv6 Attack Surface Index

Censys has been indexing IPv6 hosts alongside IPv4 for several years, and the growth rate of indexed IPv6 hosts is accelerating. Cloud deployments are the primary driver. As providers assign IPv6 addresses by default and as IPv6-only deployments become more common, the indexed surface grows. More indexed hosts mean more data for hitlist construction and more targets for automated scanning tools.

ZMap6 and improvements to 6Scan have lowered the barrier to conducting IPv6 scans against hitlist-derived target sets. These tools don't need to scan the full address space. They need a good list and a fast network connection. Both are available.

The lag between what researchers know and what practitioners have implemented is the most dangerous part of this picture. The research community reached consensus on IPv6 scanning viability years ago. Most enterprise security teams haven't updated their threat models to reflect it. That gap is where breaches happen.

Harden Your IPv6 Deployment: An Action Checklist

The experiment confirmed what the research had been suggesting. Here's what to do about it, broken into what you should handle this week and what belongs in your next 30-day sprint.

Immediate Actions (This Week)

Medium-Term Hardening (Next 30 Days)

Conclusion: Stop Treating IPv6 as a Future Problem

The honeypots received traffic. Some of them received it within days of deployment. These were pure IPv6-only addresses with no DNS records, no associated services, and no reason to exist in any organic traffic flow. The connections were not accidents.

What remains true is that random scanning of the full IPv6 address space is still computationally impractical. A determined attacker cannot simply iterate through every possible address the way they can with IPv4. But that's not how modern attackers operate. They use hitlists. They use passive DNS. They use certificate transparency logs and BGP data and every other signal that tells them where real infrastructure actually lives. The address space being large only protects hosts that have never been seen. If your infrastructure is doing anything useful, it's been seen.

The call to action is direct: audit your IPv6 posture today as if your prefix is already in every major hitlist. Because it may be. Check your firewall rules. Check your logging. Check your cloud security groups. Assume nothing was configured correctly for IPv6 unless you have verified it explicitly.

The window to get ahead of this is narrowing. Attacker tooling improves every year. Hitlists grow every year. The practitioners who treat IPv6 hardening as a present-tense problem, not a future one, are the ones who won't be explaining an incident that came in through an interface nobody was watching.