Malware WordPress Muncul Lagi: Cara Menemukan Backdoor

Anda menghapus file aneh, mengganti password, bahkan memasang plugin scanner. Beberapa jam atau hari kemudian file muncul lagi, redirect kambuh, atau halaman spam baru terindeks. Pola ini biasanya berarti satu dari dua hal: persistence yang dapat menulis ulang konten masih tertinggal, atau jalur masuk awal masih terbuka sehingga website dikompromikan ulang. Menghapus temuan yang terlihat sekali lagi hanya mengulang siklus.

Jawaban singkat: jangan mulai dengan menghapus file yang baru muncul. Simpan snapshot file, database, log hosting, log CDN, dan waktu temuan; tentukan apa yang kembali dan kapan; lalu telusuri akun/sesi, token, cron, kode inti/plugin/theme, uploads, database, konfigurasi server, dan panel hosting secara berurutan. Pulihkan dari salinan yang diketahui bersih, perbaiki entry point, cabut akses yang berisiko, dan verifikasi bahwa tidak ada mekanisme yang dapat membuat payload kembali.

“Malware kembali” belum menunjukkan sumbernya

Temuan berulang bukan diagnosis tunggal. File bisa ditulis ulang oleh backdoor PHP, plugin atau theme rentan, akun administrator asing, token application password, cron WordPress, scheduled task server, kredensial hosting yang dicuri, deployment otomatis yang tercemar, CDN Worker, atau komputer admin yang masih terinfeksi. Kadang temuan sebenarnya berasal dari restore backup yang sudah mengandung malware atau scanner yang mengulang deteksi pada file lama.

Karena beberapa penyebab menghasilkan gejala serupa, cocokkan indikator dengan timeline. Apakah file sama persis kembali di path yang sama? Apakah hash dan waktu perubahan cocok? Apakah situs hanya menampilkan redirect untuk kondisi tertentu? Apakah kemunculan bertepatan dengan login, job cron, deployment, atau restore? Simpan bukti untuk setiap pertanyaan sebelum melakukan perubahan.

Tahan risiko dan simpan bukti dahulu

1. Beri tahu hosting dan pemilik bisnis. Jika ada phishing, pembayaran, atau data pelanggan, minta containment segera, batasi route berbahaya, dan ikuti prosedur insiden organisasi.
2. Ambil snapshot file dan database serta unduh log sebelum masa retensi berakhir. Simpan salinan read-only di lokasi terpisah dan catat timestamp, zona waktu, hash, akun yang mengambilnya, serta tindakan yang sudah dilakukan.
3. Jika situs masih menerima traffic, gunakan maintenance atau isolasi yang disetujui host. Jangan mematikan seluruh layanan tanpa koordinasi bila tindakan itu dapat merusak bukti atau transaksi.
4. Buat salinan kerja yang tidak dapat diakses publik. Matikan outbound email, payment, webhook, dan integrasi produksi agar kode berbahaya tidak mengirim pesan atau mengubah sistem lain saat diperiksa.
5. Jangan menjalankan file mencurigakan untuk “melihat fungsinya”. Jangan mengunggah sampel ke layanan publik bila mengandung data atau kredensial. Jika perlu analisis malware, minta profesional memakai lingkungan terisolasi.

Susun timeline kemunculan ulang

Buat tabel per temuan: path/nama objek, kapan pertama dan terakhir terlihat, hash, sumber laporan, tindakan yang dilakukan, waktu file kembali, serta perubahan yang terjadi di sekitar waktu itu. Gunakan waktu dari server, hosting, CDN, database, dan komputer admin dengan zona waktu yang konsisten. Timestamp file dapat dimanipulasi; perlakukan sebagai petunjuk, bukan bukti tunggal.

Bandingkan versi sebelum dan sesudah cleanup bila ada. Jika hash berubah, cari proses yang menulis file. Jika hash sama tetapi lokasi berubah, periksa apakah ada salinan loader yang membuat ulang. Jika file tidak berubah tetapi perilaku berubah, telusuri rule CDN, konfigurasi web server, cache, JavaScript, atau nilai database. Cari pula apakah scanner menandai file legit yang tidak berubah—jangan menyamakan semua alarm dengan backdoor.

Periksa jalur persistence menurut lapisan

1. Akses manusia dan kredensial

