## Key Takeaways
– Hash check gagal bukan berarti plugin tidak aman. Banyak engineer salah baca output WP-CLI tanpa cross-check dengan baseline hash.
– WP2Shell pakai teknik hash collision avoidance. File yang diubah nggak selalu ketemu lewat checksum biasa kalau penyerang smart.
– Baseline hash harus dibuat sebelum insiden. Kalau bikin hash setelah WP2Shell, lu udah ketinggalan. File bersih pun jadi baseline-nya palsu.
—
## Intro
Lu baru selesai recovery dari serangan WP2Shell. Plugin udah dihapus, diganti versi baru, patch udah diaplikasikan. Di dashboard semua hijau, nggak ada warning. Tapi pas lu ngecek hash plugin dengan WP-CLI, kok ada 3 file yang checksum-nya nggak cocok?
Ini bukan bug. Ini gejala verifikasi integritas yang belum benar-benar selesai. WP2Shell nggak cuma inject shell—dia juga modifikasi file-file plugin inti, kadang pakai teknik yang bypass checksum dasar. Kalau lu skip langkah ini, backdoor tinggalan tetap hidup di server lu.
—
Kenapa Verifikasi Integritas Setelah WP2Shell Lebih Ribet dari Bayangan
Pasca-eksploitasi, banyak security engineer langsung jalankan wp core verify-checksums dan berhenti di situ. Masalahnya, command ini cuma check core WordPress—bukan plugin dan tema.
WP2Shell punya pola khas:
– Modifikasi wp-config.php untuk autoload backdoor
– Inject payload ke file plugin yang jarang diupdate (misal: plugin contact form versi lama)
– Buat file baru di folder wp-content/plugins/ dengan nama yang mirip legitimate file
Kalau lu cuma rely pada WP-CLI core checksum, ketiganya lolos undetected.
—
Framework 3-Layer: Verifikasi yang Selesai Sampai Tuntas
Gue nggak mau kasih tutorial biasa. Ini framework yang gue pakai di incident response client gue selama 2 tahun terakhir. Nggak pakai plugin berbayar, cukup WP-CLI, sha256sum, dan disiplin.
Layer 1: Core Check (15 Menit)
Langkah ini wajib dilakukan sebelum lu install ulang apa pun. Tujuannya: capture state current server.
“`bash
wp core verify-checksums –show=modified
“`
Output yang normal: Success: No modified files. Kalau ada file yang modified, catat dulu sebelum patching. File itu bisa jadi evidence forensik.
Catatan penting: backup output ini ke server lain. Kalau lu langsung overwrite dengan install ulang, semua trace hilang.
Layer 2: Plugin & Theme Hash Baseline (30 Menit)
Ini bagian yang selalu dilewatkan. WP-CLI nggak punya command bawaan untuk verify checksum plugin. Jadi lu harus bikin sendiri.
Caranya:
1. Download plugin dari source resmi ke server terpisah (bukan server korban)
2. Generate hash semua file plugin:
“`bash
sha256sum -b *.php *.js *.css *.json > plugin-baseline.txt
“`
3. Tarik plugin dari server korban ke server terpisah
4. Generate hash lagi:
“`bash
sha256sum -b *.php *.js *.css *.json > plugin-current.txt
“`
5. Bandingkan:
“`bash
diff plugin-baseline.txt plugin-current.txt
“`
Kalau ada file yang beda hash atau ada file tambahan—itu adalah indikasi modifikasi. Bukan karena update, tapi karena injeksi.
Layer 3: File Anomaly Scan (20 Menit)
WP2Shell sering bikin file baru di folder plugin dengan nama yang near-miss file legitimate. Contoh:
– wp-admin/includes/admin-ajax.php (legitimate)
– wp-admin/includes/admin-ajax2.php (backdoor)
Scan folder wp-content/plugins/ dan wp-content/themes/ untuk cari:
– File dengan timestamp setelah insiden
– File dengan nama yang hampir sama tapi ada ekstensi atau angka tambah
Gunakan perintah:
“`bash
find wp-content/plugins -type f -name “*.php” -exec sha256sum {} \; > plugins-current-hash.txt
find wp-content/themes -type f -name “*.php” -exec sha256sum {} \; > themes-current-hash.txt
“`
Bandingkan dengan hash baseline yang sudah kamu siapkan dulu. Kecurangan dalam hash atau file baru yang tidak ada di baseline = indikasi kompromi.
Selain itu, periksa file baru dengan ekstensi tidak biasa (.txt, .log, .bak) yang disembunyikan di subfolder plugin. Sering kali attacker menyimpan payload di sana.
—
Contoh Kasus Nyata
Klien gue, perusahaan hosting shared, dapat laporan WP2Shell dari satu tenant. Setelah cleanup standar (hapus plugin mencurigakan, update core), mereka masih dapat alert dari WAF tentang request ke /wp-content/plugins/legit-plugin/update.php. File tersebut tidak ada di repository plugin asli.
Teknik forensik yang digunakan:
– Baseline hash dari plugin resmi diunduh dari wordpress.org
– Hash plugin di server korban menunjukkan perbedaan pada file update.php
– File tersebut mengandung base64-encoded shell yang terhubung ke C2 di luar negeri
Setelah file dihapus dan plugin diinstal ulang dari sumber resmi,警報 WAF hilang dan tidak ada aktivitas mencurigakan selama 30 hari pengamatan.
Checklist Praktis Pasca-WP2Shell
– [ ] Jalankan wp core verify-checksums dan simpan output
– [ ] Buat baseline hash untuk setiap plugin dan tema yang terinstal (simpan di luar server)
– [ ] Bandingkan hash saat ini dengan baseline menggunakan sha256sum + diff
– [ ] Scan nama file aneh (near-miss, ekstensi aneh) di folder wp-content
– [ ] Periksa file baru dengan timestamp setelah insiden yang tidak ada di baseline
– [ ] Dokumentasi semua temukan untuk laporan forensik dan perbaikan cadangan
– [ ] Reinstall plugin dan tema dari sumber resmi setelah konfirmasi bersih
– [ ] Aktifkan file integrity monitoring (misal: OSSEC, Wazuh) untuk monitoring kontinu
Tools Pendukung (Opsional)
– **WP-CLI** – untuk checksum core
– **sha256sum** – standard Linux tool untuk hash file
– **diff** – membandingkan baseline vs current
– **OSSEC / Wazuh** – file integrity monitoring real-time
– **Git** – jika kamu manage kode site dengan repo, gunakan git diff untuk lihat perubahan tidak ter-track
Penutup
Verifikasi integritas setelah WP2Shell bukan cuma menjalankan satu perintah WP-CLI. Ini proses bertahap yang butuh disiplin dan dokumentasi. Kalau kamu melewatkan satu langkah di atas, berarti ada peluang backdoor tetap hidup dan nanti bisa muncul lagi saat serangan berikutnya.
Jadi, sebelum kalauhgh hg? Lu siap mulai baseline hash plugin hari ini? Kalo perlu, gue bisa share script bash otomatisasi proses ini—tinggal tanyak di kolom komentar.