IPv6 Trends in User Account Compromises

Lately we've observed a noticeable increase in account takeover activity making use of IPv6 in ways that traditional IP-based controls simply aren't designed to handle.

What's interesting isn't that adversaries are using IPv6. It's how they're using the enormous address space to make authentication attempts appear to come from a constantly changing source, effectively sidestepping controls that rely on blocking or building reputation around individual IP addresses.

Here's a small sample of IPv6 addresses observed in attempted account takeover activity:

2a0a:d683:fb:ec75:65bd:9052:aacd:2d47
2a0a:d683:fb:f1f1:1b0a:a20c:9067:3212
2a0a:d683:fb:f93b:d170:1c46:a45a:7bbf
2a0a:d683:fb:fc56:ccf9:aeef:c366:d89f
2a0a:d683:fc:a408:7f56:b8af:c745:de0c
2a0a:d683:fc:d1f3:648:db7:6344:ff77
2a0a:d683:fd:1736:31eb:5c27:7ea0:4121
2a0a:d683:fd:38da:bd0c:bb3e:54fd:a134
2a0a:d683:fd:4c60:fbf4:dc31:c357:4c36
2a0a:d683:fd:8a56:e756:542e:2bf9:7b83
2a0a:d683:fd:97e5:cbd0:631d:c73d:9ef1
2a0a:d683:fd:bbab:b8a5:577b:a689:bd7f
2a0a:d683:fd:f35b:d20b:cd65:3d1:8a0a
2a0a:d683:fe:1565:e2f4:832e:d369:7b69
2a0a:d683:fe:19b2:6872:e872:98ec:e88b
2a0a:d683:fe:d626:6c40:85c8:4203:c5d6
2a0a:d683:ff:1473:3829:1f98:70c1:72f0
2a0a:d683:ff:47b:b367:f8e4:770e:872

