TruffleNet shows how stolen AWS credentials turn IAM into abuse

At a glance

What this is: Apono’s analysis of TruffleNet shows attackers validating stolen AWS credentials, then using AWS IAM and SES for business email compromise and internal reconnaissance.

Why it matters: IAM teams need to treat cloud identity as an active abuse surface, because standing privileges can turn a compromised account into a launch point for email fraud and follow-on access.

Context

AWS credential abuse is not just about login success. In cloud environments, identity checks, access tokens, and service permissions can be used by attackers to confirm what works, then immediately convert that access into operational abuse.

This article focuses on a non-human identity problem: compromised AWS identities with standing privilege. The control gap is not authentication alone, but whether the identity can keep doing useful work after validation has already happened.

Key questions

Q: What breaks when stolen AWS credentials can validate themselves before abuse?

A: Security teams lose the early warning window because the attacker can confirm which credentials are live before any obvious malicious action occurs. That makes simple credential theft far more operationally valuable and turns authentication telemetry into a potential abuse signal. Defenders need to watch for validation calls that are followed quickly by service-use behavior.

Q: Why do standing AWS permissions increase the risk of business email compromise?

A: Standing permissions let a compromised identity move directly from access validation into service abuse without waiting for another approval or provisioning step. If the account can send mail through SES, the attacker can use trusted cloud infrastructure to support fraud and reconnaissance. The risk is the permission set, not just the stolen secret.

Q: What are the signs that AWS access key abuse is underway?

A: 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.

Q: How should security teams reduce blast radius for workload credentials?

A: Start by removing shared, long-lived secrets from the highest-risk workflows, especially API integrations, CI/CD jobs, and autonomous services. Prefer short-lived tokens, signed assertions, or runtime-attested identities so a stolen credential has limited replay value. Then align rotation, revocation, and authorisation policies so the control remains effective after deployment.

Technical breakdown

How stolen AWS credentials are validated in-cloud

The reported TruffleNet activity uses AWS IAM itself as a validation oracle. A GetCallerIdentity call confirms whether a stolen credential is live without needing any privileged action, which lets attackers sort usable credentials from dead ones at scale. That pattern reduces attacker effort and makes credential testing look like ordinary API traffic. Once the identity is confirmed, the same access path can be reused for deeper abuse if the account still carries useful permissions. In cloud terms, authentication is no longer the end of the event chain; it is the first checkpoint in an abuse workflow.

Practical implication: treat authentication-success checks as a threat signal when they come from unfamiliar sources, geographies, or automation patterns.

Why SES abuse turns identity into an email fraud platform

Amazon SES is a legitimate cloud messaging service, but in attacker hands it becomes an abuse channel for business email compromise. If a compromised identity can query send quotas or trigger mail from a trusted cloud account, the attacker gains infrastructure-backed legitimacy that makes fraud messages harder to block and easier to trust. The problem is not SES as a product. The problem is that the stolen AWS identity inherited enough permission to convert cloud access into outward-facing abuse with business impact.

Practical implication: separate mail-sending permissions from general cloud access and monitor SES usage as a fraud control, not only as an engineering function.

Standing access is what makes compromise reusable

The article’s core governance issue is standing privilege. If an AWS identity remains broadly usable after compromise, the attacker can move from validation to reconnaissance and then to service abuse without waiting for another control boundary. That creates an identity blast radius problem, where the scope of impact is defined by the permissions already attached to the account. In NHI terms, long-lived access and overprivilege are what make a stolen credential economically valuable to the attacker.

Practical implication: classify AWS identities by blast radius and remove persistent permissions that are not needed for continuous operation.

Threat narrative

Attacker objective: The attacker wants to turn a valid AWS identity into a reusable foothold for business email compromise, reconnaissance, and broader in-cloud abuse.

