The hits keep coming – from surveillance apps leaking plaintext chats of government officials, to your favorite cloud vendors being used against you. Misconfigurations, stale creds, and misplaced trust are fueling the surge. Examining real-world examples of how threat actors are abusing cloud-native environments is a great way to validate and continuously improve readiness and security posture. Here’s a breakdown of six recent cloud attacks, what we can all learn from them, and steps we can take to increase security.
1. TeleMessage “Signal Clone” Breach
Date Reported: May 2025
AWS services: EC2, IAM, S3 (underlying infra)
Exploit path: Hardcoded creds and an exposed archive service handed over plaintext logs – yes, logs – of a Signal clone to an attacker in under 20 minutes.
Impact: Contacts, chats, and internal credentials from hundreds of users, including U.S. government officials and companies like Coinbase.
Why it matters: They sold compliance and encryption; they delivered a plaintext bonfire on AWS.
What you can do:
- Scan code regularly (SAST\DAST) to detect and mitigate hardcoded credentials.
- Use .gitignore and .env files when dealing with secrets in Git based repositories.
- Hunt for potential secrets that might lurk in commits, as anyone that could access the repo could find them.
- Manage secrets securely using AWS Secrets Manager or any other Vault solutions.
- Minimize secrets scopes and limit them specifically to the resources being used.
- Implement least privilege access controls to minimize potential impact when creating or using secrets.
2. Ticket Resale Platform Leaks Half a Million Records
Date Reported: May 2025
AWS services: Likely EC2 or RDS (self-hosted DB)
Exploit path: Wide-open DB – no password, no VPC, no shame.
Impact: 520,000+ customer records: barcodes, names, partial cards. 200 GB of user data exposed.
Why it matters: Storing PII in the cloud without proper safeguards can expose customers and businesses to significant risk and misconfigured databases are a common attack vector.
What you can do:
- Enforce mandatory authentication (managed identity such as SSO) on databases.
- Deploy databases within secure VPCs.
- Regularly audit databases for public exposure, data sensitivity and potential access paths.
3. WorkComposer Dumps 21 Million Screenshots via S3
Date reported: April 2025
AWS services: S3
Exploit path: Unauthenticated bucket, business as usual.
Impact: 21M screenshots of people working – chats, passwords, source code, etc.
Why it matters: It’s not surveillance anymore – it’s a feed for anyone with a browser and bad intentions.
What you can do:
- Apply restrictive bucket policies and IAM rules.
- Enable S3 Access Analyzer to identify unintended public access.
- Continuously monitor and audit S3 permissions.
4. 1,229 AWS Keys Used for SSE-C Ransomware
Date reported: April 2025
AWS services: IAM, S3, SSE-C
Exploit path: Stolen keys turned into encryption bombs using AWS-native tools. No malware needed.
Impact: Dozens of orgs got their S3 data locked with ransom notes left behind.
Why it matters: Cloud ransomware without payloads. Just creds, buckets, and your own KMS against you.
What you can do:
- Aggressively rotate and revoke AWS keys regularly (yes, even on a daily basis!)
- Enable CloudTrail and set up anomaly alerts for unusual encryption activity.
- Limit key permissions strictly to in-scope and relevant resources.
5. SSRF to IMDSv1 Credentials Theft, Again
Date reported: April 2025
AWS services: EC2 (IMDSv1)
Exploit path: SSRF bugs used to siphon short-lived IAM creds from 169.254.169.254.
Impact: Thousands of EC2 instances probed. Real creds stolen.
Why it matters: IMDSv1 still exists.
What you can do:
- Disable IMDSv1, enforce IMDSv2.
- Implement web application firewalls (WAF) to detect and mitigate SSRF attacks.
- Regularly assess web applications for SSRF vulnerabilities.
6. JavaGhost Hijacks SES for Stealth Phishing
Date reported: March 2025
AWS services: IAM, SES, WorkMail
Exploit path: Long-lived creds abused to spin up SES senders and blast phishing from real accounts.
Impact: Victims sent mail they didn’t write – phish that passed SPF and DKIM.
Why it matters: When attackers hijack your cloud email infrastructure, their phishing emails look legitimate to recipients and security tools alike – passing traditional authentication checks.
What you can do:
- Regularly rotate and monitor IAM credentials.
- Use short-lived credentials and multi-factor authentication (MFA).
- Deploy anomaly detection tools for SES usage patterns.
Trends & Mitigation
The volume of cloud attacks continues to rise. In many cases, the scale of cloud adoption has outpaced security. Many recent incidents don’t involve zero-day exploits, but rather misconfigurations and overlooked access points. Attackers are increasingly leveraging cloud-native services like KMS, SES, and IMDS as designed, which makes their activity harder to detect and mitigate.
Best practices to consider:
- Conduct regular asset inventory and configuration audits.
- Demand transparency and security guarantees from vendors.
- Enforce strict policies against credential reuse and hardcoding.
- Apply rate limits and monitor cloud services for anomalous activity.
Enhanced mitigation steps:
- Enforce IMDSv2: Mandate use of IMDSv2 across all instances.
- Aggressive Key Rotation: Implement automated systems to regularly rotate keys and monitor usage.
- Default Deny Policy: Deny public access by default; explicitly permit access when absolutely necessary.
- Comprehensive Monitoring: Enhance visibility with CloudTrail, GuardDuty, and CloudWatch to detect anomalies.
- Vendor Verification: Regular security audits of vendors, including data handling practices.
Remember, cloud security thrives on proactive vigilance. By systematically addressing potential weaknesses and reinforcing best practices, you ensure your cloud environment remains secure and resilient, prepared for both current threats and future challenges.
To see how ZEST delivers proactive exposure management & remediation across cloud, applications and software supply chain, reach out to our team.
