PHP2Shell saldırısına uğradınız mı? Hangi loglara, nasıl bakılır

PHP2Shell için yamalar 21 Ekim’de yayımlandı, ama yamayı geçtiğiniz gün saldırı penceresi kapanmadı: Datadog’a göre AWS istismar girişimlerini 17 Ekim’de, yani açıklamadan dört gün önce görmüştü. 21 Ekim’den itibaren aktif istismar ve toplu tarama bildiriliyor. Bu yazıda, yamadan önceki günlerde sunucunuzun saldırıya uğrayıp uğramadığını nasıl anlayacağınızı anlatıyoruz: hangi loglara bakılır, neler aranır ve iz bulursanız ne yapılır.

Zafiyetin ne olduğunu ve nasıl yamalanacağını önceki yazımızda anlattık. Henüz güncellemediyseniz önce oradan başlayın.

Önce gerçekçi bir beklenti

Kamuya açık, resmî bir IOC listesi (IP adresleri, dosya özetleri) henüz yok. Tespit bu yüzden davranışa ve dolaylı izlere dayanıyor:

• İstismar, PHP isteği ayrıştırırken tetikleniyor. Uygulama kodunuz hiç çalışmamış olabilir; uygulama loglarında iz beklemeyin.
• Standart erişim logları POST gövdesini kaydetmez. Saldırıda kullanılan form alanlarını ancak gövdeyi kaydeden bir WAF (ör. ModSecurity audit log) gösterir.
• Başarılı istismar her zaman worker çökmesi bırakmaz ve HTTP 200 dönen bir istek de zararsız olmayabilir.

En güçlü kanıt, web sunucusunun ya da PHP worker’ının beklenmedik bir süreç başlatmasıdır. Loglar bu kanıtın ne zaman ve nereden geldiğini bulmanıza yardım eder.

İncelemeye 17 Ekim’den yamanın uygulandığı ana kadarki aralıkla başlayın.

1. PHP ve web sunucusu hata logları

Saldırının yan etkileri en çok burada görünür. Bakılacak yerler:

• Apache: /var/log/apache2/error.log veya /var/log/httpd/error_log
• Nginx: /var/log/nginx/error.log
• PHP-FPM: /var/log/php*-fpm.log ve havuzların error_log dosyaları
• CloudPanel ve benzeri panellerde site logları genellikle /home/<kullanıcı>/logs/ altındadır.

Aranacak satırlar:

# Bellek tükenmesi, çok fazla form alanı, aşırı büyük POST
grep -E "Allowed memory size of [0-9]+ bytes exhausted|Input variables exceeded|POST Content-Length of" \
  /var/log/apache2/error.log* /var/log/php*-fpm.log*

# Worker çökmeleri (Apache ve PHP-FPM)
grep -E "exit signal Segmentation fault|exited on signal (11|6)" \
  /var/log/apache2/error.log* /var/log/php*-fpm.log*

# Bellek bozulması mesajları
grep -E "zend_mm_heap corrupted|corrupted double-linked list|free\(\): invalid" \
  /var/log/apache2/error.log* /var/log/php*-fpm.log*

Datadog’un örneklerine göre bellek tükenmesi satırları istek başlatılırken oluşur ve konum olarak Unknown on line 0 gösterir. Bu satırları tek başına değil, zamanlarıyla birlikte değerlendirin: birkaç dakika içinde art arda gelen bellek hataları, max_input_vars uyarıları ve çökmeler birlikte anlam kazanır.

2. Sistem ve çekirdek logları

Çöken PHP veya Apache süreçleri çekirdek loguna da düşer:

grep -E "segfault at .* in (libphp|php|apache2|httpd)" /var/log/syslog* /var/log/kern.log* /var/log/messages*
journalctl -k --since "2026-10-17" | grep -i segfault
journalctl -u 'php*-fpm*' --since "2026-10-17" | grep -iE "signal|exited"

3. Erişim logları: POST yoğunluğu

Erişim logları gövdeyi göstermez, ama saldırının şeklini gösterir. İstismar denemeleri genellikle aynı adrese kısa sürede çok sayıda POST üretir ve bunların bir kısmı 500 ya da bağlantı kopması ile biter.

