TL;DR: TruffleNet used stolen AWS credentials, valid API calls, and trusted services like SES to run business email compromise at scale, showing how static cloud identities can be abused without malware or a zero-day, according to Defakto Security. The real failure is architectural: long-lived credentials still outlast the runtime context they were meant to represent.
At a glance
What this is: This is Defakto Security’s analysis of the TruffleNet cloud abuse campaign, which shows that stolen static AWS credentials can be validated, reused and abused through legitimate services at industrial scale.
Why it matters: It matters because IAM and PAM teams still treating cloud credentials as durable assets will miss the identity architecture problem behind modern cloud fraud, lateral abuse and audit exposure.
Context
TruffleNet is a cloud identity abuse case, not a malware story. The attack worked because static AWS credentials and reusable service permissions were available to be stolen, validated and used inside normal cloud trust boundaries.
For IAM and NHI programmes, the central governance gap is that long-lived machine credentials still behave like durable access grants rather than runtime-scoped identity. That makes service abuse possible even when perimeter controls and alerting are in place.
This pattern is typical of cloud environments that rely on static keys, broad service entitlements and delayed revocation. The article argues that the operating model, not just the control stack, is what failed.
Key questions
Q: What breaks when workloads still rely on static credentials for service-to-service access?
A: Static credentials break down when workloads are ephemeral, distributed across multiple environments, or expected to authenticate without preconfigured secrets. They are difficult to rotate safely, easy to expose in configuration or environment variables, and poorly matched to dynamic infrastructure. The result is brittle access control, weaker auditability, and a larger attack surface for compromise and lateral movement.
Q: Why does long lived AWS key abuse create such high persistence risk in cloud environments?
A: Long lived access keys give attackers an authenticated foothold that looks legitimate at the API layer. Once they have that access, they can create new identities, assign broad privileges, and remove traces by deleting the original key. The risk is less about one credential and more about how much control a valid key can unlock before defenders notice.
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: Should organisations rely on rotation or move to ephemeral identity for cloud access?
A: Rotation still helps for legacy coverage, but it should not be treated as a fix for static cloud identity. When a key remains usable between rotations, the compromise window is still large enough for abuse. Ephemeral runtime identity removes the durable secret instead of merely shortening its lifespan.
Technical breakdown
How stolen AWS keys were validated at scale
The campaign used large numbers of stolen AWS access keys and checked them with the AWS GetCallerIdentity API. That call is important because it is low-friction, legitimate and usually indistinguishable from ordinary account activity. Once a key returns identity information, attackers can sort working credentials from dead ones without tripping obvious exploit signatures. The technical problem is not just theft. It is that cloud identity exposes a reusable bearer token that can be tested, sorted and operationalised from attacker infrastructure before defenders notice. Practical implication: treat identity validation calls as part of the attack surface, not as harmless housekeeping.
Practical implication: monitor credential validation patterns as a precursor to cloud abuse, not as benign API noise.
Why static credentials enable trusted-service abuse
After validation, the attackers used valid credentials to interact with AWS SES, including checking send quotas, verifying identities and importing DKIM signing keys. That sequence matters because it shows the difference between authentication and trustworthy use. A valid credential is enough to unlock service behaviour that looks legitimate to downstream systems and recipients. In cloud platforms, broad service permissions can turn a stolen key into a fraud delivery mechanism without custom malware. Practical implication: narrow service entitlements so one compromised key cannot become an email-sending or trust-signing pathway.
Practical implication: scope machine identities so a single stolen credential cannot operate trusted delivery services.
Why rotation alone does not remove the runtime exposure window
The article argues that rotation and detection lag behind attacker speed when credentials are long-lived and not bound to workload context. That is the core architectural flaw. Rotation shortens exposure, but the key is still fully usable until it is revoked, and the compromise remains operationally valid during that window. In practice, defenders are reacting after the attacker has already used the identity. Practical implication: move from reusable secrets to short-lived, runtime-issued identity where the access window expires with the workload itself.
Practical implication: replace static credentials with ephemeral runtime identity so compromised access has no durable lifetime.
Threat narrative
Attacker objective: The objective was to turn valid cloud identity into a fraud channel that could send trusted email and drive unauthorized financial transfers.
- Entry occurred through stolen AWS access keys that attackers gathered and tested at scale using legitimate AWS identity checks.
- Credential access was confirmed when the attackers used GetCallerIdentity to identify working credentials and determine the permissions attached to them.
- Escalation happened when those valid identities were used against trusted AWS services such as SES, including verified identities and DKIM signing keys.
- Impact followed when the compromised cloud trust path was used for business email compromise, fraud, and unauthorized email delivery at scale.
Breaches seen in the wild
- Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.
- 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.
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 credentials are a runtime liability, not just a lifecycle problem. TruffleNet shows that a long-lived access key is not merely a secret to be rotated. It is a portable trust grant that can be stolen, validated and reused from attacker infrastructure. The practical conclusion is that cloud identity must be treated as an execution-time control, not a stored asset.
Static credentials carry no workload binding: that assumption was designed for a world where access could be tied to a person, a device or a stable deployment context. It fails when the credential itself is the only proof of legitimacy and can be replayed anywhere. The implication is that identity governance has to distinguish between possession and provenance, because possession alone no longer proves the right workload is acting.
Trusted cloud services become attack amplifiers when entitlement scope is broad. SES is not the problem by itself; the problem is that reusable permissions let a stolen identity operate a service that downstream recipients and controls are inclined to trust. That means blast radius is determined less by the breach entry point than by how much service authority the identity already carries.
Rotation and monitoring are compensating controls, not architectural answers. They can reduce dwell time, but they do not change the fact that a valid static credential remains usable until intervention. In an NHI programme, that means the control objective must shift from protecting secrets after issuance to eliminating the secret model where possible.
Static cloud credentials still fail at scale because the model assumes human-paced response in a machine-paced environment. That is the governance concept TruffleNet makes visible. The practitioner implication is to reframe cloud identity around ephemeral, verifiable access that expires with the task, not around durable keys that survive the task they were issued for.
From our research library:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- Read next: Ultimate Guide to NHIs — Static vs Dynamic Secrets
What this signals
Static cloud credentials remain a structural liability: the TruffleNet case shows why identity programmes that still depend on reusable keys are effectively accepting a replayable trust token into the environment. The programme signal is clear: if the credential survives the task, the attacker may survive the controls.
Cloud teams should treat service entitlements, not just secret storage, as the primary blast-radius driver. A stolen key becomes materially more dangerous when it can operate trusted delivery paths, signing flows or other downstream services that recipients and auditors assume are legitimate.
Identity blast radius: the useful concept here is the amount of trust a single credential can unlock before it is revoked. Once that blast radius is defined, the next governance step is to redesign issuance so runtime context, not possession, determines whether access still exists.
For practitioners
- Eliminate reusable cloud access keys Inventory long-lived AWS access keys, service account secrets and similar static cloud credentials, then define which workloads still depend on bearer-style access and where runtime-issued identity can replace them.
- Constrain trusted service permissions Review permissions on services such as email delivery, signing and notification paths so a single compromised key cannot both authenticate and abuse a trust-bearing service.
- Bind identity to workload context Move toward ephemeral identities that are tied to the specific workload, pipeline or service instance so stolen credentials cannot be replayed independently of the runtime that requested them.
- Rework rotation as a residual control Keep rotation for legacy edge cases, but treat it as containment rather than the primary safeguard because rotation does not remove the value of a live stolen credential.
Key takeaways
- TruffleNet is a reminder that static cloud credentials are not just secrets to protect. They are durable trust objects that can be replayed outside the workload that created them.
- The campaign succeeded by combining stolen keys with ordinary cloud behaviour, which made abuse harder to distinguish from legitimate service activity.
- The control question is no longer how fast keys can be rotated. It is whether the environment still needs keys that remain valid after the workload context is gone.
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 SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | TruffleNet began with stolen static cloud credentials that could be reused from attacker infrastructure. |
| NHI-05 — Overprivileged NHI | The campaign abused broad service permissions on valid cloud identities, especially trusted email delivery paths. | |
| NHI-07 — Long-Lived Secrets | The article’s central failure is the persistence of reusable AWS keys beyond the runtime context they represent. | |
| Recommendation — Scan for exposed cloud secrets and revoke any static credential that could be replayed outside its workload. Reduce service permissions so one compromised cloud identity cannot operate trusted downstream services. Replace long-lived cloud secrets with ephemeral credentials that expire with the workload session. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 directly governs credential lifecycle, including rotation and revocation of machine authenticators. |
| Recommendation — Apply IA-5 to enforce lifecycle controls that shorten the validity of cloud credentials. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack relied on stolen credential use and movement into trusted cloud services to conduct fraud. |
| Recommendation — Map the campaign to credential access and lateral movement to hunt for similar service abuse patterns. | ||
Key terms
- Temporary Cloud Credentials: Temporary cloud credentials are short lived access tokens issued for a limited purpose instead of storing long term keys in files or code. They reduce blast radius because they expire automatically and are better suited to applications that need to access cloud services without keeping reusable secrets on disk.
- 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.
- Dynamic Ephemeral Identity: Dynamic Ephemeral Identity is a model in which credentials or authority exist only for a short operational window and are generated at runtime. It reduces the value of exposed secrets, but only if the environment can also limit what the identity is allowed to do while active.
- Trusted Service Abuse: Trusted service abuse is the use of a legitimate cloud or communications platform to deliver malicious content while appearing authentic. The abuse works because recipients and filters may trust the sender, even though the message, link, or attachment is weaponised for phishing, malware delivery, or credential theft.
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.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org