Webshell Nedir? Web Sunucularında Webshell Nasıl Tespit Edilir?

Webshell nedir, nasıl yüklenir?

Webshell, web sunucusunu saldırgan için uzaktan yönetim paneline dönüştüren bir betiktir. Genellikle dosya yükleme açıkları, güncellenmemiş eklentiler, uzaktan kod çalıştırma zafiyetleri veya ele geçirilmiş yönetici hesaplarıyla sunucuya bırakılır.

MITRE ATT&CK T1505.003 tanımına göre webshell, internete açık bir web sunucusuna yerleştirilen ve saldırganın bu sunucuyu ağa giriş kapısı olarak kullanmasını sağlayan bir betiktir. Tek satırlık bir komut çalıştırıcı kadar basit olabileceği gibi dosya yöneticisi, veritabanı istemcisi ve komut satırı sunan kapsamlı bir panel de olabilir. Bazı webshell'ler ayrı bir istemci programla haberleşir; sunucudaki parça yalnızca gelen komutu çalıştırır.

Asıl tehlike, erişim kalıcı hâle geldikten sonra başlar. Saldırgan ek zararlı yazılım yükleyebilir, yapılandırma dosyalarındaki veritabanı parolalarını okuyabilir ve sunucuyu iç ağdaki diğer sistemlere geçmek için sıçrama noktası olarak kullanabilir.

En sık görülen yükleme yolları

• Kısıtlamasız dosya yükleme — Bir yükleme formu dosya türünü ve uzantısını doğrulamıyorsa .php ya da .aspx uzantılı bir betik doğrudan web dizinine yazılabilir.
• İçerik yönetim sistemi ve eklenti açıkları — Güncellenmemiş CMS çekirdekleri, temalar ve eklentiler en sık hedeflenen bileşenlerdir.
• Uzaktan kod çalıştırma ve dosya dahil etme — RCE, RFI veya LFI zafiyetleri saldırganın sunucuya kendi dosyasını yazmasına izin verir.
• Açıkta kalan yönetim arayüzleri — Varsayılan parolası değiştirilmemiş bir panel ya da çalınmış FTP veya SSH bilgileri tek başına yeterli olabilir.

CISA'nın web sunucusu ihlalleri üzerine yayımladığı uyarı, bu yöntemlerin çoğu zaman birlikte kullanıldığını belirtir: Açıkta kalan bir yönetim paneli, bir dosya yükleme seçeneğiyle birleştiğinde webshell bırakmaya yeter. Yükleme formlarını güvenli hâle getirmek için OWASP File Upload Cheat Sheet iyi bir başlangıç noktasıdır.

Webshell belirtileri nelerdir?

En güçlü belirtiler; web dizininde son dağıtımdan sonra ortaya çıkan betik dosyaları, web sunucusu sürecinin komut satırı başlatması ve daha önce hiç istenmemiş bir dosyaya gelen POST istekleridir. Tek bir belirti kesin kanıt sayılmaz; birkaçı bir arada görüldüğünde şüphe güçlenir.

• Yeni veya değişmiş betik dosyaları — Özellikle yükleme dizinlerinde .php, .phtml, .aspx, .ashx veya .jsp uzantılı dosyalar. Resim klasöründe çalıştırılabilir kod bulunması normal değildir.
• Şüpheli kod kalıpları — eval, base64_decode, assert, system veya shell_exec gibi fonksiyonların karartılmış (obfuscated) kodla birlikte kullanılması.
• Web sunucusundan başlayan süreçler — w3wp.exe, httpd, nginx veya php-fpm altında cmd.exe, powershell.exe, sh, whoami ya da id çalışması.
• Olağandışı HTTP trafiği — Yeni bir dosyaya gelen POST istekleri, bir resim dosyasına yapılan POST çağrıları veya bir sayfaya yalnızca bir iki kaynaktan erişilmesi.
• Beklenmedik ağ bağlantıları — Web sunucusunun dışarıya ya da iç ağdaki sistemlere alışılmadık bağlantılar başlatması.
• Kalıcılık izleri — Sunucuda sonradan açılmış yönetici hesapları, yeni zamanlanmış görevler veya web sunucusu kullanıcısına verilmiş beklenmedik yazma izinleri.

CISA uyarısı, antivirüs araçlarının webshell tespitinde sıklıkla zayıf kaldığını da vurgular. Webshell'ler küçük, kolayca değiştirilebilen ve meşru sunucu dillerinde yazılmış dosyalar olduğundan imza tabanlı tarama tek başına yetmez; değişiklik izleme ve davranış analizi bu boşluğu kapatır.

Dosya bütünlüğü izlemeyle webshell nasıl tespit edilir?

Dosya bütünlüğü izleme (FIM), web dizinindeki dosyaların hash değerlerinden bir temel durum oluşturur ve her oluşturma, değiştirme, silme ya da yeniden adlandırma olayını bu temele göre raporlar. Böylece yeni bırakılan bir webshell de mevcut bir dosyaya eklenen tek satırlık arka kapı da görünür hâle gelir.

FIM'in mantığı basittir: Bilinen iyi durumdaki her dosyanın SHA-256 gibi kriptografik bir hash değeri kaydedilir ve içerikteki tek bir bayt değişse bile hash farklı çıkar. Konunun temelleri için FIM nedir? rehberimize göz atabilirsiniz. Webshell tespitinde asıl iş, izleme kapsamını doğru kurmaktır:

