New TruffleNet BEC Campaign Leverages AWS SES Using Stolen Credentials to Compromise 800+ Hosts

TL;DR:
The threat actor dubbed “TruffleNet” exploited stolen credentials to target Amazon Simple Email Service (SES), leveraging AWS infrastructure to send large-scale Business Email Compromise (BEC) phishing. Over 800 unique hosts across 57 networks were used, highlighting how identity compromise can undercut cloud defenses.

What happened

In the TruffleNet BEC campaign, attackers used stolen AWS credentials to gain access to victims’ AWS environments. They carried out automated reconnaissance using the open-source tool TruffleHog to systematically validate the compromised credentials through the GetCallerIdentity API call.
After confirming valid access, the attackers switched to service abuse, using the GetSendQuota API call to identify Amazon SES sending limits before launching large-scale email campaigns from the compromised AWS accounts.
The TruffleNet infrastructure spanned over 800 hosts across 57 distinct Class C networks, all showing consistent open ports and Portainer exposed across systems. The use of Portainer, a web-based management interface for Docker environments, as a central orchestration tool indicated a purpose-built infrastructure rather than a typical botnet. From this foothold, attackers abused Amazon SES to send phishing and BEC emails impersonating trusted vendors, such as fake invoices from ZoomInfo, using domains like zoominfopay[.]com and cfp-impactaction[.]com, and requested high-value ACH payments through typosquatted domains.

Why the issue matters: impact and risk

1. Identity compromise at scale: Valid AWS credentials give attackers access that bypasses most perimeter or host-based defenses because the activity appears legitimate. The campaign shows how cloud identity misuse is a direct route to large-scale fraud.
   
2. Service abuse through trusted infrastructure: By leveraging SES, attackers exploited a highly trusted email service with strong deliverability, making their BEC attempts more credible and harder to block. Because SES email originates from Amazon-owned IPs with an excellent reputation, traditional spam filters and blacklists often fail to detect malicious use.
   
3. Operational sophistication: The use of 800+ hosts, dedicated orchestration platforms, and credential scanning infrastructure underscores how cloud-native abuse is becoming industrialized.
   
4. Broader consequences: Compromised identities can lead to resource abuse, data exposure, phishing campaigns, reputational damage, regulatory penalties, and loss of trust, even if direct data exfiltration is not proven.
   

Attack overview: vector, behavior, and indicators

Attack vector:
Use of stolen AWS credentials (access keys) rather than exploiting a software vulnerability.
Credentials are tested and validated via API calls (GetCallerIdentity), then used to probe SES quotas and set up sending identities.

Behavior:
Hosts conducted queries like GetSendQuota to validate SES abuse readiness.
Use of Portainer to orchestrate hundreds of nodes.
Creation of email identities leveraging DKIM keys compromised from WordPress sites, then sending out BEC-style messages requesting funds via typosquatted domains.

Indicators of compromise (IoCs):
Unexpected AWS GetSendQuota or ListIdentities calls from service accounts or unexpected roles. Large numbers of SES-verified identities were created
in a short timeframe, especially including external domains. Outbound SES activity on accounts with no prior history, particularly where sending volume spikes.
Use of hosts without a poor reputation, suggesting dedicated infrastructure rather than compromised consumer machines.

Who’s affected: scope and systemic exposure

Affected systems:
Any AWS environment that allows access keys to be stolen, where SES is enabled, and where least-privilege controls or monitoring aren’t rigorous. The campaign has shown how BEC can originate from within legitimate cloud resource usage.

Broader relevance:
This approach could apply to any cloud provider with trusted services (email, messaging, compute). Organizations using shared credentials, lacking credential rotation, relying on legacy access keys, or lacking behavioral monitoring are at significant risk.

Immediate remediation checklist

• Rotate all AWS credentials immediately, especially those tied to SES or with administrative privileges.
  
• Enforce MFA for all accounts and roles, including IAM, service accounts, and root/admin access.
  
• Audit IAM permissions: remove dormant accounts, restrict overly broad roles, and apply true least-privilege.
  
• Monitor SES usage: alert on new identities, large sending volumes, external domains as identities, and identity creation patterns.
  
• Monitor AWS APIs and logs: trigger alerts for unusual GetSendQuota, CreateEmailIdentity, ListIdentities, CreateUser, or PutAccountVdmAttributes calls.
  
• Review infrastructure: look for use of tools like Portainer as orchestration interfaces, unusual open ports, or hosts used for credential scanning.
  
• Conduct security awareness: ensure staff understand the risk of BEC and phishing even when emails originate from trusted sources.
  

Short-term and strategic controls

Short-term (0–30 days):

• Enable MFA everywhere.
  
• Disable/rotate any unused or high-risk keys (especially those with SES or email-send permissions).
  
• Begin logging and alerting for SES anomalies and AWS API misuse.
  
• Limit SES sending quotas and monitor reputation metrics.
  

Strategic (30–90+ days):

• Move to identity-aware controls: implement adaptive access, geo-fencing, and behavioral baselining.
  
• Adopt continuous identity monitoring across cloud, SaaS, and hybrid environments.
  
• Remove shared credentials and enforce individual identities for all accounts.
  
• Integrate identity signals into your security operations center: tie together cloud logs, email sending patterns, role creation events, and user behavior.
  

Conclusion & key takeaways

The TruffleNet campaign illustrates how cloud identity compromise has become a high-stakes vector, with attackers leveraging legitimate cloud services for malicious email campaigns and bypassing traditional defenses by acting from within trusted environments. The takeaway is clear: identity must be treated as the new perimeter. Robust credential hygiene (rotate keys, enforce MFA), least-privilege access, and behavioral monitoring are non-negotiable. Organizations must shift from infrastructure-centric protection to identity-centric defense.
‍
In this context, Unosecur’s platform becomes critical, as it correlates identity signals across cloud, SaaS, and hybrid systems, automates remediation, and aligns policy enforcement in real time. When identity is compromised, your entire environment is at risk, and control often hinges on a single stolen credential.

‍