Playbook Incident Response: 6 Langkah Darurat Saat Situs Dihack

Satu malam, pukul 02:14. Notifikasi panic masuk di Slack: “Situs cuma menampilkan iklan Crypto mining”. CPU di server melonjak ke 100%. Google Search Console mulai kirim alert “Malware detected”.

Insting pertama: hapus file mencurigakan, restore backup, install Wordfence. Itu wajar. Tapi itu juga yang paling berbahaya. Restore terlalu cepat bisa mengembalikan backdoor yang sama. Hapus file sebelum dicatat adalah penghilangan bukti forensik. Install plugin di tengah insiden bisa bahkan memperlebar akses penyerang.

Playbook incident response yang terstruktur berbeda. Urutan ada alasan Olsen & profundis. Pola yang terbukti efektif diSOC profesional:

Fase 0: Kenali Framework Incident Response

Banyak framework: NIST 800-61 rev.2, SANS IR, P3R (Prepare-Plan-Practice). Untuk situs WordPress dan server median, saya custom:

• Preparation: tools, access, communication plan.
• Detection & Analysis: “apakah kita sudah kena?”
• Containment: “bekukan kerusakan, jangan biarkan expand”.
• Eradication: “hapus root cause, bukan cuma gejala”.
• Recovery: “kembalikan layanan dengan aman”.
• Post-Incident: “postmortem, improve kontrol”.

Artikel ini berfokus pada fase Detection through Recovery. Preparation Anda harus udah ada: akses server, backup terverifikasi, contact list hosting provider.

Fase 1: Detection & Analysis – “Apa Yang Terjadi?”

Banyak admin langsung clean tanpa konfirmasi. Kesalahan fatal. Pertama: verifikasi apakah ini compromised atau false positive.

Langkah 1: Quick Triage dalam 10 Menit

• Check CPU/Memory: spikes берәләмлесе.
• Check access log: POST aneh ke wp-admin, wp-json, xmlrpc, admin-ajax.
• Scan file system: PHP file baru di wp-content/uploads.
• Check database: admin user baru di wp_users.
• Check wp_options: auto_prepend_file, suspicious option.

Gunakan command satu-liner:

# POST request异常 di access.log (last 24h)
grep -E '"POST' /var/log/nginx/access.log | grep -E '(wp-json|admin-ajax|xmlrpc)' | awk '{print $1, $4, $7}' | sort | uniq -c | sort -rn | head -20

# PHP file di uploads (likely backdoor)
find wp-content/uploads -name "*.php*" -type f -mtime -3 -ls

# Admin user baru (7 hari terakhir)
mysql -u root -p -e "SELECT ID, user_login, user_registered FROM wp_users WHERE user_registered > DATE_SUB(NOW(), INTERVAL 7 DAY) ORDER BY user_registered DESC;"

# wp_options dengan auto_prepend_file (PHP auto include)
mysql -u root -p -e "SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%auto_prepend_file%' OR option_value LIKE '%base64_decode%' OR option_value LIKE '%eval%' LIMIT 10;"

Kalau salah satu di atas terpicu, stop. Jangan lanjut ke cleanup. Masih di fase detection.

Langkah 2: Build Evidence Timeline

Buat timeline serangan dari semua IoC yang ditemukan. Gabungkan:

• Access log: kapan POSTerste payload?
• File timestamp: kapan backdoor dibuat?
• Database: kapan admin user ditambahkan?
• System logs: kapan cron job baru dibuat?

Korelasi waktuذا清晰地 menunjukkan chain of exploitation. Contoh:

[02:14:32] POST /wp-json/plugin/v1/upload dari IP 45.xxx
[02:14:35] File wp-content/uploads/2026/07/a7b3c.php created
[02:15:10] wp_users: user 'support_sys' registered
[02:15:45] auto_prepend_file option added di wp_options

Dengan timeline, kamu tahu:

• Vektor masuk: plugin upload vulnerability
• Backdoor terunggah: a7b3c.php
• Persistensi: auto_prepend file di wp_options
• IP attacker: 45.xxx

Ini adalah akte akta keterangan pelanggaran. Jangan直到 ini selesai sebelum containment.

Fase 2: Containment – “Bekukan, Jangan Biarkan Jangkauan Lebih Luas”

Banyak admin lali: langsungg False. Containment bukan cleaning. Containment adalah isolasi.

• Isolasi server: maintenance mode, firewall block public IP, atau migrasi ke temporary server.
• Blokir vektor aktif: nonaktifkan plugin rentan (segera setelah tahu mana), blokir endpoint upload di WAF.
• Batas akses admin: WP-CLI only, atau IP whitelist wp-admin dan wp-login.
• Preserve evidence: JANGAN HAPUS FILE. Ambil snapshot server, dump database, tar log files ke encrypted storage.
• Revoke session: force logout semua user via wp-cli wp user session destroy –all.

