Secure Server Depolarını Nasıl Secure Hale Getirebilirsiniz?

Şirket içi SharePoint kullanıcıları ve yöneticileri bir dosya yüklediğinde, söz konusu dosya ya üçüncü taraf bir antivirüs yazılımı ya da AMSI uyumlu motorlar (örneğin Microsoft Defender) ile taranır. Dosya bu ilk taramayı geçerse, işlem tamamlanmış sayılır. Bir kez temizlenirse, sonsuza kadar temiz kalır. Kötü amaçlı yazılım ve fidye yazılımı yüklerinin tam da bu şekilde, bazen yıllarca fark edilmeden depo içinde kalabildiği varsayılmaktadır.

Microsoft bunu açıkça belirtiyor: SharePoint’in kötü amaçlı yazılım koruması hasarı sınırlayabilir, ancak tek başına bir savunma noktası işlevi görmez.

BFSI (Bankacılık, Finansal Hizmetler ve Sigortacılık), sağlık, kamu sektörü ve OT (Operasyonel Teknoloji) veya Kritik Altyapı ortamlarında risk altındaki veriler arasında mevzuata uygunluk belgeleri, hasta kayıtları, vaka dosyaları ve mühendislik belgeleri yer almaktadır. Bunların tümü, her yıl giderek büyüyen bir veri havuzunda depolanmaktadır; oysa halihazırda bu havuzda bulunan veriler yeniden incelenmek üzere geri çağrılmamaktadır.

Aşağıda ele alınacak konular üç ana başlığa indirgenebilir: SharePoint antivirüs taramasının gerçekte nasıl işlediği, neleri kapsamadığı ve katmanlı, etkili bir SharePoint dosya deposu güvenliğinin nasıl olması gerektiği.

Enlyft’in teknoloji benimseme verileri, şu anda Microsoft SharePoint’i kullanan ve BT hizmetlerinden bankacılık, sağlık, petrol ve gaz ile kamu sektörüne kadar çeşitli sektörleri kapsayan 256.295 şirketi izlemektedir. Bu şirketlerin çalışan sayısı genellikle 50 ile 200 arasında değişmekte olup, gelirleri ise 1 milyon ile 10 milyon dolar arasındadır.

İşte bu büyüklük, saldırganların SharePoint depolarına ilgi göstermesinin ve bunları yüksek değerli hedefler olarak görmesinin tam da nedenidir.

Yukarıdakilerin hiçbiri, SharePoint’in sunucularını güvenli hale getirmediğini veya dosya güvenliğini ihmal ettiğini ima etmez. Microsoft’un belgelerine göre, SharePoint Server iki farklı tarama arayüzüyle Server :

• VSAPI (Virus Scanning API), uyumlu üçüncü taraf antivirüs yazılımlarının yükleme ve indirme gibi işlemler sırasında belgeleri taramasına olanak tanıyan bir SharePoint antivirüs entegrasyon arayüzüdür.

• AMSI (Antimalware Scan Interface), SharePoint Server desteklenen içerik işlemleri sırasında kötü amaçlı yazılım taraması için dosyaları AMSI uyumlu antivirüs motorlarına (örneğin Microsoft Defender) Server sağlayan bir Microsoft kötü amaçlı yazılım önleme entegrasyon çerçevesidir.

SharePoint Server , VSAPI, AMSI veya otomatik modu kullanacak şekildeyapılandırılabilir. Hangi seçeneğin ayarlandığına bakılmaksızın, bir dosyayı her seferinde yalnızca bir tarama motoru değerlendirir.

Tarama, olay tabanlıdır ve kullanıcılar belge yüklediğinde veya indirdiğinde tetiklenir; geriye dönük olarak veya belirli aralıklarla gerçekleştirilmez. Dosyayı yalnızca tek bir motor (genellikle MpEngine.dll olarak bilinen Microsoft Kötü Amaçlı Yazılım Koruma Motoru) değerlendirir.

