Zero-Day Bikin SOC-mu Panik? Ini Toolkit Incident Response Lengkap: Dari Sigma Rules Sampai Bypass WAF

CVE baru rilis pukul 23:47 WIB. Skor CVSS 9.8. Pre-auth RCE. Plugin yang dipakai 80.000+ situs WordPress. Tim SOC-mu dapat alert dari feed intelijen, tapi yang ada di dashboard cuma tulisan “update plugin sekarang.”

Masalahnya: update itu bukan incident response. Update mencegah serangan berikutnya, tapi nggak menjawab apakah serangan sudah terjadi sebelum patch terpasang. Di sinilah gap yang mematikan. Artikel generic cuma bilang “update now.” Tapi kamu perlu tahu: apa detection rules yang bisa langsung dipasang ke SIEM? Apa YARA rule untuk scan file system? Dan yang paling sering terlewat, teknik bypass WAF apa yang dipakai penyerang sehingga payload lolos dari filter?

Toolkit ini menjawab semuanya. Kita akan bangun dari layer terbawah ke teratas: IoC untuk identifikasi cepat, Sigma rules untuk alerting, YARA signatures untuk forensik, dan pemahaman WAF bypass yang bikin kamu bisa mengantisipasi serangan berikutnya.

Layer 1: Indicators of Compromise (IoC) yang Bisa Kamu Grep Sekarang Juga

Sebelum bicara Sigma rules dan SIEM, kamu butuh jawaban cepat: apakah server ini sudah kena? Berikut IoC spesifik yang bisa langsung kamu eksekusi lewat terminal. Tidak perlu setup ELK. Tidak perlu agent. Cukup SSH dan grep.

IoC Set 1: Access Log Artifacts

Zero-day modern hampir selalu masuk lewat HTTP request ke endpoint plugin. Pattern yang harus kamu cari di access log:

# 1. POST request ke endpoint mencurigakan dalam 7 hari terakhir
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

# 2. Request dengan status 200/201 ke path plugin tanpa Referer header
grep -E '(wp-json|admin-ajax)' /var/log/nginx/access.log | \
  grep -v 'Mozilla' | grep -E '" 20[01] ' | awk '{print $1, $4, $7}' | tail -30

# 3. Spike request: IP yang kirim >15 request per menit ke endpoint sama
awk '{print $1, substr($4,2,14)}' /var/log/nginx/access.log | \
  sort | uniq -c | awk '$1 > 15 {print}' | head -20

Kalau output baris ketiga menunjukkan IP dari VPS provider (DigitalOcean, Vultr, AWS) yang menghantam endpoint spesifik, itu indikasi kuat automated exploitation.

IoC Set 2: File System Anomalies

# 1. File PHP baru di folder uploads (backdoor paling umum)
find wp-content/uploads -name "*.php*" -type f -mtime -7 -ls

# 2. File dengan ekstensi mencurigakan
find . -type f \( -name "*.phtml" -o -name "*.shtml" -o -name "*.phar" -o -name "*.php5" \) -ls

# 3. File tersembunyi selain .htaccess
find . -name ".*" -type f -not -name ".htaccess" -not -path "*/.git/*" -ls

# 4. Modified files dalam 7 hari di folder wp-admin dan wp-includes
find wp-admin wp-includes -type f -mtime -7 -ls

IoC Set 3: Database Anomalies

-- 1. Admin user baru dalam 7 hari terakhir
SELECT ID, user_login, user_email, user_registered 
FROM wp_users 
WHERE user_registered > DATE_SUB(NOW(), INTERVAL 7 DAY)
ORDER BY user_registered DESC;

-- 2. Opsi mencurigakan di wp_options dengan value besar
SELECT option_name, LENGTH(option_value) AS val_size
FROM wp_options 
WHERE option_name NOT LIKE 'wp_%'
  AND option_name NOT LIKE 'siteurl'
  AND option_name NOT LIKE 'blogname'
  AND option_name NOT LIKE 'widget_%'
  AND option_name NOT LIKE 'theme_mods_%'
  AND LENGTH(option_value) > 200
ORDER BY option_id DESC LIMIT 20;

