While grandma’s stuffing might be the best part of your holiday turkey dinner, credential stuffing attacks can be the worst part of being the person responsible for your company’s security monitoring. Your IT environment likely consists of all the ingredients attackers need to deploy an attack successfully. As you add more Software-as-a-Service (SaaS) applications and connect them with Application Programming Interfaces (APIs), you create new access points that they can use to gain unauthorized access to applications, databases, systems, and networks.
As data breaches leak more user login ID and password combinations, you should understand what a credential stuffing attack is and the mitigation strategies that help reduce risk.
What Is Credential Stuffing?
In a credential stuffing attack, threat actors use automation to bombard systems with stolen login credentials, hoping to gain unauthorized access to user accounts. Attackers rely on the assumption that people reuse passwords across personal and professional accounts. After obtaining the credentials from a data breach or purchasing them from other cybercriminals, the malicious actors submit them to dozens or hundreds of websites and applications.
Increasingly, credential stuffing attacks target APIs, the technology that allows applications to communicate. APIs increase the likelihood that credential stuffing attacks will succeed for various reasons, including:
- Lack of user interface: inability to use interactive security controls, like CAPTCHAs or multi-factor authentication (MFA)
- Inability to store session information: inability to track failed login attempts that help detect an attack
- High volumes of legitimate requests: disruption to service when using traditional rate limiting policies that help detect an attack
- Endpoint exposure: sharing endpoint information for functionalities, including user authentication
How Credential Stuffing Attacks Work
Credential stuffing attacks work similarly against applications and APIs. However, a fundamental difference lies in the reconnaissance required.
Application Credential Stuffing Attack
At the application level, attackers typically deploy attacks against known domains, like social media or corporate websites. They may not need specific information about the application’s internal infrastructure.
In an application credential stuffing attack, the threat actor typically:
- Purchases leaked or stolen credentials for reuse
- Configure the chosen automation tool
- Import the list into the tool
- Tracks login failures and successes
API Credential Stuffing Attack
API credential attacks often require an additional reconnaissance step where the attackers need to identify the vulnerable access point.
In an API credential stuffing attack, the threat actor typically:
- Purchases stolen leaked or stolen credentials
- Performs reconnaissance against the target and its APIs, often a login API
- Throttles their automation tool by configuring adjust times, number of requests, and time between retries
- Launches attack against login API
- Tracks login failures and successes
Brute Force Attacks vs. Password Spraying vs.Credential Stuffing
Although all three attack types target credentials, they have nuanced differences:
- Brute force: targets a user login ID and tries various passwords to see if they work
- Password spray: targets a risky password and tries it with various user login IDs
- Credential stuffing: starts with a list of known login IDs and passwords that worked for one application and tries to see if using them with other websites or applications work
How to Mitigate Credential Stuffing Attack Risks
If a credential stuffing attack is successful, your company can suffer consequences like:
- Corporate espionage and theft
- Financial loss due to fraud
- Loss of customer trust
- Damaged brand reputation
- Attacker movement across the infrastructure
To protect your organization, you should implement some fundamental controls across your application and API landscape.
Multi-factor Authentication (MFA)
MFA helps mitigate risks arising from credential-based attacks by requiring users to respond to challenge questions that prove they are legitimately attempting to access an account. MFA requires users to provide at least two of the following:
- Something they know (password)
- Something they have (token, smartphone)
- Something they are (fingerprint or face ID)
At the application level, you should require additional authentication whenever someone attempts a login from:
- A new browser
- A new IP address
- An unusual geographic location
- Countries considered untrusted
- An IP address on a known block list or from an anonymized service
- An IP address attempting to login to multiple accounts
- Login attempts that appear to be automated
At the API level, implementing MFA looks different and may require you to:
- Set specific requirements in Identity and Access Management (IAM) policies what operations users can call
- Configure a device for each user who needs to make API requests that require MFA
- Create policies that check whether a user authenticated with the MFA device
- Require users to provide a time-based one-time password (TOTP) that the device generates before completing the call
Secondary Passwords, PINs and Security Questions
While these offer another layer of defense, they don’t constitute MFA because they are additional “things you know” factors. However, to mitigate credential stuffing risks, you may also want to prompt users to provide this additional security information, like:
- A PIN
- Characters from another memorable word
- Answers to security questions
CAPTCHA
CAPTCHAs, or “Completely Automated Public Turing Test to Tell Computers and Humans Apart,” help mitigate risk posed by attackers using botnets in their credential stuffing risks. By requiring users to interact with the website or application after supplying their credentials, CAPTCHAs can help identify human users or slow down automated tools.
IP Mitigation and Intelligence
While IP blocking can help mitigate risk, many toolkits include built-in proxy networks to overcome this protection. IP and geo blocking may offer additional protection when layered with other defenses. When implementing these network level measures, you should consider:
- Short bursts and long time periods
- Request volume from a single IP address
- Low but consistent traffic from a single IP address
- IP classification, such as residential or hosting
Device Fingerprinting
Device fingerprinting allows you to gain insight into whether the browser someone uses to access the application matches the initial authenticated browser. For example, HTTP headers can tell you about:
- Operating system
- Browser
- Language
If your application uses JavaScript, you may be able to incorporate additional information like:
- Screen resolution
- Installed fonts
- Installed browser plugins
Connection Fingerprinting
Similar to device fingerprinting, you can gain insight into the network connections with information like:
- IP Address
- Request data
- User agent strings
Unpredictable Usernames
Many applications use the same format for login IDs, like email addresses. Reuse of login ID across multiple applications makes successfully deploying a credential stuffing attack easier for cybercriminals. If the application requires people to create their own username rather than simply using an email address, the process becomes more difficult for the attackers.
Identifying Leaked Passwords
You can identify leaked passwords using paid and free services, like HaveIBeenPwned. If you prevent people from using these known passwords, you can mitigate risk. You can also find news articles linked to large hacks like the Roku Accounts.
Monitoring Failed and Successful Logins
If you aggregate, correlate, and analyze data from your Identity and Access Management (IAM) tools with other information, like inbound traffic, you can create alerts to detect potential credential stuffing attacks.
For example, if you see a high volume of failed attempts over five or ten minutes followed by a successful login, it could be attackers trying to gain unauthorized access.
API-Specific Mitigations
You can’t implement security mitigations like CAPTCHAs or unpredictable usernames with APIs. However, you should consider the following additional risk mitigation strategies:
- Know all possible flows to authenticate to the API, including mobile, web, and one-click authentication links
- Use existing standards for authentication, token generation, and password storage
- Treat credential recovery/forgotten password endpoints as login endpoints
- Require re-authentication for sensitive operations
- Implement brute-force specific mechanisms that are more strict than regular API rate limiting mechanisms
- Only use APIs keys for API client authentication, not user authentication
Graylog: Comprehensive Visibility into Organization and API Security
With Graylog Security and Graylog API Security, you can create a comprehensive security monitoring program with end-to-end API threat, monitoring, detection, and response. Graylog Security’s out-of-the-box content and security analytics enable you to build high-fidelity alerts and then pivot directly into researching the log data that matters most. Our platform gives you all the functionality of a SIEM without the complexity, providing a robust technology that empowers users of all experience levels.
With Graylog API Security, you supplement your Web Application Firewall (WAF) and API gateway monitoring for enhanced security. Graylog API Security provides Continuous API Discovery, automated risk assessment scoring, and full API request and response capture so you have all the data necessary to detect and investigate common threats and API failures faster.
Contact us today to see how our combined operations, security, and API monitoring platform can help you.
