WordPress Zararlı Dosya Tespiti: rankform.php Vaka Analizi

WordPress zararlı dosya uyarısı aldığınızda ilk refleksiniz dosyayı hemen silmek olabilir. Ancak özellikle canlı ve kurumsal bir WordPress sisteminde bu yaklaşım yeni sorunlara yol açabilir. Bir güvenlik aracının bir dosyayı şüpheli olarak işaretlemesi önemli bir bulgudur; fakat dosyanın ne olduğunu anlamadan silmek her zaman doğru çözüm değildir.

Yakın zamanda yönettiğim kurumsal bir WordPress altyapısında tam olarak böyle bir olay yaşadım. Wordfence taramasında farklı konumlarda şüpheli PHP dosyaları tespit edildi. Bunlardan en dikkat çekeni, Rank Math eklentisinin dizinlerinden birinde bulunan rankform.php dosyasıydı.

Bu yazıda dosyaların içeriğini saldırganların yeniden kullanabileceği ayrıntılarla paylaşmadan; uyarıyı nasıl değerlendirdiğimi, neden dosyaları doğrudan silmediğimi, nasıl izole ettiğimi ve temizlik sonrasında sistemi nasıl doğruladığımı gerçek bir WordPress güvenlik vaka analizi üzerinden anlatıyorum.

WordPress güvenliğini daha geniş kapsamda ele aldığım WordPress Kurumsal Site Güvenliği yazımda ise sunucu, WordPress, erişim kontrolü, izleme ve yedekleme katmanlarını birlikte nasıl yönettiğimi anlatıyorum.

Vaka Özeti: WordPress Zararlı Dosya Uyarısı Nasıl Başladı?

• İlk bulgu: Güvenlik taramasında birden fazla şüpheli PHP dosyası tespit edildi.
• Dikkat çeken dosya: Rank Math eklentisinin alt dizinlerinden birinde rankform.php adlı beklenmeyen bir dosya bulunuyordu.
• Teknik gösterge: Dosya içerisinde gizlenmiş/obfuscate edilmiş PHP kodunun çalıştırılmasına yönelik şüpheli bir yapı tespit edildi.
• Ek bulgular: Eklenti, tema ve uploads gibi farklı alanlarda başka şüpheli PHP dosyaları da raporlandı.
• İlk müdahale: Şüpheli dosyalar doğrudan silinmek yerine çalışmaları engellenecek şekilde izole edildi.
• Doğrulama: Ana site ve bağlı WordPress siteleri kontrol edildi, ardından güvenlik taraması tekrarlandı.

rankform.php Neden Dikkatimi Çekti?

Bir dosyanın yalnızca adından zararlı olup olmadığını anlayamayız. rankform.php adının Rank Math’a benzemesi de dosyanın gerçekten Rank Math tarafından oluşturulduğunu kanıtlamaz.

Benim dikkatimi çeken asıl nokta dosyanın adı değil, bulunduğu konum ile içerisindeki kod yapısının birlikte değerlendirilmesiydi.

Wordfence dosya içerisinde aşağıdaki yapıya benzeyen bir eşleşme raporluyordu:

eval(...)
gzinflate(...)
htmlspecialchars_decode(...)

Bu fonksiyonların tek başına bulunması bir PHP dosyasının kesin olarak zararlı olduğunu kanıtlamaz. Meşru yazılımlarda da farklı teknik amaçlarla benzer fonksiyonlar kullanılabilir.

Ancak beklenmeyen bir PHP dosyasında kodun okunmasını zorlaştıran obfuscation teknikleriyle birlikte dinamik kod çalıştırma yapılarının görülmesi ciddi biçimde araştırılması gereken bir güvenlik göstergesidir.

Bu nedenle rankform.php dosyasını yalnızca “Wordfence virüs dedi” diye değil; dosyanın beklenmeyen varlığı, konumu ve içerik özelliklerini birlikte değerlendirerek şüpheli kabul ettim.

Tek Bir Dosya Değildi: Asıl Önemli Bulguyu Burada Gördüm

İlk dosyayı incelemek önemliydi ancak güvenlik olayının yalnızca rankform.php ile sınırlı olduğunu varsaymak istemedim.

Tarama sonuçlarında farklı WordPress bileşenlerinde başka şüpheli PHP dosyaları da bulunuyordu. Bazıları eklenti dizinlerinde, bazıları tema bileşenlerinin içerisinde, bazıları ise normalde PHP dosyası görmeyi beklemeyeceğim yükleme alanlarında tespit edilmişti.

Bu noktada olay benim için “tek bir bozuk eklenti dosyası” olmaktan çıktı.

Birbirinden farklı dizinlerde beklenmeyen PHP dosyaları bulunuyorsa, yalnızca ilk bulunan dosyayı temizlemek yerine sistemin tamamını olay kapsamında değerlendirmek gerekir.

Şüpheli Dosyaları Neden Hemen Silmedim?

