Eight Tokens at Midnight: Why Stolen API Keys Are the New Crypto Mining

TL;DR. A low-balance email I almost ignored exposed a compromised LLM API key being drained by an automated bot. The forensic trail showed no server breach, just a credential swept off the machine, likely by a compromised dependency. The lesson: API keys are now liquid cash, and attackers have built a quiet economy around finding, testing, and draining them. Treat every key as disposable, set spend caps, and enable request logging before you need it.

It started with an email I almost ignored.

I was logged into a notebook, doing something completely unrelated, when a message from an LLM provider slid into my inbox: my credit balance was running low. On any other day that's a mundane, almost reassuring kind of notification, the sort of thing you file under "deal with it later." But this time a small detail snagged my attention. I wasn't using that provider for anything at that moment. Nothing of mine was running against it. No job, no batch, no background process should have been spending a cent.

A low balance you can explain is housekeeping. A low balance you can't explain is a signal. So instead of filing it away, I opened the usage dashboard right then and there.

A Key With Exactly One Job

What I found was a key calling top-tier chat models, including several different frontier models, in a tight cluster of requests. That alone wouldn't be alarming, except for one thing: this was a key with exactly one job. It existed for a single project, wired into a single pipeline, and that pipeline does not call those models. The traffic on the dashboard didn't match any workload I own.

Someone, or something, was spending my money on inference I never asked for.

That's the moment a vague unease becomes a concrete problem. The key was clearly compromised. The interesting question, the one worth a few hours of attention, was how, and what it implied. So I sat down to investigate, with an AI assistant alongside me to help comb through logs faster than I could alone, and we started walking the suspect list.

Walking the Suspect List

The instinct with a leaked credential is to assume the worst: someone broke into the machine. But "assume the worst" isn't the same as "confirm the worst," so we went looking for evidence rather than reaching for a conclusion.

First hypothesis: did the key get committed somewhere it shouldn't have? We checked whether it had ever ended up in version control, in a config file under source control, or pasted into anything that gets shared. It hadn't. The key lived in one place, a local environment file, and nowhere else we could find.

Second hypothesis: was it reused across projects? No. It was scoped to a single project. One key, one purpose, one file.

Third hypothesis, the big one: did someone get onto the machine itself? This is where you want hard evidence, not vibes. We pulled the authentication logs and reconstructed who had logged in and from where. There was a wave of the usual background noise that every internet-exposed host endures, automated brute-force attempts hammering away from a rotating cast of addresses. Crucially, none of those attempts succeeded in the window that mattered. We pinned down when the current key had actually been written to disk, and after that moment every successful login came from our own network. No external session. No stranger at the console.

We checked the boring-but-important things too: file permissions on the secret, shell histories for anything resembling an exploit being downloaded or compiled, suspicious scheduled tasks, processes phoning home, unexpected listeners. Nothing jumped out. The host looked intact.

Which left an uncomfortable shape to the problem: a key that never left a single file on a machine nobody seemed to have broken into was, nonetheless, being spent by someone else.

The Fingerprint in the Timeline

The breakthrough wasn't a smoking gun. It was a rhythm.

When we laid the abusive requests out on a timeline, a very particular pattern emerged. The first event was tiny, a request of roughly eight input tokens and a handful of output tokens, fired off in the dead of night. It cost a fraction of a cent and clearly produced nothing useful. It wasn't work. It was a question: is this key alive?

Then nothing, for about nine hours.

And then, mid-morning, the real activity arrived in a burst: a rapid sequence of calls spread across several different models, one after another, including one enormous request, on the order of half a million input tokens in a single shot, that accounted for the overwhelming majority of the total spend. The whole episode cost only a few dollars. But the shape of it told the story.

That cadence (validate at an odd hour, sit idle, then consume in a concentrated burst hopping between models) is not what a targeted human attacker who owns your box looks like. Someone with real access to your machine doesn't need to test whether your key works; they can read it and use it. What this looked like instead was an assembly line: a scanner finds a credential somewhere public, an automated check confirms it's valid, the key goes into a queue, and later a consumer drains it. The model-hopping is the tell of someone probing what this key can reach rather than running a known workload.

It's commodity abuse, not a personal vendetta. That reframing mattered, because it pointed the explanation away from "your server is owned" and toward "your key got swept up off the machine."

When the Leak Isn't on Your Machine

This is, oddly, the more reassuring outcome. If the host itself were compromised, the blast radius would be everything on it. A key that leaked off the machine (scraped from somewhere it briefly touched, harvested by a tool you trusted, picked up in transit) means the box is probably fine and the damage is bounded to one credential you can kill with a single click.

It's also the more humbling outcome, because we couldn't point to the exact moment of exposure. And honestly, that's normal. You don't always get a clean answer. The most likely vectors for "the key left without anyone visibly breaking in" are unglamorous: a credential pasted somewhere it shouldn't have been, a log that captured an environment variable, or, the one I keep coming back to, a compromised dependency.

The Dependency You Never Read

We're living through a steady drumbeat of supply-chain attacks against package ecosystems. Popular libraries get hijacked. Malicious versions get published under names one keystroke away from the real thing. Some recent ones behave like worms: the moment they're installed or imported, they rifle through environment variables and config files looking for anything that smells like a secret, ship whatever they find to an attacker, then try to spread to the next victim.