Inventarisasi akun administrator, editor, akun hosting, SSH/SFTP, panel DNS, CDN, registrar, deployment key, akun backup, dan pengguna layanan. Periksa pengguna baru, perubahan role, email pemulihan, waktu login, sesi aktif, application password, dan token API. Nama akun yang dikenal tidak membuktikan bahwa sesi atau kredensialnya masih aman.

Dari perangkat yang telah dipastikan bersih, reset password unik untuk akun pemilik, hosting, SSH/SFTP, database, CDN, DNS, dan layanan yang dapat menulis ke situs. Aktifkan MFA, cabut application password/token yang tidak dibutuhkan, akhiri sesi lama, dan hapus akun berbahaya setelah akses pemilik sah dipastikan. Jika password diganti dari perangkat yang ikut terinfeksi, penyerang mungkin kembali memakai kredensial baru tersebut.

2. File inti, plugin, theme, dan drop-in

Bandingkan file WordPress inti dengan versi resmi menggunakan wp core verify-checksums. Perintah tersebut membandingkan checksum file inti WordPress; ia bukan scanner menyeluruh untuk semua plugin, theme, uploads, atau database. Untuk plugin WordPress.org, wp plugin verify-checksums --all dapat membantu, tetapi theme custom/premium dan plugin tanpa checksum publik membutuhkan pembandingan terhadap paket tepercaya atau sumber vendor. Lihat dokumentasi WP-CLI core checksums, plugin checksums, dan panduan pemeriksaan keamanan dengan WP-CLI.

Cari file PHP baru atau berubah pada root, wp-admin, wp-includes, plugin/theme, mu-plugins, uploads, cache, dan folder sementara. Periksa wp-config.php, .htaccess, .user.ini, konfigurasi PHP, drop-in, serta file yang tidak berada di lokasi normal. Jangan menimpa semuanya dengan paket core sebelum membuat snapshot dan memastikan versi yang benar; penggantian core tidak menghapus persistence di plugin, theme, database, atau server.

3. Cron dan automation

Pada salinan terisolasi, catat jadwal WordPress dengan wp cron event list dan bandingkan hook yang tidak dikenal dengan plugin/theme yang memang terpasang. Periksa juga cron sistem, scheduled task hosting, pipeline deployment, job backup, dan event pada CDN. Perintah WP-CLI itu menunjukkan event terjadwal, bukan seluruh automation di server; dokumentasinya ada di wp cron event list.

Jangan hapus seluruh cron event tanpa tahu fungsinya. Task sah dapat mengirim email, membersihkan cache, atau memperbarui data. Cari siapa yang menjadwalkan hook, kode callback-nya, perubahan jadwal, dan apakah event memanggil file atau URL yang tidak disetujui.

4. Database, konfigurasi, dan jalur masuk

Periksa halaman/post asing, opsi sitewide, widget, custom code, daftar admin, plugin aktif, URL tujuan redirect, dan nilai yang berubah pada waktu insiden. Gunakan salinan database dan alat yang menangani data serialized; edit massal raw SQL dapat merusak serialisasi atau konfigurasi multisite. Tinjau access/error log, login panel, permintaan POST yang tidak biasa, WAF/CDN, user FTP, backup, dan integrasi. Minta provider memeriksa log yang tidak Anda miliki.

Temukan entry point yang memungkinkan penulisan pertama: komponen usang, kredensial lemah/terpakai ulang, file upload yang bisa dieksekusi, akses vendor lama, permission terlalu longgar, atau akun dan token yang tidak dicabut. Jika celah awal belum diketahui, jangan menyatakan insiden sudah selesai hanya karena payload hilang.

Hubungkan perubahan yang kembali dengan proses penulisnya

Sebuah dugaan backdoor harus dapat diuji terhadap bukti. Buat tabel dengan kolom “temuan”, “siapa/proses yang dapat menulis”, “log yang mendukung”, “uji aman berikutnya”, dan “pemilik keputusan”. Untuk file baru, cocokkan path dengan user sistem yang memilikinya dan log FTP/SFTP/deploy; untuk post baru, cocokkan author ID dengan login dan perubahan role; untuk redirect, cocokkan request ID di CDN dan origin. Jika tidak ada log, tulis batasan itu secara eksplisit dan minta host memeriksa sumber yang masih tersedia.

Jalankan inspeksi pada salinan dengan plugin dan theme dimatikan hanya jika itu aman untuk investigasi; beberapa konfigurasi WordPress memerlukan komponen aktif untuk membaca database atau menampilkan perilaku. Catat setiap perubahan pada salinan agar pembandingan tetap valid. Jangan menjadikan “tidak muncul saat plugin dimatikan” sebagai bukti pasti bahwa plugin tertentu berniat jahat: dependency, cache, atau aturan kondisional dapat berubah. Uji satu komponen per kali, lalu cocokkan dengan file, kode vendor, dan log.