Command untuk blokir via firewall (cloudflare atau server-level):

# UFW (Ubuntu)
ufw insert 1 deny from 45.xxx
ufw status numbered

# iptables
iptables -I INPUT -s 45.xxx -j DROP

# Cloudflare API (block IP)
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/firewall/rules" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{"paused":false,"description":"Block attacker IP","filter":{"expression":"ip.src eq 45.xxx"},"action":"block"}'

Fase 3: Eradication – “Hapus Root Cause, Bukan Cuma Gejala”

Setelah evidence terebut dan situs terisolasi, baru eradication. Aturan:

• Jangan pakai aplikasi web untuk hapus file (bisa dieksekusi oleh backdoor lagi).
• Gunakan WP-CLI atau akses filesystem langsung.
• Verify checksums core WordPress: wp core verify-checksums.
• Reinstall semua plugin dan theme dari source resmi.
• Hapus plugin/theme yang tidak aktif.
• Ganti semua password dan salt (Fase 4 recovery ganti dulu, baru reinstall).

Command eradication:

# Hapus file PHP mencurigakan di uploads (dapatkan list dulu!)
find wp-content/uploads -name "*.php" -type f -exec ls -la {} \;

# Setelah dapat list, hapus satu per satu dengan catat
find wp-content/uploads -name "*.php" -type f -delete

# Reinstall plugin dari resmi (contoh untuk akismet)
wp plugin delete akismet
wp plugin install akismet --activate

# Hapus user admin asing
wp user delete 123 --reassign=1  # redirect ke user 1

# Hapus option mencurigakan (contoh: _transient_...)
wp option delete suspicious_option_name

# Verify core checksums (file modified di core)
wp core verify-checksums

Fase 4: Recovery – “Kembalikan Layanan Dengan Aman”

Recovery bukan sekadar restore backup. Recovery adalah:

• Rotasi kredensial: semua password admin, database user, FTP/SFTP, hosting panel, API keys, SMTP credential.
• Update everything: core, plugin, theme dari source resmi.
• Harden: nonaktifkan file editing, limit login attempts, disable XML-RPC jika tidak dipakai, block PHP execution di uploads via .htaccess.
• Monitor: aktifkan audit log, security plugin dengan real-time alert, file integrity monitoring.
• Go live: setelah validasi penuh, buka maintenance mode,clear cache.

.htaccess rule untuk block PHP di uploads:

<Files *.php>
  deny from all
</Files>

Fase 5: Post-Incident – “Jangan Sampai Kembali Terjadi”

Postmortem harus documented. Template minimal:

• Summary dan timeline deteksi hingga recovery.
• Root cause: vektor masuk apa? (plugin rentan? credential poisoning? misconfig?)
• Blast radius: data apa yang terekspos? (user PII, order, API keys?)
• Technical findings: artifacts yang ditemukan (file, IP, user).
• Action items: perbaikan jangka pendek dan panjang.
• Owner dan deadline.

Contoh action item:

• Deploy WAF custom rule untuk endpoint upload plugin X.
• Implementation mandatory MFA untuk wp-admin.
• Setup centralized logging dengan retention 90 hari.
• Implement file integrity monitoring (AIDE atau Tripwire).
• Review dan rotation API keys semua layanan third-party.

Counter-Intuitive Insight: Jangan Restore Sebelum Timeline Selesai

Ini adalah pervasive mistake. Ketika panic, restoring backup terasa like magic solution. Tapi kalau backup-created setelah attacker sudahestablished persistent? Kamu justh restore backdoor juga.

Profesional SOC approach: backup sebelum restore. Tar semua log, file, database ke encrypted storage. Baru lakukan restore dari backup yang terverifikasi clean, ideally dari sebelum earliest IoC timestamp.

It's tempting to skip forensic. Tapi evidence preservation Determine apakah Anda perlu breach notification (GDPR, PDP), dan lessons learned untuk pencegahan masa depan.

Checklist 60 Menit Incident Response

• 0-10 min: isolasi, block IP, preserve logs, quick triage.
• 10-20 min: collect evidence, timeline build, identifikasi vektor.
• 20-40 min: eradication dengan WP-CLI, hapus backdoor, cleanup wp_options.
• 40-50 min: credential rotation, updates, harden.
• 50-60 min: validation, monitoring setup, postmortem template.

Baca juga: Toolkit Incident Response untuk Zero-Day: Sigma Rules, YARA, WAF Bypass, dan Playbook 60 Menit untuk WordPress Hosting Compromised.

External References

• NIST SP 800-61 Rev.2: Computer Security Incident Handling Guide
• SANS Incident Handler's Handbook
• OWASP: Incident Response

FAQ: Incident Response Playbook untuk WordPress