Look for unusual user agents, source IPs from unexpected hosting providers, and repeated API calls from the same key that do not match normal operator behaviour. Rare enumeration actions such as GetCallerIdentity from multiple access keys, or odd service calls like SES quota checks, are especially useful signals because they often expose attacker reconnaissance rather than routine administration.
What points to AWS key abuse rather than normal administration
The strongest indicators are behavioural, not just technical. access key used from unfamiliar geographies or cloud hosting ranges, with user agents that do not match your normal tooling, often indicate scripted activity. Repeated calls from one key across many services or accounts, especially outside expected maintenance windows, are another clear sign that the key is being driven by an adversary rather than an operator.
High-signal clues are often small, but they cluster: enumeration, recon, and follow-on privilege use tend to appear together. A key that suddenly begins invoking low-frequency discovery calls, checking permissions, or probing service limits is behaving differently from routine application traffic.
- Unusual user agents, SDK versions, or automation fingerprints
- Source IPs from hosting providers, VPNs, or regions the key never normally uses
- Bursts of API calls from one access key across multiple services
- Repeated read-only discovery actions that do not fit the key’s normal role
- Credential use shortly after exposure events, such as code leaks or config leaks
Why these signals matter to investigators
AWS key abuse usually starts with reconnaissance and quickly moves toward persistence or monetisation. Attackers want to learn what the key can reach, whether it has broader permissions than expected, and whether they can blend into ordinary cloud activity long enough to expand access. Signals like GetCallerIdentity from multiple keys, quota checks, and other uncommon service probes matter because they often reveal that the actor is mapping the environment before taking louder action.
Those behaviours are especially useful when they do not align with the key owner’s normal workflow. A key used by an application or automation job should usually show consistent endpoints, consistent timing, and a narrow set of API calls. When that pattern breaks, the key may be compromised even if no destructive action has happened yet.
For broader context on how compromised cloud credentials are used in real incidents, see AI LLM hijack breach, Codefinger AWS S3 ransomware attack, and Ultimate Guide to NHIs, Key Challenges and Risks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl and Exposure | AWS access key abuse often starts with exposed or stolen secrets. |
| NHI-04 — Privilege Creep and Excessive Permissions | Abuse impact depends on how much the key can do once stolen. | |
| NHI-06 — Detection and Monitoring | Unusual API calls, IPs, and user agents are core abuse indicators. | |
| Recommendation — Track exposed AWS keys as high-risk secrets and rotate them immediately. Reduce access key permissions to the minimum required for the workload. Alert on anomalous key usage patterns and unusual service enumeration. | ||
| MITRE ATT&CK | T1580 — Cloud Infrastructure Discovery | Enumeration-style calls from a key often indicate cloud reconnaissance. |
| T1528 — Steal Application Access Token | Stolen AWS credentials are a common initial access mechanism. | |
| T1087 — Account Discovery | GetCallerIdentity-like probing is used to learn what identity is in use. | |
| Recommendation — Hunt for cloud discovery activity that deviates from known key behaviour. Monitor for credential theft paths that can feed cloud access key abuse. Correlate identity discovery calls with subsequent access expansion attempts. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Abuse signs are surfaced through ongoing behaviour monitoring and alerting. |
| PR.AC — Access Control Management | Key abuse risk is shaped by whether privileges are scoped and managed well. | |
| Recommendation — Continuously monitor cloud API activity for anomalous access key use. Limit access key permissions and remove standing access where possible. | ||
| CIS Controls v8 | 6 — Access Control Management | Account and key abuse is reduced by disciplined access management. |
| 8 — Audit Log Management | Detection depends on preserving cloud audit events for unusual key behaviour. | |
| Recommendation — Review and revoke unused cloud credentials and tightly scope active ones. Centralise and retain API logs needed to spot access key abuse. | ||
Practitioner Guidance
What to verify: Compare the access key’s current activity against its historical baseline for source IP, user agent, service mix, and time of day. If the key suddenly shows enumeration or cross-service access, treat that as stronger evidence than a single failed login or one odd request.
Decision rule: If the key is performing calls that were never part of its intended function, prioritise containment and rotation before spending time proving intent. The practical question is not whether abuse is certain, but whether the key’s current behaviour creates enough blast radius to justify immediate action.
What practitioners underestimate: Attackers often begin with quiet discovery, so the first visible signal may be a harmless-looking API call rather than an obvious impact event. That is why you should look for pattern breaks across many requests, not just one suspicious request in isolation.
Practitioner takeaway: The most useful indicator is a deviation from the key’s normal behavioural profile, especially when discovery-style calls and unfamiliar infrastructure appear together.
To align detection with recognised control guidance, compare your logging and account monitoring approach with OWASP Non-Human Identity Top 10, MITRE ATT&CK Enterprise Matrix, and CIS Controls v8.
Related resources from NHI Mgmt Group
- How should security teams detect cloud account abuse when attackers use valid AWS access keys to create persistence?
- Why does long lived AWS key abuse create such high persistence risk in cloud environments?
- Why does expanding remote access increase the likelihood of credential abuse?
- What happens when malicious actors abuse Microsoft Teams and OneDrive access during an account takeover campaign?
