LLMjacking: API Key AI Dicuri, Tagihan Cloud Korban Tembus $1 Juta
Oleh Tim APIPedia, Tim Engineering APIPedia · Terbit · 9 menit baca
Google dan Mandiant ungkap LLMjacking: API key AI dicuri lalu dijual murah lewat LLM Mixer, korban ditagih hingga $1 juta. Ini cara kerja dan cara ceknya.

LLMjacking adalah pembajakan akses model AI (LLM) milik perusahaan memakai kredensial curian, lalu aksesnya dijual ulang ke pihak lain sementara korban yang menanggung tagihannya. Laporan Google Threat Intelligence Group (GTIG) dan Mandiant pada 2 November 2026 mencatat tagihan palsu lebih dari $100.000 dalam sehari, dan ada korban yang tagihannya mencapai $1 juta.
Laporan ini langsung ramai dibahas di media keamanan dan komunitas developer sejak 3 November. Alasannya sederhana: hampir semua tim sekarang menyimpan API key AI di suatu tempat, entah di file .env, di CI, atau di gateway seperti LiteLLM. Artikel ini membahas apa yang terjadi, cara kerjanya, mitos yang beredar, dan langkah cek yang bisa Anda jalankan hari ini.
Apa yang sebenarnya dilaporkan Google dan Mandiant?
Sepanjang 2026, Mandiant menangani beberapa insiden LLMjacking di sektor jasa keuangan, ritel, teknologi, dan transportasi di Amerika Utara, Amerika Selatan, dan Asia Pasifik. Temuan utamanya: pelaku tidak bekerja sendirian. Ada pembagian kerja yang rapi.
- Pencari akses awal mencuri kredensial cloud atau API key LLM, atau mencari endpoint model yang terbuka ke internet.
- Operator "LLM Mixer" menampung kunci-kunci curian itu di balik gateway, mengatur kuotanya, menyamarkan asal request, lalu menjual akses murah ke pelanggan di pasar gelap.
Bedanya dengan cryptojacking, yang menguras sumber daya pelan-pelan, LLMjacking bisa membuat tagihan melonjak dalam hitungan jam. BleepingComputer melaporkan volume request bisa melonjak hingga lebih dari 1.000 request per detik. Karena request itu memakai kunci yang sah, penyedia cloud mencatatnya sebagai pemakaian normal dan menagihkannya ke korban.
Bagaimana LLMjacking bekerja, langkah demi langkah?

