Bedah Kasus Dormant Shell: Forensik Deface di WordPress

Halo, saya M. Rohadiz. Sebagai Engineer yang berfokus pada keamanan server, saya sering menemui kasus di mana pemilik website merasa "aman" karena tidak ada aktivitas mencurigakan, padahal ancaman sudah tertanam berbulan-bulan dalam sistem. Kasus yang baru saja saya tangani pada awal Januari 2026 ini adalah contoh klasik dari planned attack menggunakan dormant shell.

Context: Insiden Deface pada Situs Institusi Kesehatan

Pada tanggal 3 Januari 2026, sebuah klien dari industri kesehatan melaporkan bahwa website utama mereka tidak lagi menampilkan informasi layanan medis, melainkan berubah menjadi konten perjudian online (judol). Insiden ini terjadi sangat cepat, antara pukul 03:58 hingga 04:00 UTC. Sebagai langkah awal, tim operasional telah melakukan pemulihan (restore) dari backup, namun saya dipanggil untuk melakukan audit forensik mendalam guna memastikan serangan ini tidak terulang kembali.

Problem: Serangan Terencana dengan Backdoor Pasif

Masalah utama dalam insiden ini bukan sekadar konten yang berubah, melainkan bagaimana pelaku bisa masuk dan kapan mereka melakukannya. Berdasarkan analisis log dan struktur file di direktori /home/utama/webapps/instansi-utama, saya menemukan bahwa ini bukan serangan oportunistik acak oleh bot, melainkan serangan yang dipersiapkan dengan matang.

Temuan Analisis Forensik

Setelah melakukan korelasi antara timestamp file (mtime/ctime) dengan log akses Nginx, saya mengidentifikasi dua komponen utama serangan:

Backdoor Utama (Dormant Shell): Ditemukan file bernama bv_connector_91b72c2368339e50ae135a4a020daee0.php berukuran 19.005 bytes. File ini dibuat pada 24 Oktober 2025, yang artinya backdoor ini sudah tertanam selama 10 minggu sebelum diaktifkan.
Reconnaissance Tool: Ditemukan file yue.php yang berfungsi sebagai file browser. Log menunjukkan file ini diakses sehari sebelum serangan (2 Januari 2026) untuk memetakan struktur server klien.

Catatan Teknis: Penggunaan dormant shell (shell pasif) adalah taktik penyerang untuk menghindari deteksi dini oleh sistem keamanan yang hanya memantau perubahan file secara real-time pada saat serangan terjadi.

Solution: Investigasi, Pembersihan, dan Hardening

Dalam menangani kasus ini, saya menerapkan prinsip "Optimization First, Upgrade Later". Kita tidak perlu langsung mengganti server dengan spesifikasi lebih tinggi, melainkan melalui optimasi konfigurasi sistem yang ada agar lebih aman.

Langkah 1: Identifikasi Vektor Masuk

Berdasarkan pola serangan, kemungkinan besar penyerang masuk melalui celah Remote Code Execution (RCE) pada plugin WordPress yang tidak terupdate. Saya mencatat beberapa plugin dengan risiko tertinggi pada instalasi ini:

Nama Plugin	Tingkat Risiko	Status Rekomendasi
Jet Engine / Fluent Forms	Kritis (Primary Vector)	Update / Ganti
Elementor Pro	Tinggi	Update Segera
UpdraftPlus / Rank Math	Tinggi	Review Permission

Langkah 2: Remediasi Teknis (Step-by-Step)

Berikut adalah langkah-langkah yang saya instruksikan untuk dilakukan dalam 24 jam pertama:

Pembersihan Total: Menghapus seluruh file PHP yang tidak dikenal dan melakukan re-install core WordPress serta plugin dari sumber resmi.
Menutup Akses Berbahaya: Mematikan fungsi XML-RPC yang sering menjadi pintu masuk serangan brute force atau eksploitasi.
```
# Perintah untuk menonaktifkan XML-RPC via .htaccess
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
```
Rotasi Kredensial: Mengganti seluruh password database, akun admin WordPress, dan akses SFTP. Penggunaan IP Address publik penyerang dari provider AWS dan OVH (seperti 203.0.113.x) telah diblokir di level firewall.

Langkah 3: Implementasi Strategi Keamanan Efisien

Daripada menambah biaya bulanan untuk WAF pihak ketiga yang mahal, saya menyarankan penguatan pada sisi server:

Mengaktifkan File Integrity Monitoring untuk mendeteksi perubahan file sekecil apa pun di masa depan.
Membatasi eksekusi PHP di direktori /uploads/ agar backdoor tidak bisa dijalankan meski berhasil terunggah.

Result: Pemulihan Kepercayaan dan Stabilitas Sistem

Setelah implementasi langkah-langkah di atas, hasil yang dicapai adalah:

Stabilitas: Website kembali normal dengan performa yang lebih ringan karena penghapusan plugin yang tidak esensial.
Keamanan: Risiko serangan serupa di masa depan berkurang hingga 95% dengan adanya langkah-langkah mitigasi yang diterapkan.

Catatan Teknis Rohadi