Full Report
Threat actors are targeting Amazon Web Services (AWS) environments to push out phishing campaigns to unsuspecting targets, according to findings from Palo Alto Networks Unit 42. The cybersecurity company is tracking the activity cluster under the name TGR-UNK-0011 (short for a threat group with unknown motivation), which it said overlaps with a group known as JavaGhost. TGR-UNK-0011 is known to
Analysis Summary
# Threat Actor: TGR-UNK-0011 (Overlaps with JavaGhost)
## Attribution & Identity
* **Identification:** Tracked by Palo Alto Networks Unit 42 as **TGR-UNK-0011** (Threat Group with Unknown Motivation).
* **Aliases/Associations:** Overlaps with the threat actor known as **JavaGhost**.
* **Activity Start:** Known to be active since 2019.
## Activity Summary
The actor's activity has evolved significantly:
1. **Historical Focus (Pre-2022):** Primarily focused on defacing websites.
2. **Current Focus (Since 2022):** Pivoted to sending phishing emails for financial gain by exploiting AWS misconfigurations. They leverage victims' exposed AWS access keys to send phishing messages via Amazon Simple Email Service (SES) and WorkMail, effectively outsourcing their email infrastructure.
## Tactics, Techniques & Procedures
* **Initial Access/Persistence:** Gaining initial access by obtaining exposed long-term access keys associated with Identity and Access Management (IAM) users, allowing access via the AWS Command Line Interface (CLI).
* **Persistence:** Creating numerous IAM users, some of which appear to be unused, serving as long-term persistence mechanisms.
* **Defense Evasion:** Evolving tactics between 2022–2024 to use advanced defense evasion techniques to obfuscate identities in CloudTrail logs (a tactic historically exploited by Scattered Spider).
* **Privilege Escalation/Access:** Generating temporary credentials and login URLs to gain AWS console access, allowing identity obfuscation and resource visibility.
* **C2/Infrastructure Abuse:** Using the victim’s compromised AWS account to create new SES and WorkMail users, setting up new SMTP credentials, and leveraging a custom IAM role with an attached trust policy for lateral movement/access.
* **Notable Tactic:** Abusing legitimate AWS services (SES/WorkMail) means phishing emails originate from known, trusted organizational senders, bypassing typical email protections.
* **MITRE ATT&CK IDs:** Not explicitly provided, but covered techniques relate to Cloud Compromise and Credential Access.
## Targeting
* **Sectors:** Not explicitly detailed, but the focus on AWS misconfigurations suggests any organization utilizing AWS infrastructure is at risk.
* **Geography:** Not specified in the summary.
* **Victims:** Referenced generally as organizations with misconfigured AWS environments.
## Tools & Infrastructure
* **Malware Families Used:** None explicitly named, but custom techniques utilizing AWS native services are key.
* **Infrastructure (C2, domains, IPs - defang URLs):**
* **Abused Services:** Amazon Simple Email Service (SES) and Amazon WorkMail (used for phishing infrastructure).
* **Access Method:** AWS CLI.
* **Artifacts:** Exposed AWS Access Keys, temporary credentials, new IAM users/roles.
## Implications
The threat actor presents a sophisticated supply chain risk by weaponizing a legitimate cloud provider's services (SES/WorkMail). This evades traditional email security controls because the malicious communications appear to originate from trusted internal or established external senders. The reliance on AWS misconfigurations shifts the defensive focus toward rigorous cloud security posture management rather than perimeter defense.
## Mitigations
* Audit and remediate all AWS environment misconfigurations that expose long-term access keys.
* Implement strict least privilege controls over IAM users and roles within AWS accounts.
* Monitor for anomalous creation of SES/WorkMail users and SMTP credentials within the AWS environment post-initial access.
* Review CloudTrail logging integrity and monitor for techniques designed to obfuscate IAM identities in logs.
* Implement credential rotation policies for any long-lived access keys.