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.
Dr. Anton Chuvakin, security advisor at Office of the CISO, Google Cloud, joined our recent API Security Summit. Dr. Chuvakin’s session – co-hosted by Salt Security's Michelle McLean – provided an in-depth discussion on why API security has become a “now” problem.
The monetary growth opportunities promised by APIs are immense, but to harness them, CISOs must ensure the protection of their APIs.
With the industry moving to microservices and API-driven applications, new security threats and attack vectors have emerged. The PCI Security Standards Council has worked to address these threats in its newest PCI DSS 4.0 standard.