AWS AssumeRole Monitoring: Detecting Unauthorized Cross-Account Access

Every time an IAM principal assumes a role — either within the same account or across accounts — CloudTrail records an AssumeRole event. Monitoring these events reveals who is accessing what resources through which roles, from which IP addresses, and at what times. Deviations from normal patterns are often the first signal of compromise: stolen credentials being used to assume roles they shouldn't, automated systems accessing accounts outside their normal scope, or configuration errors enabling unintended access.

AssumeRole monitoring is distinct from general IAM monitoring because role assumption changes the effective identity performing actions. When a compromised IAM user assumes an administrator role, all subsequent actions appear under the role's identity in CloudTrail unless you specifically correlate the AssumeRole event to the original user identity.

What CloudTrail Records for AssumeRole

The AssumeRole CloudTrail event includes:

• userIdentity: The calling principal (who is assuming the role)
• requestParameters.roleArn: The role being assumed
• requestParameters.roleSessionName: The session name (often contains the username or system name)
• sourceIPAddress: The IP address the assumption was made from
• responseElements.credentials: The temporary credentials issued (access key ID only — never the secret)
• errorCode: Present if the assumption failed (AccessDenied, MalformedPolicyDocument, etc.)

The temporary credentials issued by AssumeRole have a short expiration (typically 1-12 hours). Subsequent actions performed with these credentials appear in CloudTrail with the assumed role's identity. To correlate subsequent actions back to the original assuming principal, match the access key ID from the AssumeRole response to the access key used in subsequent CloudTrail events.

Building AssumeRole Monitoring

The primary use cases for AssumeRole monitoring and the corresponding detection logic:

High-privilege role assumption from unexpected sources: Define which principals should be able to assume your most sensitive roles (break-glass admin roles, security audit roles, deployment roles). Alert when any assumption of these roles occurs from a principal not on the approved list.

EventBridge rule to detect break-glass role assumption:

{
  "source": ["aws.sts"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": ["AssumeRole"],
    "requestParameters": {
      "roleArn": ["arn:aws:iam::*:role/BreakGlassAdministrator"]
    }
  }
}

Failed assumption attempts: Repeated AssumeRole failures (AccessDenied) against specific roles may indicate credential testing or an attacker trying to determine which roles a compromised credential can assume. Alert when a specific principal has more than 5 AssumeRole failures within 10 minutes.

Cross-account assumption from external sources: Any AssumeRole event from a source account that isn't in your AWS Organization or approved partner list should trigger investigation. This may indicate a misconfigured trust policy or an attacker using stolen credentials from an external source account.

After-hours assumption of human-access roles: Roles designated for human administrative access that are assumed at 3 AM warrant investigation. Automation that runs continuously should use dedicated automation roles, not human access roles. After-hours assumption of human roles is either someone working late (notify and verify) or credential compromise (investigate immediately).

Correlating AssumeRole Chains

Complex cross-account architectures involve chains of role assumptions: an engineer assumes a bastion role, which assumes a target account role, which assumes a service role. Tracking actions back through this chain requires correlating AssumeRole events at each hop.

CloudTrail's userIdentity field for actions taken with assumed credentials includes a sessionContext that references the original principal. The chain can be reconstructed: the action event contains the assumed role identity; the assumed role session was created by an AssumeRole event (visible in the target account's CloudTrail); that AssumeRole event shows the original calling principal in its userIdentity field.

AWS CloudTrail Lake's advanced query capabilities handle multi-hop correlation better than standard Athena queries. If you're investigating complex attack chains that involve multiple role assumptions, CloudTrail Lake's event data store with its JOIN capabilities across events is the right tool.

Service-Linked Role vs. Regular Role Assumptions

AWS services (EC2, Lambda, ECS) assume service-linked roles automatically when performing actions on your behalf. These assumptions generate CloudTrail events but represent normal service operation. Distinguish service-linked role assumptions (expected, high-volume) from regular role assumptions (potentially unexpected) in your monitoring to avoid alert fatigue.

Filter service-linked role assumptions by checking whether the roleArn contains aws-service-role in the path. Create monitoring rules that specifically target non-service-linked roles for anomaly detection. Service-linked role assumptions should be monitored for anomalies separately — they shouldn't be assumed from unusual geographic locations or at unusual times either.

Integration with Vigilare Monitoring

Vigilare processes CloudTrail AssumeRole events across all monitored accounts, correlating assumption patterns to detect deviations from baseline behavior. The baseline tracks which principals normally assume which roles, from which IP ranges, and at what times. Deviations — a new source IP, an unusual role assumption, anomalous volume — surface as findings in the Vigilare dashboard with context to assess whether the pattern represents a true security concern or a legitimate change to your environment.

Related Reading

• Cross-account access — the trust policy model that governs what AssumeRole allows
• CloudTrail alerting — building EventBridge rules for CloudTrail events
• IAM security monitoring — comprehensive IAM activity monitoring
• AWS cloud forensics — tracing role assumption chains during incident investigation

FAQ

Does the target account CloudTrail see AssumeRole events or just the resulting actions?

Both. When a principal in Account A assumes a role in Account B, the AssumeRole API call appears in Account A's CloudTrail (the account making the API call) and also in Account B's CloudTrail (the account where the role exists). Subsequent actions taken with the assumed credentials appear in Account B's CloudTrail under the assumed role's identity. Centralizing CloudTrail from all accounts to a single location makes it easy to correlate assumption events with subsequent actions regardless of which account generated each event.

What's the maximum duration for an AssumeRole session?

The maximum session duration is configured on the role (1-12 hours, default 1 hour). When assuming the role, the requester can specify a duration up to the role's maximum. Roles used for automation should have shorter durations (1 hour); roles for human access patterns that might span a workday can have longer durations. Shorter session duration limits the window during which stolen session credentials remain valid.

Can I see when a role's assumed session expired?

You can determine when a session expires from the expiration time in the AssumeRole response, which is logged in the event's responseElements. There's no explicit "session expired" CloudTrail event — the session simply stops working after the expiration time. If you need to know when the last action was taken with a specific session, query CloudTrail for the maximum timestamp of events using the session's access key ID.