EDR Kör Etme Sanatı: SCM Telemetrisi ve Wazuh ile BYOVD (T1068) Saldırılarının Tespiti
SCM Telemetrisi ve Wazuh ile BYOVD (T1068) Saldırılarının Tespiti
Gelişmiş tehdit aktörleri ve fidye yazılımı grupları tarafından EDR/AV ajanlarını tamamen devre dışı bırakmak amacıyla kullanılan BYOVD (Bring Your Own Vulnerable Driver) tekniğini inceliyoruz. Komut satırı takibinin ötesine geçerek, Windows Service Control Manager (SCM) Event ID 7045 telemetrisi ve iki aşamalı gürültüsüz (low-noise) Wazuh kural mimarisiyle production ortamına hazır bir tespit stratejisi kurguluyoruz.
Özet
Bu çalışma, Windows çekirdek katmanında (Kernel-land) koruma sağlayan güvenlik mekanizmalarını bypass etmek için meşru ama zafiyetli sürücülerin (Driver) istismar edilmesini temel alan BYOVD (Bring Your Own Vulnerable Driver) saldırı vektörünü ele almaktadır. Saldırganların Ring 0 yetkileri elde ederek EDR (Endpoint Detection and Response) ajanlarını susturmasını engellemek adına, süreç takibine dayalı geleneksel ve zayıf tespit yöntemleri yerine Service Control Manager (SCM) seviyesinde yapısal bir izleme kurgulanmıştır. Çalışma kapsamında, kurumsal ortamlarda yüksek False Positive gürültüsü yaratmayacak, şüpheli yolları (Paths) ve bilinen zafiyetli imajları hedef alan iki aşamalı bir Wazuh kural hiyerarşisi tasarlanmış ve pratik bir PoC (Proof of Concept) simülasyonu ile doğrulanmıştır.
Genel Bakış ve Tehdit Modeli: BYOVD Nedir?
Modern işletim sistemlerinde güvenlik ajanları ve kritik koruma bileşenleri, kullanıcı katmanındaki (User-land) manipülasyonlardan etkilenmemek adına çekirdek katmanında (Kernel-land / Ring 0) çalışır. Gelişmiş kalıcı tehdit (APT) aktörleri ve modern fidye yazılımı grupları, sıfır-gün (Zero-day) bir kernel zafiyeti aramakla uğraşmak yerine daha az maliyetli ve daha sinsi bir yönteme başvurur: BYOVD.
Bu teknikte saldırganlar, hedef sisteme Microsoft tarafından dijital olarak imzalanmış, tamamen yasal ancak üzerinde kod yürütme veya doğrudan bellek manipülasyonu zafiyeti barındığı bilinen eski sürücüleri (örn. gdrv.sys, mhyprot2.sys, rtcEvt64.sys) getirir. Sürücü meşru bir sertifikaya sahip olduğu için Windows Kernel tarafından güvenle yüklenir. Saldırgan, bu zafiyetli sürücüye User-land üzerinden özel IOCTL (Input/Output Control) istekleri göndererek Ring 0 yetkilerine ulaşır. Bu noktadan sonra EDR ajanlarının bellek süreçlerini sonlandırabilir, imza kontrollerini bypass edebilir ve güvenlik loglarını tamamen susturabilir.
Defansın Kör Noktası (The Blind Spot)
Geleneksel SOC ekipleri ve SIEM kuralları, sürücü yükleme ve servis oluşturma aktivitelerini çoğunlukla süreç oluşturma telemetrisine (Event ID 4688 veya Sysmon Event ID 1) güvenerek izler. Saldırganların komut satırıından yürüteceği sc.exe create benzeri girdiler aranır. Ancak bu yaklaşım ciddi bir blind spot barındırır. Gelişmiş malware yapıları, komut satırı araçlarını kullanmak yerine doğrudan Windows alt seviye API’lerini (örn. CreateServiceW, NtLoadDriver) çağırarak çekirdek servislerini arka planda kaydedebilir. Bu durum komut satırı loglamasını tamamen bypass eder ve defansı kör bırakır.
Çözüm, doğrudan servisin kaydedildiği ve yönetildiği merkeze, yani Service Control Manager (SCM) veritabanına odaklanmaktır. SCM, sisteme yeni bir servis veya kernel driver eklendiğinde bunu doğrudan Windows System Event ID 7045 (New Windows Service Created) loguyla tesciller. Saldırgan hangi API’yi kullanırsa kullansın, bu telemetri alanından kaçamaz.
Wazuh İçin Üretim Ortamına Hazır (Production-Ready) Kural Mimarisi
Canlı bir kurumsal üretim (Production) ortamında sisteme yüklenen her kernel modu sürücüsüne yüksek seviyeli (high-level) alarmlar üretmek tam bir felakettir. Antivirüs güncellemeleri, VPN yazılımları, sanallaştırma çözümleri (VMware, VirtualBox) veya meşru sistem sürücüleri sürekli SCM kaydı bırakır. Bu durum SOC analistlerinde algı körlüğüne (Alert Fatigue) neden olur.
Bu gürültüyü engellemek adına iki aşamalı bir kural hiyerarşisi tasarlanmıştır. İlk kural, sistemdeki tüm kernel modu sürücü yüklemelerini yakalar ancak alarm seviyesini düşük tutar (Level 3). İkinci kural ise ilk kuralı paranteze alarak, yalnızca şüpheli dizinlerden (Temp, Public, AppData) yüklenen veya bilinen BYOVD bileşenleriyle eşleşen girdileri filtreleyip alarmı kritik seviyeye (Level 13) yükseltir.
Wazuh kural motoruna (local_rules.xml) dahil edilecek optimize edilmiş mimari:
<group name="windows,sysmon,byovd">
<!-- Kural 100500: Genel Kernel Sürücü Kayıt Takibi (Düşük Seviye) -->
<rule id="100500" level="3">
<if_sid>61138</if_sid> <!-- Parent Kural: Yeni Windows Servisi Oluşturuldu -->
<field name="win.eventdata.serviceType">kernel mode driver</field>
<description>Windows: A new kernel mode driver was registered.</description>
</rule>
<!-- Kural 100501: Şüpheli Klasör veya Imaj Filtreli BYOVD Tespiti (Kritik Seviye) -->
<rule id="100501" level="13">
<if_paragraph>100500</if_paragraph>
<!-- Regex ile şüpheli yollar ve bilinen istismar sürücü isimleri taranır -->
<field name="win.eventdata.imagePath">(?i)\\temp\\|\\users\\public\\|\\appdata\\|gdrv\.sys|mhyprot2\.sys</field>
<description>Critical Threat - BYOVD (Bring Your Own Vulnerable Driver) Attack Detected! Suspicious Driver Loaded.</description>
<mitre>
<id>T1543.003</id>
<id>T1068</id>
</mitre>
</rule>
</group>
Atak Simülasyonu ve Doğrulama (Proof of Concept)
Geliştirilen tespit mimarisini test etmek amacıyla laboratuvar ortamında kontrollü bir simülasyon gerçekleştirilmiştir. Saldırganların sıkça tercih ettiği zafiyetli sürücü şablonu, geçici bir klasöre (Temp) bırakılarak bir çekirdek servis context’i oluşturulmuştur.
Simülasyon adımları (PowerShell):
# Sürücü imajı şüpheli yola kopyalanır ve servis SCM üzerinde oluşturulur
sc.exe create MaliciousDriver binPath= "C:\windows\temp\gdrv.sys" type= kernel
Bu komut çalıştırıldığı anda SCM veritabanı tetiklenir ve Windows System logları arasına Event ID 7045 düşer. Wazuh kural motorundaki 100500 nolu kural durumu analiz eder; ardından imagePath alanında temp dizinini ve gdrv.sys ifadesini yakalayan 100501 nolu kural otomatik devreye girerek Wazuh Dashboard ekranına Level 13 seviyesinde bir kritik alarm fırlatır.
Triage Parametreleri ve Log Analizi
| Field (Log Alanı) | Analiz Değeri ve IOC Anlamı |
|---|---|
win.eventdata.serviceName |
MaliciousDriver (Saldırganın atadığı servis adı) |
win.eventdata.imagePath |
C:\windows\temp\gdrv.sys (Zararlı driver’ın diskteki tam konumu) |
win.eventdata.serviceType |
kernel mode driver (Saldırının Ring 0 katmanını hedeflediğinin kanıtı) |
rule.mitre.id |
T1543.003, T1068 (Kalıcılık ve Yetki Yükseltme taktik eşleşmeleri) |
Laboratuvar Temizliği
Simülasyon sonrasında test ortamını eski stabil haline getirmek, artık kayıtları temizlemek ve servis mimarisini sıfırlamak için şu komut yürütülür:
sc.exe delete MaliciousDriver
SOC Ekipleri İçin Önemli Çıkarımlar
- Süreç Değil, Servis Odaklı İzleme: Saldırganların komut satırı loglarını tamamen bypass edebileceğini unutmayın. Tespit mekanizmalarınızı
sc.exetakibinden doğrudan SCM telemetrisine kaydırın. - Hassas Filtreleme ve Performans: Kurumsal ağlarda performans kaybı yaşamamak ve False Positive gürültüsünü engellemek için kural mimarinizi iki aşamalı tasarlayın; ana filtreleri şüpheli klasör yolları ve bilinen imaj isimleriyle daraltın.
- Sürücü Engelleme Listeleri (Driver Blocklisting): Tespit mühendisliğinin yanı sıra proaktif bir koruma için Microsoft’un Önerilen Sürücü Engelleme Kurallarını (Vulnerable Driver Blocklist) sistemlerinizde aktif hale getirin.
Laboratuvar Dosyaları ve Uygulamalar
Bu projede kurgulanan ve test edilen tüm konfigürasyonlara, optimize edilmiş Wazuh kural setlerine ve laboratuvar araçlarına resmi GitHub reposu üzerinden erişebilirsiniz: GitHub - Wazuh-BYOVD-Guardian
Sen de yaz, arşivde yerini al
AltaySec Arşiv'e katkı ver — uzmanlığını Türkçe siber güvenlik literatürüne kat.
Yazar Ol