Web Shell, Backdoor, Hacklink ve Zararlı Kod Türleri: 2026 Teknik Rehber

CISA ve MITRE ATT&CK, web shell kullanımını T1505.003 altında sunucu yazılım bileşeni üzerinden kalıcılık tekniği olarak ele alır. Web sunucusunun zaten internete açık olması saldırgan açısından avantajdır; zararlı dosya normal uygulama trafiğine karışabilir.

Bir dosyanın “shell” olup olmadığı yalnız dosya adına göre anlaşılmaz. index.php, class.php, wp-info.php gibi sıradan isimler kullanılabilir veya zararlı kod meşru bir dosyanın içine gömülebilir. Bu nedenle dosya bütünlüğü, son değişiklik zamanı, çağrıldığı URL ve çalışma zamanı davranışı birlikte değerlendirilir.

Microsoft Defender Security Research Team’in Nisan 2026 araştırması, Linux hosting ortamlarında cookie değerlerini kontrol kanalı olarak kullanan PHP webshell’lerin normal trafik altında hareketsiz kalabildiğini anlatıyor. Bazı örneklerde kritik fonksiyon adları çalışma anında oluşturulduğu için basit grep kontrolleri yeterli olmayabiliyor.

Savunma tarafında yalnız “eval(” aramak yerine web sunucusu prosesinin beklenmedik shell process başlatması, cron tarafından web dizinine PHP yazılması, hosting panelinden olağan dışı görev oluşturulması ve şüpheli cookie kalıpları gibi davranış sinyalleri de incelenmelidir.

base64_decode, gzinflate, str_rot13 veya dinamik fonksiyon çağrısı tek başına malware kanıtı değildir. Lisanslı yazılımlar, cache mekanizmaları veya meşru paketler de benzer fonksiyonları kullanabilir. Şüphe; kodun yüksek oranda gizlenmiş olması, input ile execution zinciri, beklenmeyen dizin konumu ve yakın zamanda yapılan değişikliklerle artar.

Dosyayı çalıştırmadan incelemek için hash alın, metin bloklarını ayırın, kullanılan PHP superglobal’lerini ve dış girdinin hangi sink’e ulaştığını takip edin. Statik analiz sonucu production üzerinde bilinmeyen payload çalıştırılmamalıdır.

sha256sum public_html/supheli.php

grep -nE "\$_(GET|POST|COOKIE|REQUEST|SERVER)|eval|base64_decode|gzinflate|shell_exec|system|exec|passthru|proc_open" public_html/supheli.php

php -l public_html/supheli.php

Hayır. Web shell kalıcı erişim veya uzaktan işlem için kullanılan sunucu tarafı araçtır; hacklink ise ele geçirilmiş siteden başka sitelere SEO değeri aktarmak için izinsiz link yerleştirme pratiğidir. Aynı saldırıda ikisi birlikte bulunabilir fakat temizleme adımları farklıdır.

Hacklink tema footer’ında, veritabanı option alanında, JavaScript ile DOM’a sonradan eklenmiş şekilde veya yalnız botlara sunulan cloaked HTML içinde bulunabilir. Google, arama motoruna görünür fakat kullanıcıya gizli link/metin eklenmesini spam politikalarında açıkça tanımlar.

Google’ın hacked content açıklamasında yönlendirmelerin referrer, user-agent veya cihaz türüne göre değişebileceği belirtilir. Bu yüzden site yöneticisi URL’yi doğrudan açtığında sorun görmezken Google sonucundan gelen kullanıcı spam sayfaya gidebilir.

İncelemede farklı User-Agent değerleri, mobil/masaüstü, Google referer, temiz tarayıcı profili ve CDN cache durumu karşılaştırılır. Amaç saldırıyı taklit etmek değil, sunucunun farklı isteklere verdiği yanıtların aynı olup olmadığını doğrulamaktır.

Bir temizleme vakasında yalnız görünen shell kaldırılırsa başka bir mekanizma dosyayı tekrar oluşturabilir. Cron kayıtları, .user.ini auto_prepend_file, .htaccess rewrite, CMS mu-plugin, özel bootstrap dosyaları ve panel zamanlanmış görevleri özellikle kontrol edilir.

Cron içinde çok sık çalışan base64/curl/wget veya webroot’a çıktı yazan komutlar şüpheli olabilir. Ancak sistem bakım görevleri de bu araçları kullanabildiğinden görev sahibi, zaman, hedef yol ve beklenen işlev birlikte değerlendirilmelidir.

crontab -l

grep -RIn "auto_prepend_file\|auto_append_file" /home /var/www 2>/dev/null

find public_html -type f -mmin -60 -print

Sağlıklı triage dört katmanı birleştirir: dosya sinyali, request sinyali, process sinyali ve persistence sinyali. Şüpheli fonksiyon + POST isteği + php-fpm’den shell process + cron kaydı aynı zaman aralığında görülüyorsa risk, yalnız tek dosyada base64_decode bulunmasına göre çok daha yüksektir.

Dosyanın malware olup olmadığına karar verilmeden önce uygulamanın bilinen sürümüyle diff, paket checksum doğrulaması ve varsa vendor kaynağı yapılmalıdır. WordPress core gibi imzalı/standart bileşenlerde checksum karşılaştırması özellikle değerlidir.

Upload dizinlerinde script execution kapatılması, dosyaların webroot dışında tutulması, uygulama kullanıcısına minimum filesystem yetkisi verilmesi, panel/SSH MFA, güncel PHP ve framework kullanımı, WAF, güvenli upload validasyonu ve düzenli bütünlük izleme temel savunma katmanlarıdır.

OWASP File Upload Cheat Sheet, yalnız uzantıya veya Content-Type başlığına güvenilmemesini; allowlist, dosya imzası, uygulama tarafından üretilen dosya adı, boyut limiti, yetkilendirme ve mümkünse webroot dışı depolama gibi katmanların birlikte kullanılmasını önerir.

Şüpheli dosya listesi, hash ve konum bilgileri; değiştirilmiş dosyalar; olası kalıcılık noktaları; Google spam/hacklink bulguları; panel ve log zaman çizgisi; tespit edilen uygulama güvenlik riskleri ve düzeltme önerileri tek raporda toplanır.

İnceleme sırasında zararlı dosyalar üretim üzerinde çalıştırılmaz. Gerekli dinamik doğrulamalar yalnız yetkilendirilmiş izole kopyada yapılır ve amaç savunma doğrulamasıdır.