# En çok POST gönderen IP ve adresler
awk '$6=="\"POST" {print $1, $7}' /var/log/apache2/access.log* | sort | uniq -c | sort -rn | head -20

# Belirli bir IP'nin POST'ları, zamanı ve durum koduyla
grep '"POST ' /var/log/apache2/access.log | grep '^203.0.113.50 ' | awk '{print $4, $7, $9}'

Şüpheli bir IP bulduğunuzda, aynı dakikalara denk gelen hata logu satırlarıyla karşılaştırın. Zaman korelasyonu bu soruşturmanın en değerli adımıdır. Bazı tarama araçları kendine özgü bir User-Agent ile gelir; sitenizi kontrol eden servisler dışındaki tuhaf User-Agent’ları da not edin. Bunlar değiştirilebileceği için kesin kanıt sayılmaz.

4. WAF ve ModSecurity audit logları

İstek gövdesini kaydeden bir WAF’ınız varsa en net izler buradadır. Datadog’un yayımladığı işaretler:

• Uygulamanızın normalde kullanmadığı PHPSESSID ve PHP_SESSION_UPLOAD_PROGRESS adlı form alanları
• Çok sayıda parçalı (multipart) alan, çok uzun alan adları, iç içe köşeli parantezli adlar
• Dosya adlarında <?php ya da serileştirilmiş nesne parçaları (|O:)
• Yanıtta alışılmadık uzunlukta veya standart dışı karakterler içeren Set-Cookie: PHPSESSID= değerleri; bu, bellek sızıntısına işaret edebilir
• Büyük Content-Length bildirip hiç tamamlanmayan yüklemeler

grep -E 'name="(PHPSESSID|PHP_SESSION_UPLOAD_PROGRESS)"' /var/log/modsec_audit.log*
grep -E 'Set-Cookie: PHPSESSID=[^;]{60,}' /var/log/modsec_audit.log*

Bu alanlar meşru dosya yükleme ilerleme çubuklarında da görülebilir. Uygulamanız bu özelliği kullanıyorsa sonuçları dikkatle ayırın.

5. Süreçler ve ağ bağlantıları

Saldırgan kod çalıştırabildiyse bu en çok süreç ağacında görünür: apache2, php-fpm ya da nginx altında başlayan sh, bash, curl, wget, nc, python, perl gibi süreçler.

# Web kullanıcısının süreçleri, ebeveynleriyle
ps -eo pid,ppid,user,lstart,args --forest | grep -E -A3 "apache2|php-fpm|nginx" | grep -vE "^\s*$"

# Web sürecinin açık dış bağlantıları
ss -tpn | grep -E "php|apache2|nginx|httpd"

# Geçici dizinlerden çalışan süreçler
ls -l /proc/*/exe 2>/dev/null | grep -E "/tmp/|/dev/shm/|/var/tmp/"

Bu kontrol yalnızca o anı gösterir. Geçmişi görmek için EDR, auditd ya da güvenlik duvarı ve proxy çıkış kayıtlarına bakın.

6. Dosya sistemi ve kalıcılık

Saldırganlar erişimi kaybetmemek için genellikle webshell ve zamanlanmış görev bırakır.

# 17 Ekim'den sonra değişen PHP dosyaları, sahibiyle
find /var/www /home/*/htdocs -name "*.php" -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' 2>/dev/null

