TeamPCP Serang LiteLLM Versi 1.82.7–1.82.8 Lewat Kompromi Trivy CI/CD, Ada Backdoor Berbahaya

TeamPCP, kelompok ancaman yang sebelumnya telah melakukan kompromi pada Trivy dan KICS, kembali melakukan serangan serius dengan menyusup ke paket Python populer bernama LiteLLM versi 1.82.7 dan 1.82.8. Dua versi berbahaya ini memuat credential harvester (alat pencuri kredensial), toolkit pergerakan lateral Kubernetes, dan backdoor persisten yang memungkinkan pengendalian luas terhadap lingkungan Kubernetes.

Menurut laporan dari beberapa vendor keamanan ternama seperti Endor Labs dan JFrog, kedua versi LiteLLM berbahaya ini dirilis pada tanggal 24 Maret 2026, kemungkinan besar akibat penggunaan Trivy dalam alur kerja CI/CD paket tersebut. Versi yang terinfeksi tersebut telah dihapus dari repositori PyPI sebagai langkah mitigasi.

Modus Operandi Serangan TeamPCP pada LiteLLM

Endor Labs menjelaskan bahwa payload berbahaya ini bekerja dalam tiga tahap utama:

• Pencurian kredensial: Pengumpulan berbagai data sensitif seperti kunci SSH, kredensial cloud, rahasia Kubernetes, dompet kripto, serta file .env.
• Toolkit pergerakan lateral Kubernetes: Menggunakan token akun layanan Kubernetes untuk mendeteksi semua node dalam klaster dan memasang pod berhak istimewa ke setiap node.
• Backdoor persisten systemd: Layanan bernama sysmon.service yang secara berkala melakukan polling ke domain jahat "checkmarx[.]zone/raw" untuk mengunduh payload lanjutan.

Payload yang dicuri dienkripsi dan dikirim ke domain models.litellm[.]cloud melalui permintaan HTTPS bertipe POST dengan nama file arsip "tpcp.tar.gz". Ini menunjukkan tingkat pengamanan dan kompleksitas serangan yang cukup tinggi.

Teknik Penyusupan dan Penyebaran

Dalam versi 1.82.7, kode berbahaya disisipkan pada file litellm/proxy/proxy_server.py selama atau setelah proses pembuatan wheel paket. Kode ini aktif saat modul litellm.proxy.proxy_server diimpor, sehingga setiap proses yang menggunakan modul tersebut tanpa sengaja menjalankan payload berbahaya.

Sementara itu, versi 1.82.8 meningkatkan serangan dengan menambahkan file litellm_init.pth di root wheel. File .pth ini dijalankan otomatis saat interpreter Python mulai, sehingga payload aktif di setiap proses Python dalam lingkungan tersebut tanpa perlu mengimpor modul LiteLLM secara eksplisit.

Lebih berbahaya lagi, file .pth ini memicu proses Python anak secara terpisah menggunakan subprocess.Popen, yang memungkinkan payload berjalan di latar belakang tanpa terlihat.

"File .pth Python yang ditempatkan di site-packages otomatis diproses oleh site.py saat interpreter mulai. File ini berisi satu baris kode yang mengimpor subprocess dan menjalankan proses Python terpisah untuk mendekode dan menjalankan payload Base64 yang sama," jelas Endor Labs.

Implikasi untuk Infrastruktur Kubernetes dan Supply Chain

Payload ini tidak hanya mencuri data tapi juga membentuk kontrol permanen dengan cara:

1. Menggunakan token akun layanan Kubernetes untuk menyebar ke semua node dalam klaster.
2. Memasang pod berhak istimewa yang melakukan chroot ke sistem file host.
3. Memasang layanan systemd sebagai backdoor yang menjalankan skrip Python bernama sysmon.py setiap 50 menit untuk memeriksa dan mengunduh payload terbaru.

