WordPress Core üzerindeki WP2Shell RCE zincirinin, CrowdStrike Falcon telemetrisi, built-in webshell görünürlüğü ve davranışsal Custom IOA kuralları üzerinden Linux sistemler için incelenmesi.
Modern EDR platformları endpoint üzerinde çalışan process'leri, file aktivitelerini, script içeriklerini ve parent-child ilişkilerini güçlü bir telemetry ile görünür hale getirir. Buna rağmen internet-facing web uygulamalarındaki bir zafiyetin başarılı biçimde exploit edilmesi, her zaman ilk aşamada yüksek önem seviyeli bir endpoint alarmına dönüşmeyebilir. SQL injection, yetki manipülasyonu ve uygulamanın meşru yönetim fonksiyonlarının kötüye kullanılması gibi adımlar çoğu zaman application ve database katmanlarında kalır. Endpoint açısından kritik an, saldırı zincirinin işletim sistemi komut çalıştırmaya, dosya bırakmaya veya post-exploitation araçlarını kullanmaya başladığı noktadır.
Bu makalede WordPress Core için yayımlanan WP2Shell zinciri, InfinitumIT test ortamında Linux sistemler özelinde CrowdStrike Falcon perspektifinden incelenmiştir. Amaç CrowdStrike ürününü tek bir başarılı veya başarısız alarm üzerinden değerlendirmek değil; belirli bir public PoC'nin hangi telemetry'yi ürettiğini, hangi built-in mekanizmaların devreye girdiğini ve kurumun kendi risk modeline uygun Custom IOA kurallarıyla detection coverage'ın nasıl genişletilebileceğini göstermektir.
WP2Shell Case Study
WP2Shell adıyla yayımlanan saldırı zinciri, WordPress REST batch davranışı ile SQL injection etkisini birleştirerek kimlik doğrulama gerektirmeyen bir saldırganın administrator hesabı oluşturmasına ve ardından remote code Execution (RCE) elde etmesine imkan tanımaktadır. Çalışmada kullanılan public PoC, zafiyetin kontrol edilmesi ve kontrollü bir shell akışının yürütülmesi için çeşitli alt komutlar sunmaktadır. Araştırmada kullanılan repository: https://github.com/0xsha/wp2shell
Public PoC'nin shell akışı, kimlik bilgisi sunulmadığında yeni bir WordPress administrator hesabı oluşturmuş, bu hesapla oturum açmış, token kontrollü bir plugin webshell yüklemiş ve verilen komutu web server kullanıcısı altında çalıştırmıştır. Bu zincir yalnızca bir PHP dosyasının diske yazılmasından ibaret değildir; application katmanındaki yetki kazanımı ile endpoint katmanındaki process execution arasında ardışık bir saldırı yolu oluşturur.
InfinitumIT Test Ortamı
Test ortamı VMware Workstation üzerinde, izole 192.168.77.0/24 segmentinde çalışan iki Ubuntu sanal makineden oluşturulmuştur. 192.168.77.10 adresindeki attacker host public PoC ve kontrollü payload testleri için, 192.168.77.20 adresindeki target host ise WordPress 6.9.4, Apache 2.4.58, PHP 8.3.6, MariaDB 10.11.14 ve CrowdStrike Falcon Sensor 7.39.0-19203 için kullanılmıştır. Saldırı trafiği yalnızca lab segmentinde tutulmuş, target sistemin kontrollü NAT erişimi Falcon cloud iletişimi için korunmuştur.
Şekil 1. InfinitumIT WP2Shell Detection Lab mimarisi: izole attacker host ile CrowdStrike Falcon Sensor bulunan WordPress target arasındaki kontrollü test ağı.
WordPress ortamı REST API erişimi, published test post ve plugin installation fonksiyonları public PoC'nin gereksinimlerini karşılayacak şekilde hazırlanmıştır. Test sonuçları Falcon Advanced Event Search, Falcon process tree, Linux Auditd kayıtları, PoC terminal çıktıları ve WordPress üzerinde oluşan kullanıcı ile plugin artifact'leri üzerinden karşılaştırılmıştır.
Şekil 2. WordPress 6.9.4 üzerinde hazırlanan WP2Shell Detection Lab ana sayfası ve yayımlanmış EDR test içeriği.
Exploit Öncesi Non-Destructive Doğrulama
Tam RCE zincirine geçilmeden önce public PoC'nin "check" alt komutu kullanılarak hedef uygulamanın zafiyete ilişkin ön koşulları doğrulanmıştır. Bu adımda WordPress sürümü, REST batch endpoint erişimi ve route confusion davranışı kontrol edilmiş; shell alt komutu çalıştırılmadığı için işletim sistemi seviyesinde komut yürütme, yeni administrator hesabı oluşturma veya plugin webshell deployment amaçlanmamıştır.
PoC çıktısında WordPress 6.9.4 sürümü vulnerable olarak işaretlenmiş, /wp-json/batch/v1 endpoint'inin unauthenticated biçimde erişilebilir olduğu ve route confusion davranışının aktif olduğu görülmüştür. Bu kontrol, sonraki RCE testlerinin application-level dayanağını oluşturmuştur.
Şekil 3. Public PoC check alt komutunda WordPress 6.9.4 sürümünün vulnerable olarak belirlenmesi, batch endpoint erişimi ve route confusion davranışının doğrulanması.
Public PoC ile Uçtan Uca RCE
İlk kontrollü testte PoC'ye yalnızca id komutu verilmiştir. Buna rağmen araç, komut çalıştırma aşamasına ulaşmadan önce pre-authentication administrator creation ve plugin webshell deployment işlemlerini tamamlamıştır.
PoC çıktısında wp2_<hex> formatında yeni bir administrator hesabı, wp2shell_<hex> formatında plugin dizini ve uid=33(www-data) sonucu gözlemlenmiştir. WordPress kullanıcı ve plugin karşılaştırmaları yeni hesabı ve webshell dosyasını doğrulamıştır. Webshell test artifact'i www-data tarafından wp-content/plugins altında oluşturulmuştur.
Şekil 4. Attacker host terminalinde pre-authentication administrator hesabının oluşturulması, plugin webshell deployment ve www-data yetkisiyle id komutunun çalıştırılması.
Auditd kayıtları ile Falcon ProcessRollup2 event'leri aynı zinciri doğrulamıştır: Apache worker process'i /usr/bin/dash çalıştırmış, dash ise /usr/bin/id process'ini başlatmıştır. Her iki execve işlemi de başarılı olmuş ve komut sonucu attacker'a dönmüştür. Bu özel PoC akışında built-in detection veya prevention oluşmamasına rağmen Falcon olayın araştırılması için gerekli process ancestry, command line ve kullanıcı context'ini telemetri logu olarak sağlamıştır.
İşletim Sistemi ve Falcon Telemetrisiyle Zincirin Doğrulanması
Şekil 5. Linux Auditd kayıtlarında /usr/bin/dash ve /usr/bin/id için başarılı execve işlemleri ile webshell çalışma dizininin görünümü.
Auditd kayıtları işletim sistemi seviyesindeki process execution işlemlerini doğrularken, Falcon telemetry'si aynı olayları parent-child ilişkileri ve komut satırı bağlamıyla merkezi olarak ilişkilendirmiştir.
Şekil 6. CrowdStrike Advanced Event Search üzerinde apache2, dash ve id process zincirinin ParentProcessId ve TargetProcessId alanlarıyla ilişkilendirilmesi.
Daha dar kapsamlı sorgu, web server tarafından doğrudan başlatılan shell process'ini izole ederek RCE davranışının temel detection sinyalini ortaya koymuştur.
Şekil 7. Web server child process davranışına odaklanan sorguda apache2 tarafından başlatılan /usr/bin/dash process'i ve sh -c -- id komut satırı.
Telemetri Mevcutken Alarm Neden Oluşmayabilir?
Bir EDR açısından id, whoami, curl, chmod veya dash tek başına zararlı değildir. Bu araçlar Linux işletim sisteminin normal bileşenleridir ve yönetim, deployment, monitoring veya uygulama iş akışlarında meşru şekilde kullanılabilir. WP2Shell testinin ilk aşamaları da WordPress, PHP ve MariaDB katmanlarında ilerlemiş yeni administrator hesabı oluşturulması doğrudan yeni bir Linux binary veya bilinen malware artifact'i üretmemiştir.
Bu nedenle asıl güvenlik sinyali binary'nin adı değil, process ancestry ve contextdir. Normal şartlarda internet-facing bir Apache worker'ın shell interpreter başlatması ve bu shell altında utility çalıştırması, web application RCE veya webshell aktivitesi açısından yüksek değerli bir davranıştır. Detection engineering çalışması tam olarak bu telemetry'yi kurumun normal iş yüklerinden ayıran davranış kurallarına dönüştürmeyi hedeflemiştir.
Kontrollü Post-Exploitation Davranışları
Falcon görünürlüğünü daha geniş bir davranış seti üzerinde değerlendirmek için aynı webshell üzerinden whoami, id, uname, useradd, getent, curl, chmod, sh ve cat komutları çalıştırılmıştır.
"useradd" girişimi www-data yetkisi nedeniyle başarısız olmuş, ancak process'in çalıştırıldığı ve ilgili command line'ın Falcon telemetry'sine kaydedildiği görülmüştür.
Benign payload transferi testinde attacker host üzerindeki zararsız shell script curl ile /tmp dizinine indirilmiş, chmod ile çalıştırılabilir hale getirilmiş ve /bin/sh ile başlatılmıştır. Falcon bu zincirde apache2, dash, curl, chmod ve ikinci shell process'ini görünür hale getirmiş; ancak bu kontrollü ve benign içerik için built-in detection üretmemiştir. Sonuç, web server ancestry'sinin tekil binary reputation bilgisinden daha anlamlı olabileceğini göstermiştir.
Şekil 8. Attacker host üzerinde discovery komutları, başarısız useradd girişimi, benign payload transferi ve indirilen script'in çalıştırılması.
Attacker terminalindeki çıktı komutların hedef üzerinde gerçekten yürütüldüğünü gösterirken, Falcon tarafındaki process telemetry bu aktivitelerin web server ancestry'si altında nasıl zincirlendiğini ortaya koymuştur.
Şekil 9. CrowdStrike Advanced Event Search üzerinde webshell üzerinden çalıştırılan shell, discovery, hesap yönetimi ve dosya transferi process'lerinin geniş görünümü.
Geniş telemetry görünümünün ardından sorgu, yalnızca güvenlik açısından daha anlamlı post-exploitation process'lerine daraltılmıştır.
Şekil 10. Post-exploitation davranışlarına odaklanan filtrelenmiş Falcon telemetry'sinde useradd, curl, chmod, dash ve cat process'leri.
EICAR ile Anti-Malware Kanalının Doğrulanması
Falcon'un bilinen test içeriğine verdiği tepkiyi bağımsız olarak doğrulamak için EICAR (European Institute for Computer Antivirus Research) dosyası curl üzerinden /tmp/eicar.com yoluna yazılmıştır. Falcon, "EICARTestFileWrittenLin" isimli Informational severity detection üretmiş ve process tree üzerinde systemd, apache2, dash ve curl zincirini göstermiştir. Actions taken alanı None olduğundan test dosyası yazımı engellenmemiştir.
Bu sonuç WP2Shell veya webshell detection coverage'ının kanıtı değildir. EICAR yalnızca anti-malware ürünlerinin bilinen test içeriğini tanıyıp tanımadığını güvenli biçimde doğrulamak için kullanılır. EICAR standardı: https://www.eicar.org/download-anti-malware-testfile/
Şekil 11. Attacker host üzerinden EICAR test dosyasının curl ile /tmp/eicar.com yoluna indirilmesi ve dosyanın oluşturulduğunun doğrulanması.
Dosyanın hedef sisteme yazılmasının ardından Falcon, bilinen EICAR test içeriğini tanıyarak ayrı bir built-in detection üretmiştir.
Şekil 12. Falcon Console üzerinde EICARTestFileWrittenLin isimli Informational severity detection ve systemd, apache2, dash, curl process zinciri.
PHP Webshell Visibility: İkinci Test Neden Alarm Üretti?
Falcon Linux ve PHP Görünürlük Ön Koşulları
PHP webshell testinden önce target hosta atanan Linux Prevention Policy üzerinde Filesystem visibility, Enhance PHP visibility ve On write script file visibility ayarlarının etkin olduğu doğrulanmıştır.
Filesystem visibility yeni dosya ve script aktivitelerinin context bilgileriyle görünür hale gelmesini, On write script file visibility yazım anındaki script telemetry'sinin üretilmesini, Enhance PHP visibility ise PHP runtime içinde dinamik olarak evaluate edilen içeriğin PhpEvalString gibi event'lerle incelenebilmesini desteklemiştir.
Şekil 13. Test hostuna atanan Linux Prevention Policy üzerinde Filesystem visibility, Enhance PHP visibility ve On write script file visibility ayarlarının etkin durumu.
Bu ayarlar, aşağıdaki testte gözlemlenen NewScriptWritten ve PhpEvalString telemetry'sinin yorumlanması açısından önemlidir. Farklı sensor sürümleri ve policy yapılandırmaları aynı testte farklı event kapsamı üretebilir.
Built-in webshell visibility mekanizmasını daha belirgin bir davranışla test etmek için ikinci bir PHP test dosyası hazırlanmıştır. Bu dosya attacker-controlled POST verisini Base64 decode etmiş, eval ile çalıştırmış ve decoded içerikte shell_exec("whoami") çağrısını yürütmüştür.
PHP dosyası web server process zinciri üzerinden curl kullanılarak doğrudan WordPress uploads dizinine yazılmıştır. Falcon, NewScriptWritten event'iyle dosyanın yazıldığını ve writer process olarak curl context'ini göstermiştir. Enhance PHP visibility sayesinde PhpEvalString event'inde evaluate edilen gerçek içerik echo shell_exec("whoami"); biçiminde görünür olmuştur. Falcon Console ayrıca High severity LinWebshell detection üretmiştir.
Şekil 14. Attacker host üzerinde PHP test webshell'inin WordPress uploads dizinine yazılması ve POST isteğiyle shell_exec("whoami") çalıştırılması.
Bu çağrının ardından Falcon, davranışı PHP runtime içeriği, yeni script yazımı ve built-in webshell detection olmak üzere birbirini tamamlayan katmanlarda görünür hale getirmiştir.
Falcon PHP ve Script Görünürlüğü
Şekil 15. Falcon PhpEvalString event'inde evaluate edilen echo shell_exec("whoami"); içeriğinin görünür hale gelmesi.
PhpEvalString event'i çalıştırılan dinamik PHP içeriğini gösterirken, dosyanın diske yazıldığı aşama NewScriptWritten telemetry'siyle ayrıca kaydedilmiştir.
Şekil 16. NewScriptWritten event'inde curl process'i tarafından wp-content/uploads/2026/07 dizinine yazılan PHP dosyası.
Runtime ve file-write sinyallerinin birlikte değerlendirilmesi sonucunda Falcon Console üzerinde "LinWebshell" isimli High severity detection oluşmuştur.
Şekil 17. Falcon Console üzerinde High severity LinWebshell detection ve webshell dosyasını yazan curl process'ine ait process tree.
Detection process tree'si incelendiğinde web server process'leri altında dash ve curl aracılığıyla gerçekleştirilen dosya transferi açık biçimde izlenebilmektedir.
Şekil 18. "LinWebshell" olayıyla ilişkili process zincirinde apache2 altında çalışan dash ve curl process'lerinin execution ayrıntıları.
Detection ve Prevention Sonucunun Ayrıştırılması
"LinWebshell" olayı High severity bir built-in detection üretmiş olsa da Falcon Console üzerinde Actions taken alanı None olarak görünmüştür. PHP dosyası hedef dizine yazılmış, POST isteği işlenmiş ve shell_exec("whoami") sonucu attacker terminaline www-data olarak dönmüştür. Dolayısıyla bu testte runtime ve file-write görünürlüğü ile alarm üretimi doğrulanmış, ancak ilgili davranış için built-in prevention uygulanmamıştır. Bu ayrım, bir detection oluşmasının aynı olayın otomatik olarak engellendiği anlamına gelmediğini göstermektedir.
Orijinal WP2Shell ile Klasik Webshell Arasındaki Fark
Orijinal public PoC'nin webshell'i küçük ve sade bir PHP dosyasıdır. WordPress'in normal plugin upload mekanizmasıyla wp-content/plugins altına yazılmış, WordPress açısından meşru bir plugin installation işlemine benzer görünmüş ve eval veya Base64 decode kullanmamıştır.
İkinci testte ise web server process zinciri üzerinden curl çalıştırılmış, PHP doğrudan uploads dizinine yazılmış, attacker-controlled veri Base64 decode edilmiş ve eval ile çalıştırılmıştır. Evaluated içerik ayrıca shell_exec çağırmıştır. WordPress uploads altında PHP bulunması ve dinamik eval davranışı daha klasik ve belirgin bir webshell paterni oluşturmuştur.
Bu farklılık Falcon'un webshell visibility özelliğinin çalışmadığı anlamına gelmemektedir. Aksine ikinci testte "NewScriptWritten", "PhpEvalString" ve "LinWebshell" detection'larının oluşması ilgili bileşenlerin aktif olduğunu göstermiştir. Bulgular, farklı webshell implementation'larının farklı telemetry ve detection sonuçları üretebildiğini ortaya koymaktadır.
Detection Engineering: Falcon Custom IOA Kural Seti
Test boyunca elde edilen telemetry, yalnızca WP2Shell isimlendirmesine bağlı olmayan davranışsal kurallar geliştirmek için kullanılmıştır. Özellikle ilk iki kural genel Linux web application RCE ve webshell senaryolarında da uygulanabilecek parent-child process ilişkilerine odaklanmaktadır.
⚠ Uyarı: Bu kurallar sınırlı sayıda canlı veri bulunan izole InfinitumIT test ortamında doğrulanmıştır. Production ortamlara doğrudan Process Kill veya başka bir prevention action ile uygulanmamalıdır. Önce test host gruplarında Monitor veya Detect mode'da çalıştırılmalı, normal deployment, maintenance, backup, monitoring ve plugin update davranışları gözlemlenmeli, gerekli false-positive tuning ve dar kapsamlı exclusion çalışmaları tamamlanmalıdır. Engelleme ancak sınırlı pilot, change management onayı ve rollback planı sonrasında kademeli olarak etkinleştirilmelidir.
Test Sırasında Kullanılan Ortak IOA Alanları
Kuralların ilk doğrulama aşamasında yalnızca davranışı belirleyen alanlar daraltılmış, diğer alanlar olası telemetry farklılıkları nedeniyle geniş tutulmuştur. Process Creation kurallarında kullanılmayan Grandparent Command Line, Parent Command Line ve Command Line alanlarına .* değeri verilmiştir. File Creation kurallarında Grandparent Image Filename, Grandparent Command Line, Parent Image Filename, Parent Command Line, Image Filename ve Command Line alanları .* olarak bırakılmış; File Type seçiminde Select All kullanılmıştır. Bu yapı test kapsamındaki eşleşmeyi doğrulamak amacıyla uygulanmış olup production tuning sonrasında process, command line, file type ve host scope alanları daraltılmalıdır.
INFNT-IOA-0001 - Web Server Spawning Shell Interpreter
Bu kuralın amacı Apache, Nginx, HTTPD veya PHP worker process'lerinin sh, dash, bash ve benzeri shell interpreter'ları başlatmasını tespit etmek ve uygun ortamlarda engellemektir. Kural WP2Shell'e özgü değildir; PHP webshell, CMS compromise ve genel Linux web application RCE vakalarında aynı davranış görülebilir.
Detect mode testinde apache2 altında doğan dash process'i Critical Custom IOA detection üretmiştir. Process Kill mode'a geçildikten ve yeni action endpoint'e ulaştıktan sonra yapılan tekrarda dash process'i sonlandırılmış, attacker terminaline komut sonucu dönmemiştir. Falcon Console üzerindeki Actions taken: Process killed bilgisi engelleme sonucunu doğrulamıştır.
Detect ve Process Kill Doğrulaması
Şekil 19. INFNT-IOA-0001 kuralının Detect mode doğrulamasında apache2 altında başlayan dash process'i için üretilen Critical Custom IOA detection.
Kural Detect mode'da doğru process lineage üzerinde alarm ürettikten sonra action Process Kill olarak değiştirilmiş ve aynı davranış yeniden çalıştırılmıştır.
Şekil 20. Attacker host üzerinde aynı komutun iki kez çalıştırılması: ilk denemede çıktı alınırken Process Kill action'ı endpoint'e ulaştıktan sonraki denemede komut sonucunun dönmemesi.
Attacker tarafındaki çıktı farkı, yeni action'ın endpoint'e uygulanmasından sonra shell process'inin yürütülmeden sonlandırıldığını göstermiştir.
Şekil 21. Falcon Console üzerinde INFNT-IOA-0001 için Actions taken alanında Process killed sonucunun gösterilmesi.
INFNT-IOA-0002 - Web Shell Spawning Post-Exploitation Utility
İkinci kural, web server tarafından başlatılan shell altında curl, wget, chmod, useradd, Python, netcat veya systemctl gibi utility'lerin çalıştırılmasını tespit etmektedir. Payload transferi, izin değişikliği, account creation girişimi, script execution ve persistence amaçlı araç kullanımı bu davranış modelinin kapsamındadır.
Benign payload testinde dash altında çalışan curl ve chmod process'leri ayrı Custom IOA detection'ları üretmiştir. Bu kural, ilk kurala kıyasla daha geniş bir binary listesi içerdiği için production öncesinde daha uzun bir baseline ve false-positive tuning süreci gerektirir.
Şekil 22. Attacker host üzerinde benign payload indirme ve çalıştırma komutları ile WordPress uploads dizinine PHP dosyası yazma testlerinin terminal çıktıları.
Komut zincirindeki curl ve chmod işlemleri ayrı child process'ler olarak oluştuğu için INFNT-IOA-0002 tarafından bağımsız detections şeklinde kaydedilmiştir.
Şekil 23. INFNT-IOA-0002 kuralının /usr/bin/chmod 700 /tmp/ioa-benign.sh komutunu Critical Custom IOA olarak tespit etmesi.
Aynı parent-child bağlamında curl process'i de payload transferi davranışı olarak ayrıca eşleşmiştir.
Şekil 24. INFNT-IOA-0002 kuralının curl ile benign script indirme davranışını web server ve shell ancestry'si altında tespit etmesi.
INFNT-IOA-0003 - PHP File Created in WordPress Uploads
WordPress uploads dizini normalde medya ve doküman barındırır. Bu dizine PHP dosyası yazılması çoğu WordPress mimarisinde yüksek şüpheli bir davranıştır. File Creation rule type ile aşağıdaki path pattern'i izlenmiştir.
Doğrulama testinde curl ile uploads/ioa-validation/infnt-validation.php dosyası oluşturulmuş ve kural Critical Custom IOA detection üretmiştir. Dedicated WordPress sunucularında bu kural yüksek güvenilirlikli bir sinyal olabilir; yine de özel deployment ve application davranışları baseline edilmelidir.
Şekil 25. Attacker host üzerinde wp-content/uploads/ioa-validation dizinine infnt-validation.php dosyasının yazılması ve dosya izinlerinin doğrulanması.
Dosyanın hedef dizinde oluşmasıyla birlikte Falcon File Creation Custom IOA mekanizması path pattern'i üzerinden eşleşme üretmiştir.
Şekil 26. INFNT-IOA-0003 kuralının WordPress uploads dizinindeki PHP file creation davranışı için ürettiği Critical detection.
INFNT-IOA-0004 - WP2Shell Public PoC Plugin Webshell Creation
Bu kural public PoC'nin wp2shell_<8 hex> directory ve filename naming pattern'ini hedefler. Düşük false-positive potansiyeline sahiptir; ancak saldırganın dosya veya dizin adını değiştirmesiyle kolayca atlatılabileceği için davranışsal kuralların yerine geçmez.
Kuralın regex ve File Creation davranışı doğrudan curl file-write testiyle doğrulanmış ve Custom IOA detection oluşmuştur. Public PoC'nin gerçek plugin ZIP upload ve extraction aşamasında aynı File Creation event'inin oluşması ayrıca doğrulanmadığından, kural yardımcı ve PoC-specific bir coverage katmanı olarak değerlendirilmelidir.
PoC-Specific ve Genel Plugin Dizini Kurallarının Doğrulanması
Şekil 27. INFNT-IOA-0004 kuralının wp2shell_a1b2c3d4 dizin ve dosya isimlendirme pattern'iyle eşleşen PHP file creation davranışını tespit etmesi.
Aynı file-write davranışı, PoC isimlendirmesine bağlı dar kuralın yanı sıra plugin ve theme dizinlerini kapsayan daha genel kural tarafından da değerlendirilmiştir.
INFNT-IOA-0005 - PHP File Created in WordPress Plugin or Theme Directory
Beşinci kural WordPress plugin veya theme dizinlerine genel PHP yazımını izler. Farklı webshell ve malicious plugin/theme senaryolarını kapsayabilir; ancak meşru plugin kurulumu, update ve deployment işlemlerinde false positive üretme ihtimali yüksektir.
Direct-write doğrulama testinde genel path kuralı da başarıyla detection üretmiştir. Bu kural production ortamında varsayılan olarak Process Kill için uygun değildir; Monitor veya Detect mode, dar host scope ve iyi tanımlanmış maintenance davranışlarıyla kullanılmalıdır.
Şekil 28. INFNT-IOA-0005 kuralının WordPress plugin dizinine yapılan genel PHP file creation davranışı için ürettiği detection.
Detect'ten Process Kill'e: Engellemenin Gerçek Sınırı
INFNT-IOA-0001 Process Kill modunda dash process'ini başarıyla sonlandırmış ve işletim sistemi komutunun attacker'a dönmesini engellemiştir. Ancak PoC çıktısı administrator hesabının ve plugin webshell'in shell process'i başlamadan önce oluşturulabildiğini göstermektedir. Bu nedenle process termination, application-level compromise artifact'lerini otomatik olarak geri almaz.
Başarılı bir prevention sonucunun ardından dahi yeni administrator hesapları, wp-content altındaki PHP dosyaları, Apache access logları ve database değişiklikleri incelenmelidir. Endpoint kuralı saldırı zincirinin kritik bir aşamasını durdurabilir; fakat olay müdahalesi application, database ve endpoint katmanlarını birlikte kapsamalıdır.
Test Sonuçlarının Karşılaştırmalı Özeti
Farklı testler, Falcon'un telemetry, built-in detection ve Custom IOA katmanlarının aynı saldırı zincirinde farklı roller üstlendiğini göstermiştir. Aşağıdaki tablo testlerde gözlemlenen temel sonuçları tek bir görünümde özetlemektedir.
Tablo 1. WP2Shell ve Custom IOA testlerinde gözlemlenen telemetry, detection ve prevention sonuçlarının karşılaştırılması.
WP2Shell Ötesinde Linux Web Application RCE Coverage'ı
Her ne kadar çalışma WP2Shell üzerinde yürütülmüş olsa da INFNT-IOA-0001 ve INFNT-IOA-0002 WordPress'e veya public PoC isimlendirmesine bağlı değildir. Web server'ın shell interpreter başlatması ve shell altında post-exploitation utility çalıştırılması, farklı CMS ürünlerinde, PHP framework'lerinde, internet-facing servislerde ve çeşitli Linux web application RCE senaryolarında ortaya çıkabilecek ortak davranışlardır.
INFNT-IOA-0003 ve INFNT-IOA-0005 ise WordPress dizin yapısına bağlıdır. INFNT-IOA-0004 yalnızca public PoC'nin naming pattern'ine odaklanan dar bir kuraldır. Bu ayrım, signature benzeri PoC göstergeleri ile daha dayanıklı davranışsal detection'ların aynı rule set içinde farklı amaçlarla konumlandırılmasını sağlar.
Katmanlı Savunma: WAF, Patching ve Endpoint Kontrolleri
Bu test yalnızca EDR seviyesinde gerçekleştirilmiştir. Gerçek production ortamlarında uygun şekilde yapılandırılmış bir WAF, saldırganın REST API ve batch endpoint isteklerini application katmanına ulaşmadan engelleyebilir. Güvenli WordPress sürümüne hızlı güncelleme, attack surface reduction, güvenli plugin yönetimi, reverse proxy kontrolleri ve application log monitoring saldırının endpoint'e ulaşmasını önleyen veya daha erken görünür kılan katmanlardır.
CrowdStrike Falcon bu kontrollerin alternatifi değil, tamamlayıcı endpoint visibility ve prevention katmanıdır. Falcon'un process ancestry, file creation ve PHP visibility telemetry'si; WAF logları, Apache access logları ve WordPress artifact'leriyle korele edildiğinde daha güçlü bir incident investigation ve containment kabiliyeti sağlar.
MDR ve Continuous Threat Hunting'in Rolü
Built-in detection üretmeyen ancak telemetry olarak mevcut olan aktiviteler, MDR hizmeti kapsamındaki continuous threat hunting çalışmalarıyla ortaya çıkarılabilir. Web server'ın shell başlatması, web process context'inde payload indirilmesi, WordPress dizinlerine PHP yazılması veya web server kullanıcısının post-exploitation utility çalıştırması periyodik hunting sorgularıyla incelenebilir.
Bu süreçte önce telemetry içinde şüpheli davranışlar belirlenir. Doğrulanan davranışlar detection engineering use-case'lerine dönüştürülür ve test host gruplarında Monitor veya Detect mode'da doğrulanır. Ardından false-positive tuning ve operasyonel kapsamlandırma tamamlanır. Yeterli güven seviyesi sağlandığında kontrollü prevention uygulanır ve kural performansı düzenli olarak gözden geçirilir. Böylece MDR hizmeti yalnızca mevcut alarmları yönetmekle kalmaz, platformdaki telemetry'den yeni detection coverage üretir.
WP2Shell Vakasının Önerileri
• WordPress, tüm production ve staging instance'larında güvenli ve desteklenen sürüme yükseltilmelidir.
• WAF veya reverse proxy üzerinde REST batch API ve olağan dışı plugin upload istekleri izlenmeli, gereksinim dışı erişim sınırlandırılmalıdır.
• Yeni veya beklenmeyen administrator hesapları, özellikle wp2_<hex> benzeri isimler, düzenli olarak araştırılmalıdır.
• wp-content/plugins, wp-content/uploads ve wp-content/themes altında yeni PHP dosyaları ile bütünlük değişiklikleri incelenmelidir.
• Falcon process tree, NewScriptWritten ve PhpEvalString telemetry'si Apache access loglarıyla zaman bazında korele edilmelidir.
• Custom IOA kuralları önce Monitor veya Detect mode'da, dar host scope ile ve yeterli baseline süresi boyunca test edilmelidir.
• Process Kill sonrasında dahi application-level artifact'ler kaldırılmalı, credentials ve WordPress secret'ları risk durumuna göre rotate edilmelidir.
• Sunucu bütünlüğü güvenilir biçimde doğrulanamıyorsa sistem temiz ve güncel bir image üzerinden yeniden oluşturulmalıdır.
Sonuç
WP2Shell case study'si, güçlü endpoint telemetry'sinin her web application exploit implementation'ı için aynı built-in detection veya prevention sonucunu garanti etmediğini göstermiştir. Falcon Sensor ilk public PoC testinde process ancestry ve command line context'ini eksiksiz biçimde görünür hale getirmiş, daha belirgin eval ve Base64 tabanlı webshell testinde ise NewScriptWritten, PhpEvalString ve High severity LinWebshell detection üretmiştir.
Detection engineering çalışmasıyla web server'ın shell interpreter başlatması, shell altında post-exploitation utility çalıştırılması ve WordPress dizinlerine PHP yazılması için kurum odaklı coverage geliştirilmiştir. INFNT-IOA-0001 Process Kill modunda test edilerek OS command execution aşamasını durdurmuştur. Bununla birlikte saldırgan hesabı ve plugin webshell gibi artifact'lerin daha önce oluşabilmesi, endpoint prevention'ın WAF, patching, application monitoring ve incident response süreçleriyle birlikte ele alınmasını zorunlu kılmaktadır.
Bu çalışmanın en önemli operasyonel çıktısı, telemetry içinde kalan şüpheli davranışların continuous threat hunting ile keşfedilebileceği, detection engineering ile kurala dönüştürülebileceği ve yalnızca kontrollü Monitor, Detect ve tuning süreci sonrasında prevention katmanına taşınması gerektiğidir.
Sorumluluk Reddi: Bu doküman yalnızca bilgilendirme ve savunma amaçlıdır. Kurallar ürün sürümü, sensor policy, application mimarisi ve normal iş yüküne göre farklı sonuçlar üretebilir. Production ortamında uygulanmadan önce kontrollü test, false-positive tuning, change management ve rollback planı gerektirir. İçerik yalnızca kullanıcıya ait izole lab ortamında yürütülen testleri açıklar.
© 2026 INFINITUMIT · InfinitumIT MDR - Detection Engineering & Threat Hunting
Hakan AKSUNGUR — L2 MDR Analyst
InfinitumIT MDR — Detection Engineering & Threat Hunting
Bu yazı, InfinitumIT'e ait izole bir CrowdStrike Falcon test ortamında yürütülen kontrollü test sonuçlarına dayanmaktadır. Sunulan IOA ifadeleri ve test senaryoları örnek niteliğindedir.
