AWS access key compromise detection exposes the limits of long-term keys

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Wazuh's blog post: Native AWS telemetry can detect access key compromise by correlating validation, enumeration, persistence, and exfiltration activity.

Why it matters: It matters because access keys are IAM identities in practice, so identity teams need detection and prevention controls that treat stolen keys as valid access, not just suspicious log noise.

Context

AWS access keys are non-human credentials that can authenticate applications, users, and automation to AWS services. Once exposed, they inherit the permissions of the IAM identity they belong to, which means abuse often looks like legitimate API activity unless the surrounding telemetry is correlated.

The governance problem is not only secret exposure but also attribution under valid identity use. CloudTrail records the API trail, GuardDuty adds behavioural findings, and Wazuh correlates both so teams can separate ordinary service activity from a stolen key being exercised at runtime.

Key questions

Q: What breaks when AWS configuration files expose access keys?

A: When AWS configuration files expose access keys, the attacker inherits the workload’s identity and can often authenticate without triggering traditional login controls. If the credential is over-privileged, the incident quickly moves from exposure to escalation, lateral movement, and data theft. Treat the file as an identity-bearing object, not just a configuration artifact.

Q: Why do long-lived access keys increase risk in cloud environments?

A: Long-lived keys create standing access that is easy to reuse, hard to govern, and difficult to revoke at scale. If they are embedded in code or shared across teams, compromise can lead to broad access that persists until manually cleaned up. Temporary roles and federated identity reduce exposure and make access far easier to control.

Q: How can security teams tell whether AWS key abuse is progressing from validation to persistence?

A: Look for a sequence that starts with sts:GetCallerIdentity or sts:GetSessionToken, moves into repeated read-only discovery and AccessDenied bursts, and then includes key-creation or user-policy changes. That pattern shows an attacker moving from proof of access to control expansion.

Q: Should teams treat CloudTrail and GuardDuty as separate controls or one detection chain?

A: Treat them as one detection chain. CloudTrail supplies API evidence, GuardDuty adds anomaly context, and correlation turns both into an incident narrative that is much harder to dismiss than isolated alerts. Separate handling usually leaves the attacker’s validation and enumeration steps under-read.

Technical breakdown

How AWS access key compromise becomes valid IAM activity

An AWS access key is composed of an access key ID and a secret access key, and together they authenticate a caller as the associated IAM identity. That identity may belong to an application, a user, or automation, so compromise is dangerous because the attacker does not need to break AWS authentication once the key is exposed. The key issue is identity reuse: the same credential that enables normal API calls also enables attacker-controlled API calls, often from a different IP, user agent, or command pattern. Practical implication: detection has to focus on the context around API activity, not the key value alone.

Practical implication: baseline API behaviour by identity so suspicious use stands out when the same key appears from a new context.

CloudTrail and GuardDuty as compromise signals

CloudTrail provides the who, what, and when of API activity, which makes it the primary evidence source for access-key abuse. GuardDuty adds higher-level findings by inspecting CloudTrail, VPC Flow Logs, and DNS logs for anomalous behaviour, including credential exfiltration patterns. Wazuh sits above those services, ingests their output, decodes the records, and applies correlation rules so multiple weak signals become one incident view. That matters because single events such as a lone validation call or a read-only list request are easy to miss in isolation. Practical implication: correlation is the control layer that turns telemetry into detection.

Practical implication: centralise AWS telemetry correlation so isolated validation, enumeration, and exfiltration signals are not handled as unrelated events.

Why the attack chain is staged, not instantaneous

The article breaks compromise into validation, enumeration, persistence, and exfiltration. Validation confirms the key works, enumeration maps permissions with read-heavy calls and AccessDenied probes, persistence adds backup credentials or policy changes, and exfiltration is surfaced as anomalous S3 behaviour or heavy object reads. That sequence matters because the first three stages are directly reproducible through API calls, while exfiltration often depends on learned baselines inside GuardDuty. Practical implication: detection rules should be staged so security teams can catch the chain before an attacker turns access into durable control.

Practical implication: build separate detections for validation, enumeration, and persistence instead of waiting for exfiltration indicators alone.

Threat narrative

Attacker objective: The attacker aims to turn a stolen AWS key into durable authenticated access that can be used for discovery, persistence, and data exfiltration under the victim identity.

1. Entry occurs when a public repository, build pipeline, credential file, or compromised device exposes an AWS access key that can authenticate as a valid IAM identity.
2. Credential validation follows when the stolen key is tested with sts:GetCallerIdentity or sts:GetSessionToken, often from an unfamiliar IP address or scanner user agent.
3. Escalation and persistence appear through read-heavy enumeration, repeated AccessDenied probing, and account changes such as iam:CreateAccessKey, iam:CreateUser, or iam:AttachUserPolicy.
4. Impact is reached when the attacker exfiltrates data through heavy s3:GetObject activity or GuardDuty flags anomalous S3 behaviour linked to the abused identity.

