CVE-2026-59310: Apa yang Diungkap Kampanye Serangan VMware vCenter?

CVE-2026-59310 bukan lagi sekadar celah yang harus segera ditambal. Broadcom mengungkap dan memperbaiki kerentanan kritis pada Syslog Server VMware vCenter pada 29 Juli 2026. Namun, peneliti mengamati tanda-tanda eksploitasi aktif mulai 3 Agustus—hanya lima hari kemudian.

Kampanye tersebut dikaitkan dengan 361 alamat IP terpantau di 47 negara. Para penyerang juga menggunakan reverse SSH untuk mempertahankan akses. Karena itu, Shadowserver menilai sistem yang menunjukkan mekanisme tersebut harus dianggap telah sepenuhnya disusupi.

Apa yang memungkinkan CVE-2026-59310?

Broadcom dan National Vulnerability Database (NVD) menjelaskan CVE-2026-59310 sebagai kerentanan directory traversal pada Syslog Server vCenter. Penyerang yang memiliki akses jaringan ke vCenter tidak memerlukan autentikasi untuk mengeksploitasi celah ini dan menjalankan kode arbitrer pada sistem yang terdampak. Skor CVSS-nya mencapai 9,8, yang menempatkannya dalam kategori kritis.

Secara praktis, celah ini dapat mengubah appliance vCenter yang terekspos menjadi pintu masuk untuk mempertahankan akses dan bergerak lebih jauh di lingkungan virtualisasi. Sejumlah laporan kampanye menyebut eksekusi kode pada konteks root appliance, meski uraian paling otoritatif dari vendor dan basis data kerentanan menegaskan risiko eksekusi kode arbitrer secara umum, bukan seluruh detail hak akses pada setiap intrusi.

Broadcom menyediakan rilis yang telah diperbaiki, tetapi tidak menawarkan workaround. Untuk sistem rentan, pembaruan yang tercantum dalam rekomendasi vendor merupakan langkah remediasi resmi.

Kronologi: patch tersedia, serangan menyusul lima hari kemudian

Broadcom mengungkap CVE-2026-59310 sekaligus merilis patch pada 29 Juli. QUIRSO kemudian melaporkan indikasi eksploitasi aktif mulai 3 Agustus, sebelum kampanye berkembang dengan cepat.

Urutan waktu ini penting bagi respons insiden. vCenter yang baru ditambal setelah 3 Agustus tidak otomatis bisa dianggap bersih hanya karena proses pembaruan berhasil. Administrator perlu memisahkan dua hal: memperbaiki kerentanan dan memeriksa apakah penyerang sudah lebih dulu memperoleh akses.

Seberapa luas kampanyenya?

Peneliti mengaitkan aktivitas ini dengan 361 alamat IP korban yang terpantau di 47 negara. Jerman, Amerika Serikat, Turki, Iran, dan Prancis dilaporkan mencakup lebih dari separuh kumpulan yang diamati.

Angka tersebut perlu dibaca secara hati-hati. Satu alamat IP tidak selalu mewakili satu organisasi, sehingga “361 korban” bukan bukti bahwa 361 perusahaan atau institusi berbeda telah disusupi. Meski demikian, laporan yang tersedia menunjukkan adanya kampanye luas terhadap sistem vCenter yang dapat diakses dari internet atau terekspos di jaringan.

Mengapa peneliti menduga ada keterkaitan dengan China?

QUIRSO menilai keterkaitan kampanye dengan China dengan tingkat keyakinan moderat. Indikator yang dilaporkan meliputi artefak berbahasa Mandarin, perangkat dan riset yang digunakan ulang secara publik, aktivitas yang selaras dengan jam kerja UTC+08:00, serta pola korban yang tampaknya tidak mencakup China daratan.

Petunjuk tersebut mendukung penilaian berbasis wilayah atau bahasa, tetapi tidak mengidentifikasi kelompok negara China tertentu dan tidak membuktikan bahwa operasi ini diarahkan pemerintah. Atribusi berdasarkan artefak malware, pola waktu, dan pemilihan target dapat berubah ketika bukti baru tersedia. Deskripsi yang paling tepat saat ini adalah “aktor yang diduga memiliki keterkaitan dengan China”, bukan operasi yang telah terbukti disponsori negara.

Rantai serangan yang dilaporkan

Kampanye ini diduga menggunakan CVE-2026-59310 untuk eksekusi awal, lalu memasang beberapa lapisan persistensi dan akses:

1. Directory traversal: Permintaan yang dibuat khusus ke layanan Syslog digunakan untuk keluar dari jalur yang seharusnya dan menulis konten yang dikendalikan penyerang.
2. Persistensi melalui cron: Penyerang dilaporkan membuat entri cron yang tidak lazim agar tugas terjadwal dapat menjalankan perintah lanjutan.
3. Pengiriman backdoor: curl atau wget digunakan untuk mengambil backdoor linuxFile yang memakai WebSocket dan obfuscation XOR, menurut laporan atas intrusi yang diamati.
4. Reverse SSH: Perangkat reverse SSH dipasang untuk membuat akses keluar menuju infrastruktur yang dikendalikan penyerang. Shadowserver melaporkan mekanisme persistensi ini muncul pada seluruh korban dalam laporan khususnya.
5. Penyalahgunaan akun dan kredensial: Penyelidik melaporkan adanya akun administrator vCenter dan ESXi yang dibuat tanpa izin, serta penyalahgunaan kredensial VMware Directory Service.
6. Penyebaran ransomware: Setidaknya beberapa laporan mengaitkan aktivitas ini dengan varian ransomware turunan Babuk yang menambahkan ekstensi .babyk.

