---
title: AWS root account activity
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: Docs > Datadog Security > OOTB Rules > AWS root account activity
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# AWS root account activity
Classification:attackTactic:[TA0001-initial-access](https://attack.mitre.org/tactics/TA0001)Technique:[T1078-valid-accounts](https://attack.mitre.org/techniques/T1078) 
## Goal{% #goal %}

Detect AWS root account console logins, sensitive-service writes, and read or write activity originating from malicious or suspicious IP addresses.

## Strategy{% #strategy %}

This rule monitors AWS CloudTrail for high-signal activity where `@userIdentity.type` is `Root` and the event was not invoked by an AWS service or a SAML provider. AWS best practices strongly discourage root account usage. Legitimate administrative work should use IAM roles, so root logins, sensitive-service writes, and activity from threat-intelligence-flagged IPs warrant investigation.

### Severity tiers{% #severity-tiers %}

Activity is bucketed and severity is calibrated to the risk of the observed behavior:

| Severity | Condition                                                                                                                                                                                                                                                 |
| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Critical | Activity from an IP flagged `malicious` by threat intel                                                                                                                                                                                                   |
| High     | Successful console login                                                                                                                                                                                                                                  |
| Medium   | Write activity against sensitive services (IAM, Organizations, CloudTrail, Config, KMS, Secrets Manager, SSM, S3, EC2, Route 53, CloudFormation, GuardDuty, Security Hub, Lambda); write or read activity from an IP flagged `suspicious` by threat intel |
| Low      | Five or more failed console logins within five minutes                                                                                                                                                                                                    |

Buckets are evaluated top-to-bottom and the first match determines severity, so the highest applicable tier always wins. Isolated failed console logins do not generate a signal; the Low case requires at least five failures within the five-minute evaluation window.

### Assumed-root sessions{% #assumed-root-sessions %}

The rule also covers **assumed-root sessions** (`@userIdentity.sessionContext.assumedRoot:true`), produced by AWS Centralized Root Access Management when a delegated administrator calls `AssumeRoot` against a member account. Assumed-root activity is matched by the same severity tiers, so an assumed-root write to IAM is Medium.

There is no dedicated case for assumed-root activity. `AssumeRoot` sessions are limited to task-scoped policies, and they generate a signal only when they match the sensitive-service or threat-intelligence cases above. Filter on `@userIdentity.sessionContext.assumedRoot` to identify the access path.

## Triage and response{% #triage-and-response %}

1. Determine whether the root API call `{{@evt.name}}` is expected, and whether account `{{@userIdentity.accountId}}` has a documented business justification for root access within an approved change window.
1. Establish **which access path** was used. If the signal is an assumed-root session, this was a delegated `AssumeRoot` call, not use of a literal root credential. Identify and validate the calling principal, and revoke the `AssumeRoot` grant if it wasn't authorized. Do **not** start by rotating root credentials in this case.
1. Check the source IP `{{@network.client.ip}}` against known corporate egress ranges, VPN ranges, and threat intelligence. For **Critical** (malicious IP) signals, treat the session as compromised and begin containment immediately rather than starting with justification review.
1. Review `@eventSource` and `@evt.name` to identify which services and API calls were invoked, and assess the impact of any writes. Sensitive-service writes (Medium) warrant a review of the specific resource changed.
1. Review IAM activity in the same timeframe for privilege escalation, new user or access key creation, or policy changes indicating the session was used to establish persistence.
1. If the activity was not legitimate and a literal root credential was used, rotate the root credentials, enforce MFA on the root user, and open an investigation.

- For best practices, check out the [AWS Root Account Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) documentation.
- For centralized root access, check out the [AWS Centralized Root Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html) documentation.
- For compliance, check out the [CIS AWS Foundations Benchmark controls](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls.html) documentation.

## Changelog{% #changelog %}

- 17 August 2026 - Removed broad Info-level read and write activity cases to avoid signals for routine activity from trusted networks.
- 4 August 2026 - Updated rule queries, cases, and severities; added subtechnique tag T1078.004.