Here's why that's the perfect explanation for a leak you can't trace. A secret loaded into a process's environment is readable by every line of code in that process, including the dependency buried three levels down that you never opened and never will. You audited your code. You didn't audit the transitive dependency that your dependency's dependency pulled in last week. If one of those was carrying a stealer, your key was gone the instant the process started. No dramatic login, no shell history, no broken door, just a value read from memory and sent out over an ordinary HTTPS connection that looks like every other API call your app makes.

I'm not claiming that's what happened to us. I'm saying it's a vector that produces exactly the symptoms we observed, and that you may never be able to confirm or rule it out. Plan for that ambiguity.

Why Nobody Mines Crypto on Your Box Anymore

Step back and the bigger pattern is hard to miss: the economics of compromise have shifted.

For years, the default payload on an opportunistically-hacked machine was a crypto miner. It made a kind of sense when the only thing your box was good for was its CPU. But mining on stolen hardware is loud. It pins your processors, spikes your power and your bills, gets noticed, and gets cleaned up. The payout has cratered.

A valid API key is a different kind of prize entirely. Tokens are expensive, and frontier inference is cash. A working key is immediately liquid:

• It can be drained directly for free inference.
• It can be resold on a market that's hungry for valid credentials.
• It can be wrapped into a "free LLM" service that quietly bills your account.

And it's silent. The traffic blends in with legitimate usage. There's no fan noise, no thermal alarm. The first sign you get might be a low-balance email at the wrong time. Why steal CPU cycles to slowly mint a volatile coin when you can steal a key and resell premium inference today?

That's the shift I'd bet on continuing. The thing on your machine worth stealing is no longer the silicon. It's the credentials.

What We Changed the Same Afternoon

We didn't tear the machine down to the studs. The incident was contained and the cost was trivial. But a few changes were obvious and cheap:

• Kill the key immediately. Revocation is the one action that's both instant and total. Everything else is investigation; this is the tourniquet.
• Shrink the attack surface. We closed off remote access that didn't need to be exposed in the first place. Less reachable means less interesting.
• Turn on request logging. The provider's input/output logging had been off, which is exactly why we couldn't see what the attacker actually prompted. Next time, and there will be a next time, the content of the abusive requests will tell us far more than the billing line ever could.
• Tighten the secret's permissions. A credential file readable by more accounts or processes than strictly necessary is a credential waiting to be read.

A Field Guide for the Next Time

If you run anything that holds inference credentials, a few habits make these episodes boring instead of scary:

1. Treat every key as disposable. Assume it will leak eventually. Scope it narrowly, give it the least privilege that works, and make rotation a non-event rather than a fire drill.
2. Set spend limits and alerts. A hard cap turns a "few dollars" story into a "zero dollars" story, and a usage alert is sometimes the only tripwire you've got.
3. Enable logging before you need it. Forensics you didn't configure in advance is forensics you don't have.
4. Watch the rhythm, not just the total. The cost told me that something was wrong; the timeline told me what kind of wrong. Cheap abuse can still teach you who you're dealing with.
5. Respect the supply chain. Pin versions, prefer lockfiles, be suspicious of fresh releases of critical packages, and remember that a secret in your environment is visible to every dependency you run.

Keys Are Cash Now

The part that stays with me isn't the three dollars. It's how close I came to never looking. An unexplained notification at an inconvenient moment was the entire difference between catching this and shrugging it off.

We've spent a long time defending machines as if their value were their hardware. The attackers have already moved on. The valuable thing on your system is the small string of characters that lets it spend real money on someone else's behalf, and there is now a quiet, automated economy built around finding those strings, testing them in the dark, and draining them in the light.

So the next time a balance looks lower than it should, don't file it under housekeeping. Open the dashboard. The eight tokens someone spent at midnight to see if your key was alive are the cheapest warning you'll ever get.

FAQ

Q: How do I know if my API key has been stolen?

The clearest signals are unexplained spending and a usage pattern that doesn't match any workload you own. Check your provider's usage dashboard for calls to models or at times you never use. A small validation request followed hours later by a burst of model-hopping calls is a classic sign of automated credential abuse rather than legitimate traffic.

Q: Why are attackers stealing API keys instead of installing crypto miners?

The economics changed. Crypto mining on stolen hardware is loud, pins the CPU, raises power bills, and gets noticed and cleaned up, while payouts have collapsed. A valid LLM API key is silent and immediately liquid: it can be drained for free inference, resold, or wrapped into a paid "free LLM" service that bills your account. The traffic blends in with normal usage.

Q: My server logs show no breach but my key was used. How is that possible?

The key likely leaked off the machine rather than through a server compromise. A secret loaded into a process's environment is readable by every line of code in that process, including transitive dependencies you never audited. A compromised package can read environment variables and send them out over ordinary HTTPS, leaving no login, no shell history, and no broken door.

Q: What should I do the moment I suspect a key is compromised?

Revoke the key first. Revocation is instant and total, and everything else is investigation. Then close off any remote access that doesn't need to be exposed, enable request logging if it was off, and tighten file permissions on the secret. Investigate the timeline afterward to understand what kind of attacker you're dealing with.

Q: How can I limit the damage from a leaked key before it happens?

Set hard spend limits and usage alerts so a leak becomes a zero-dollar event instead of a surprise bill. Scope each key to a single purpose with least privilege, make rotation routine, enable input/output logging in advance, and treat your dependency supply chain as part of your attack surface by pinning versions and using lockfiles.