Account Takeover Protection

ASM provides account takeover (ATO) protection to detect and mitigate account takeover attacks.

ATO protection has the following benefits:

  • Block attackers and disable users.
  • Identify targeted and compromised users.
  • Differentiate existing users from non-existing users.
  • Cluster attackers into logical groups for mitigation.

Account takeover protection overview

Account takeover occurs when an attacker gains access to a user’s account credentials and assumes control of the account.

The following tables lists the attacker motivation by business:

Monetary TheftReselling Accounts
Consumer banking appsSaaS Platforms
Financial service apps that issue credit cardsConsumer platforms with stored gift cards

Attacker strategies

Attacks use publicly available automated tools to compromise a user’s account credentials. The sophistication and scale of these tools have varying capabilities.

Here are some common strategies:

Credential stuffing
An automated cyberattack where stolen account credentials (usernames, email addresses, passwords, and so on) are used to gain unauthorized access to user accounts. Access is gained through large scale automated login requests directed against a web application.
Credential stuffing relies on credential dumps.
Credential dumps
Credential dumps occur when stolen credentials from a security breach are posted publicly or sold on dark web markets. This often results in the release of a large number of usernames, passwords, and other account details.
Credential cracking
Credential cracking involves attempting to decipher a user’s password by systematically trying different combinations of passwords until the correct one is found. This method often uses software tools that apply various password guessing techniques.
Brute force
Brute force is a trial-and-error method used to obtain information such as a user password or personal identification number (PIN). In this attack, automation is used to generate consecutive guesses and gain unauthorized access to a system.

Setting up ATO detection and prevention

ASM provides managed detections of ATO attacks.

Effective ATO detection and prevention requires the following:

  1. Instrumenting your production login endpoints. This enables detection with ASM-managed rules.
  2. Remote configuration. This enables blocking attacks and pushing remote instrumentation from the Datadog user interface.
  3. Notifications. Ensures you are notified of compromised accounts.
  4. Reviewing your first detection. Understand how automated protection fits in with your attacks and escalation requirements.

Instrumenting your production login endpoints

The following user activity events are used for ATO tracking.

EnrichmentAuto-instrumentedUse case
users.login.successTrueAccount takeover detection rule requirement
users.login.failureTrueAccount takeover detection rule requirement
users.password_resetFalseDetection rule requirement to identify user enumeration through password reset

Those enrichment need to hold a user identifier (unique to a user, numeric or otherwise) as usr.id. In the case of login failures, it also needs to know whether the user existed in the database or not (usr.exists). This helps identifying malicious activity that will regularly target missing accounts.

For steps on enabling tracking for events that are not automatically instrumented, go to User Monitoring and Protection.

For the latest list of relevant detections and instrumentation requirements, go to Detection Rules page.

Automatic instrumentation is a Datadog capability that automatically identifies user login success and failure for many authentication implementations.

You are not limited to how Datadog defines these enrichments. Many platform products opt to add additional enrichments, such as identifying the customer organization or user role.

Remote Configuration

Remote Configuration enables ASM users to instrument apps with custom business logic data in near real time.

Notifications

Notifications are a flexible method to ensure the correct team members are informed of an attack. Collaboration Integrations with common communication methods are available out of the box.

Review your first detection

ASM highlights the most relevant information and suggests actions to take based on the detection type. It also indicates what actions have been taken.

An Account Takeover signal showing different highlighted areas of interest

Compromised Users

Compromised and targeted users can be reviewed and blocked within Signals and Traces.

Signals

Individual users can be blocked in Signals using Targeted Users.

Compromised users shown on a security signal

Traces

Individual users can be blocked on Traces, in User. Click on any user to show this option.

Compromised users shown in the security trace explorer

Best practices for signal review and protection

Review the following best practices to help you detect and mitigate account takeover attacks.

Develop an incident response plan

Review the following sections to help you develop an incident response plan.

Do you use authenticated scanners?

Identify trusted IPs, preventing them from being automatically blocked. This step is useful for the following:

  • Approved scanning sources that attempt to log in.
  • Corporate sites with large numbers of users behind single IP addresses.

To configure trusted IPs, use Passlist and add a Monitored entry. Monitored entries are excluded from automated blocking.

Monitored passlist

Know your customer authentication profile

Review the networks your customers authenticate from, such as:

  • Mobile ISPs
  • Corporate VPNs
  • Residential IPs
  • Data centers