1. Mencuri kredensial
Menurut GTIG, jalur masuk yang paling dominan adalah identitas cloud yang bocor atau dicuri: kredensial IAM, service account key, GitHub Personal Access Token, dan token sesi aktif. Ada juga pelaku yang memanen API key LLM dari repositori GitHub publik, dan pelaku yang memanggil endpoint /api/create pada server Ollama yang terbuka untuk mendaftarkan model miliknya sendiri.
Kelompok UNC6993 bahkan membuat halaman palsu yang menyamar sebagai portal aplikasi. Korban diminta menempelkan payload JSON berisi access token aktif, sehingga pelaku bisa melewati kata sandi dan MFA.
2. Menguji kunci tanpa ketahuan
Sebelum dijual, kunci divalidasi dengan request sangat kecil, misalnya max_tokens=1. Pemakaiannya nyaris nol, jadi tidak memicu alarm volume di SIEM atau EDR.
3. Mengaktifkan layanan AI dan bertahan
Di beberapa insiden, layanan AI korban bahkan belum aktif. Pelaku memakai kunci curian untuk mengaktifkan Bedrock atau Gemini API, membuat API key baru, mendaftar paket Pay-As-You-Go, dan memilih model premium. Agar bertahan, mereka membuat akun IAM baru, menyuntikkan SSH key ke metadata VM, dan dalam satu kasus membuat service account yang menyamar sebagai "internal billing optimization utility". Ada juga pelaku yang menyalakan instance GPU di beberapa region dan meminta kenaikan kuota.
4. Menjual lewat LLM Mixer
GTIG menyebut UNC6993 memakai alat open source new-api dan gcli2api untuk menggabungkan kunci curian dan membagi beban request. Contoh paling mencolok adalah Jet Night (jet-night.com): satu pelaku yang memasok kunci curian ke layanan ini membuat lebih dari 500.000 panggilan API LLM dalam waktu kurang dari delapan jam, dan biaya token yang dibebankan ke korban hampir $1 juta. Jet Night menawarkan paket "unlimited" sekitar $60 per bulan, padahal langganan resmi yang sebanding berkisar $100 sampai $250 per bulan. Layanan ini juga beberapa kali mengumumkan gangguan di Telegram, yang menurut GTIG kemungkinan terjadi karena korban mencabut kuncinya.
5. Menyerang gateway LLM
Bagian ini paling relevan bagi tim yang memasang gateway sendiri. Satu kelompok lanjutan menerima Virtual Key LiteLLM yang sudah divalidasi, lalu mengeksploitasi CVE-2026-40217 untuk menaikkan kunci biasa menjadi kredensial master PROXY_ADMIN. Siapa pun yang menguasai lapisan routing bisa melihat dan memakai semua kunci di belakangnya.
Apa itu CVE-2026-40217, dan kenapa deskripsinya berbeda-beda?
Ada perbedaan antarsumber yang perlu Anda ketahui. Laporan GTIG menggambarkan CVE-2026-40217 sebagai kerentanan user ID rebind di endpoint /key/regenerate LiteLLM. Sementara itu, deskripsi CVE di database publik (cvefeed/NVD dan Red Hat Bugzilla) menyebut eksekusi kode jarak jauh lewat bytecode rewriting di endpoint /guardrails/test_custom_code, berlaku untuk LiteLLM "sampai 2026-04-08", dengan skor CVSS 3.1 sebesar 8.8 (High). BleepingComputer mengikuti deskripsi yang kedua.
Kedua sumber tidak menyebut nomor versi perbaikan yang spesifik. Sikap yang aman: perbarui LiteLLM ke rilis terbaru, dan batasi akses ke kedua endpoint tersebut dari internet.
Ringkasan angka dan fakta kunci
| Aspek | Fakta | Sumber |
|---|---|---|
| Tanggal laporan | 2 November 2026 | GTIG & Mandiant |
| Tagihan puncak | Lebih dari $100.000 dalam satu hari | GTIG |
| Tagihan kumulatif | Hingga $1 juta sebelum akses dicabut | GTIG |
| Kasus Jet Night | 500.000+ panggilan API dalam < 8 jam, biaya hampir $1 juta | GTIG |
| Harga paket gelap | ±$60/bulan, vs $100–$250 untuk langganan resmi | GTIG |
| Lonjakan request | Bisa lebih dari 1.000 request/detik | BleepingComputer |
| Gateway yang dieksploitasi | LiteLLM, CVE-2026-40217 (CVSS 8.8) | GTIG, cvefeed |
| Layanan yang disebut | AWS Bedrock, Gemini API, Gemini Enterprise Agent Platform, Azure Cognitive Services, Ollama | GTIG |
Mitos vs fakta
- Mitos: "Kami tidak pakai AI di cloud, jadi aman." Fakta: di beberapa insiden, layanan AI memang belum aktif. Pelaku sendiri yang mengaktifkannya dengan kredensial curian.
- Mitos: "Kalau ada pencurian, pasti kelihatan dari lonjakan pemakaian." Fakta: tahap uji memakai request
max_tokens=1yang nyaris tak terlihat. Lonjakan baru muncul setelah kunci dijual, dan saat itu tagihan sudah berjalan. - Mitos: "Korban membayar $100.000 setiap hari." Fakta: angka itu adalah puncak tertinggi yang dicatat dalam satu hari, bukan biaya rata-rata harian. Beberapa judul berita membuatnya terdengar lebih rutin.
- Mitos: "Cukup ganti kata sandi." Fakta: API key, service account key, dan token sesi tetap berlaku sampai dicabut atau dirotasi. Ganti kata sandi saja tidak menghentikan pemakaian kunci yang sudah bocor.
Bagaimana cara mengecek apakah Anda kena?
GTIG menegaskan bahwa layanan LLM yang tiba-tiba aktif tanpa izin harus diperlakukan sebagai insiden keamanan kritis. Berikut event log yang mereka sarankan untuk dipantau.

