TruffleNet BEC shows how stolen AWS credentials fuel cloud fraud

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unosecur's blog post: Stolen AWS credentials were validated and then used to abuse Amazon SES for large-scale BEC phishing in the TruffleNet campaign.

Why it matters: It matters because IAM and NHI teams have to treat cloud credentials as fraud-enabling access, not just infrastructure access, when trusted services can be weaponised from inside the tenant.

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

Context

Stolen cloud credentials can turn an ordinary AWS account into a fraud platform when the attacker is able to validate access, discover service limits, and then abuse trusted delivery channels. In this case, the governance gap is not only credential theft but the assumption that cloud-native email use remains benign once authenticated.

TruffleNet is a useful example of how identity compromise changes the threat model for AWS environments. Once access keys were confirmed as valid, the attackers moved from access validation to service abuse, using Amazon SES to send BEC email at scale from accounts that still looked legitimate to downstream controls.

The article also shows that the problem is operational, not just technical. Dedicated orchestration, credential scanning, and trusted email infrastructure combined to make the campaign persistent enough to matter to both IAM owners and fraud defenders.

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 trusted cloud email services increase BEC risk?

A: Trusted cloud email services can inherit provider reputation, which makes malicious messages harder to distinguish from legitimate traffic. When attackers send BEC mail through a service like SES, filters that lean heavily on sender reputation, IP blacklists, or domain novelty can miss the abuse. Identity-based monitoring becomes the decisive control layer.

Q: How do security teams detect cloud credential abuse before fraud starts?

A: Look for validation and discovery behaviour, not only successful compromise. Unusual identity-check API calls, quota discovery, new email identity creation, and sudden sending patterns are early signals that stolen credentials are being turned into abuse capacity. Correlating those signals across cloud logs and email telemetry gives defenders earlier containment opportunities.

Q: How should IAM teams limit the impact of a stolen AWS key?

A: Constrain the key so it cannot both discover service capacity and send mail at scale. Separate administrative functions from email-sending permissions, remove dormant credentials, and ensure that any high-risk key has a short operational lifetime. The goal is to shrink the amount of fraud a single credential can support.

Technical breakdown

How stolen AWS credentials are validated before abuse

The first technical step is proving that the stolen keys still work. In this campaign, attackers used GetCallerIdentity, an AWS API call that returns the caller's identity without requiring additional business context, to confirm that the credentials were live. That matters because valid cloud access often blends into normal authentication telemetry, especially when the account already has legitimate patterns. Once validation succeeds, the attacker has a reliable foothold for service discovery, quota checks, and abuse planning. Practical implication: monitor identity-verification API calls as an early sign of credential testing, not just as routine noise.

Practical implication: alert on identity-verification calls from unusual sources so validated stolen credentials are caught before service abuse begins.

Why Amazon SES is attractive for BEC operators

Amazon SES is not the vulnerability here. The issue is that a trusted bulk-email service gives attacker-generated mail better deliverability than traffic from throwaway infrastructure. After credential validation, TruffleNet queried GetSendQuota to understand how much email the compromised account could send, then used SES identities to launch phishing and BEC messages. Because the mail originates from a reputable cloud service, perimeter spam controls and blacklist-based filtering are less reliable. Practical implication: cloud email services need identity-aware monitoring for quota discovery, identity creation, and unusual sending patterns.

Practical implication: treat SES quota checks and identity creation as abuse signals, not routine administrative activity.

What orchestration tells us about industrialised credential abuse

The campaign used more than 800 hosts across 57 networks, with Portainer exposed across systems, which points to organised infrastructure rather than opportunistic misuse. That scale matters because credential abuse is no longer a single-account event; it is an operational process that can validate access, stage infrastructure, and coordinate send capacity across many nodes. In identity terms, the attacker is turning one stolen credential set into a repeatable service-abuse pipeline. Practical implication: defenders need telemetry that correlates credential testing, orchestration tooling, and outbound email patterns across accounts and networks.

Practical implication: correlate cloud API activity with infrastructure management tools to spot organised abuse patterns.

Threat narrative

Attacker objective: The objective was to use trusted AWS infrastructure to deliver believable BEC email and extract fraudulent payments.

1. Entry began with stolen AWS access keys that gave the attacker authenticated access to victim cloud accounts.
2. Credential access was confirmed by calling GetCallerIdentity, which let the attacker test which keys were still valid.
3. Escalation into service abuse followed when the attacker queried GetSendQuota and used SES identities to send phishing and BEC mail.
4. Impact was achieved when trusted cloud infrastructure was used to impersonate vendors and request fraudulent payments at scale.

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.
• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud credential compromise is now a fraud-enablement problem, not just an access problem. TruffleNet shows that once AWS keys are stolen, the attacker can move from authentication to service abuse without ever needing to break the cloud platform itself. The security failure is the assumption that valid cloud access is inherently low-risk if it comes from a trusted provider. Practitioners need to treat identity theft in cloud accounts as a direct fraud control issue.

