2,975 Keys in 48 Days: The Zerofot Scanner Proves Credential Theft Has Been Automated End to End

Between April 5 and May 23, 2026, one operator collected 2,975 working keys and credentials from 1,742 internet-facing hosts. That is 48 days. The haul, as Gambit Security documented in its August 18 threat intelligence report, breaks down into 661 SSH private keys, 635 AWS access keys tied to 214 distinct accounts, 448 Google Gemini keys, 254 OpenAI keys, 205 GitHub tokens and 176 Anthropic keys.

The operator, a Chinese-speaking actor Gambit tracks as Zerofot, did not write the scanner. Codex and Claude Code wrote it. Zerofot described the work as being for "an authorized CTF sandbox" so the models would not refuse, then spent the next seven weeks running the output against the open internet.

I have read a lot of credential-theft reporting this year. Most of it describes a crew, a toolkit, a set of victims. This one describes a machine, and the machine had a step in it that almost nobody is watching.

The validation step is the whole story

Here is what auto_scan did, in order. It took target lists from internet-wide scans. It looked for exposed files and open directory listings, the ordinary debris of misconfigured web servers: .env files, backup archives, config dumps, .git directories left readable. When it found something it could reach, it downloaded the contents and pattern-matched for credentials belonging to AI providers, cloud platforms, source control and SaaS tools.

Then it did the thing that matters. It called each provider's API to check whether the credential still worked.

Read that again, because it is the load-bearing detail. Zerofot did not report 2,975 credentials found. Gambit reports 2,975 credentials validated. Somewhere between the scraping and the spreadsheet, an automated process made an authenticated request against AWS, against GitHub, against OpenAI, against Anthropic, using keys it had just picked up off a stranger's web server.

Every one of those checks is a network event that a defender could have seen. Almost none of them were seen, because the credentials were real and the request looked like a normal API call from a slightly unusual place. Which is exactly why the same behaviour, aimed at a credential that was never real, is such a clean signal.

Why this scaled the way it did

The scanner is not clever. Anyone who has run a bug bounty program has written something like it. What changed is the cost of writing it and the cost of maintaining it.

Gambit's report notes that Zerofot also used the assistants for the boring parts: deploying infrastructure, managing proxy pools, debugging failures when the pipeline broke. That is the real shift. The historical bottleneck in mass credential harvesting was never the idea. It was the two weeks of unglamorous plumbing, the proxy rotation that breaks on a Tuesday, the parser that chokes on a new file format, the rate limits that get you blocked. An operator with mediocre engineering skills used to lose steam there. Now they ask a model and keep going.

Recovered scripts also showed attempts at cloud lateral movement inside AWS and scanning of exposed Jenkins servers, which tells you the AWS keys were not just being counted. They were being used to look around.

And there was a buyer. Gambit reports the valid AI provider keys were sold on to llde[.]tech, a gateway that resold model access. Think about what that means for the victim. Your Anthropic key gets scraped from a forgotten staging server, validated, bundled and sold to a reseller who fronts cheap inference to strangers. The first you hear about it is a bill, or a rate limit, or nothing at all. Nobody encrypted your files. Nobody left a note. This is the quiet end of the credential economy, and it is the fastest-growing end.

Your scanner and their scanner are not playing the same game

The obvious objection is that this is a secrets hygiene problem, and secrets hygiene is a solved discipline. Scan your repos, rotate on exposure, done.

The numbers say otherwise. GitGuardian's State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets pushed to public GitHub during 2025, a 34% jump year over year and the largest single-year increase they have recorded. Credentials for AI services specifically hit 1,275,105 instances, up 81%. And the finding that should end the argument: of the secrets GitGuardian validated as live back in 2022, more than 64% were still valid in January 2026. Four years. Two-thirds unrotated.

So the scanning works fine. The scanning has never been the problem. The problem is that detection produces a ticket, and the ticket needs an owner, and the owner needs to know what breaks when the key is rotated, and nobody documented that, so the ticket ages. We wrote about this failure mode in detail when we looked at why non-human identities are the biggest blind spot in enterprise security: an API key has no MFA, no session timeout, no conditional access and frequently no named owner. It just works, forever, for whoever holds it.

Meanwhile Zerofot's scanner does not care about your remediation backlog. It cares whether the key returns HTTP 200 today.

There is a second objection worth taking seriously: that exposed .env files on random hosts are a small-business problem, not an enterprise one. Look at the AWS figure again. 635 access keys spanning 214 accounts. That is an average of three keys per compromised account, which is not the signature of hobby projects. That is the signature of organisations with real infrastructure and a staging box somebody forgot about.

