Topic starter
24/06/2026 6:51 pm
TL;DR: Unosecur reports that TruffleNet abused stolen AWS credentials to validate access with GetCallerIdentity, probe Amazon SES capacity, and send large-scale BEC phishing from compromised cloud accounts. The case shows that trusted cloud services can become fraud infrastructure when credential governance and detection lag behind abuse.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “How TruffleNet Used Stolen AWS Keys to Launch BEC Attacks via Amazon SES”.
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.
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.
Q: How do security teams detect cloud credential abuse before fraud starts?
A: Look for validation and discovery behaviour, not only successful compromise.
Practitioner guidance
- 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.
Bottom line: TruffleNet shows that stolen cloud credentials can be used to turn legitimate AWS services into fraud infrastructure without any platform exploit.
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
👉 Read Unosecur's analysis of the TruffleNet BEC campaign and AWS credential abuse →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 hours ago by NHI Mgmt Group
25/06/2026 3:50 am
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.
A question worth separating out:
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.
👉 Read our full editorial: TruffleNet BEC shows how stolen AWS credentials fuel cloud fraud
This post was modified 5 hours ago by NHI Mgmt Group