Distributed Credential Stuffing campaign (attacker fingerprint)

This page is not yet available in Spanish. We are working on its translation.
If you have any questions or feedback about our current translation project, feel free to reach out to us!

Goal

Detect Account Takeover (ATO) attempts on services. ATO attempts include brute force, dictionary, and distributed credential stuffing attacks.

This detection rule is designed to detect distributed credential stuffing campaigns, where an attacker uses many IP addresses to attempt to log into different accounts using stolen password lists. The attacker will often try a single password per account, and may make a few login attempts with each individual IP address.

Required business logic events

Datadog auto-instruments many event types. Review your instrumented business logic events. This detection requires the following instrumented events: users.login.failure with usr.id populated.

Strategy

Monitor login events and track the number of failed login attempts from a given network range (ASN) with a given user agent. Generate a Medium severity signal when the rate of login failures deviate from historical trends. Datadog requires a number of users to be logged in and associated with multiple IP addresses to be attempting logins. This helps deduplicate any non-distributed signals (such as brute force and credential stuffing) that may appear.

If we detect login successes from the same network range and user agent, the signal severity is raised to High.

The monitored login attempts exclude local IPs, common ISPs, programmatic ranges, unless the IP address has been identified for malicious activity in the past. This helps reduce false positives.

Triage and response

  1. Review the activity of the signal to confirm whether the activity is unusual.
  2. Create a custom WAF rule to block on those attributes if possible. Double-check that you are seeing actual illegitimate activity from this ASN and user agent. Attackers will often try to fake legitimate activity (for instance, pretend to be the customer’s mobile application) in order to be harder to identify.
  3. If the severity has increased, review any successful logins. Those accounts may be compromised and should be blocked until the passwords are reset.
PREVIEWING: rtrieu/product-analytics-ui-changes