Figure 1: Credential Stuffing cashout kill chain (Source: Radware)
Statistically speaking, the vast majority of malicious bot attacks across the web are driven by credential stuffing attacks, as threat actors use breached credentials to take over accounts of credential-recycling users.
Cashout is the most common outcome of account takeover – when a freshly breached account is drained of all its assets (balance, Gift cards, Loyalty points/miles). Since those assets are at their yearly peak during the holiday season (Nov-Dec), credential stuffing and cashout attacks are also at their yearly peak.
From a CTI research perspective, a successful bot’s Account-Take-Over-cashout attack is rarely a single, isolated event. It is a carefully orchestrated campaign. From a defender's perspective, this single campaign can manifest as five distinct, seemingly unrelated events across DevOps, security, and finance departments.
The finance department may observe a rise in chargebacks, the security team a spike in login failures, and the DevOps team unusual probes to a mobile API. Frequently, these are all connected.
This post will deconstruct the credential-stuffing threat landscape by analyzing five key events, “attack traces” your security team sees but probably won't notice. We will connect these dots, from pre-attack reconnaissance to post-attack fallout, to provide a clearer view of the operations.
Event 1: The 'Bypass' - Reconnaissance of Defenses
- What: Network and application testing on your login page and APIs
- Who: The "Attack Script Developer"
- Why: To perform pre-attack research and gather intelligence on your detection mechanisms
This is the reconnaissance phase. Before launching a large-scale attack, threat actors must understand the defenses. An Attack Script Developer, who specializes in building automated tools, will probe your login pages and APIs to gather intelligence.
They seek to answer critical questions:
- Does this application block data center IPs? Does it use an IP reputation service? Which one?
- What are the rate-limiting thresholds?
- What type of CAPTCHA, JS challenge, or any other bot detection is in place?
- Which type of device has the least protection in its authentication process? PC, mobile, or API?
This activity often appears as anomalous, low-and-slow traffic. The objective is to gather the necessary intelligence to build a script that can successfully bypass defenses. This script is a critical component for Event 3.
Event 2: The 'List' - Building the Target List
- What: User validation attempts against registration and password reset flows.
- Who: The "Account Cracker" – the threat actors who buy the attack script and execute the attack.
- Why: To validate which accounts exist on the platform and create a "Valid victim list" – before the attack.
Attackers often acquire large "combo lists" (email: password) from third-party data breaches. However, they must first determine which of these credentials belong to an actual account on your service.
To do this, the "Account Cracker" (the bot operator) performs user enumeration. Attacking the login page directly is often "noisy" and risks early detection. Instead, they commonly use your registration and password reset flows as an "oracle." They attempt to register an account with a stolen email, and the application helpfully replies, "An account with this email already exists."
This "information leak" is the primary objective of this phase. The attacker adds that validated email to their "Valid victim list," which will be used in the main attack.
Event 3: The 'Breach' - The Credential Stuffing Attack
- What: A massive spike in sign-in attempts, often targeting your mobile API.
- Who: The "Account Cracker".
- Why: Taking over user accounts at scale.
This is the primary attack phase. Using the "bypass" script from Event 1 and the "Valid victim list" from Event 2, the Account Cracker launches a high-volume, automated credential stuffing attack.
Mobile APIs are a preferred target vector for several reasons:
- They may be legacy versions with weaker security controls.
- They might be managed by different teams, creating gaps in security policy.
- They often lack the robust CAPTCHA and bot protection present on web-based login pages.
This is precisely why the reconnaissance in Event 1 was so important. The attacker identified this weaker entry point and is now exploiting it to test thousands of credentials per minute.
Event 4: The 'Sale' - The Cybercrime Hand-off
- What: A successful login, often from a new or unusual location.
- Who: The "Account Buyer".
- Why: Cashing out (monetizing) the account.
This step highlights the specialization within the cybercrime economy. The "Account Cracker" (Event 3), who breaches the accounts, rarely monetizes them. Instead, they package the validated, working credentials and sell them on a dark web marketplace.
A different actor, the "Account Buyer," purchases the guaranteed-access account. This individual logs in methodically to monetize the account before it is discovered. Common tactics include:
- Purchasing digital gift cards (which are fast, anonymous, and difficult to trace).
- Manipulating shipping addresses to reroute physical goods.
- Making multiple small transactions to remain just below automated fraud detection thresholds.
Event 5: The 'Fallout' - The Lagging Indicator
- What: A spike in charge-back rates.
- Who: "The Victim" (the legitimate user).
- Why: The user is reporting unauthorized transactions.
This is the final, lagging indicator of the attack. The fraud is discovered by the actual user, who contacts their bank to report the unauthorized transactions. For business, this appears in the finance department as a sudden, costly spike in chargebacks.
By the time this occurs, the financial damage is already done. The cost is not just the chargeback fee-it includes the loss of goods, the reputational damage to the brand, and customer churn from a loss of trust. Furthermore, your payment processor may now classify you as "high-risk," which could increase your transaction fees on all future transactions.
Correlating the Events: A Unified Attack Chain
What appears as five separate issues is, in reality, one continuous kill chain.
- An Attack Script Developer (Event 1) performs reconnaissance to find vulnerabilities.
- An Account Cracker (Event 2) validates user accounts to create a target list.
- The Account Cracker (Event 3) uses the script and the list to execute the high-volume attack.
- An Account Buyer (Event 4) monetizes the compromised account.
- The Victim (Event 5) reports fraud, leaving the business to manage the consequences.
An effective bot mitigation strategy must have visibility across this entire chain. It should not just block the final attack but also correlate these seemingly unrelated events. Detecting reconnaissance (Event 1) and enumeration (Event 2) is key to breaking the attack chain before the cashout occurs.