Not affiliated with AWS
← Back to BlogRSS

AWS Credential Theft Has Been Industrialized

blast-radiuscredential-accessiamsupply-chain

On April 2, 2026, Cisco Talos published details of a large-scale credential harvesting operation they track as UAT-10608. The campaign exploited React2Shell (CVE-2025-55182) to compromise 766 Next.js hosts, then systematically vacuumed credentials from every one of them. AWS keys, database passwords, SSH private keys, Stripe API keys, GitHub tokens, Kubernetes service account tokens. All collected, organized, and made searchable through a web-based dashboard the operators call NEXUS Listener.

The Hacker News coverage called it a credential harvesting operation. That's accurate, but it undersells what's happening. This isn't a one-off campaign. It's the latest example of a trend that's been accelerating for two years: the industrialization of cloud credential theft.

What UAT-10608 actually built

The NEXUS Listener framework isn't a hastily assembled exfiltration script. It's a product. Version 3 of a password-protected web application with a search interface, per-host credential views, and precompiled statistics. The operator can browse compromised hosts, filter by credential type, and get analytical insights across the full dataset.

From 766 compromised hosts, Talos documented what was collected:

Credential type Hosts affected Percentage
Database credentials ~701 91.5%
SSH private keys ~599 78.2%
Shell command history ~245 32.0%
AWS credentials ~196 25.6%
Stripe API keys (live) ~87 11.4%
GitHub tokens ~66 8.6%

The harvesting runs in 10 automated phases: environment variables, JS runtime environment, SSH keys, pattern-matched tokens, shell history, cloud metadata (AWS/GCP/Azure IMDS), Kubernetes service account tokens, Docker container configs, process command lines, and aggregate process environment variables. Each phase calls back to the C2 server on port 8080 with the victim hostname and collected data.

The AWS credentials came from two sources: environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) and the Instance Metadata Service. For hosts running on EC2 without IMDSv2 enforcement, the harvester queried 169.254.169.254 directly for IAM role credentials. For hosts with credentials baked into environment variables or .env files, it simply read them from the process environment.

196 sets of AWS credentials from a single campaign. And each set unlocks whatever that identity can reach.

The blast radius of 196 stolen AWS credentials

A stolen AWS credential is a foothold. The damage it causes depends entirely on what that credential can access: which S3 buckets, which secrets, which databases, which roles it can assume. That's the blast radius.

Consider the attack paths available from the credentials UAT-10608 collected:

Stolen EC2 instance profile credentials (from IMDS)
  -> S3: enumerate and download buckets
  -> Secrets Manager: read database passwords, API keys
  -> STS: AssumeRole into other accounts (if cross-account trust exists)
  -> RDS/Redshift: query databases via stolen secrets

Stolen IAM user credentials (from env vars / .env files)
  -> Same paths as above, but potentially long-lived
  -> No session expiry, no automatic rotation
  -> May have broader permissions than instance roles

This is the same pattern we saw in the LexisNexis breach, where a single compromised identity with broad Secrets Manager access cascaded into 536 Redshift tables and 3.9 million records. And it's the same pattern behind 93 HackerOne reports where SSRF or leaked credentials turned into full infrastructure access.

The difference with UAT-10608 is scale. This isn't one researcher finding one SSRF on one server. It's automated infrastructure compromising hundreds of hosts simultaneously and organizing the stolen credentials for systematic exploitation.

This is a trend, not an incident

UAT-10608 fits into a pattern of credential harvesting operations that have been growing more sophisticated and more frequent since 2024. The common thread: attackers are building infrastructure specifically designed to steal, organize, and monetize cloud credentials at scale.

EmeraldWhale: 15,000 cloud credentials from exposed git configs (October 2024)

Sysdig documented a campaign that scanned over 500 million IP addresses for exposed /.git/config files and Laravel .env files. The operation harvested 15,000 cloud credentials, including AWS access keys matched by the regex AKIA[A-Z0-9]{16}. The attackers compromised 700+ AWS CodeCommit repositories and created new IAM users with admin access. Target lists were sold via Telegram bots for $100+, and the stolen data was stored in a publicly exposed S3 bucket.

AndroxGh0st: 40,000 hosts harvesting AWS credentials from .env files (January 2024)

Severe enough to warrant a joint FBI/CISA advisory, the AndroxGh0st botnet targeted Laravel web applications to steal credentials from .env files. After extracting AWS keys, the malware created new IAM users and policies, then spun up additional EC2 instances for further scanning. The botnet grew to 40,000 controlled devices.

Codefinger: ransomware using stolen AWS keys (January 2025)

The Codefinger operation showed what happens downstream of credential theft. Attackers used stolen AWS keys to encrypt S3 objects with SSE-C (server-side encryption with customer-provided keys), then demanded ransom for the decryption key. Because AWS processes but does not store customer-provided encryption keys, the data is unrecoverable without paying. This isn't an AWS vulnerability. It's a demonstration that stolen credentials have direct ransomware value.

Fabrice: three years of stealing AWS keys from a single PyPI package (2021-2024)

A typosquatting package on PyPI named "fabrice" (mimicking the legitimate "fabric" library with 200M+ downloads) went undetected for over three years while accumulating 37,000+ downloads. The package used the boto3 SDK to extract AWS credentials from environment variables, instance metadata, and configured credential sources, then exfiltrated them to a VPN server in Paris.

The infostealer supply chain

The campaigns above are just the ones targeting cloud infrastructure directly. Beneath them sits a massive infostealer ecosystem that feeds stolen credentials to cloud attackers.

