Microsoft Defender for Endpoint özelinde bir EDR kör noktasının anatomisi: tespit boşluğu nerede açılıyor, Advanced Hunting ile nasıl kapatılır, Microsoft bu sınıf riski nasıl çerçeveliyor.
Giriş
Modern EDR/XDR ürünlerinin büyük kısmı, artık imza değil davranış üzerinden karar veriyor: hangi sürecin hangi süreci başlattığı, komut satırının şekli, ebeveyn zincirinin "normal" görünüp görünmediği. Bu yaklaşım dosya tabanlı tespiti büyük ölçüde geride bıraktı, ama beraberinde yeni bir kör nokta getirdi — ebeveyn süreç imzalı ve güvenilirse, ajanın büyük kısmı child sürece neredeyse hiç şüpheyle bakmıyor.
Biz bu varsayımı laboratuvar ortamında test ettik: VMware vSphere altyapısında, hipervizör yönetim düzleminden misafir işletim sistemine gönderilen bir PowerShell komutunun, altı farklı EDR/XDR ürününde alarm üretip üretmediğine baktık. Sonuç, ürün bağımsız bir örüntüydü — hiçbiri varsayılan yapılandırmada bir şey görmedi. Bu bulguyu 1 Temmuz 2026'da INFINITUM-SA-2026-07-001 bülteni olarak paylaştık. Bu yazıda aynı vakayı Microsoft Defender for Endpoint (MDE) özelinde derinlemesine ele alıyoruz.
Vaka: vmtoolsd ve Guest Operations
VMware Tools'un host tarafındaki bileşeni vmtoolsd.exe, VMware imzalı ve neredeyse her uç nokta ajanının dosya itibar veritabanında güvenilir olarak işaretli bir servistir. vSphere'in GuestProcessManager.StartProgramInGuest API'si, bu servis üzerinden host VM içinde program çalıştırılmasına izin verir — otomasyon, ajan dağıtımı gibi tamamen meşru senaryolar için tasarlanmış bir olaydır.
Buradaki kritik ayrıntı şu: bu yürütme ne ağ üzerinden (SMB/WinRM/RDP) ne de etkileşimli bir oturumdan gelir. Komut, VMX/hipervizör kanalı üzerinden doğrudan vmtoolsd.exe'nin alt süreci olarak doğar. Yani uç nokta ajanının alıştığı iki büyük korelasyon kaynağı — ağ telemetrisi ve oturum telemetrisi — bu senaryoda baştan devre dışıdır.
EDR'lar Bunu Neden Kaçırıyor
Testlerde gözlemlediğimiz kaçırma nedenini tek bir faktöre indirgemek yanıltıcı olur; aslında üst üste binen dört ayrı etki var:
Bunu bir "ürün açığı" olarak okumak yanlış olur. Her altı üründe de süreç telemetrisi kayboldu değil — sadece hiçbiri bunu varsayılan politikada alarma çevirmedi. Aradaki fark önemli, çünkü çözüm de ona göre şekilleniyor: eksik olan görünürlük değil, korelasyon.
MDE Özelinde: Kayıt Var, Alarm Yok
MDE'nin süreç oluşturma görünürlüğü, çekirdeğe kayıtlı bir PsSetCreateProcessNotifyRoutineEx bildirim rutini ve tamamlayıcı ETW (Event Tracing for Windows) sağlayıcılarından besleniyor. Bu olaylar DeviceProcessEvents tablosuna düşüyor ve şu alanları taşıyor:
InitiatingProcessFileName, InitiatingProcessId— raporlanan parentFileName, ProcessCommandLine, AccountName— child processInitiatingProcessParentFileName— grand-parent (zincir analizinde işe yarıyor)ProcessUniqueId / InitiatingProcessUniqueId— PID tekrar kullanımı sorununu ortadan kaldıran, örneğe özgü kimlikler
Test ortamımızda vmtoolsd.exe altında başlatılan powershell.exe süreci, DeviceProcessEvents'te eksiksiz bir satır olarak duruyordu — komut satırı dahil. Yani MDE'nin telemetri toplama katmanında hiçbir kayıp yok. Kaçırılan şey, bunun üstüne oturan varsayılan alarm mantığı: imzalı bir ikilinin child süreç yaratması, MDE'nin bulut tarafındaki davranışsal modelleri için düşük öncelikli/gürültü ağırlığında değerlendiriliyor. Bu, false-positive oranını düşük tutmaya yönelik bilinçli bir tasarım tercihi ama pratikte VMware bültenimizde gördüğümüz boşluğun MDE'deki birebir karşılığı.
Advanced Hunting sorgusu
Tespit Yaklaşımı: Advanced Hunting'den Custom Detection Rule'a
Bahsedilen sorgunun kural olarak MDE sistemine eklenmesi için şunları yapabilirsiniz:
Custom Detection Rules > Create detection rule:
Gerekli alanları görseldeki gibi doldurabilir ve ardından Add query butonuna basabilirsiniz:
Bu query'i ilgili alana yazarak test edebilir ve ardından onaylayabilirsiniz:
Alarm ayarlarını tercihinize göre ayarlayabilirsiniz:
Bu aşamada alarm tetiklendikten sonraki aksiyonu belirleyebilirsiniz fakat daha önce belirtildiği gibi ilk etapta bir aksiyon alınması tavsiye edilmemektedir:
Bu kısımda ise bu kuralın organizasyonunuzun içerisindeki kapsamını belirleyebilirsiniz:
Son aşamada oluşturduğunuz kuralı gözden geçirdikten sonra Submit butonuna basabilirsiniz:
Microsoft Bu Konuyu Nasıl Ele Alıyor?
vmtoolsd üçüncü taraf bir bileşen olduğu için Microsoft'un doğrudan bir açıklaması yok — ama aynı mimari boşluk Microsoft'un kendi Azure Guest Agent / Run Command özelliği için de geçerli, ve orada üreticinin duruşunu net görüyoruz. Microsoft Security Blog'daki Storm-0501 analizlerinde (Eylül 2024 ve Ağustos 2025), aktörlerin Azure Run Command'i RDP/SSH gerektirmeden SYSTEM bağlamında script çalıştırmak için kullandığını Microsoft kendisi tarif ediyor ve bunu "hibrit bulut ortamlarında görünürlük boşluğu" olarak adlandırıyor. Çözüm olarak da MDE'yi tek başına yeterli görmüyor; Defender for Cloud ve Defender for Cloud Apps'in birlikte devreye alınmasını öneriyor.
Yani üreticinin felsefesi şu: "yönetim düzleminden gelen, kimlik doğrulamalı, imzalı bir aracın meşru kullanımı" bir ürün açığı değildir; asıl kontrol noktası o yönetim düzlemine erişimin sıkılaştırılmasıdır. MDE bilinçli olarak varsayılan alarm üretmiyor ve boşluğu kapatma sorumluluğunu custom detection rule + kontrol düzlemi log korelasyonu üzerinden müşteriye bırakıyor.
Kapanış
vmtoolsd örneği aslında daha büyük bir ailenin sadece bir üyesi. Aynı mimari örüntüyü (OS dışından, oturumsuz, imzalı-güvenilir ebeveyn altında komut yürütme) SCCM, Intune, bulut guest agent'ları ve çeşitli RMM araçlarında da görüyoruz — bunu ayrı bir yazıda ele alacağız. Buradaki asıl çıkarım, tek bir ürünü suçlamak değil: davranışsal tespitin güvendiği "imzalı = masum" varsayımının, yönetim düzlemine erişimi olan bir aktör için ne kadar kolay tersine çevrilebildiğini görmek. MDE bu senaryoda görünürlüğü kaybetmiyor; kararı size bırakıyor. Custom detection rule'u yazıp yazmamak, o kararı önceden vermiş olmak demek.
Selman Bilal SİVRİ — L2/L3 MDR Analyst
InfinitumIT MDR — Detection Engineering & Threat Hunting
Bu yazı, gerçek bir Microsoft Defender for Endpoint ortamında yürütülen kontrollü test ve Rule Simulation sonuçlarına dayanmaktadır.