Menariknya, skrip ini memiliki kill switch yang menghentikan eksekusi jika URL payload berisi "youtube[.]com", pola yang sama dengan insiden kompromi sebelumnya.

Menurut Endor Labs, kampanye TeamPCP ini kemungkinan besar masih berlanjut. Mereka memanfaatkan kredensial yang dicuri untuk membuka target berikutnya, mengeskalasi serangan dari lingkungan CI/CD seperti GitHub Actions ke produksi melalui paket di PyPI yang berjalan di klaster Kubernetes.

Serangan ini merupakan bagian dari kampanye rantai pasokan yang luas mencakup lima ekosistem besar: GitHub Actions, Docker Hub, npm, Open VSX, dan PyPI. Dengan cara ini, TeamPCP memperluas jangkauan serangannya ke berbagai sistem dan proyek open source.

Tanggapan dan Saran Mitigasi

Kelompok keamanan Socket menegaskan bahwa TeamPCP sedang menjalankan operasi berkelanjutan dengan target utama infrastruktur pengembang open source dan alat keamanan, yang memiliki efek besar terhadap rantai pasokan perangkat lunak global.

Dalam sebuah pesan di kanal Telegram mereka, TeamPCP dengan congkak mengklaim bahwa perusahaan keamanan tidak mampu melindungi rantai pasokan mereka sendiri, dan mereka berencana melanjutkan pencurian data dalam skala besar.

Pengguna dan organisasi yang menggunakan LiteLLM disarankan melakukan langkah-langkah berikut untuk mengurangi risiko:

• Audit dan identifikasi semua versi LiteLLM 1.82.7 dan 1.82.8, lalu rollback ke versi bersih.
• Isolasi host yang terindikasi terinfeksi.
• Periksa keberadaan pod mencurigakan di klaster Kubernetes.
• Analisis log jaringan untuk trafik keluar ke domain models.litellm[.]cloud dan checkmarx[.]zone.
• Hapus mekanisme persistence yang terpasang.
• Audit pipeline CI/CD yang menggunakan Trivy dan KICS selama periode kompromi.
• Cabut dan ganti semua kredensial yang mungkin terekspos.

"Rantai pasokan open source kini seperti runtuh sendiri," kata Gal Nagli, kepala ancaman di Wiz (milik Google). "Trivy dikompromikan → LiteLLM dikompromikan → kredensial puluhan ribu lingkungan jatuh ke penyerang → kredensial itu memicu kompromi berikutnya. Kita terjebak dalam lingkaran setan."

Analisis Redaksi

Menurut pandangan redaksi, serangan TeamPCP ini menandai eskalasi serius dalam perang siber terhadap rantai pasokan perangkat lunak open source. Dengan teknik multi-tahap yang menggabungkan pencurian kredensial, penyebaran lateral ke seluruh klaster Kubernetes, dan backdoor persisten, ancaman ini tidak hanya berpotensi menyebabkan kebocoran data besar-besaran tapi juga pengambilalihan penuh lingkungan produksi yang krusial.

Yang perlu diwaspadai adalah pola kompromi yang menggunakan satu titik lemahnya CI/CD (seperti Trivy) untuk menyusup ke paket yang digunakan jutaan pengembang dan sistem produksi. Ini menimbulkan risiko snowball effect yang sulit dihentikan jika tidak ada tindakan nyata dan koordinasi lintas ekosistem.

Ke depan, organisasi harus memperketat pengawasan terhadap rantai pasokan perangkat lunak, menerapkan segmentasi lingkungan yang ketat, dan terus mengawasi aktivitas anomali di Kubernetes serta pipeline CI/CD mereka. Pengguna juga harus siap menghadapi serangan lanjutan yang semakin canggih dan terorganisir.

Dengan berbagai ekosistem yang sudah terinfeksi, penting juga untuk mengikuti perkembangan dan advis keamanan terbaru dari vendor terpercaya guna mengantisipasi serangan berikutnya.