TruffleNet shows static cloud credentials still fail at scale

At a glance

What this is: This analysis shows how the TruffleNet campaign abused stolen AWS credentials and trusted cloud services to conduct fraud at scale.

Why it matters: It matters because IAM and NHI teams still face cloud identities that can be reused, over-scoped, and trusted after compromise across machine, agentic, and human control planes.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Defakto Security's analysis of TruffleNet and cloud identity abuse at scale

Context

TruffleNet is a cloud identity abuse case, not a malware story. The attackers worked with stolen AWS access keys, validated them through standard identity calls, and then used trusted services to send authenticated fraud at scale. That pattern matters because cloud identity was treated as a fixed credential problem when it had already become a runtime trust problem.

For IAM and NHI programmes, the lesson is that long-lived credentials, broad service permissions, and weak workload binding create a reusable attack surface. The attack also shows why static secrets age badly in automated environments: once they can be validated from anywhere, the control model stops protecting the workload and starts protecting the attacker's timing.

Key questions

Q: What breaks when cloud credentials are valid outside their original workload?

A: When a cloud credential can be reused outside the workload that issued it, the identity layer stops distinguishing legitimate execution from attacker replay. That makes standard API calls, service trust, and outbound actions available to anyone holding the secret. The practical result is that detection and rotation arrive after the credential has already been monetised.

Q: Why do long-lived cloud secrets increase fraud risk in trusted services?

A: Long-lived secrets increase fraud risk because they let attackers operate inside the trust boundary of services like mail delivery, storage, and automation platforms. Once a credential is accepted, the service often treats the action as legitimate. That is why broad permissions plus reusable secrets can turn infrastructure into a fraud channel.

Q: How do security teams know if cloud identity controls are failing?

A: The clearest sign is when a stolen credential can be validated, reused, and operationalised from infrastructure that has no relationship to the original workload. If the control model depends on later alerting or manual rotation, it is measuring aftermath rather than preventing misuse. Teams should look for workload binding, not just secret age.

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

A: Accountability sits with the teams that own the workload identity, the cloud service permissions, and the governance model that allowed reusable credentials to persist. Frameworks such as the OWASP Non-Human Identity Top 10 and NIST CSF both point to access control, least privilege, and identity lifecycle ownership as core responsibilities.

Technical breakdown

How stolen AWS access keys become valid cloud identities

Cloud identity abuse often starts with credential discovery, then moves to validation. In this case, attackers used AWS access keys and the GetCallerIdentity API to confirm whether keys were live and to infer permissions without touching the workload that originally owned them. That is a critical distinction: the compromise is not about breaking a service, but about proving the credential still works inside the cloud control plane. Because the API response is routine and legitimate, defenders see normal identity traffic while the attacker is simply enumerating what the stolen key can do.

Practical implication: replace broad, reusable keys with workload-bound identities that cannot be validated or replayed from arbitrary infrastructure.

Why trusted cloud services make fraud harder to detect

Once the attackers had valid identity, they used AWS SES and related trust features to send authenticated email from cloud infrastructure. That works because many cloud services inherit the trust of the parent account and project legitimacy outward through DKIM, verified identities, and quota checks. The result is a fraud chain that looks internally consistent to mail systems and externally believable to victims. Monitoring still helps, but it is looking at a fully authorised action path after the identity layer has already failed to distinguish the legitimate workload from the attacker.

Practical implication: scope service permissions tightly and separate fraud-sensitive outbound channels from general-purpose cloud identities.

Why static credentials fail at automation scale

Static credentials break down because they are durable outside their original execution context. A long-lived AWS key can be copied, replayed, and used at machine speed from anywhere, while rotation and detection operate on human time. That creates a structural mismatch between attacker velocity and defender response. Ephemeral identity changes the model by tying access to a specific workload or execution window, which reduces the value of stolen secrets and makes reuse far harder. The issue is not that rotation is useless, but that rotation cannot compensate for credentials that remain valid independently of runtime context.

Practical implication: move high-risk workloads to ephemeral identity issuance and retire long-lived secrets wherever runtime binding is possible.

Threat narrative

Attacker objective: The attackers sought to turn trusted cloud identity into a fraud platform for convincing business email compromise and financial theft.

1. Entry occurred through stolen AWS access keys that were validated with routine identity calls rather than exploit code.
2. Escalation came from the abuse of trusted cloud services, especially SES, where the compromised identity could check quotas, verify senders, and import signing material.
3. Impact followed as authenticated fraud emails passed trust checks and enabled business email compromise and payment diversion at scale.

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

Static cloud identity is the failure mode TruffleNet exposes. The campaign worked because a long-lived credential could exist independently of the workload that issued it, then be replayed from attacker infrastructure without losing legitimacy. That assumption was designed for stable, human-paced access, not for cloud automation that validates identity at machine speed. The implication is that identity programmes must stop treating reusable credentials as a tolerable baseline.

