# PHP2Shell saldırısına uğradınız mı? Hangi loglara, nasıl bakılır > PHP2Shell (CVE-2026-109618, CVE-2026-109619) istismarını tespit etmek için bakılacak loglar, aranacak izler, örnek komutlar ve olay müdahalesi adımları. - URL: https://twinlikee.com/blog/php2shell-saldiri-tespiti-log-analizi/ - Published: 2026-10-25 - Category: Siber Güvenlik - Tags: PHP2Shell, olay müdahalesi, log analizi, PHP-FPM, tehdit avı - Publisher: Twinlike (https://twinlikee.com) 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](https://twinlikee.com/blog/php2shell-kritik-php-zafiyetleri-yama-rehberi/) 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//logs/` altındadır. Aranacak satırlar: ```bash # 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: ```bash 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. ```bash # 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 `/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. ```bash # 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](https://twinlikee.com/downloads/php2shell_scan.py) · [SHA-256 özeti](https://twinlikee.com/downloads/php2shell_scan.py.sha256) ```bash 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](https://twinlikee.com/hizmetler/siber-guvenlik/) ekibimizle çalışabilirsiniz. Sunucularınızın güncel ve izlenir kalmasını istiyorsanız [Sunucu & BT Yönetimi](https://twinlikee.com/hizmetler/sunucu-ve-bt-yonetimi/) sayfamıza bakın ya da doğrudan [bize yazın](https://twinlikee.com/iletisim/). *Kaynaklar: [Datadog Security Labs: PHP2Shell](https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/), [Tanium: Responding to PHP2Shell](https://www.tanium.com/blog/php2shell-responding-to-cve-2026-109618-and-cve-2026-109619), [Huntress: PHP2Shell](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities). Bilgiler 25 Ekim 2026 itibarıyla günceldir.* ## FAQ ### Loglarda hiçbir iz bulamadım. Güvende miyim? Hayır, bu kesin bir güvence değildir. Standart erişim logları POST gövdesini kaydetmez ve başarılı bir istismar her zaman çökme bırakmaz. Loglar döndürülmüş ya da silinmiş de olabilir. Önce PHP'yi güncelleyin, sonra süreç, dosya sistemi ve ağ çıkış kayıtlarıyla doğrulayın. ### Sunucuda tek bir "Allowed memory size exhausted" hatası var. Bu saldırı mı? Tek başına değil. Bellek tükenmesi meşru iş yüklerinde de sık görülür. Aynı dakikalarda aynı IP'den yoğun POST, max_input_vars uyarıları ve worker çökmeleri birlikte görülüyorsa durum şüphelidir. ### İz bulursam ilk ne yapmalıyım? Sunucuyu ağdan yalıtın, logların ve belleğin kopyasını alın, ardından PHP'yi güncelleyip worker'ları yeniden başlatın. Parolaları ve API anahtarlarını yenileyin. Kişisel veri etkilendiyse KVKK'ya göre 72 saat içinde bildirim yapmanız gerekebilir.