Threat in a Bucket: Inside a Live Hacking Operation

Misconfigured cloud storage is a gift to anyone hunting for credentials. While researching exposed buckets, I found something that raised my heart rate: thousands of stolen credentials, and an entire hacking operation’s toolkit, sitting in a public AWS bucket.

The people behind it had spent months collecting exposed AWS credentials from misconfigured servers worldwide. Then they stored the whole operation in a misconfigured bucket of their own. Or, more likely, in a bucket that belonged to one of their victims. Ironic.

A shorter version of this account was first published on LinkedIn .

What was in the bucket

The bucket looked, at first, like it was meant for video. Alongside the videos were millions of saved web responses, lists of IP addresses, and lists of AWS credentials, each one an access key, a secret, and a region. Once the videos and the scraped pages were set aside, what remained was a toolkit for finding credentials and putting them to work.

This was not a handful of scripts. It was an industrial process: collect, check, use, and then keep access even after the original key is rotated.

How the operation worked

Finding credentials

The operators scanned large numbers of websites for exposed Git directories, a common mistake when a repository is left on a server that should never have served it. Where they had stolen source-control tokens, they cloned repositories and searched those too. They also parsed JavaScript files for keys left in client-side code.

They narrowed the search with Amazon’s published IP ranges, so the scans spent more time on hosts that were likely to contain AWS credentials in the first place.

One stolen token led to more repositories, and those repositories led to more keys. The collection fed itself.

Sorting the keys that mattered

A lot of exposed keys are old or useless. The toolkit checked credentials across AWS regions and sorted them by what they could do. The valuable ones could manage users, send email at a high daily quota (on the order of 50,000 messages), or send SMS. The checks ran in parallel, so a large pile of keys could be sorted quickly.

Using them, and staying in

Keys that passed the checks were used immediately, including for spam. Where a key could manage identities, the tooling created a new administrator account. Rotating or deleting the original stolen key did not remove that account. The operators still had a way in.

Stolen credentials also paid for the infrastructure used to steal the next batch. The bucket I found was probably one of those victim accounts, used as a workshop. That is a parasitic loop: compromise an account, then run the next round of theft from inside it.

A known pattern

The tactics match EMERALDWHALE , a global operation documented by Sysdig’s threat research team. That campaign also hunted exposed Git configuration, stole cloud credentials at scale, and parked the loot in a victim’s public S3 bucket.

The toolkit here was built to be operated, not just written. It showed the kind of finish you see when tooling is meant for people other than its authors, in the same way the Magic Cat fraud platform documented by NRK was offered onward to other operators. I am not claiming this bucket is that case. The resemblance is in how shareable the tooling was.

What I did with it

I reported the bucket to AWS, and I asked Norwegian authorities for guidance. NSM, Norway’s national security authority, and Kripos, the National Criminal Investigation Service, confirmed that AWS was the right place to take it. Within a few weeks the bucket was gone, and AWS confirmed they had acted.

That closes one campaign. It does not close the practice. Operations like this run continuously, and a credential that leaks today can be abused within hours.

If a key leaks

Treat the exposure as a compromise, not as a close call.

• Rotate the credential, and assume it was used in the window before you did.
• Look for users and access keys you did not create. A new administrator is the point of this kind of toolkit, and it survives rotation of the key that was originally stolen.
• Log management activity in every region, and alert on identity changes and on unusual email or messaging use.
• Keep secrets out of git and out of client-side code. Scan changes with a secrets scanner before they are committed, and do not deploy .git directories onto anything that answers on the web.
• Prefer short-lived credentials, least privilege, and multi-factor authentication on console users. Turn on account-level Block Public Access for storage unless a bucket is deliberately public.

Scrapers are already looking for the next mistake. This time, they made one themselves.