Cara Membandingkan File WordPress yang Berubah Setelah Insiden

Setelah peringatan keamanan atau pemulihan sementara, admin melihat file WordPress dengan waktu modifikasi baru dan ingin tahu apakah ada kode asing. Timestamp saja tidak menjawabnya: update otomatis, deployment, ekstraksi backup, migrasi server, dan pelaku yang mengubah metadata dapat menghasilkan waktu yang tampak serupa. Mengganti semua file sebelum mencatat kondisi saat ini juga dapat menghapus petunjuk yang dibutuhkan untuk menemukan sumber perubahan.

Jawaban singkat: simpan salinan file dan database yang terlindungi, catat waktu, versi WordPress, locale, plugin, dan riwayat deployment, lalu bandingkan file dengan baseline tepercaya yang cocok. WP-CLI dapat memeriksa file inti terhadap checksum resmi WordPress.org dan plugin yang tersedia di direktorinya. Hasil yang berbeda adalah temuan untuk ditinjau—bukan perintah otomatis untuk menghapus atau menimpa file. File kustom, plugin premium, tema, upload, konfigurasi, serta database perlu dibandingkan dengan sumber yang berwenang untuk situs itu.

Jika bukti menunjukkan akun, konten, atau file telah diubah tanpa izin, ikuti panduan pemulihan website yang diretas sebagai kerangka insiden. Untuk memulihkan dari salinan, lihat panduan backup website; file dan database harus sama-sama dipertimbangkan.

Tentukan pertanyaan yang ingin dijawab

Jangan mulai dengan “file mana yang paling baru?” Mulailah dari pertanyaan lebih sempit: komponen mana yang berubah, apakah perubahan itu sesuai rilis atau deployment yang disetujui, kapan perubahan mulai terlihat, dan apakah file tersebut dijalankan pada request publik. Daftar temuan Search Console, nama file dari host, alert scanner, atau laporan vendor adalah petunjuk awal; catat sumber dan waktu setiap temuan, jangan langsung menganggapnya sebagai bukti lengkap.

Tentukan cakupan sebelum menjalankan perintah. WordPress terdiri dari core, plugin, tema, mu-plugin, drop-in, uploads, file konfigurasi, aset build, dan database. Perintah pemeriksaan core tidak akan menjawab apakah wp-content/uploads berisi PHP asing, apakah plugin premium diubah, atau apakah nilai database telah diinjeksi. Tulis bagian mana yang diperiksa, bagian yang tidak tercakup, serta alasan pengecualiannya agar operator berikutnya tidak menyamakan “pemeriksaan core berhasil” dengan “seluruh situs bersih”.

Simpan kondisi saat ini sebelum membandingkan

Minta administrator atau host membuat salinan file dan database sebelum penggantian, pembersihan, update, atau restore. Simpan juga log akses, error, autentikasi, deployment, dan aktivitas panel yang masih tersedia. Letakkan salinan di luar webroot dengan akses terbatas; jangan kirim dump database, konfigurasi, cookie, atau kredensial ke tiket publik. Catat siapa yang mengambil salinan, waktu dan zona waktu, lokasi penyimpanan, versi WordPress, bahasa instalasi, serta nama environment.

Buat inventaris komponen dari sumber yang berwenang: catatan rilis, file lock atau manifest deployment, paket plugin/tema resmi, repository internal, atau snapshot host sebelum insiden. Jangan mengunduh “versi terbaru” lalu membandingkannya dengan instalasi lama tanpa memastikan versinya cocok. Perbedaan versi akan menghasilkan banyak file berbeda yang memang diharapkan dan membuat temuan sulit dipilah.

Jika situs melayani transaksi atau pengguna, koordinasikan snapshot dengan host agar containment tidak merusak bukti atau menghentikan layanan tanpa persetujuan owner. Bila ada dugaan pencurian data, permintaan dari regulator, atau proses hukum, jangan mengklaim bahwa salinan biasa adalah image forensik. Minta tim incident response dan penasihat yang memahami kebijakan serta yurisdiksi terkait.

Periksa WordPress core dengan checksum yang cocok

WP-CLI menyediakan wp core verify-checksums untuk membandingkan file core terhadap checksum WordPress.org. Jalankan dari direktori instalasi yang benar dan pastikan target bukan staging, salinan, atau multisite lain secara tidak sengaja. Dokumentasi resmi menjelaskan bahwa versi dan locale dapat diberikan bila perlu:

wp core version
wp core verify-checksums --version=<versi-terpasang> --locale=<locale-terpasang>

Ganti placeholder dengan informasi yang telah dicatat; jangan mengetik tanda kurung sudut sebagai nilai literal. Perintah tersebut memeriksa file core terhadap checksum rilis, bukan seluruh file di akun hosting. Baca setiap baris hasil, simpan output bersama catatan insiden, dan catat file yang hilang, tidak cocok, atau tidak dikenal. Jika pemeriksaan gagal karena versi atau locale tidak tepat, perbaiki parameter dan ulangi—jangan langsung mengunduh file baru untuk menutupi hasil awal.

Checksum yang cocok berarti file yang diperiksa cocok dengan referensi untuk versi dan locale tersebut. Itu tidak membuktikan bahwa tidak ada file tambahan di luar cakupan, bahwa database aman, atau bahwa situs tidak memiliki akses penyerang. Sebaliknya, file core yang berbeda pun belum otomatis berarti serangan: instalasi lama dapat memuat modifikasi sah, distribusi host dapat memberi patch, dan deployment bisa mengganti file. Cocokkan temuan dengan ticket perubahan dan sumber rilis sebelum memutuskan tindakan.

Cek plugin dengan batas yang sama jelasnya

Untuk plugin yang didistribusikan melalui WordPress.org, perintah wp plugin verify-checksums --all dapat membantu membandingkan file dengan checksum yang tersedia. Periksa dokumentasi WP-CLI plugin verify-checksums dan simpan output. Dukungan checksum tidak mencakup semua plugin premium, plugin internal, atau salinan yang dibeli langsung dari vendor. Pesan “checksum tidak tersedia” tidak sama dengan “file berbahaya”; itu berarti Anda memerlukan baseline lain.

Untuk plugin premium atau khusus, dapatkan paket rilis dari akun vendor atau repository organisasi melalui kanal yang diketahui. Pastikan nama produk, versi, hash paket bila disediakan, tanggal rilis, dan license/source memang cocok. Bandingkan dengan salinan yang disimpan pada deployment tepercaya, bukan dengan file unduhan dari situs yang sedang diselidiki. Jangan unggah kode privat atau backup pelanggan ke layanan pembanding publik tanpa izin.

Periksa juga tema aktif, child theme, mu-plugin, drop-in seperti object-cache, file wp-config.php, .htaccess, konfigurasi Nginx, aturan CDN, dan plugin yang menulis file secara sah. Komponen itu mungkin tidak tercakup oleh checksum core. Jika owner tidak memiliki baseline, dokumentasikan keterbatasan dan bandingkan dengan sumber bersih yang disetujui oleh maintainer atau host; jangan menetapkan bahwa setiap kustomisasi adalah malware hanya karena tidak ada di paket WordPress standar.

Bandingkan file tambahan tanpa mengandalkan tanggal saja

Bila paket bersih sudah dipastikan, lakukan perbandingan terarah pada salinan atau staging. Catat path relatif, ukuran, hash, pemilik file, permission, dan perbedaan isi. sha256sum dapat membantu mencatat fingerprint untuk perbandingan berulang, sedangkan alat diff dapat menunjukkan perubahan baris. Jangan menampilkan isi file konfigurasi yang berisi rahasia ke output yang dibagikan. Untuk file biner atau minified, gunakan hash dan alat yang sesuai; tampilan diff kosong atau tidak terbaca bukan bukti aman.

Timestamp tetap berguna sebagai petunjuk jika disandingkan dengan log deploy, backup, login, update otomatis, dan perubahan ownership. Tetapi waktu dapat berubah saat file diekstrak atau disalin, server bisa memakai zona waktu berbeda, dan pelaku bisa mengubah metadata. Jangan mengurutkan file berdasarkan tanggal saja lalu menghapus semua yang baru. Catat perbedaan waktu antara server, log, dan Search Console sebelum menyusun kronologi.

Periksa file tambahan pada direktori core, wp-content, root, dan lokasi yang dikelola host sesuai akses resmi. File baru bisa saja berupa cache, hasil update, konfigurasi host, atau alat operasional yang sah. Verifikasi dengan owner komponen dan log proses pembuatnya. Jangan menjalankan file yang dicurigai untuk “melihat isinya”; salin secara aman lalu minta spesialis memeriksa bila ada obfuscation, loader, atau kode yang dapat mengeksekusi perintah.

