Log'lar açık, EDR ekranı önümde, ve bir şeylerin ters gittiğini hissediyorum ama tam olarak nerede ters gittiğini göremiyorum. Sonra şunu fark ediyorum: zararlı süreç, Windows'un kendi çekirdeğinde (kernel) koşuyor. Meşru bir sürücü imzasının arkasına saklanmış. O an içimden 'yine mi?' diye geçirdim. Ve evet — BYOVD (Bring Your Own Vulnerable Driver), yani 'Kendi Açıklı Sürücünü Getir' taktiği, hâlâ sektörün kör noktası olmaya devam ediyor.
GodDamn ransomware grubunun ABD'li kuruluşları hedef alan son kampanyası bu taktik üzerine kurulu. (Kaynak: Dark Reading) Beni asıl çıldırtan şey şu: bu teknik yeni değil. BYOVD, en azından 2021'den beri APT gruplarının favorisi. Sektör bunu biliyor, araştırmacılar bunu yazıyor, konferanslarda anlatılıyor — ama savunma tarafındaki operasyonel olgunluk hâlâ gereken seviyede değil. Bunu bir daha anlatmak istemiyordum ama burada oturup sustamam.
Saldırgan Ne Yapıyor — Red Team Gözüyle
Şöyle düşün: hedef sistemde bir EDR (Endpoint Detection and Response) var. User-space'de (kullanıcı alanında) çalışan her şeyi izliyor. Hook'lar kurulu, telemetri akıyor. Normal bir kötü amaçlı yazılım bu katmanda kolayca yakalanır. Peki ya kernel'a inersen?
BYOVD tam burada devreye giriyor. Saldırgan, Windows'un dijital imzalamış olduğu, yani işletim sistemi tarafından 'güvenilir' olarak kabul edilen ama bilinen bir güvenlik açığı barındıran meşru bir sürücü dosyasını sisteme bırakıyor. Bu sürücüyü yükleyince kernel-mode erişimi kazanıyor. Oradan da EDR'ın kancalarını (hooks) söküyor, süreçleri gizliyor, güvenlik araçlarını körleştiriyor. Artık kullanıcı alanında ne yaparsa yapsın, kimse görmüyor.
GodDamn'ın kullandığı akış büyük ihtimalle şuna benziyor:
- İlk erişim (initial access) — phishing ya da açık bir servis üzerinden.
- Açıklı sürücünün drop edilmesi ve yüklenmesi — imzalı, meşru görünümlü.
- Kernel-mode'dan EDR hook'larının sökülmesi (EDR tampering).
- Fidye yazılımının (ransomware) artık 'kör' bir sistemde serbestçe çalışması.
- Şifreleme ve fidye notu.
Adım 3'e dikkat et. Çoğu zaman incident response (olay müdahalesi) sırasında analistler 'EDR neden alarm üretmedi?' diye soruyor. Cevap basit: EDR'a göre ortalık sakin, çünkü kernel seviyesinde gözleri çıkarılmış.
(Aklıma geldi — bu yüzden kernel telemetrisini sadece EDR'a bırakmamak gerekiyor. Ayrı bir ETW [Event Tracing for Windows] kanalı tutmak hayat kurtarıyor.)
Bir red team testi sırasında benzer bir senaryo uygulamıştım. Infracore (kurgusal şirket, SaaS sektörü) için yaptığımız değerlendirmede, bir driver whitelisting mekanizmasının sadece sürücü imzasına baktığını, CVE kaydına bakmadığını keşfettik. Açıklı ama imzalı bir sürücüyü yükleyip kernel handle'larını manipüle edebildik. Raporu yazdığımda savunma ekibinin yüzündeki ifadeyi hatırlıyorum — 'ama imzalıydı' dediler. Evet, tam olarak.
Blue Team: Bunu Nasıl Durdurursun?
Şimdi modu değiştiriyorum. Saldırganın bakış açısını anladıktan sonra savunma tarafına geçelim.
İlk ve en kritik kontrol: açıklı sürücü listesi (vulnerable driver blocklist). Microsoft'un yayınladığı HVCI (Hypervisor-Protected Code Integrity) ve önerilen sürücü engelleme listesi var. Bu listeyi aktif tutuyorsan, bilinen açıklı sürücülerin yüklenmesi doğrudan engelleniyor. Aklında bulunsun: bu liste statik, güncellemek gerekiyor. loldrivers.io adresini yer imlerine ekle — topluluk destekli, güncel bir açıklı sürücü referansı.
İkinci kontrol: kernel davranışı izleme. Bir güvenlik sürücüsünün kendi hook'larının söküldüğünü fark edebilmesi için ya self-monitoring mekanizması olmalı ya da bu tür olayları dışarıdan izleyen ayrı bir katman. Windows'ta ObRegisterCallbacks ve PsSetCreateProcessNotifyRoutine gibi kernel callback'lerin aniden kaybolması ciddi bir sinyal. SIEM'inde bu event'leri ayrı bir kural setiyle izlemiyorsan, kör bir noktandan bakıyorsun demektir.
Aslında yanlış söyledim — daha doğrusu, sadece SIEM yeterli değil. Kernel seviyesindeki bu değişiklikler her zaman standart Windows event log'larına düşmüyor. ETW (Event Tracing for Windows) kanallarını doğrudan tüketen bir çözüm olmadan bu sinyaller gürültüde kayboluyor. Microsoft Defender for Endpoint'in bazı planlarında bu kapsanıyor ama her ortamda o plan olmayabiliyor.
Üçüncü ve pratik bir kontrol: sürücü yükleme politikaları. Grup politikası (Group Policy) ya da Intune üzerinden 'yalnızca WHQL imzalı sürücülere izin ver' demek bir başlangıç ama yeterli değil — BYOVD tam da WHQL imzalı sürücüleri kullandığı için. Bunun ötesine geçip uygulama kontrolü (application control) katmanında sürücü hash whitelisting yapman gerekiyor. Bu zahmetli, biliyorum. Ama alternatifiniz kernel'ı saldırgana açık bırakmak.
Dördüncü kontrol — belki de en sık atlanan: lateral movement tespiti. GodDamn gibi gruplar kernel erişimini fidye yazılımını yaymak için kullanıyor. Bu noktada ağ içi hareketliliği (lateral movement) izlemek kritik. 192.168[.]1[.]100 gibi iç ağ adreslerine anormal SMB ya da WMI trafiği, veya attacker[.]example[.]com benzeri komuta kontrol (C2) çağrıları EDR kör olsa bile ağ katmanında görünebilir. NDR (Network Detection and Response) araçları burada değer üretiyor.
Nereye Vardık?
Bir hafta önce benzer bir tatbikat (tabletop exercise) sırasında bir ekiple BYOVD senaryosunu işledik. 'Bizim EDR bunu yakalar' dediler. 'Sürücü imzalıysa' dedim, 'ama açıklıysa?' Sessizlik. Sonra tartıştık, test ettik, eksikleri gördük.
GodDamn'ın şu an ABD'li şirketleri vurması, yarın başka bir coğrafyada başka bir fidye grubu tarafından aynı teknikle farklı bir sektörün vurulmayacağı anlamına gelmiyor. Healthcare'de çalışan PulseCore (kurgusal şirket, sağlık sektörü) gibi bir organizasyon için bu senaryo, operasyonel sistem kesintisinin çok ötesinde sonuçlar doğurabilir.
Sahada bunları test etmek, raporlamak, savunma ekibine göstermek — işin bu kısmı hiç bitmeyecek. Ve açıkçası, bitmemeli de.