Önemli nokta: Dosyalar , yükleme veya indirme sırasında tek bir motorla taranır; bu işlemde motorun o andaki imza veritabanı ve algılama yetenekleri kullanılır.

Bu yaklaşım, söz konusu algılama motorunun mantığını atlatmak üzere özel olarak tasarlanmış dosya kaynaklı bir tehdidi yakalamak için geliştirilmemiştir. Özellikle gelişmiş kalıcı tehditler, genellikle tam da bu sınırdan yararlanarak uzun süreler boyunca tespit edilmeden kalmaktadır.

Bu kalıcılık, saldırganların güvenilir SharePoint içeriğini kötü amaçlı olarak kullanmalarına olanak tanır. Tehdit aktörlerinin, ele geçirilmiş SharePoint sitelerini kötüye kullanarak kimlik avı belgeleri ve zararlı bağlantılar barındırdığına dair belgelenmiş saldırılar halihazırda mevcuttur.

Bir sıfırıncı gün saldırısı, temiz bir dosya gibi taramadan geçecektir; bunun tek nedeni, henüz onu tespit eden bir tarama motorunun bulunmamasıdır. Ayrıca SharePoint, mevcut içeriği daha sonra yeniden taramadığından, ilk gün taramadan geçen bir sıfırıncı gün dosyası, satıcı onu tespit edecek bir imza güncellemesi yayınlasa bile, iki yüzüncü günde ikinci kez incelenmez.

Bilinmeyen tehditler de aynı mantığa göre hareket eder. Üzerinde herhangi bir imza bulunmadığından, statik analiz (antivirüs motorlarının yaptığı şey) bu tehdidi tespit edemez.

Not: Bunlar, kusurlardan ziyade kapsamdaki eksikliklerdir. SharePoint Server yerleşik antivirüs özelliği, belirli etkileşim noktalarında belirli bir anda yapılan denetimler için tasarlanmıştır; sürekli genişleyen ve sürümleri bulunan bir veri havuzunu, gelişen tehdit ortamına göre sürekli olarak yeniden doğrulamak için tasarlanmamıştır.

Temmuz 2025’te Microsoft, şirket içi SharePoint Server etkileyen, kimlik doğrulaması gerektirmeyen bir uzaktan kod yürütme zincirinin aktif olarak istismar edildiğini açıkladı: CVE-2025-49706, CVE-2025-49704; daha sonra bunlara CVE-2025-53770 ve CVE-2025-53771 de eklendi. Bu istismarın çalışması için kimlik bilgileri veya oturum açma gerekmiyordu.

Microsoft daha sonra bu güvenlik açığını düzeltti ve bu istismar zincirine bir isim verildi: ToolShell.

Infosecurity Magazine’in aktardığı Eye Security analizine göre, 41 ülkedeki 145 kuruluşta 396 adet güvenliği ihlal edilmiş sistem tespit edildi. En ağır darbeyi kamu sektörü aldı; teyit edilen enfeksiyonların %30’unu bu sektör oluştururken, tek başına ABD toplamın %31’ini oluşturdu. Bununla ayrı olarak, Shadowserver Foundation, yüzlerce kuruluşu etkileyen bu güvenlik açığı kamuoyuna duyurulduktan sonra bile, aynı istismar zincirini çalıştıran herkesin erişebileceği 10.700'den fazla SharePoint örneğinin hâlâ açık durumda olduğunu bildirdi. Bu istismarın arkasındaki gruplardan biri olan Storm-2603, bu açık durumdan yararlanarak bir Warlock fidye yazılımı yükü oluşturdu.

Sisteme girdikten sonra, Storm-2603 çalıntı kimlik bilgilerini ve meşru yönetici araçlarını kullanarak sistemler arasında yatay olarak hareket etti. Bu hareket, orada olması gereken araçlara dayandığı için herhangi bir alarmı tetiklemedi. Storm-2603, web kabukları kurdu ve önemli verileri dışarı aktardı. Saldırganlar, geçerli kimlik doğrulama belirteçlerini taklit etmek için gerekli anahtarları çoktan çalmış oldukları için, güvenlik açığı yamalandıktan sonra bile erişimlerini sürdürdüler.