Temuan mengenai reverse SSH sangat penting. Shadowserver menyimpulkan bahwa sistem yang telah dipasangi mekanisme ini harus diperlakukan sebagai sistem yang sepenuhnya disusupi. Menghapus satu binary atau cron job tanpa membangun ulang kepercayaan terhadap appliance dan mengganti kredensial istimewa bukanlah strategi pemulihan yang memadai.

Ransomware mungkin digunakan untuk mengaburkan jejak

Aktivitas .babyk yang dilaporkan belum tentu merupakan kampanye ransomware konvensional yang tujuan utamanya mengenkripsi sebanyak mungkin data untuk pemerasan. Analis menduga enkripsi selektif terhadap log ESXi mungkin dimaksudkan untuk mengganggu penyelidikan dan menyembunyikan bukti.

Penjelasan tersebut masih berupa inferensi, bukan pernyataan resmi mengenai niat penyerang. Meski begitu, tim pertahanan perlu menyelidiki dua kemungkinan sekaligus: dampak ransomware terhadap mesin virtual dan manipulasi log yang sengaja dilakukan untuk mengaburkan intrusi.

Repositori GitHub dan penggunaan ulang alat

Laporan lain mengaitkan operasi ini dengan sebuah repositori GitHub yang menyamarkan binary reverse SSH sebagai utilitas Linux untuk membersihkan berkas sementara. Menyamar sebagai alat administrasi atau pembersihan dapat membuat perangkat persistensi lebih mudah didistribusikan dan tidak terlalu mencolok dalam pemeriksaan rutin.

Namun, bukti yang tersedia belum secara independen membuktikan siapa pengelola repositori tersebut. Keberadaan repositori itu tidak boleh dianggap sebagai bukti atribusi.

Dampaknya bagi Broadcom

Saham Broadcom turun sekitar 5% hingga 6% pada 14 Agustus ketika laporan eksploitasi VMware vCenter aktif mulai memengaruhi investor. Salah satu laporan mencatat pergerakan harga dari 417,82 dolar AS menjadi 392,99 dolar AS dalam satu sesi.

Laporan keamanan menjadi salah satu faktor penurunan tersebut, tetapi bukan berarti satu-satunya. Pemberitaan pada periode yang sama juga menyoroti kekhawatiran lain, termasuk eksposur utang terkait AI. Karena itu, tidak aman untuk mengaitkan seluruh penurunan harga saham atau jumlah pasti kapitalisasi pasar yang hilang hanya dengan CVE-2026-59310.

Belum ada bukti yang cukup dari laporan yang tersedia untuk menyimpulkan bahwa kampanye ini telah menyebabkan penurunan pendapatan VMware yang terukur. Dampak bisnis jangka pendek yang lebih dapat didukung bukti adalah biaya remediasi pelanggan, risiko gangguan operasional, dan tekanan reputasi. Dampak terhadap pendapatan dalam jangka panjang membutuhkan pengungkapan perusahaan atau bukti finansial tambahan.

Langkah yang perlu dilakukan administrator vCenter

Menambal adalah langkah pertama, bukan langkah terakhir. Organisasi sebaiknya:

1. Segera menerapkan rilis perbaikan Broadcom pada setiap instance vCenter yang terdampak, dengan prioritas pada appliance yang menghadap internet atau dapat dijangkau dari jaringan internal yang luas. Broadcom tidak mencantumkan workaround.
2. Menganggap sistem telah disusupi jika menemukan indikator, termasuk perubahan cron yang tidak dikenal, artefak reverse SSH, linuxFile, unduhan curl atau wget yang tidak biasa, akun administrator vCenter atau ESXi yang asing, serta aktivitas VMware Directory Service yang anomali.
3. Mengisolasi appliance mencurigakan dan, bila memungkinkan secara operasional, mengamankan image disk, log, serta bukti volatile sebelum melakukan pembangunan ulang.
4. Mengganti seluruh kredensial istimewa, termasuk vCenter SSO, VMware Directory Service, ESXi atau root, API, akun layanan, dan kredensial administrator yang terhubung. Batalkan sesi aktif dan tinjau jalur federasi.
5. Membangun ulang sistem yang terbukti memiliki persistensi, bukan sekadar membersihkannya. Penghapusan akun ilegal, cron job, binary, kunci SSH, dan tunnel harus menjadi bagian dari proses respons insiden yang terdokumentasi.
6. Melakukan threat hunting di seluruh infrastruktur virtualisasi untuk mencari aktivitas .babyk, koneksi SSH atau WebSocket keluar yang tidak biasa, akun ilegal, dan tanda-tanda manipulasi log ESXi.
7. Memulihkan data dan telemetri tepercaya dari cadangan yang diketahui baik dan bersifat immutable jika log atau konfigurasi telah diubah.
8. Mengurangi paparan di masa depan dengan membatasi akses administrasi vCenter ke jaringan pengelolaan yang tersegmentasi serta memantau koneksi keluar dari vCenter dan host ESXi.

Inti operasionalnya sederhana: perbarui setiap sistem vCenter yang rentan, tetapi jangan menyamakan patch yang berhasil dengan lingkungan yang sudah bersih. Eksploitasi yang berlangsung cepat, persistensi reverse SSH, dan dugaan penyalahgunaan kredensial membuat setiap appliance yang terekspos perlu diselidiki sebagai kemungkinan kompromi penuh.