Pengantar

Server email menjadi salah satu target menarik bagi hacker karena di dalamnya tersimpan banyak informasi penting. Mulai dari komunikasi perusahaan, dokumen, password reset, hingga data pengguna.

Hal tersebut kembali terlihat pada serangan terhadap Zimbra Collaboration Suite. Hacker diketahui mengeksploitasi sebuah celah keamanan yang dikenal sebagai CVE-2026-73570 untuk mendapatkan akses ke server Zimbra.

Yang membuat serangan ini berbahaya adalah aktivitas hacker tidak berhenti setelah mendapatkan akses awal. Mereka memasang web shell, membuat mekanisme persistence, mencuri credential, bergerak ke server lain, hingga mengambil data mailbox.

Apa Itu CVE-2026-73570?

CVE-2026-73570 merupakan kerentanan pada Zimbra Collaboration Suite yang memungkinkan attacker melakukan OS Command Injection.

Sederhananya, celah ini memungkinkan attacker menyisipkan perintah tertentu sehingga server menjalankan perintah yang sebenarnya tidak seharusnya dijalankan.

Kerentanan ini memiliki tingkat keparahan CVSS 8.9, sehingga termasuk kerentanan serius.

Dalam kondisi tertentu, eksploitasi dapat dilakukan tanpa harus memiliki akun atau melakukan login terlebih dahulu.

Kerentanan ini berkaitan dengan komponen zimbra-snmp dan konfigurasi SNMP notifications.

Karena itu, server Zimbra yang masih menggunakan konfigurasi dan versi yang rentan memiliki risiko cukup besar apabila terekspos ke internet.

Serangan Dimulai dari SMTP

Salah satu hal menarik dari serangan ini adalah attacker memanfaatkan request SMTP yang telah dimanipulasi.

Attacker tidak perlu terlebih dahulu mendapatkan username dan password administrator.

Request yang dibuat khusus dikirimkan ke server Zimbra untuk memicu command injection.

Jika berhasil, attacker dapat menjalankan perintah dengan privilege akun layanan Zimbra.

Dari sinilah serangan kemudian berkembang.

Pada tahap awal, attacker biasanya melakukan reconnaissance untuk mengetahui lingkungan server yang berhasil ditembus.

Mereka mencari informasi seperti:

• Versi sistem.
• Konfigurasi Zimbra.
• Struktur server.
• Mailbox.
• Konfigurasi MTA.
• Credential dan secret.
• Server Zimbra lain yang dapat diakses.

Memasang Web Shell

Setelah mendapatkan akses, attacker tidak ingin kehilangan akses tersebut.

Salah satu teknik yang digunakan adalah memasang web shell.

Web shell merupakan script yang memungkinkan attacker menjalankan perintah melalui server web.

Dalam kasus ini, ditemukan beberapa JSP web shell yang ditempatkan pada direktori aplikasi Zimbra.

Dengan adanya web shell, attacker dapat kembali mengakses server meskipun jalur eksploitasi awal sudah ditutup.

Inilah alasan mengapa melakukan patch saja belum tentu cukup.

Jika server sudah berhasil dikompromikan sebelum patch diterapkan, attacker mungkin sudah meninggalkan backdoor.

Reverse Shell dan Persistence

Selain web shell, attacker juga menggunakan teknik reverse shell.

Reverse shell memungkinkan server yang sudah dikompromikan membuat koneksi kembali ke server yang dikendalikan attacker.

Teknik ini memberikan attacker akses interaktif ke sistem.

Mereka juga mencoba membuat berbagai mekanisme persistence agar akses tetap tersedia.

Beberapa lokasi yang menjadi perhatian antara lain:

• Cron job.
• Systemd service.
• SSH authorized keys.
• Shell startup files.
• Akun lokal.
• File sementara.
• Web application.

Dengan persistence, attacker tidak harus mengeksploitasi vulnerability yang sama setiap kali ingin masuk kembali.

Mencoba Mendapatkan Hak Root

Setelah memperoleh akses sebagai user Zimbra, attacker mencoba meningkatkan hak akses.

Salah satu aktivitas yang ditemukan adalah perubahan pada konfigurasi:

/etc/pam.d/sudo

Tujuannya adalah membuat akun Zimbra dapat menjalankan perintah tertentu menggunakan sudo tanpa harus memasukkan password.

Jika berhasil, dampaknya jauh lebih besar.

Attacker yang awalnya hanya memiliki akses sebagai user layanan dapat memperoleh kemampuan untuk melakukan aktivitas dengan privilege yang lebih tinggi.

Ini merupakan contoh klasik privilege escalation.

Mencuri Credential dan Secret Zimbra

Server Zimbra menyimpan berbagai secret penting yang digunakan untuk authentication dan komunikasi antar-komponen.

Attacker menggunakan utilitas seperti:

zmlocalconfig -s

untuk mencari informasi konfigurasi dan secret.

Beberapa informasi yang menjadi target antara lain:

