Credential stuffing is a cyberattack in which public usernames and passwords are used to gain fraudulent access to accounts through large-scale automated login requests. The heavy use of accounts, password reuse, and massive amounts of compromised credentials on the darknet create a perfect storm for cybercriminals to conduct credential-stuffing campaigns, while the tactics used by attackers make identifying and preventing attempts to spoof credentials a serious challenge for organizations, writes CSO.
Compounding the pressure is the fact that attackers deliberately disguise the filling in of credentials so that fraudulent access attempts look legal and are not detected. "Credential-stuffing attacks mimic requests that a legitimate user would make," said Troy Hunt, a security researcher and founder of the data leak notification service Have I Been Pwned. "Attackers ask: what does a legitimate request look like? How can we emulate this? What becomes really interesting is when we look at the fighting between defenders and attackers, " he said.
Here are four ways that cybercriminals can hide their login credentials to understand how to protect themselves from these types of attacks.
Request throttling to prevent speed limit management
A common trick when it comes to masking credential - spoofing attacks is to regulate requests, says Salt Security technical evangelist and former Gartner analyst Michael Isbitski. "Speed limits and resource limits are often recommended as security best practices for API mediation mechanisms," he told CSO.
For example, organizations can set a speed limit of 10 requests per minute for a given API mediated by the API gateway. If the API caller makes 11 requests per minute, the first 10 will work if the requester has access, and the last one will be explicitly blocked. "This threshold is usually reset in the next minute, while some rate-limiting mechanisms allow dynamic limits where an API caller deemed excessive may be restricted for a longer interval, similar to the account lockout threshold.
When attackers limit requests, they configure their tools or scripts to work close to this limit without reaching it, and then back off, " adds Isbitski. This method often works because speed limits are based on common consumption patterns without taking into account abuse cases. "Dynamic rate limiting, based on continuous analysis of the behavior of API callers within sessions, is the best defense against this technique," he says.
CAPTCHA bypass to mask robotic logins
Attacks with filling in credentials are automated. This makes it necessary for attackers to bypass controls designed to prevent a robot from logging in, such as captchas. CAPTCHAS generated automatically on a login request ask users to complete an image-related task to prove that they are not a bot. Although these are usually simple tests for humans, it is unlikely that a computer program will be able to interpret the information needed to get the correct answer, and therefore access will be denied.
Users who fill in their credentials spend time and effort looking for solutions to circumvent this barrier. Hunt cites a real, past case of hiring a human-led CAPTCHA solution service that would receive a constant stream of CAPTCHA tasks to solve and send back through the appropriate APIs for a minimal fee. "The success rate was high - something like over 90%. It was interesting to see how you can get around even anti-automation for a small amount of money, " he says.
This sheds light on the return on investment in filling in credentials and the importance that attackers attach to compromising accounts. "If we can increase the cost of these account hijacking attacks, we will start to reduce our ROI," Hunt adds.
Changing HTTP header data to avoid detection
According to Isbitski, some security detection mechanisms attempt to profile or fingerprint the API caller by analyzing HTTP header information, such as user agent strings. However, security analysis based on this metadata alone is unreliable, and attackers tend to exploit it.
"This is completely controlled by the user, even with the basic browser plugins. Intercepting proxy servers allows an attacker to change the headers as they see fit, and they can automate changes to request sets to avoid detection," says Isbitski. "They can show up as a web user, mobile user, IoT device, or something else, if detection is limited to such a header check."
According to Isbitski, organizations need to analyze more than just the information in HTTP headers, and study user behavior within sessions to identify malicious API callers. "This requires the collection of API telemetry at multiple points in the architecture and continuous analysis to identify anomalies that may be signs of an attack."
Geographical distribution of API requests for canceling lists of bans and permissions
Lists of allowed and forbidden IP addresses mediate internal API calls 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 prevent this, attackers use proxy servers to make login attempts look like they are coming from different locations.
"This method can geolocate an attacker in another country where they may reside, and leads network defenders to monitor packets originating from the source IP address, which did not generate traffic," said Chris Morgan, senior cyber threat analyst at Digital Shadows. He added that attackers use network tunnels to mask the source IP address and geolocation, which makes attribution difficult for network defenders.
"Attackers also use cloud computing to launch and distribute their attacks," says Isbitski. Cloud Service Provider (CSP) IP address spaces are often trusted by organizations, so authorized cloud resources and integrations can work seamlessly."
According to Isbitski, cloud IP addresses, especially with containerized forms of computing, are too ephemeral for organizations to keep up with them with lists of allowed/forbidden IP addresses. "If and when CSP gains popularity, the attacker will move on to new forms of computing or new CSPs. Like rate limiting, security protection needs to be more dynamic so that it can detect when an attacker is moving, where their API requests are coming from, or when they are displaying abusive behavior," the expert predicted.
Preventing attacks with filling in credentials
Hunt says layered protection is key to preventing credential spoofing attacks for information security directors, starting with instilling a culture of proper password hygiene in the organization. "Until we can actually direct people to password managers and achieve more widespread adoption, we will only shrink at the edges. I think it's an easy win, low-hanging fruit. Let's try to stop people from using passwords that increase the risk of account hijacking."
Two-factor authentication is the next best step, Hunt says, pointing out that basic authentication such as SMS authentication is useful and easy to implement. "Giving tools to people is a good idea, and the question is what happens in the background without interfering too much with the login process. We don't want to do something that prevents people from using the service with minimal difficulty."
From there, more complex confidence thresholds can be introduced, which are triggered when a combination of red login flags appears that require additional authentication checks. "If our confidence drops below a certain threshold, we can say: you entered the correct username and password, but it doesn't sound quite right, so we sent you an email with a confirmation token, and if it's just a single click , it's not too bad from the users' point of view, " Hunt says.
Finally, and perhaps most importantly, Hunt advises organizations to clearly understand the risk implications for their entire range of services and to 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 cat photos, but it's quite another if they're logged into a cryptocurrency wallet. Thus, there should be proportionate risk and impact control measures," he said.
Author: Michael Hill
Compounding the pressure is the fact that attackers deliberately disguise the filling in of credentials so that fraudulent access attempts look legal and are not detected. "Credential-stuffing attacks mimic requests that a legitimate user would make," said Troy Hunt, a security researcher and founder of the data leak notification service Have I Been Pwned. "Attackers ask: what does a legitimate request look like? How can we emulate this? What becomes really interesting is when we look at the fighting between defenders and attackers, " he said.
Here are four ways that cybercriminals can hide their login credentials to understand how to protect themselves from these types of attacks.
Request throttling to prevent speed limit management
A common trick when it comes to masking credential - spoofing attacks is to regulate requests, says Salt Security technical evangelist and former Gartner analyst Michael Isbitski. "Speed limits and resource limits are often recommended as security best practices for API mediation mechanisms," he told CSO.
For example, organizations can set a speed limit of 10 requests per minute for a given API mediated by the API gateway. If the API caller makes 11 requests per minute, the first 10 will work if the requester has access, and the last one will be explicitly blocked. "This threshold is usually reset in the next minute, while some rate-limiting mechanisms allow dynamic limits where an API caller deemed excessive may be restricted for a longer interval, similar to the account lockout threshold.
When attackers limit requests, they configure their tools or scripts to work close to this limit without reaching it, and then back off, " adds Isbitski. This method often works because speed limits are based on common consumption patterns without taking into account abuse cases. "Dynamic rate limiting, based on continuous analysis of the behavior of API callers within sessions, is the best defense against this technique," he says.
CAPTCHA bypass to mask robotic logins
Attacks with filling in credentials are automated. This makes it necessary for attackers to bypass controls designed to prevent a robot from logging in, such as captchas. CAPTCHAS generated automatically on a login request ask users to complete an image-related task to prove that they are not a bot. Although these are usually simple tests for humans, it is unlikely that a computer program will be able to interpret the information needed to get the correct answer, and therefore access will be denied.
Users who fill in their credentials spend time and effort looking for solutions to circumvent this barrier. Hunt cites a real, past case of hiring a human-led CAPTCHA solution service that would receive a constant stream of CAPTCHA tasks to solve and send back through the appropriate APIs for a minimal fee. "The success rate was high - something like over 90%. It was interesting to see how you can get around even anti-automation for a small amount of money, " he says.
This sheds light on the return on investment in filling in credentials and the importance that attackers attach to compromising accounts. "If we can increase the cost of these account hijacking attacks, we will start to reduce our ROI," Hunt adds.
Changing HTTP header data to avoid detection
According to Isbitski, some security detection mechanisms attempt to profile or fingerprint the API caller by analyzing HTTP header information, such as user agent strings. However, security analysis based on this metadata alone is unreliable, and attackers tend to exploit it.
"This is completely controlled by the user, even with the basic browser plugins. Intercepting proxy servers allows an attacker to change the headers as they see fit, and they can automate changes to request sets to avoid detection," says Isbitski. "They can show up as a web user, mobile user, IoT device, or something else, if detection is limited to such a header check."
According to Isbitski, organizations need to analyze more than just the information in HTTP headers, and study user behavior within sessions to identify malicious API callers. "This requires the collection of API telemetry at multiple points in the architecture and continuous analysis to identify anomalies that may be signs of an attack."
Geographical distribution of API requests for canceling lists of bans and permissions
Lists of allowed and forbidden IP addresses mediate internal API calls 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 prevent this, attackers use proxy servers to make login attempts look like they are coming from different locations.
"This method can geolocate an attacker in another country where they may reside, and leads network defenders to monitor packets originating from the source IP address, which did not generate traffic," said Chris Morgan, senior cyber threat analyst at Digital Shadows. He added that attackers use network tunnels to mask the source IP address and geolocation, which makes attribution difficult for network defenders.
"Attackers also use cloud computing to launch and distribute their attacks," says Isbitski. Cloud Service Provider (CSP) IP address spaces are often trusted by organizations, so authorized cloud resources and integrations can work seamlessly."
According to Isbitski, cloud IP addresses, especially with containerized forms of computing, are too ephemeral for organizations to keep up with them with lists of allowed/forbidden IP addresses. "If and when CSP gains popularity, the attacker will move on to new forms of computing or new CSPs. Like rate limiting, security protection needs to be more dynamic so that it can detect when an attacker is moving, where their API requests are coming from, or when they are displaying abusive behavior," the expert predicted.
Preventing attacks with filling in credentials
Hunt says layered protection is key to preventing credential spoofing attacks for information security directors, starting with instilling a culture of proper password hygiene in the organization. "Until we can actually direct people to password managers and achieve more widespread adoption, we will only shrink at the edges. I think it's an easy win, low-hanging fruit. Let's try to stop people from using passwords that increase the risk of account hijacking."
Two-factor authentication is the next best step, Hunt says, pointing out that basic authentication such as SMS authentication is useful and easy to implement. "Giving tools to people is a good idea, and the question is what happens in the background without interfering too much with the login process. We don't want to do something that prevents people from using the service with minimal difficulty."
From there, more complex confidence thresholds can be introduced, which are triggered when a combination of red login flags appears that require additional authentication checks. "If our confidence drops below a certain threshold, we can say: you entered the correct username and password, but it doesn't sound quite right, so we sent you an email with a confirmation token, and if it's just a single click , it's not too bad from the users' point of view, " Hunt says.
Finally, and perhaps most importantly, Hunt advises organizations to clearly understand the risk implications for their entire range of services and to 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 cat photos, but it's quite another if they're logged into a cryptocurrency wallet. Thus, there should be proportionate risk and impact control measures," he said.
Author: Michael Hill
