İmzalı ve güvenilir process'ler her zaman güvenli davranışlar sergilemez. Bu makalede VMware Guest Operations üzerinden vmtoolsd.exe aracılığıyla başlatılan işlemlerin CrowdStrike Falcon ile tespiti ve engelleme yaklaşımlarını inceliyoruz — endpoint telemetry, hunting query, önerilen Custom IOA ve tuning adımlarıyla.
Modern EDR çözümleri, klasik antivirüs yaklaşımındaki imza tabanlı tespitlerin ötesine geçerek endpoint üzerinde oluşan davranışları bütünsel olarak analiz eder. Process oluşturma, parent-child ilişkisi, komut satırı parametreleri, dosya sistemi hareketleri, network bağlantıları, registry değişiklikleri ve kullanıcı bağlamı birlikte değerlendirildiğinde daha güçlü bir saldırı görünürlüğü elde edilir.
Ancak EDR mimarisinde hâlâ dikkat edilmesi gereken kritik bir alan vardır: dijital olarak imzalı ve kurumsal ortamlarda güvenilir kabul edilen process'lerin kötüye kullanımı. Bu process'ler işletim sistemi, yönetim araçları veya sanallaştırma platformları tarafından meşru amaçlarla kullanıldığı için tek başına yüksek riskli kabul edilmeyebilir. Bu durum saldırganlar açısından önemli bir avantaj yaratır; çünkü güvenilir process altında başlayan davranışlar, bağlam analizi yapılmadığında sıradan operasyonel aktivite gibi görünebilir.
Bu makalede VMware Tools bileşeni olan vmtoolsd.exe üzerinden Guest Operations kötüye kullanımını CrowdStrike Falcon perspektifinden inceliyorum. Kontrollü lab ortamında gerçekleştirilen testlerde, vCenter/ESXi katmanından guest VM içerisine indirilen komutların Falcon üzerinde nasıl telemetry bıraktığı, hangi query'lerle izlenebildiği ve vmtoolsd.exe parent process'i altında beklenmeyen child process'leri yakalamak için nasıl bir Custom IOA kuralı tasarlanabileceği ele alınmaktadır.
Vmware Tools Case'i
VMware Tools, guest işletim sistemi ile hypervisor/vCenter katmanı arasında entegrasyon sağlayan kritik bir bileşendir. Windows guest işletim sistemlerinde VMware Tools daemon bileşeni vmtoolsd.exe olarak görülür. Normal şartlarda bu process zaman senkronizasyonu, guest bilgisi toplama, araç entegrasyonu ve Guest Operations gibi yönetim fonksiyonları için kullanılır.
Guest Operations API'leri kullanıldığında vCenter veya ESXi üzerinden guest VM içinde process başlatmak, process listelemek, guest dosya işlemleri yapmak veya credential doğrulamak mümkündür. Bu davranış, guest işletim sistemine RDP ile bağlanmadan veya PsExec/WinRM/SMB gibi klasik protokolleri kullanmadan gerçekleşebilir. Bu nedenle olayın endpoint üzerindeki ana göstergesi çoğu zaman vmtoolsd.exe parent process'i altında başlayan child process olur.
Bu senaryoda saldırgan veya yetkili bir otomasyon hesabı, Guest Operations yetkisine sahipse guest VM içinde komut başlatabilir. Komut benign bir yönetim script'i de olabilir, zararlı bir post-exploitation davranışı da olabilir. Detection açısından kritik nokta, vmtoolsd.exe altında hangi child process'in hangi komut satırıyla ve hangi kullanıcı bağlamında çalıştığıdır.
CrowdStrike ve diğer EDR Platformları bu aktiviteyi neden kaçırabilir
Bu davranış her zaman native alarm üretmeyebilir. Bunun birkaç nedeni vardır:
- vmtoolsd.exe dijital olarak imzalı ve kurumsal VMware ortamlarında normal görülen bir process'tir.
- Guest Operations ile başlayan işlem, klasik remote execution protokolleri olan RDP, WinRM, SMB veya PsExec paterni üretmeyebilir.
- EDR agent guest VM içindeki process telemetry'sini görse bile vCenter/ESXi tarafındaki API çağrısı ile otomatik korelasyon kurmayabilir.
- vmtoolsd.exe altında başlayan child process benign komut çalıştırıyorsa davranışsal risk skoru native detection eşiğini geçmeyebilir.
- Backup, VCF, cloud management veya otomasyon hesapları da Guest Operations API'lerini meşru amaçlarla kullanabilir; bu nedenle yalnızca API çağrısı görmek alarm için yeterli değildir.
CrowdStrike Falcon Perspektifinden Tespit Yaklaşımı
CrowdStrike tarafında bu senaryo iki temel katmanda ele alınmalıdır. İlk katman, guest VM üzerinde çalışan Falcon Sensor'ın topladığı endpoint telemetry verileridir. Bu noktada en kritik sinyal, ProcessRollup2 eventlerinde ParentBaseFileName alanının vmtoolsd.exe olması ve bu parent process altında powershell.exe, cmd.exe, pwsh.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, regsvr32.exe veya msiexec.exe gibi beklenmeyen child process'lerin başlatılmasıdır.
İkinci katman ise vCenter ve ESXi loglarının Falcon Next-Gen SIEM / LogScale tarafına alınarak korelasyon yapılmasıdır. vpxd.log, vpxa.log ve hostd.log içerisinde Guest Operations aktiviteleri, ilgili kullanıcı veya servis hesabı, operation ID ve API method bilgileri incelenebilir. En güçlü tespit yaklaşımı, vCenter/ESXi üzerindeki GuestOps aktiviteleri ile guest VM içerisindeki vmtoolsd.exe parent-child process telemetry'sinin aynı zaman penceresinde ilişkilendirilmesidir.
Falcon Advanced Event Search / LogScale üzerinde temel av sorgusu aşağıdaki gibi kurgulanabilir buna ek olarak hunting query olarak ekleyip içeride gerçekleştirilebilecek sürekli sorgularla görünürlüğün artması sağlanabilir:
Hunting Query ile tespit.
Test sonunda Falcon üzerinde vmtoolsd.exe parent process'i altında beklenmeyen child process'lerin loglandığı görülürse görünürlük doğrulanmış olur. Native detection oluşmaması, aktivitenin Falcon tarafından görülmediği anlamına gelmez. Benign komutlar çoğu zaman prevention veya detection eşiğine ulaşmayabilir. Bu nedenle kurum ortamına özel Custom IOA veya SIEM correlation rule ile davranışsal tespit geliştirilmesi gerekir.
Figure 3 - Falcon Process Tree / vmtoolsd.exe altında powershell.exe
CrowdStrike Custom IOA Önerisi
Bu senaryo için önerilen Custom IOA, Windows platformunda Process Creation tipiyle kurgulanmalıdır. İlk aşamada kuralın doğrudan prevention modunda değil, detect-only veya monitor mantığında pilot host grubunda test edilmesi önerilir. Son 7-30 günlük Event Search çıktıları üzerinden false positive analizi yapılmalı; backup sistemleri, VMware automation hesapları, VCF, SDDC Manager, Azure Guest Management veya benzeri meşru GuestOps kullanan servis hesapları tuning sürecinde ayrıca değerlendirilmelidir.
Önerilen başlangıç kuralı:
Parent Image Filename:
Image Filename:
Daha yüksek güvenli komut satırı paterni için aşağıdaki 2 regex kullanılabilir:
Bu patern, vmtoolsd.exe altında başlayan child process'lerde encoded command, download davranışı, riskli path kullanımı ve dosya silme gibi daha geniş şüpheli aktiviteleri yakalamak için kullanılabilir. Daha kapsamlıdır ancak false positive ihtimali ikinci kurala göre biraz daha yüksek olabilir.
Bu patern daha çok PowerShell kötüye kullanım davranışlarını hedefler. -enc, -nop, -noprofile, bypass, invoke-webrequest, iwr, downloadstring, iex, http/https gibi PowerShell tabanlı saldırı veya script execution senaryolarını yakalamak için daha uygundur.Bu yapı ile yalnızca vmtoolsd.exe altında başlayan script interpreter veya trusted binary aktiviteleri değil, aynı zamanda encoded command, download davranışı, Temp/AppData kullanımı ve dosya silme gibi daha riskli komut satırı örüntüleri de izlenebilir.
Sonuç
vmtoolsd.exe tek başına zararlı bir process değildir; VMware Tools'un meşru ve gerekli bir bileşenidir. Ancak Guest Operations üzerinden vmtoolsd.exe parent process'i altında powershell.exe, cmd.exe, mshta.exe, rundll32.exe veya benzeri process'lerin başlatılması, özellikle beklenmeyen kullanıcı hesabı, olağan dışı saat, dış bağlantı, dosya silme/değiştirme veya Temp/AppData path kullanımı ile birleştiğinde yüksek değerli bir detection sinyali üretir.
Bu nedenle CrowdStrike Falcon üzerinde yalnızca endpoint telemetry'ye bakmak yeterli değildir. En etkili yaklaşım, guest VM üzerindeki Falcon Sensor verileri ile vCenter/ESXi loglarının Falcon Next-Gen SIEM / LogScale tarafında korele edilmesidir. Böylece GuestOps kaynaklı komut yürütme davranışı hem endpoint hem de sanallaştırma katmanı perspektifinden uçtan uca görünür hale getirilebilir.
Burak ÖRT
MDR Ekip Lideri
Bu yazı, gerçek bir CrowdStrike Falcon ortamında yürütülen kontrollü test ve önerilen Custom IOA çıktılarına dayanmaktadır.