• zimbraPreAuthKey
• zimbraAuthTokenKey
• zimbraTwoFactorAuthSecret

Credential dan secret seperti ini sangat berharga.

Jika berhasil dicuri, attacker dapat menggunakannya untuk melakukan aktivitas lain tanpa harus mengeksploitasi vulnerability yang sama.

Karena itu, administrator tidak boleh menganggap patch vulnerability sebagai akhir dari masalah.

Jika server diduga sudah dikompromikan, credential dan secret yang berkaitan juga perlu dipertimbangkan untuk dirotasi.

Bergerak ke Server Zimbra Lain

Serangan kemudian dapat berkembang menjadi lateral movement.

Dalam lingkungan Zimbra yang menggunakan beberapa server atau node, attacker dapat mencoba berpindah dari satu server ke server lainnya.

Salah satu target yang ditemukan adalah SSH identity milik Zimbra, termasuk:

/opt/zimbra/.ssh/zimbra_identity

Jika credential atau SSH key tersebut dapat digunakan untuk mengakses server lain, attacker dapat memperluas kontrolnya.

Attacker juga menggunakan tool seperti rsync untuk memindahkan file dan script.

Artinya, kompromi satu server Zimbra berpotensi menjadi pintu masuk menuju server lain dalam lingkungan yang sama.

Munculnya Malware Zimdown2

Microsoft juga menemukan payload bernama Zimdown2.

Malware ini dibuat menggunakan bahasa pemrograman Go.

Zimdown2 digunakan untuk memasang komponen lain yang disebut Zimclient2.

Komponen tersebut memberikan attacker berbagai kemampuan untuk mengendalikan server yang sudah terinfeksi.

Beberapa kemampuan yang ditemukan antara lain:

• Interactive shell.
• Transfer file.
• SOCKS5 proxy.
• WebSocket.
• TLS.
• Raw TCP.

Kemampuan tersebut membuat server yang sudah dikompromikan tidak hanya menjadi target, tetapi juga dapat digunakan sebagai pivot point menuju jaringan internal.

Misalnya, server Zimbra yang berada di jaringan internal perusahaan dapat dimanfaatkan attacker untuk mencoba mengakses sistem lain yang sebelumnya tidak dapat dijangkau langsung dari internet.

Data Mailbox Menjadi Target

Mengapa attacker tertarik menyerang server email?

Jawabannya sederhana: data email sangat berharga.

Dalam serangan ini, attacker tidak hanya mencari file sistem.

Mereka juga menargetkan database dan informasi mailbox Zimbra.

Beberapa data yang menjadi perhatian antara lain:

• Mailbox.
• Metadata mailbox.
• Informasi perangkat mobile.
• Konfigurasi out-of-office.
• Data dalam namespace Zimbra.
• Mail rules.
• Credential.
• Certificate.
• LDAP secret.
• Konfigurasi server.

Jika berhasil mendapatkan data tersebut, attacker dapat mengetahui komunikasi internal organisasi dan informasi penting lainnya.

Data Kemudian Dikumpulkan dan Dieksfiltrasi

Setelah mendapatkan data, attacker perlu mengeluarkannya dari server.

Proses ini disebut data exfiltration.

Data yang dikumpulkan dapat dikompresi terlebih dahulu menjadi archive agar lebih mudah dipindahkan.

Dalam salah satu aktivitas yang ditemukan, attacker juga menggunakan AzCopy dan Azure Blob Storage untuk membantu proses transfer data.

Hal ini menunjukkan bahwa serangan tidak hanya bertujuan mendapatkan akses sementara.

Target akhirnya dapat berupa pencurian data dalam jumlah besar.

Timeline Serangan

Secara sederhana, rangkaian peristiwa dapat digambarkan seperti berikut:

Juli 2026
Zimbra merilis versi yang memperbaiki vulnerability tersebut.

28 Juli–7 Agustus 2026
Ditemukan aktivitas scanning yang mencoba menguji command injection.

13 Agustus 2026
CVE-2026-73570 dipublikasikan.

21 Agustus 2026
CVE tersebut masuk ke daftar Known Exploited Vulnerabilities (KEV) milik CISA.

September 2026
Microsoft mengungkap detail mengenai aktivitas eksploitasi, termasuk web shell, persistence, credential theft, lateral movement, dan pencurian data mailbox.

Timeline ini menunjukkan satu hal penting: vulnerability yang sudah memiliki patch tetap dapat menjadi masalah jika organisasi terlambat melakukan update.

Bagaimana Mengetahui Server Zimbra Sudah Dikompromikan?

Administrator Zimbra perlu melakukan pemeriksaan jika server pernah menggunakan versi yang rentan atau terekspos ke internet.

Beberapa hal yang dapat diperiksa antara lain:

1. Periksa Log

Perhatikan aktivitas mencurigakan pada log Zimbra, termasuk request SMTP yang tidak biasa.

Periksa juga aktivitas login dan koneksi dari alamat IP yang tidak dikenal.

2. Cari Web Shell

