For bad actors to manually take over an account, they have credentials that they are confident will work. Rather than guessing the credentials, or even needing to phish the victim, they have a pre-vetted set that someone else has already validated. How do they know that these credentials work, and how did they obtain a filtered list?
Typically, someone else has already tested a much more extensive, highly inaccurate list of credentials that they bought following a recent data breach. To refine the list, they iterate through every single set to find the small percentage of credentials that work. They then sell the refined target list for a much higher amount than what they paid for the untested list. The ROI for someone who cleans the list is very high, and the risk of getting caught is much lower since they don't perform the subsequent manual fraud.
Because the credential stuffing attacker may just be trying to see whether credentials work at all, they may not be interested in going deeper into the account. Giving them any positive signal, such as a different HTTP status code or a 2-step challenge (such as 2FA or a CAPTCHA), may do more harm than good. It provides the attacker with enough information to know that even if there are some roadblocks, they have the right credentials, and a more targeted attack is likely to succeed.
they are harder to pin down by using more IPs, anticipating that defenders are looking at IP rather than other indicators
they appear local by using IPs in regions that regular users are in
they appear less suspicious by creating many fake accounts to build a reputation
they seem innocent by using registration and password resets instead of more direct approaches
Suppose that in the worst-case scenario, an attacker has identified a useful set of credentials and already made it past authentication. In naive designs that rely on bottlenecking authentication, the attacker can have high confidence once they scale the first wall. Their behavior inside the account, such as unusual transactions, gift card redemptions, or making a beeline to reset the password from a new device, could go unnoticed. Ignoring the context of identity and only focusing on traditional, credentialed authentication leaves open many opportunities for bad actors.
This video demonstrates a credential stuffing attack and some ways to mitigate it.
Since we can anticipate the goal of an attack by considering the attacker experience, how can we take proactive steps to mislead attackers?
By automatically determining an attack is in progress from detecting a series of failed logins, create a signature of the abusive device
Even if the attacker's machine proxies through a set of reputable IP addresses, when it attempts to log in with the correct credentials, it needs to be stopped completely
The attacker should receive no indication (e.g., HTTP response, 2-step challenge) to indicate that the credentials are valid since that leads to more targeted attacks on the account in the future.
The company's security teams and the end-user should have immediate notification of the near-successful compromise, including all steps needed to secure the account--even though the attack failed for the time being.
Even in the worst-case scenario where an attacker compromises the account, it is still possible to defend against fraudulent transactions, account changes, and other abuses. Every action, device, and account trait can provide a new chance to detect deviations from the norm. Attackers can trivially circumvent approaches that only look for single signatures such as user agents or IP address. Attackers are becoming sophisticated enough to disguise themselves and defeat naive bot checks at login.
With enough context, it is possible to determine when activities are suspicious within an account, and not just at login. Castle uses threat intelligence gleaned from hundreds of millions of good accounts against even the most sophisticated attackers. To learn more about how identity, authentication, and threat intelligence are changing, please enjoy our webinar: https://go.castle.io/security-decentralized