SignDrop Zero-Day Açığı: Windows CLFS Mitigation’ı Kendi Aleyhine Kullanılıyor ve SYSTEM Yetkisi Veriyor

Merhaba

Güvenlik araştırmacısı Abdelhamid Naceri (Nightmare Eclipse, GitHub’da MSNightmare adıyla da biliniyor) 10 Kasım 2026’da, Microsoft’un Kasım güvenlik güncellemelerini yayımladığı gün, SignDrop adlı yeni bir Windows zero-day exploit’ini kamuya açtı. Exploit, standart bir kullanıcıyı NT AUTHORITY\SYSTEM yetkisine çıkarıyor. İşin ilginç tarafı, açığın Microsoft’un Ekim 2025’te Common Log File System (CLFS) sürücüsüne eklediği bir güvenlik önleminden doğması.

Bu yazıda SignDrop’un ne olduğunu, hangi mekanizmayı suistimal ettiğini, kurumsal ortamlarda nasıl kontrol edebileceğinizi ve yama gelene kadar neler yapılabileceğini özetliyorum. Exploit’i ben laboratuvarda çalıştırıp doğrulamadım; aktardıklarım araştırmacının ve haber kaynaklarının anlattıklarıdır.

SignDrop’a Genel Bakış

Alan	Bilgi
Ad	SignDrop
Bileşen	Common Log File System (CLFS), clfs.sys kernel sürücüsü
Tür	Yerel yetki yükseltme (Local Privilege Escalation, LPE)
Sonuç	Standart kullanıcıdan NT AUTHORITY\SYSTEM yetkisine yükselme
Araştırmacı	Abdelhamid Naceri (Nightmare Eclipse / MSNightmare / Chaotic Eclipse)
Yayın tarihi	10 Kasım 2026 (GitHub, PoC ve ayrıntılı yazı)
Test edilen sürümler	Windows 11 26H2, Windows 11 26H2 Experimental, Windows Server 2025 Experimental
CVE (Common Vulnerabilities and Exposures)	Atanmadı
Yama	Yok
Microsoft doğrulaması	Haber tarihi itibarıyla yok
Gerçek saldırılarda kullanım	Bildirilmedi; CISA KEV (Known Exploited Vulnerabilities) kataloğunda listelenmiyor

Arka Plan: CLFS ve Ekim 2025’teki Mitigation

Common Log File System (CLFS), Windows’un genel amaçlı log altyapısıdır ve kernel tarafında clfs.sys ile çalışır. Geçmişte bu sürücüdeki bellek bozulması açıkları, fidye yazılımı operasyonlarında SYSTEM yetkisi elde etmek için kullanıldı. Kaynaklarda örnek olarak, gerçek saldırılarda yamalanmadan önce istismar edilen CVE-2025-29824 anılıyor.

Microsoft bu saldırı sınıfını zorlaştırmak için Ekim 2025’te CLFS log dosyalarına bir kimlik doğrulama mitigation’ı ekledi. Haberlere göre sürücü, her log için hash tabanlı bir mesaj doğrulama kodu (Hash-based Message Authentication Code, HMAC) tutuyor ve doğrulama verisini .cnpf uzantılı yardımcı bir dosyada saklıyor. Naceri, mitigation sonrasında CLFS açıklarını kullanan saldırıların belirgin biçimde azaldığını da belirtiyor.

SignDrop Nasıl Çalışıyor?

Naceri’ye göre sorun kriptografide değil, .cnpf dosyasının oluşturulma mantığında. Haberlerde aktarılan akış kabaca şöyle:

1. Standart kullanıcı, yolları kendi kontrolünde olan bir CLFS log ve container hazırlar.
2. CLFS, log oluşturulurken erişim kontrollerini başta doğru şekilde uygular.
3. Daha sonra ayrıcalıklı bir süreç bu logu açtığında, clfs.sys .cnpf dosyasını o sürecin güvenlik bağlamında oluşturur. Naceri’ye göre Windows Defender gibi süreçler logu açmaya zorlanabilir.
4. Exploit, object manager symbolic link’leri ile bu dosya oluşturma işlemini saldırganın seçtiği bir konuma yönlendirir. Dosya SYSTEM yetkisiyle ve orijinal dosyanın erişim izinleriyle oluşur.
5. Bu zincir doğru kurulursa SYSTEM yetkisinde bir shell elde edilir.

Naceri’nin kendi ifadesiyle Microsoft mitigation’ı doğru uygulamış, ancak mantık suistimale izin veriyor. Yani meşru bir güvenlik özelliği kendi aleyhine kullanılabiliyor.

SignDrop PoC exploit (Abdelhamid Naceri)

En Dikkat Çekici İddia: AV ve EDR Tamper Protection Bypass

Naceri’nin en iddialı tespiti, tekniğin herhangi bir antimalware motorunun kendi kendini koruma (self-defense veya tamper protection) mekanizmasına karşı kullanılabileceği.

Gerekçesi şu: Saldırgan, antimalware sürecinin bağlamında keyfi dosya oluşturma tetikleyebilirse, ürünün kernel sürücüleri isteği kendi meşru sürecinden geldiği için görür ve izin verir. Bu durumda herhangi bir antivirus (AV) veya Endpoint Detection and Response (EDR) ürünü devre dışı bırakılabilir.

Bu iddia araştırmacının kendi açıklamasına dayanıyor. Ürün bazında bağımsız bir doğrulama görmedim. Yine de EDR’nin son savunma hattı olarak görüldüğü ortamlarda bu senaryo ciddiye alınmalı.

