TruffleNet BEC shows how stolen AWS credentials fuel cloud fraud

At a glance

What this is: This is a cloud identity abuse analysis showing how stolen AWS credentials were validated and then used to send BEC phishing through Amazon SES at scale.

Why it matters: It matters because IAM, PAM, and NHI teams must treat cloud credentials and trusted service abuse as a direct fraud path, not just an access problem.

By the numbers:

• 800 unique hosts across 57 networks were used, used in the TruffleNet campaign.
• Organizations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious.

👉 Read Unosecur's analysis of the TruffleNet AWS credential abuse campaign

Context

Cloud identity compromise becomes dangerous when stolen credentials can be validated and then used against trusted services without triggering a clear anomaly. In this case, the primary issue is not a software exploit but the misuse of valid AWS access to drive Business Email Compromise through Amazon SES.

For IAM and NHI programmes, that means the control problem sits in credential exposure, privilege scope, and service-level monitoring. Once attackers can prove the keys work, they can move from reconnaissance to message delivery inside infrastructure that defenders often trust by default.

Key questions

Q: What breaks when stolen AWS credentials can send mail through SES?

A: Traditional perimeter and spam controls break down because the messages originate from a trusted cloud provider and a valid identity. Once the credential is accepted, the attacker can send convincing business email compromise traffic that looks operationally legitimate. The real failure is not just access theft, but the ability to convert identity into deliverability.

Q: Why do stolen cloud credentials increase BEC risk so quickly?

A: They let attackers move directly from initial validation to service abuse without exploiting software vulnerabilities. In cloud environments, a valid identity often has enough trust to enumerate quotas, create mail identities, and send messages before defenders detect the anomaly. That shortens the response window and increases the chance of payment fraud.

Q: What do security teams get wrong about AWS access-key exposure?

A: They often treat exposed keys as a single account problem instead of a broader trust problem. A valid key can unlock email, storage, and orchestration services, so the blast radius depends on attached permissions and downstream reputation. Monitoring must cover the services the key can legitimately use, not only the login event.

Q: Who is accountable when compromised cloud identities are used for fraud?

A: Accountability usually spans IAM, cloud operations, and security monitoring because the weakness sits in credential lifecycle, permission scope, and detection coverage. Frameworks such as NIST SP 800-207 support the case for continuous verification, while NHI governance defines who owns the secret, who can use it, and who must revoke it.

Technical breakdown

Valid AWS credentials turn reconnaissance into service abuse

The first technical step in the campaign was credential validation. Attackers used a tool such as TruffleHog to test stolen AWS access keys and confirm them with GetCallerIdentity, which is a legitimate API call that returns the identity behind the credentials. That matters because the access now looks real to the cloud control plane. At that point, the attacker no longer needs to break in again. They can enumerate what the account can do, then pivot into abuse of whatever trusted services are enabled.

Practical implication: alert on identity-verification calls from unexpected sources and tie them to credential exposure events.

Amazon SES abuse creates a trusted fraud channel

Once access was confirmed, the attackers queried GetSendQuota to understand Amazon SES limits and then used the service to send phishing and BEC mail. SES is operationally attractive because mail originates from Amazon-owned infrastructure, which improves deliverability and reduces the chance of simple blacklist detection. The abuse pattern is therefore not just email fraud but identity-backed service misuse. In cloud terms, the attacker is borrowing the provider’s reputation to move malicious traffic through a trusted channel.

Practical implication: monitor SES identity creation, quota checks, and unusual sending from accounts with no established mail history.

Orchestration at scale is a sign of industrialised identity abuse

The infrastructure behind the campaign included more than 800 hosts across 57 Class C networks, with Portainer exposed across systems and used as an orchestration layer. That suggests organised operations rather than opportunistic credential misuse. The important lesson is that cloud fraud campaigns now combine identity theft with repeatable infrastructure management, so defenders need to correlate credential events, email activity, and orchestration footprints together instead of treating them as separate alerts.

Practical implication: correlate AWS identity logs with infrastructure orchestration indicators and outbound email spikes to identify coordinated abuse.

Threat narrative

Attacker objective: The objective was to turn stolen cloud identity into a trusted fraud delivery mechanism for business email compromise and payment theft.

1. Entry occurred when attackers obtained stolen AWS access keys and validated them with GetCallerIdentity to confirm the credentials were usable.
2. Escalation followed when they queried GetSendQuota and used Amazon SES identities to prepare large-scale phishing and BEC delivery from trusted cloud infrastructure.
3. Impact came from fraudulent email campaigns impersonating vendors and requesting payment through typosquatted domains, while the Amazon-backed sender reputation helped the messages reach targets.

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 compromise is now a fraud platform, not just an access event. When attackers can authenticate with real AWS credentials, they inherit the trust boundary of the environment and can use it to deliver phishing at scale. That shifts the security question from whether access exists to whether the account can be abused without immediate behavioural detection. For IAM and NHI teams, the implication is that identity exposure is now a direct revenue-loss and fraud-loss issue, not a narrow admin problem.

