> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

> Playbook for using Auth0's Brute Force monitoring feature in the Security Center

# Brute Force Protection Playbook

<Card title="Before you start">
  You must configure [Brute Force Protection](/docs/secure/attack-protection/brute-force-protection) and set up logs and [alerts for thresholds](/docs/secure/security-center/security-alerts).
</Card>

Attackers can employ brute force techniques ([TT1110](https://attack.mitre.org/techniques/T1110/)) to gain access to sensitive systems. Often unsophisticated, most brute-force attacks are easily defeated, but defense can be resource-intensive. Below are some common brute-force attack techniques and guidance on how to identify and investigate potential attacks against your tenant.

### Find log events of interest

Before blocking IPs or otherwise responding to an attack, identify breaches by sifting through the log messages of interest. The attack may be coming from a limited set of IPs or from a single autonomous system number or country.

The following log event types are relevant when investigating a brute force attack. They are found in the [Auth0 tenant logs](/docs/secure/attack-protection/view-attack-protection-events).

<Accordion title="Log event types">
  1. `f`: Failed user login
  2. `fu`: Failed user login due to invalid username
  3. `fp`: Failed user login due to invalid password
  4. `pwd_leak`: Attempted login with a leaked password
  5. `signup_pwd_leak`: Attempted to sign up with a leaked password
  6. `limit_wc`: IP blocked for >10 failed login attempts to a single account
  7. `limit_sul`: User blocked for >20 login per minute from the same IP address
  8. `limit_mu`: IP blocked for >100 failed login attempts or >50 signup attempts
  9. `fcoa`: Failed cross-origin authentication
  10. `scoa`: Successful cross-origin authentication
</Accordion>

### Password guessing

Attackers with little prior knowledge of your tenant’s policies can repeatedly attempt to guess passwords ([TT1110.001](https://attack.mitre.org/techniques/T1110/001/)) in an attempt to access accounts. Since attackers are merely guessing whether a user exists with an unknown password, your [Auth0 logs](/docs/deploy-monitor/logs/log-event-type-codes) will display many `fp`, `fu` and `fcoa` log events. For more information, read Auth0's [Breached Password playbook](/docs/secure/attack-protection/playbooks/breached-password-playbook).

### Password spraying

Attackers try many commonly-used passwords ([TT1110.003](https://attack.mitre.org/techniques/T1110/003/)) to gain access to legitimate user accounts. These often trip Auth0’s brute force protections and leave many `fp`, `fu`, and `fcoa` log events in your logs.

### Credential stuffing

Credential stuffing ([TT1110.004](https://attack.mitre.org/techniques/T1110/004/)) is most effective when used against tenants that employ passwords but no additional factors. By taking advantage of password leaks and attempting to log in to a victim’s account using a dictionary of leaked passwords, credential stuffing attacks generate `fp` log events and `pwd_leak` log events.

### Signup attacks

Attackers can attempt to sign up for a large number of accounts in a short window of time as part of a username enumeration attack ([T1087](https://attack.mitre.org/techniques/T1087/)), where attackers attempt to see whether a user account exists on your tenant or signup fraud campaigns. The goal is to create many accounts to take advantage of signup incentives or create aged accounts for later attacks. Signup attacks generate `fs`, `ss` and `signup_pwd_leak` log events.

### Detection using the Auth0 Management API

The [Auth0 Management API](/docs/deploy-monitor/logs/retrieve-log-events-using-mgmt-api) allows tenant logs to be queried using [log search query syntax](/docs/deploy-monitor/logs/log-search-query-syntax) for log types in the time range of interest. More advanced use cases are supported by log aggregation tooling like data warehouses or SIEMs by leveraging Auth0 log streams.

When using the Auth0 <Tooltip tip="Management API: A product to allow customers to perform administrative tasks." cta="View Glossary" href="/docs/glossary?term=management+API">management API</Tooltip>, the potential attack timeframe is specified as `date:[startdate to enddate]` in `YYYY-MM-DD` format. For example, `2024-10-01`. Use `*` to represent the current date.

By limiting the time of interest to a potential attack window, you can retrieve all log events of the type you’re interested. Below is an example query that searches for brute force attacks from October 1, 2024 to the present:

```text wrap lines theme={null}
date:[2024-10-01 TO *] AND (type:"f" OR type:"fu" OR type:"fp" OR type:"pwd_leak" OR type:"limit_wc" OR type:"limit_sul" OR type:"limit_mu" OR type:"fcoa")
```

For advanced analysis or to correlate login activities with applications outside Auth0, enable log streaming to the external tool of your choice. Review the [Management API documentation](https://auth0.com/docs/api/management/v2/logs/get-logs) to understand how to extract a subset of log events from your tenant for analysis.

#### Mitigation strategies

For optimal protection from attacks, consider the following strategies:

* Enable [Breached Password Detection](/docs/secure/attack-protection/breached-password-detection) or Credential Guard to protect against breached credentials with minimal user friction, noting that neither protects against dictionary attacks.
* Activate CAPTCHA for one or more flows and increase CAPTCHA frequency as needed, but remember that CAPTCHA is a deterrent, not a solution.
* Change your CAPTCHA provider if attackers bypass your current CAPTCHA or consider migrating to Auth0's Auth Challenge or another [supported provider](/docs/secure/attack-protection/bot-detection/configure-captcha).
* Temporarily disable account creation by everyone, including malicious actors.
* Change your web application firewall rules with an edge provider, or use [tenant access control lists](/docs/secure/tenant-access-control-list), to block abusive IPs, autonomous system numbers, geographic locations, [TLS clients](/docs/customize/custom-domains/self-managed-certificates/tls-ssl), or HTTP header elements like `user-agent` strings, and consider employing a [reverse proxy.](/docs/customize/custom-domains/self-managed-certificates#configure-reverse-proxy)
* Tighten [Brute Force](/docs/secure/attack-protection/brute-force-protection) and [Suspicious IP](/docs/secure/attack-protection/suspicious-ip-throttling) thresholds to reduce allowed connection limits and mitigate brute-force attacks.
* If your application does not rely on the [Cross-Origin Authentication](/docs/authenticate/login/cross-origin-authentication) endpoints (for example, you only use Universal Login, or your embedded flows use the OAuth 2.0 Token endpoint directly), disable those endpoints when you see frequent `fcoa` and `scoa` events to remove unused attack surface.
* Enforce [step-up MFA](/docs/secure/multi-factor-authentication/step-up-authentication) for compromised accounts, up to and including requiring <Tooltip tip="Multi-factor authentication (MFA): User authentication process that uses a factor in addition to username and password such as a code via SMS." cta="View Glossary" href="/docs/glossary?term=MFA">MFA</Tooltip> for potentially compromised accounts.
* Migrate to stronger MFA options by replacing SMS or voice-based MFA with [OTP](/docs/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-otp-notifications-for-mfa) or [Webauthn](/docs/secure/multi-factor-authentication/fido-authentication-with-webauthn/configure-webauthn-device-biometrics-for-mfa) to mitigate SMS pumping or toll fraud attacks.
* Implement SMS/voice provider security fraud protection like Twilio's [Preventing Fraud in Verify](https://www.twilio.com/docs/verify/preventing-toll-fraud) when using SMS/voice MFA.