Bersihkan dengan urutan yang dapat dibalik

1. Tetapkan salinan bersih yang dipercaya dari backup sebelum insiden atau paket resmi vendor, setelah memeriksa bahwa tanggal backup memang sebelum kompromi.
2. Perbaiki atau nonaktifkan entry point pada staging; update atau ganti komponen yang tidak didukung. Hapus file asing hanya setelah pemilik, fungsi, dan bukti tersimpan.
3. Cabut akses/token berisiko dan rotasi rahasia dari perangkat bersih. Periksa key integrasi, database user, SSH key, dan akun layanan, bukan password WordPress saja.
4. Pulihkan data bisnis yang diperlukan secara selektif setelah konten, akun, dan opsi diperiksa. Jangan mengimpor database lama secara utuh tanpa memahami bahwa persistence dapat tersimpan di sana.
5. Uji fungsi inti, login, formulir, pembayaran, cron, email, dan route yang pernah terdampak pada staging. Cocokkan file serta database dengan baseline tepercaya.
6. Terapkan perbaikan yang sama ke produksi pada waktu perubahan yang disetujui, simpan backup sebelum perubahan, lalu verifikasi kembali hasilnya.

Bukti bahwa perbaikan benar-benar bertahan

Jadwalkan pemeriksaan berulang selama periode pemantauan yang ditetapkan tim. Bandingkan hash file penting, akun, plugin/theme, cron, redirect, halaman indeks, dan log. Ulangi uji setelah cache expire atau setelah job terjadwal berjalan; tes hanya sesaat setelah restore dapat melewatkan task yang aktif pada jadwal berikutnya. Simpan hasil bersih beserta tanggal dan cakupan pemeriksaannya.

Jika Google Search Console menampilkan Security Issues, minta review setelah seluruh temuan dan entry point diperbaiki. Google dapat menunjukkan sampel URL tambahan; periksa seluruh situs, bukan hanya contoh. Panduan Google juga menyarankan pemantauan log dan pencarian perubahan tidak dikenal (prevent malware infection). Untuk respons insiden yang lebih luas, ikuti panduan pemulihan website WordPress yang diretas. Untuk tanda yang terlihat pengunjung, baca indikator website terkena malware.

Kesalahan yang membuat malware muncul lagi

• Menghapus satu file atau mengganti password WordPress, tetapi membiarkan akun hosting, token, cron, plugin rentan, atau sesi tetap aktif.
• Restore backup berdasarkan tanggal nama file tanpa memeriksa kapan kompromi pertama terjadi.
• Menjalankan scanner berkali-kali tanpa membandingkan hash, log, atau proses yang menulis file.
• Mengganti semua file inti dan menyebutnya cleanup, padahal wp-content, database, CDN, dan server tidak diperiksa.
• Menghapus semua event cron atau semua file PHP tanpa mengidentifikasi pemilik dan dampaknya.
• Mengubah permission menjadi 777 agar cleanup mudah, sehingga proses yang sudah memiliki akses dapat menulis kembali file.
• Mengirim password baru melalui chat atau menggantinya dari perangkat yang belum bersih.

Apakah reinstall WordPress core akan menghilangkan backdoor? Tidak selalu. Core bersih tidak otomatis membersihkan plugin, theme, mu-plugin, uploads, database, akun, cron server, atau CDN.

Mengapa malware kembali setelah saya mengganti password? Password yang diganti mungkin hanya satu dari beberapa kredensial; sesi, application password, akun hosting, cron, atau kerentanan aktif dapat mempertahankan akses.

Apakah setiap file PHP asing adalah malware? Tidak. Theme, plugin, dan aplikasi tertentu dapat punya file yang sah. Bandingkan lokasi, checksum, owner, waktu, isi, dan sumber paket sebelum menghapusnya.

Kapan saya perlu bantuan profesional? Eskalasi jika file terus dibuat ulang, ada akses hosting yang tidak dikenal, database atau pembayaran terdampak, Anda kehilangan log/baseline, atau situs tetap menampilkan perilaku berbeda setelah restore.

Jika malware berulang dan Anda belum menemukan proses yang membuatnya kembali, minta bantuan pemulihan WordPress darurat untuk menelusuri bukti sebelum melakukan perubahan destruktif.