TruffleNet shows how stolen AWS credentials turn IAM into abuse

At a glance

What this is: This is an analysis of how stolen AWS credentials are being validated and weaponized inside cloud environments, with SES abuse and reconnaissance as the downstream impact.

Why it matters: It matters because IAM, PAM, and NHI teams must treat cloud identity as an attack surface where standing privilege can be converted into fraud, exfiltration, and lateral abuse.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Apono's analysis of TruffleNet credential abuse in AWS

Context

Stolen AWS credentials are not just an authentication problem. Once attackers can validate an identity and inherit its standing permissions, AWS IAM becomes part of the attack chain rather than a control that interrupts it. In this case, the primary issue is credential abuse inside cloud infrastructure, with AWS SES and reconnaissance activity showing how quickly identity can be converted into operational abuse.

For IAM and NHI programmes, the lesson is straightforward: access scope, not just credential validity, determines the blast radius. If a compromised identity can call identity metadata, query mail quotas, or invoke downstream services, the organisation has already lost containment even before the attacker reaches the final objective.

Key questions

Q: How should security teams respond when stolen AWS credentials are being validated in real time?

A: Teams should treat validation activity as an active compromise signal, not a benign login attempt. Investigate the source, correlate it with recent secret exposure, disable the affected credential path, and review downstream permissions immediately. If the identity can reach services such as SES or discovery APIs, the blast radius is already larger than authentication alone suggests.

Q: Why do standing AWS permissions increase the impact of stolen credentials?

A: Standing permissions let an attacker do useful work as soon as credentials are accepted. That can include validating the identity, querying service limits, sending mail, or exploring the environment without needing to escalate first. The more durable the privilege, the more likely the attacker can turn one stolen secret into several stages of abuse.

Q: What breaks when SES permissions are too broad in AWS accounts?

A: Broad SES permissions turn a cloud identity into a messaging platform for abuse. An attacker who compromises the identity can send email, test quotas, and support business email compromise campaigns using legitimate infrastructure. That makes SES governance part of fraud prevention, not just email operations.

Q: Who is accountable when compromised cloud identity is used for business email compromise?

A: Accountability sits with the teams that govern identity scope, credential exposure, and service permissions across the cloud estate. IAM, security operations, and platform owners all have a role, because the abuse path usually depends on a permission decision made long before the incident. Regulatory and internal controls only work if those ownership boundaries are explicit.

Technical breakdown

How attackers validate stolen AWS credentials with GetCallerIdentity

GetCallerIdentity is a low-friction AWS STS call that returns the identity associated with credentials without requiring elevated permissions. That makes it useful for attackers who need to confirm whether stolen keys, tokens, or assumed-role credentials are live before investing in further activity. In this pattern, the validation step is operationally valuable because it separates dead secrets from active ones at scale. TruffleHog can automate the discovery and testing workflow, turning large volumes of exposed credentials into an efficient triage pipeline for abuse.

Practical implication: monitor identity-validation calls as an early signal of credential abuse and investigate unusual STS activity from newly observed sources.

Why AWS SES becomes an abuse channel after credential compromise

Simple Email Service is attractive to attackers because it can be used for outbound email abuse once the compromised identity has enough privilege. In practical terms, the attacker is no longer trying to break authentication. They are repurposing legitimate cloud services to send messages, test quotas, or support business email compromise campaigns. GetSendQuota queries are part of that operational pattern because they help reveal sending limits and service viability. The abuse is especially damaging when the compromised identity has standing rights that were never intended for mail operations.

Practical implication: separate mail-sending permissions from general AWS access and review which identities can interact with SES before they are compromised.

Standing privilege turns cloud identity into a springboard for reconnaissance

Once inside, attackers often shift from immediate abuse to reconnaissance. Cloud identity permissions can reveal what exists, what is reachable, and which services can be chained into later stages such as data theft or production disruption. That is why standing access is such a problem: the attacker inherits the original trust relationship and uses it as an internal discovery mechanism. The issue is not only stolen credentials. It is the persistence of usable privilege after compromise, which expands the attacker’s options far beyond the initial login.

Practical implication: reduce standing privilege and audit service-level permissions so a valid credential cannot double as an internal recon tool.

Threat narrative

Attacker objective: The attacker aims to turn compromised AWS identity into a reusable platform for email fraud, internal discovery, and follow-on abuse.

1. Entry begins with stolen AWS credentials that are tested at runtime using GetCallerIdentity and automation such as TruffleHog to identify valid access.
2. Escalation occurs when the valid identity is used to query SES quota and related AWS controls, turning ordinary cloud permissions into operational abuse.
3. Impact follows when the compromised environment is used for business email compromise and reconnaissance that can support later attacks against sensitive resources.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud identity is now an abuse platform, not just an access boundary. The attackers in this pattern are not exploiting a software flaw first; they are exploiting the authority embedded in valid AWS credentials. That shifts the problem from authentication failure to privilege reuse, where the same identity that can reach business services can also be used to support fraud and recon. Practitioners should treat AWS IAM as a live attack surface whose permissions shape the attacker’s next move.

