- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- Administrator's Guide
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
ASM provides account takeover (ATO) protection to detect and mitigate account takeover attacks.
ATO protection has the following benefits:
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 Theft | Reselling Accounts |
---|---|
Consumer banking apps | SaaS Platforms |
Financial service apps that issue credit cards | Consumer platforms with stored gift cards |
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:
ASM provides managed detections of ATO attacks.
Effective ATO detection and prevention requires the following:
The following user activity events are used for ATO tracking.
Enrichment | Auto-instrumented | Use case |
---|---|---|
users.login.success | True | Account takeover detection rule requirement |
users.login.failure | True | Account takeover detection rule requirement |
users.password_reset | False | Detection 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 enables ASM users to instrument apps with custom business logic data in near real time.
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.
ASM highlights the most relevant information and suggests actions to take based on the detection type. It also indicates what actions have been taken.
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.
Traces
Individual users can be blocked on Traces, in User. Click on any user to show this option.
Review the following best practices to help you detect and mitigate account takeover attacks.
Review the following sections to help you develop an incident response plan.
Identify trusted IPs, preventing them from being automatically blocked. This step is useful for the following:
To configure trusted IPs, use Passlist and add a Monitored
entry. Monitored entries are excluded from automated blocking.
Review the networks your customers authenticate from, such as:
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?
Understanding your customers’ account name structure helps you determine if attacks are targeted or blind attempts at credential stuffing.
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:
Use the Threats Overview to monitor business logic trends, such as spikes in failed logins against your services.
Review the following best practices for signals.
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.
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 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.
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.
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.
Review the following best practices for 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.
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:
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.