1. Entry occurs through stolen AWS credentials that attackers test with GetCallerIdentity to confirm which identities are live and usable.
2. Credential access is followed by privilege abuse, as the same authenticated identity is used inside AWS to query SES capacity and support email-based abuse.
3. Escalation comes through operational reuse of the compromised cloud account for business email compromise and internal reconnaissance.
4. Impact is achieved when trusted cloud infrastructure is repurposed for fraud and foothold expansion inside the victim environment.

Breaches seen in the wild

• TruffleNet stolen AWS keys campaign 2025: TruffleNet used 800+ attacker hosts to test stolen AWS keys and check SES capacity; one compromised account sent a fake $50,000 invoice.
• Sumo Logic breach 2023: A compromised credential opened a Sumo Logic AWS account; customers were told to rotate API keys and stored credentials. No data impact was found.

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

NHI Mgmt Group analysis

Stolen cloud credentials become more dangerous when IAM itself confirms they work. GetCallerIdentity is not a compromise by itself, but in attacker hands it becomes a low-friction validation step that separates live credentials from noise. That shifts the defender’s problem from simple theft to credential usability, which is where the operational damage starts. The practitioner conclusion is that validation behavior around cloud identities should be treated as part of the threat model, not just authentication telemetry.

Standing AWS access creates an identity blast radius that attackers can monetise immediately. The article shows how a compromised identity with sufficient privileges can be converted into SES abuse and internal recon. That is a governance failure in the lifecycle of NHI permissions, because the account remains operationally useful after compromise. The implication is that blast-radius reduction has to be built into the identity model, not left to post-breach containment.

Ephemeral trust assumptions fail when the credential can be reused across multiple cloud actions. This attack sequence depends on the idea that a credential, once validated, should still be trusted to perform follow-on work. That assumption breaks when the same identity can test itself, query service quotas, and send mail from a trusted cloud tenant. The practitioner conclusion is that access scope must be narrowed to the smallest possible operational window.

TruffleNet shows a named concept: credential validation abuse. The security issue is not only stolen credentials, but the use of cloud control-plane calls to confirm legitimacy before abuse begins. That pattern compresses detection time and increases the chance that the first observed action already reflects post-compromise utility. The practitioner conclusion is to look for validation plus service-use sequences as one abuse pattern, not two separate events.

From our research library:

• Stolen credentials were involved in 22% of breaches overall and in 88% of basic web application attacks, according to Verizon's 2025 Data Breach Investigations Report.

What this signals

Credential validation abuse: cloud attackers increasingly use identity checks as a reconnaissance step, which means defenders should correlate authentication success with subsequent service activity instead of treating them as separate events.

Standing cloud access is the real amplifier here. Once a compromised identity can still send mail or query service quotas, the attacker inherits legitimate infrastructure that can be repurposed for fraud, recon, and follow-on access.

For IAM and NHI programmes, the practical shift is from proving that a credential works to proving that it cannot do anything valuable after it works.

For practitioners

• Audit live AWS identities for validation-oracle abuse Look for repeated GetCallerIdentity calls, unusual CLI activity, and automation patterns that suggest stolen credentials are being tested before abuse begins.
• Remove standing permissions from mail-sending identities Separate SES permissions from broad cloud administration and restrict which identities can query send quotas or send mail at all.
• Classify AWS accounts by blast radius Map each identity to the services it can reach, then remove permissions that are not required for continuous operation or support workflows.
• Harden detection around SES abuse paths Alert on quota checks, unexpected SES usage, and mail activity from identities that do not normally interact with messaging services.

Key takeaways

• Stolen AWS credentials are dangerous because they can be validated and then reused inside the same cloud environment for abuse.
• The reported campaign connects identity validation, SES use, and business email compromise, showing how quickly cloud access becomes operational impact.
• Reducing standing privilege is the control that most directly limits the blast radius of a stolen AWS identity.

Key terms

• Credential Validation Abuse: Credential validation abuse is the practice of testing stolen or suspected credentials against identity or control-plane endpoints to confirm whether they are live. In cloud environments, the validation step itself can become a reconnaissance signal that precedes service abuse, fraud, or lateral movement.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.