Cek AWS: siapa yang membuka akses model atau mematikan log Bedrock?
Perintah berikut membaca event manajemen CloudTrail (riwayat 90 hari) di region aktif. Ulangi untuk setiap region yang Anda pakai.
# Event yang membuka akses model atau mematikan logging Bedrock
for ev in PutUseCaseForModelAccess CreateFoundationModelAgreement \
DeleteModelInvocationLoggingConfiguration PutModelInvocationLoggingConfiguration; do
echo "== $ev"
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=$ev \
--max-results 20 \
--query 'Events[].[EventTime,Username,EventName]' --output table
done
# Siapa saja yang membuat access key baru
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \
--max-results 20 --query 'Events[].[EventTime,Username]' --output table
Cek Google Cloud: layanan apa yang baru diaktifkan?
# Daftar aktivasi layanan 7 hari terakhir, cari aiplatform/generativelanguage
gcloud logging read \
'protoPayload.methodName="google.api.serviceusage.v1.ServiceUsage.EnableService"' \
--freshness=7d --limit=50 \
--format='table(timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.resourceName)'
# Layanan AI yang sedang aktif di project ini
gcloud services list --enabled | grep -Ei 'aiplatform|generativelanguage'
Catatan: event pemakaian model seperti GenerateContent di Google Cloud hanya tercatat kalau Data Access logs diaktifkan, dan secara default fitur itu nonaktif.
Cek gateway LiteLLM dan kebocoran kunci di repo
# Versi LiteLLM yang terpasang (jalankan di host/container gateway)
pip show litellm | grep -i ^version
# Pindai seluruh riwayat git untuk API key yang pernah ter-commit
gitleaks git -v . # gitleaks v8.19+; versi lama: gitleaks detect -v
Sambil menunggu pembaruan, tutup endpoint berisiko dari akses publik di reverse proxy, misalnya Nginx:
# Endpoint yang disebut dalam CVE-2026-40217: hanya untuk jaringan internal
location ~ ^/(guardrails/test_custom_code|key/regenerate) {
allow 10.0.0.0/8;
deny all;
proxy_pass http://litellm_upstream;
}
Apa artinya bagi developer dan bisnis di Indonesia?
Tagihan cloud dihitung dalam dolar. Dengan kurs sekitar belasan ribu rupiah per dolar, tagihan $100.000 dalam sehari sudah setara miliaran rupiah, jauh melampaui anggaran AI tahunan kebanyakan startup dan UMKM digital. Itu sebabnya batas pengeluaran bukan formalitas.
Langkah prioritas yang dirangkum dari rekomendasi GTIG:
- Simpan kunci di secrets manager dan rotasi otomatis. Jangan pernah commit
.env. - Least privilege: tolak semua izin yang tidak dibutuhkan, termasuk akses ke layanan LLM cloud.
- Pisahkan kunci per model dan lingkungan (dev/prod), supaya kunci untuk model murah tidak bisa memanggil model frontier.
- Pasang budget dan kuota per model, lengkap dengan alert.
- Pindai secret otomatis di GitHub/GitLab, lalu cabut kunci yang bocor secepatnya.
- Masukkan LiteLLM dan proxy sejenis ke jadwal patch, prioritaskan CVE-2026-40217.
- Pakai MFA tahan phishing di konsol cloud dan platform developer.
Tren ini juga sejalan dengan insiden yang menyasar alat developer AI belakangan ini, misalnya ekstensi Claude Code palsu yang menanam backdoor SSH dan plugin Postman yang terpasang diam-diam di Claude Code dan Codex. Kredensial di mesin developer kini menjadi target bernilai tinggi.
Kalau Anda memakai API pihak ketiga, termasuk di console APIPedia, prinsipnya sama: buat kunci terpisah per aplikasi, pantau log pemakaian, dan cabut kunci yang tidak lagi dipakai.
FAQ
Apa beda LLMjacking dengan cryptojacking?
Cryptojacking mencuri daya komputasi untuk menambang kripto secara perlahan. LLMjacking mencuri akses model AI berbayar, dan karena harga token model premium tinggi, tagihannya bisa melonjak dalam hitungan jam. GTIG memperkirakan pelaku akan makin memilih LLMjacking karena ada pasar penjualan ulangnya.
Apakah memakai layanan AI murah "unlimited" itu berbahaya?
Layanan yang menjual akses model frontier jauh di bawah harga resmi patut dicurigai. GTIG menilai Jet Night, dengan paket sekitar $60 per bulan, hanya bisa untung kalau memakai kunci curian. Selain melanggar hukum, prompt dan data Anda melewati infrastruktur pelaku kejahatan.
Apa tanda paling awal bahwa kunci saya sudah dicuri?
Perhatikan request sangat kecil seperti max_tokens=1 atau ping dengan temperature nol dari IP asing, layanan AI yang tiba-tiba aktif, access key atau service account baru, dan perubahan konfigurasi logging. Lonjakan biaya biasanya datang belakangan.
Kunci saya terlanjur bocor di GitHub. Cukup hapus commit-nya?
Tidak cukup. Riwayat git dan salinan (fork, cache) bisa tetap menyimpannya. Langkah yang benar adalah cabut atau rotasi kunci di penyedia lebih dulu, periksa log pemakaian, baru bersihkan riwayat repo.
Sumber
- Google Cloud Blog (GTIG & Mandiant): The Rise of LLMJacking, 2 November 2026
- BleepingComputer: Google: LLMjacking attacks rack up $1 million in cloud AI charges
- Help Net Security: Stolen AI access leaves companies with cloud bills of up to $1 million
- CSO Online: Enterprises pay $100,000 a day for AI they never ordered
- cvefeed.io: CVE-2026-40217 (LiteLLM)
- Red Hat Bugzilla: Bug 2457301 (CVE-2026-40217)
Topik: #keamanan #llmjacking #api-key #cloud #ai #litellm
Tentang penulis
Tim APIPedia — Tim Engineering APIPedia
Tim engineering di balik APIPedia yang membangun dan memelihara API data Indonesia - ongkir, OCR KTP, data wilayah, BMKG, hingga server MCP - dan menulis panduan integrasinya dari pengalaman langsung.