Trusted cloud services become fraud amplifiers when identity is not workload-bound. SES, send quotas, verified identities, and DKIM all make legitimate operations easier, but they also make stolen access more valuable once the attacker is inside the trust boundary. This is not a visibility gap alone. It is a governance gap where the control plane still trusts the credential more than the runtime context. Practitioners need to recognise that trust propagation is itself part of the attack surface.

Identity blast radius is the more useful concept here than credential rotation speed. The attack shows that a valid key can still be operationally catastrophic even if it is eventually rotated, because the harmful action path is already available once the credential is accepted. The named concept is identity blast radius: how far a single valid credential can move before controls interrupt it. The practitioner conclusion is to measure how much damage one identity can do, not just how often secrets are changed.

Access review processes are still too slow for machine-speed misuse. Audit and recertification assume that entitlements persist long enough to be reviewed, challenged, and revoked. TruffleNet demonstrates the opposite: if a secret can be stolen, validated, and used across distributed infrastructure before the next review cycle, the governance model is reacting after the breach has already monetised the identity. Practitioners should re-evaluate whether current review cadences are measuring residual risk or merely documenting it.

Cloud identity security now depends on removing the conditions that make stolen credentials reusable. The article's core lesson is that static secrets, broad permissions, and weak workload binding are not separate problems. They are a single design choice that turns cloud trust into a liability. For the field, that means machine identity governance has to be built around runtime verifiability, not just post-incident investigation.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, 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 helps explain why static cloud secrets still persist in production.
• That maturity gap is why readers should also review the Ultimate Guide to NHIs , Static vs Dynamic Secrets for the control model shift this article points toward.

What this signals

Static credential debt: the real issue is not just that secrets exist, but that they outlive the workload and remain valid from places they were never meant to operate. Once that happens, cloud identity becomes replayable infrastructure rather than context-bound access, and traditional monitoring only sees the misuse after the trust decision has already been made.

With 88.5% of organisations acknowledging that their non-human IAM practices lag behind or are merely on par with human IAM, the field is still compensating for machine-scale identity with human-era assumptions. That gap will widen as automation and AI increase the number of identities that must be bound, reviewed, and retired without manual intervention.

Teams should prepare for identity programmes to be judged less on secret rotation frequency and more on whether a credential can be replayed outside its workload. For practical next steps, the NHI Lifecycle Management Guide and the OWASP Non-Human Identity Top 10 are the most relevant reference points for rebuilding that control layer.

For practitioners

• Eliminate long-lived cloud secrets from high-risk workflows Prioritise AWS access keys and service credentials that can be reused outside their original workload or pipeline. Replace them with runtime-issued identities where the credential has a short lifetime and is bound to the specific execution context.
• Tighten SES and other trusted outbound permissions Review which machine identities can send mail, verify identities, or import signing material. Remove broad service permissions from workloads that do not explicitly need outbound trust capabilities, and separate fraud-sensitive actions from general cloud access.
• Measure identity blast radius before the next audit cycle Map the downstream actions available to each privileged cloud identity, including validation, email sending, and identity configuration. Use that map to identify where one stolen key can still trigger authenticated abuse before detection or rotation can intervene.
• Rework review cadence around runtime binding, not key age Assess whether the identity is still valid outside the workload that owns it, then shorten or remove any secret that can be copied and replayed from another environment. If the entitlement outlives the workload, the governance model has already lost the context it needs to protect the account.

Key takeaways

• TruffleNet shows that cloud fraud can succeed without malware when stolen credentials remain valid inside trusted services.
• The scale problem is structural: 88.5% of organisations say non-human IAM still lags human IAM, which leaves reusable secrets in place.
• The control that matters most is runtime binding, because credentials that cannot be replayed outside their workload sharply reduce blast radius.

Key terms

• Static Credential: A static credential is a long-lived secret such as an API key, token, or password that remains valid until someone changes or revokes it. In cloud environments, static credentials are risky because they can be copied, replayed, and used independently of the workload that originally received them.
• Workload Binding: Workload binding means an identity is tied to a specific service, pipeline, or runtime context rather than being usable anywhere a secret is copied. This reduces replay value because the credential is only meaningful when presented by the expected workload under the expected conditions.
• Identity Blast Radius: Identity blast radius is the amount of damage a single valid identity can cause before controls detect or stop misuse. It is a practical measure of privilege scope, service trust, and runtime reach, and it is often more useful than focusing only on credential age or rotation cadence.
• Ephemeral Identity: Ephemeral identity is a short-lived credential or assertion issued at runtime for a specific task or session. It expires quickly and is usually bound to context, which makes it harder to steal, reuse, or replay across environments compared with static secrets.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 Defakto Security: TruffleNet and cloud abuse at scale, an identity architecture failure. Read the original.