(This list has been shortened substantially, but you'll see the pattern in the prefix)

At the time, these addresses were part of AS32167 (LSHIY LLC), although the actor has since moved on. This isn't a set of thousands of separate hosts; it's a single allocation with a /32 prefix being used by a single host: 2a0a:d683::/32.

That gives the adversary around 79.2 octillion addresses to play with - roughly 18.44 quintillion times the size of the entire IPv4 address space (in case you were interested!).

Essentially, every single account takeover attempt can come from a brand new randomly generated IP address in that block, with no need to ever reuse one.

Security controls that block, throttle, or maintain reputation on a per-IP basis are basically irrelevant here. So if you're not looking at the CIDR and understanding the reputation of the range behind the address, you're going to struggle.

We've seen similar activity across a range of ISPs. Here is a sample of ranges operated by Hurricane Electric:

2001:470:50f8::/48
2001:470:50fa::/48
2001:470:5101::/48
2001:470:723a::/48
2001:470:7884::/48
2001:470:b6cf::/48

Hurricane Electric provide a tunnel broker service, enabling people to reach the IPv6 internet by tunnelling over IPv4. A tunnel user has access to a /48 prefix, so in this case we can see that the adversary is making use of multiple Hurricane Electric allocations in order to tunnel their activities.

Something defenders often overlook is that most VPS providers hand out a block of IPv6 addresses, typically a /48 or /64, to every host. Here's a snippet of IPv6 addresses in use by a single OVH VPS involved in account takeover activity:

2607:5300:203:9e47:4b0c:a303:b756:5ad8
2607:5300:203:9e70:50af:dfff:5215:cd6e
2607:5300:203:9e47:3197:77e0:4666:8831
2607:5300:203:9e61:4f8e:e93a:d38b:3da5
2607:5300:203:9e61:125b:fda7:266f:9291

With OVH, it's free to get access to additional /56 blocks:


Looking at the addresses above, it seams we're dealing with the range 2607:5300:203:9e::/56, presumably the /56 assigned to the adversaries VPS.

This isn't unique to OVH. Some hosting providers, such as Clouvider and Hostinger, hand out a /48 to every VPS by default. Others, including Linode/Akamai, Vultr and Hetzner, provide a /64.

IPv6 address space is so plentiful that this makes perfect sense - that was a huge point of IPv6. But if your defences are still following an IPv4-era "block the IP address" model and applying this to IPv6, they're simply not going to keep pace in an IPv6 world, and adversaries know it.

We've also seen similar activity from AS6079 (RCN), from a range we believe was in use at the time by Netlabs LLC customers, again /48 allocations:

2a06:b440:2::/48
2a06:b440:3::/48
2a06:b440:5::/48

We're currently seeing activity from AS200373 (3xK Tech GmbH), an ASN that hadn't really cropped up in a noticeable way for us previously. Here we see two allocations currently in use:

2a13:3f80::/32
2a0a:da40::/29

In this case, we're able to confirm with a very high degree of confidence that every single address in those two CIDR ranges is assigned to a single actor, or rather a single system.

It's not just VPS providers making IPv6 space easy to come by. Recently we've observed traffic targeting user accounts originating from the following Cloudflare ranges:

2a09:bac1::/32
2a09:bac5::/32

These are both IPv6 blocks owned by Cloudflare, although they're not documented as such on Cloudflare's website. We suspect they're being used via the WARP client or pages/workers.dev services.

Advice for defenders investigating IPv6-related incidents

If you're investigating suspicious IPv6 activity, one of the biggest mistakes you can make is treating an individual IPv6 address in the same way you'd treat an IPv4 address.

It's rare for a hosting provider to assign a customer a single /128 IPv6 address. Typically, addresses are handed out in blocks of at least a /64. So when you observe malicious activity from an IPv6 address, it's worth understanding the nature of the range behind it, and in particular the reputation of that range as a whole rather than just the individual address.

Searching for a single IPv6 address in your favourite threat intelligence platform is unlikely to tell you anything useful:

While it won't always be the case, in all likelihood you're the only one to have observed an attack from that specific address. The next probe may come from another address in the same range, and the one after that from another.

When it comes to IPv6 and AiTM (something we specialise in), the most common situation we see is an adversary who has spun up a VPS and, despite having an entire /64 available to them, only uses the one configured address.

Exactly how these look depends somewhat on the hosting provider's configuration, but a compressed address like this is often a good indication of a VPS with a CIDR allocation behind it:

2001:db8:dead:beef::1

SLAAC and DHCPv6 will typically result in a much less predictable interface identifier. A neat ::1 is more suggestive of deliberate configuration, something commonly seen on VPSs where a provider has assigned the host a larger IPv6 prefix.

(We've swapped the real prefixes here for 2001:db8::/32, the documentation range reserved for exactly this kind of example - i.e. don't treat this range as malicious!)

In these cases it's worth assigning reputation to the whole CIDR. The address format can also tell you something about the adversary: they haven't bothered configuring any of the other addresses available to them.

They're likely connecting to their VPS via IPv4 and assuming that the IPv4 address is what's being used to perform the AiTM authentication. Whether that's actually the case depends entirely on whether their dual stack VPS chooses IPv4 or IPv6 at that point in time.

An address like the following can be trickier to assess without further enrichment or correlated activity:

2001:db8:dead:beef:5400:6ff:fe77:d1b7

Here, a greater level of care is advised. Much of the activity we've observed from the ranges shared in this post relates to account brute-forcing by initial access brokers leveraging infostealer logs to seed their attempt to gain access. With attackers cycling through addresses, the reputation of one individual IPv6 address tells you very little. You need to understand what sits around it: the allocation, the ASN, other activity from the same range, and whether the addresses form part of a wider pattern.

In other words, don't automatically block a huge IPv6 range because one address looked suspicious. But equally, don't assume an address is clean simply because that exact /128 has never appeared in your threat intelligence before.

Why isn't this being caught already?

This isn't a new gap, but it's one we see constantly, and it's becoming increasingly important for defenders to understand given the recent uptick in IPv6-driven account takeover activity.

Below is a sample from a set of authentication logs where the overwhelming majority of malicious activity originated from IPv6 ranges. Filtering for instances where Entra ID blocked a sign-in specifically because of IP reputation removes almost none of it.

If you rely on Entra ID to help secure your environment, it's worth being aware of this limitation. Microsoft does block authentication from IPs it has flagged as malicious, but when we run that filter against our own data, only a very small subset of the malicious activity we see is caught by its reputation scoring.

From what we observe, its IPv6 coverage appears extremely limited and largely address-focused rather than CIDR-focused.

Below is a tiny fraction of a set of authentication logs showing sign-ins blocked by Microsoft's reputation scoring. The sample includes just one of the two IPv6 entries it identified as malicious across the whole dataset. Tens of thousands of other IPv6 addresses involved in far more prolific campaign weren't identified, nor were their CIDRs:

If Microsoft are maintaining reputation on a per IP address basis, and adversaries are rotating IP address on each authentication attempt, this is simply going to sidestep Microsofts reputation scoring.

This limitation is well worth being aware of. Most SOC tooling simply doesn't work for IPv6 in the same way it does for IPv4.

To be fair to Microsoft, this isn't an easy problem to solve well. Unlike IPv4, where a single address can be a reasonably strong signal, IPv6 reputation often only becomes meaningful at the CIDR level, and there's no reliable way for a third party to know where one customer's allocation ends and another's begins.

A hosting provider might hand out a /48, a /56 or a /64, and that boundary isn't necessarily published anywhere. Building a reputation system that's confident enough to block traffic without also catching huge swathes of legitimate users sharing the same /32 or /48 is a genuinely hard problem at Microsoft's scale.

That said, "hard" doesn't mean it should be ignored. If you're relying on Entra ID's built-in reputation scoring as a primary control against IPv6-based credential attacks, our data suggests that it's offering little to no benefit. And unfortunately the same goes for most other similar tooling.

It's unlikely that these type of attacks will disappear overnight, so understanding how adversaries are using IPv6 to sidestep classic IP based controls is something to be aware of.

Note to our subscribers

All of the CIDR ranges described above, as well as numerous others, were actively blocked in your environment prior to, and during, the attacks we observed, ensuring account compromise attempts from these ranges will have failed. We work with CIDR ranges across both IPv4 and IPv6 in order to ensure effective, proactive, controls.

Our Cloudflare named location also includes multiple "undocumented" Cloudflare ranges we've observed being used in account takeover activity.

If you're seeing similar activity in your environment, it is probable that credentials for the affected user accounts have been disclosed, if so you should check our infostealer dataset to understand your exposure.

If you're not already a subscriber, but would like to proactively block account takeover attacks, you can subscribe here.