Twelve minutes at one login page
At 02:49:08 UTC on 23 October 2026 a flood of HTTP/2 requests hit the login page of a website we protect. It ran until 03:01 UTC, just under 12 minutes.
In that time the edge received 96,785,711 requests, about 135,000 a second on average. The busiest second, right at the start, carried 350,333. All but 383 requests were stopped at the edge. The website stayed online and kept serving its visitors, and the other websites on the same edge were served normally.
The same seven Safaris, the same two Googles
The requests carried the fingerprints of the 20 October flood:
- The same seven User-Agents in an even rotation. All seven claim Safari on iPhone and iPad, and each carried between 14.2% and 14.3% of the requests, the same strings in the same even split as on 20 October.
- The same referers. Half of the requests named
https://www.google.com.tr/and halfhttps://www.google.com/(50.0% and 49.9%). - One request, over and over. Practically every request was a
GETfor the login page, and all but 620 of the 96.8 million came over HTTP/2.
| User-Agent | Share |
|---|---|
Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Mobile/15E148 Safari/604.1 | 14.3% |
Mozilla/5.0 (iPhone; CPU iPhone OS 17_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Mobile/15E148 Safari/604.1 | 14.3% |
Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1 | 14.3% |
Mozilla/5.0 (iPad; CPU OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1 | 14.3% |
Mozilla/5.0 (iPad; CPU OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Mobile/15E148 Safari/604.1 | 14.2% |
Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1 | 14.2% |
Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4.1 Mobile/15E148 Safari/604.1 | 14.2% |
What changed was the setting. The flood aimed at a login page instead of a home page, and it ran more than three times as long at about a quarter of the rate.
| 20 October | 23 October | |
|---|---|---|
| Target | A home page | A login page |
| Duration | 3 minutes 29 seconds | Just under 12 minutes |
| Requests | 118.0 million | 96.8 million |
| Busiest second | 1,015,237 | 350,333 |
| Average a second | ≈564,000 | ≈135,000 |
| Addresses | ≈889,000 | ≈1.07 million |
| /24 networks | ≈478,000 | ≈557,000 |
| Countries | 52 | 58 |
| Data received | 49 GB | 42 GB |
A crowd that ran out of new faces
On 20 October the crowd changed every minute: 98% of the second minute's addresses were new. This time the flood ran long enough to use its crowd up. The first two minutes were almost all new addresses. From the third minute on, the share of new ones kept falling, and in the last minute 98% of the addresses had already been seen in this flood.
| Minute (UTC) | Requests | Busiest second | Addresses | Not seen before |
|---|---|---|---|---|
| 02:49 (from :08) | 11,193,260 | 350,333 | ≈345,000 | ≈345,000 |
| 02:50 | 8,003,996 | 173,581 | ≈248,000 | ≈248,000 |
| 02:51 | 8,691,230 | 176,607 | ≈273,000 | ≈164,000 |
| 02:52 | 9,704,972 | 177,119 | ≈303,000 | ≈103,000 |
| 02:53 | 8,634,396 | 153,266 | ≈271,000 | ≈72,000 |
| 02:54 | 8,612,585 | 152,792 | ≈273,000 | ≈40,000 |
| 02:55 | 7,974,160 | 142,343 | ≈240,000 | ≈29,000 |
| 02:56 | 7,513,451 | 131,326 | ≈235,000 | ≈20,000 |
| 02:57 | 7,245,004 | 128,037 | ≈224,000 | ≈12,000 |
| 02:58 | 6,814,750 | 121,177 | ≈208,000 | ≈16,000 |
| 02:59 | 6,769,089 | 118,114 | ≈211,000 | ≈10,000 |
| 03:00 | 5,628,818 | 119,391 | ≈177,000 | ≈4,000 |
In any one minute the flood came from 177,000 to 345,000 addresses. Over the whole flood it reached about 1.07 million, and then it had no new ones left to bring.
Half the crowd came back
We compared the addresses of the two floods. About 476,000 took part in both: about 54% of the 20 October crowd came back, and they made up about 44% of the new one. At the level of /24 networks the overlap was larger. About 72% of the networks seen on 20 October appeared again.
Together the two floods came from about 1.49 million different addresses. That is the size of the crowd this tool has shown us so far, not the size of the network behind it: the other half of each crowd was new. Home and mobile connections change addresses all the time, so a botnet of infected devices or a residential proxy network reappears partly under new addresses and largely inside the same networks, which is what we saw.
Home connections in 58 countries
The 1.07 million addresses were spread over about 557,000 /24 networks, fewer than two per network. No country sent more than 15% of the requests. Compared with 20 October, more of the flood came from China and Vietnam.
| Country | Share of requests |
|---|---|
| United States | 15.0% |
| Russia | 10.1% |
| China | 8.2% |
| Brazil | 7.5% |
| United Kingdom | 4.9% |
| Vietnam | 4.0% |
| Canada | 3.8% |
| Mexico | 3.4% |
| Colombia | 3.3% |
| Japan | 3.2% |
| Others | 36.6% |
The largest networks were again home and mobile internet providers. The largest sent less than 5% of the requests, and the ten largest together less than 22%.
| Network | AS number | Share of requests |
|---|---|---|
| Chinanet | AS4134 | 4.3% |
| Comcast | AS7922 | 3.7% |
| Rostelecom | AS12389 | 3.1% |
| China Unicom | AS4837 | 1.9% |
| AT&T | AS7018 | 1.8% |
| VNPT | AS45899 | 1.7% |
| Uninet (Telmex) | AS8151 | 1.4% |
| Verizon | AS701 | 1.4% |
| Virgin Media | AS5089 | 1.4% |
| Viettel | AS7552 | 1.2% |
What this flood says about protecting a login page
Login limits per address do not reach it
Over the whole flood each address sent about 90 requests, one every eight seconds. In the first 52 seconds, about 345,000 addresses sent 11.2 million requests: about 0.6 a second each. A login limit that low also locks out real customers who share an address.
Last attack's blocklist covers half
A list of every address from the 20 October flood would have held less than half of the addresses of this one. And those are home connections: the same addresses belong to real customers of the same providers.
Coming back is not proof
Addresses repeated, within this flood and across the two. Real visitors repeat too, behind the same shared and reassigned home addresses. Seeing an address again says little about the device behind it.
As on 20 October, what told the flood apart from real visitors was what each client showed on its own requests and connections, not where it came from or whether we had seen its address before. Shieldify decides per request and per client on that evidence, so a customer on the same network as an attacking device can still log in.
Data and method
All figures come from Shieldify's edge, which recorded the flood as it happened. Request and byte counts are exact. Distinct addresses and /24 networks are HyperLogLog estimates (about ±2%). The overlap of the two floods comes from merging their HyperLogLog sketches and is good to about ±35,000 addresses. Country, network, User-Agent, referer and path shares are estimated from a weighted sample of the requests. Times are in UTC. We publish no addresses, and we do not name the website.
Countries and networks: IP Geolocation by DB-IP (IP to Country Lite and IP to ASN Lite, CC BY 4.0).