Common warning signs include console logins from atypical geographies, missing MFA, unexpected use of the aws-cli, and API calls such as UpdateLoginProfile, CreateUser, CreateAccessKey, and AttachUserPolicy. A newly created user requesting service quota increases is another strong indicator. Taken together, these signals suggest account takeover or hands-on-keyboard activity rather than routine administration.
How AWS IAM User Abuse Usually Shows Up
An attacker who has taken over an AWS IAM user often behaves differently from a normal operator, even when they try to blend in. The strongest indicators are activity shifts that do not match the user’s history, such as unexpected login origin, new tooling, privilege changes, or rapid attempts to expand access before defenders can respond.
Look for the pattern, not a single event. A lone unusual API call can be legitimate, but a cluster of login anomalies, privilege edits, and account-creation activity is much more consistent with real-world credential abuse patterns than with routine administration. When the actor is trying to persist, they often move quickly from initial access to policy manipulation.
For cloud-specific attack paths, misuse often includes creating new keys, changing login profiles, attaching policies, or testing whether the account can request higher service limits. Those actions are attractive because they turn a single stolen user into durable access and broader control. A useful reference point is the AWS account compromise and crypto-mining case pattern, where stolen credentials were used to extend control rather than simply log in once.
In practice, the most meaningful signals are usually behavioural combinations: atypical geography, first-time use of aws-cli, console sessions at odd hours, and write actions against identity objects. The question is not only whether the account is active, but whether it is now being used to reshape its own permissions or create a fallback path for the attacker.
What Makes the Activity Suspicious to a Defender
The API calls in your direct answer are especially important because they target the account itself. UpdateLoginProfile can signal a takeover attempt to establish a console foothold, CreateAccessKey can add a second authentication path, AttachUserPolicy can expand permissions, and CreateUser can help an attacker build a new persistence layer. These are not just administrative verbs, they are access-shaping actions.
Unexpected use of the aws-cli matters for the same reason. Attackers often prefer programmatic access once they have stolen a session or key, because it is easier to automate enumeration, privilege checks, and follow-on abuse. When that activity appears alongside login anomalies or new key creation, the case for misuse becomes much stronger than when any one indicator appears alone.
- Correlate CloudTrail identity events with source IP, user agent, and first-seen region.
- Check whether the user suddenly began performing access-management actions on itself.
- Review whether the account is newly created, newly activated, or newly granted policy attachments.
- Look for service quota increase requests as a sign of planned scale-out or monetisation.
For broader threat context, attacker tradecraft around credential theft and privilege expansion is well represented in CISA cyber threat advisories, which are useful for mapping suspicious identity activity to active campaign patterns rather than treating each event as isolated noise.
A practical threshold is whether the user is only consuming resources or is also changing the identity plane. Once an IAM user starts creating keys, editing login settings, or attaching policies that it did not previously use, assume the priority has shifted from investigation to containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1078 — Valid Accounts | Stolen IAM user activity reflects abuse of valid credentials and sessions. |
| T1098 — Account Manipulation | Creating keys, changing login profiles, and attaching policies alter the account for persistence. | |
| Recommendation — Map the activity to T1078 and hunt for follow-on privilege and persistence actions. Map self-modification events to T1098 and alert on unauthorized account changes. | ||
| CIS Controls v8 | 5 — Account Management | Suspicious IAM user misuse is best reduced by controlling account creation, review, and deprovisioning. |
| 6 — Access Control Management | The misuse signals center on excessive or newly expanded access and policy attachment. | |
| Recommendation — Apply CIS Control 5 to review, restrict, and remove unnecessary IAM user access paths. Apply CIS Control 6 to detect and revoke unauthorized policy and privilege changes. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The question is about recognising compromised identity behaviour and access abuse. |
| Recommendation — Strengthen PR.AA monitoring to flag anomalous AWS IAM user authentication and authorization events. | ||
Practitioner Guidance
What to prioritise: Treat identity-changing API calls as higher priority than ordinary read-only reconnaissance. If the user is creating access keys, updating login profiles, or attaching policies, rotate or disable the account path before spending time proving intent.
What to verify: Validate whether the source IP, region, user agent, and time of day fit the user’s normal pattern, and confirm whether MFA was present on the console path. If the account suddenly appears through aws-cli after being console-only, that shift is often more useful than the raw volume of calls.
Decision rule: If the account is newly created or newly modified and immediately requests quota increases, treat it as likely abuse until proven otherwise. That combination usually indicates the attacker is preparing for scale, persistence, or resource consumption, not performing ordinary setup work.
Practitioner takeaway: The most reliable signal is not a single suspicious login, but a takeover sequence that moves from unusual access to self-modification and privilege expansion. When you see that sequence, act on containment first and attribution second.
Related resources from NHI Mgmt Group
- What is LLMjacking in an IAM context?
- Why does creating a new IAM user with administrator access create such high risk in AWS environments?
- What are the early signs that AWS IAM role exploitation is already happening?
- What are the signs that AWS IAM Identity Center access reviews are not working properly?
