Notifications
Clear all
Topic starter
24/06/2026 6:51 pm
TL;DR: TruffleNet used stolen AWS credentials, automated validation, and Amazon SES abuse to run large-scale BEC phishing across more than 800 hosts in 57 networks, according to Unosecur. The campaign shows that cloud identity compromise can bypass perimeter controls and turn trusted infrastructure into a fraud delivery system.
NHIMG editorial — based on content published by Unosecur: New TruffleNet BEC Campaign Leverages AWS SES Using Stolen Credentials to Compromise 800+ Hosts
By the numbers:
- 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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Unosecur's analysis of the TruffleNet AWS credential abuse campaign →
Stolen AWS credentials and SES abuse: what IAM teams missed?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 3:50 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: TruffleNet BEC shows how stolen AWS credentials fuel cloud fraud
