What is Credential Stuffing – and How to Defend Against it

1. Perform recon of a target and its APIs – attackers stealthily scan and collect information about their targets, often selecting their victims based on data or functionality that is of high value or brand recognition. Information gathering includes IP address ranges, registered domain names, hosting application servers and exposed API endpoints. Attackers will also reverse engineer the web and mobile application client code to better understand how to interact with back-end APIs.

2. Compile a dataset of pilfered credentials – an attacker pulls together large sets of credentials that were once known to be working and typically harvested from prior data breaches, credential stuffing campaigns, and ATO successes. These credentials become the inputs into automation tooling and serve as the authentication material for a target API endpoint.

3. Configure automation tool with throttling – an attacker sets up an automation tool of choice or creates scripts. The configuration depends on a number of factors including how unique the target API endpoints are, the level of integration an attacker needs for other attack tooling, or simply the attacker’s own preference. Attackers additionally configure the automation tooling to evade detection and lockout thresholds. Steps include mimicking legitimate user agent metadata, avoiding use of multi-threading, and attempting logins once per minute. Note that automation tooling – when configured properly – looks and behaves much like that of typical and sanctioned business activity.

4. Launch attack against the login API – once attackers have configured their automation tools with all the appropriate pre-requisites, they launch their attacks against the login mechanism. It may take some time to uncover a working credential for the login, depending on the age and validity of the dataset of pilfered credentials the attacker is using. Attackers will likely launch multiple instances of the automation tool from different network locations (such as in a cloud provider) and often geographically distributed to speed up the process and further evade detection.

5. Track login credential successes and failures – an attacker must track the successes and failures across all instances of the attack automation tooling. This correlation may be as basic as checking logs for success codes after the fact, but most attackers will configure or code these results into their automation tooling so as not to waste time attempting further logins. Once the attacker has obtained a working login, this outcome is technically the point of ATO. An attacker will then likely pivot in the attack campaign, obtain an authenticated session via the login API, and then continue to exfiltrate data, escalate privileges, or further abuse functionality.

*** This is a Security Bloggers Network syndicated blog from Salt Security blog authored by Michael Isbitski. Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)