Breaches seen in the wild

• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Long-term AWS keys create identity ambiguity, not just exposure risk: once an access key is copied, the attacker inherits the same API surface as the legitimate caller. That collapses the security value of the key itself, because AWS cannot distinguish intent from identity at the credential layer. The practitioner takeaway is that detection must move up to behaviour and context rather than trust the existence of a valid key.

Correlated telemetry is the control boundary for stolen keys: CloudTrail alone shows activity, GuardDuty alone shows suspicion, and neither is sufficient if treated in isolation. The article’s real value is in showing that compromise detection becomes reliable only when API calls, denied requests, and anomaly findings are stitched into one sequence. Practitioners should treat correlation as part of identity governance, not as an after-the-fact SOC convenience.

Staged detections outperform single-alert thinking in NHI compromise: validation, enumeration, persistence, and exfiltration are different control problems, even though they involve the same credential. The first three stages are visible as discrete API behaviours and can be detected before data loss, which is why long-lived keys are a governance problem as much as an incident-response problem. The practical conclusion is to map each stage to a distinct detection and response path.

Ephemeral access reduces the blast radius that long-term keys expand: the article reinforces that a stolen key is most dangerous when it can be reused without a narrow time boundary. That makes standing credential lifespan the decisive governance variable, because every additional hour of validity increases the chance that validation turns into persistence. Practitioners should measure key longevity as a risk multiplier, not an administrative convenience.

Access-key compromise is an NHI lifecycle failure, not only a secret-management failure: the problem begins when a long-term credential remains valid beyond the operational need that created it. The article shows how backup keys, policy changes, and read-heavy discovery extend that lifetime into active abuse. Practitioners should view rotation, revocation, and offboarding as the real control plane for AWS identities.

From our research library:

• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity governance for AWS keys now starts with lifetime, not just inventory: a valid key can behave like a live user account until it is revoked or expires. That means NHI programmes should treat access key lifespan, offboarding, and rotation as primary controls, not back-office hygiene.

Staged compromise detection is the right model for machine credentials: validation, enumeration, and persistence are distinct signals that deserve separate rules and response paths. When those stages are wired together, teams can act before exfiltration becomes the first visible symptom.

Long-lived access keys preserve attacker optionality: the same credential can support discovery, persistence, and theft if it remains usable long enough. Security teams should therefore measure how long privileged keys stay valid and how quickly exposure paths are removed.

For practitioners

• Use short-lived IAM roles instead of long-term access keys Replace standing access keys with role-based access where the workload or user can assume temporary credentials. That narrows the theft-to-abuse window and makes stolen credentials expire before they can be reused across multiple stages.
• Correlate CloudTrail and GuardDuty in one detection flow Ingest both telemetry sources into a single correlation pipeline so validation, enumeration, persistence, and anomaly findings are evaluated together. The article shows that isolated API calls are easy to dismiss when they are not stitched into one attack narrative.
• Detect validation and enumeration as separate stages Create rules for sts:GetCallerIdentity and sts:GetSessionToken from untrusted sources, then separate rules for repeated AccessDenied bursts and read-only discovery calls. That lets you intervene before the attacker creates backup credentials or starts exfiltration.
• Audit repository and CI/CD secret exposure paths Scan source control, build pipelines, credential files, and endpoint stores for committed AWS secrets, then remove anything that can authenticate directly to AWS APIs. Exposure in these paths turns a code or build problem into an identity compromise problem.
• Review trusted IP and service-identity allowlists regularly Keep the trusted IP list and service identity exclusions aligned to current egress ranges and integration accounts. Stale allowlists can either suppress genuine compromise alerts or flood analysts with activity from your own infrastructure.

Key takeaways

• AWS access keys are valid IAM identities, so exposure turns routine API access into a potential compromise path.
• The article shows that validation, enumeration, persistence, and exfiltration leave distinct AWS signals that can be correlated before takeover.
• Reducing key lifetime and correlating telemetry are the controls that most directly shrink the abuse window.

Key terms

• AWS Access Key ID: A public identifier for an AWS credential pair used to help route and identify the principal making a request. In this research context, the ID is not just a label. It can also encode account information, which means disclosure may help attackers correlate the credential with a specific AWS account.
• CloudTrail: CloudTrail is AWS’s audit logging service for recording API activity across an account. Security teams use it to track who did what, when, and from where, which supports detection, investigation, and compliance evidence. Its value depends on retention, alerting, and active review, not just log generation.
• GuardDuty Finding: A GuardDuty finding is a security alert generated when AWS detects behavior that may indicate misuse, compromise, or unusual activity. The finding typically includes event details, affected identities, and contextual signals that analysts use to determine whether the activity is expected, anomalous, or worth escalating.
• Authentication Correlation: Authentication correlation is the practice of linking login failures, source patterns, and timing across many identities to reveal attacks that look harmless in isolation. It is essential when adversaries spread attempts across users to stay below lockout thresholds.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.