194 addresses, all resolved

There's a common mental picture of bot traffic: a botnet of hijacked home computers, malware quietly conscripting somebody's laptop into a scanning army.

I resolved every address that touched one of my systems over ninety-six days β€” all 194 of them β€” to the network that actually owns it. The picture is close to the exact opposite.

Nobody's laptop is doing this. Somebody's credit card is.

87%
of hostile addresses were
rented infrastructure
93%
of hostile events came
from the same
90%
of everyone else came
from a home connection
13
of 30 attacking addresses
were Google Cloud
01 The Method

How to Ask This Question Properly

Every source address in the log was resolved to its ASN β€” the autonomous system number, which identifies the network that actually announces that address to the internet. That gives a real name for each one: AMAZON-02, ATT-INTERNET4, GOOGLE-CLOUD-PLATFORM.

Addresses were then split two ways. Hostile meant anything that tripped a honeypot, was reported to a public abuse database, or requested a known credential, configuration or CMS probe path. Everything else was all remaining traffic. Each address was then bucketed as hosting/cloud, consumer ISP, or other.

This is a question almost nobody asks about their own logs, because the log hands you an address and stops. The address is meaningless on its own. The network that owns it is the entire story.

02 The Split

An Almost Perfect Inversion

Hostile Traffic

30 Addresses

  • 87% hosting / cloud infrastructure
  • 3% consumer ISP
  • 10% other or unresolved
  • Countries: overwhelmingly US, with single addresses in Lithuania, Romania and China
SOURCE: RENTED
Everything Else

164 Addresses

  • 7% hosting / cloud
  • 90% consumer ISP
  • 4% other
  • Ordinary home and mobile broadband, almost entirely domestic
SOURCE: RESIDENTIAL

Weighted by events rather than distinct addresses, it sharpens further. Of 80 hostile events, 93% came from hosting networks. Exactly one β€” a single event across ninety-six days β€” came from a consumer ISP.

On this dataset the network type is very nearly the answer by itself. Datacenter means hostile. Home broadband means human.
03 The Senders

Not Who You'd Guess

Ask anyone which cloud the attacks come from and they'll say Amazon.

The single largest source was Google Cloud β€” 13 of the 30 hostile addresses, more than Amazon's two networks combined.

Hostile addresses

by network Β· 30 total

  • Google Cloud Platform13
  • Amazon (AMAZON-02)4
  • Amazon (AMAZON-AES)4
  • DigitalOcean2
  • Hostinger Β· Cloudflare Β· a UK reseller Β· a China Telecom data park Β· one other1 each

Everything else

by network Β· 164 total

  • AT&T104
  • Comcast16
  • T-Mobile14
  • Charter5
  • Verizon4

Two completely different internets, arriving at the same hostname. One is a handful of datacenters. The other is home broadband and mobile phones.

04 The Economics

Why It's Rented, Not Stolen

Compromising machines is expensive. You need a working exploit, you need to maintain persistence, and the machines are unreliable β€” they get patched, they get turned off, they sit behind home connections that drop.

Renting is cheap, instant and dependable. A scanner on a cloud instance gets a clean address, a fast connection, no owner to notice anything, and it can be destroyed and recreated in seconds. The capacity is billed by the minute and available to anyone with a card.

Mass internet scanning isn't a hacking problem any more. It's a procurement decision β€” and the barrier to sweeping every address on the internet for a leaked credentials file is a signup form.

05 The Application

What You Can Do With This β€” and What You Shouldn't

The obvious move is to block datacenter networks outright. That's more dangerous than it looks, and this post would be irresponsible if it didn't say so.

Blanket-blocking hosting networks breaks legitimate search crawlers and AI assistants, uptime monitors, link checkers and preview generators, corporate VPNs and privacy relays, and quite possibly your own CI and webhook tooling. In this very dataset, 11 non-hostile addresses were on hosting networks β€” including Google and Microsoft.

01

One signal, not a verdict

Combine network type with what the request actually asked for. A datacenter address requesting a credentials file isn't ambiguous. A datacenter address reading your blog probably is.

02

Different thresholds, not different verdicts

Rate-limit datacenter traffic harder. Challenge it sooner. Log it more verbosely. Same rules, tuned by how likely the source is to be a person.

03

Allow the crawlers by name

Name the agents you actually want β€” search, AI assistants, your own monitoring β€” explicitly, and let the rest of the datacenter traffic meet the stricter rules.

The finding isn't "block the cloud." It's that there's a strong, cheap, almost entirely unused signal sitting inside a field you already log β€” and hardly anybody ever looks it up.

06 The Limits

Read Before Quoting This

Thirty hostile addresses is a signal, not a law. One property, ninety-six days. Clear enough to act on, small enough that I wouldn't generalise it to the whole internet.

The residential finding is partly about who my users are. This is an internal system used by me and a small number of people in one metro area. That AT&T figure is largely one dynamic home connection being reassigned a new address over time. It's a statement about this user population, not a universal truth about legitimate traffic β€” a consumer product would look very different.

A privacy relay in the hostile column isn't the relay attacking you. Proxies exit through their own networks, so the address tells you about the exit point rather than the origin.

Google Cloud leading does not mean Google is attacking anyone. It means Google Cloud is where the scanners happened to be rented that month. Providers are the venue, not the actor, and next quarter the ranking could easily invert.

ASN assignments drift. These were resolved in August 2026. Anyone reproducing this should re-resolve rather than reuse my mapping.

Why this was worth doing

This took about an hour. The addresses were already in the log; the only new work was asking who owns them. That's the part worth copying β€” not my numbers, but the question.

If you run anything with a log table, you can answer this about your own traffic today, and you'll almost certainly learn something you were guessing about before.

The bottom line

The attacks aren't coming from hijacked laptops. They're coming from a datacenter, on a monthly invoice.

The network that owns an address tells you far more than the address ever will β€” and it's already sitting in your logs.

Sources & Method

Method. First-party security event log, 623 rows, May–August 2026. All 194 distinct source addresses were resolved to their ASN and network name. "Hostile" means an address that tripped a honeypot, was reported to a public abuse database, or requested a known credential, configuration or CMS probe path. Individual addresses are not published here; the network names and counts carry the argument. The author's own test traffic is excluded.