Arama Yap Mesaj Gönder
Biz Sizi Arayalım
+90
X

Lütfen Ülke (Bölge) Seçiniz

Türkiye (Türkçe)Türkiye (Türkçe) Almanya (German)Almanya (German) Worldwide (English)Worldwide (English)
X

Lütfen Para Birimi Seçiniz

Türk Lirası $ US Dollar Euro
X

Lütfen Ülke (Bölge) Seçiniz

Türkiye (Türkçe)Türkiye (Türkçe) Almanya (German)Almanya (German) Worldwide (English)Worldwide (English)
X

Lütfen Para Birimi Seçiniz

Türk Lirası $ US Dollar Euro

Bize Ulaşın

Konum Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
OLAY MÜDAHALESİ · 2026

Sunucum Hacklendi mi? Web Sitesi ve Sunucu Güvenlik Kontrolü

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.

Eka Sunucu teknik ekibinin web sitesi ve sunucu güvenlik olayı inceleme çalışması
Teknik inceleme görseli
Siteyi hemen rastgele silip yeniden kurmayın; önce yedek ve kanıt kopyası alın.
Şüpheli dosyanın değiştirilme zamanını, erişim logları ve panel hareketleriyle eşleştirin.
uploads, cache, tmp, images gibi normalde PHP çalıştırmaması gereken alanları ayrıca kontrol edin.
Cron, .user.ini, .htaccess ve yeni yönetici hesaplarını kalıcılık açısından inceleyin.
Google spam görünüyorsa dosya temizliği ile indeks temizliğini ayrı süreçler olarak yönetin.

İçindekiler

  1. İlk 15 dakikada ne yapılmalı?
  2. Web sitesinin hacklendiğini düşündüren 20+ belirti
  3. Shell ve backdoor için dosya sistemi nasıl taranır?
  4. Shell dosyasını siliyorum ama neden geri geliyor?
  5. Google’da bahis, casino, slot veya anlamsız ? parametreli URL’ler görünüyorsa
  6. cPanel, Plesk, FTP, SSH ve CMS hesaplarını kontrol edin
  7. Zararlı içerik veritabanından mı geliyor?
  8. Dosya zamanı ile access log nasıl eşleştirilir?
  9. Temizlik sırasında yapılmaması gerekenler
  10. Dosya, log ve kod güvenliği incelemesini nasıl yapıyoruz?
01

İlk 15 dakikada ne yapılmalı?

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.

Dosya + veritabanı yedeği alındı
Raw/access/error logları arşivlendi
Son değişiklik zamanı not edildi
Panel/FTP/SSH oturumları kontrol edildi
Temizleme öncesi ekran görüntüsü ve URL listesi kaydedildi
02

Web sitesinin hacklendiğini düşündüren 20+ belirti

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.

Google sonucu site içeriğinden farklı
Mobilde veya Google’dan gelişte yönlendirme
Sitede görünmeyen bahis/casino linkleri
CPU/RAM veya outbound trafik artışı
Spam e-posta gönderimi
Tanımadığınız yönetici/FTP hesabı
Dosya tarihleriyle uyumsuz son değişiklikler
Cron içinde web dizinine dosya yazan komutlar
03

Shell ve backdoor için dosya sistemi nasıl taranır?

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.

CLI 1
find public_html -type f -name "*.php" -mtime -7 -print
CLI 2
find public_html -type f -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -100
CLI 3
find public_html -path "*/uploads/*" -type f \( -name "*.php" -o -name "*.phtml" \) -print
CLI 4
grep -RInE "eval\s*\(|base64_decode\s*\(|gzinflate\s*\(|shell_exec\s*\(" public_html --include="*.php"
04

Shell dosyasını siliyorum ama neden geri geliyor?

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.

CLI 1
crontab -l
CLI 2
find /home \( -name .user.ini -o -name .htaccess \) 2>/dev/null
CLI 3
grep -RIn "auto_prepend_file\|auto_append_file" /home 2>/dev/null
CLI 4
find public_html -type f -mmin -180 -ls
05

Google’da bahis, casino, slot veya anlamsız ? parametreli URL’ler görünüyorsa

Google, 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.

CLI 1
site:alanadi.com casino
CLI 2
site:alanadi.com bet
CLI 3
site:alanadi.com slot
CLI 4
site:alanadi.com viagra
06

cPanel, Plesk, FTP, SSH ve CMS hesaplarını kontrol edin

Bir 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.

07

Zararlı içerik veritabanından mı geliyor?

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.

08

Dosya zamanı ile access log nasıl eşleştirilir?

Şü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.

09

Temizlik sırasında yapılmaması gerekenler

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.

10

Dosya, log ve kod güvenliği incelemesini nasıl yapıyoruz?

İ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.

Hızlı olay ön değerlendirmesi

Bu araç tarayıcınızda çalışır; seçiminizi sunucuya göndermez. Sonuç profesyonel incelemenin yerine geçmez.

Düşük sinyal
Belirtileri seçtikçe ön değerlendirme güncellenir.
EKA Web Güvenlik İnceleme

Teknik ekibe inceletin

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.

Google Spam Policiesdevelopers.google.comGoogle Security Issues Reportsupport.google.comGoogle Prevent Malwaredevelopers.google.comMicrosoft Cookie-controlled PHP webshellswww.microsoft.comCISA Web Shell Guidancewww.cisa.gov

Sık sorulan sorular

Shell dosyasını silmek yeterli mi?

Hayır. Dosyayı oluşturan cron, ikinci backdoor, çalınmış panel hesabı veya uygulama açığı devam ediyorsa tekrar oluşabilir.

Sitem normal açılıyor ama yine de hacklenmiş olabilir mi?

Evet. Cloaking, cookie/header kontrollü kod veya yalnız belirli referrer/device koşullarında çalışan yönlendirmeler normal ziyarette görünmeyebilir.

Google’da bahis sitesi görünmek dosyada casino kelimesi olduğu anlamına mı gelir?

Hayır. İçerik veritabanından, rewrite kuralından, dinamik router’dan veya Googlebot’a özel yanıttan üretilebilir.

Hacker IP’sini bulabilir miyiz?

Loglardan olayla ilişkili IP adresleri çıkarılabilir; ancak bu IP gerçek kişinin kimliğini kesin olarak kanıtlamaz.

Analiz için şifre göndermem gerekiyor mu?

İ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.

24–72 saatte kesin temizlenir mi?

Bu bir planlama aralığıdır, garanti süre değildir. Kapsam ön inceleme sonrasında belirlenir.

WordPress çekirdeğini yeniden yüklemek yeterli mi?

Plugin, theme, uploads, veritabanı, cron ve hesaplar temizlenmediyse tek başına yeterli olmayabilir.

Aynı sunucudaki diğer siteler kontrol edilmeli mi?

Ortak kullanıcı, ortak parola veya aynı web sunucusu bağlamı varsa çapraz etki açısından kontrol edilmesi önerilir.

Top