Countermeasures must harness the broadest possible datasets and personalized consumer identity info
ANALYSIS Credential stuffing, which compromises web accounts by automatically feeding credentials harvested from data breaches into countless login pages, remains a technically simple, resource-light, highly effective form of cyber-attack.
And with so many web users still recycling the same password across multiple online accounts, the onus is on organizations to protect customers through better detection and more secure, but low friction, login processes.
Following The Daily Swig’s recent deep dive into the phenomenon, Tony Lauro, director of security technology and strategy at Akamai, offers his prescriptions for how this might be achieved:
‘Bot detection must be done holistically’
As credential stuffing tools become more sophisticated, organizations are increasingly trying to detect and repel attacks without creating intolerable friction at the login process for legitimate users.
The problem is, many such mechanisms do introduce considerable friction, as well as having a high false positive rate.
Cross-site, cross-industry analysis
Neither downside applies to cross-site or cross-industry analysis.
On a daily basis, Akamai helps clients leverage this technique in combination with personalized consumer identity information to protect and validate user identities before fraud has taken place.
The analysis process should begin with scanning for compromised credentials on publicly available datasets – a comparatively easy first step.
However, attackers are spreading requests among a growing number of IP addresses and making fewer requests per IP. When one of our clients sustained an attack from around 12,000 IP addresses, for instance, most sent fewer than 20 login attempts per IP over the course of 24 hours.
Ten percent sent a single login attempt over that time frame, 65% sent no more than 10, and 92% sent up to 20. Analysis on such a low request rate provides insufficient detection coverage.
However, widening the dataset to encompass the campaign’s activity across other customers’ login attempts yields a different perspective.
The botnet actually targeted 71 websites with an average of 6,902 login attempts per hour against the single site compared to 203,793 attempts in total against all other sites analyzed.
Although this demonstrates the visibility impact of viewing this data in aggregate, it still does not fully optimize the decision-making process.
Integrating consumer identity information
With more and more attackers eschewing ‘cloud proxies’ in favor of botnets of compromised smart-home devices, integrating consumer identity information into the detection process is the next important step in distinguishing between malicious bots and the legitimate human user.
This methodology considers what an adversary needs to know in order to look like a real user – such as:
- CIDR block info, IP reputation, location data, whether IP is from a known cloud provider or known compromised botnet
- Browser fingerprint, user agent, header structure, header order needs to match real browser version, version numbers, TLS fingerprint
- Device characteristics, location data, accelerometer data
- How to meet all rate control requirements, such as time of day to look like real traffic from ‘awake’ customers
What notable items were missing from the above list? How about:
- The user TonyLauro@myemail.com always connects from an AT&T Business network from Dallas, Texas
- When TonyLauro@myemail.com tries to log in, his device headers usually belong to an iOS mobile device
- When TonyLauro@myemail.com logged in 15 minutes ago, he was in Dallas, Texas and NOT in Philadelphia, Pennsylvania
These secondary and tertiary detection methods are made possible by the ability to tie who or what is attempting to login with the details we know about the actual human who owns the credentials.
Attackers often know much about the browser and applications they’re attacking, because all that information can be gleaned using the publicly available OSINT information of their target system.
But personalized information about the user – who they are and what their login connections look like – is much harder for an attacker to justify keeping track of, and is nearly impossible at large scale.
Easing the burden
You might point out that distinguishing between valid and invalid logins won’t stop illegitimate logins from creating a burdensome load on the website and impair the user experience.
This is true unless you offload all traffic relating to the login process through a cloud provider who can proxy this traffic on your behalf.
I have seen many organizations implement comprehensive bot detection technologies and then discover that real users and ‘good bots’ only accounted for 30-40% of their traffic volumes.
Finally, organizations must implement methodologies that preserve the ability to take decisive, decision-based actions after determining if, for instance, the request is definitively human or bot, or simply suspicious. ‘Yes’ or ‘no’ is not good enough as attackers continue to innovate their methodologies.
Credential abuse and account takeover are often dismissed as problems that only the financial industry – historically the principal target – need worry about.
This is not the case. For instance, with so many of the world’s office workers now working from home, media companies are increasingly targeted in the pursuit of free service, access to payment card information, or to simply exploit the burgeoning ecosystem of in-app micro-transactions.
The integration of credential stuffing tools with other hacking tools and automation workflows using API technologies is an alarming development.
As these tools continue to evolve, so do all the other applications used by the attacker to pursue full account takeover.
The most dangerous recent innovation in credential stuffing tools, I believe, is how easily they now integrate into the attacker workflow. Many are written to integrate the use of APIs to streamline response codes from good or bad login attempts, manage captcha responses, and so on.
Some all-in-one bot tools used for ‘inventory sniping’ (the process of automating the selection, checkout, payment, and shipping of high value retail goods) are fully compatible and configured in accordance with the target sites’ API workflow, and have input mechanisms for previously validated credentials, payment card information (stolen or otherwise), and shipping profiles.
They even have a workflow to manage what happens if a card is fraud blocked or a transaction can’t complete because of errors.
Most surprisingly – although I haven’t seen this in credential abuse tools yet – the inventory sniping tools have a ‘captcha catcher’ mechanism which streamlines the captcha response process.
They even ‘inform’ the user that playing YouTube videos in the background will gain them valuable ‘user liveliness tokens’. If a retail store uses Google ReCaptcha, these tokens will give the attacker simple, one-click ‘I am not a robot’ challenges as opposed to more complicated picture puzzles.
I therefore expect to see bot defenses start to present crypto worker challenges to bot operators in order to slow or halt their advance through the website.
This methodology will only be enabled when defenders can create custom response capabilities based on the level of validation achieved at various junctures of the inspection process, and on each request, modify the responses accordingly.
YOU MIGHT ALSO LIKE Strategies for combating increased cyber threats tied to coronavirus