Canlı sistemlerde şüpheli bir dosyayı doğrudan silmek her zaman ilk tercihim değildir.

• Dosyanın daha sonra incelenmesi gerekebilir.
• Yanlış pozitif ihtimali tamamen dışlanmamış olabilir.
• Dosyanın hangi bileşenle ilişkili olduğunu anlamak gerekebilir.
• Silme işleminden sonra sistem davranışındaki değişikliği karşılaştırmak zorlaşabilir.

Wordfence’in kendi dokümantasyonu da tarama sonuçlarının incelenmesini, yanlış pozitif ihtimalinin değerlendirilmesini ve özellikle silme/onarım işlemlerinden önce dosyanın yedeğinin alınmasını öneriyor.

Bu vakada şüpheli dosyaların bir kopyasını güvenli biçimde sakladıktan sonra, web sunucusu tarafından PHP olarak çalıştırılmalarını engellemek amacıyla dosyaları .disabled uzantısıyla yeniden adlandırarak izole ettim.

Bu yöntem her güvenlik olayında uygulanması gereken evrensel bir reçete değildir. Ancak bu vakada dosyanın çalışmasını durdururken inceleme materyalini korumamı sağladı.

WordPress Zararlı Dosya İncelemesinde İzlediğim Süreç

1. Önce Yedek ve Kanıtları Korudum

Değişiklik yapmadan önce mevcut yedeklerin durumunu kontrol ettim ve şüpheli dosyaların inceleme için kopyalarını sakladım.

Bir güvenlik olayında yalnızca sistemi ayağa kaldırmak değil, ne olduğunu anlayabilmek de önemlidir.

2. Dosyanın Gerçekten O Dizine Ait Olup Olmadığını Sorguladım

Bir eklenti klasöründe bulunan her dosya o eklentiye ait değildir.

Bu nedenle dosyanın:

• normal paket içerisinde bulunup bulunmadığını,
• dosya adının bileşenin yapısıyla uyumlu olup olmadığını,
• beklenmeyen PHP kodu içerip içermediğini,
• güvenlik taramasının hangi nedenle alarm verdiğini

birlikte değerlendirdim.

3. Şüpheli Dosyaları İzole Ettim

İnceleme sonucunda şüpheli kabul ettiğim dosyaların çalışmasını durdurdum. Bu aşamada doğrudan toplu silme yapmak yerine kontrollü ilerledim.

Her değişiklikten sonra sistemin çalışmaya devam edip etmediğini kontrol ettim.

4. Tekrar Güvenlik Taraması Yaptım

İlk bulunan dosyaları izole etmek işlemin bittiği anlamına gelmiyordu.

Wordfence taramasını tekrar çalıştırarak:

• başka şüpheli dosya bulunup bulunmadığını,
• değiştirilmiş WordPress dosyalarını,
• tema ve eklenti dizinlerindeki beklenmeyen değişiklikleri,
• uploads gibi kullanıcı içeriği barındıran alanlardaki PHP dosyalarını

yeniden kontrol ettim.

Wordfence’in resmi tarama dokümantasyonunda da WordPress çekirdek dosyalarının, eklenti ve tema dosyalarının bilinen sürümlerle karşılaştırılması ve şüpheli kod kalıplarının taranması gibi kontroller yer alıyor.

5. Sitelerin Çalışmasını Doğruladım

Güvenlik temizliğinin başarılı olması yalnızca tarama ekranında daha az uyarı görmek değildir.

Yaptığım değişikliklerden sonra ana siteyi ve bağlı WordPress sitelerini tek tek kontrol ettim. Sayfaların açılması, yönetim alanına erişim ve temel fonksiyonların çalışması doğrulandı.

Bu kontrol özellikle çoklu WordPress yapılarında önemliydi; bir dosyayı kaldırırken başka bir sitenin ihtiyaç duyduğu bileşeni yanlışlıkla etkileyebilirdim.

Uploads Klasöründe PHP Dosyası Neden Dikkat Gerektirir?

WordPress’in uploads dizini esas olarak medya dosyalarının saklandığı alandır. Bu nedenle burada beklenmeyen çalıştırılabilir PHP dosyaları görmek benim için ayrıca araştırılması gereken bir durumdur.

“Uploads içinde PHP var = kesin zararlı” şeklinde otomatik karar vermek yerine dosyanın kaynağı ve içeriği incelenmelidir.

Buna rağmen ihtiyaç olmadığı halde yükleme dizinlerinde çalıştırılabilir PHP bulunması güvenlik açısından ayrıca değerlendirilmelidir.

Bu Vakada Yapmadığım Şeyler

Güvenlik olaylarında yapılan bazı hızlı müdahaleler problemi çözmek yerine kanıtları yok edebilir veya sistemi bozabilir.