Trusted service abuse exposes a standing-privilege assumption that no longer holds. SES, like other cloud-native send services, assumes the caller is authorised and that message reputation follows legitimate business use. TruffleNet shows that this assumption fails when stolen credentials can switch from reconnaissance to sending within the same session. The implication is that reputation-based controls cannot be the only line of defence for cloud mail channels.

Credential validation APIs have become a high-value early warning signal. The use of GetCallerIdentity and GetSendQuota is operationally meaningful because it reveals an attacker moving from possession to exploitation. That makes API telemetry part of identity governance, not just cloud monitoring. Teams that do not monitor these calls lose the chance to distinguish a stolen key from a living, abused identity before abuse scales.

Identity blast radius now depends on where the credential can borrow trust. Identity blast radius: the maximum fraud, delivery, or access impact a single compromised credential can create when it reaches trusted services, lateral cloud permissions, and external reputation systems. In this campaign, the blast radius was amplified by SES deliverability and distributed orchestration, so the practitioner conclusion is that access scope must be measured by downstream trust effects, not only by IAM policy size.

Standing credential exposure window: this breach worked because AWS access keys remained usable long enough for attackers to validate, enumerate, and weaponise them before any defensive intervention. That is a lifecycle failure mode, not merely a bad secret hygiene issue. The practitioner conclusion is that long-lived keys create a window in which legitimate identity becomes attacker infrastructure.

From our research:

• Organizations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to The 2026 Infrastructure Identity Survey.
• Another finding from the 2026 Infrastructure Identity Survey shows that only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For the broader credential-lifecycle angle, read The 52 NHI Breaches Analysis for recurring patterns in secret exposure, overprivilege, and delayed revocation.

What this signals

Identity-first fraud detection will become a core cloud control. As more attackers exploit trusted services rather than malware, teams need to watch for credential verification, quota discovery, and service-specific abuse patterns as early indicators of compromise. The practical shift is from chasing payloads to tracking when an identity begins behaving like infrastructure.

The article also reinforces a broader NHI lesson: long-lived credentials are not just difficult to manage, they are easy to weaponise once exposed. That makes lifecycle discipline, permission scoping, and anomaly detection inseparable parts of the same programme, especially when cloud services can be turned into mail-sending intermediaries.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey, the same weakness that fuels cloud fraud also undercuts future AI and workload governance. Teams should treat credential modernisation as a shared foundation across machine identity, human IAM, and autonomous systems.

For practitioners

• Instrument credential-verification API calls Alert on GetCallerIdentity, GetSendQuota, and similar identity-check events when they originate from unfamiliar hosts, new geographies, or newly activated accounts. Treat those calls as early compromise indicators, not harmless diagnostics.
• Restrict SES permissions by role purpose Separate email-sending entitlements from general AWS access and remove SES permissions from roles that do not explicitly need them. Enforce scoped identities so a stolen key cannot become a mail relay.
• Rotate and retire long-lived access keys Inventory all AWS keys, identify dormant and shared credentials, and move high-risk workloads to short-lived identity patterns where possible. The goal is to reduce the window in which a stolen key remains operational.
• Correlate cloud identity with outbound mail behaviour Join AWS API telemetry, SES sending logs, and email-security alerts so that a new identity or quota check is evaluated alongside message volume and domain-creation patterns. This is where abuse becomes visible.

Key takeaways

• Stolen AWS credentials turned legitimate cloud access into a BEC delivery mechanism, showing that identity compromise can be the attack path rather than the aftermath.
• The campaign used over 800 hosts across 57 networks, which indicates a coordinated abuse operation rather than isolated misuse of a single account.
• The most effective limit on this pattern is tighter credential lifecycle control, narrower SES entitlements, and API telemetry that spots identity validation before fraud scales.

Key terms

• Cloud identity abuse: The misuse of a valid cloud account, access key, token, or role to perform actions that appear legitimate to the provider. In practice, the attacker does not need to break authentication again once the credential is stolen, so the environment’s own trust model becomes the attack surface.
• Service abuse: Using an otherwise legitimate cloud service for an unauthorised purpose, such as sending phishing, relaying messages, or moving data. The service itself may be functioning normally, but the identity behind it is compromised or misused, which makes detection harder than with obvious malware.
• Standing credential: A long-lived secret or access path that remains usable until someone explicitly rotates or revokes it. Standing credentials are especially risky in cloud environments because theft creates a broad and immediate window for abuse, often before the organisation notices the exposure.
• Identity blast radius: The total downstream impact a compromised identity can create across services, reputation systems, and business processes. It is larger than the permission set alone because a valid identity can borrow trust from infrastructure, making fraud or lateral abuse easier to execute and harder to block.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The exact AWS API sequence used to validate and stage abused credentials, including the reconnaissance pattern around GetCallerIdentity and GetSendQuota.
• The infrastructure indicators tied to the campaign, including the role of Portainer and exposed services across the 800-plus host footprint.
• The email abuse characteristics, such as SES identity creation patterns, typosquatted payment domains, and vendor impersonation examples.
• The immediate remediation checklist and short-term control changes that map the attack chain to specific AWS actions.

👉 The full Unosecur blog covers the attack chain, SES abuse details, and remediation steps

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.