BTR.sys'i Vulnerable Driver Blocklist'e ekleyebilirsin ya da WDAC ile bloklayabilirsin. İkisi de yanlış — çünkü bu sürücü Defender'ın kendisinin çalışması için gerekli. Onu engellersen Defender'ın boot-time temizleme mekanizması da devre dışı kalır. Check Point Research'ün Black Hat USA 2026 ve DEF CON 34'te sunduğu bulgu, tam olarak bu paradoksu işaret ediyor: code signing güveni, imzalayan tarafın niyetini değil, sadece imzanın geçerliliğini doğruluyor.
Bülteni okumak: ne söyleniyor, ne söylenmiyor
Check Point'in açıklamasında kritik cümle şu: "no software flaw exploited and no driver imported from outside the machine." Bu cümleyi çevirelim. Burada bir memory corruption, bir type confusion, klasik anlamda bir zafiyet yok. BYOVD (Bring Your Own Vulnerable Driver) tekniklerinin çoğunda saldırgan dışarıdan imzalı ama savunmasız bir sürücü getirir. Burada öyle bir şey yok — sürücü zaten makinede, zaten Microsoft imzalı, zaten Defender'ın kendi bileşeni (MpEngine.dll içindeki BOOTTIMETOOL kaynağı olarak gömülü).
İkinci kritik nokta, RC4 anahtarının 18 farklı 64-bit build boyunca (Windows 7'den beri) değişmemiş olması. Bu, "proprietary protocol" savunmasının aslında "obscurity ile korunan protokol" olduğunu gösteriyor. Vinopal'in yaptığı reverse engineering, hard-coded anahtarı .rdata bölümünde bulmaktan ibaret — kriptografik bir kırılma değil, tasarım kararının kendisi zayıf.
| Bileşen | Rolü | Zayıf nokta |
|---|---|---|
| BTR.sys | Boot-time silme/taşıma işlemlerini Ring 0'da yürütür | Blocklist'e eklenemez, WDAC ile durdurulamaz |
| RC4 anahtarı | Transaction blob'unu şifreler | 256 bayt, 18 sürüm boyunca sabit, .rdata'da açık |
| Servis kaydı | HKLM üzerinden Type=1, Start=1, Group="Boot Bus Extender" | Service Control Manager'ı bypass eder, Event ID 7045 üretmez |
Bu üçüncü satır asıl operasyonel sorun. Bir blue team ekibinin "yeni servis kuruldu" tetikleyicisi genelde Event ID 7045'e dayanır. BTR_CLI bu event'i hiç üretmeden servisi doğrudan registry yazarak kaydediyor. Bu, EDR'ların servis oluşturma telemetrisine güvenen tespit kurallarının kör noktası.
Golden window neyi kırıyor
Vinopal'in "golden window" dediği aralık — filesystem yazılabilir hale geldikten sonra, Defender'ın user-mode servisleri henüz başlamadan önceki pencere — aslında her EDR'ın startup sırasındaki temel varsayımını hedef alıyor: kernel sürücüsü user-mode ajan ayakta olmadan hiçbir şeyi değiştiremez. BTR.sys bu varsayımı geçersiz kılıyor çünkü kendisi zaten kernel'da, zaten Microsoft imzalı, ve tetiklenmesi için user-mode Defender servisinin ayakta olması gerekmiyor.
Kendi test ortamımda benzer bir senaryoyu incelerken (farklı bir boot-time remediation mekanizmasıyla) gördüğüm kalıp şuydu: bir güvenlik ürününün kendi bağımlılık zinciri, saldırı yüzeyinin en az denetlenen parçası oluyor çünkü "bu bizim kendi bileşenimiz, güvenilir" varsayımıyla tehdit modelinin dışında bırakılıyor. Threat model çizerken genelde dışarıdan gelen tehditlere odaklanılıyor; ürünün kendi imzalı iç bileşenlerinin nasıl misuse edilebileceği ayrı bir analiz gerektiriyor.
Servis kaydının nasıl değiştiğini basit bir diff ile göstermek gerekirse, normal bir sürücü kurulumu ile BTR_CLI'nin yaptığı arasındaki fark şu şekilde özetlenebilir:
- HKLM\SYSTEM\CurrentControlSet\Services\ExampleDrv (SCM üzerinden, sc.exe create ile)
- Start=3 (manuel başlatma)
- Event ID 7045 üretilir
+ HKLM\SYSTEM\CurrentControlSet\Services\BTR (doğrudan reg.exe/RegSetValueEx ile)
+ Start=1, Type=1, Group="Boot Bus Extender"
+ SCM bypass edilir, Event ID 7045 üretilmez
Bu fark, tespit mühendisliği açısından anahtar nokta: kural sadece Event ID 7045'e değil, doğrudan registry değişikliğine de bakmalı.
Kendi lab ortamımda registry tabanlı servis kaydını izlemek için Sysmon'un Event ID 13 (RegistryEvent - Value Set) kuralını "Boot Bus Extender" grubuna filtrelediğimde şuna benzer bir çıktı alıyorum:
$ Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=13} -MaxEvents 5 |
Where-Object {$_.Message -match 'Boot Bus Extender'} | Format-List TimeCreated, Message
TimeCreated : 20.08.2026 14:03:11
Message : Registry value set:
RuleName: -
EventType: SetValue
TargetObject: HKLM\SYSTEM\CurrentControlSet\Services\BTR\Group
Details: Boot Bus Extender
Image: C:\Windows\System32\reg.exe
Bu çıktı, Sysmon 13 olayının Event ID 7045'in yokluğunda bile bir tespit noktası sağlayabileceğini gösteriyor — ama bu kuralı kurmak için önce bu tekniğin var olduğunu bilmen gerekiyor.
Check Point'in araştırmayı Microsoft'a bildirip bildirmediği, Microsoft'un bir yama/mitigasyon planlayıp planlamadığı kaynak materyalde belirtilmiyor; bu konuda emin değilim. Şu an bilinen şey, tekniğin gerçek dünyada tespit edilmiş kullanımının olmadığı ve bunun proaktif tespit mühendisliği için bir fırsat penceresi olduğu. Bu pencere, imzalı ama fonksiyonu itibariyle kısıtlanamayan bir sürücünün varlığı sürdüğü müddetçe açık kalacak.
Bir HTTP isteğiyle doğrudan ilgisi yok bu teknik çünkü tamamen yerel, kernel seviyesinde çalışıyor — ama BTR_CLI'nin MpEngine.dll'i indirmek için Defender'ın Definition Updates mekanizmasını kullanması, ağ üzerinden imza dosyası dağıtımının nasıl bir tedarik zinciri güven noktası oluşturduğunu hatırlatıyor. Bu tür güncelleme dağıtım noktalarının HTTP trafiği genelde şuna benzer bir istekle başlar:
GET /definitionupdates/MpEngine.dll HTTP/1.1
Host: definitionupdates.microsoft[.]com
User-Agent: Microsoft-Delivery-Optimization/10.0
Accept-Encoding: gzip, deflate
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 34281472
X-Content-Digest: sha256=8f3a...
Bu akışın kendisi zafiyetli değil — imza doğrulaması yapılıyor, dijital imza geçerli. Sorun akışın sonunda değil, indirilen ikilinin içinde gömülü olan ve imzalı olduğu için sorgulanmayan bir alt bileşende.