TruffleNet BEC Operation Hijacks AWS SES to Breach 800+ Hosts in Coordinated Credential Theft Campaign

Read full article here: https://www.unosecur.com/blog/new-trufflenet-bec-campaign-leverages-aws-ses-using-stolen-credentials-to-compromise-800-hosts/?utm_source=nhimg

A newly discovered TruffleNet Business Email Compromise (BEC) campaign demonstrates a dangerous evolution in cloud-enabled cybercrime. Instead of compromising email providers directly, attackers are now stealing AWS credentials to infiltrate Amazon SES (Simple Email Service) and send fraudulent emails from trusted cloud infrastructure. This campaign successfully abused 800+ hosts across 57 Class C networks and used stolen SES quotas to send BEC and phishing emails impersonating legitimate vendors, bypassing traditional email security and spam defenses.

This incident signals a clear industry shift: cloud identity has become the primary attack vector, and compromised service credentials now enable attackers to weaponize legitimate cloud services at scale.

What Happened

The TruffleNet attackers began by stealing AWS credentials and systematically validating them using the GetCallerIdentity API call, a method highly effective in confirming whether a key provides usable access without raising alarms.

Once access was confirmed, attackers escalated to service abuse rather than data theft, querying GetSendQuota to determine available Amazon SES sending capacity. They then began:

• Creating SES identities
• Abusing Portainer-orchestrated containers across a distributed network of 800+ hosts
• Sending BEC emails impersonating trusted vendors (e.g., ZoomInfo) from typosquatted domains such as zoominfopay[.]com and cfp-impactaction[.]com

Unlike traditional botnets, the infrastructure displayed consistency and central management, confirming that this was a purpose-built cloud-native BEC factory, not opportunistic malware distribution.

Why This Attack Matters: Impact and Business Risk

1. Cloud identity compromise bypasses traditional security

Valid AWS keys authenticate legitimately, meaning:

• No malware required
• No vulnerability exploitation
• No abnormal login patterns

Security tools that rely on endpoint telemetry, spam filtering, or IP reputation fail to detect this behavior.

2. Abuse of trusted cloud services is extremely effective

Amazon SES has:

• High deliverability
• Trusted IP reputation
• Broad email acceptance across enterprises

BEC emails sent through SES appear far more legitimate than typical phishing messages.

3. Infrastructure shows industrial-scale cybercrime

The use of:

• 800+ dedicated hosts
• Portainer-based orchestration
• Automated credential harvesting and validation

reveals a professionalized and scalable cyber operation, not a one-off attack.

4. Systemic exposure across industries

Any company using AWS credentials without strong identity governance can be exploited in the same manner—even without enabling SES intentionally.

Attack Chain: Vector, Behavior, and Indicators

Key Indicators of Compromise

Organizations should immediately investigate if any of the following are present:

• Unexpected GetSendQuota, ListIdentities, CreateEmailIdentity, PutAccountVdmAttributes API calls
• Sudden spike in SES outbound volume
• SES usage on accounts that historically never sent email
• Creation of new sending identities tied to external domains
• Unusual Docker or Portainer deployments exposed to the internet

Who Is at Risk

Directly vulnerable

• Any AWS tenant using long-lived access keys
• Any environment where IAM least-privilege is not enforced
• Workloads without MFA, rotation, or credential monitoring
• Teams with dormant SES capabilities not actively in use

Broader implications

This playbook can extend to:

• Azure (SendGrid, Logic Apps)
• Google Cloud (Gmail API)
• Multi-tenant cloud email APIs
  Investments in infrastructure security are not enough when identity is the attack surface.

Immediate Remediation Checklist

Zero-Day Response (0–7 Days)

• Rotate all AWS access keys with SES privileges
• Enforce MFA across every IAM identity, including service roles
• Restrict SES sending quotas for accounts that do not require email operations
• Investigate unexplained SES identities or DKIM configurations

30-Day Hardening

• Implement least-privilege IAM policies
• Block creation of SES identities by default
• Alert on:
  • GetSendQuota
  • CreateEmailIdentity
  • PutAccountVdmAttributes
  • New IAM user creation

Long-Term Strategy

• Move to ephemeral credentials and dynamic secrets
• Eliminate shared access keys
• Integrate identity telemetry into SIEM/SOAR
• Adopt identity risk-based authentication and continuous monitoring

Conclusion: The New Reality of Cloud-Enabled BEC

The TruffleNet campaign proves that identity—not infrastructure—is the new perimeter. Attackers no longer need to compromise email service providers; they compromise cloud identities and weaponize private, trusted services.

Companies that rely only on perimeter defense, email filtering, or endpoint monitoring are now defenseless against attacks launched from inside trusted cloud services.

Modern security requires:

• Continuous monitoring of identity behavior
• Real-time correlation across cloud, SaaS, and workloads
• Automated remediation at the identity layer

Where Unosecur Fits

Unosecur’s identity security platform detects and mitigates campaigns like TruffleNet by:

• Correlating IAM and API actions across cloud + SaaS + hybrid systems
• Detecting identity anomalies (e.g., new key usage, quota probing, privilege drift)
• Automating remediation workflows to stop misuse before damage occurs

In a world where one stolen credential can compromise an entire cloud environment, identity-centric security is no longer optional—it is foundational.