-- 3. Cek apakah ada plugin/tema yang baru aktif tanpa sepengetahuanmu
SELECT * FROM wp_options WHERE option_name = 'active_plugins';

Dengan tiga set IoC ini, kamu bisa mengonfirmasi dalam kurang dari 10 menit apakah ada indikasi kompromi. Kalau nggak ada yang triggered, lanjut ke layer berikutnya untuk deteksi proaktif.

Layer 2: Sigma Rules untuk SIEM dan Real-Time Detection

IoC di atas bersifat retrospektif. Kamu butuh deteksi real-time yang bisa langsung masuk ke SIEM (Splunk, Elastic, Wazuh, Graylog). Sigma rules adalah format standar yang bisa dikonversi ke query SIEM apa pun pakai sigmac.

Berikut tiga Sigma rules yang langsung bisa kamu pakai untuk zero-day WordPress. Rules ini men-target pola yang selalu muncul di pre-auth RCE: pemanggilan fungsi berbahaya via endpoint publik tanpa capability check.

Sigma Rule 1: Deteksi Pemanggilan wp_insert_user dengan Role Administrator dari IP Eksternal

title: WordPress Admin User Created via REST API from External IP
id: 8a3f1b2c-4d5e-6f7a-8b9c-0d1e2f3a4b5c
status: experimental
description: Detects wp_insert_user call with administrator role triggered by REST API request from non-internal IP
references:
  - https://hadezuka.dev/incident-response-toolkit-zero-day
author: Hadezuka SOC Team
date: 2026/06/06
tags:
  - attack.persistence
  - attack.t1136
logsource:
  category: application
  product: wordpress
detection:
  selection:
    event: 'user_register'
    role: 'administrator'
  filter_internal:
    src_ip:
      - '127.0.0.1'
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_internal
falsepositives:
  - Legitimate admin user creation via staging sync
level: high

Sigma Rule 2: Deteksi unserialize() Dipanggil dari Endpoint Publik

title: PHP unserialize() Called from Unauthenticated Endpoint
id: 9b4c2d3e-5f6a-7b8c-9d0e-1f2a3b4c5d6e
status: experimental
description: Detects unserialize() execution triggered by unauthenticated HTTP request
references:
  - https://hadezuka.dev/incident-response-toolkit-zero-day
author: Hadezuka SOC Team
date: 2026/06/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: application
  product: wordpress
detection:
  selection_endpoint:
    request_uri|contains:
      - '/admin-ajax.php'
      - '/wp-json/'
  selection_function:
    php_function: 'unserialize'
  filter_auth:
    has_session_cookie: 'true'
  condition: selection_endpoint and selection_function and not filter_auth
level: critical

Sigma Rule 3: Deteksi Command Execution via call_user_func_array Chain

title: Suspicious call_user_func_array with System Functions from Web Request
id: 0c5d3e4f-6a7b-8c9d-0e1f-2a3b4c5d6e7f
status: experimental
description: Detects when call_user_func_array is called with dangerous function name originating from HTTP request context
references:
  - https://hadezuka.dev/incident-response-toolkit-zero-day
author: Hadezuka SOC Team
date: 2026/06/06
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: application
  product: wordpress
detection:
  selection_dangerous:
    callback_function:
      - 'system'
      - 'exec'
      - 'shell_exec'
      - 'passthru'
      - 'popen'
      - 'proc_open'
  selection_context:
    request_method: 'POST'
  condition: selection_dangerous and selection_context
level: critical

Konversi rules ini ke format SIEM-mu dengan sigmac -t splunk -c splunk_config.yml sigma-rule.yml atau sigmac -t elastalert. Pasang sebagai alert priority critical supaya langsung masuk ke on-call SOC analyst.

Layer 3: YARA Signatures untuk File System Forensik

Setelah deteksi real-time berjalan, kamu perlu scan file system untuk artefak yang mungkin sudah tertanam sebelum rules aktif. YARA adalah standar de facto untuk pattern matching di file system. Berbeda dengan grep biasa, YARA rules bisa mendeteksi pattern yang tersebar di beberapa lokasi dalam satu file.

YARA Rule: Deteksi Backdoor PHP Pasca Zero-Day

