Hackers Exploit AWS Misconfigurations to Launch Phishing Attacks via SES and WorkMail

AWS Exploited for Phishing Campaigns – Why Are Organizations Under Attack?
Recently, security experts from Palo Alto Networks Unit 42 uncovered a group of hackers exploiting Amazon Web Services (AWS) misconfigurations to launch sophisticated phishing campaigns.
While these attacks do not exploit vulnerabilities within AWS itself, they take advantage of organizational misconfigurations to hijack services like Amazon Simple Email Service (SES) and WorkMail for sending phishing emails. This tactic allows attackers to bypass email security measures, making it easier to deceive victims.
Who’s Behind This Campaign?
Palo Alto Networks has tracked a hacker group dubbed TGR-UNK-0011, believed to be linked to another group known as JavaGhost. Emerging in 2019, JavaGhost initially focused on website defacement attacks, but since 2022, they’ve shifted to financially motivated phishing via email.
Once they successfully Exploit a system, JavaGhost can:
✅ Access a victim’s AWS environment using exposed access keys.
✅ Send spoofed emails via SES and WorkMail to trick targets.
✅ Evade detection, as emails originate from a legitimate source.
✅ Establish anonymization mechanisms to cover their tracks.
How Did Hackers Breach AWS?
1. Stealing AWS Access Keys
Rather than exploiting AWS vulnerabilities, hackers capitalize on victims’ configuration errors, such as:
🔸 Exposed AWS credentials on platforms like GitHub, Jira, or other storage services.
🔸 Overly permissive IAM (Identity and Access Management) access keys.
🔸 Using the AWS CLI (Command Line Interface) to infiltrate victim systems.
With stolen access keys, hackers can leverage the AWS CLI to perform malicious actions within a victim’s AWS account.
2. Setting Up Attack Infrastructure with SES and WorkMail
Once inside, JavaGhost exploits SES and WorkMail to orchestrate phishing campaigns:
📌 Creates new SES and WorkMail accounts.
📌 Configures SMTP credentials for mass email distribution.
📌 Uses AWS to send emails, lending them an air of legitimacy.
Since these spoofed emails come from a trusted source, they often bypass victims’ security filters, increasing the likelihood of successful deception.
3. Maintaining Control with IAM and EC2
To ensure long-term access, hackers create new IAM accounts and:
✅ Use some accounts for immediate attacks.
✅ Leave others dormant as “backdoors” for future intrusions.
Additionally, JavaGhost sets up EC2 security groups named “Java_Ghost” with the description “We Are There But Not Visible”. While these groups contain no security rules and aren’t assigned to resources, they appear in CloudTrail logs, serving as a “signature” of the hacker group.
Lessons Learned: How to Protect AWS from These Attacks?

These attacks don’t target AWS directly but exploit user configuration mistakes. Here are some steps organizations can take to safeguard their AWS environments:
🔹 1. Secure and Control AWS Access Keys
- Never expose IAM access keys publicly (e.g., on GitHub).
- Use IAM Roles instead of IAM Users to minimize credential exposure risks.
- Limit IAM permissions based on the least privilege principle (grant only what’s necessary).
🔹 2. Monitor and Detect Anomalous Activity
- Enable AWS CloudTrail to track suspicious behavior.
- Set up alerts in AWS GuardDuty to detect unauthorized access.
- Use AWS Config to audit security configurations.
🔹 3. Secure SES and WorkMail
- Restrict SES email-sending permissions to trusted accounts only.
- Enable DKIM and SPF for SES to prevent email spoofing.
- Monitor SES and WorkMail activity for unusual behavior.
Conclusion
The JavaGhost attacks highlight how hackers can exploit AWS misconfigurations to execute phishing campaigns. While AWS itself isn’t directly compromised, organizations that fail to secure their accounts risk losing control to malicious actors.
💡 Protecting AWS isn’t just Amazon’s responsibility—it’s yours too. Proactively audit and strengthen your security to avoid becoming a target of these bad actors! 🚀
👉 Have you ever encountered an AWS-related security incident? Share your experience in the comments below! 🔥