Periksa direktori aplikasi Zimbra untuk mencari file JSP yang tidak dikenal.

File baru yang muncul tanpa proses deployment resmi harus diperiksa.

3. Periksa /tmp

Direktori /tmp sering digunakan attacker untuk menyimpan script, binary, atau file sementara.

Cari file yang mencurigakan dan periksa waktu pembuatannya.

4. Periksa Cron

Jalankan pemeriksaan terhadap cron job.

Cari job yang tidak dibuat oleh administrator.

5. Periksa Systemd

Pastikan tidak ada service baru yang mencurigakan.

Attacker dapat menggunakan systemd untuk membuat malware berjalan otomatis setelah server reboot.

6. Periksa SSH Key

Periksa authorized_keys dan SSH identity.

Pastikan tidak ada key yang ditambahkan oleh pihak yang tidak dikenal.

7. Periksa User

Cari akun lokal baru.

Akun yang tidak dikenal dapat menjadi indikasi persistence.

8. Periksa Koneksi Keluar

Monitor koneksi outbound dari server Zimbra.

Koneksi menuju IP atau domain yang tidak dikenal perlu mendapatkan perhatian khusus.

Bagaimana Cara Melindungi Server Zimbra?

Langkah pertama adalah melakukan patch.

Administrator perlu menggunakan versi Zimbra yang sudah memperbaiki CVE-2026-73570 atau versi terbaru yang direkomendasikan vendor.

Jika patch belum dapat dilakukan, administrator dapat mempertimbangkan langkah mitigasi seperti:

• Menghapus zimbra-snmp jika memang tidak dibutuhkan.
• Menonaktifkan SNMP notifications.
• Membatasi akses SNMP.
• Membatasi akses SMTP.
• Membatasi akses server dari internet.
• Menggunakan firewall.
• Memantau koneksi outbound.

Namun mitigasi tidak boleh dianggap sebagai pengganti patch permanen.

Jika Server Sudah Terlanjur Terinfeksi

Jika ditemukan indikasi compromise, jangan hanya melakukan update kemudian menganggap masalah selesai.

Server sebaiknya diperlakukan sebagai incident response case.

Beberapa langkah yang dapat dilakukan:

1. Isolasi server yang terindikasi terkompromikan.
2. Simpan dan amankan log.
3. Cari web shell dan malware.
4. Periksa persistence.
5. Periksa akun dan SSH key.
6. Audit privilege.
7. Periksa aktivitas lateral movement.
8. Rotasi credential dan secret.
9. Periksa mailbox yang mungkin telah diakses.
10. Lakukan threat hunting pada server lain.

Jika server menyimpan data penting, proses investigasi sebaiknya dilakukan dengan hati-hati agar bukti digital tidak hilang.

Pelajaran untuk Sysadmin dan Tim SOC

Kasus Zimbra ini memberikan beberapa pelajaran penting.

Patch Bukan Akhir dari Incident Response

Jika vulnerability sudah dieksploitasi sebelum patch diterapkan, attacker mungkin sudah meninggalkan backdoor.

Karena itu, setelah melakukan patch tetap diperlukan threat hunting.

Email Server Harus Dianggap Sebagai Aset Kritis

Server email bukan sekadar tempat mengirim dan menerima email.

Di dalamnya dapat tersimpan:

• Informasi perusahaan.
• Dokumen.
• Credential.
• Password reset.
• Data pelanggan.
• Informasi keuangan.
• Komunikasi internal.

Karena itu, email server harus mendapatkan monitoring dan perlindungan yang serius.

Persistence Harus Dicari di Banyak Tempat

Jangan hanya mencari malware pada satu direktori.

Periksa juga:

• Cron.
• Systemd.
• SSH key.
• User account.
• Web application.
• Shell startup.
• /tmp.
• Konfigurasi service.

Attacker dapat menggunakan lebih dari satu metode persistence.

Kesimpulan

Eksploitasi CVE-2026-73570 menunjukkan bagaimana sebuah vulnerability pada server email dapat berkembang menjadi serangan yang jauh lebih besar.

Serangan dapat dimulai dari command injection, kemudian berkembang menjadi:

Initial Access → Web Shell → Reverse Shell → Persistence → Privilege Escalation → Credential Theft → Lateral Movement → Mailbox Theft → Data Exfiltration

Kasus ini menjadi pengingat bagi administrator bahwa melakukan patch saja tidak selalu cukup.

Jika sebuah vulnerability sudah diketahui pernah dieksploitasi, administrator juga perlu bertanya:

“Apakah server saya sudah pernah ditembus sebelum saya melakukan patch?”

Pertanyaan tersebut sangat penting karena attacker mungkin sudah meninggalkan web shell, akun tambahan, SSH key, malware, atau mekanisme persistence lainnya.

Karena itu, pendekatan terbaik adalah menggabungkan patching, hardening, monitoring, threat hunting, dan incident response untuk memastikan server benar-benar kembali dalam kondisi aman.