Backdoor WordPress yang Bangun Diri Sendiri: 8 Lokasi yang Menjelaskan File Muncul Lagi Setelah Dihapus

Jam 9 pagi, klien menelepon. Katanya, file mencurigakan di website-nya sudah dihapus semalam, tapi pagi ini muncul lagi. Saya minta ia membuka File Manager hosting. Dua folder yang ia hapus semalam ada lagi dengan nama yang persis sama.

Pertanyaan paling umum dari pemilik website UMKM bukan “saya diretas”. Pertanyaannya lebih spesifik, dan itu yang sering membuat orang berhenti: “file sudah saya hapus, kok muncul lagi?”

Pada 1 Oktober 2026, Sucuri mempublikasikan analisis malware WordPress yang menjelaskan kenapa. Temuannya hampir tidak masuk akal kalau Anda belum pernah menemukannya langsung: satu backdoor hidup di minimal delapan tempat sekaligus, tersebar di file, database, dan memori bersama, dan satu tempat bisa membangun ulang yang lainnya.

Ini bukan cerita plugin atau theme nulled yang sudah sering muncul. Ini pola yang lebih rapi, lebih tahan banting, dan yang membuat cara pembersihan tradisional gagal.

Delapan tempat yang harus hidup bersamaan

Peneliti Sucuri, Gabriel Barbosa, menyebut jaringan ini sebagai “self-healing mesh”. Istilah itu bukan istilah baku. Yang dimaksud adalah jaringan komponen yang saling membangun ulang, bukan satu file yang bisa dihapus seperti biasa.

Malware yang mereka temukan diberi nama SC, dari penanda “SC_” yang muncul di kode yang disuntikkan. Ini hanya label dari peneliti, bukan nama resmi dari vendor malware mana pun.

Delapan komponen itu, ringkasannya begini:

Baris yang paling menjelaskan semuanya ada di dua file drop-in. Kalau Anda hapus plugin-nya, advanced-cache.php menulis ulang plugin tersebut. Kalau Anda hapus drop-in-nya, theme yang menulis ulang. Kalau semua file di disk Anda bersihkan sampai tuntas, permintaan halaman berikutnya memuat ulang seluruh rangkaian dari database atau dari segmen memori bersama.

Artinya tidak ada satu titik yang bisa dihapus untuk menghentikan sistem ini.

Kenapa file .user.ini itu penting

Banyak pemilik website mengira file berawalan titik di hosting mereka hanya .htaccess. Padahal ada satu lagi yang jarang dibahas, dan di kasus ini justru jadi titik awal serangan.

Isi file .user.ini yang disisipkan adalah auto_prepend_file. Directive ini memberi tahu PHP: sebelum memproses permintaan di folder itu, jalankan file ini terlebih dahulu. Artinya loader bisa berjalan sebelum WordPress selesai dimuat, dan sebelum plugin keamanan Anda sempat aktif.

Kalau di File Manager Anda ada file .user.ini di dalam folder wp-content, dan Anda tidak pernah membuatnya sendiri, perlakukan itu sebagai tanda serius.

Kenapa RAM jadi tempat simpan

Ini bagian yang paling jarang dibahas di artikel tentang pembersihan malware, dan justru bagian yang menjelaskan kenapa beberapa kasus tidak selesai.

Pada server yang mendukung System V shared memory, payload ini ditulis ke sebuah segmen dengan kunci numerik yang ditentukan. Segmen itu ada di RAM. Konsekuensinya langsung: segmen ini selamat dari penghapusan file dan dari pembersihan database, karena tidak ada di disk sama sekali.

Di shared hosting, ada satu hal yang lebih merepotkan. Segmen memori bersama itu kadang dimiliki akun berbeda dari website Anda, sehingga wajar kalau Anda tidak bisa melihatnya.

Dua pertanyaan yang perlu Anda uji di server sendiri:

• Apakah proses PHP di server ini mendukung shared memory? Jalankan php -i | grep sysvshm. Kalau hasilnya kosong, fitur itu tidak aktif, dan mekanisme ini tidak berlaku untuk website Anda.
• Kalau aktif, apakah ada segmen milik proses lain yang mencurigakan? Periksa dengan ipcs -m di terminal server.

Kalau hasil pemeriksaan menunjukkan fitur ini tidak aktif di server Anda, Anda boleh sedikit tenang. Bukan berarti website Anda aman, tapi satu vektor penyebab balik sudah gugur.

Apa yang dilakukan backdoor ini setelah hidup

Sapaan backdoor ini bukan sekadar bikin website tetap terbuka. Dari analisis Sucuri, begitu aktif ia mengumpulkan alamat dan host website, versi WordPress dan plugin, hash dari path folder, daftar theme aktif, daftar must-use plugin, sampai token sesi administrator yang sedang dipakai.

Semua data itu dikirim dalam bentuk terenkripsi ke alamat tujuan yang sudah ditentukan. Balasan dari server attacker bisa berisi tiga hal: JavaScript baru untuk disisipkan di halaman depan, PHP baru untuk dipasang, dan daftar plugin keamanan yang harus dinonaktifkan lalu dihapus.

Dua poin di situ perlu Anda sadari. Pertama, pada toko online, JavaScript yang disisipkan di halaman depan berarti pencurian data kartu di halaman pembayaran. Kedua, malware ini secara aktif mencari plugin keamanan Anda sendiri lalu menghapusnya.

Kodenya juga tidak terbaca. Para peneliti menemukan malware ini tidak memakai nama fungsi yang bisa dibaca, melainkan decoder yang mengurai kode memakai cipher substitusi. Itu alasan kenapa pemeriksaan manual dengan membaca file PHP sering gagal.

Langkah yang harus Anda lakukan sekarang