Trusted delivery infrastructure changes the detection problem. BEC sent through Amazon SES can inherit the reputation of the underlying cloud provider, which weakens controls that depend on bad-IP lists or obvious infrastructure markers. That means fraud defenders and IAM teams have to watch identity creation, send quotas, and anomalous API usage instead of relying on message origin alone. The practical conclusion is that trust in the transport layer is not trust in the sender.

Standing access assumptions fail when the attacker is operating inside the tenant. Least privilege and MFA matter, but this campaign shows that stolen access keys can still provide enough room to discover email capacity and launch abuse if entitlement scope is too broad. The named concept here is identity-to-fraud blast radius: the amount of fraudulent output a single compromised credential can generate before detection. Practitioners should measure cloud accounts by abuse potential, not only by admin status.

Industrialised credential abuse requires governance across cloud identity, email, and operations tooling. The use of more than 800 hosts and exposed Portainer instances suggests that the attacker was coordinating cloud abuse as an operation, not improvising it. That means identity governance has to look at how credentials, orchestration, and service limits interact over time. The field should stop treating NHI compromise as a siloed cloud issue and start treating it as part of fraud infrastructure governance.

What this signals

The practical lesson for IAM and NHI programmes is that fraud controls now start at credential governance. When a single AWS key can validate access and unlock trusted email infrastructure, the meaningful question is no longer whether the key works, but how much abuse it can support before containment.

A useful programme concept here is identity-to-fraud blast radius: the amount of malicious output one compromised credential can generate across cloud services before detection. That should influence rotation priority, permission design, and the way cloud teams decide which accounts deserve the tightest monitoring.

Teams should also treat email-sending services as identity surfaces, not just application services. SES quota checks, identity creation, and external-domain abuse all belong in the same governance conversation as IAM permissions and key hygiene.

For practitioners

• Harden AWS access key lifecycle Inventory every access key, remove unused keys, and rotate high-risk credentials tied to email or administrative permissions on a fixed schedule.
• Alert on identity-verification API calls Create detections for unusual GetCallerIdentity activity, especially from new geographies, new roles, or accounts that rarely use that API.
• Monitor SES abuse signals Track new email identities, unexpected GetSendQuota checks, sudden send-volume spikes, and use of external domains as sending identities.
• Reduce the blast radius of cloud credentials Restrict SES and IAM permissions to the narrowest practical scope so one stolen key cannot both confirm access and initiate fraud campaigns.

Key takeaways

• TruffleNet shows that stolen cloud credentials can be used to turn legitimate AWS services into fraud infrastructure without any platform exploit.
• The campaign used validated credentials, SES quota checks, and large-scale orchestration across more than 800 hosts to make BEC delivery harder to stop.
• Limiting key scope, tightening rotation, and monitoring identity-verification and email-service signals are the controls most likely to reduce blast radius.

Key terms

• Business email compromise: A form of social engineering where an attacker impersonates a trusted person or domain to manipulate payment, change banking details, or extract sensitive information. It often succeeds without malware because the attacker targets process trust and human judgement instead of technical controls.
• Identity Verification API Call: A cloud API request used to confirm which identity is currently authenticated. In AWS, this kind of call can help both defenders and attackers validate whether a key is live, so unusual use can indicate credential testing, automation, or abuse preparation.
• Email Sending Quota: The permitted volume or rate at which an account can send email through a cloud messaging service. Attackers probe quotas to understand how much abuse the account can sustain, while defenders use quota activity as a signal that legitimate service use may have shifted into fraud enablement.
• Fraud Blast Radius: Fraud blast radius is the amount of damage an attacker can cause after gaining access to identity data or a trusted workflow. It includes the number of accounts, transactions, or records that can be abused before the organisation detects and contains the misuse.

What's in the full article

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

• API-call indicators such as GetCallerIdentity and GetSendQuota that defenders can turn into detections
• The attacker infrastructure pattern, including Portainer exposure and the 800-plus host footprint
• Examples of phishing content and typosquatted domains used to impersonate trusted vendors
• The immediate remediation checklist for AWS credentials, SES monitoring, and least-privilege tightening

👉 Unosecur's full post covers the attack chain, SES abuse patterns, and the recommended AWS controls.

Deepen your knowledge

NHI governance, secrets management, and workload identity security 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.