ToolShell, birbirine zincirlenmiş dört CVE üzerine inşa edildi ve başından itibaren yama atlatma mekanizmaları entegre edildi. CVE-2025-53770 ve -53771, özellikle CVE-2025-49704 ve -49706 için sunulan orijinal düzeltmelerin atlatılabilmesi nedeniyle ortaya çıktı.

Asıl önemli olan, bir saldırganın aynı hedefe karşı, yama döngüsünden iki kez daha hızlı bir şekilde uyum sağlamış olmasıdır; hem de birkaç hafta içinde.

Tek bir antivirüs programının bir dosyayı tek seferlik olarak tek bir satıcının imzalarıyla karşılaştırması gibi statik denetimler, başlangıçta sunucu tarafındaki bir istismar zincirini tespit etmek üzere tasarlanmamıştır. Ayrıca, yamanın yayınlanmasından sonra yamayı atlatacak bir yöntemle geri dönen bir saldırgana karşı da koruma sağlayamazlar.

ToolShell, artık özellikle SharePoint sunucularını hedef alan saldırıların ne kadar gelişmiş bir düzeye ulaştığını ortaya koyuyor. Böyle bir istismarın son kez yaşandığını varsaymak için hiçbir neden yok. Bu sunucularda bulunan veriler, gelişmelere ayak uyduracak şekilde tasarlanmış bir sistemle mi korunuyor, yoksa sadece bir kez tarama yapıp işi bitiren bir yöntemle mi?

Adil olmak gerekirse, ToolShell, yükleme taramasını atlatan kötü amaçlı bir belge değildi. Peki ya saldırganların yerleştirdiği web kabuğu (spinstall0.aspx ve adları değiştirilmiş varyantları)? O bir dosyadır. Sunucuda duruyordu ve tespit edilip edilmediği, daha önce açıklanan aynı sınırlamalara bağlıydı: tek bir tarama motoru, tek seferlik kontrol, belirli bir zaman diliminde.

İşte bu olay ile daha geniş kapsamlı tartışma arasındaki bağlantıyı kuran mekanizma budur. Yama uygulaması, özellikle ToolShell istismar zincirini kapatır. Ancak, depoda halihazırda bulunan ve henüz taranmamış bir sonraki dosya için hiçbir işe yaramaz.

2023 yılından beri hiç dokunulmamış içerik söz konusu olduğunda, bu içerik gerçekten taranmadıkça yukarıdakilerin hiçbiri pek önemli değildir.

Bu, SharePoint’in yerleşik antivirüsünün destekleyemediği bir alandır: sürüm geçmişi aracılığıyla saklanan eski sürümler de dahil olmak üzere depolanan içeriği, yalnızca yükleme veya indirme sırasında değil, tekrarlayan veya sürekli bir şekilde yeniden incelemek. Gerçek zamanlı, zamanlanmış ve isteğe bağlı yeniden tarama, veritabanları güncellendikçe dosyaları periyodik olarak denetleyerek bu eksikliği giderir.

Bu güvenlik önlemlerinin her biri, tek başına daha önce ele alınan belirli bir güvenlik açığını kapatır. Birlikte ise, Microsoft’un kendi belgelerinde “yerleşik antivirüsün tek bir savunma noktası olarak tasarlanmadığını” belirttiği katmanlı savunma sistemini oluştururlar.

MetaDefender Storage Security , çeşitli modeller aracılığıyladevreye alınabilir: doğrudan donanım kurulumları için fiziksel sunucular, sanallaştırma platformları (VMware, Hyper-V ve XenServer ile uyumlu), önde gelen bulut sağlayıcılarının sunduğu IaaS (Hizmet Olarak Altyapı) hizmetleri veya Kubernetes kümelerinde konteyner tabanlı dağıtımlar.

