Tartışma

EDR/XDR’ye Karşı Direct Syscalls Tehdidi

Başlatan İMRAN · 06 Oca 2026 23:12 · 5 Görüntülenme · 0 Yanıtlar
Konuyu Açan #0
Hell’s Gate sınıfı yaklaşımlar ve User-mode API Hooking’in kör noktaları (Defansif İnceleme – VIP)


1) Temel fikir (yüksek seviye)


Birçok EDR, kullanıcı modunda (user-mode) yaygın Win32/NT API çağrılarını hook’layarak telemetri üretir. Bu yaklaşım pratik ama doğası gereği “bypass edilebilir”dir; Microsoft da user-mode hooking’in, süreç içinde kod çalıştırabilen bir saldırgan tarafından unhook veya doğrudan syscall ile aşılabileceğini açıkça not eder. Microsoft


Direct syscalls sınıfı yaklaşımlar (Hell’s Gate ismiyle anılan aile dahil), kabaca “user-mode hook’ların etrafından dolaşma” hedefindedir. Burada kritik olan: mesele tek bir teknik değil; EDR’nin yalnız user-mode’a dayanmasının kırılganlığı. Elastic+1




2) Savunmacı için “risk nerede?”


Bu tehdit sınıfı en çok şu boşluklardan fayda bulur:


  • Sadece user-mode sensör: Kernel telemetri zayıfsa, user-mode atlatılınca görünürlük düşer. Elastic
  • Bellek bütünlüğü izlenmiyor: Kritik DLL’lerde (ör. sistem çağrı katmanı) anormal değişimler fark edilmiyorsa. Deep Instinct+1
  • Davranış korelasyonu yok: “Hook görmedim” diye olay yok sayılır; halbuki davranış (süreç/iş parçacığı/handle/memory) bağırıyordur. Microsoft+1



3) “Bypass ettiler” diye oyun bitmez: Hâlâ yakalanırlar


Elastic’in kernel ETW call stack yaklaşımı gibi çalışmaların ana mesajı şu: user-mode hook kırılgan olsa da kernel telemetri ve call-stack bağlamı ile anomali yakalanabilir. Elastic+1


Savunma açısından pratik sinyaller (genel, ürün bağımsız):


  • Şüpheli bellek davranışı: kısa sürede RX/RWX sayfa artışı, bellek koruma değişimleri, beklenmedik region’lar
  • Process/Thread anomalleri: beklenmeyen thread start, APC/handle pattern’leri, süreçler arası etkileşim
  • Telemetry “sessizliği” anomalisi: normalde beklenen API/ETW/AMSI sinyalleri yokken davranışsal etki var (bu “ghost” etkisi) Microsoft+1
Önemli: Burada detaylı saldırı akışı vermiyorum; SOC’un “hangi sınıf sinyali” izlemesi gerektiğini özetliyorum.



4) Blue Team / SOC için Tespit Stratejisi (VIP pratik)


4.1 “Kernel-first” görünürlük


  • EDR/XDR’de mümkünse kernel telemetri (ETW kernel provider’lar, kernel callbacks, driver sensörleri) etkin ve korelasyonlu olmalı. Elastic+1
  • Call-stack zenginliği olan telemetri, “normal API yolu” ile “anormal yol” ayrımını güçlendirir. Elastic+1

4.2 Bellek bütünlüğü kontrolleri


  • Kritik kullanıcı-modu modüllerinde beklenmeyen değişim/hotpatch benzeri durumları izleyen kontroller (ürün/EDR özelliğine göre). User-mode hooking’in kolay bypass edilebildiği gerçeği, bu kontrollerin değerini artırır. Deep Instinct+1

4.3 “Sessizlik” anomalisini alarm yap


  • Normalde görülen güvenlik arayüzlerinin (ör. AMSI gibi) telemetrisinde ani düşüşler/boşluklar, olay triage için güçlü sinyal olabilir. (MDE’nin AMSI kullanımına dair arka plan: Microsoft Learn)



5) Sertleştirme (Hardening): Bypass maliyetini yükselt


5.1 Yapılandırma ve platform güvenliği


  • Sanallaştırma tabanlı korumalar (HVCI/Memory Integrity), saldırganın “sessiz bellek” oyunlarını zorlaştırabilir (kurum politikalarına göre).
  • Uygulama kontrolü (WDAC/AppLocker) ve imza politikaları: bilinmeyen loader/ikili çalıştırmayı azaltır.

5.2 EDR mimarisi


  • “User-mode hook”u tek dayanak yapma. Kernel telemetri + davranış analitiği + bellek sensörleri birlikte olmalı. Elastic+1
  • Alert’leri “tek olay” değil, kill-chain korelasyonu ile ele al (process tree + network + memory).

5.3 Operasyonel önlemler


  • Yüksek riskli endpoint’lerde ek logging katmanları (Sysmon/ETW kaynakları, güvenilir audit)
  • Olay müdahale runbook: “telemetri körlüğü” şüphesinde bellek dump, canlı yanıt, imaj bütünlüğü kontrolü.

Yanıt vermek için giriş yapmış olmalısınız.

0 alıntı seçildi