Sistemim Etkileniyor mu? Kontrol Yöntemi

Naceri iki kontrol yolu öneriyor: PoC’yi çalıştırmak ya da CLFS kimlik doğrulama modunu registry’den okumak. PoC GitHub’dan gelen, doğrulanmamış bir koddur ve SYSTEM shell açmayı amaçlar. Bu yüzden üretim sistemlerinde çalıştırmanızı önermem, test etmek istiyorsanız izole bir laboratuvar makinesi kullanın. Registry kontrolü çok daha güvenli:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CLFS\Authentication" -Name Mode

Değer yolu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode anahtarıdır.

Değerlerin anlamı şöyle:

Mode Değeri	Anlamı	SignDrop Durumu
0	Learning (öğrenme) modu	Savunmasız
1	Enforcement (zorunlu kılma) modu	Savunmasız

Haberler yalnızca 0 ve 1 değerlerini savunmasız olarak belirtiyor. Naceri etkilenen sistemlerin oranını yaklaşık %80 olarak tahmin ediyor, ancak bu rakam için veri sunmuyor. Kaynaklara göre mitigation 28 Ekim 2025 ve sonrasındaki güncellemelerle Windows 11 ve Windows Server 2025 sürümlerine geldiği için, uzun süredir güncel olan sistemlerde bu değerin bulunması bekleniyor. Learning modu için kaynaklarda 90 günlük bir süreçten söz ediliyor. Anahtar bulunmayan sistemlerde sonucu kendi laboratuvarınızda doğrulayın.

Yama Yok: Ne Yapılabilir?

Naceri’ye göre Microsoft’un yamasını beklemek dışında doğrudan bir çözüm yok. CLFS mitigation’ını kapatmak çözüm olarak görünse de bunu önermiyorum: mitigation devre dışı kalırsa sistemler yeniden bellek bozulması tabanlı CLFS açıklarına açık hale gelir.

Aşağıdakiler resmi bir Microsoft rehberi değil, yerel yetki yükseltme açıkları için genel sertleştirme önerileridir:

• SignDrop yerel erişim gerektirir. Asıl risk, phishing veya zararlı yazılım sonrası ikinci aşama olarak kullanılmasıdır. İlk erişim yüzeyini (e-posta, tarayıcı, USB, uzak erişim) daralttığınızdan emin olun.
• Standart kullanıcı hesaplarını en az yetki ilkesiyle yönetin; yerel yönetici haklarını kaldırın.
• AppLocker veya App Control for Business gibi uygulama kontrolü (application control) çözümleriyle kullanıcı profili ve Downloads klasörlerinden yürütülebilir dosya çalıştırmayı kısıtlayın.
• EDR ve AV ürünlerinizde tamper protection açık kalsın, ancak tek başına yeterli kabul etmeyin. Ürünün beklenmedik şekilde durması veya servislerinin devre dışı kalması için ayrı bir uyarı ve izleme kuralı tanımlayın.
• Standart kullanıcı oturumlarından SYSTEM yetkisiyle başlayan cmd.exe veya PowerShell süreçleri ve beklenmedik .cnpf dosyası oluşumları için tespit kuralı yazmayı değerlendirin. Bu kurallar genel LPE tespit mantığıdır, SignDrop için yayımlanmış resmi bir tespit imzası değildir.
• Microsoft Security Response Center (MSRC) duyurularını ve Aralık 2026 Patch Tuesday güncellemelerini takip edin. Bir advisory veya CVE yayımlanırsa envanterinizi buna göre tarayın.

Naceri’nin Önceki Açıkları ve Yama Durumu

SignDrop tekil bir olay değil. Naceri, kendisini eski bir Microsoft çalışanı olarak tanımlıyor ve Nisan’dan bu yana Microsoft Defender, BitLocker ve diğer Windows bileşenlerinde çok sayıda zero-day yayımladı.

Bunların bir kısmı yamalandı, bir kısmı hala yamasız:

Yama Durumu	Açıklar
Yamalandı	ShieldBreak, RoguePlanet, YellowKey, GreenPlasma, MiniPlasma
Resmi yama yok (haber tarihi itibarıyla)	BigDiskBuster, ShieldCrash, LegacyHive, BlueHammer, RedSun, UnDefend, SignDrop

Haberde ayrıca, Naceri’nin açıkları Microsoft’a önce özel olarak bildirmeden yayımladığı ve Microsoft’un zararlı faaliyetlere karşı hukuki adım uyarısı yaptığı hatırlatılıyor. Koordineli açıklama tartışması bu olayın bir parçası, ancak müşteri açısından pratik sonuç aynı: yayımlanmış, çalışan bir exploit ve henüz olmayan bir yama.

Sonuç

SignDrop, savunma amaçlı bir mitigation’ın kendisinin saldırı yüzeyi haline gelebildiğini gösteren iyi bir örnek. Yerel erişim gerektirdiği için tek başına uzaktan bir tehdit değil, ancak ilk erişim sonrası SYSTEM yetkisine çıkış ve EDR’yi devre dışı bırakma potansiyeli bunu fidye yazılımı operasyonları için cazip bir ikinci aşama yapıyor. Şu an için atılacak adımlar yetki ve uygulama kontrolünü sıkılaştırmak, EDR’nin durma davranışını izlemek ve Microsoft’un yanıtını takip etmek.

Gelişme olursa (CVE ataması, advisory veya yama) yazıyı güncelleyeceğim.

Başka bir yazımızda görüşmek dileğiyle…