Kalau website Anda menunjukkan gejala-gejala di atas, urutannya penting. Salah urutan berarti kerja Anda hilang.

Pertama, sadari bahwa website yang sudah diretas tidak bisa dijamin aman hanya dengan menghapus file. Pada pola seperti ini, satu tempat yang tersisa sudah cukup untuk membangun ulang semuanya.

Kedua, ganti semua kunci sebelum membersihkan. Password dashboard WordPress, password hosting, password FTP, dan password database. Putuskan juga semua sesi aktif di WordPress. Ini penting karena kalau ada admin asing yang masih aktif, semua pekerjaan bersih-bersih Anda sia-sia.

Ketiga, jangan uninstall WordPress lalu berharap selesai. Mengganti file inti hanya membersihkan bagian permukaan. Isi folder wp-content dan database tidak ikut bersih, dan pada kasus SC justru di situ payload-nya tersimpan.

Keempat, periksa halaman Anda dari dua perangkat. Buka dari HP, bukan hanya dari laptop. Malware seperti ini sering menampilkan isi berbeda tergantung perangkat yang dipakai. Banyak pemilik website baru sadar setelah kliennya yang mengetahuinya.

Kenapa plugin keamanan tidak menemukan semuanya

Ada satu pertanyaan praktis yang sering muncul: apakah plugin keamanan seperti Wordfence atau Sucuri akan menemukan semua ini?

Jawabannya: tidak semuanya. Plugin keamanan bekerja di dalam WordPress, pada lapisan PHP. Tapi tiga dari delapan komponen ini berada di luar jangkauan plugin. File .user.ini dibaca PHP sebelum WordPress selesai dimuat. File advanced-cache.php dan db.php adalah drop-in, bukan plugin, dan dimuat pada tahap awal. Segmen memori bersama bukan file sama sekali, jadi tidak bisa dibaca scanner mana pun yang bekerja dengan memindai file.

Saya tidak sedang mengatakan plugin keamanan itu tidak berguna. Plugin keamanan tetap berguna, terutama untuk memblokir percobaan serangan sebelum masuk. Tapi kalau penyerang sudah masuk, plugin keamanan hanya akan melihat apa yang sudah bisa ia akses.

Kapan Anda harus berhenti dan minta bantuan

Batas antara yang bisa dikerjakan sendiri dan yang perlu bantuan orang lain ternyata cukup jelas, dan batasnya ada di tempat yang sama: apakah jalur masuknya sudah tertutup atau belum.

Kalau Anda menemukan satu saja dari tanda berikut, sebaiknya berhenti mencoba membersihkan sendiri dan bawa ke orang yang memang mengerjakan ini setiap hari:

• Website Anda berada di shared hosting dan Anda tidak punya akses terminal atau SSH ke server.
• Ada file PHP asing di dalam folder wp-content/uploads yang Anda tidak bisa jelaskan asalnya.
• Indikator di halaman Google Search Console Anda masih menampilkan URL asing.
• Toko online Anda memakai payment gateway, dan Anda tidak yakin apakah data kartu pernah bocor.

Alasan keempat ini perlu dijelaskan lebih lanjut. Kalau website Anda memproses pembayaran, satu hal yang perlu dijawab bukan hanya “situsnya sudah dibersihkan”, tapi “apakah data pelanggan saya aman”. Backdoor yang mampu mengambil token sesi administrator dan menyisipkan JavaScript di halaman depan memang dirancang untuk menyentuh jalur itu. Menginstal ulang WordPress tidak menjawab pertanyaan itu.

Pencegahan yang masuk akal, bukan sekadar paranoia

Ada dua saran pencegahan dari Sucuri yang layak dijalankan, dan keduanya gratis.

Pertama, jaga semua komponen tetap mutakhir. Mayoritas kompromi yang Sucuri tangani memanfaatkan kerentanan yang sudah diketahui dan sudah ditambal di komponen versi lama. Update yang cepat memperpendek jendela waktu yang dipakai penyerang.

Kedua, pasang firewall aplikasi web. Firewall memblokir percobaan serangan sebelum mencapai aplikasi, bisa menangkap parameter beacon yang dipakai malware ini untuk menghubungi server attacker, dan membantu menghentikan request keluar ke command channel.

Dua-duanya masuk akal untuk website UMKM. Plugin keamanan gratis seperti Wordfence atau Sucuri sudah cukup untuk langkah kedua. Yang sering dilupakan justru langkah pertama: berapa plugin dan theme yang sudah tidak Anda pakai selama setahun, dan masih terpasang di website Anda? Plugin yang tidak aktif tetap bisa jadi pintu masuk kalau pernah punya kerentanan.

Catatan jujur tentang blog ini

Saya menulis artikel ini karena pola seperti ini akan semakin sering ditemui. Tapi saya juga ingin jujur soal batasannya. Analisis yang saya rangkum di atas berdasarkan riset Sucuri, bukan pemeriksaan langsung di website Anda. Saya tidak bisa tahu apakah website Anda mengalami hal yang sama hanya dari artikel ini.

Kalau website Anda menunjukkan gejala yang saya jelaskan di atas, langkah paling berguna yang bisa Anda lakukan hari ini juga yang paling murah: masuk ke File Manager, periksa apakah ada file .user.ini di folder wp-content yang tidak pernah Anda buat. Kalau ada, Anda sudah punya petunjuk yang jelas.

Kalau tidak ada tapi gejalanya tetap ada, jangan mengulang cleaning permukaan. Yang perlu diputuskan bukan file mana yang harus dihapus, tapi dari mana penyerang masuk dan kenapa jalurnya masih terbuka.

Kalau Anda ingin website Anda diperiksa sungguhan, kirim pesan. Saya bantu cek, dan kalau memang perlu pengerjaan serius, saya akan bilang terus terang.