After reported Ukrainian drone strikes targeted Yandex facilities in Russia, speculation circulated that the damage had disabled Russian bot farms and influence operations. Traffic charts showed significant declines, leading observers to conclude that malicious actors had been disrupted. Yet aggregate traffic metrics can be misleading. Yandex operates under two separate autonomous system numbers (ASNs): AS13238 handles its search engine, while AS200350 manages cloud services.

Analysis using Cloudflare Radar and Bot Management data revealed that the two ASNs experienced different impacts despite both seeing traffic reductions. Yandex Search (AS13238) lost traffic consisting almost entirely of verified search crawlers indexing web pages, images and site resources. Yandex.Cloud (AS200350) saw declines in malicious activities such as vulnerability scanning and probing, but high-volume automation did not cease—it simply shifted to other hosting providers.

The distinction matters because malicious traffic originating from a particular provider does not necessarily reveal who operates that traffic. Determining why the strikes had limited lasting effect on malicious activity requires examining request behavior patterns rather than focusing solely on overall traffic volume.

The strikes and their immediate effects

Between October 7 and 11, reported Ukrainian drone strikes targeted three Yandex facilities in Russia, progressively taking data centers and network capacity offline. Cloudflare Radar data showed a near-total collapse of the Yandex network on October 11, with traffic dropping to 99% below baseline for Yandex Search (AS13238) and 90% for Yandex.Cloud (AS200350). Following a brief partial recovery, both networks remained disrupted through October 13, settling at 86-90% below normal baselines. As of October 14 at 18:00 UTC, traffic stood at 85% of normal.

A decline in overall HTTP traffic only confirms that a network went offline. It does not indicate whether malicious or evasive bots were affected. Examining the pre-event automation baseline reveals that before the strikes, automated requests represented 36.1% of all HTTP traffic observed globally across Cloudflare's network, and 35.8% of traffic from Russian IP addresses.

The outage produced different consequences for automated activity on the two ASNs because they served distinct purposes.

Yandex Search: search crawling disrupted

The Yandex Search ASN (AS13238) operates for search index crawling. Cloudflare classified 99.5% of its requests as automated, with 93.6% of bot requests marked as Verified. Analysis showed that traffic from this ASN indexed pages, rendered pages and rendered images—behavior consistent with a search crawler. This ASN accounted for approximately 7% of Russia-origin bot requests and just 0.05% of the global total.

The decline on Yandex Search ASN consisted almost entirely of search crawling activity. Sampled requests showed that 78.1% came from verified YandexBot, 11.5% from YandexRenderResourcesBot and 1.9% from YandexImages.

Publishing and Newspapers saw the steepest drop among website categories, with traffic from Yandex networks falling 44%. Approximately 90% of pre-event traffic to news sites from this ASN was YandexBot indexing articles, with 40.5% of Cloudflare customers returning HTTP 403 Forbidden responses because site owners had blocked the crawler. When the Yandex Search ASN went offline, customers simply experienced reduced indexing from Yandex.

Yandex.Cloud: malicious traffic relocates

Yandex.Cloud presented an entirely different profile. Approximately 95.0% of its scored requests were bots, but none of its observed bot requests were verified by Cloudflare. Yandex.Cloud's bots resembled software applications: nearly two-thirds of their requests sent data to websites, some identified themselves as JavaScript, Python or Go programs, and a larger proportion targeted software companies than Yandex's search bots. This ASN supplied about 2% of Russia-origin bot requests and just 0.01% of the global total.

Following the reported strikes, bot traffic from Yandex.Cloud fell approximately 40%. Several attack-like categories showed especially sharp declines. WordPress plugin probing dropped 90% and scanner-identified requests fell 93%. Notably, Cloudflare customer blocks on Yandex.Cloud traffic also fell 70% during the event period, suggesting that proportionately less malicious traffic was even reaching the Cloudflare WAF from this ASN.

The gambling sector reveals the pattern

Yandex.Cloud's bot traffic segmented into two primary industry buckets: computer software and gambling. The computer software category was predictable for an ASN designed to host third-party applications and software integrations. Traffic to this sector succeeded at high rates both before and during the event, pointing to legitimate usage.

The gambling sector provided the clearest evidence that malicious automation relocated rather than disappeared. Nearly all of Yandex.Cloud's bot requests targeted one gambling customer account, with traffic shifting among its hostnames. Immediately following the October 8 disruption, bot requests from Yandex.Cloud to this account dropped to zero. Simultaneously, identical requests began appearing from other Russian hosting ASNs, including Radist and Selectel. The incoming traffic maintained an identical fingerprint across providers:

  • The same JA4 TLS client fingerprint
  • The same uncommon request paths and HTTP headers
  • The same custom User-Agent strings

Russian bot traffic targeting gambling accounts remained essentially flat over the week, moving from 167.7 million to 170.1 million requests (+1.4%). The automation never stopped running; operators simply migrated their workloads to alternate cloud providers once Yandex.Cloud became unavailable.

Social media activity showed no disruption

Analysis of social media traffic found no unexpected changes from Russian-origin IPs (0.6% decrease in total traffic over the event period) or globally (1.2% increase in total traffic over the event period). The same analysis applied to bot traffic hitting the "post", "reply" and "like" endpoints for a specific social media platform similarly showed no unexpected shift from Russian-origin IPs (5.7% decrease in total traffic over the event period) or globally (1.1% increase in total traffic over the event period). Based on this assessment, the data does not appear to support claims that the strikes crippled social media manipulation, though without further analysis using data outside of Cloudflare, no conclusive determination is possible.

What the data revealed and what it did not

When traffic from Yandex networks collapsed, speculation spread that Russian influence operations and malicious botnets had suffered severe damage. Cloudflare data tells a different story: across Cloudflare's network, there was no evidence that the strikes knocked social media manipulation offline or otherwise disrupted malicious activity on the Internet. Instead, the data demonstrated two key findings:

  • Search indexing declined. The overwhelming majority of traffic that dropped from Yandex Search ASN consisted of verified YandexBot crawlers fetching news articles and web assets. The primary impact was reduced content discovery in Yandex Search.
  • Malicious automation migrated instead of stopping. While vulnerability scanning and plugin probing temporarily dropped on Yandex.Cloud, high-volume operations quickly moved to alternative hosting networks.

A network disruption means that specific servers stopped sending requests, but it does not mean an automated threat disappeared. Cloud workloads are portable, so when a data center goes dark or an IP prefix gets blocked, operators can migrate their scripts to another provider in hours.

This analysis demonstrates that client ASN traffic volume is an unreliable indicator for interpreting automated bot behavior. Defending against automated threats requires inspecting request behavior, such as identifying shared JA4 fingerprints, monitoring anomalous request rates and applying WAF rules to sensitive endpoints, regardless of which network the request originates from. Physical infrastructure is static, but malicious automation is built to move.