rule ZeroDay_PHP_Backdoor_Generic {
    meta:
        description = "Detects common PHP backdoor patterns found after zero-day exploitation"
        author = "Hadezuka SOC Team"
        date = "2026-06-06"
        severity = "critical"
        tlp = "amber"
    strings:
        $fn1 = "system" nocase
        $fn2 = "shell_exec" nocase
        $fn3 = "passthru" nocase
        $fn4 = "eval" nocase
        $fn5 = "base64_decode" nocase
        $fn6 = "file_put_contents" nocase
        $fn7 = "move_uploaded_file" nocase
        $fn8 = "wp_insert_user" nocase
        $fn9 = "add_role" nocase
        $obf1 = "strrev" nocase
        $obf2 = "gzinflate" nocase
        $obf3 = "rot13" nocase
    condition:
        (2 of ($fn*)) or ($obf1 and $obf2) or ($obf3 and any of ($fn*))
}

YARA Rule: Deteksi WAF Bypass Payload yang Tersimpan

rule ZeroDay_WAF_Bypass_Stored_Payload {
    meta:
        description = "Detects WAF bypass payload patterns stored in database dumps or log files"
        author = "Hadezuka SOC Team"
        date = "2026-06-06"
        severity = "high"
    strings:
        $h1 = "multipart/form-data" nocase
        $h2 = "Content-Type: application/json" nocase
        $p1 = "\\u002e\\u002e" 
        $p2 = "/../../../" ascii
        $p3 = " 0 or $p4 or $p5)
}

Jalankan YARA scan dengan:

# Scan seluruh direktori WordPress
yara -r -s rules/zero-day-backdoor.yar /var/www/html/

# Scan spesifik folder uploads dan plugins
yara -r -s rules/zero-day-backdoor.yar \
  /var/www/html/wp-content/uploads/ \
  /var/www/html/wp-content/plugins/

Layer 4: Teknik Bypass WAF yang Dipakai Penyerang (dan Cara Kamu Mengantisipasinya)

Ini bagian yang paling sering terlewat dari artikel “update now.” WAF (Cloudflare, ModSecurity, Wordfence) memang memblokir banyak serangan generik. Tapi penyerang yang menarget zero-day spesifik nggak pakai payload generik. Mereka merancang payload yang khusus mem-bypass ruleset WAF yang umum dipasang.

Pahami dulu mindset-nya: WAF bekerja dengan pattern matching. Kalau kamu tahu pattern apa yang dicari WAF, kamu bisa mengubah payload supaya nggak dikenali. Inilah yang dilakukan penyerang zero-day.

Teknik 1: JSON Payload Obfuscation via Unicode Escape

Banyak WAF rules mencari string seperti administrator atau system secara literal di request body. Tapi kalau payload dikirim sebagai JSON dengan Unicode escape, string tersebut tidak muncul secara literal di wire format. Contoh:

# Payload normal yang terdeteksi WAF:
{"role": "administrator"}

# Payload dengan Unicode escape yang sering lolos:
{"role": "\u0061\u0064\u006d\u0069\u006e\u0069\u0073\u0074\u0072\u0061\u0074\u006f\u0072"}

PHP json_decode() akan men-decode Unicode escape ke string normal. Jadi aplikasi tetap menerima administrator, tapi WAF cuma melihat deretan karakter \uXXXX yang tidak memicu pattern match apapun. Mitigasi: Konfigurasikan WAF untuk men-decode dan men-scan nilai JSON yang sudah di-decode, bukan raw body. Untuk Cloudflare, aktifkan JSON parsing di WAF settings.

Teknik 2: Multipart Boundary Injection

Banyak WAF ruleset hanya memeriksa body dengan Content-Type application/x-www-form-urlencoded atau application/json. Penyerang bisa mengganti Content-Type ke multipart/form-data dengan boundary custom, lalu menyisipkan payload di dalam salah satu part. WAF sering mengabaikan body multipart kalau ruleset-nya nggak dikonfigurasi untuk parsing multipart.

# Request yang bisa bypass WAF ruleset standar:
POST /wp-admin/admin-ajax.php HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

------WebKitFormBoundary
Content-Disposition: form-data; name="action"

