Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Web sitenizde virüs, zararlı kod, izinsiz yönlendirme, SEO spam, sahte yönetici hesabı, backdoor, phishing sayfası veya tekrar eden güvenlik ihlali şüphesi varsa önce belirtileri ve olası teknik katmanı ayırıyoruz. İlk ön analizde mümkün olan kontrolleri yalnızca alan adınız üzerinden yapıyor, dosya sistemi veya veritabanı erişimi gerektiren derin kontrolleri ayrıca açıklıyoruz.
İlk aşamada wp-admin, hosting, FTP, SFTP veya SSH şifresi istemiyoruz. Site adresinizi, gördüğünüz belirtinin kısa açıklamasını ve varsa Search Console ya da hosting güvenlik uyarısının ekran görüntüsünü iletmeniz yeterlidir.
Zararlı kod, yönlendirme, spam ve ihlal belirtileri
Beklenmeyen yönlendirmeler, Google sonuçlarında sizin oluşturmadığınız Japonca/Çince/kumar/ilaç sayfaları, bilinmeyen yönetici hesapları, wp-content/uploads altında çalıştırılabilir PHP dosyaları, değişen çekirdek dosyaları, zararlı JavaScript, silindikten sonra geri gelen dosyalar, Search Console Security Issues uyarıları, tarayıcıda “Aldatıcı site” uyarısı, beklenmeyen cron görevleri ve olağan dışı sunucu trafiği güçlü belirtilerdir. Fakat tek bir belirti kesin kanıt değildir; dosya, veritabanı, kullanıcı, cron, log ve sunucu katmanları birlikte değerlendirilmelidir.
Bir alan adını dışarıdan kontrol ederek her gizli backdoor dosyasını, veritabanına gömülmüş payload’ı veya sunucu seviyesindeki kompromizeyi kesin olarak görmek mümkün değildir. Dış analiz görünür belirtileri, yönlendirmeleri, tarayıcı kaynaklarını ve güvenlik uyarılarını anlamaya yarar. Kesin temizlik ve kök neden analizi için çoğu vakada dosya sistemi, veritabanı, kullanıcılar, cron görevleri, erişim logları ve gerekirse sunucu seviyesi incelenmelidir.
Bir alan adını dışarıdan kontrol ederek her gizli backdoor dosyasını, veritabanına gömülmüş payload’ı veya sunucu seviyesindeki kompromizeyi kesin olarak görmek mümkün değildir. Dış analiz görünür belirtileri, yönlendirmeleri, tarayıcı kaynaklarını ve güvenlik uyarılarını anlamaya yarar. Kesin temizlik ve kök neden analizi için çoğu vakada dosya sistemi, veritabanı, kullanıcılar, cron görevleri, erişim logları ve gerekirse sunucu seviyesi incelenmelidir.
Aynı belirti birden fazla katmandan çıkabilir. Belirtileri kanıt ve kontrol yöntemiyle eşleştiriyoruz.
| Belirti | Olası katman | İlk kontrol |
|---|---|---|
| Site başka siteye yönlendiriyor | Zararlı JavaScript, .htaccess/Nginx kuralı, eklenti/tema enjeksiyonu, veritabanı redirecti, Cloudflare Worker/Redirect Rule | Farklı cihaz/referrer testleri, redirect zinciri, HTML/JS kaynağı ve sunucu kuralları |
| Google’da Japonca/Çince sayfalar çıkıyor | SEO spam, cloaking, hacklenmiş içerik veya otomatik spam URL üretimi | site:domain araması, Search Console, sitemap, rewrite ve uygulama route kontrolü |
| Tarayıcı “Aldatıcı site” uyarısı veriyor | Phishing, social engineering veya zararlı içerik | Search Console Security Issues ve uyarıdaki örnek URL’ler |
| Siteye girince pop-up veya reklam açılıyor | Enjekte JavaScript, kompromize üçüncü taraf script, tema/eklenti veya veritabanı kodu | Network/Sources, beklenmeyen domainler ve son değişen dosyalar |
| Bilinmeyen admin hesabı oluşuyor | Yetkisiz kullanıcı oluşturma, çalınmış admin oturumu veya kalıcılık mekanizması | Kullanıcı kayıt tarihi, rol, audit ve erişim logları |
| Temizlenen dosya geri geliyor | Backdoor, cron persistence, MU plugin, sibling site veya sunucu seviyesi compromise | WP-Cron, sistem cron, mu-plugins, diğer siteler ve sunucu logları |
| Hosting antivirüsü sürekli uyarıyor | Gerçek malware, false positive veya temizlenmemiş kopya/yedek | Dosya bağlamı, hash, konum, değişim zamanı ve temiz kaynak karşılaştırması |
| CPU birden yükseldi | Bot saldırısı, brute-force, spam üretimi, miner, kötü cron veya yoğun sorgu | Access log, process list, cron ve istek dağılımı |
| Sunucudan spam mail gidiyor | Web shell, PHP mail abuse, ele geçirilmiş SMTP hesabı veya form abuse | Mail logları, script path, SMTP auth kayıtları ve mail queue |
| Dosyalarda anlamsız uzun kod var | Obfuscation olabilir; fakat her base64/encoded kod zararlı değildir | Resmî kaynak, checksum, kodun neyi çözdüğü ve çalışma bağlamı |
“Virüs” tek bir teknik problem değildir. Temizlik yöntemini saldırı ve kalıcılık türü belirler.
Saldırganın ilk açık kapatılsa bile yeniden erişebilmesini sağlayan gizli kod, kullanıcı veya erişim mekanizmasıdır. Tek görünen malware dosyasını silmek yeterli değildir.
Web üzerinden dosya veya komut işlemleri yapabilen zararlı script sınıfıdır. PHP sitelerde normal dosya adına benzeyecek şekilde saklanabilir.
Kumar, ilaç, sahte ürün veya farklı dilde binlerce yetkisiz URL üretilmesi ve bazen arama motoruna ziyaretçiden farklı içerik gösterilmesidir.
Sitenizin altında banka, kargo, sosyal medya veya ödeme hizmetini taklit eden sahte giriş ve ödeme sayfaları oluşturulmasıdır.
Ziyaretçiyi başka siteye yönlendirebilir, pop-up gösterebilir, sahte form yerleştirebilir veya uzaktaki zararlı kodu yükleyebilir.
WordPress veya başka CMS’de saldırganın kalıcı erişim için oluşturduğu yetkisiz admin hesabıdır.
Zararlı script, iframe, spam link veya redirect kodunun dosya yerine veritabanındaki option, post, widget ya da özel tabloya yazılmasıdır.
Silinen zararlı dosyayı yeniden oluşturan veya uzaktan payload indiren planlı görevin WordPress cron, sistem cron veya scheduler içinde saklanmasıdır.
WordPress core veya resmî eklenti dosyalarının beklenen sürümle uyuşmamasıdır. Her fark malware değildir; özelleştirme ve yarım güncelleme de fark yaratabilir.
Sorunun CMS dışında hosting hesabı, FTP, SSH, web sunucusu veya aynı kullanıcı altındaki başka bir siteden kaynaklanmasıdır.
Bir web sitesinin yavaşlaması, 500 hatası vermesi veya bir PHP dosyasında base64_decode görülmesi tek başına hack kanıtı değildir. Güvenlik incelemesinde belirtiler kanıtlarla ilişkilendirilmelidir. Örneğin base64, lisanslama veya veri saklama için meşru biçimde de kullanılabilir. Asıl soru kodun beklenen dosyada olup olmadığı, hangi veriyi çözdüğü ve uygulamanın normal sürümüyle uyuşup uyuşmadığıdır.
Güçlü teşhis için zaman çizgisi oluşturmak önemlidir: sorun ilk ne zaman başladı, o tarihten önce hangi eklenti/tema/modül güncellendi, yeni FTP veya admin hesabı açıldı mı, hosting uyarısı geldi mi, erişim loglarında olağandışı POST istekleri var mı, aynı kullanıcı altındaki başka siteler de etkilendi mi?
Bu yaklaşım hem yanlış dosya silme riskini azaltır hem de “temizledim ama iki gün sonra geri geldi” vakalarında gerçek kalıcılık mekanizmasını bulmayı kolaylaştırır.
Yönlendirme her ziyaretçide görünmeyebilir. Bazı zararlı kodlar yalnız mobil cihaz, Google’dan gelen ziyaretçi, belirli ülke, ilk ziyaret veya çerez bulunmayan kullanıcı koşullarında çalışır. Bu nedenle kendi bilgisayarınızda sorun görünmemesi sitenin temiz olduğu anlamına gelmez.
Kontrol zinciri DNS ve web sunucusu redirectlerinden başlayıp .htaccess veya Nginx kuralları, WordPress siteurl/home değerleri, tema header/footer dosyaları, eklentiler, mu-plugins, wp-config.php, veritabanı seçenekleri, service worker ve ziyaretçiye gönderilen JavaScript’e kadar ilerlemelidir.
Bir redirect tespit edildiğinde yalnız hedef alan adını engellemek çözüm değildir. Redirect kodunun nereden geldiği ve ilk enjeksiyonun nasıl gerçekleştiği bulunmalıdır.
Arama sonuçlarında sitenize aitmiş gibi görünen fakat sizin oluşturmadığınız Japonca, Çince, kumar, ilaç veya sahte ürün başlıkları genellikle hacked SEO spam belirtisidir. Saldırgan binlerce URL üretip arama motoruna farklı içerik sunabilir.
Sadece spam URL’leri Search Console’dan kaldırmak kök sorunu çözmez. URL’yi oluşturan rewrite kuralı, dosya, veritabanı kaydı, zararlı plugin/modül veya backdoor temizlenmeden yeni URL’ler yeniden üretilebilir.
Temizlik sonrasında doğru 404/410 davranışı, sitemap temizliği, canonical kontrolü ve Search Console güvenlik inceleme süreci birlikte ele alınmalıdır. İndeksin normale dönmesi temizlik bittiği anda gerçekleşmeyebilir.
Google, tespit ettiği hacked content, malware veya social engineering örneklerini Search Console içindeki Security Issues raporunda gösterebilir. Raporda problem türü ve bazı örnek URL’ler bulunabilir; örnek URL listesinin tüm enfekte sayfaları kapsamak zorunda olmadığı unutulmamalıdır.
Chrome’da “Deceptive site ahead” benzeri bir uyarı görülmesi phishing veya social engineering içerikle ilişkili olabilir. Uyarıyı kaldırmaya çalışmadan önce kompromize içerik tamamen temizlenmeli ve saldırı yüzeyi kapatılmalıdır.
Sorun giderildikten sonra Search Console üzerinden inceleme talebi gönderirken neyin temizlendiğini ve açığın nasıl kapatıldığını net açıklamak daha sağlıklı bir kurtarma süreci oluşturur.
Backdoor, saldırgana normal giriş akışını kullanmadan tekrar erişim sağlayan gizli mekanizmadır. Bir PHP dosyası, eklenti içine eklenmiş kod, bilinmeyen admin, cron görevi, SSH anahtarı veya sunucu katmanındaki başka bir mekanizma backdoor görevi görebilir.
Yalnız antivirüsün işaretlediği tek dosyayı silmek, enfeksiyon kaynağı veya persistence mekanizması duruyorsa geçici sonuç verir. Temizlik planı “zararlı dosyayı bul” yerine “ilk giriş, yetki, kalıcılık ve yeniden üretim zinciri” mantığıyla yürütülmelidir.
Aynı hosting hesabında birden fazla WordPress kurulumu varsa eski ve unutulmuş bir alt domain dahi temiz siteyi tekrar enfekte edebilir.
Resmî WordPress çekirdek dosyaları WP-CLI ile WordPress.org checksum değerlerine karşı doğrulanabilir. Bu yöntem çekirdekte beklenmeyen değişiklikleri hızlıca bulmaya yardımcı olur. Aynı şekilde WordPress.org deposundaki eklentiler için de checksum doğrulaması yapılabilir.
Checksum uyuşmazlığı otomatik olarak “bu dosya virüstür” anlamına gelmez. Manuel değiştirilmiş eklenti, özelleştirilmiş core dosyası veya yarım kalan güncelleme de fark üretebilir. Sonuç dosyanın kaynağı ve sürümüyle birlikte yorumlanmalıdır.
Premium veya özel geliştirilmiş eklentiler WordPress.org checksum sisteminde bulunmayabilir. Bu durumda temiz vendor paketi, Git deposu, bilinen temiz yedek veya hash bazlı karşılaştırma gerekir.
Standart WordPress medya yüklemelerinde uploads dizini çoğunlukla görsel, PDF ve medya dosyaları içerir. Bu dizinde çalıştırılabilir PHP dosyası görülmesi araştırmaya değer güçlü bir işarettir; saldırganlar yazılabilir dizinleri web shell saklamak için kullanabilir.
Ancak her PHP dosyasını otomatik silmek doğru değildir. Bazı eklentiler özel işlevleri için farklı dosya yapıları oluşturabilir. Dosyanın içeriği, oluşturulma zamanı, çağrıldığı URL ve eklentinin resmî davranışı doğrulanmalıdır.
Temizlikten sonra uploads altında script çalıştırmayı web sunucusu seviyesinde kısıtlamak, uygulama uyumluluğu kontrol edilerek ek savunma katmanı sağlayabilir.
Zararlı script doğrudan tema dosyasına yazılabileceği gibi veritabanındaki widget, option, page builder alanı veya tag manager benzeri üçüncü taraf yapıdan da gelebilir. Bu nedenle yalnız PHP dosyalarını taramak her vakayı yakalamaz.
Tarayıcının Network ve Sources görünümü, beklenmeyen domainlere yapılan istekleri ve hangi dosyanın scripti yüklediğini gösterebilir. HTML kaynak kodu ile JavaScript çalıştıktan sonra oluşan DOM’u karşılaştırmak runtime enjeksiyonlarını ayırmaya yardımcı olur.
Üçüncü taraf reklam, chat veya analytics hesabı ele geçirildiyse site dosyaları temiz görünürken ziyaretçiye zararlı script aktarılabilir. Hesap erişimleri de olay incelemesinin parçası olmalıdır.
Evet. WordPress options, posts, widgets, theme settings veya eklenti tablolarına script, iframe, spam bağlantı veya yönlendirme kodu enjekte edilebilir. Dosyaları temizlemek bu kayıtları otomatik kaldırmaz.
Veritabanında arama yapılırken yalnız belirli bir kelimeye güvenmek hatalıdır. Zararlı içerik parçalanmış, encode edilmiş veya farklı alanlarda birleştiriliyor olabilir. Aynı zamanda meşru HTML ve JavaScript kayıtlarının yanlışlıkla silinmemesi gerekir.
Canlı veritabanında toplu replace veya DELETE yapmadan önce tam yedek alınmalı, hangi tablonun ve satırın değişeceği doğrulanmalı ve geri dönüş planı hazırlanmalıdır.
Tanımadığınız administrator hesabı güçlü kompromize göstergesidir. Ancak hesabı silmeden önce kayıt tarihi, e-posta, user meta, son aktivite/audit kaydı ve hesabın oluşturulmasına yakın erişim logları not edilirse olayın kaynağını anlamaya yardımcı olabilir.
Ardından yetkisiz hesap kaldırılır, tüm yönetici parolaları ve ilişkili hosting/FTP/SSH şifreleri döndürülür, aktif oturumlar sonlandırılır ve WordPress authentication salts yenilenir.
Saldırgan hesabı bir güvenlik açığı üzerinden yeniden oluşturabiliyorsa yalnız parola değiştirmek yeterli olmayacaktır. Açık eklenti, dosya upload noktası veya backdoor kapatılmalıdır.
Evet. WordPress WP-Cron, cPanel Cron Jobs, Plesk Scheduled Tasks veya sistem crontab içinde zararlı bir komut belirli aralıklarla dosyayı yeniden oluşturabilir, uzak adresten payload indirebilir veya spam içerik üretebilir.
WordPress cron listesi ile sistem cron aynı şey değildir. Uygulama temiz görünürken hosting seviyesinde görev kalmış olabilir. Queue worker, supervisor veya özel scheduler kullanılan Laravel gibi sistemlerde de benzer kalıcılık senaryoları düşünülmelidir.
Bilinmeyen görevi yalnız silmek yerine hangi kullanıcı tarafından, ne zaman ve hangi dosyayla ilişkili oluşturulduğu mümkünse loglardan araştırılmalıdır.
.htaccess içinde user-agent, referer veya IP koşuluna göre yalnız belirli ziyaretçileri spam sayfasına yönlendiren kurallar eklenebilir. Bu nedenle site sahibinde normal görünen sayfa Googlebot veya mobil ziyaretçide farklı davranabilir.
Nginx kullanılıyorsa benzer kurallar vhost yapılandırmasında veya include edilen config dosyalarında bulunabilir. Cloudflare Redirect Rules, Workers veya başka edge katmanları da ayrıca kontrol edilmelidir.
Temizlikte beklenen WordPress rewrite kurallarıyla şüpheli eklemeler ayrılmalı; dosyanın değiştirilme zamanı ve tekrar değişip değişmediği takip edilmelidir.
wp-config.php veritabanı bağlantısı ve WordPress çalışma ayarlarını içerdiği için kritik dosyadır. Zararlı include veya beklenmeyen kod eklenmesi tüm isteklerde payload çalıştırabilir.
Dosyada sadece zararlı kod değil sızmış veritabanı parolası ve authentication salts gibi sırlar da olay sonrası döndürülmelidir. Hosting hesabı kompromize olmuşsa yalnız WordPress admin şifresini değiştirmek yeterli değildir.
İzinler, dosya sahipliği ve web kullanıcısının gereksiz yazma yetkileri de kontrol edilmelidir.
Lisans kontrolü kaldırılmış veya kaynağı belirsiz tema/eklenti paketinin içine önceden backdoor, spam injector veya credential stealer yerleştirilmiş olabilir. Dosyanın orijinal vendor paketiyle güvenilir biçimde karşılaştırılması zorlaşır.
Ayrıca nulled paketler resmî güncelleme kanalından kopabilir. Güvenlik açığı kapatılsa bile eski sürüm kullanılmaya devam edebilir.
Temizlik sonrasında kaynağı belirsiz paketleri güvenilir lisanslı veya doğrulanabilir sürümlerle değiştirmek yeniden bulaşma riskini azaltır.
Eski sürüm kullanılması riski artırabilir fakat olay incelemesinde “eskiydi, kesin buradan girdiler” şeklinde varsayım yapılmamalıdır. Erişim logları, bilinen açık zaman çizgisi, dosya değişim tarihleri ve saldırı paterni mümkünse korele edilmelidir.
Güncelleme güvenlik bakımının temel parçasıdır. Ancak hacklenmiş sitede önce yedek ve olay kanıtı alınmadan tüm bileşenleri rastgele güncellemek bazı izleri yok edebilir veya uyumluluk sorununa yol açabilir.
Sağlıklı süreç izolasyon, yedek, tespit, temizlik, güncelleme/hardening ve yeniden tarama sırasını kontrollü yürütür.
Evet. Enfekte yedek üretimde geri yüklemek için değil, olay incelemesi ve yanlış temizlik durumunda geri dönüş için değerlidir. Temizlikten önce dosya ve veritabanının salt okunur kopyası alınması faydalıdır.
Olaydan önceki bilinen temiz yedek varsa karşılaştırma için çok değerlidir. Fakat “bir ay önceki yedeği yükledim, sorun çözüldü” yaklaşımı o tarihten beri verilmiş sipariş, kullanıcı ve içerik verisini kaybettirebilir.
E-ticaret sistemlerinde eski yedeğe dönmek yerine temiz dosyalarla güncel veritabanını güvenli biçimde korumak veya kontrollü veri taşıma planı yapmak gerekebilir.
Erişim logları hangi IP’nin hangi endpoint’e hangi zamanda istek yaptığını, olağandışı POST trafiğini, upload noktalarını veya brute-force paternlerini gösterebilir. Error log ise başarısız exploit veya zararlı script hatalarına dair iz taşıyabilir.
Logların saklama süresi kısa ise olaydan sonra gecikmeden kopya alınmalıdır. CDN veya reverse proxy kullanıldığında origin logunda gerçek istemci IP’sinin doğru aktarılıp aktarılmadığı da önemlidir.
Tek başına bir IP’yi engellemek kök neden çözümü değildir; saldırgan farklı IP kullanabilir. Loglar esas olarak giriş vektörünü ve zaman çizgisini anlamak için kullanılır.
Ele geçirilmiş PHP dosyası sunucunun mail fonksiyonunu kullanarak spam gönderebilir veya SMTP hesabının parolası çalınmış olabilir. Bu durum domain/IP itibarını bozabilir ve meşru e-postaların spam klasörüne düşmesine yol açabilir.
Mail queue ve mail loglarında hangi kullanıcı/script veya SMTP hesabının gönderim yaptığı ayrılmalıdır. Sadece gönderimi durdurmak yeterli değildir; web shell veya ele geçirilmiş mailbox temizlenmelidir.
Olay sonrası SPF, DKIM, DMARC ve blacklist durumu ayrıca değerlendirilir. Bu konu için ayrı e-posta teslimat analizi sayfası daha derin teşhis sunacaktır.
Evet. Aynı hosting kullanıcısındaki başka bir site, FTP hesabı, kontrol paneli hesabı, SSH anahtarı veya sunucu servisi ele geçirilmişse temiz WordPress dosyaları yeniden enfekte olabilir.
Kalıcı vakalarda inceleme sınırını CMS ile sınırlamamak gerekir. Sibling siteler, kontrol paneli kullanıcıları, cron, mail hesapları, web sunucusu ve dosya sahipliği birlikte düşünülmelidir.
Paylaşımlı hostingde sunucu seviyesi log ve süreçlere erişim kısıtlı olabilir. Gerekirse hosting sağlayıcısından olay zamanına ait güvenlik, erişim ve mail logları istenir.
WordPress, tema ve eklentiler güncel ve desteklenen sürümlere alınmalı; kullanılmayan eklenti ve temalar kaldırılmalı; güçlü benzersiz parolalar ve mümkünse 2FA kullanılmalı; yönetici hesabı sayısı minimum tutulmalıdır.
Dosya izinleri ve sahipliği, wp-config korunması, dosya düzenleyicisi, XML-RPC gereksinimi, REST API erişimi ve upload dizininde script çalıştırma politikası uygulamaya göre değerlendirilmelidir.
WAF ve brute-force koruması savunmayı güçlendirebilir fakat açık eklentiyi güncellemenin veya backdoor’u temizlemenin yerine geçmez. Güvenlik birden fazla katmanın birlikte çalışmasıdır.
Sadece WordPress admin parolasını değiştirmek genellikle yetersizdir. Hosting paneli, FTP/SFTP, SSH, veritabanı, SMTP/mailbox, CDN/Cloudflare, domain registrar ve ilgili API anahtarları olay kapsamına göre döndürülmelidir.
Aynı parola başka hizmetlerde kullanıldıysa credential stuffing riski nedeniyle o hesaplar da değerlendirilmelidir. Yeni parolalar benzersiz ve parola yöneticisiyle üretilmiş olmalıdır.
WordPress authentication salts yenilendiğinde mevcut oturumların geçersizleşmesine yardımcı olur. Fakat bu işlem açık bir backdoor üzerinden yeniden girişi engellemez; kök neden yine kapatılmalıdır.
Hayır. WAF bilinen saldırı paternlerini ve kötü trafiği filtrelemede güçlü bir katmandır fakat kötü parola, ele geçirilmiş admin hesabı, tedarik zinciri saldırısı veya sunucu seviyesi kompromize karşı tek başına mutlak koruma değildir.
Cloudflare gibi edge güvenlik katmanları origin IP gizleme, rate limiting ve WAF sağlayabilir. WordPress güvenlik eklentileri ise login, dosya bütünlüğü ve malware taraması gibi uygulama içi kontroller sunabilir.
En iyi sonuç güncelleme, minimum yetki, 2FA, yedek, loglama, WAF, dosya bütünlüğü ve düzenli taramanın birlikte uygulanmasıyla elde edilir.
Hayır. WordPress ve WooCommerce vakaları yaygın olduğu için örneklerin önemli bölümü WordPress üzerindedir; ancak kaynak koduna ve gerekli erişime sahip olunan OpenCart, PrestaShop, Joomla, Laravel, özel PHP ve benzeri web uygulamalarında da güvenlik ön analizi yapılabilir.
Her platformun dosya bütünlüğü ve persistence noktaları farklıdır. Laravel’de .env, storage, scheduler/queue ve vendor bütünlüğü; OpenCart ve PrestaShop’ta extension/module dosyaları, cache ve admin hesapları farklı yöntemlerle değerlendirilir.
Kapalı SaaS sistemlerde kaynak kod incelenemiyorsa yalnız platformun sunduğu log, API ve yönetim kontrolleri kapsamında analiz yapılabilir.
İlk aşamada site adresinizi, gördüğünüz belirtiyi, problemin ne zaman başladığını ve varsa Search Console/hosting güvenlik uyarısının ekran görüntüsünü iletirsiniz. Şifre gerektirmeyen dış kontrollerle görülebilen belirtileri değerlendiririz.
Sonuçta “görünür bir kompromize belirtisi var”, “dışarıdan kesin teşhis edilemiyor, dosya/veritabanı incelemesi gerekli” veya “bulgu güvenlik ihlalinden çok yapılandırma/hata ihtimalini gösteriyor” şeklinde teknik yönlendirme yapılır.
Dosya temizleme, backdoor kaldırma, veritabanı müdahalesi, log inceleme veya yeniden yapılandırma gerekiyorsa ücretli işlem kapsamı ve erişim ihtiyacı ayrıca belirlenir. Ücretsiz ön analiz yetkisiz penetrasyon testi değildir.
Site URL’si, görülen hata veya yönlendirme, problemin ilk fark edildiği yaklaşık tarih, kullanılan altyapı ve varsa hosting antivirüs raporu başlangıç için yeterlidir. Search Console Security Issues ekranı varsa hassas bilgileri kapatarak ekran görüntüsü paylaşabilirsiniz.
Daha önce hangi dosyaların silindiğini veya hangi güvenlik eklentisinin ne bulduğunu bilmek tekrar eden vakalarda önemlidir. “Temizledim ama geri geldi” diyorsanız ne kadar süre sonra geri geldiğini de belirtin.
İlk ön analizde parola göndermeyin. Derin inceleme gerekiyorsa hangi erişimin neden gerektiği ayrıca açıklanır.
Sağlıklı süreç önce izolasyon ve yedekle başlar. Ardından kompromize belirtileri ve giriş vektörü araştırılır; zararlı dosya/veritabanı kayıtları temizlenir, backdoor ve sahte hesaplar kaldırılır, zayıf bileşenler güncellenir veya değiştirilir.
Parolalar ve anahtarlar döndürülür, dosya bütünlüğü tekrar doğrulanır, cron ve loglar yeniden kontrol edilir. Site fonksiyon testi yapıldıktan sonra Search Console güvenlik uyarıları varsa inceleme talebi hazırlanır.
Son adım yeniden enfeksiyon takibidir. Temizliğin hemen ardından ve takip eden günlerde kritik dosya değişimleri, admin hesapları ve güvenlik taramaları izlenmelidir.
Antivirüsün bulduğu her dosyayı otomatik silmek, yalnız wp-admin/wp-includes klasörlerini değiştirmek, eski yedeği körlemesine geri yüklemek, sadece admin parolasını değiştirmek ve Search Console’daki spam URL’leri kaldırıp kök nedeni bırakmak sık hatalardır.
Bir diğer hata güvenlik eklentisini kurduktan sonra sitenin otomatik olarak temiz olduğunu varsaymaktır. Scanner faydalı sinyal üretir ancak özel obfuscation, veritabanı persistence veya sunucu seviyesi sorunlar manuel inceleme gerektirebilir.
Canlı e-ticaret sitesinde temizlik öncesi yedek almamak sipariş ve müşteri verisi kaybına neden olabilir. Her müdahalenin geri dönüş planı olmalıdır.
Hayır. Zararlı veya spam URL’ler temizlendikten sonra Google’ın siteyi yeniden taraması, güvenlik durumunu yeniden değerlendirmesi ve indeks sinyallerinin toparlanması zaman alabilir.
Temizleme sonrası doğru HTTP durum kodları, sitemap, internal link, canonical ve noindex davranışı kontrol edilmelidir. Binlerce spam URL için hepsini ana sayfaya 301 yönlendirmek yerine gerçek içerik durumuna uygun 404/410 davranışı çoğu vakada daha doğrudur.
Search Console Security Issues uyarısı varsa sorun gerçekten çözüldükten sonra review request gönderilir. Yalnız uyarıyı kaldırmaya odaklanıp güvenlik açığını açık bırakmak yeniden probleme yol açar.
Aşağıdaki örnekler savunma ve bütünlük kontrolü içindir. Çıktıdaki her farkı otomatik silmeyin; dosyanın bağlamını ve uygulama ihtiyacını doğrulayın.
Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
wp core verify-checksums --include-rootwp plugin verify-checksums --all --strictwp user list --fields=ID,user_login,user_email,roles,user_registeredwp cron event listfind wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -printfind . -type f -name "*.php" -mtime -7 -printYazılımın bizden satın alınmış olması gerekmez. Kaynak kod ve gerekli yetkili erişim varsa mevcut sisteminize göre değerlendirme yapılabilir.
Core, theme, plugin, kullanıcı, cron, uploads, wp-config ve veritabanı option kontrolleri
WordPress kontrollerine ek ödeme/sepet scriptleri, webhook, müşteri ve sipariş bütünlüğü
Extension/modification dosyaları, admin hesapları, config, cache ve upload yüzeyi
Module/theme override, admin kullanıcıları, cache ve değiştirilmiş PHP dosyaları
Core, extension, template, kullanıcı ve configuration bütünlüğü
.env, public/storage, vendor/composer bütünlüğü, scheduler/queue ve özel kod
Uygulama yapısına göre dosya, veritabanı, auth, upload, cron ve log kontrolleri
Temizlik yalnız dosya silmek değildir. Olayın kapsamı, giriş noktası, kalıcılık ve yeniden bulaşma ihtimali birlikte yönetilmelidir.
Yönlendirme, spam URL, güvenlik uyarısı veya şüpheli dosyanın gerçekten mevcut olduğunu doğrula.
Mevcut durumu kaybetmeden dosya/veritabanı kopyası ve mümkünse logları koru.
Tek site mi, tüm hosting hesabı mı, e-posta veya sunucu katmanı da etkilenmiş mi ayır.
Açık bileşen, zayıf hesap, backdoor, cron, sahte admin ve sunucu düzeyini kontrol et.
Zararlı içeriği kaldır, temiz paketlerle doğrula, zayıf bileşenleri değiştir veya güncelle.
Admin, hosting, FTP/SSH, veritabanı, SMTP ve gerekli API anahtarlarını yenile.
2FA, minimum yetki, WAF, dosya izinleri, yedek ve loglama katmanlarını iyileştir.
Dosya bütünlüğü, kullanıcı, cron ve dış davranışı tekrar doğrula; Search Console incelemesini tamamla.
Ücretsiz ön analiz için site adresinizi ve gördüğünüz belirtinin kısa açıklamasını iletin. İlk aşamada parola veya panel erişimi istemiyoruz. Derin temizlik veya müdahale gerekiyorsa yapılacak işlem ve erişim ihtiyacını ayrıca netleştiriyoruz.
Güvenlik içeriklerinde mümkün olduğunca resmî WordPress ve Google dokümantasyonu ile güvenlik ürünlerinin teknik belgelerini referans alıyoruz.
Ön analiz sonucunda sorun güvenlik, uygulama veya başka bir katmana işaret ederse ilgili uzmanlık sayfasına geçebilirsiniz.
Kullanıcıların en sık karşılaştığı belirtileri kısa ve doğrudan cevaplarla topladık.
Dışarıdan görülebilen yönlendirme, spam, güvenlik uyarısı ve bazı istemci tarafı belirtiler ücretsiz ön analizde değerlendirilebilir. Gizli backdoor veya veritabanı enjeksiyonu için dosya/veritabanı erişimi gerekebilir.
Hayır. İlk ön analizde site adresi ve problemin açıklaması yeterlidir. Derin inceleme gerekirse erişim ihtiyacı ayrıca açıklanır.
Evet. Kaynak kod ve gerekli yetkili erişim sağlanabiliyorsa özel PHP, Laravel, OpenCart, PrestaShop, Joomla ve benzeri sistemler değerlendirilebilir.
Kesin değildir. Yanlış redirect, Cloudflare kuralı veya eklenti ayarı da olabilir. Zararlı JS, .htaccess, veritabanı ve sunucu kuralları birlikte ayrılmalıdır.
SEO spam ihtimali yüksektir. Spam URL’leri tek tek kaldırmadan önce bunları üreten dosya, rewrite, veritabanı kaydı veya backdoor bulunmalıdır.
Önce phishing/social engineering veya malware içeriği tamamen temizlenmeli ve açık kapatılmalıdır. Ardından Search Console Security Issues üzerinden durum kontrol edilip uygun inceleme talebi gönderilir.
Backdoor, cron görevi, sahte admin, sibling site, ele geçirilmiş FTP/hosting hesabı veya sunucu seviyesi kalıcılık mekanizması kalmış olabilir.
Hayır. Scanner önemli bir sinyaldir fakat özel obfuscation, veritabanı enjeksiyonu veya sunucu seviyesindeki kompromizeyi her zaman tespit edemeyebilir.
Dosyanın işlevi ve bağlamı doğrulanmadan otomatik silme canlı siteyi bozabilir. Önce yedek, dosya konumu ve kaynak karşılaştırması yapılmalıdır.
Tek başına hayır. Meşru yazılımlar da encoding kullanabilir. Dosyanın kaynağı, neyi decode ettiği ve normal sürümle farkı incelenmelidir.
Hayır. Riskli bir işaret olabilir fakat kesin hüküm değildir. Kodun bağlamı ve resmî kaynakla karşılaştırılması gerekir.
Araştırılması gereken güçlü bir işarettir. Ancak otomatik silmeden önce ilgili eklentinin bu dosyayı meşru olarak oluşturup oluşturmadığı doğrulanmalıdır.
Resmî çekirdek dosyalarının beklenen WordPress.org sürümüyle uyuşup uyuşmadığını kontrol ederek beklenmeyen değişiklikleri tespit etmeye yardımcı olur.
WordPress.org checksum bulunmayabilir. Temiz vendor paketi, Git deposu, bilinen temiz yedek veya dosya hash karşılaştırması gerekir.
Yetkisizse kaldırılmalıdır; fakat mümkünse önce kayıt tarihi ve ilgili loglar not edilerek hesabın nasıl oluştuğu araştırılmalıdır.
Olay kapsamına göre WordPress, hosting, FTP/SFTP, SSH, veritabanı, e-posta, CDN ve domain hesapları dahil ilgili kimlik bilgileri döndürülmelidir.
Hayır. Cloudflare WAF ve trafik filtreleme sağlar fakat mevcut zararlı dosyayı veya veritabanı kaydını temizlemez.
Hayır. Güncelleme, minimum yetki, 2FA, güvenilir kaynaklar, yedek, loglama ve dosya bütünlüğü birlikte uygulanmalıdır.
Evet. Kaynağı doğrulanamayan paketler backdoor içerebilir ve resmî güvenlik güncellemelerinden kopabilir.
Risk oluşturabilir ancak kök neden log ve kanıtlarla doğrulanmalıdır. Eski sürüm görüp otomatik olarak saldırı vektörü ilan etmek doğru değildir.
Olay incelemesi, yanlış temizlikten geri dönüş ve temiz sürümle karşılaştırma için değerlidir. Enfekte yedek üretime körlemesine geri yüklenmemelidir.
Her zaman değil. Açık hâlâ duruyorsa yeniden hacklenebilir; ayrıca e-ticarette yeni sipariş ve müşteri verisi kaybedilebilir.
Hayır. Bu yalnız arama görünürlüğünü etkileyen bir adımdır. URL’leri üreten kompromize mekanizması temizlenmelidir.
Gerçek karşılığı olmayan hack spam URL’lerinde uygun 404/410 davranışı çoğu durumda daha doğaldır. URL türüne göre karar verilmelidir.
Zararlı içerik, güvenlik uyarıları ve spam indeksleme arama görünürlüğünü olumsuz etkileyebilir. Temizlik sonrası toparlanma zaman alabilir.
Her vakada değil. Temiz kaynaklarla dosya doğrulama ve kontrollü temizlik mümkün olabilir. Ağır veya sunucu seviyesi kompromizede temiz kurulum daha güvenli seçenek olabilir.
Veritabanı, Cloudflare Worker/Redirect, Tag Manager, DNS, service worker veya sunucu config gibi dosya dışı katmanlar kontrol edilmelidir.
Tek kullanıcı altında birden fazla site varsa evet. Eski bir alt domain veya unutulmuş CMS yeniden bulaşma kaynağı olabilir.
Evet. PHP mailer abuse veya web shell spam gönderebilir; ayrıca mailbox parolası ayrı olarak ele geçirilmiş olabilir. Mail logları ayrım için önemlidir.
Olabilir fakat kesin değildir. Trafik artışı, cron, ağır sorgular ve botlar da CPU yükseltebilir. Process ve access log ile teşhis gerekir.
Şüpheli olabilir. Komutun ne çalıştırdığı, ne zaman eklendiği ve hangi uygulamaya ait olduğu doğrulanmadan silinmemelidir.
Vakanın kapsamına göre kısa bakım veya izolasyon gerekebilir. E-ticaret ve canlı sistemlerde kesinti planı önceden belirlenir.
Evet. Dosya bütünlüğü, kullanıcılar, cron, dış davranış ve gerekli güvenlik raporları yeniden kontrol edilmelidir.
Hayır. Yetkisiz exploit, brute force veya saldırı testi yapılmaz. Ücretsiz hizmet pasif/dış gözlem ve kullanıcının sağladığı bulguların teknik yorumudur.
Dosya sayısı, altyapı, canlı veri hassasiyeti, enfeksiyon kapsamı, tekrar eden backdoor, sunucu erişimi ve log analizi ihtiyacı iş yükünü değiştirir. Ön analiz sonrası kapsam belirlenir.
Evet. Yazılımı Eka Sunucu veya Eka Yazılım’dan satın almış olmanız gerekmez. Kaynak kod ve gerekli erişim mevcutsa altyapı bağımsız değerlendirme yapılabilir.
Zararlı içerik, backdoor ve güvenlik açığı gerçekten temizlendikten ve site tekrar kontrol edildikten sonra gönderilmelidir.
Hayır. HTTPS bağlantıyı şifreler; zayıf eklenti, kötü parola veya uygulama açığını otomatik kapatmaz.
Hayır fakat parola ele geçirilmesine karşı güçlü ek katmandır. Yazılım açığı veya sunucu compromise gibi diğer vektörlere karşı tek başına yeterli değildir.
Site adresi, gördüğünüz belirti, yaklaşık başlangıç tarihi ve varsa Search Console/hosting uyarısının ekran görüntüsü yeterlidir. İlk aşamada şifre göndermeyin.
Ücretsiz ön analiz için site adresinizi ve gördüğünüz belirtinin kısa açıklamasını iletin. İlk aşamada parola veya panel erişimi istemiyoruz. Derin temizlik veya müdahale gerekiyorsa yapılacak işlem ve erişim ihtiyacını ayrıca netleştiriyoruz.