Attackers Turned a Company's AI Services Back On After It Had Switched Them Off — Then Billed It $1 Million

Table of Contents

• What Google actually reported, and when
• Terms worth defining before going further
• How the attack actually works, step by step
• The business model behind it — and why that's the scarier part
• The one documented case with real numbers
• What Google itself recommends
• Why this matters whichever cloud platform you work on
• What we're not claiming

Most cloud security stories this year have been about data: who got in, what they took, who they sold it to. This one is different in a way that's worth sitting with — a wave of attacks reported by Google this week isn't about stealing anything from a victim's cloud account at all. It's about using it. Specifically, using it to run artificial intelligence workloads that someone else pays for, at a scale large enough to generate six-figure bills in a single day. One detail from Google's own research sums up how brazen this has gotten: in several cases, companies had already turned their AI services off, and attackers used stolen credentials to switch them back on.

What Google actually reported, and when

The research comes from Google's Threat Intelligence Group (GTIG), with incident-response detail added by Mandiant, Google's security consulting arm. Three outlets — BleepingComputer, CSO Online, and Help Net Security — covered it the same day, November 3, 2026, each citing the GTIG blog post directly. Mandiant's own contribution, per Help Net Security's coverage, is concrete: "In 2026, Mandiant responded to several of these LLMjacking incidents," recorded across the financial services, retail, technology, and transportation sectors in North America, South America, and Asia Pacific. None of the three outlets names a specific victim company, a specific cloud provider, or a specific AI platform — this is reported as a cross-industry, cross-region pattern rather than an incident at any one named organization.

Terms worth defining before going further

LLMjacking is the term security researchers use for stealing access to large language model services — the AI systems behind products like chatbots and coding assistants — and using that stolen access to run workloads the legitimate account holder never authorized, with the resulting usage charges landing on the victim's bill.

Service account key is a credential that lets software, rather than a person, authenticate to cloud services automatically — similar in concept to the application credentials covered in identity-focused cloud security generally. If one leaks into a public code repository or sits on an improperly secured machine, anyone who finds it can use it exactly as the legitimate software would have.

LLM mixer, a term used in Google's own research, refers to a resale operation that takes stolen AI access and repackages it for other customers — effectively a black-market subscription service built entirely on top of other people's stolen cloud credentials.

How the attack actually works, step by step

Google's research describes two distinct operational patterns feeding this activity. One cluster of attackers scans the internet for publicly exposed LLM endpoints — AI services left reachable without proper access controls. The other steals valid credentials directly: service account keys, GitHub personal access tokens, active session tokens, and LLM API keys, typically harvested from unprotected machines or accidentally committed into public code repositories. Help Net Security's coverage adds a specific technique: one threat cluster, tracked as UNC6993, got in through a misconfigured service account key, while a separate scheme used a fake portal that tricked visitors into pasting in an active access token directly — a method that sidesteps passwords and MFA entirely, since the victim hands over an already-authenticated session rather than credentials that would trigger either check.

Once attackers have working access, the pattern described across all three sources is similar: they probe for further credentials, sometimes create backdoor accounts, and in some cases exploited a specific vulnerability, CVE-2026-40217 in LiteLLM, to escalate an ordinary limited-scope API key into one with administrative privileges. CSO Online's coverage adds a detail about evasion: attackers validate stolen keys using requests capped at a single output token, specifically to stay under the usage thresholds that would otherwise trigger an automated billing or security alert before the real exploitation begins.

The business model behind it — and why that's the scarier part

What separates this from a typical credential-theft story is what happens after access is obtained: it gets resold. Google's research describes "LLM mixers" — services like the ones named in coverage, Jet Night and newapi.pro — that take stolen AI access and repackage it into subscription products for other buyers, who may have no idea the underlying access was stolen at all. Help Net Security reports that one of these services, Jet Night, offered unlimited access for roughly $60 a month, against roughly $100 to $250 for a comparable legitimate subscription — a price difference that only works because the underlying compute is being paid for by someone else entirely. Request volumes from these resale operations sometimes exceeded 1,000 requests per second, logged by the cloud provider as ordinary, legitimate consumption, and billed accordingly to whoever actually owned the compromised account.

The one documented case with real numbers

Across the three outlets, one specific example recurs with consistent figures: a case Google refers to by the resale brand name "Jet Night," in which an attacker made more than 500,000 LLM API calls in under eight hours, passing along what BleepingComputer describes as "nearly one million dollars in token costs" to the victim organization. That's the single most concrete data point in the coverage — everything else is described as a range ("exceeding $100,000 in a single day," "cumulative charges reaching up to roughly $1 million") rather than tied to one named, documented incident the way the Jet Night case is.

One detail from Help Net Security's reporting is worth repeating on its own because it captures the brazenness of this activity better than any dollar figure: in several incidents Mandiant investigated, the victim organization's AI services had actually been switched off at the time of compromise, and the attackers used stolen access keys specifically to turn them back on before running up charges. That's not an attacker quietly riding along on an account that was already active — that's an attacker reactivating a service a company had deliberately disabled, which should reframe how anyone thinks about "disabled" as a security state for cloud AI access.

What Google itself recommends

Rather than general advice, Google's own mitigation guidance, as relayed across the three sources, is specific: deny all permissions not explicitly required, including access to cloud LLM services themselves for accounts that have no legitimate reason to touch them; use centralized secrets management with actual rotation schedules rather than long-lived static keys; deploy phishing-resistant MFA; actively monitor for "shadow AI" — AI services spun up or accessed outside of sanctioned, tracked channels; set hard API usage and spending limits rather than relying on after-the-fact bill review; and keep cloud audit logs and AI inference logs both enabled and actually monitored, rather than collected and ignored until an invoice forces the question.

Why this matters whichever cloud platform you work on

None of the coverage reviewed for this piece names AWS, Azure, or Google Cloud specifically as the affected provider — Google's own research describes this as a cross-provider pattern, and the mechanics (stolen service credentials, exposed endpoints, resold access) apply to any cloud platform offering AI services with usage-based billing, not to one in particular. That's actually the more useful framing for anyone learning cloud infrastructure: this isn't a story about a flaw in one vendor's product, it's a story about what happens when credential hygiene and cost monitoring are treated as separate concerns instead of the same discipline. IAM access policies get dedicated attention in Innovative Academy's AWS Training in Bangalore, alongside the ongoing discipline of actually reviewing a cloud bill and investigating what's driving it rather than only glancing at the total — which, between the two of them, cover most of what Google's own guidance keeps circling back to. A narrowly scoped service account credential and a spending alert configured to actually fire aren't advanced techniques; they're fundamentals, and this story is what happens at scale when they get skipped. Contact for course details: 8447712333.

What we're not claiming

No specific cloud provider's platform is shown to have a vulnerability enabling any of this — none of the three sources reviewed names AWS, Azure, or Google Cloud as uniquely implicated, and the attack vector described is stolen credentials and exposed endpoints, not a platform-level flaw. Nor should $1 million be read as a typical bill from this kind of attack; that figure sits at the higher end of what's been documented, with the Jet Night case standing out specifically because it's the one incident where a concrete number is tied to a described, specific attack rather than folded into an aggregate range. No victim company is named in any source checked here, and the sector and regional breakdown reflects Mandiant's own incident-response caseload — who called Mandiant in for help — rather than necessarily the full scope of how widespread this activity is industry-wide.