Kritik bir WordPress RCE zincirinin ardından, Linux tabanlı bir web sunucusunda MDE'nin varsayılan koruma profiliyle neyi kaçırdığını ve bunun yerine ne yazmamız gerektiğini gerçek bir lab testiyle gösteriyoruz.
Yönetici Özeti
17 Temmuz 2026'da WordPress Core için yayınlanan CVE-2026-63030 (REST API batch endpoint route confusion) ve CVE-2026-60137 (WP_Query SQL injection), zincirlendiğinde kimlik doğrulamasız RCE'ye çıkıyor. Sektörde "wp2shell" olarak adlandırılıyor. Bu yazıda, zafiyetin post-exploitation davranışını izole bir lab'de simüle edip Microsoft Defender for Endpoint'in (Linux) bunu varsayılan koruma profiliyle yakalayıp yakalamadığını test ettik. Sonuç net: MDE, en sıkı koruma ayarlarıyla bile bu davranışı alarm olarak üretmedi. Süreçler telemetride eksiksiz duruyordu, ama hiçbiri bir incident'a dönüşmedi. Kendi yazdığımız Advanced Hunting sorguları aynı olayları anında yakaladı. Yazının geri kalanı bu sorguları ve neden gerekli olduklarını anlatıyor.
Zafiyet Mekanizması
CVE-2026-60137 tek başına yalnızca kimliği doğrulanmış bir kullanıcıyı ilgilendiren bir SQL injection (WP_Query'nin author__not_in parametresi). CVE-2026-63030 ise REST API batch endpoint'inde bir route confusion ve asıl kritik nokta burada: bu confusion, SQLi'yi authenticated kullanıcıya kısıtlayan blocklist'i bypass ediyor. Zincirlendiğinde: anonim istek → SQLi ile admin parola hash'i sızdırma → kırma/giriş → webshell yükleme. Etkilenen sürümler 6.9.0-6.9.4 ve 7.0.0-7.0.1; yama 6.9.5 ve 7.0.2'de. Yayıncı taraf hiçbir sabit webshell hash'i veya dosya adı vermedi — bu, tespitin en başından itibaren davranışa dayanması gerektiği anlamına geliyor.
Etkilenen sürümler
- WordPress 6.9.0 - 6.9.4
- WordPress 7.0.0 - 7.0.1
Yamalı sürümler
- WordPress 6.9.5
- WordPress 7.0.2
Test Ortamı
İzole bir sanal ortamda savunmasız sürüm aralığında bir WordPress kurulumu ayağa kaldırdık (Ubuntu + Apache/PHP-FPM), cihaza MDE for Linux sensörünü kurduk. Test üç aşamada ilerledi:
- Politika ataması yokken (sensör varsayılan ayarlarla)
- En sıkı koruma profili uygulandıktan sonra (real-time protection + cloud-delivered protection + PUA koruması maksimumda).
- Kendi yazdığımız Advanced Hunting sorgularıyla.
Her aşamada aynı senaryoyu tekrarladık: wp-content/uploads altına bir PHP webshell düşürdük ve üzerinden whoami, id, uname -a, curl, python3 gibi keşif/indirme komutları çalıştırdık.
Canlı Test Sonuçları
Aşama 1 ve 2: Hiçbir koruma profilinde alarm üretilmedi. Timeline/telemetri tarafında süreçler eksiksiz görünüyordu; php-fpm/apache2'nin child process olarak sh, sonra whoami/curl/python3 ama bu hiçbiri incident olarak düşmedi. En sıkı ayarla test tekrarlandığında da sonuç değişmedi.
Bunun nedeni ürün açığı değil, mimari bir sınır: Linux ajanının koruma profili büyük ölçüde dosya tabanlı; real-time protection ve cloud-delivered protection, diske yazılan zararlı dosyayı imza/bulut itibarıyla yakalamaya çalışıyor. Ama burada webshell'in kendisi (<?php system($_GET[...]); ?>) kötü niyetli bir imza taşımıyor, sıradan bir PHP dosyası gibi görünüyor. Asıl kötü niyetli olan şey dosyanın içeriği değil, o dosyanın tetiklediği süreç zinciri ve bu sınıf davranışsal korelasyonu Windows tarafında ASR/EDR motorunun yaptığı derinlikte Linux ajanında karşılığı yok. Yani "sıkı politika" burada yanlış kaldıraç; koruması gereken katman zaten farklı bir mekanizma gerektiriyor.
Aşama 3: Kendi sorgularımız. Aynı üç komut dizisini, aşağıdaki iki Advanced Hunting sorgusuna karşı çalıştırdık; ikisi de olayları anında yakaladı.
MDE Tarafında Sorgular
Lab testinde dosya sorgusunu belirli bir yola (/var/www/wp2shell/wp-content/uploads) sabitlemiştik; yukarıdaki sürüm bunu genelleştiriyor çünkü kurumdan kuruma WordPress kök dizini değişir (/var/www/html, /srv/www, özel bir vhost yolu vb.) — wp-content/uploads alt yolu göreli olarak sabit kaldığı için hangi kökte olursa olsun yakalıyor.
Prod'a taşımadan önce bir uyarı: Bu iki sorguyu olduğu gibi bir Custom Detection Rule'a çevirmeden önce, süreç sorgusunu bir kez ham haliyle canlı bir ortamda çalıştırın. Windows tarafında aynı mantığı (w3wp.exe/php.exe → cmd.exe) gerçek bir müşteri ortamında test ettiğimizde, 30 günde binlerce satır döndüğünü ve bunun neredeyse tamamının farklı iç uygulamaların (lisans/donanım kontrolü, zamanlanmış rapor işleri) rutin wmic/tasklist çağrıları olduğunu gördük, gerçek tehdit sıfırdı. Linux tarafında da aynı risk var: sh/curl/python3 bir web sunucusu sürecinden doğması, kurumun kendi PHP uygulamalarının (harici API çağrısı, görsel işleme, log rotasyonu) meşru davranışı olabilir. Kurala çevirmeden önce, sh/bash/dash gibi shell interpreter'ların yalnızca gerçek bir keşif/indirme/ters-shell imzası (chmod +x, base64 -d, /dev/tcp/, -e /bin/sh gibi) taşıdığında tetiklenmesini şart koşan bir ek filtre ekleyin, aksi halde kural birkaç gün içinde gürültüden kapatılır.
Custom Detection Rule'a Çevirme
Advanced Hunting'de doğruladıktan sonra Custom Detection Rules > Create detection rule üzerinden kurala çeviriyoruz:
- Detection Name: Suspicious Process Spawning from Web Server
- Add Query butonuyla açılan pencerede sorgumuzu yazıyoruz
Frequency: Every hour (webshell sonrası ilk saatlerdeki hareket kritik)
Severity: High
Category: Suspicious Activity
Alert Settings kısmındaki alanları kendi tercihinize göre doldurabilirsiniz
Automated actions: İlk devreye almada otomatik izolasyon önermiyoruz. Kuralı bir-iki hafta "alert only" modda çalıştırıp kendi ortamınızdaki FP oranını gördükten sonra host izolasyonu bağlayın.
Not: Dosya ve süreç sorgularını ayrı kural olarak tanımlayın; ikisi aynı host'ta yakın zaman damgasıyla birlikte tetiklenirse bu zaten yüksek güvenilirlikli bir incident'tır.
Katmanlı Savunma
Bu tespit katmanı, yamalama ve WAF'ın yerini almıyor — onların başarısız olduğu senaryoda son çizgi. Öncelik sırası hâlâ aynı:
- 6.9.5/7.0.2'ye yama.
- WAF'ta /wp-json/batch/v1 ve ?rest_route=/batch/v1 bloklaması.
- burada anlattığımız davranışsal kural bir güvenlik ağı olarak.
Sonuç
MDE'nin Linux ajanı bu senaryoda görünürlüğü kaybetmiyor, süreç zinciri telemetride eksiksiz duruyordu. Kaybolan şey bunun üzerine oturan varsayılan alarm mantığı: dosya tabanlı bir koruma motoru, davranışsal bir saldırı zincirini yakalayacak şekilde tasarlanmamış. En sıkı koruma profili bile bunu değiştirmiyor, çünkü sıkılaştırdığınız kadranlar (imza/bulut itibarı) zaten yanlış katman. Custom detection rule yazmak, bu boşluğu kapatma sorumluluğunu üstlenmek demek; biz test ettik, çalışıyor.
Selman Bilal SİVRİ - L2/L3 MDR Analyst
InfinitumIT MDR - Detection Engineering & Threat Hunting
Bu yazı, izole bir lab ortamında MDE for Linux sensörüne karşı yürütülen kontrollü test sonuçlarına dayanmaktadır.
