JavaGhost Uses Amazon IAM Permissions to Phish Organizations


Unit 42 uncovers JavaGhost’s evolving AWS attacks. Learn how this threat actor uses phishing, IAM abuse, and advanced evasion techniques, and find out how to detect and respond.

Researchers at Palo Alto Networks’ Unit 42 have been tracking a persistent threat actor, designated TGR-UNK-0011, which they have confidently attributed to the group known as JavaGhost. As per their investigation, shared with Hackread.com, this group has been active for over half a decade and has recently shifted its focus from website defacement to conducting financially motivated phishing campaigns, particularly targeting cloud environments.

Initially, JavaGhost’s activities, documented on website defacement registries, primarily revolved around altering the content of websites. However, Unit 42’s investigations conducted between 2022 and 2024 revealed that attackers were actively exploiting misconfigurations within organizations’ Amazon Web Services (AWS) environments to launch phishing attacks.

It is worth noting that these attacks did not result from vulnerabilities within AWS itself, but from the exposure of long-term access keys due to configuration errors within the targeted organizations. 

The group’s methodology involves leveraging compromised AWS credentials to gain initial access via the command-line interface (CLI). To evade detection, they avoid the commonly used “GetCallerIdentity” API call, and instead, use “GetServiceQuota,” “GetSendQuota,” and “GetAccount” to blend in with normal AWS activity, avoiding common detection triggers.

Researchers observed that their toolset can also be identified by the use of python urllib3 during the GetSigninToken events. Once inside, they generate temporary credentials and console access using “GetFederationToken” with an “allow all” policy, granting them maximum control.

To establish their phishing infrastructure, JavaGhost manipulates Amazon Simple Email Service (SES) and WorkMail. They create multiple SES email identities, modify DKIM settings, and adjust Virtual Delivery Manager (VDM) and Mail-from attributes. Additionally, they configure AWS WorkMail Organizations and create user accounts, generating various SES and AWS Directory Service (DS) events within CloudTrail logs.

Create Amazon WorkMail Directory Automatically Create Events (Source: Unit 42)
New WorkMail User Creation (Source: Unit 42)

JavaGhost creates new SMTP credentials for sending emails, which leads to the creation of new identity and access management (IAM) users and groups. They also establish IAM users for long-term persistence, often with administrator privileges, and in more recent attacks, create IAM roles with trust policies that allow access from attacker-controlled AWS accounts.  

SMTP Credentials Retrieval Example (Source: Unit 42)

A unique calling card of the group is the creation of EC2 security groups named “Java_Ghost” with the description “We Are There But Not Visible.” They also attempt to leave AWS Organizations and enable all AWS regions, indicating a desire to remove security constraints. 

“Accessing the console via this methodology obfuscates their identity and allows them easier visibility into the resources within an AWS account. Since attackers rarely create temporary credentials to access the AWS console URL, these methods often bypass detection,” researchers noted in their report.

The evolution of JavaGhost’s tactics, from simple access key usage to sophisticated evasion techniques, highlights the group’s increasing sophistication. However, their actions are traceable through CloudTrail logs (a tactic historically employed by Scattered Spider) specifically by examining user agent strings indicating the use of the Python urllib3 library. Moreover, to stay protected from similar attacks targeting AWS environments, organizations should implement a multi-layered security approach. Avoid long-term keys, rotate them, review policies, and monitor for unusual API calls and IAM activity.

Roger Grimes, data-driven defence evangelist at KnowBe4 commented on the latest development stating, “This is another example of how not doing the basics better can hurt you. When clouds took over a decade ago, “experts’ worried about all the new cloud-specific attacks we would see and become accustomed to. But what has proven true over time is that the same things that plague us in on-premise environments for over 2-3 decades are still what plague us in cloud environments. In this case, overly permissive permissions and social engineering. Social engineering is responsible for 70% – 90% of successful attacks. Overly permissive permissions are also a top threat (but surpassed also by vulnerability exploits and stolen credentials),” said Roger.

He further suggested that “If you want to keep hackers and their malware creations out, concentrate on the long-time basics, not just as part of everything you are doing, but primarily what you are doing. If you’re not stopping social engineering, exploits against unpatched vulnerabilities, credential theft (79% of the time through social engineering), and misconfigurations, of which overly permissive permissions are one type, then you aren’t going to stop hackers. The only difference now is you need to learn how to do it in both on-premises and cloud environments. But the threats are the same.”

  1. ShinyHunters, Nemesis Exposed After AWS S3 Leak
  2. Hackers Use Fake PoCs on GitHub to Steal AWS Keys
  3. Tunneling Flaws Put VPNs, CDNs, Routers at Risk Globally
  4. FUNNULL Unmasked: AWS Abused for Global Cybercrime
  5. Codefinger Ransomware Exploits AWS to Encrypt S3 Buckets

Top/Featured Image via Pixabay/TheDigitalArtist





Source link