Credential stuffing is a cyberattack in which exposed usernames and passwords are used to gain fraudulent access to user accounts through large-scale, automated login requests. High account usage, password reuse, and vast volumes of breached credentials on the dark web create the perfect storm for cybercriminals to carry out credential stuffing campaigns, while tactics used by malicious actors make identifying and preventing credential stuffing attempts a significant challenge for organizations.
Adding to pressures is the fact that attackers purposely disguise credential stuffing to make fraudulent access attempts appear legitimate and escape detection. “Credential stuffing attacks are emulating the sorts of requests that a legitimate user would make,” Troy Hunt, security researcher and founder of data breach notification service Have I Been Pwned, tells CSO. “Attackers are asking: What does it look like to make a legitimate request? How can we emulate that? Where it starts to get really interesting is when we look at the combativeness between defenders and attackers.”
Here are four ways cybercriminals hide credential stuffing activity with insight into how to defend against attacks.
Throttling requests to thwart rate limit controls
A common trick of the trade when it comes to disguising credential stuffing attacks is request throttling, says Salt Security technical evangelist and former Gartner analyst Michael Isbitski. “Rate limits and resource limits are often recommended as a security best practice for API mediation mechanisms,” he tells CSO.
As an example, organizations might set a rate limit of 10 requests per minute on a given API that is mediated by an API gateway. If an API caller attempts 11 requests in a minute, the first 10 will work provided the requester has access, and the last will be explicitly blocked. “This threshold will typically reset in the next minute, while some rate limiting mechanisms allow for dynamic limits where an API caller deemed to be excessive might be restricted for some longer interval, much like an account lockout threshold.
When attackers throttle requests, they configure their tools or scripts to run close to this limit without hitting it and then back off,” Isbitski adds, a technique that often works because rate limits are based on normal consumption patterns without considering abuse cases. “Dynamic rate limiting based on continuous behavior analysis of API callers within sessions is the best defense against this technique,” he says.
Solving CAPTCHAs to disguise non-human logins
Credential stuffing attacks are automated. This creates the need for malicious actors to circumvent controls designed to prevent non-human login, specifically CAPTCHAs. Automatically generated upon a login request, CAPTCHAs ask users to perform an image-related task to prove they’re not a bot. While they are typically simple tests to pass for humans, a computer program is highly unlikely to be able to interpret the information required to return a correct response, and so access will be denied.
Credential stuffing actors invest time and effort into to find solutions to bypass this barrier. Hunt cites a real, past case of a human-led CAPTCHA-solving service for hire, which would receive a constant feed of CAPTCHA challenges to solve and send back on corresponding APIs for a minimal fee. “The success rate was high – something like more than 90%. It was interesting to see how even anti-automation can be circumvented for a small cost,” he says.
This shines a light on the ROI around credential stuffing and the value malicious actors place on compromising accounts. “If we can raise the cost of these account takeover attacks, we start to reduce the ROI,” Hunt adds.
Altering HTTP header data to evade detection
Some security detection mechanisms attempt to profile or fingerprint an API caller by analyzing HTTP header information like user agent strings, says Isbitski. However, security analysis on this metadata alone is unreliable and its something that attackers look to exploit.
“It’s entirely user controllable with even basic browser plugins. Intercepting proxies allows an attacker to alter headers as they see fit, and they can automate the alterations over sets of requests to evade detection,” says Isbitski. “They can appear as a web user, a mobile user, an IoT device, or something else if detection is limited to such header examination.”
Organizations must analyze more than just HTTP header information and examine behaviors of users within sessions to identify abusive API callers, Isbitski says. “This requires collection of API telemetry at numerous points of architecture and continuous analysis to identify anomalies that may be signs of an attack.”
Geo-distributing API requests to negate allow and deny lists
IP address allow and deny lists mediate calls to a back-end API and can be configured to block a network connection if the API call originates from an IP address or space that is known to be malicious. To negate this, attackers use proxies to make login attempts appear to originate from different locations.
“This method can geolocate a threat actor to a different country to where they may be residing and results in network defenders observing packets originating from a source IP address that did not generate the traffic,” senior cyberthreat intelligence analyst at Digital Shadows, Chris Morgan, tells CSO. Threat actors use network tunnels to mask their source IP address and geolocation, thus making attribution difficult for network defenders, he adds.
“Attackers also spin up cloud-hosted compute to launch and distribute their attacks,” Isbitski says. IP address spaces of cloud service providers (CSPs) are often trusted by organizations so sanctioned cloud resources and integrations can function without problems.”
Cloud-based IP addresses, particularly with containerized forms of compute, are too ephemeral for organizations to keep up with via IP address allow/deny lists, Isbitski says. “If and when a CSP does catch on, the attacker will have moved on to new forms of compute or new CSPs altogether. Much like rate limiting, security protection must be more dynamic so that it can identify when an attacker shifts where their API requests originate from or exhibits abusive behaviors.”
Preventing credential stuffing attacks
Hunt says multi-layered defense is key to preventing credential stuffing attacks for CISOs, starting with instilling a culture of good password hygiene across an organization. “Until we can actually steer people toward password managers and get a broader adoption rate, we’re only ever chipping around the edges. I think this is an easy win, low hanging fruit. Let’s try and stop people from using passwords that increase the risk of account takeover.”
Two-factor authentication is the next best step to take, Hunts says, pointing out that something as basic as SMS authentication is helpful and straightforward to implement. “Providing the tools to people is a good idea, and it’s a question of what happens in the background without impeding the login flow too much. We don’t want to do something that stops people from being able to use a service with little friction.”
From there, more complexed confidence thresholds can be introduced that kick in when a combination of login red flags appear that require additional authentication checks. “If our confidence drops beneath a certain threshold, we can say: You’ve provided the right username and password, but this doesn’t sound quite right, so we sent you an email with a verification token, and if it’s just one click, it’s not too bad from a user friction perspective,” Hunt says.
Finally, and perhaps most importantly, Hunt advises organizations to firmly understand risk values across their spectrum of services and measure the impact of potentially suspicious logins on each of them individually. “It’s one thing if someone logged into my Chrome account to comment on pictures of cats, and it’s another thing altogether if they’re logging into a cryptocurrency wallet. So, there needs to be commensurate controls to risk and impact.”