ENV file vulnerabilities resulted in massive exploitation. Over 110,000 domains have been affected by a significant ransomware campaign that Palo Alto Networks has detected. Attackers gained access to data stored in cloud storage by using wrongly set up ENV files in AWS and demanding a ransom for it.
How did they do it ?
The attackers achieved this by making use of exposed environment variable files (.env files), which held private information like login passwords for different apps.
Throughout this campaign, a number of security mistakes were made, including the following:
- revealing environmental variables
- Making use of long-lasting credentials
- Lack of architecture with the least privilege
About the Campaign
The campaign operation used Amazon Web Services (AWS) settings to set up the attack structure. Then, it took advantage of this foundation to search over 230 million unique targets for sensitive data.
With 110,000 domains as the objective, almost 90,000 unique variables in the.env files were produced by this effort. Of those, 7,000 were associated with cloud services used by organisations, and 1,500 were linked to social media profiles. Additionally, in order to make the operation easier, the attackers exploited several source networks.
The following were used by the attackers in their ransom campaign:
- To carry out reconnaissance and initial access operations, use the onion router (Tor) network.
- Using virtual private networks (VPN) to move laterally and exfiltrate data
- Endpoints for virtual private servers (VPS) for additional campaign components
Attackers gained initial access to the cloud environments of their victims by exploiting environment files (.env) that were left unprotected in the online applications of the victim organisation. Organisations must stick to security best practices and never publish environment files publicly because of the security risks connected to the authentication data kept inside.env files.
Several services, including the following, were the focus of these discovery operations:
Simple Storage Service (S3), Simple Email Service (SES), and IAM Security Token Service (STS).
Using the following API calls, the threat actors were then able to carry out more thorough discovery activities against AWS SES:
Signals to compromise
VPN Endpoints
- 139.99.68[.]203
- 141.95.89[.]92
- 146.70.184[.]10
- 178.132.108[.]124
- 193.42.98[.]65
- 193.42.99[.]169
- 193.42.99[.]50
- 193.42.99[.]58
- 195.158.248[.]220
- 195.158.248[.]60
- 45.137.126[.]12
- 45.137.126[.]16
- 45.137.126[.]18
- 45.137.126[.]41
- 45.94.208[.]42
- 45.94.208[.]63
- 45.94.208[.]76
- 45.94.208[.]85
- 72.55.136[.]154
- 95.214.216[.]158
- 95.214.217[.]173
- 95.214.217[.]224
- 95.214.217[.]242
- 95.214.217[.]33
Hash
- SHA256 for Lambda.sh – 64e6ce23db74aed7c923268e953688fa5cc909cc9d1e84dd46063b62bd649bf6
In order to ensure monitoring and the identification of suspicious activity, it is recommended that organisations wishing to secure their cloud environments employ temporary credentials, stick to the least privilege principles, and enable all available event logs. Securing cloud resources can also be greatly enhanced by turning on sophisticated Amazon security features like GuardDuty and CloudTrail.
HackingBlogsGroup Join Our Official Telegram Group for the PoC Even_log.txt