Standing privilege is the control assumption this campaign breaks. Standing access was designed for identities whose permissions can be reviewed after use. That assumption fails when stolen credentials are validated and abused immediately, because the attacker operates inside the legitimate trust boundary before governance processes can respond. The implication is not simply tighter permissions, but a recognition that access review cycles are too slow to contain credential abuse once the identity is live.

SES abuse shows how non-human identities can become fraud infrastructure. AWS service access is often scoped for operational convenience, but attackers only need one identity with the wrong privileges to repurpose that access for business email compromise. This is a classic OWASP-NHI concern: overprivileged credentials create a cross-service blast radius that can move from identity validation to outbound abuse without changing tools. Practitioners should read this as a governance failure in privilege design.

TruffleNet is a name for a repeatable credential-hunting workflow, not a one-off campaign. The combination of exposed secrets, automated validation, and post-compromise service abuse is exactly the kind of chain that scales across cloud tenants. It aligns with OWASP Non-Human Identity Top 10 concerns around secret exposure and privilege misuse, and with ZT-NIST-207 principles that assume every credential can be contested. Security teams should assume the workflow, not the single incident, will recur.

Reconnaissance inside cloud environments is often the precursor to more damaging identity abuse. The most important signal is not only what the attacker does immediately, but what the stolen identity lets them learn about the environment. Once an attacker can query service quotas, list resources, or probe permissions, the compromised account becomes a map of future opportunity. Practitioners should treat internal discovery through cloud APIs as a governance problem, not just a detection problem.

From our research:

• 23.7% of organisations share secrets through insecure methods such as email or messaging applications, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, which shows how weak the governance baseline remains.
• For deeper context, review 52 NHI Breaches Analysis for recurring failure patterns in credential exposure, privilege misuse, and lateral abuse.

What this signals

Credential validation is becoming a detection primitive. When attackers can cheaply test stolen secrets, security teams need to watch for the identity checks that happen before the larger abuse chain. That means tuning telemetry around AWS STS, SES, and unusual API usage, then linking those events to secret exposure workflows and incident response. The governance gap is not just exposure, but the speed at which exposed identity becomes usable.

Teams should expect cloud identity abuse to spread from direct compromise into adjacent business functions. Once a service account or IAM user can be repurposed for messaging, quota discovery, or internal reconnaissance, the incident stops being a simple account problem and becomes a platform problem. The practical response is to map every standing permission to a plausible attacker use case, not only to the intended business workflow.

The best next reference is Ultimate Guide to NHIs , Static vs Dynamic Secrets, because the core issue here is not just theft but the lifetime of the stolen credential.

For practitioners

• Restrict identity-validation permissions Monitor and limit use of GetCallerIdentity and similar low-friction validation calls from unusual sources, especially when they appear in bursts alongside newly observed credentials.
• Separate mail-sending rights from general AWS access Review which roles and users can interact with SES, and ensure mail-sending permissions are isolated from identities that only need application or infrastructure access.
• Remove standing access where identity can be stolen and reused Shift high-risk cloud access toward just-in-time patterns so a compromised identity does not retain durable privileges that can be repurposed for internal recon or fraud.
• Audit service quotas and privilege paths for abuse potential Look for identities that can query quota, send, or discovery APIs without a clear operational need, then map those permissions to the likely abuse chain rather than the intended workflow.

Key takeaways

• Stolen AWS credentials become far more dangerous when they can be validated instantly and reused inside the same cloud environment.
• SES abuse and internal reconnaissance show that identity compromise can support fraud and discovery, not just unauthorized login.
• Reducing standing privilege and separating service permissions are the controls most likely to limit the blast radius of this pattern.

Key terms

• GetCallerIdentity: An AWS STS action that returns the identity associated with the credentials used to call it. Attackers value it because it confirms whether a stolen key or token is live without requiring broad permissions, making it a common validation step in credential-abuse workflows.
• Standing Access: Permissions that remain continuously available rather than being issued only when needed. In cloud identity programmes, standing access increases blast radius because a compromised identity can be reused immediately for abuse, reconnaissance, or service exploitation without waiting for approval.
• Business Email Compromise: A fraud pattern in which an attacker uses legitimate or stolen access to send convincing email for financial or operational gain. When cloud identities can access mail services, BEC can become a downstream abuse case of identity compromise rather than a separate phishing event.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Apono: TruffleNet weaponizes stolen credentials to target AWS. Read the original.