CVE-2026-59310: Apa yang didedahkan oleh kempen serangan VMware vCenter

CVE-2026-59310 bukan lagi sekadar isu yang perlu ditampal segera. Broadcom mendedahkan dan membaiki kerentanan kritikal dalam Syslog Server VMware vCenter pada 29 Julai 2026, namun penyelidik mengesan eksploitasi aktif seawal 3 Ogos — hanya lima hari kemudian. Kempen itu melibatkan 361 alamat IP yang diperhatikan di 47 negara dan menggunakan reverse SSH untuk mengekalkan akses. Shadowserver menyifatkan sistem yang terjejas sebagai telah dikompromi sepenuhnya.

Apakah yang boleh dilakukan oleh CVE-2026-59310?

Broadcom dan National Vulnerability Database (NVD) menerangkan CVE-2026-59310 sebagai kerentanan directory traversal dalam Syslog Server vCenter. Penyerang yang mempunyai akses rangkaian tidak memerlukan pengesahan untuk mengeksploitasi kelemahan itu dan melaksanakan kod sewenang-wenangnya pada sistem vCenter yang terjejas. Kerentanan ini menerima skor CVSS 9.8, iaitu tahap kritikal.

Secara praktikal, kelemahan ini boleh menjadikan peralatan vCenter yang terdedah sebagai pintu masuk untuk mengekalkan kehadiran penyerang dan mendapatkan akses lebih luas kepada infrastruktur maya. Laporan kempen menyebut pelaksanaan kod dalam konteks root pada peralatan tersebut, namun huraian vendor dan pangkalan data kerentanan yang paling berautoriti menegaskan risiko pelaksanaan kod sewenang-wenangnya tanpa menghuraikan tahap keistimewaan bagi setiap pencerobohan.

Broadcom menyediakan versi yang telah dibaiki tetapi tidak menawarkan penyelesaian sementara. Oleh itu, memasang kemas kini yang disenaraikan vendor ialah langkah pemulihan rasmi untuk sistem yang terdedah.

Garis masa: tampalan tersedia, serangan menyusul lima hari kemudian

Broadcom mendedahkan CVE-2026-59310 dan mengeluarkan tampalan pada 29 Julai. QUIRSO kemudian melaporkan tanda-tanda eksploitasi aktif bermula pada 3 Ogos, sebelum kempen berkembang dengan pantas.

Urutan ini penting untuk tindak balas insiden. Sistem yang ditampal selepas 3 Ogos tidak boleh dianggap bersih hanya kerana proses kemas kini berjaya. Pentadbir perlu membezakan antara membaiki kerentanan dengan menilai sama ada sistem telah diceroboh: tampal kelemahan itu, kemudian siasat kemungkinan penyerang sudah membina laluan masuk.

Skala kempen

Penyelidik mengaitkan aktiviti ini dengan 361 alamat IP mangsa yang diperhatikan di 47 negara. Jerman, Amerika Syarikat, Türkiye, Iran dan Perancis dilaporkan menyumbang lebih separuh daripada jumlah tersebut.

Angka ini perlu ditafsir dengan berhati-hati. Satu alamat IP tidak semestinya mewakili satu organisasi, jadi “361 mangsa” tidak membuktikan terdapat 361 syarikat atau institusi berbeza. Namun, laporan yang tersedia menunjukkan kempen berskala luas terhadap sistem vCenter yang boleh dicapai melalui internet atau terdedah dalam rangkaian.

Mengapa penyelidik mengesyaki kaitan China?

QUIRSO menilai kaitan kempen dengan China pada tahap keyakinan sederhana. Petunjuk yang dilaporkan termasuk artifak berbahasa Cina, penggunaan alat dan penyelidikan awam yang digunakan semula, aktiviti yang selari dengan waktu bekerja UTC+08:00, serta corak mangsa yang kelihatan tidak merangkumi tanah besar China.

Petunjuk ini menyokong penilaian berkaitan wilayah atau bahasa, tetapi tidak mengenal pasti kumpulan negara China tertentu dan tidak membuktikan arahan kerajaan. Atribusi berdasarkan artifak perisian hasad, corak masa dan sasaran boleh berubah apabila bukti baharu diperoleh. Oleh itu, gambaran paling berasas buat masa ini ialah “aktor yang disyaki mempunyai kaitan dengan China”, bukannya operasi tajaan negara yang telah disahkan.

Rantaian pencerobohan yang dilaporkan

Kempen ini dipercayai menggunakan CVE-2026-59310 untuk pelaksanaan awal sebelum memasang beberapa lapisan akses dan mekanisme kekal:

1. Directory traversal: Permintaan yang direka khas kepada perkhidmatan Syslog digunakan untuk keluar daripada laluan yang sepatutnya dan menulis kandungan yang dikawal penyerang.
2. Kekal melalui cron: Penyerang dilaporkan mencipta entri cron yang rosak supaya tugas berjadual boleh melancarkan arahan susulan.
3. Penghantaran backdoor: curl atau wget digunakan untuk mendapatkan backdoor linuxFile yang menggunakan WebSocket dan obfuscation XOR, menurut laporan mengenai pencerobohan yang diperhatikan.
4. Reverse SSH: Alat reverse SSH dipasang bagi mewujudkan akses keluar ke infrastruktur yang dikawal penyerang. Shadowserver melaporkan mekanisme ini ditemui pada semua mangsa dalam laporan khasnya.
5. Penyalahgunaan akaun dan kelayakan: Penyiasat melaporkan kewujudan akaun pentadbir vCenter dan ESXi yang tidak dibenarkan serta penyalahgunaan kelayakan VMware Directory Service.
6. Penyebaran ransomware: Sekurang-kurangnya sebahagian laporan mengaitkan aktiviti ini dengan varian ransomware berasaskan Babuk yang menambah sambungan .babyk.

