Kamu sudah update semua plugin. Theme juga sudah versi terbaru. Dashboard bersih, nggak ada notifikasi aneh. Tapi dalam hati, rasa nggak tenang masih nongol. Kenapa? Karena WP2Shell baru saja lewat, dan lu tahu persis: patching bukan berarti bersih.
Masalahnya Bukan Patch, Tapi Verifikasi
Banyakan engineer fokus ke prevention. Install WAF, hardening wp-config, batasi file permission. Semuanya benar. Tapi setelah insiden WP2Shell, pertanyaan kritis yang jarang ditanyakan: bagaimana caranya yakin file plugin dan tema lu benar-benar sama persis dengan versi official?
WP2Shell itu eksploitasi supply chain. Dia nggak cuma inject webshell. Dia bisa modify file plugin/tema yang legitimate, nambah backdoor di dalam kode yang tampak normal. Scan malware biasa nggak akan ketemu karena file-size nggak berubah drastis, dan signature-based scanner buta terhadap modifikasi halus.
Tiga Kenapa Verifikasi Standar Gagal
1. Checksum WordPress.org hanya untuk core. Plugin dan tema di repository punya checksum, tapi sekali lu install, file bisa berubah lewat auto-update, file editor, atau supply chain attack. Lu nggak punya baseline trusted untuk bandingin.
2. Git history bukan bukti integritas runtime. Commit hash di GitHub nggak menjamin file di server production sama. CI/CD bisa compromised, artifact bisa di-swap pas deploy, atau attacker modify langsung di server lewat file manager.
3. Scanner signature-based buta terhadap living-off-the-land. WP2Shell nggak drop file baru yang mencolok. Dia modify fungsi existing, inject eval() di dalam fungsi legitimate, atau nambah hook yang tampak wajar. YARA rules butuh IOC spesifik, dan IOC baru keluar setelah damage done.
Framework Verifikasi Integritas 4-Lapis (Post-WP2Shell)
Ini bukan teori. Ini workflow yang lu bisa implement hari ini, tanpa beli tool enterprise.
Lapisan 1: Baseline Checksum Immutable
Sebelum deploy ke production, generate SHA-256 untuk setiap file plugin dan tema. Simpan di artifact store yang read-only (bisa S3 dengan Object Lock, atau GitHub Release dengan sigstore/cosign).
# Generate baseline checksums
find wp-content/plugins wp-content/themes -type f -name \”*.php\” -o -name \”*.js\” -o -name \”*.css\” | \
xargs sha256sum > baseline-checksums.txt
# Sign with cosign (keyless, OIDC)
cosign sign-blob –yes baseline-checksums.txt
# Verify later
cosign verify-blob baseline-checksums.txt
Ponytail: Baseline ini harus dibuat di environment trusted (local machine atau CI runner yang lu kontrol penuh), bukan di server production.
Lapisan 2: Runtime File Integrity Monitoring (FIM) Real-time
Weekly scan itu terlalu lambat. WP2Shell bisa tanam backdoor dalam menit. Lu butuh FIM yang monitor setiap write ke wp-content/plugins dan wp-content/themes.
– Wazuh / OSSEC – open source, support real-time FIM, rules untuk WordPress sudah ada
– Auditd (Linux native) – ringan, no agent, tapi butuh tuning rule supaya nggak kebanjiran noise
– Falco / Sysdig – kernel-level, deteksi execve, open/write ke path sensitif
# Auditd rule example untuk WordPress
-w /var/www/html/wp-content/plugins -p wa -k wp_plugin_change
-w /var/www/html/wp-content/themes -p wa -k wp_theme_change
Lalu monitor ausearch -k wp_plugin_change
Alert ke Slack/Telegram/Email saat ada write ke path-plugin/tema yang nggak lewat deployment pipeline lu.
Lapisan 3: Differential Diff Against Baseline
FIM kasih tau ada perubahan. Diff kasih tau apa yang berubah. Schedule diff harian (atau per 6 jam untuk high-value site) terhadap baseline checksum.
#!/bin/bash
# diff-integrity.sh – Jalankan via cron
BASELINE=\”s3://bucket/baseline-checksums.txt\”
CURRENT=\”/tmp/current-checksums.txt\”
find wp-content/plugins wp-content/themes -type f \\( -name \”*.php\” -o -name \”*.js\” -o -name \”*.css\” \\) | \
xargs sha256sum > \”$CURRENT\”
# Bandingin
diff -u <(sort \"$BASELINE\") <(sort \"$CURRENT\") | \
grep -E \"^[-+]\" | grep -v \"^[-+]{3}\" | \
tee /var/log/wp-integrity-diff.log
# Alert kalau ada diff
if [ ${PIPESTATUS[0]} -ne 0 ]; then
curl -X POST \"$WEBHOOK_URL\" -d \"WP Integrity diff detected on $(hostname)\"
fi
Output diff ini jadi bukti forensik. Lu lihat persis fungsi mana yang di-inject, baris mana yang di-modify.
Lapisan 4: Behavioral Anomaly Detection
Ini lapisan terakhir kalau attacker berhasil bypass tiga lapisan di atas (misal: attacker modify file, lalu update baseline checksum juga - supply chain attack penuh).
- PHP function calls aneh: eval, assert, create_function, base64_decode, gzinflate di file plugin/tema yang nggak seharusnya pakai fungsi ini
- Network connection keluar: PHP process konek ke IP external (C2 beaconing)
- Cron job aneh: wp_cron entries yang nggak dari plugin legitimate
- User admin baru: INSERT ke wp_users role administrator tanpa aktivitas login normal
Tools: WP Activity Log (untuk audit trail), custom PHP wrapper yang log dangerous function calls, atau Falco rules untuk PHP execve anomaly.
Checklist Verifikasi Praktis (Copy-Paste ke Notion/Obsidian)
1. Pre-deploy: Generate + sign checksum baseline untuk semua plugin/tema
2. Deploy: Hanya lewat CI/CD pipeline yang verified (signed artifact)
3. Runtime: Enable auditd/Wazuh FIM di wp-content/plugins & themes
4. Daily: Automated diff terhadap baseline, alert ke channel tim
5. Weekly: Review behavioral anomalies (dangerous PHP functions, outbound conn, cron, user)
6. Post-incident: Full diff + timeline reconstruction dari FIM logs
Integrasi dengan Existing Stack
Lu nggak perlu ganti seluruh stack. Tambahkan:
- SIEM (Splunk, Elastic, Graylog): Forward auditd/Wazuh logs, bikin dashboard \"WP File Changes\"
- SOAR (Cortex XSOAR, n8n, Tines): Auto-quarantine file yang diff-an, rollback ke baseline via git/artifact store
- Ticketing (Jira, GitLab Issues): Auto-create ticket saat diff detected, assign ke security engineer
FAQ
Apakah perlu verifikasi untuk plugin premium yang nggak di repository WordPress.org?
Ya, justru lebih kritis. Plugin premium nggak punya checksum public. Lu harus minta vendor provide signed release artifact (cosign/slsa), atau lu generate baseline sendiri saat pertama kali beli/install. Simpan baseline itu sacred.
Bagaimana cara handle false positive dari auto-update plugin?
Whitelist proses update legitimate. Di auditd, exclude PID dari package manager (apt/dnf) atau WP CLI update process. Atau lebih simpel: disable auto-update di production, update hanya lewat CI/CD pipeline yang lu kontrol, lalu regenerate baseline setelah update.
Berapa biaya implementasi framework ini?
Rp 0. Semua tools (auditd, Wazuh, cosign, bash) open source. Biaya cuma waktu engineer untuk setup awal (~2-4 jam) dan maintenance bulanan (~30 menit review diff). Bandingin dengan biaya insiden: downtime, reputasi, forensic, legal.
Kesimpulan
WP2Shell ngajarin satu hal keras: trust tapi verify nggak cukup. Lu butuh verify continuously. Patch itu lapisan pertama. Verifikasi integritas file plugin dan tema itu lapisan yang nggak bisa di-skip, apalagi pasca-insiden supply chain attack.
Mulai dari baseline checksum hari ini. Nggak perlu perfect. Cukup generate SHA-256 untuk folder plugins dan themes, simpan di tempat aman, lalu schedule diff harian. Itu saja sudah narikin 80% risiko modifikasi file tak terduga.
Lu punya pengalaman verifikasi integritas pasca-hack? Share di komentar. Atau kalau butuh bantu setup Wazuh/Falco rules untuk WordPress, dm aja.
