AttachUserPolicy in CloudTrail: Who Granted Which Policy to Whom

What it records

AttachUserPolicy attaches a managed policy to an IAM user. AWS’s documentation separates it from PutUserPolicy, which embeds an inline policy instead. The record from iam.amazonaws.com carries the two documented parameters, requestParameters.policyArn and requestParameters.userName, and the caller in userIdentity; responseElements is null in the recorded event, so the grant is described entirely by the request.

The policy ARN carries most of the meaning. AWS managed policies have aws where an account ID would be, arn:aws:iam::aws:policy/AdministratorAccess being the one attackers want, while a customer managed policy has the account’s ID and has to be read to know what it allows. In the recorded attack-simulation event, a user attaches AdministratorAccess to a user the same run had created.

When it matters

Attaching a policy is how a foothold becomes control of the account (MITRE ATT&CK T1098.003, additional cloud roles). Three shapes deserve attention:

• AdministratorAccess or IAMFullAccess attached to anyone outside the IAM team. IAMFullAccess is administrator-equivalent because it allows granting any other permission.
• A self-grant. requestParameters.userName equals the caller’s own user name.
• A fresh user. CreateUser, then AttachUserPolicy with a broad policy, then CreateAccessKey or CreateLoginProfile for the same user within minutes is a backdoor administrator being built.

The free log analyzer flags AdministratorAccess and IAMFullAccess grants as critical, and so does a customer managed policy created in the same log whose document allows every action on every resource. The validated Sigma rule LTR-0002 alerts on this and the related IAM calls from principals outside an allowlist of administrators.

How to investigate

1. Read who attached which policy to whom: userIdentity.arn, requestParameters.policyArn, requestParameters.userName.
2. For a customer managed policy, find its document in the CreatePolicy or CreatePolicyVersion call that defined it, or in IAM.
3. Check the receiving user’s history: when it was created and by whom, and whether keys or a console password were added afterwards.
4. Follow the caller’s key across the hour around the grant, then detach the policy if it is not explained.

Policy grants to users in Microsoft Sentinel, with AWS managed policies and self-grants marked:

AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName == "AttachUserPolicy" and isempty(ErrorCode)
| extend Request = parse_json(RequestParameters)
| extend PolicyArn = tostring(Request.policyArn), TargetUser = tostring(Request.userName)
| extend PolicyName = extract(@"([^/]+)$", 1, PolicyArn),
    AwsManaged = PolicyArn startswith "arn:aws:iam::aws:policy/",
    SelfGrant = TargetUser == UserIdentityUserName
| project TimeGenerated, UserIdentityArn, TargetUser, PolicyName, AwsManaged, SelfGrant, SourceIpAddress, UserAgent
| order by TimeGenerated desc

Broad AWS managed policies attached to users, roles or groups:

AWSCloudTrail
| where TimeGenerated > ago(30d)
| where EventName in ("AttachUserPolicy", "AttachRolePolicy", "AttachGroupPolicy") and isempty(ErrorCode)
| extend PolicyArn = tostring(parse_json(RequestParameters).policyArn)
| where PolicyArn in ("arn:aws:iam::aws:policy/AdministratorAccess", "arn:aws:iam::aws:policy/IAMFullAccess")
| project TimeGenerated, EventName, UserIdentityArn, PolicyArn, RequestParameters, SourceIpAddress

In Athena, over a table on the trail’s S3 bucket (named cloudtrail_logs here):

SELECT eventtime, useridentity.arn AS granted_by,
       json_extract_scalar(requestparameters, '$.userName') AS target_user,
       json_extract_scalar(requestparameters, '$.policyArn') AS policy_arn, sourceipaddress
FROM cloudtrail_logs
WHERE eventname = 'AttachUserPolicy' AND errorcode IS NULL
ORDER BY eventtime DESC
LIMIT 200;