Detect account takeover before it succeeds by instrumenting the browser and device during the attack's setup phase, not after the account is drained. The signals that matter early are different from the ones you check after a breach: headless and stealth-browser tells, fingerprint drift against an account's history, residential-proxy behavior, and login velocity that no human hand produces. One signal rarely proves intent. A pattern of them does, and you can see that pattern before the attacker monetizes anything.
Most ATO programs are post-hoc. They confirm fraud after a password reset, an address change, or a payout. Pre-ATO detection moves the decision earlier: catch the credential-testing run, the first login from a spoofed environment, the session that authenticates cleanly but carries automation fingerprints. Server logs show that a login happened. Browser signals explain whether the thing logging in is plausibly your user. cside captures those runtime signals (device, real IP, automation posture, and third-party script behavior) and exposes them as session risk you can act on before checkout.
What "before it happens" actually means
ATO has a setup phase. Attackers test stolen credential lists, probe your login endpoint, and stage automation before any single account falls. Each of those steps leaves browser-layer evidence that a network-only view never captures.
| Phase | What the attacker is doing | Pre-ATO signal to capture |
|---|---|---|
| Reconnaissance | Probing login and recovery endpoints | Request velocity, endpoint fan-out, automation tells |
| Credential testing | Running stuffing lists through real or stealth browsers | Headless tells, fingerprint reuse across accounts, proxy rotation |
| First foothold | A clean login from the wrong environment | Fingerprint drift, new-device event, impossible velocity |
| Pre-monetization | Sitting on the session before acting | Session continuity break, behavioral mismatch |
The point is to act in the first three rows, not the fourth.
Browser automation tells that fire before the foothold
A generic detection rule misses this layer. Automated takeover increasingly runs through real browser engines driven by frameworks, not crude scripts. The tells are specific and observable at runtime, and most of them are the same signals that give away AI agents and stealth browsers.
navigator.webdriverset totrueis the honest default of a controlled browser. Serious attackers patch it, so its absence proves nothing, but inconsistency between it and other surfaces is itself a signal.- Chrome DevTools Protocol (CDP) artifacts. Frameworks that drive Chrome over CDP can leak detectable runtime side effects; a session that exposes CDP-driven evaluation behavior while claiming to be a hand-driven browser is contradicting itself.
- Headless property gaps. Classic headless Chrome ships with missing or stubbed APIs, zeroed plugin arrays, and permission states that do not match a real install. Stealth kits paper over the well-known ones, which creates a new tell: surfaces that are too clean and uniform across thousands of "different" users.
- Stealth-kit fingerprint uniformity. When a leaked password list is tested through one automation profile, hundreds of accounts get touched by browser environments that are improbably identical. Reuse across accounts is the signal, not any single attribute.
cside research found that installs of playwright-stealth, one of many stealth-browser kits used to dress automation up as a human browser, climbed roughly tenfold over 2025 (per the cside Future of Web Security 2026 report). That is the tooling showing up in front of your login form. Detecting it lets you block a credential stuffing run instead of reading about it after the chargebacks land.
Fingerprint drift on real accounts
Once an attacker has a working password, the first authenticated login is your next window. A returning user carries a consistent device and browser fingerprint over time. A takeover login usually breaks that baseline.
Drift is not one field changing. People upgrade browsers and buy phones. Drift becomes a signal when several stable surfaces shift at once, against an account that has been consistent, in a way that does not look like a normal upgrade.
- Build a per-account baseline from known-good sessions: device, OS family, browser, rendering surfaces, timezone, language.
- Score the delta on each login, not the absolute fingerprint.
- Weight surfaces that rarely change for a real user higher than ones that drift naturally.
- Combine drift with network and velocity context before you challenge.
The caution from adversary-in-the-middle phishing is real: a kit that replays a victim's cookies can also mirror fingerprint surfaces, so a clean match is not proof of a clean user. Treat fingerprint match as one input alongside reputation and behavior, never as a standalone allow.
Network behavior: proxy, VPN, and velocity
Attackers hide origin behind residential proxy pools and commercial VPNs to defeat IP reputation. The defense is behavioral, not a static blocklist.
- Residential-proxy rotation. A single account or campaign exits from many residential IPs in a short window, sometimes one per request. Real users do not rotate egress that way. The rotation pattern is the tell, even when each individual IP looks like a clean home connection.
- VPN and datacenter egress. A login arriving from a hosting ASN, or from a VPN range correlated with prior abuse, raises risk as context, not as a hard block, because legitimate users use VPNs too.
- Login velocity. Bursts of attempts per account, or one environment touching an unusual number of accounts, mark credential testing before any single login succeeds.
- Impossible velocity. The same account authenticating from locations too far apart for the elapsed time points to shared or stolen credentials in active use.
Capturing the real client IP at the browser layer matters here. A request can ride through a proxy that rewrites or omits forwarded headers, leaving server logs with a misleading source. Browser-side capture gives you the egress the session actually used.
Why this is a browser-layer job
The login page itself is an attack surface, and it is often where takeover begins, before any credential is even tested. A compromised first- or third-party script on your login page can skim credentials as the user types, or overlay a spoofed form, with nothing reaching your server as anomalous. That is e-skimming pointed at authentication instead of payment.
So pre-ATO detection has two halves. Watch the attacker's environment for automation and drift tells. Watch your own page for tampered scripts that turn a legitimate user's login into a credential leak. Both live in the browser at runtime, and both are invisible to a WAF or server log. cside instruments the page and the session together: real-time third-party script and behavior monitoring, AI-agent and headless detection, device and real-IP capture, and runtime payload visibility, delivered as signals over an API your fraud logic can consume. For the page-integrity side of that picture, see client-side security.
Operating plan
- Instrument the login and recovery endpoints for browser-layer signals, not just server auth logs.
- Detect automation posture on every attempt: headless tells, CDP leaks, stealth-kit uniformity.
- Score fingerprint drift against a per-account baseline instead of matching absolutes.
- Add residential-proxy behavior, VPN/datacenter context, and velocity as risk inputs.
- Challenge or step up risky sessions before account changes, payouts, or checkout.
- Feed challenge outcomes back into the baseline so the model sharpens over time.
The goal is a confident decision built from weak signals that compound, early enough to challenge the session, not just document the loss.