# Webshell'lerde sık görülen kalıplar
grep -rlE '(eval|assert|system|passthru|shell_exec)\s*\(\s*(base64_decode|\$_(GET|POST|REQUEST|COOKIE))' /var/www /home/*/htdocs 2>/dev/null

# Web kullanıcısının geçici dizinlere bıraktığı dosyalar
find /tmp /var/tmp /dev/shm -user www-data -newermt "2026-10-17" -ls 2>/dev/null

# Zamanlanmış görevler, yeni kullanıcılar ve SSH anahtarları
crontab -u www-data -l; ls -la /etc/cron.* /var/spool/cron/ 2>/dev/null
grep -vE "nologin|false" /etc/passwd; find / -name authorized_keys -newermt "2026-10-17" 2>/dev/null

Değişiklik zamanı (mtime) geri alınabilir; şüpheli dosyalarda stat ile durum değişim zamanına (ctime) da bakın. Uygulama dosyalarındaki değişiklikleri dağıtım kayıtlarınızla karşılaştırın.

Sınırlamalar

• “Bulgu yok”, “etkilenmedik” demek değildir. Gövde kaydı olmadan istismar yalnızca dolaylı iz bırakır.
• Log döndürme eski kayıtları silmiş olabilir; .gz arşivlerini de tarayın (zgrep).
• Başarılı bir saldırgan yerel logları temizlemiş olabilir. Uzak syslog, SIEM ya da Cloudflare gibi bir ara katmanın kayıtlarıyla çapraz kontrol yapın.
• Zaman damgalarını aynı saat dilimine çevirerek karşılaştırın.

Ayrıca: sürüm envanteri

Tespitin yanında hangi sunucunun hâlâ etkilenen sürümde olduğunu da bilmeniz gerekir. Bunun için yazdığımız, internet bağlantısı gerektirmeyen php2shell_scan.py aracı sunucudaki bütün PHP kurulumlarını bulur, sürümlerini kontrol eder ve güncelleme önerisi verir. Python 3.6 ve üstüyle çalışır, ek paket istemez; banka gibi kapalı ağlarda da kullanılabilir.

• İndirin: php2shell_scan.py · SHA-256 özeti

curl -O https://twinlikee.com/downloads/php2shell_scan.py
curl -O https://twinlikee.com/downloads/php2shell_scan.py.sha256
sha256sum -c php2shell_scan.py.sha256        # dosyanın bozulmadığını doğrulayın
sudo python3 php2shell_scan.py               # ekrana özet
sudo python3 php2shell_scan.py --json rapor.json

Araç yalnızca okur; hiçbir dosyayı değiştirmez. Kapalı ağda kullanacaksanız dosyayı internete bağlı bir makinede indirip özetini doğruladıktan sonra taşıyın.

İz bulursanız: olay müdahalesi adımları

1. Yalıtın: sunucuyu ağdan ayırın ya da yalnızca yönetim erişimine izin verin. Kapatmayın; bellek kanıt olabilir.
2. Kanıtı koruyun: logların, şüpheli dosyaların ve mümkünse belleğin kopyasını alın ve sunucu dışına taşıyın.
3. Yamalayın: PHP’yi 8.5.12, 8.4.27, 8.3.36 veya 8.2.35’e güncelleyin ve bütün worker’ları yeniden başlatın.
4. Kalıcılığı temizleyin: webshell’leri, cron görevlerini, yeni kullanıcıları ve SSH anahtarlarını kaldırın. Emin değilseniz temiz bir yedekten yeniden kurun.
5. Sırları yenileyin: veritabanı parolaları, .env içindeki API anahtarları, ödeme ve e-posta servis anahtarları.
6. Bildirin: kişisel veriler etkilendiyse KVKK kapsamında 72 saat içinde Kurul’a bildirim yükümlülüğü doğabilir.

Sonuç

PHP2Shell’de yamayı uygulamak işin yarısı. Diğer yarısı, yamadan önceki günlerde içeri girilip girilmediğini anlamak. Hata loglarındaki bellek ve çökme izlerini, erişim loglarındaki POST yoğunluğuyla zaman üzerinden eşleştirin, ardından süreç ve dosya sistemi kontrolleriyle doğrulayın. Gövdeyi kaydeden bir WAF’ınız yoksa bu olay, kurmak için iyi bir neden.

Loglarınızı birlikte incelemek, şüpheli bir bulguyu doğrulamak ya da olay müdahalesi için Siber Güvenlik ekibimizle çalışabilirsiniz. Sunucularınızın güncel ve izlenir kalmasını istiyorsanız Sunucu & BT Yönetimi sayfamıza bakın ya da doğrudan bize yazın.

Kaynaklar: Datadog Security Labs: PHP2Shell, Tanium: Responding to PHP2Shell, Huntress: PHP2Shell. Bilgiler 25 Ekim 2026 itibarıyla günceldir.

This article is also available in English — Read in English →