• Wordfence’in işaretlediği her dosyayı düşünmeden silmedim.
• Yalnızca dosya adına bakarak zararlı olduğuna karar vermedim.
• Tüm eklentileri rastgele kaldırmadım.
• Canlı sistemde kontrolsüz kod değişiklikleri yapmadım.
• İlk temiz taramayı gördükten sonra olayın tamamen bittiğini varsaymadım.

Bir WordPress Sitesinde Şüpheli PHP Dosyası Bulursanız Ne Yapmalısınız?

Benzer bir durumda genel kontrol sıram şu şekilde:

1. Panikle silme yapmayın. Önce dosyanın konumunu ve güvenlik aracının neden alarm verdiğini inceleyin.
2. Güncel yedeği kontrol edin. Müdahale öncesi geri dönüş imkanınız olsun.
3. Dosyanın kaynağını doğrulayın. Resmi WordPress çekirdeği, tema veya eklenti paketinde bulunması gereken bir dosya mı kontrol edin.
4. Dosya içeriğini güvenli biçimde inceleyin. Beklenmeyen veya gizlenmiş kod yapılarının bulunup bulunmadığını değerlendirin.
5. Şüpheli bileşeni kontrollü biçimde izole edin. Canlı sistemde rastgele toplu silme yapmayın.
6. Tüm sistemi yeniden tarayın. Tek bir dosya bulmak olayın yalnızca o dosyayla sınırlı olduğunu göstermez.
7. WordPress, tema ve eklentileri kontrol edin. Değiştirilmiş veya kaynağı doğrulanamayan bileşenleri güvenilir paketlerle karşılaştırın.
8. Yönetici hesaplarını inceleyin. Tanımadığınız kullanıcı veya yetki değişikliği olup olmadığını kontrol edin.
9. Kritik erişimleri gözden geçirin. Olayın kapsamına göre yönetici ve sunucu erişim bilgilerinin yenilenmesi gerekebilir.
10. Temizlik sonrası tekrar doğrulayın. Tarama sonuçları kadar sitenin gerçek davranışını ve logları da takip edin.

WordPress’in resmi Hardening WordPress dokümantasyonu da güncellemeler, parolalar, dosya izinleri, eklentiler, yedekleme, loglama ve izleme gibi güvenlik katmanlarının birlikte değerlendirilmesini öneriyor.

Wordfence Uyarısı Her Zaman Zararlı Yazılım Anlamına Gelir mi?

Hayır.

Güvenlik tarayıcıları bilinen zararlı kod kalıpları, değiştirilmiş dosyalar veya şüpheli fonksiyon kombinasyonları gibi birçok göstergeyi kullanır. Bu sistemler değerlidir ancak bazı durumlarda meşru kodlar da inceleme gerektiren uyarılar oluşturabilir.

Wordfence de kendi dokümantasyonunda bazı tarama sonuçlarının yanlış pozitif olabileceğini ve dosyanın içeriğinin incelenmesi gerektiğini belirtiyor.

Uyarıyı görmezden gelme, fakat uyarıyı tek başına kesin hüküm olarak da kabul etme.

Dosyanın konumu, kaynağı, içeriği ve sistemdeki diğer bulgular birlikte değerlendirilmelidir.

Bu Güvenlik Vakasından Çıkardığım Sonuç

Bu olay bana bir kez daha WordPress güvenliğinin yalnızca bir güvenlik eklentisi kurup tarama sonucunu beklemekten ibaret olmadığını gösterdi.

Wordfence ilk uyarıyı verdi ancak asıl teşhis bundan sonra başladı. Dosyaların gerçekten ilgili bileşenlere ait olup olmadığını kontrol ettim, şüpheli dosyaları doğrudan silmek yerine kontrollü biçimde izole ettim, sistemi yeniden taradım ve yaptığım değişikliklerden sonra sitelerin çalışmasını tek tek doğruladım.

Benim bu vakada izlediğim süreci kısaca şöyle özetleyebilirim:

Tespit → Analiz → İzolasyon → Yeniden Tarama → Doğrulama → İzleme

Özellikle farklı dizinlerde birden fazla şüpheli dosya bulunduğunda yalnızca ilk dosyayı temizleyip işlemi bitmiş saymamak gerekiyor. Böyle bir durumda olayın kapsamını anlamaya çalışmak, WordPress çekirdeğini, tema ve eklentileri kontrol etmek ve temizlik sonrasında sistemi izlemeye devam etmek daha sağlıklı bir yaklaşım.

Bu vakadaki rankform.php dosyasını da yalnızca adı veya Wordfence uyarısı nedeniyle şüpheli kabul etmedim. Dosyanın beklenmeyen konumu, içerisindeki kod yapısı ve sistemde bulunan diğer şüpheli dosyalar birlikte değerlendirildi.

Sonuç olarak güvenlik aracının görevi bana önemli bir sinyal vermekti. Dosyanın gerçekten ne olduğunu anlamak ve doğru müdahaleyi yapmak ise ayrıca teknik inceleme gerektirdi.

WordPress Zararlı Dosya Hakkında Sıkça Sorulan Sorular