Understanding authentication sources can inform your blocking strategy.

For example, you might not expect customers to authenticate with your consumer application from data centers. Consequently, you might have more freedom to block the IPs associated with that data center.

Nevertheless, if your customers source entirely from Mobile ISPs, you might have an impact to legitimate traffic if you block those ISPs.

Consider who your customers are, and their account name structure.

Do your customers match these attributes?

  • Employees with an expected ID format such as integers, corporate domains, or combinations of numbers and text.
  • SaaS customers using domain names associated with the customer company.
  • Consumers using free providers such as Gmail or Proton Mail.

Understanding your customers’ account name structure helps you determine if attacks are targeted or blind attempts at credential stuffing.

Distributed attacks

Blocking advanced distributed attacks is often a business decision because attacks can impact availability, user funds, and legitimate users.

Here are three critical components for success in mitigating these attacks:

  1. Proper onboarding: Are you configured for blocking with ASM?
  2. Proper configuration: Ensure you have correctly set client IPs and X-Forwarded-For (XFF) HTTP headers.
  3. Internal communication plans: Communication with security teams, service owners, and product leads is critical to understanding the impact of mitigating large scale attacks.
Responders can identify service owners using the tags in all ASM signals.

Use the Threats Overview to monitor business logic trends, such as spikes in failed logins against your services.

Threats Overview

Signal review

Review the following best practices for signals.

IP addresses

Use short durations for blocking attackers. 15 minutes or less is recommended. It is uncommon for attackers to reuse IP addresses in distributed account takeovers.

Data centers

Some attacks are launched using inexpensive virtual private servers (VPS) and hosting providers. Attackers are motivated by how their low cost and automation enables access to new IP addresses at the data center.

Many consumer applications have low occurrences of user authentication from data centers, especially low cost data centers and VPS providers. Consider blocking the entire data center or ASN when the network range is small, and not within your expected user authentication behavior.

Datadog uses third party data sources such as IPinfo and Spur to determine if an IP is a hosting provider. Datadog processes this data within Datadog infrastructure.

Proxies

Datadog uses Spur to determine if an IP is a proxy. Datadog correlates indicators of compromise (IOCs) with account takeover attacks for faster detection with the ASM-managed account takeover rules.

Datadog recommends never blocking IP addresses solely based on threat intelligence IOCs for IP addresses. See our threat intelligence best practices for details.

Details on IPs, including ownership and threat intelligence, are available in the IP address details. Click on an IP addresses to view these details.

Two types of proxies are frequently seen in distributed account takeovers:

  • Hosting proxies: Proxies that exist at data centers, and are often the result of a compromised host at that data center. Guidance for interacting with hosting proxies is similar to data centers.

  • Residential proxies: Proxies that exist behind residential IPs. Residential proxies are frequently enabled by mobile application SDKs or browser plugins. The user of the SDK or plugin is typically unaware that they are running a proxy. It is common to see benign traffic from IP addresses identified as residential proxies.

Mobile ISPs

Datadog uses third parties such as IPinfo and Spur to determine if an IP is a Mobile ISP.

Exercise caution when blocking Mobile ISPs. Mobile ISPs use CGNAT and frequently have large numbers of phones behind each IP address.

Attacker attributes

Use attacker attributes to target response actions.

Datadog clusters attackers by the similarity of their attributes. Responders can use custom rules to block the attributes of persistent attackers.

Protection

Review the following best practices for protection.

Automated protection

Evaluate the managed ruleset to determine which rules fit your internal automated blocking policies.

If you do not have a policy, review your existing detections and start with the suggested responses in Signals. Build your policy based on the most relevant actions taken over time.

Users

In Signals, the What Happened and Targeted Users sections provide examples of the attempted usernames.

The Traces section identifies if the users exist. Understanding if users exist can influence your incident response decisions.

Develop an incident response plan using the following post compromise steps:

  1. Monitoring compromised user accounts.
  2. Plan to invalidate credentials and contact users to update credentials.
  3. Consider blocking users using ASM.

Attack motivation can influence post-compromise activity. Attackers wanting to resell accounts are unlikely to use accounts immediately after a compromise. Attackers attempting to access stored funds will use accounts immediately after compromise.

Consider blocking compromised users in addition to blocking the attacker.

Further reading

PREVIEWING: rtrieu/product-analytics-ui-changes