10 Nov 2026, 15:31 - Suspicious Traffic Claiming Referral From aocr.org

Starting in late September, large quantities of traffic purported to be referred from https://www.aocr.org/ began appearing in site analytics across the web. This is not traffic from the eponymous American Osteopathic College of Radiology but is instead of a more nefarious nature. Usually I see no note of bot traffic in my site analytics, but this specific case managed to get through many sites’ defences and muddy the data. Some investigations have been performed, but most are seemingly AI slop feeding off each other, so I’ve combed through logs, run my own tests, and conducted a small survey to get some traffic analytics from various people.

It is first important to note that a referrer is not a verified value in any way. Anyone can put anything in the Referer header with no need to prove that it is actually coming from the location specified. This suspicious traffic doesn’t appear to be scoped to a specific type of content, as I can find referrals in the analytics of seemingly completely unrelated websites.

With a small number of outliers, the traffic associated with the referrer has these identifiable properties:

extensionTiming
    forestResFrom
    forestResLoadStart

htmlPredictorHit

These properties have similarities with ByteSpider – the web crawler operated by Chinese company ByteDance – but it is not the same and is not entirely consistent. The browser in use is, however, almost certainly of ByteDance origin. ByteDance has a cloud computing arm called Volcano Engine (火huǒ山shān引yǐn擎qíng) which offers browser-as-a-service functionality within China. The global version is BytePlus, which I poked around to understand their browser. Most importantly, BytePlus’ browser is extraordinarily similar to the browser sending these aocr.org referral traffic. It is a full browser that executes JavaScript, which is generating this traffic, and not just performing a fetch. This is probably a large part of why it showed in so many sites’ analytics – it executed the analytics scripts.

As for the timing field values, forest most likely refers to a resource loader developed by ByteDance, which we can find mentioned in the code of the cross-platform framework Lynx, which is used for applications like TikTok. The exact forest strings are absent from BytePlus’ browser-as-a-service, which is the most glaring disparity, though ByteDance-specific fields are present. The Accept header is also distinctive. It is identical to stock Chromium’s with the exception of advertising image/heif support, which stock Chromium doesn’t. The only browser at time of writing to have support for the format is Safari, so it is odd for it to be included. This is further evidence suggesting that ByteDance’s Browser-as-a-service is in use. I’m inclined to believe this aocr.org traffic is using a newer version which is perhaps provided somewhere unknown to me. This age difference is corroborated by the Browser-as-a-service having a ClientHello message that is 512 bytes, X25519 only, while this aocr.org referrer is 1,722–1,818 bytes, PQ class, which is more in line with newer browsers.

Across all sites with traffic from aocr.org, I’ve found a small spike around October 27^th-30^th and a significant spike on November 5^th/6^th where the same pages were fetched multiple times. The majority of traffic is from United States IPs, with Brazil as a follow-up and a wide variety of countries beyond that. The IPs are from a wide array of data centres and residential addresses, though these are proxies and the browsers are almost certainly running in China due to that being the only region ByteDance’s browser-as-a-service supports.

There is no obfuscation or attempt to rotate the referrer. It is extremely predictable and consistent with the only thing that seems to change being the origin IP with occasional small variation in the user agent. A genuine page referral from a clicked link will also have a Sec-Fetch-Site of cross-site, not none as the spider provides. Having no referrer header would likely have seen the request blocked, though had they cycled referrers, many people probably wouldn’t have noticed.

I’m left with four questions I cannot answer to a satisfactory degree:

• Why choose aocr.org? Likely because it is an established, non-commercial, old domain (registered 1999) that seems innocuous at first glance? It is in the Majestic Million and Tranco lists, so it was probably chosen at random from there.
• Why not change referrers to avoid arousing suspicion? Unless the goal is to arouse suspicion for some purpose or to identify sites which fail to react and implement protections. Or it could have been a value mistakenly hard-coded, set as a variable, or forgotten as a default.
• Who is running this? Is it a single entity or are there many parties involved? Given the scope of the scraping and how many different servers and proxies are used, it seems unlikely to be more than a single controlling party.
• What is the purpose? I’m inclined to put forward AI scraping, as advertising fraud or traffic laundering don’t make sense. AOCR aren’t trying to get clicks from curious webmasters, and the affected sites haven’t paid to receive traffic.

• #SEO/GEO/AIO