Ten Masks, One Actor

When Trusted Names Become Cover

Research Note · June 24, 2026 · BotConduct Observatory

On June 24, 2026, something visited one of the properties we monitor. It stayed for five minutes. It made about thirty requests. And it arrived twelve different times, as twelve different visitors.

Or so it appeared.

The names it used were not invented. They were the names of real, established companies:

OpenAI. Perplexity. Apple. Google. Microsoft Bing. Amazon. Yandex. Baidu. DuckDuckGo.
Twelve trusted identities. One actual source. Five minutes.

What It Did

The visit had two faces.

On one hand, it browsed the site like any legitimate service would. It downloaded research articles. It read public pages. It fetched a PDF briefing. Normal behavior for a search engine or an AI service indexing content.

On the other hand, between those normal-looking requests, it systematically probed for sensitive files. Configuration files that might contain database passwords. Version control metadata that might reveal internal code. API endpoints that might expose application secrets.

It checked five different variations of the same configuration file. Then it moved to version control. Then to application internals. Each probe used a different company name, so no single name appeared more than once or twice.

This interleaving was not accidental. A sequence of pure probes would look suspicious. By mixing them with legitimate page requests and rotating the name on each one, the entire session appears to be twelve brief, innocent visits from well-known companies.


Why No One Would Have Noticed

Every request, looked at individually, seems unremarkable.

A request from what appears to be OpenAI to a configuration file that doesn't exist? Returns an error. Logged, ignored, forgotten. A request from what appears to be Perplexity to an API endpoint? Same result. No file was accessed. No data was exposed. No alarm was triggered.

But step back and look at the full picture: one source, pretending to be twelve different trusted companies, systematically working through every common location where organizations accidentally leave passwords, API keys, or internal configurations exposed.

The probes all came back empty — nothing was found. But the actor doesn't know that in advance. It runs this sequence against thousands of sites. On a small percentage, something will be there. An application configuration file left accessible after a deployment. A version control directory not properly restricted. A backup file with credentials in the name.


The Question That Matters

The property we observed had nothing exposed. Every probe came back empty.

But here is the question for any organization:

Would you have known this happened?

Twelve visits from twelve recognized names. Each one making a request or two. Each one receiving a normal error response. Nothing in your security dashboard. Nothing in your incident log. Nothing in your weekly report to the board.

The reconnaissance was real. The mapping was systematic. And it was completely invisible to every tool that identifies visitors by the name they declare.


What This Tells Us

When someone knocks on your door and says "I'm from Google," most systems let them in. When twelve different visitors arrive in five minutes, each claiming to be from a different well-known company, most systems see twelve separate, legitimate visits.

The only way to see what actually happened is to stop looking at the names and start looking at the behavior. Not who they say they are — but what they do, in what order, and how fast.

The name on the door can be borrowed.
The behavior in the room cannot.
This observation is based on production data from the BotConduct Observatory. No active testing was performed against any property. Infrastructure attribution is based on publicly available network data.

BotConduct Observatory — botconduct.org