Where do automated attacks actually come from? 238 attack networks, mapped from 887,000 real events

What is the RankShield mesh actually measuring?

The mesh is the shared threat-intelligence layer that every RankShield product reports into. When a protected WordPress site, Shopify store, or device guardian encounters hostile traffic, the event is recorded, and the mesh resolves the source address to the network that owns it. In networking terms that owning network is an Autonomous System, identified by an ASN, which is simply the unit an internet provider or cloud host uses to announce the blocks of addresses it controls. The product’s attack-network view groups events by ASN, which is why the headline figure is 238: that is the count of distinct networks the mesh has caught hostile traffic coming from since it started collecting.

Two numbers describe the same thing at different resolutions, and it is worth being precise about them. The 238 is the count of distinct networks (ASNs). The 9,085 is the finer-grained count of distinct address blocks, the IP prefixes, that those networks attack from. One network can announce many prefixes, so a single ASN in the 238 can account for dozens of the 9,085. Both are real and both matter: the ASN count tells you how many operators you are up against, and the prefix count tells you how much address space they spread across to stay hard to block.

What does a live attack-network map look like?

It looks like the infographic below: a small number of high-volume networks doing most of the damage, sitting on top of a long tail of thousands of address blocks. This is the shape of the data as of July 3, 2026, drawn straight from the production mesh. Download it, share it, put it in a deck. The pattern it shows is the argument for measuring attackers by network rather than by address.

Where are this week’s attacks coming from?

Zooming into the last seven days sharpens the picture. In that window the mesh recorded roughly 586,000 events from 90 actively hostile networks spread across 4,587 distinct IP prefixes. That the seven-day event count is such a large share of the all-time total tells you the mesh’s collection has scaled quickly and that recent hostile volume is high, not that older weeks were quiet by comparison.

The concentration at the top is the real story. The five networks below account for the heaviest hostile traffic this week, and each one is a well-known cloud or hosting provider. The "prefixes" column shows how many distinct address blocks within each network the attacks came from, and "products hit" shows how many different RankShield product types saw traffic from that network, which is a direct signal that the same infrastructure is being pointed at more than one kind of target.

Why are the top attackers all cloud providers?

Because that is where modern attack infrastructure lives, and it is important to say clearly what that does and does not mean. It does not mean Google Cloud, AWS, Tencent, or DigitalOcean are attacking anyone. It means attackers rent computing capacity from these providers the same way legitimate businesses do, spin up disposable instances, run their bots from the provider’s address space, and discard them when they get blocked. The hostile traffic originates from IP space that belongs to the provider, but the hand on the controls is a customer abusing the service, and every one of these providers has an abuse process precisely because of it.

The reason attackers prefer cloud and hosting infrastructure over, say, a home connection is entirely practical. Cloud gives them scale on demand, reputationally clean IP space that is not already on every blocklist, geographic spread, and the ability to rotate through fresh addresses the moment one gets flagged. That last point is why the prefix counts matter so much: a network like Google Cloud showing up with attacks from 25 distinct prefixes in a week is the fingerprint of an operator rotating through address blocks to stay ahead of simple IP bans. Blocking one address accomplishes almost nothing when the attacker holds thousands more in the same network.

This is also why the honest unit of measurement is the network, not the address. A single IP is disposable and meaningless on its own. The network it belongs to, and the pattern of behavior across that network, is the thing that actually identifies an attacker and lets you anticipate the next address before it is used. Seeing 238 networks is far more useful than seeing a million individual IPs, because the networks are what persist.

There is a practical warning in this for defenders, and it is the reason so many blocklists feel like they never quite work. If you respond to abuse by banning individual addresses, you are playing a game the attacker has already won, because the marginal cost to them of a fresh address inside the same cloud network is essentially zero, while the cost to you of maintaining an ever-growing list of dead IPs is real and rising. The providers themselves cannot simply blanket-ban the abusers either, because the very same networks carry enormous volumes of legitimate traffic, so a heavy hand there would break the good along with the bad. The workable response is to shift the unit of decision up a level: reason about the reputation and behavior of the network and the prefix, apply friction proportional to how a source is behaving rather than to a static list, and lean on intelligence gathered across many targets so a network that turns hostile anywhere is recognized everywhere. That is precisely what the numbers on this page are built from, and precisely what a single site, looking only at its own slice, can never assemble on its own.

What does a network-level view give you that a single site can’t?

A single protected site only ever sees the slice of an attack that is aimed at it. From that vantage point every hostile request looks new, and the site learns each attacker the hard way, one hit at a time. The whole value of a mesh is that it changes the vantage point. When one protected endpoint anywhere encounters a hostile network, that recognition becomes available to every other endpoint, so the next site the attacker touches already knows the network and can act on it immediately.

The "products hit" column in the table above is the clearest evidence of why this matters. When the same network shows up attacking three or four different RankShield product types in a single week, it proves the attacker is not targeting one customer, they are running the same infrastructure against many targets at once. That is precisely the situation a network defends against and a lone site cannot: the attacker’s own reuse of their infrastructure is what betrays them, but only something watching across many targets can see the reuse. One site sees a stranger; the mesh sees a repeat offender.

This is the honest version of a "network effect" in security. It is not a slogan. It is the concrete mechanic that turns 238 separately-observed nuisances into a shared map that every protected endpoint can use, and that gets sharper each time another endpoint joins and contributes what it sees. The data on this page is what that map looks like at one moment in time.

Is your own infrastructure exposed to these attack networks?

The networks in the map above are not aimed at RankShield in particular; they sweep the whole internet, which means they are almost certainly touching your sites and services too. The useful question is whether you would know, and whether you could do anything about it. Run the quick check below. It scores how well your current setup handles exactly the pattern this data reveals: high-volume, network-level, cloud-hosted automation that rotates addresses to evade simple IP blocks.

How honest are these numbers?

As honest as we can make them, which means disclosing their limits rather than rounding them off. The most important caveat is enrichment coverage. Resolving a raw IP address to the network that owns it requires an enrichment step, and that step is rate-limited and best-effort, so not every event has had its network identified yet. Every figure on this page counts only the events where enrichment has run. The practical consequence is that the true number of distinct attack networks is very likely higher than 238, not lower, because some hostile traffic is still sitting in the queue unresolved. We would rather report a firm 238 we can stand behind than an inflated estimate we cannot.

The second point is the definitional one, restated because it is easy to conflate: 238 is the count of networks (ASNs), and 9,085 is the count of distinct address prefixes those networks attack from. If you see the two numbers quoted interchangeably somewhere, that is a mistake. They measure the same activity at different resolutions. And the third is simply the collection window: this data begins on June 17, 2026, when the mesh started recording, so "all-time" here means since that date, not since the beginning of the internet. None of these caveats weaken the core finding. They are the difference between a marketing number and a measurement, and this is a measurement.