If you're reading this, perhaps you've found yourself in the aftermath of a credential-stuffing attack, facing the daunting task of steering your team and organization through the incident. It's a situation no one wants to find themselves in—a breach not only of security but of trust. But amidst this chaos, know that you are not alone.
This blog post is crafted with you in mind, a beacon of guidance designed to illuminate your path to recovery and resilience. We understand the weight of responsibility that rests on your shoulders, the sleepless nights wondering where the vulnerability lies, and the stress of safeguarding your users' trust. We aim to provide you with a rapid response playbook tailored specifically for the aftermath of Account Takeovers (ATOs) and Credential Stuffing incidents.
Here, you'll find not just strategies but solace in actionable advice that's been carefully curated to help you navigate an incident. From immediate steps to mitigate damage to long-term strategies that bolster your defenses, this playbook is your companion in turning adversity into action. These strategies and insights have been built on our team's real world learning's and experiences in the field.
So take a breath, and let's embark on this journey together towards recovery, security, and resilience.
T minus 1 day - The days leading up…
You've had a tsunami of customer complaints flood all customer support channels, social media, review sites, call centers, and email. This escalates to management, and you're now very aware of what could have happened and the nature of a potential incident.
💡 Credential Stuffing and subsequent Account Takeovers (ATO) primarily happen because weak authentication methods are employed during a sign-in. This could include authentication credentials like passwords, passphrases, and PINs. The symmetric nature of such credentials means that even though you may securely store passwords/PINs or have complexity requirements, these credentials are highly likely to be re-used, exposed via unrelated breaches, or easily phished from your users.
T minus 0+ days - Your response
Your incident response plans kick into gear, and most good plans involve immediate assessments/containment, a formed incident management team, effective internal and external communications, and lastly, blameless post-mortems.
We won't go too much into detail about incident management processes in this post, but we'll dive into immediate assessment and containment strategies you might want to employ. We will break down the trade-offs and effectiveness of the different approaches.
Immediate assessments
What's being exfiltrated? - Are customer funds being stolen? Is private identifiable information being obtained? Can you observe what APIs or URLs are being hit? Log sources, Google analytics, server logs (nginx, apache), observability tools (Datadog/Splunk).
What are your legal responsibilities?
Most jurisdictions have privacy laws that require immediate reporting to relevant authorities within stipulated times. For example, in the EU, Data Controllers are obliged to report to a supervisory authority within 72 Hours of becoming aware of a data breach.
Are health records involved, there are more stringent processes and regulations that apply to health records.
Can you determine the customers who are impacted?
Are customers from a particular region or specific demographic specifically targeted? Are there exfiltration signals you could correlate (e.g, chargebacks, reporting, dark web lists, customer complaints).
How long has this been going on?
Are you able to determine the start of the credential stuffing attack? Typically inquiring your logging and observability tools could give an indication of unusually high volumes of traffic for “sensitive” routes.
How "to/not to" communicate to your customers
The first rule of thumb is to not attribute blame, especially on your customers. In recent times, some high-profile companies have opted to take a “pass the buck” position in public disclosures. Instead here are some options which you could use in your communications:
- Be transparent in acknowledging the incident and stating the facts.
- Communicate directly to affected customers first, before the blog post or press release, and inform the affected parties first.
- Offer tools and services to impacted customers. The result of an account takeover can be traumatic and your teams may not have the capacity to help deal with the aftermath of a breach. There are organizations globally that can help your customers through this process, direct them to these services, or even better fund the provision of these services.
- IDcare (Australia & New Zealand).
- Credit and identity monitoring.
- Re-state your customers’ rights and be transparent about their rights to control their data, including the ability to delete their data.
- Communicate the immediate mitigations and controls that will be put in place
- Could 2FA/MFA be turned on?
- Can the customer reset passwords or freeze account activity.
You may want to have a dedicated incident page or portal for your customers to manage and be informed on the developments and progress.
Containment and Mitigations
Uplift to stronger authentication methods/utilize step-up
Using first principles, the last layer of defense to mitigate credential stuffing is to employ Multi-factor Authentication (MFA/2FA) using strong authentication factors. Immediate mitigations may involve opting for at least Email One-time passwords (OTP) or magic links using your user's existing email address on file.
Now not every app or platform will have this readily available as a switch, so MFA may not be a rapid response option for your team. But if available, stepping up authentication on sign-in with at least one kind of passwordless authentication factor will drastically deter bad actors and stop them in their tracks.
💡 Authsignal makes it very simple to rapidly respond to ongoing credential stuffing attacks, through our single API integration and pre-built hosted UI flows. Step-up MFA doesn't have to come a the expense of good customers. Step-up logic could be completely managed via Authsignal's no-code rules engine, by isolating challenges to new devices or attempts made from IP addresses outside of your typical customer base countries
Bot mitigation
Web Application Firewalls (WAF)/Content Delivery Networks (CDN)/Reverse proxies, and/or bot mitigation vendors typically offer solutions that are based on machine learning models and customer flows that offer CAPTCHAs to exonerate good customers and stop bots. These bot mitigations are usually effective in high-volume attacks, and some solutions offer a global network of signals from their customer network to mitigate globally organized attacks, which offers a lot of value.
In isolation, bot mitigation platforms cannot be your long-term mitigation as models are probabilistic in nature (i.e. using a bot probability score to determine whether to BLOCK or CHALLENGE) and bad actors are heavily investing in tooling to circumvent detection models and to solve captcha puzzles. Do also note the impact of CAPTCHAs on good customers, as many find them hard to solve and may frustrate a segment of your customer base.
Solution Spotlight: Cloudflare
Cloudflare offers a rapid deployment model, allowing you to utilize them as Domain Name Server (DNS), CDN, and WAF all in one. Because Cloudflare's core offering operates at the edge of your application's endpoints, rapid mitigation can be quickly employed as requests can be intercepted and evaluated, with Cloudflare acting as a reverse proxy. Cloudflare's new challenge platform employs a range of signals and strategies to appropriately decide whether to ALLOW, CHALLENGE, or BLOCK your customers. It's worth considering switching to Cloudflare if you're not already using a WAF, are still under attack, and want results fast.
Other vendors can operate at your WAF or CDN of choice and typically employ a javascript tag that runs on your pages to evaluate an existing session and have challenge flows that can be embedded into customer flows. Do note that the more complex your applications are i.e. mobile apps, single page applications, there will be increased integration complexity, do weigh up the trade-offs if you're thinking of CAPTCHA based bot protection solutions.
End-point rate limits
Another reason to employ a WAF is the ability to quickly enforce rate limits on endpoints that are the subject of the credential stuffing attacks i.e."yourdomain.com/sign-in"Although not a full mitigation, rate limits on sensitive endpoints can at least slow attackers down, increasing the cost of the attack which disincentivizes bad actors, do remember these actors are also economically driven.
Increase password complexity and Forced password reset
NIST suggests that user-generated passwords of at least 8 characters should be enforced, and the the use of sequential characters like “aaa” be avoided. Enforcing more complex passwords when paired with forced password resets could be an effective way to uplift your customer account security posture but be warned, if introduced during an attack you maybe offering an option for bad actors to lock customers out of their accounts.
Failed Attempt limits and cool-down periods
This is also known as an account lockout, this control mainly slows down the attacker but can have consequences that impede on your good customers. Allow for a cool-off period, for example, 15-30mins after the failed attempts before the counter resets.
If possible lock out or enforce MFA only to new devices to limit the impact on your good customers.
Removal of a weak authentication factor
One of the most common low-hanging fruit opportunities is to remove a weak authentication factor. It's still not uncommon, even at the time of this post, for many consumer-facing portals, even in the financial service industry, to still rely on PIN codes (usually only 4 to 6 digits long) shocking but true. This is a honey pot of bad actors, and screams, "Please credential stuff my sign-in form."
Reluctance to remove this option is because of the fear of demographics that may be reluctant to use a password. This trade-off should be well understood by not only technical teams but also those who have operational and risk oversight in your business. If you're a cyber risk professional and see this in your organization, it's paramount to educate and highlight the trade-off, but also explain how simple and effective it is to drop PINs as an authentication factor.
Longer-Term Mitigations and Improvements
Once the dust has settled, and hopefully your team has a bit of reprieve after implementing the immediate actions it's time to think about some longer-term strategies to bring down credential stuffing risk to a minimum.
It's important to note that credential stuffing is not the only threat vector to lead to an Account Takeover. Use this time to start planning improvements that can mitigate other threats such as cookie session hijacking, and phishing.
Passkeys Phishing Resistant MFA
Authsignal's suite of out-of-the-box authenticators allows for customer-tuned passkey flows, which are highly secure and phishing resistant. Passkeys are the next-generation authentication factor that is both phishing resistant and uses asymmetric cryptography that will help dramatically uplift your customer account security. We go into more depth in our article below.
Passkeys APIs and SDKs - Making Passkeys implementation more easier and more secure.
We hope that this rapid response playbook could help you and your team with some ideas and proven strategies; although not exhaustive, having a reference point could help reduce the stress while navigating the preceding days.
Good luck, and we’d hope to those reading, preemptive measures can be put in place so that this playbook will never have to be enacted.
Are you under attack or worried that you might be?
Authsignal has a rapid response team that can offer complimentary advice and guidance, especially during times of high stress. Contact us, and our solutions support team will get back to you within 24 hours.
