vSphere Guest Operations üzerinden gelen komutları Check Point Harmony neden alarm olarak işaretlemiyor? Bir laboratuvar testinden yola çıkarak Threat Hunting sorgusu, Behavioral Protection kuralı ve 30 günlük geri sayma penceresi ile boşluğu adım adım kapatıyoruz.
EDR platformları, artan saldırı vektörleri ve gelişen davranışsal tekniklerin baskısıyla imza tabanlı tespitten çok davranış tabanlı tespitlere ağırlık veriyor. Dijital olarak imzalı ve güvenilir kabul edilen dosyaların kötüye kullanımı bu ürünler tarafından genel olarak yakalanabiliyor olsa da bazı senaryolarda hâlâ kör noktalar oluşabiliyor. Bu yazıda, vmtoolsd üzerinden yürütülen bir Guest Operations senaryosunun Check Point Harmony Endpoint tarafında nasıl tespit edilebileceğini ele alacağım.
vmtoolsd, VMware Tools kurulumuyla gelen bir servistir. Görevi, hipervizör tarafında verilen komutları misafir işletim sistemine taşımak. İmzalı, meşru ve neredeyse hiç sorgulanmadan çalışmasına izin verilen bir bileşen.
Ama işin bir de öbür yüzü var. Saldırgan vSphere yönetim tarafını ele geçirdiği anda bu kanalı olduğu gibi kullanıyor. Ağa çıkmıyor, oturum açmıyor; komut misafir OS'ta SYSTEM olarak koşuyor. EDR'nin gördüğü tablo, sıradan yönetim aktivitesinden farksız.
Aşağıdaki üç sorunun peşinden gideceğim: Guest Operations üzerinden başlatılan bir PowerShell çağrısı Threat Hunting deposunda ne bıraktı? Behavioral Guard neden sessiz kaldı? Boşluğu kapatmak için Custom Rule'a hangi davranışsal kuralı ekledim?,
Test
Windows Server 2022 misafiri. Üzerinde Harmony Endpoint agent'ı ve varsayılan Threat Prevention policy'si. vSphere yönetim tarafında Guest Operations API'sini çağıran bir script çalıştırdım: StartProgramInGuest ile misafir OS içinde powershell.exe -encodedcommand ... tetiklendi. Komut birkaç sistem dosyasına dokundu ve çıktı.
Sonucu tek cümleyle özetlersem: Harmony her şeyi topladı, tek bir alarm üretmedi.
Threat Hunting Ne Diyor?
Telemetri havuzu dolu. Infinity Portal → Threat Hunting arayüzünde iki basit filtre olayı yüzeye çıkarıyor:
Parent Process Name Is vmtoolsd.exe
Process Name Is cmd.exe
Figure 1: Threat Hunting sorgusu ve sonuç listesi
Seçilen zaman aralığında dönen olayların bir kısmında ebeveyn vmtoolsd.exe, alt süreç cmd.exe ve komut satırı aynı desende: /C powershell -NonInteractive -EncodedCommand .... Yani zincir tek adımlı değil — vmtoolsd, cmd'i doğuruyor; cmd de kodlanmış bir PowerShell komutu çağırıyor. Guest Operations API üzerinden gönderilen komutların tipik izi budur; komut satırındaki EncodedCommand parametresi ise gizleme adımının imzasıdır.
Aynı listede meşru kullanımlar da var: C:\Program Files\VMware\VMware Tools\poweron-vm-default.bat gibi VMware'in kendi başlatma script'leri, misafir açılışında vmtoolsd altında cmd doğuruyor. Bu tür yollara istisna tanımlamak, kuralın FP profilini kabul edilebilir seviyeye çekiyor.
Süreç ağacı, komut satırı, kullanıcı, dosya operasyonu — hepsi kayıtta. Yani sinyal yok değil. Eksik olan tek şey, bu sinyale "önemli" etiketini yapıştıran bir kural.
Behavioral Guard Neden Sessiz?
Üç yapısal sebep aynı anda:
vmtoolsd, VMware'in imzalı ve güvenilir servisi. Publisher güven seviyesi yüksek olduğu için Behavioral Guard'ın davranışsal puanlaması eşiğin altında kalıyor.
İşlem hipervizör kanalıyla geliyor. Ağ tarafında Harmony'nin görebileceği bir bağlantı yok, Anti-Bot devreye girmiyor.
Etkileşimli oturum açılmamış. Logon Type 2/10 kayıtları boş; kimlik doğrulama ile korelasyon kanalları da yok.
Kısacası vmtoolsd → powershell zinciri, tek başına Harmony'nin iz sürme listesinde yer almıyor. Kaydediliyor, sınıflandırılıyor, ama bir uyarıya dönüştürülmüyor.
Gerekli Kural
Infinity Portal içinde Threat Prevention → Behavioral Protection → Custom Rules altına aşağıdaki davranışsal kuralı ekledim. Kuralın kapsamı, testin ortaya çıkardığı cmd → powershell zincirini tek başına yakalamaya yetecek şekilde cmd, powershell, pwsh, cscript ve wscript süreçlerini kapsıyor:
Burada iki uyarı var. Birincisi, aksiyon Detect ile başlıyor. Prevent'e geçmeden önce meşru kullanımlar için istisna tanımlamak gerekiyor; VMware'in kendi Toolbox script'leri, poweron-vm-default.bat gibi başlatma dosyaları veya Ansible / Terraform gibi otomasyon araçları geçici olarak bu zinciri kullanabiliyor. İkincisi, kural tek başına yetmiyor — vSphere denetim log'u ile eşleştirilmediği sürece endpoint tarafındaki her PS çağrısı aynı ağırlıkta görünüyor. Guest Operations event'i olmayan bir tetikleme bambaşka bir anlama gelir.
Kaydetmeden Önce Doğrula
Kuralı kaydetmeden önce aynı sorguyu son 30 gün üzerinde çalıştırmak gerekiyor. Amaç: bu kural yayına alındığında kaç alarm doğacak, hangi endpoint'lerden geleceği, hangi komut satırı desenleri kapsanacak. Aralarında FP oluşturan durumlar varsa kural üzerinde gerekli düzenleme yapıldıktan sonra kural kaydedilmeli.
Endpoint Kuralı Yetmiyor — Hipervizör Tarafını da Kapat
Boşluğun kaynağı vSphere yönetim düzlemi. Endpoint tarafındaki kural ancak sonuç kısmını görüyor; ihtiyaç, aynı zamanda kaynağa da yaklaşmak.
vCenter erişimini MFA + PAM arkasına al. Yönetici oturumları immutable bir log kanalına düşsün.
vSphere RBAC'te Guest Operations privileges'ı sadece iş ihtiyacı olan role bırak. Ne kadar az rol, o kadar dar saldırı yüzeyi.
Guest OS tarafında PowerShell Constrained Language Mode aktif olsun. Üstüne AppLocker veya WDAC katmanı.
Script Block Logging, Module Logging, Transcription — üçü birden aktif ve log'lar merkezi SIEM'e giden bir kanalda.
Harmony tarafındaki Behavioral Protection istisnalarını gözden geçir. Sadece signer bazlı geniş istisnalar tehlikeli; path + hash + signer üçlüsü olmadan istisna yayınlanmasın.
Ömer Kaan Kurt — L1 MDR Analyst
InfinitumIT MDR — Detection Engineering & Threat Hunting
Bu yazı gerçek bir EDR ortamında yapılan test ve kural simülasyonu sonuçlarına dayanmaktadır.
