A source network goes offline, and a monitoring graph drops sharply. Is that enough to conclude that suspicious requests to your website have subsided?

Cloudflare’s Yandex outage analysis, published on October 14, 2026, offers a useful case for examining that decision. Operating a web service means tracking both changes in request origins and changes in access to the functions you protect.

With that distinction in place, we can connect JA4, a fingerprint of TLS characteristics, and request logs to a more useful assessment of whether activity has stopped.

Search crawling and cloud traffic give a network decline different meanings

The decline from Yandex Search’s AS13238 was almost entirely search crawling. For one gambling customer, requests from Yandex.Cloud’s AS200350 stopped, then appeared from other hosting networks with matching JA4, distinctive paths and headers, and custom User-Agent strings. Cloudflare’s observations indicate that automation moved.

Automation and abuse require separate judgments. Cloudflare’s bot score ranges from 1 to 99 and expresses how likely a request is automated. A low score alone does not determine whether your service should reject it.

An allowed search crawler and a script repeatedly attempting unexpected operations need different treatment. Alongside where requests originate, distinguish what those requests are doing.

JA4 groups TLS characteristics to help correlate requests

When origins change, characteristics associated with client implementations and settings remain useful comparison points. JA4 extracts a fingerprint from the ClientHello sent at the start of a TLS connection.

The FoxIO JA4 specification uses information including TLS version, cipher and extension counts, and ALPN. It also sorts and hashes lists such as cipher suites. Because the fingerprint does not identify clients by source IP, it can help compare requests whose source addresses differ.

Its inputs do not establish a user’s identity. The design also means separate clients with matching connection characteristics can produce the same value. Combine destination paths, HTTP methods, headers, and timing to narrow down potentially related requests.

Treat a JA4 match as a starting point for investigation. It cannot, by itself, identify an attacker or operator.

Compare the same destination across ASNs

One way to apply this lesson is to fix the endpoint under investigation first. Compare equal time windows before and after a disruption, count requests to that path across all ASNs, and then examine the origin breakdown. This is a proposed monitoring approach derived from the incident.

For example, if an investigation filtered requests to a particular ASN, remove that filter while retaining the distinctive path and User-Agent, plus JA4 where available. The question becomes whether matching traffic is arriving elsewhere as it declines at the original source.

Cloudflare’s JA3/JA4 documentation describes using fingerprints in analytics and logs. Cloudflare provides these fields to Enterprise customers who have purchased Bot Management. Values can be absent, including for non-TLS traffic, so counting only rows with JA4 leaves some requests outside the analysis.

Keep requests without JA4 in a separate group and continue comparing paths, methods, and User-Agent values. Build monitoring around the fields available to you; a missing fingerprint is not evidence that suspicious traffic is absent.

Narrow enforcement after checking overlap with legitimate traffic

Once related traffic is identified, decide the scope of enforcement. Cloudflare’s Bot Feedback Loop guidance discusses combining characteristics such as IP, JA3, ASN, and User-Agent. It advises checking for legitimate traffic using a JA3 fingerprint before blocking or rate-limiting it.

For JA4, too, inspect activity at the destination before broadly blocking a TLS characteristic. At a login endpoint, for example, you could correlate a request group with authentication successes, failures, and frequency, then narrow conditions to avoid disrupting normal usage. This is a service-specific decision using application logs, rather than a universal rule configuration.

The incident analysis covers traffic visible on Cloudflare’s network. It does not establish the full extent of social-platform activity or the identities of operators. Keep those observational limits in mind when interpreting your own logs.

Returning to the opening question, a falling origin graph provides insufficient evidence to end a response. Track whether suspicious operations against protected endpoints have declined and legitimate use remains available. That makes the decision less dependent on where requests happen to originate.

Source

• Title: Yandex outage: Data shows that instead of going dark, malicious bots went on the move
• URL: https://blog.cloudflare.com/yandex-outage/