process_cache
------WebKitFormBoundary
Content-Disposition: form-data; name="cache_data"

O:13:"Cache_Handler":2:{s:8:"callback";s:6:"system";...}
------WebKitFormBoundary--

Mitigasi: Pastikan WAF ruleset-mu meng-cover semua Content-Type, bukan cuma JSON dan URL-encoded. Untuk ModSecurity, aktifkan SecRule MULTIPART_STRICT_ERROR. Untuk Cloudflare, gunakan custom rule dengan condition http.request.body tanpa filter Content-Type.

Teknik 3: Double Encoding dan Nested Serialization

WAF rules sederhana mencari O:13:"Cache_Handler" atau administrator sekali scan. Penyerang bisa melakukan double URL-encoding atau nested serialization untuk menyembunyikan pattern:

# Single encoding (terdeteksi):
O%3A13%3A%22Cache_Handler%22

# Double encoding (sering lolos):
O%253A13%253A%2522Cache_Handler%2522

# Nested serialization (payload dibungkus serialized string lagi):
a:1:{s:4:"data";s:XXX:"O:13:...";}

PHP secara otomatis men-decode URL encoding sebelum memproses input. Kalau WAF nggak melakukan recursive decoding, payload lolos. Mitigasi: Aktifkan normalization di WAF engine. ModSecurity punya directive SecDefaultAction dengan t:none,t:urlDecodeUni,t:htmlEntityDecode. Cloudflare WAF otomatis melakukan normalization, tapi verifikasi dulu di dashboard.

Menggabungkan Empat Layer: Workflow Incident Response 30 Menit

Berikut adalah alur kerja yang bisa langsung kamu terapkan begitu CVE kritis terbit. Waktu target: 30 menit dari alert ke konfirmasi status.

1. Menit 0-5: Jalankan tiga set IoC (access log, file system, database) di atas. Kalau ada yang triggered, langsung masuk mode containment.
2. Menit 5-10: Konversi tiga Sigma rules ke format SIEM-mu pakai sigmac. Pasang sebagai alert real-time dengan priority critical.
3. Menit 10-15: Jalankan YARA scan di folder uploads, plugins, dan themes. Catat setiap hit sebagai artefak forensik.
4. Menit 15-20: Review WAF logs untuk mencari request dengan Content-Type alternatif, Unicode escape, atau double encoding yang mungkin lolos.
5. Menit 20-25: Kalau ada IoC positif, baca panduan pemulihan darurat. Kalau bersih, tetap deploy virtual patch lewat WAF sementara menunggu update.
6. Menit 25-30: Dokumentasikan semua temuan di incident report. Timeline, IoC yang ditemukan, action yang diambil.

Workflow ini sudah dipakai oleh tim SOC managed hosting kami. Baca juga panduan kami sebelumnya tentang 7 pola log forensik untuk deteksi pre-patch compromise yang membahas IoC lebih mendalam, dan teknik virtual patching lewat WAF untuk mitigasi sementara.

Kesimpulan: Jangan Cuma Update, Bangun Toolkit-mu Sendiri

Artikel “update now” akan selalu ada setiap kali CVE terbit. Tapi kamu yang bekerja di SOC, managed hosting, atau mengelola puluhan situs WordPress tahu bahwa update adalah langkah terakhir, bukan langkah pertama. Langkah pertama adalah menjawab: apakah kita sudah kena?

Toolkit di artikel ini bisa jadi template yang kamu modifikasi untuk setiap CVE baru: ganti endpoint path, ganti parameter yang diinjeksi, ganti class gadget chain yang tersedia. Framework-nya tetap sama. Dan dengan empat layer yang sudah kita bangun, kamu nggak cuma bisa mendeteksi kompromi, tapi juga memahami bagaimana penyerang mem-bypass pertahanan yang sudah ada.

Untuk referensi teknis lebih lanjut: Sigma Rules Repository untuk koleksi rules tambahan, YARA Documentation untuk penulisan rules lanjutan, dan OWASP ModSecurity CRS untuk baseline WAF ruleset yang bisa kamu perkuat.

FAQ: Incident Response Toolkit untuk Zero-Day WordPress