Lumma Stealer, before Microsoft's May 2025 takedown of ~2,300 of its domains, had infected an estimated 394,000 Windows machines. It harvested browser-stored passwords (including AWS console credentials), SSO sessions, and files matching cloud credential patterns. RedLine Stealer, taken down in October 2024 by Dutch National Police and international partners, had millions of infections globally. The credential logs from these stealers are sold on dark web markets and used by groups like ShinyHunters/UNC5537, who weaponized infostealer logs to breach 165 Snowflake customers in May-June 2024, including Ticketmaster (~560 million records) and AT&T (~110 million records).

The pipeline is clear: infostealers harvest credentials from endpoints. Those credentials end up in logs. Attackers buy the logs and use them to access cloud environments. The credential doesn't need to be stolen from the cloud. It just needs to eventually reach it.

The numbers tell the story

The scale of credential exposure keeps growing. GitGuardian's 2025 State of Secrets Sprawl report, covering 2024 data, found:

  • 23.8 million new secrets detected in public GitHub commits (up 25% year-over-year)
  • 7,000 valid AWS keys exposed on Docker Hub across 15 million analyzed images
  • 70% of secrets leaked in 2022 remain valid today, years later
  • 35% of private repositories contain plaintext secrets (9x more likely than public repos)

Meanwhile, Datadog's 2025 State of Cloud Security found that 59% of AWS IAM users have an access key older than one year. Long-lived credentials that sit in CI/CD pipelines, .env files, and developer machines, exactly the kind UAT-10608's harvester is designed to find.

And IBM's Cost of a Data Breach Report has consistently found that credential-based breaches take nearly 10 months to identify and contain, the longest of any initial access vector. The credentials UAT-10608 stole in April 2026 may not trigger an incident until early 2027.

Why this keeps working

Every campaign in this list exploits the same structural problem: credentials that are more accessible than they should be, attached to identities that can reach more than they need to.

UAT-10608 harvested AWS credentials from environment variables and IMDS. EmeraldWhale found them in .git/config files. AndroxGh0st pulled them from .env files. Fabrice stole them from the Python credential chain. Lumma and RedLine scraped them from browser password stores.

The entry points are different. The outcome is identical: the attacker gets a credential, and that credential can reach too much.

The F5 Labs campaign from March 2025 showed this plainly. Automated infrastructure scanned the internet for any SSRF vulnerability on any EC2 instance still running IMDSv1, rotating through six different query parameter names across thousands of targets. The same technique that compromised Capital One in 2019, now fully automated and running continuously.

IMDSv2 blocks the IMDS vector. But as UAT-10608 demonstrates, IMDS is just one of ten collection phases. The harvester also reads environment variables, process memory, SSH keys, shell history, Docker configs, and Kubernetes tokens. Fixing one entry point doesn't help when there are nine others.

Reducing the blast radius

The entry points will keep multiplying. New vulnerabilities appear in web frameworks, new infostealers emerge, new supply chain attacks ship malicious packages. You can't prevent every credential from being stolen. You can control what a stolen credential can reach.

Enforce IMDSv2 on every EC2 instance. UAT-10608 queried IMDS for IAM role credentials. IMDSv2 blocks this because the harvester's HTTP GET can't obtain the required session token. Despite this, only 49% of EC2 instances enforce IMDSv2 as of late 2025.

Eliminate long-lived credentials. 59% of IAM users have access keys older than a year. Each one is a credential waiting to be found in an .env file, a git config, or a browser password store. Use IAM roles with temporary credentials. Use OIDC federation for CI/CD. If a long-lived key exists, assume it will eventually be harvested.

Scope IAM policies to specific resources. The difference between a contained incident and a catastrophic breach is the blast radius of the stolen credential. A role scoped to one S3 bucket yields one bucket. A role with s3:* on * yields everything.

Don't store secrets in environment variables. UAT-10608's very first collection phase reads the process environment. Use AWS Secrets Manager or SSM Parameter Store with scoped IAM access. Rotate secrets on a schedule, and rotate immediately if compromise is suspected.

Audit what each identity can reach. Start from every EC2 instance profile, ECS task role, and Lambda execution role. Trace the AssumeRole chains, the Secrets Manager access, the S3 bucket permissions. That's your blast radius. That's what an attacker gets when they harvest that credential.

Key takeaways

  • Credential harvesting has become an organized operation. UAT-10608 built a searchable web application for browsing stolen credentials across 766 hosts. This is infrastructure, not improvisation.

  • 25.6% of compromised hosts yielded AWS credentials. Talos found 196 sets of AWS credentials from a single campaign. Each set is a foothold with a blast radius determined by its IAM permissions.

  • The attack surface for credential theft keeps expanding. UAT-10608 used React2Shell. EmeraldWhale used exposed git configs. AndroxGh0st used .env files. Lumma and RedLine used browser-stored passwords. The entry points change. The outcome is the same: your credentials end up in someone else's database.

  • Stolen credentials now have direct ransomware value. Codefinger demonstrated that stolen AWS keys can encrypt S3 data with customer-provided keys, making recovery impossible without paying. The credential isn't just an access vector. It's a weapon.

  • 70% of leaked secrets from 2022 are still valid in 2025. GitGuardian's data shows that credential rotation remains the exception, not the norm. Every un-rotated credential is a potential foothold that persists for years.

  • The blast radius is set before the credential is stolen. Every one of these campaigns exploits permissions that already existed. The time to measure what each identity can reach is before an attacker catalogs it in their NEXUS Listener dashboard.

Ready to map what an attacker could reach with your AWS credentials? Sign up for hackaws.cloud and find out before the next harvesting campaign does it for you.