```
Attackers who steal cloud credentials are quietly running their AI inference bills through other people's accounts, and the tab is growing fast: Google says LLMjacking campaigns it has tracked have generated roughly $1 million in cumulative fraudulent cloud AI charges, with some victim organisations burning through more than $100,000 in a single day, according to BleepingComputer.
That $1 million figure reflects only what one vendor observed on its own platforms — a floor rather than a ceiling — and the daily spikes suggest the true industry-wide cost is considerably higher.
What LLMjacking actually is
LLMjacking is credential theft with an AI-shaped payload. Intruders obtain cloud API keys or tokens — through phishing, leaked secrets in public repositories, exposed management consoles or previously compromised workloads — and then point them at hosted large-language-model and GPU-accelerated services. The legitimate account owner pays for the compute; the attacker gets anonymous, scalable model access they never had to build or bill for.
In structure it echoes cryptojacking, the wave of illicit mining that dominated cloud abuse a decade ago. The economics are different in three ways that matter:
Unit cost. A commodity mining rig trickles cents per hour. A GPU accelerator instance is orders of magnitude more expensive per hour, so a modest, unattended footprint turns into a five-figure invoice before anyone opens a console.
Always-on spend. Model endpoints and inference services stay warm while idle. Unlike a batch job that finishes, a forgotten deployment keeps accruing charges with no user activity to flag it.
Quiet legitimacy. The traffic looks like ordinary API usage. It does not trigger the malware detections, process anomalies or egress patterns that SecOps teams typically watch for, so it travels under the radar until Finance asks why the bill tripled.
Where detection breaks down
The failure point is usually organisational, not technical. Spend anomalies surface with procurement and finance, whose dashboards track budgets; telemetry about which identity provisioned which accelerator sits with security operations. Each team sees half the signal. Without hour-level alerting that merges the two, an attack can run for days before either side reacts.
Google's disclosure, as reported by BleepingComputer, lands at a moment when AI compute is becoming both a strategic asset and an attack surface — a duality that changes how cloud teams should prioritise hygiene.
Five controls worth implementing now
None of the mitigations are novel; most are hygiene that remains under-deployed:
- Credential hygiene and exposure scanning. Treat secrets as high-value assets: no long-lived keys in code, config files, CI pipelines or public repositories, with continuous scanning for accidental exposure.
- Short-lived credentials and workload identity. Replace static access keys with workload identity federation and short-lived tokens, so a leaked credential expires before it can be weaponised at scale.
- Daily spend alerts routed to security. Budget and anomaly alerts should land with SecOps, not only FinOps, with hour-level thresholds on AI and GPU services rather than monthly budget reviews.
- Endpoint least privilege plus quotas. Scope permissions to what each workload genuinely needs, and cap GPU/accelerator provisioning so a compromised identity cannot mint unlimited capacity.
- Usage baselining and provisioning-event review. Establish normal patterns per team and region, and review who provisions what — deviations in accelerator launches are a leading indicator, not an afterthought.
Segmenting the AI plane from general production workloads adds another layer of containment.
For Hong Kong IT and AI teams in particular, the message is practical: GPU hours are expensive enough that unauthorised consumption registers as a real financial event within hours, which makes spend telemetry one of the most under-used detection signals available.
Compute has quietly become a security asset as much as a line item. When the bill itself is the alarm, the finance dashboard deserves a seat in the SOC.
Source: BleepingComputer, reporting findings from Google.
```
據 BleepingComputer 報道，竊取雲端憑據的攻擊者正悄然將 AI 推理帳單轉嫁至他人帳戶，而且開支正急劇上升：Google 表示，其追蹤的 LLMjacking 攻擊行動已產生約 100 萬美元的累積詐騙雲端 AI 費用，部分受害機構更在單日內耗費超過 10 萬美元。
這個 100 萬美元的數字僅反映單一供應商在其自身平台上觀測到的情況——只是下限而非上限，而單日開支的急升亦顯示，整個行業的真實成本應遠高於此。
LLMjacking 究竟是什麼
LLMjacking 是以 AI 為載體的憑據盜竊行為。入侵者透過釣魚攻擊、公開 repository 中洩露的 secrets、暴露的管理主控台或先前已被入侵的負載，取得雲端 API keys 或 tokens，然後將其指向託管的大型語言模型及 GPU 加速服務。合法帳戶持有人負責支付運算費用；攻擊者則獲得匿名、可擴展的模型存取權，無需自行建構或計費。
在結構上，它與十年前主導雲端濫用的 cryptojacking（加密貨幣挖礦劫持）如出一轍。然而兩者在三個關鍵方面存在差異：
單位成本。 普通挖礦機每小時僅花費數美仙。GPU 加速實例每小時的費用則高出數個數量級，因此一個規模不大、無人監管的使用足跡，在有人打開主控台之前，就可能變成五位數字的帳單。
持續性開支。 模型 endpoints 和推理服務在閒置時仍保持運行。與會完成的 batch job 不同，被遺忘的 deployment 會持續累積費用，且沒有用戶活動可供觸發警報。
隱蔽的合法外觀。 相關流量看起來與一般 API 使用無異，不會觸發 SecOps 團隊通常監控的惡意軟件檢測、process 異常或 egress 模式，因此能一直避人耳目，直至財務部門追問為何帳單驟增三倍才被發現。
偵測機制何以失效
失效的環節通常是組織層面，而非技術層面。開支異常由負責追蹤預算的採購與財務部門察覺；而哪個 identity 開通了哪個加速器的 telemetry 則掌握在安全運營團隊手中。每支團隊都只看到一半的訊號。若缺乏將兩者整合的小時級警報，攻擊可能持續數日，雙方才會有所反應。
據 BleepingComputer 報道，Google 此次披露的時機，正值 AI 運算同時成為戰略資產與攻擊面之際——這一雙重特性改變了雲端團隊應如何優先處理保安衞生（hygiene）問題。
五項值得立即實施的管控措施
以下緩解措施並無新意；大部分只是至今部署仍然不足的保安衞生基本功：
- 憑據衞生及暴露掃描。 將 secrets 視為高價值資產：代碼、config files、CI pipelines 或公開 repository 中不得存在長期有效的 keys，並持續掃描以偵測意外暴露。
- 短暫有效憑據及 workload identity。 以 workload identity federation 及短暫有效的 tokens 取代靜態存取 keys，使洩露的憑據在被大規模武器化之前已告失效。
- 將每日開支警報導向保安團隊。 預算及異常警報應同時送達 SecOps，而非僅由 FinOps 接收，並對 AI 及 GPU 服務設定小時級閾值，而非僅作每月預算覆核。
- Endpoint 最低權限配合配額限制。 將權限範圍限制至各負載真正所需的程度，並對 GPU／加速器開通設定上限，令被入侵的 identity 無法無限製造運算容量。
- 用量基線化及開通事件覆核。 為各團隊及地區建立正常模式，並覆核由誰開通了什麼——加速器啟動的偏離情況是領先指標，不應事後才作考慮。
將 AI 平面與一般 production 負載分隔，可為遏制措施增加另一層保障。
對香港 IT 及 AI 團隊而言，尤其這番信息相當實際：GPU 時數成本高昂，未經授權的消耗數小時內便會反映為真實的財務事件，這使開支 telemetry 成為現有最未受充分利用的偵測訊號之一。
運算資源已悄然成為保安資產，與財務帳目上的開支行項目同等重要。當帳單本身就是警報時，財務儀表板理應在 SOC 中佔一席之地。
資料來源：BleepingComputer，報導 Google 公布的調查結果。