Putuskan: dokumentasikan, pulihkan, atau eskalasi

Kelompokkan hasil menjadi: cocok dengan rilis resmi; modifikasi sah yang memiliki owner dan ticket; perbedaan yang belum diketahui; file hilang; dan file tambahan yang tidak punya sumber terverifikasi. Untuk setiap item, tulis path, baseline, bukti yang mendukung, owner yang dimintai konfirmasi, risiko, serta keputusan. Jangan menandai file sebagai bersih hanya karena scanner tidak mengenalinya, dan jangan menghapus file hanya karena namanya acak.

Jika core atau plugin standar terbukti berubah tanpa persetujuan, pertimbangkan pemasangan ulang komponen bersih dari sumber resmi setelah salinan bukti dibuat dan entry point dikendalikan. Jangan menimpa file satu per satu jika perubahan dapat mengandung modifikasi lokal yang dibutuhkan; bandingkan terlebih dahulu dengan repository/deployment dan uji di staging. Bila plugin atau tema yang memuat backdoor, mengganti file tanpa menghapus akun, tugas terjadwal, atau konfigurasi pembuat ulang dapat menyebabkan file muncul lagi.

Jika yang berbeda adalah konfigurasi server, mu-plugin, theme khusus, atau nilai database, minta pemilik komponen dan host menilai dampaknya. Hentikan akses yang telah dipastikan tidak sah, perbaiki kerentanan yang ditemukan, dan rotasi kredensial yang mungkin terekspos dari perangkat bersih sesuai rencana insiden. Bila Anda tidak dapat membedakan perubahan sah dari injeksi, jangan melakukan cleanup produksi lewat tebakan; eskalasi ke administrator hosting atau profesional keamanan.

Verifikasi setelah pemulihan dan bangun baseline baru

Setelah komponen yang disetujui dipulihkan, jalankan kembali pemeriksaan checksum dengan versi dan locale yang sama. Bandingkan output sebelum dan sesudah; hasil yang berubah harus punya alasan dan ticket. Uji login admin, halaman publik, form, checkout bila ada, plugin yang penting, permission, scheduled tasks, dan respons pada path yang dilaporkan. Periksa log baru untuk melihat apakah file kembali berubah. Jika muncul lagi, cari proses penulisnya—jangan hanya mengulang reinstall.

Simpan baseline bersih yang memiliki owner, waktu, versi komponen, daftar file khusus, dan hash yang disepakati. Simpan backup offline/terpisah dan uji restore secara berkala pada lingkungan yang tidak publik. Terapkan update terencana, akun dengan hak minimum, akses host individual, dan pencatatan deployment. Baseline yang terdokumentasi membuat pemeriksaan berikutnya jauh lebih berguna daripada daftar timestamp tanpa konteks.

Pertanyaan yang sering ditanyakan

Apakah checksum yang cocok membuktikan website pasti bebas malware? Tidak. Itu hanya menyatakan file yang tercakup cocok dengan referensi checksum untuk versi dan locale tersebut. File tambahan, plugin premium, tema, uploads, database, akun, scheduled task, server, atau CDN memerlukan pemeriksaan terpisah.

Apakah file dengan timestamp baru pasti diubah penyerang? Tidak. Update, deploy, restore, ekstraksi, migrasi, dan sinkronisasi dapat mengubah waktu. Cocokkan dengan log, riwayat rilis, hash, dan owner perubahan.

Bolehkah saya mengganti semua file yang checksum-nya gagal? Jangan lakukan sebelum snapshot dan verifikasi sumber. Pastikan paket tepat, catat hasil, pertimbangkan kustomisasi, dan uji pemulihan pada salinan. Penggantian tidak menutup proses yang membuat file berubah.

Apa yang diperiksa jika checksum core dan plugin lulus tetapi gejala masih ada? Perluas pemeriksaan ke plugin/tema khusus, mu-plugin, uploads, konfigurasi server, database, akun, cron, cache/CDN, dan script pihak ketiga. Hasil checksum bukan audit menyeluruh.

Jika ada file yang kembali berubah, akun tidak dikenal, atau halaman berbahaya masih disajikan, minta bantuan respons keamanan website. Sertakan catatan versi, output checksum, waktu, dan langkah yang sudah diambil—tanpa mengirim password, token, atau dump pelanggan melalui kanal publik.