What the same report shows about AI on the interactive side

Zerofot was one of three cases in Gambit's report, and the contrast between them is instructive.

A second operator, assessed with medium confidence as an affiliate of The Gentlemen ransomware-as-a-service crew, used Claude Sonnet 4.6 interactively during intrusions at a minimum of six organisations in late June 2026, including an Australian energy utility, a Mauritius financial services firm and manufacturers in Thailand and the United States. The tradecraft that stands out: rather than dumping credentials from memory, the operator had the model reconfigure a compromised FortiGate so that VPN authentication pointed at an attacker-controlled LDAP service. A Python listener on the other end captured a service account password in clear text as it arrived.

That is a genuinely good trick, and it is worth pausing on. No LSASS access. No Mimikatz on disk. No EDR-visible credential dumping at all. The firewall simply asks the wrong server whether the password is correct, and the wrong server writes it down. It belongs to the same family of attacks we covered in the service account lateral movement analysis, where the credential never has to be stolen in any way your endpoint tooling recognises as theft.

Gambit also notes that in the same intrusion the model was asked which databases mattered most to the business, and it ranked them. Their line on this is better than anything I would write: the access was the operator's, the understanding of the business was the model's.

The third case, a Python framework called RAGE built with AI-generated components and a DeepSeek-backed orchestrator, went after exposed Redis, Elasticsearch, Docker, Tomcat, Jenkins, Hadoop YARN, Confluence and Supervisord deployments, mostly to drop cryptominers. In one instance AWS credentials pulled from an exposed Redis instance produced administrative access to a SaaS provider's account.

One operator hunting keys at scale. One operator using the model as a consultant mid-intrusion. One operator automating commodity exploitation. Different skill levels, same underlying change: the tooling floor has dropped, and the thing all three converge on is credentials.

The tripwire is the request they have to make

Go back to the validation step, because it is the only part of Zerofot's pipeline that a target organisation can actually observe.

An attacker who scrapes a credential cannot know if it is live. They have to test it. That test is not optional, it is not skippable, and it happens before any of the damage. A stolen key that is never used is harmless. A stolen key that gets used announces itself, if you have arranged for it to.

This is the entire logic of a credential mine. You place a fake AWS access key in the .env file on the staging box. You place a fake SSH private key in the backup archive in /var/www/backups/. You put a fake Gemini key in the config dump. They cost nothing, they authenticate nothing, and they sit there being uninteresting until an automated scanner three continents away decides to check whether they work.

At that moment you get an alert with an attacker IP, a user agent, a timestamp and a geolocation. Not an anomaly score. Not a correlation that a tier-one analyst has to adjudicate at 3am. A binary fact: something just tried to use a credential that exists for no reason other than to be tried. There is no legitimate path to that key. That is why the false positive rate is zero, and zero is not marketing language here, it is a structural property of a token no real system references.

The economics work in your favour too. Zerofot's scanner is indiscriminate by design, which means it will grab the decoy alongside the real thing and validate both. The same property that made the campaign efficient makes it detectable. Mine2's honeytoken and decoy solutions are built around exactly this asymmetry: attackers have to touch things to learn about them, and touching a decoy is confession.

For the exposed-service side of the problem, the Redis and Jenkins and Elasticsearch instances that RAGE was hunting, MineField's decoy TCP services give you the same signal a layer down. An attacker port-scanning your estate finds a Redis that answers, connects to it, and has now told you they are there before touching anything real.

What I would actually do this week

Three things, in order of how much they cost you.

Start with the hosts that are not in anyone's inventory: staging servers, old marketing sites, contractor-built boxes, anything with a public IP that nobody has SSH'd into for a year. That is where Zerofot's scanner found its 1,742 victims. Enumerate them before someone else does.

Then seed them. Not the production repos, the forgotten ones. A decoy AWS key in the staging .env and a decoy SSH key in the backup directory take minutes to place and cover exactly the file locations auto_scan was built to read.

Last, accept that your 64% is probably worse than GitGuardian's 64% and stop pretending the rotation backlog will clear. It will not. Deception is what you deploy when remediation is slower than exploitation, and every honest secrets program is in that position. We made the same argument about the flood of stolen credentials already circulating in the infostealer epidemic analysis, and nothing in Gambit's report changes it. If anything, the automation makes the gap wider.

The uncomfortable summary of the Zerofot case is that one person with a scanner they did not write extracted 2,975 live credentials in seven weeks, and the only reliable moment any victim could have caught them was a single authentication attempt that looked completely normal. Make that attempt abnormal. Book a Mine2 demo and we will show you what a validation callback against a decoy key looks like from the defender's side of the alert.