What does account takeover bot traffic look like in a store's logs?
Credential stuffing gets the headlines, but account takeover is the quieter, more expensive cousin: bots test stolen credentials slowly, verify the good ones, then monetize the accounts. In the logs it looks less like an attack and more like a crowd of forgetful customers, until you check the timing.
The slow probe phase
Account takeover campaigns start with patience. Unlike credential stuffing, which hammers the login endpoint with thousands of attempts per minute, ATO probes dribble in: a few login attempts per IP per hour, spread across residential proxies, each using a different username and password pair from a breached credential list. In the logs, this looks like normal failed logins. The failure rate is elevated if you aggregate, but no single IP trips a rate limit, and no single hour looks alarming.
The tell is in the patterns across the noise. The usernames are email addresses from breach compilations, not your customers guessing passwords. The timing is metronomic: attempts spaced evenly, twenty-four hours a day, including hours when your human login traffic is near zero. The user agents rotate through a small set of plausible browser strings rather than the long tail of real browsers. And the attempts never include the behaviors real failed logins have: no password reset requests, no second attempts with a corrected password, no navigation to the account page afterward.
This phase can run for weeks. The operators are in no hurry, because the credentials are free and the probing is cheap. They are building a list of valid username and password pairs for your store specifically, and they will only move to the next phase once the list is worth monetizing. Most stores never notice this phase at all, which is exactly why it works.
The verification burst
When a credential pair works, the behavior changes immediately. The successful login is followed within seconds or minutes by a burst of account activity: profile page views, order history checks, saved payment method views, address book reads. In the logs, this is a sharp discontinuity: months of quiet probing, one success, then a flurry of authenticated requests from the same session. The operator is verifying the account's value before deciding what to do with it.
What they do next depends on the store. On stores with saved payment methods, the burst may include small test purchases or changes to the account email, locking the real customer out. On stores with loyalty points or store credit, the points get drained, often transferred or spent within the hour. On stores with subscription management, the shipping address gets changed. Each of these leaves a distinct log signature: authenticated actions that no legitimate customer performs in that sequence or at that speed.
The timing of the burst is also diagnostic. Real customers who log in successfully browse, hesitate, compare, and come back later. ATO sessions compress the entire account lifecycle into minutes: login, inventory the account, extract the value, move on. Session duration and action density separate the two populations cleanly. A legitimate session with forty pageviews in three minutes is rare; an ATO verification session looks exactly like that.
How to separate it from real customers
The practical detection rule combines three signals: login success after a history of distributed failures from related infrastructure, immediate high-density account activity post-login, and value-extraction actions like email changes or point redemptions. Any one of these has false positives; all three together are nearly always account takeover. Build the rule as a sequence, not as individual thresholds, because the sequence is the signature.
Response should be staged. On the first strong signal, step up authentication: require re-authentication or a verification code before any value-extraction action, like changing the account email or spending points. This stops most ATO in its tracks without punishing legitimate customers, because legitimate customers can complete a verification step and bots usually cannot. Reserve account lockout for confirmed cases, and always notify the real customer through a channel the attacker cannot intercept.
Finally, feed what you learn back into the probe detection. Every confirmed ATO gives you the infrastructure fingerprints, the credential patterns, and the timing signatures of that operator's probing phase. Blocking the next campaign's probes is cheaper than catching its verification bursts. The stores that handle ATO well treat every incident as training data for the quiet phase, because the quiet phase is where the next attack is already underway.
Frequently asked questions
What does account takeover bot traffic look like in logs?
Bursts of login attempts across many accounts, often from rotating addresses, with high failure rates and unusual locations or devices. Credential stuffing runs look automated and repetitive compared with normal customer sign ins.
Why do bots target customer accounts on stores?
Saved payment methods, stored addresses, loyalty points, and gift card balances make retail accounts valuable. A compromised account can be used for fraud or resold, which is why login pages need monitoring, not just checkout.
What should a store do if login attempts spike?
Rate limit and challenge the suspicious traffic, check for successful logins from the same sources, force password resets where compromise is plausible, and notify affected customers clearly. Preserve the logs, because they are your record of what was attempted and what succeeded.