Between the night of October 7 and the night of October 11, 2026, Ukrainian drones hit three Yandex data centers: Sasovo in the Ryazan region, then Kaluga, then Vladimir. At about 00:30 UTC on October 11, HTTP traffic from Yandex's search network, AS13238, was 99 percent below the previous week on Cloudflare Radar, and traffic from Yandex Cloud, AS200350, was down 90 percent. Screenshots of the chart circulated as proof that Russian social media bots had gone quiet, alongside an unsourced graph said to show AfD activity, which Czech MEP Tomáš Zdechovský shared on October 11, and Volodymyr Zelenskyy told the Warsaw Security Forum on October 12 that there were "fewer bots."
Cloudflare's own forensics, published on October 14, say something more useful and less dramatic. The traffic that vanished from AS13238 was almost entirely Yandex's own verified crawlers indexing web pages. The high-volume automation on AS200350 did not stop. It moved: the bots aimed at one gambling customer reappeared on other Russian hosting networks, Radist and Selectel among them, with the same TLS fingerprint, the same odd request paths and the same custom User-Agent strings. Russia-origin bot share dipped from 50.4 to about 42 percent of requests, and by 18:00 UTC on October 14 Yandex traffic was back to 85 percent of normal.
Three data centers were hit and the bots moved house within hours. That is the actual lesson of the week, and it is a lesson about what an autonomous system number does and does not tell you about a request.
Three strikes, one chart, and what the curve measured
The physical sequence is well documented. Meduza reports that the Sasovo site houses two of Yandex's three AI training supercomputers. It was hit overnight on October 7 to 8 and stopped operating. Kaluga lost part of its infrastructure on the morning of October 9. Vladimir went offline on the night of October 11, after which Yandex Cloud told customers the platform was in emergency mode, and Kommersant's source put equipment replacement at up to six months.
Cloudflare Radar's curve for AS13238 tracks this closely: about 35 percent lower after Sasovo, then a 99 percent collapse when Vladimir shut down. Both Yandex networks stayed 86 to 90 percent below baseline through October 13.
A chart like this has no column for "who ran the bot." It counts HTTP requests from an address range, and when the servers inside that range lose power the requests stop, whether they came from a search crawler, a price scraper or a troll farm. Cloudflare's post is blunt about it: there was no evidence that the strikes knocked social media manipulation offline. For one social media platform, bot traffic to its post, reply and like endpoints from Russia fell 5.7 percent over the event. Globally it rose 1.1 percent.
Two Yandex networks, two kinds of bot
The part of Cloudflare's analysis worth keeping is the split between the two ASNs, because they carry opposite kinds of automation and deserve opposite treatment.
| AS13238, Yandex Search | AS200350, Yandex Cloud | |
|---|---|---|
| RIPE holder | YANDEX LLC | Yandex.Cloud LLC |
| Announced IPv4 (RIPEstat, Oct 14) | 29 prefixes covering 192,768 addresses | 52 prefixes covering 219,648 addresses |
| Requests classified as automated | 99.5% | about 95% |
| Bot requests Cloudflare could verify | 93.6% | 0% |
| What the bots were | 78.1% YandexBot, 11.5% YandexRenderResourcesBot, 1.9% YandexImages | Scripts self-identifying as Python, Go or JavaScript; WordPress plugin probes; scanners |
| Share of global bot requests | 0.05% | 0.01% |
| Customers already blocking it | 40.5% returned 403 to the crawler (news-site traffic) | Blocks fell 70% during the event |
AS13238 is a search engine. Its traffic is verifiable because Yandex, like Google, publishes a reverse DNS convention: the PTR record of a real crawler address ends in yandex.ru, yandex.net or yandex.com, and the forward lookup of that hostname returns the original address. Yandex's own webmaster documentation describes this check and does not publish a crawler IP list, because the addresses change frequently. When the network went dark, publishers lost a crawler. Nothing else.
AS200350 is a cloud. Anyone with a card can rent a VM there, and the traffic looks like it: nearly two-thirds of its bot requests sent data to websites rather than fetching it, and WordPress plugin probing fell 90 percent during the outage. None of it was verifiable because none of it belonged to an operator who publishes an identity. Swap in AS16509 or AS14061 and the shape is the same.
To be fair to the people who misread the chart, the two networks share a brand, and Radar shows them side by side. But a verified crawler and an anonymous cloud tenant have nothing in common except the first six letters of their AS name.
The gambling bot that moved to Selectel and Radist
The most interesting paragraph in Cloudflare's post concerns a single customer. Nearly all of Yandex Cloud's bot traffic to gambling sites targeted one customer account, rotating between its hostnames, and 99.1 percent of those requests were already getting 4xx responses before the strikes. Immediately after the October 8 Sasovo disruption, requests from AS200350 to that account dropped to zero.
They did not stay at zero anywhere else. Identical requests started arriving from Radist, which holds AS57753 and announces six IPv4 prefixes covering 2,048 addresses, and from Selectel, the St. Petersburg hoster whose two main networks are AS49505 and AS50340. Cloudflare matched them on four things: the same JA4 TLS client fingerprint, the same uncommon request paths, the same HTTP headers and the same custom User-Agent strings. Over the week, Russian bot traffic to gambling accounts went from 167.7 million to 170.1 million requests, up 1.4 percent. The operator lost a data center, and the gambling traffic it was part of stayed essentially flat.
Cloudflare's explanation is the right one: cloud workloads are portable, so when a data center goes dark or a prefix gets blocked, the operator rents capacity elsewhere and redeploys in hours. No defender forced this move; drones did. Had someone blocked AS200350 on October 6, the result would have been the same migration two days earlier, plus collateral damage to the cloud's legitimate tenants, whose traffic made api.cloudflare.com one of its top hostnames.
Why an ASN is the wrong unit of blocking
An autonomous system number identifies who announces a route in BGP. That is all. It says nothing about who runs the process that generated the request, and on a hosting network there are several layers between the two: the hoster announces a /16, assigns a /22 to a reseller, who assigns a /24 to a VPS panel, who hands single addresses to customers who signed up an hour ago. The origin AS is identical all the way down. Blocking it blocks the panel's other 250 customers and everyone else in the /16, and keeps blocking them until someone remembers the rule exists.
Cloudflare groups Selectel and Radist together as "other Russian hosting ASNs." Nothing in the registry ties the gambling bot to either: it was a tenant, and tenancy does not show up in a routing table. A country block has the same flaw one level up. Russia-origin bot share fell from 50.4 to 42.1 percent while Russian bot traffic to gambling sites, where this operator worked, rose 1.4 percent, and the operator could have rented capacity in Frankfurt as easily as in St. Petersburg.
ASN blocklists also decay in the other direction. Prefixes get transferred, re-originated after an acquisition, or returned to an RIR and handed to someone else, so a list of "bad ASNs" written in 2024 is partly a list of networks that no longer carry what they carried in 2024. Every reputation dataset, ours included, lags a transfer by some interval. A hand-maintained blocklist lags it forever.
The useful signal is the type of network, not its number. "This address belongs to a hosting provider" survives the operator moving from Yandex Cloud to Selectel, because the next address is a hosting address too.
What a lookup should return for a hosting address
The replacement for an ASN blocklist is a classification you can act on without collateral damage. For an address like the ones the gambling bot used, a lookup should answer four questions: who announces the route, what kind of organization uses the block, whether the address is datacenter space, and whether anyone has already seen abuse from it. In Ipregistry's response those live in the connection, company and security objects:
{
"company": {
"domain": null,
"name": "Selectel Network",
"type": "hosting"
},
"connection": {
"asn": 49505,
"domain": "selectel.ru",
"organization": "JSC Selectel",
"type": "hosting"
},
"security": {
"is_abuser": false,
"is_attacker": false,
"is_cloud_provider": true,
"is_proxy": false,
"is_residential_proxy": false,
"is_vpn": false
}
}The two type fields are the ones that matter. The connection type classifies the network announcing the route and the company type classifies the organization actually using the block, which on a sub-allocated range can differ from the announcer. The is_cloud_provider flag is the blunt version of the same question, and it is deliberately kept out of is_threat, because a datacenter address is not a threat. It is a datacenter address.
How you use it depends on what the request claims to be. If it claims to be a crawler, verify that claim first with forward-confirmed reverse DNS, since a verified YandexBot or Googlebot runs on datacenter space and should never be caught in a datacenter rule. If it claims nothing, the network type decides the scrutiny: a login from a hosting address gets a challenge, a scraper-shaped request from one gets a rate limit keyed on the fingerprint, and a residential ISP address goes through normal scoring, with is_residential_proxy as the tiebreaker for home lines that behave like datacenters.
One honest caveat. Classifying a block as hosting is itself an inference rather than a registry fact, so a freshly routed Selectel /24 may not carry the label on day one. That is still a better failure mode than a static list that never updates at all.
A checklist for the next time a network goes dark
- Verify crawler claims with forward-confirmed reverse DNS, then allow or deny the crawler by its operator's rules. Never put a verified crawler's range in a datacenter rule.
- Score unverified automation by the type of network it comes from and by its request fingerprint, not by AS number. The operator will change ASN; it will rarely change its tooling.
- Treat country as a weak signal on hosting space. A VM in Moscow and a VM in Frankfurt rented by the same person are the same actor.
- Look the hosting classification up at request time or refresh it daily rather than baking a snapshot into a firewall rule.
- When you do block an entire hosting network, write down why and when, and set an expiry.
The last point is the one most people skip. Cloudflare notes that, on news-site traffic, 40.5 percent of its customers were already returning 403 to YandexBot before the strikes. That is their right, but a Yandex rule almost certainly matched the search crawler and nothing else. The traffic those sites presumably wanted to stop was on a different ASN, and, as the gambling bot showed, it could be on yet another one the next day.
Telling a verified crawler from a cloud tenant from a residential line is what Ipregistry's data is for: each lookup returns the announcing network, the company and connection type, the hosting flag and the proxy and abuse signals for an address, so a rule can key on what the address is rather than on which AS number it sits in this week. You can try it with 20,000 free lookups to get started.
Keep users in the loop Ship release notes that get read. Try Noticeable