1. Web kök dizinlerini izleyin: Linux'ta /var/www/html ve sanal sunucu dizinleri, Windows ve IIS'te C:\inetpub\wwwroot ile uygulama klasörleri.
2. Yükleme dizinlerine ayrı ve daha yüksek bir önem derecesi verin; bu klasörlerde betik uzantılı yeni bir dosya neredeyse her zaman incelenmelidir.
3. Uzantı ve dosya adı kalıplarıyla kurallar yazın (*.php, *.aspx, *.jsp gibi); log ve önbellek klasörlerini gürültü üretmemeleri için ayrıca ele alın.
4. Değişikliği yapan kullanıcıyı ve süreci kaydedin. Dağıtım hesabının yazdığı dosya beklenen bir değişikliktir; w3wp.exe veya php-fpm sürecinin yazdığı yeni bir betik ise güçlü bir alarm sinyalidir.
5. Fark (diff) görünümüyle değişen satırları inceleyin; meşru bir index.php dosyasının sonuna eklenmiş tek satırlık bir eval çağrısı ancak böyle fark edilir.

Beklenen değişiklikleri ayırmak için FIM uyarılarını değişiklik yönetimi kayıtları ve dağıtım pencereleriyle eşleştirin. CISA da sunucu içeriğinin bilinen temiz bir kopyasını saklamayı ve dosya bütünlüğü izlemeyi değişiklik yönetimiyle birlikte kullanmayı önerir. Logchase dosya bütünlüğü izleme bu olayları kullanıcı ve süreç bağlamıyla birlikte, önem derecesine göre uyarı olarak sunar.

Loglardan webshell nasıl tespit edilir?

Webshell iki yerde iz bırakır: web sunucusunun erişim logunda yeni dosyaya gelen isteklerde ve işletim sisteminin süreç olaylarında, web sunucusu altında başlayan komutlarda. Bu iki kaynağı FIM olaylarıyla aynı zaman çizelgesinde birleştirmek, en güvenilir tespit yoludur.

Web sunucusu erişim logları

Apache, Nginx ve IIS erişim logları her isteğin kaynağını, yolunu, HTTP yöntemini, yanıt kodunu ve kullanıcı aracısını (user agent) kaydeder. Yükleme dizinindeki bir betiğe gelen ve 200 dönen POST isteklerine, cmd= gibi parametrelere ve az sayıda IP adresinin eriştiği yeni yollara bakın. CISA erişim loglarında sıklık analizini önerir: Webshell'e genellikle yalnızca onu yükleyen kişi eriştiği için çok az kullanıcı aracısı ve yönlendiren (referrer) çeşidi görülür.

203.0.113.45 - - [12/May/2026:11:03:21 +0300] "POST /uploads/2026/05/thumb.php HTTP/1.1" 200 312 "-" "python-requests/2.31"

Süreç oluşturma olayları

Windows'ta süreç oluşturma denetimi açıkken güvenlik loguna yazılan 4688 olayı, yeni bir sürecin başladığını gösterir; komut satırını içermesi için ayrıca ilgili grup ilkesinin etkinleştirilmesi gerekir. Sysmon kullanıyorsanız Olay 1 (süreç oluşturma) ve Olay 3 (ağ bağlantısı) ek bağlam sağlar. Linux'ta auditd ile execve çağrılarını izleyerek www-data kullanıcısının çalıştırdığı komutları kaydedebilirsiniz. MITRE ATT&CK'in tespit önerisi tam olarak bu zinciri hedefler: web dizininde yeni dosya, ardından web sunucusu sürecinin komut kabuğu başlatması.

EventID=4688
ParentProcess=C:\Windows\System32\inetsrv\w3wp.exe
NewProcess=C:\Windows\System32\cmd.exe
CommandLine="cmd.exe /c whoami"

Webshell bulunduğunda ne yapılmalı?

Dosyayı hemen silmek yerine önce sunucuyu sınırlandırın ve kanıtları koruyun; ardından saldırganın nasıl girdiğini ve nereye ulaştığını belirleyin. Giriş noktası kapatılmadan silinen bir webshell kısa sürede geri gelebilir.

1. Sınırlandırın — Sunucuyu yük dengeleyiciden çıkarın veya şüpheli kaynak IP adreslerini engelleyin; mümkünse sunucunun ağ erişimini kısıtlayın.
2. Kanıtları koruyun — Webshell dosyasının bir kopyasını, hash değerini, erişim ve süreç loglarını saklayın; dosyanın zaman bilgilerini silmeden önce kaydedin.
3. Kapsamı belirleyin — Dosyanın ilk ne zaman oluştuğunu, hangi IP adreslerinin eriştiğini ve hangi komutların çalıştığını bulun; aynı hash veya kod kalıbına sahip başka dosyaları ve iç ağa açılan bağlantıları arayın.
4. Temizleyin ve açığı kapatın — Tüm webshell'leri, yeni hesapları ve zamanlanmış görevleri kaldırın; zafiyetli bileşeni güncelleyin ve dosya yükleme kurallarını sıkılaştırın.
5. Kimlik bilgilerini yenileyin — Yapılandırma dosyalarındaki veritabanı parolaları, API anahtarları ve yönetici hesapları ele geçirilmiş kabul edilmelidir.
6. Temiz kopyadan geri yükleyin — Uygulamayı bilinen temiz bir sürümden geri yükleyin ve aynı dizinleri bir süre yakından izleyin.

Bu sıralama, NIST'in olay müdahale rehberinin uzun süre referans alınan 2. sürümündeki yaşam döngüsüyle örtüşür: hazırlık; tespit ve analiz; sınırlandırma, temizleme ve kurtarma; olay sonrası değerlendirme. Nisan 2025'te yayımlanan NIST SP 800-61 Rev. 3, aynı önerileri NIST Siber Güvenlik Çerçevesi (CSF) 2.0 ile ilişkilendirir. Olayda kişisel verilerin etkilenmiş olabileceğini düşünüyorsanız KVKK kapsamındaki veri ihlali bildirim yükümlülüğünü hukuk ekibinizle değerlendirin.