Bilinmeyen PHP dosyaları, silindikten sonra geri gelen shell’ler, Google’da bahis/casino başlıkları, spam URL’ler, yönlendirmeler, anormal CPU kullanımı veya tanımadığınız yönetici hesapları tek başına aynı nedeni göstermez. Bu rehber, semptomu kanıttan ayırarak dosya sistemi, uygulama, veritabanı, panel hesapları ve erişim loglarını aynı zaman çizgisinde değerlendirmenize yardımcı olur.
Site aktif saldırı altındaysa ilk hedef “hemen her şeyi silmek” değil, etkiyi sınırlamak ve inceleme için güvenilir bir kopya oluşturmaktır. Dosyaların değiştirilme zamanlarını, erişim loglarını ve şüpheli kullanıcıları kaybetmeden önce tam dosya yedeği, veritabanı dökümü ve mümkünse log arşivi alın.
Production sistemi üzerinde kontrolsüz deneme yapmak hem kanıtı bozabilir hem de hizmet kesintisini büyütebilir. Şüpheli dosyaları önce karantina kopyasına alın; temiz kopyayı staging veya izole bir ortamda doğrulayın. Hosting paneli, FTP/SFTP, SSH, veritabanı ve CMS yönetici parolalarını farklı ve güçlü parolalarla değiştirin; mümkün olan hesaplarda MFA açın.
Bilinmeyen .php/.phtml dosyaları, site kökünde anlamsız isimler, uploads altında çalıştırılabilir dosyalar, .htaccess veya .user.ini değişiklikleri, silinen dosyanın tekrar oluşması, beklenmeyen cron görevleri, yeni admin kullanıcıları ve nedeni açıklanamayan dış bağlantılar güçlü inceleme sinyalleridir.
Tarayıcıda normal görünen bir site de saldırıya uğramış olabilir. Googlebot, mobil cihaz, belirli referer veya özel cookie geldiğinde farklı davranan kodlar normal ziyarette görünmeyebilir. Microsoft’un 2026 araştırması, cookie ile etkinleşen ve rutin trafikte sessiz kalan PHP webshell örneklerini özellikle vurguluyor.
Tek bir kelimeye göre dosya silmek doğru değildir. eval, base64_decode, gzinflate, shell_exec, system, exec, passthru, proc_open veya popen gibi fonksiyonlar meşru yazılımlarda da bulunabilir. Asıl değer; bu işaretlerin kullanıcı girdisi, obfuscation, son değişiklik zamanı ve beklenmeyen dizin konumuyla birlikte değerlendirilmesidir.
Özellikle webroot, uploads, images, cache, tmp, vendor içinde sonradan eklenmiş PHP dosyaları; çift uzantılı dosyalar; .ico/.jpg gibi görünen fakat PHP içeren dosyalar ve çok yüksek entropili/uzun kod blokları incelenmelidir. Dosyanın hash’i, sahibi, izinleri ve mtime/ctime bilgisi olay zaman çizgisinde tutulmalıdır.
find public_html -type f -name "*.php" -mtime -7 -printfind public_html -type f -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -100find public_html -path "*/uploads/*" -type f \( -name "*.php" -o -name "*.phtml" \) -printgrep -RInE "eval\s*\(|base64_decode\s*\(|gzinflate\s*\(|shell_exec\s*\(" public_html --include="*.php"Dosyanın geri gelmesi çoğu zaman kalıcılık mekanizmasının temizlenmediğini gösterir. Cron, systemd timer, hosting panel zamanlanmış görevi, .user.ini auto_prepend_file, .htaccess rewrite, CMS eklentisi, veritabanına gömülmüş payload veya başka bir backdoor temizlenen dosyayı tekrar oluşturabilir.
Microsoft’un Nisan 2026 tarihli Linux hosting araştırmasında saldırganların cPanel benzeri meşru yönetim akışlarından cron kaydı oluşturarak kaldırılan PHP loader’ı tekrar ürettiği vakalar anlatılıyor. Bu nedenle “shell.php silindi” ile “olay kapandı” aynı şey değildir.
crontab -lfind /home \( -name .user.ini -o -name .htaccess \) 2>/dev/nullgrep -RIn "auto_prepend_file\|auto_append_file" /home 2>/dev/nullfind public_html -type f -mmin -180 -lsGoogle, ele geçirilmiş sitelerde içerik enjeksiyonu, gizli linkler, cloaking ve bazı ziyaretçileri spam sayfalara yönlendiren kodları hacked content kapsamında ele alıyor. Doğrudan URL açıldığında sorun görünmeyip yalnız Google sonucundan tıklamada yönlendirme yaşanması da mümkündür.
site:alanadi.tld casino, site:alanadi.tld bet, site:alanadi.tld slot ve site:alanadi.tld viagra gibi sorgularla indeks görünürlüğünü hızlıca kontrol edebilirsiniz. Ancak temizleme kararı yalnız bu sorgulara göre verilmez; Search Console Security Issues, URL Inspection, sitemap, canonical, server response ve kaynak kodu birlikte incelenir.
site:alanadi.com casinosite:alanadi.com betsite:alanadi.com slotsite:alanadi.com viagraBir saldırının giriş noktası her zaman uygulama açığı değildir. Sızmış FTP parolası, yeniden kullanılan panel şifresi, kötü amaçlı tarayıcı eklentisi veya çalınmış oturum bilgisi de dosya değiştirilmesine yol açabilir. Panel hareketleri ile dosya zamanlarını eşleştirmek bu ayrımı yapmada önemlidir.
Parola değişiminden sonra eski oturumların kapatılması, tanımadığınız API token/SSH key’lerin kaldırılması ve yalnız gerekli hesapların tutulması gerekir. Aynı sunucudaki diğer domainler de aynı kullanıcı veya ortak erişim bilgilerini kullanıyorsa çapraz etki açısından kontrol edilmelidir.
Hacklink veya spam içerik her zaman fiziksel PHP dosyasında bulunmaz. CMS ayarları, widget/footer alanları, post meta, option tabloları, tema ayarları veya özel içerik tablolarına eklenmiş HTML/JavaScript ziyaretçiye dinamik olarak basılabilir.
Veritabanında toplu arama yaparken doğrudan üretim verisi üzerinde replace çalıştırmak yerine önce dump alın. Şüpheli domain, casino/bet kelimeleri, iframe/script parçaları ve son oluşturulan yönetici hesaplarını inceleyin. WordPress, OpenCart, Laravel ve özel PHP projelerinde tablo yapısı farklı olduğu için “tek SQL her şeyi temizler” yaklaşımı güvenli değildir.
Şüpheli dosyanın yaklaşık oluşturulma veya değiştirilme zamanını belirleyin. Örneğin 02:14 civarında oluşan bir dosya için 02:10–02:20 aralığındaki POST/PUT istekleri, upload endpoint’leri, 200/302 yanıtları ve hemen ardından gelen şüpheli GET istekleri incelenebilir.
Aynı IP’nin logda görünmesi gerçek kişinin kimliğini kanıtlamaz. CDN, reverse proxy, VPN, botnet veya ele geçirilmiş başka bir sunucu kullanılabilir. IP bir teknik göstergedir; karar, zaman, URL, yöntem, kullanıcı hesabı ve dosya değişikliği gibi birden fazla sinyal üzerinden verilmelidir.
Tüm PHP dosyalarında toplu string silme, bilinmeyen kodu anlamadan replace etme, logları temizleme, production veritabanında yedeksiz SQL çalıştırma ve sadece ana shell dosyasını kaldırıp parolaları değiştirmeden sistemi açma en sık görülen hatalardır.
Temiz bir CMS çekirdeği veya sürüm kontrollü kaynak varsa dosyaları referans kopyayla karşılaştırmak daha güvenilir sonuç verir. Özel yazılımda ise uygulama davranışı bozulmadan zararlı kodu ayırmak için dosya bazlı diff ve kontrollü test gerekir.
İnceleme kapsamına göre ZIP/site yedeği, SQL dump, cPanel/Plesk logları, Search Console ekranları veya yetkilendirilmiş SSH erişimi kullanılır. Önce statik dosya analizi, son değişiklikler, şüpheli fonksiyon zincirleri, kalıcılık noktaları ve spam URL yapısı çıkarılır; ardından log zaman çizgisi ve uygulama güvenlik kontrolleri değerlendirilir.
Temizleme sonrasında yalnız müşterinin açıkça yetkilendirdiği kopya veya staging ortamında kontrollü doğrulama yapılır. Teslimatta tespit edilen dosyalar, değişiklikler, olası giriş noktaları, riskler ve tekrar bulaşmayı azaltacak hardening önerileri raporlanır. Google indeksindeki temizlenmenin teknik dosya temizliğinden ayrı ve arama motorunun yeniden tarama süresine bağlı olduğu özellikle belirtilir.
Bu araç tarayıcınızda çalışır; seçiminizi sunucuya göndermez. Sonuç profesyonel incelemenin yerine geçmez.
Standart vakalar ön inceleme sonrasında genellikle 24–72 saatlik analiz planına alınır. Süre; dosya sayısı, log erişimi, zararlı kodun yayılımı ve uygulamanın yapısına göre değişebilir.
Önemli not: Yalnız size ait veya açıkça yetkilendirildiğiniz sistemlerde test yapın.
Hayır. Dosyayı oluşturan cron, ikinci backdoor, çalınmış panel hesabı veya uygulama açığı devam ediyorsa tekrar oluşabilir.
Evet. Cloaking, cookie/header kontrollü kod veya yalnız belirli referrer/device koşullarında çalışan yönlendirmeler normal ziyarette görünmeyebilir.
Hayır. İçerik veritabanından, rewrite kuralından, dinamik router’dan veya Googlebot’a özel yanıttan üretilebilir.
Loglardan olayla ilişkili IP adresleri çıkarılabilir; ancak bu IP gerçek kişinin kimliğini kesin olarak kanıtlamaz.
İlk aşamada hayır. Site türü, belirti, yedek durumu ve varsa hata/log örnekleri yeterlidir. Gerekli erişim daha sonra güvenli kanaldan istenir.
Bu bir planlama aralığıdır, garanti süre değildir. Kapsam ön inceleme sonrasında belirlenir.
Plugin, theme, uploads, veritabanı, cron ve hesaplar temizlenmediyse tek başına yeterli olmayabilir.
Ortak kullanıcı, ortak parola veya aynı web sunucusu bağlamı varsa çapraz etki açısından kontrol edilmesi önerilir.