Bu kontrol listesi, CISA’nın ToolShell istismarına ilişkin kılavuzuna dayanmaktadır.

1. Yama durumunu kontrol edin.

Sömürülen tüm CVE’ler için güvenlik güncellemeleri mevcuttur; ancak yamalanmamış sunucular ToolShell saldırılarına karşı savunmasız kalmaya devam etmektedir. Etkilenen tüm SharePoint Server için Microsoft’un güvenlik güncellemelerini uygulayın.

2. AMSI'nin yapılandırıldığını doğrulayın.

Kurulmuş ancak yanlış yapılandırılmış bir AMSI, AMSI’nin hiç olmamasıyla aynı güvenlik açığını yaratır. AMSI entegrasyonunun etkinleştirildiğinden ve her SharePoint sunucusunda bir antivirüs çözümünün kurulduğundan emin olun.

3. ASP.NET makine anahtarlarını yenileme

Çalınan makine anahtarları, saldırganların bir sunucuya yama uygulandıktan sonra bile geçerli kimlik doğrulama belirteçleri oluşturmasına olanak tanır. Yama uygulamak tek başına, halihazırda çalınmış anahtarları geçersiz kılmaz. Makine anahtarlarını değiştirin, güvenlik güncellemesini uygulayın, ardından makine anahtarlarını tekrar değiştirin. Her anahtar değişikliğinden sonra iisreset.exe komutunu kullanarak IIS’yi yeniden başlatın; böylece applicationHost.config ve web.config dosyalarındaki zararlı girdiler silinir.

4. Daha önce bir güvenlik ihlali olup olmadığına dair belirtileri manuel olarak araştırın.

CISA, bu kampanyada kullanılan .dll yüklerinin sistem anahtarlarını ele geçirmek için kullanılabileceğini belirtiyor. Güvenlik yaması, sunucuya halihazırda yerleştirilmiş olan yükü ortadan kaldırmaz. Yalnızca güvenlik açığının kendisini değil, sistemlerde ve belirli dosyalarda IOC’leri (Güvenlik İhlali Göstergeleri) de kontrol edin.

5. Kullanım ömrü sona ermiş veya hizmet dışı bırakılmış sürümler olup olmadığını kontrol edin.

Bazı SharePoint örnekleri kullanım ömrünün sonuna gelmiştir ve istismar faaliyetlerinden bağımsız olarak artık güvenlik güncellemeleri almamaktadır. Şirketiniz tarafından kullanılan sürümlerin hâlâ desteklenip desteklenmediğini kontrol edin. Desteklenmiyorsa, gerekli önlemleri alın.

6. Bilinen göstergeler açısından günlükleri inceleyin

CISA, bu kampanyayla bağlantılı belirli istek kalıplarını ve IP adreslerini tespit etmiştir. CISA’nın referanslarıyla eşleşen istekler için arama günlüklerini inceleyin.

7. Yönetici ve düzenleme yetkilerini denetleyin.

Hasarın boyutunu sınırlamak için, SharePoint'te düzenleme ve yönetim izinlerine sahip kullanıcıları gözden geçirin ve aktif olarak gerekli olmayan erişim haklarını kaldırın.

8. Yalnızca şu anda görünür olanları değil, halihazırda depolanmış olanları da değerlendirin

Yukarıda belirtilenlerin tümü, istismar zincirinin kendisini ele almaktadır. Bunların hiçbiri, bu yamaların herhangi birinden önce oluşturulmuş dosyalar da dahil olmak üzere, belge kütüphanelerinde halihazırda bulunan içeriği değerlendirmez.

İlgili yamalar ve imza güncellemelerinden bu yana mevcut depo içeriğinin yeniden taranıp taranmadığını ya da hâlâ orijinal, muhtemelen güncelliğini yitirmiş tarama sonucunu taşıyıp taşımadığını belirleyin.