Real Phones, Sensors and IP,
But One Number Never Moved

I. Where the real story hid

Some investigations start with a shrug.

A client of mine, a fast-growing online marketplace platform, flagged a batch of new accounts that had crossed our desk with nothing technically ‘wrong’ on paper — valid hardware, real IP addresses, phone numbers that checked out with device sensor readings moving the way a hand actually moves a phone; not the flat, mechanical drift we see from scripts.

The client’s existing bot-detection vendor had grouped a chunk of this traffic under one shared device ID and called it solved. That’s when they brought us in. 

But when I pulled the same transactions, I got something different: distinct IP ranges and user agents. Every marker that usually tells two accounts apart was telling me these were different phones.

“One vendor’s conclusion versus what our signals actually showed. That gap is where the real story was hiding.”

A device farm built on emulators fails hard the moment you look for virtualization artifacts. This wasn’t that. What we were looking at was real, physical Android hardware, sitting in a rack somewhere, being operated remotely by someone who had never touched it. The other vendor wasn’t wrong that the traffic was connected, but they were wrong about why. They’d clustered it on behavior, not identity and called a probability a device ID. Close enough to catch attention, not close enough to hold up.

II. Too boring to matter

I then stopped asking whether any single device looked fake and started asking what an unrelated-looking population of devices might share that none of them would reveal on their own.

I lined up the accounts and started checking for anything static across sessions that had no business being static. An unsecured keyguard, again and again. The same Wi-Fi network name, on devices that had never been near each other. And then a number I almost scrolled past because it looked too boring to matter.

Every device in the cluster reported its screen brightness at exactly the same percentage. Not close to the same number or clustered around it. The identical reading on accounts registered days apart, behaving differently, with no reason to know about each other.

“One phone at a specific brightness percentage is nobody’s business. A population of them, locked to that value with zero variation, stops being a coincidence and starts being a fingerprint of the thing that built them.”

I tested it under high-volume traffic on other platforms to rule out the possibility that the brightness percentage was just a common setting in a large sample. It wasn’t. Elsewhere, that exact reading showed up only in scattered, low-reputation devices, the kind of noise you’d expect from chance. Here, it was everywhere.

III. Tiers of the same farm

Then I went and rented time on a known cloud device farm provider myself. I got the same static screen brightness reading every time. This was not a preference I had set. It was a default that the platform never allowed fraudsters to change.

That’s when the shape of it came together. This wasn’t one device farm. There were tiers of them. The cheaper ones failed our integrity checks outright, which is exactly why some of the suspicious transactions showed obvious signs of tampering. The more expensive ones preserved real Android integrity almost perfectly and left us almost nothing to catch device by device. Both tiers left the same tell behind at the population level, because neither builder had bothered to make brightness configurable.

Digging into how these devices were provisioned turned up something bigger than the immediate case. The same underlying service that spun up these devices came with a built-in marketplace for account creation at scale, and this platform wasn’t its only listed target. Other major consumer apps were sitting right there in the same tool. This wasn’t a bespoke attack built for one client. It was commercial infrastructure, sold and reused, and the accounts I was looking after were one customer among many.

IV. Depth, breadth, and complexity

A frequency table and a number that refused to move is what actually broke open the case, and it only worked because I widened the lens from one device to the population behind it.

Advanced device farm tiers preserve real hardware integrity well enough that any vendor relying on individual-level detection alone will miss them. That’s why population-level signal analysis exists.. Persistent device identifiers — the backbone of fraud-detection tooling — struggle against infrastructure engineered to reset itself in one click. The population view is often the only place left to look, and even that only works until the provisioning gets smart enough to randomize the one setting that gave it away.

That’s the part worth sitting with longer than the win.

“Somewhere in your own traffic right now, something is probably built to pass every single device check, on purpose. The question is whether your signal depth is deep enough and breadth across dimensions goes beyond the single device.”

Detection at this level isn’t about a better single check. It’s asking what an entire population of clean-looking accounts might share that none of them would ever give up in isolation.

Every risk decision is only as good as the depth, breadth and complexity of the signals behind it.