- Cloudflare found bot traffic aimed at one gambling customer reappeared on other Russian hosts after reported Yandex strikes. Russian bot traffic targeting gambling accounts stayed essentially flat (+1.4%).
- A network going dark shows the network failed. It does not show that the automation behind the traffic stopped.
- Ask whether your bot defences track behavior, such as fingerprints and request rates, or rely on which network a request comes from.
When a data center goes dark, it is tempting to believe the attackers inside it went dark too. The Yandex outage shows why that belief is risky. A network can fail while the work running on it simply relocates. The lesson for security leaders: an address tells you where a request came from, not who is behind it.
What was claimed, and what Cloudflare measured
Cloudflare reports that Ukrainian drone strikes reportedly hit three Yandex facilities in Russia between October 7 and 11. The low point came on October 11. Against its normal level, Yandex's search network (AS13238) carried 99% less traffic. Its cloud network (AS200350) carried 90% less. An ASN is a number that identifies a network run by one organization.
Online, many people read those steep charts as proof that Russian bot farms and influence campaigns had been shut down. Cloudflare tested that idea against its Radar and Bot Management data. Its point is narrow: falling volume shows a network failed, but says nothing about whether harmful bots were affected.
Two networks, two very different jobs
The two Yandex networks carried different kinds of automation. Cloudflare classified 99.5% of requests from the search network as automated. Of those bot requests, 93.6% were verified, meaning Cloudflare could confirm the legitimate crawler sent them. The drop there was almost all search crawling. The verified YandexBot made up 78.1% of sampled requests.
Yandex.Cloud is a hosting network that rents computing power to outside customers. Roughly 95% of its scored requests came from bots. Cloudflare could verify none of them as legitimate.
Cloudflare says these bots behaved like software applications. Close to two thirds of their requests pushed data to websites. Some named JavaScript, Python or Go as their client.
The gambling traffic that stepped sideways
Some malicious activity did fall on Yandex.Cloud. Probing for WordPress plugins dropped 90%. Requests flagged as scanners dropped 93%. Customer blocks on this traffic fell 70%. Bot traffic from the network fell about 40% overall.
The gambling sector told a different story. Nearly all of Yandex.Cloud's bot requests aimed at a single gambling customer account. After the October 8 disruption, those requests fell to zero.
At the same moment, identical requests began arriving from other Russian hosting networks, including Radist and Selectel. The new traffic matched the old in detail. It used the same rare URL paths and the same HTTP headers, the labels a client sends with each request.
Now look at the wider picture. Russian bot traffic targeting gambling accounts barely changed over the week. It went from 167.7 million requests to 170.1 million. Cloudflare concludes that the operators moved their workloads once Yandex.Cloud became unavailable.
Why moving is so easy
Cloud workloads are portable. A script that runs on one rented server runs on another with little change. Cloudflare notes that relocating can take only hours after a data center fails or an address range is blocked.
Think of a street market that closes after a flood. The vendors do not retire. They set up their stalls on the next street. If your security plan counts the empty stalls, it will report success while the same customers are served nearby.
What the data does not show
Cloudflare checked social media traffic too. From Russian IP addresses, total traffic changed by -0.6%. Globally it rose 1.2%.
Bot traffic to the posting, reply and like endpoints of one platform fell 5.7% from Russian IPs. It rose 1.1% globally. Cloudflare says this does not support the claim that the strikes crippled social media manipulation.
The company adds a limit. Without data from outside its own network, it cannot rule out a connection. The findings also cover only the traffic Cloudflare sees. Yandex.Cloud supplied just 0.01% of global bot requests, so this is a close look at one slice.
Questions for your security team
First, do your bot rules lean on network reputation, such as blocking or scoring by hosting provider? If so, ask what happens when the same traffic arrives from a different provider tomorrow.
Second, can your tools recognize a repeat client by behavior? Cloudflare points to shared JA4 fingerprints, which describe how a client sets up its encrypted connection. It also points to unusual request rates and WAF rules on sensitive endpoints. These work whatever network the request comes from.
Third, which of your endpoints would a patient operator target first? Logins, checkout and posting paths deserve rules that do not depend on where the request originates.
Servers sit in one place. Automated threats are written to travel. Defences should be built the same way.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