Penemuan reverse SSH amat penting. Kesimpulan operasi Shadowserver ialah sistem yang dipasang mekanisme ini perlu dianggap telah dikompromi sepenuhnya. Memadam satu binari atau tugas cron tanpa membina semula kepercayaan terhadap peralatan dan menukar semua kelayakan istimewa bukanlah strategi pemulihan yang mencukupi.

Ransomware mungkin digunakan untuk mengaburkan bukti

Aktiviti .babyk yang dilaporkan tidak semestinya menggambarkan kempen ransomware konvensional yang fokus utamanya ialah menyulitkan sejumlah besar data untuk mendapatkan wang tebusan. Penganalisis mencadangkan penyulitan terpilih terhadap log ESXi mungkin bertujuan mengganggu siasatan dan menyembunyikan bukti.

Penjelasan itu masih merupakan kesimpulan berdasarkan analisis, bukan pengesahan niat penyerang. Namun, pasukan pertahanan perlu menyiasat kedua-dua kemungkinan: kesan ransomware terhadap mesin maya dan pengubahsuaian log yang disengajakan untuk mengaburkan pencerobohan.

Repositori GitHub menyamar sebagai alat pembersihan

Laporan turut mengaitkan operasi itu dengan sebuah repositori GitHub yang mempersembahkan binari reverse SSH sebagai utiliti Linux untuk membersihkan fail sementara. Menyamarkan alat untuk mengekalkan akses sebagai program pentadbiran atau pembersihan boleh memudahkan pengedaran dan menjadikannya kurang mencurigakan ketika semakan rutin. Bukti yang tersedia tidak mengesahkan secara bebas siapa yang mengendalikan repositori tersebut, jadi kewujudannya tidak boleh dianggap sebagai bukti atribusi.

Kesan terhadap Broadcom dan VMware

Saham Broadcom susut kira-kira 5% hingga 6% pada 14 Ogos ketika laporan mengenai eksploitasi VMware vCenter aktif sampai kepada pelabur. Satu laporan menyebut harga saham turun daripada AS$417.82 kepada AS$392.99 dalam sesi dagangan berkenaan.

Laporan keselamatan merupakan salah satu faktor kejatuhan itu, tetapi bukan semestinya satu-satunya faktor. Liputan pada waktu yang sama turut menyebut kebimbangan lebih luas, termasuk pendedahan hutang berkaitan kecerdasan buatan. Maka, tidak wajar untuk mengaitkan keseluruhan penurunan harga saham atau jumlah kehilangan nilai pasaran tertentu kepada CVE-2026-59310 sahaja.

Bukti yang tersedia juga belum mencukupi untuk menyimpulkan bahawa kempen ini telah menyebabkan penurunan hasil VMware yang boleh diukur. Kesan perniagaan jangka pendek yang lebih munasabah ialah kos pemulihan pelanggan, risiko gangguan operasi dan tekanan terhadap reputasi. Kesan terhadap hasil dalam jangka panjang memerlukan pendedahan syarikat atau bukti kewangan tambahan.

Apa yang perlu dilakukan oleh pentadbir vCenter?

Menampal sistem ialah langkah pertama, bukan penamat. Organisasi disarankan untuk:

1. Pasang versi pembaikan Broadcom dengan segera pada setiap peralatan vCenter yang terjejas, khususnya sistem yang menghadap internet atau boleh dicapai daripada rangkaian dalaman yang luas. Broadcom tidak menyenaraikan sebarang penyelesaian sementara.
2. Anggap sistem telah dikompromi jika terdapat petunjuk, termasuk perubahan cron yang tidak dijangka, artifak reverse SSH, linuxFile, muat turun curl atau wget yang tidak dapat dijelaskan, akaun pentadbir vCenter atau ESXi yang tidak dikenali dan aktiviti VMware Directory Service yang luar biasa.
3. Asingkan peralatan yang mencurigakan dan, jika keadaan operasi mengizinkan, simpan imej cakera, log serta bukti volatile sebelum proses bina semula.
4. Tukar semua kelayakan berkeistimewaan, termasuk vCenter SSO, VMware Directory Service, ESXi atau root, API, akaun perkhidmatan dan akaun pentadbiran yang berkaitan. Batalkan sesi aktif dan semak laluan federasi.
5. Bina semula sistem yang mempunyai mekanisme kekal yang disahkan, bukannya sekadar “membersihkannya”. Padam akaun, tugas cron, binari, kunci SSH dan terowong yang tidak dibenarkan sebagai sebahagian daripada proses tindak balas insiden yang didokumenkan.
6. Lakukan pemburuan ancaman di seluruh infrastruktur maya untuk mengesan aktiviti .babyk, sambungan SSH atau WebSocket keluar yang tidak dijangka, akaun penyangak dan tanda-tanda log ESXi telah diubah.
7. Pulihkan data dan telemetri yang dipercayai daripada sandaran tidak boleh ubah yang diketahui bersih apabila log atau konfigurasi telah diubah.
8. Kurangkan pendedahan pada masa depan dengan mengehadkan akses pengurusan vCenter kepada rangkaian pentadbiran yang diasingkan serta memantau sambungan keluar daripada vCenter dan hos ESXi.

Kesimpulan operasinya mudah: kemas kini semua sistem vCenter yang terdedah, tetapi jangan samakan tampalan yang berjaya dengan persekitaran yang bersih. Gabungan eksploitasi pantas, reverse SSH yang mengekalkan akses dan penyalahgunaan kelayakan menunjukkan bahawa peralatan yang terdedah perlu disiasat sebagai kemungkinan pencerobohan penuh.