İmzalı ve güvenilir process'ler EDR'ların davranışsal tespitini nasıl atlatabiliyor? VMware Tools'un vmtoolsd bileşeni üzerinden Guest Operations kötüye kullanımının Palo Alto Cortex XDR ile analizi, test çıktıları ve bu senaryoyu hem tespit eden hem de engelleyen özel kural yapılandırması.
EDR çözümleri, davranışsal analiz odaklı yapıları sayesinde son dönemde endpoint güvenliğinde antivirüs çözümlerinin önüne geçmiştir. Modern bir EDR yalnızca bilinen zararlıları signature tabanlı yöntemlerle yakalamakla kalmaz oluşan process'leri, sistemde meydana gelen davranışları, dosya sistemi aktivitelerini ve kullanıcı davranışlarını bir bütün olarak toplayarak analiz eder ve bu çok katmanlı detection yetenekleri ile tehditlere karşı önlem alır.
Ancak signature tabanlı ve reputation tabanlı yöntemler, güvenilir process'lerin kötüye kullanımı ile atlatılabilinmektedir. Özellikle dijital imzaya sahip ve bilinen process'ler tehdit aktörleri sıklıkla hedefi olmaktadır. Bu senaryo çoğunlukla Windows sistem dosyalarının kötüye kullanımlarında görülse de, VMware Tools gibi kurumsal ortamlarda yaygın kullanılan yazılımlarda da karşımıza çıkmaktadır. Bu makalede vmtoolsd process'inin kötüye kullanım senaryosunu ve bu senaryonun Palo Alto Cortex XDR üzerinde hangi izleri bıraktığı, nasıl tespit edilebileceği ve nasıl engellenebileceği InfinitumIT test ortamlarında bir case study üzerinden incelenmiştir.
VMware Tools Case Study
“vmtoolsd”, Guest Operations kapsamında çalışan ve VMware Tools'un temel bileşeni olan imzalı ve meşru kullanımda olan güvenilir bir process'tir. Guest OS tarafında başlatılan işlemler, ağ üzerinden gelen bir uzaktan erişim yerine hipervizör ile VMware Tools arasında kalan vmtoolsd üzerinden geçer. Bu işlemlerde PsExec, RDP, WinRM veya SMB gibi protokoller kullanılmaz. vmtoolsd üzerinden başlatılan işlemler, bu protokollerin kullanılmaması ve aktivitenin yalnızca endpoint telemetrisiyle sınırlı kalması sebebiyle EDR'ların kör noktası hâline gelebilmektedir.
EDR platformları bu aktiviteleri neden kaçırır?
EDR, imzalı ve güvenilir process'leri otomatik olarak düşük riskli kabul edebilir.
EDR, VM içerisindeki aktiviteleri başka endpoint cihazlar üzerindeki etkileriyle gerekli korelasyonu kuramayabilir.
EDR, VM içindeki bu aktivitelerde SMB, WinRM, RDP, PsExec gibi protokoller kullanılmadığı için geleneksel saldırı topolojileriyle eşleştiremeyebilir.
Modern EDR platformlarının tespit yaklaşımı nasıl olmalı?
EDR, imzalı process'lere peşinen düşük risk gözüyle bakmamalı, davranışsal analizler yapmalıdır.
Parent-child process'ler arasındaki ilişkiler daha detaylı analiz edilmeli, olağan dışı faaliyetlere şüpheci yaklaşılmalıdır.
Yalnızca çalışan process'ler değil, her process altında çalıştırılan komutlar da detaylı incelenmelidir.
Cortex XDR Perspektifinden Trusted Process Abuse Tespiti
Cortex XDR bir process olayını değerlendirirken yalnızca işletim sisteminin bildirdiği doğrudan parent'ı değil, zincirin kökenini de belirler. Cortex bu kök process'e Causality Group Owner (CGO) adını verir yani bir aktivitenin nedensellik zincirinin sahibi olan asıl process'tir. vmtoolsd üzerinden başlatılan bir cmd veya PowerShell aktivitesinde bu zincirin CGO'su vmtoolsd.exe olur.
Sorunun ana nedeni tam da buradadır. vmtoolsd.exe VMware tarafından imzalı, meşru ve güvenilir bir binary olduğu için, Cortex XDR dahil pek çok EDR bu güvenilir parent'a bağlı olarak çalışan child process'leri, örneğin cmd.exe, powershell.exe veya diğer LOLBin process'leri, varsayılan davranışsal analizde şüpheli olarak görmeyebilir ve alarm üretmeyebilir. Kısacası güvenilir ve imzalı parent, altında doğan ve zararlı olabilecek child process zincirini gölgeleyerek görünmez kılabilir. Oysa VMware Tools'un normal işleyişinde vmtoolsd'nin altında bir powershell veya cmd gibi script interpreter'ın doğması olağan bir davranış değildir.
Bu noktada detection mantığımız, EDR'ın güvenini tersine çevirmek üzerine kuruludur. CGO'su vmtoolsd.exe olan ve altında bir script interpreter veya LOLBin (PowerShell, CMD, WScript, CScript, MSHTA) olarak doğan her aktiviteyi tespit etmek üzerine kurgulanmıştır. Bu aktiviteleri ortaya çıkarmak amacıyla Cortex XDR Query Builder üzerinde aşağıdaki XQL sorgusu çalıştırılmıştır:
Bu sorgu ile CGO'su vmtoolsd.exe olan ve komut satırında ya da process adında PowerShell, CMD veya Windows Script Host bileşenlerini içeren process'leri filtrelemek amaçlanmıştır. Kontrollü test kapsamında Guest OS üzerinde vmtoolsd.exe parent'ı ile beklenmeyen bir process (cmd/powershell) oluşturulmuş ve olağan dışı bir komut çalıştırılmıştır. Sorgunun çıktısı aşağıda yer almaktadır.
Şekil 1. Cortex XDR Query Builder: CGO'su vmtoolsd.exe olan ve altında script interpreter doğan aktiviteyi ortaya çıkaran XQL sorgusu ve tek sonuçlu çıktı. Telemetri mevcut olmasına rağmen varsayılan yapılandırmada alarm üretilmemiştir.
Çıktıda görüldüğü gibi imzalı ve güvenilir kabul edilen bir parent process (vmtoolsd.exe), altında bir cmd.exe child process başlatmış ve komut satırında obfuscate edilmiş bir PowerShell komutu çalıştırmıştır:
-EncodedCommand parametresi, Base64 ile kodlanmış bir PowerShell komutunu ifade eder ve klasik bir gizleme (obfuscation) ve savunma atlatma göstergesidir. Buradaki kritik bulgu şudur: imzalı ve güvenilir bir parent, olağan dışı child process'ler ve bu child process'lerde çalıştırılan komutlar Cortex XDR tarafından eksiksiz loglanmış olmasına rağmen, bu aktiviteler varsayılan yapılandırmada bir anomali olarak görülmemiş ve alarm olarak tetiklenmemiştir. Yani telemetri mevcuttur ancak güvenilir ve meşru olan parent process nedeniyle davranışsal tespit devreye girmemektedir.
Engelleme Adımları | XQL Sorgusundan BIOC Kuralı Oluşturma
Cortex XDR'da yazdığımız bir XQL sorgusu, doğrudan bir BIOC (Behavioral Indicator of Compromise) kuralına dönüştürülebilir. Query Builder üzerinde sorgu geçerli bir BIOC yapısına sahipse arayüzde "Valid BIOC" ibaresi belirir. Save as menüsünden BIOC Rule seçilerek sorgu kalıcı bir davranışsal tespit kuralına çevrilir.
Şekil 2. XQL sorgusundan BIOC oluşturma: 'Valid BIOC' doğrulaması ve Save as -> BIOC Rule.
Bu adımdaki query çıktısı, tespitin dayanağını da doğrular niteliktedir: parent process'in yolu C:\Program Files\VMware\VMware Tools\vmtoolsd.exe, imzalayan üretici ise VMware, Inc. olarak görünmektedir. Yani parent gerçekten beklenen dizinde ve gerçek üretici imzasıyla çalışmaktadır. Tehdit aktörünün faydalanabildiği güven de tam olarak bu duruma dayanmaktadır. Buna rağmen ilgili parent process altında bir script interpreter'ın doğması anomalidir ve kuralımızın yakaladığı davranış budur.
Kuralı kaydederken bir ad, tür, MITRE ATT&CK tekniği ve severity atanır. Bu testte kural "VMTools GuestOps - Script Interpreter Spawn" adıyla, Execution türünde ve High severity ile oluşturulmuştur.
Oluşturulan kural Detection Rules / BIOC altında listelenir ve artık vmtoolsd.exe altında bir script interpreter process'i oluştuğunda BIOC kuralımız sayesinde alarm tetiklenecektir.
Şekil 3. Detection Rules -> BIOC: oluşturulan “VMTools GuestOps - Script Interpreter Spawn” kuralı (Execution, High, Enabled) ve sağ tık menüsündeki 'Add to restrictions profile' seçeneği.
Bu kural, vmtoolsd.exe parent process'i ile başlatılan ve child process'lerinde PowerShell, CMD veya benzeri interpreter'lar bulunan aktiviteleri tespit ederek alarm üretmek için oluşturulmuştur. Böylece vmtoolsd, normal kullanıcı davranışının dışında, özellikle gizli komut çalıştırma senaryolarında kullanıldığında Cortex XDR erken aşamada görünürlük sağlayacaktır. Yukarıdaki ekran görüntüsünde de görülen sağ tık menüsündeki "Add to restrictions profile" seçeneği ise bu kuralı yalnızca tespitle sınırlı tutmayıp engellemeye dönüştürmek için kullanılır.
Engelleme Adımları | Restriction (Custom Prevention Rule) Profili
Cortex XDR'da bir BIOC kuralı varsayılan olarak yalnızca alarm üretir. Aynı kuralın ilgili davranışı gerçek zamanlı olarak engellemesi için, kuralın bir Restrictions (Prevention) profili içindeki Custom Prevention Rules bölümüne eklenmesi gerekir. Bu profil bir prevention policy'e atandığında, kapsamdaki endpoint'lerde kuralın tanımladığı davranış bloklanır. Aşağıda bu yapılandırmanın adımları yer almaktadır.
Adım 1 Prevention profili oluşturma
Endpoints / Policy Management / Prevention / Profiles yolu izlenir ve Add Profile düğmesine tıklanarak yeni bir profil oluşturulur.
Şekil 4. Endpoints -> Policy Management -> Prevention -> Profiles ekranı ve “Add Profile' ile yeni prevention profili oluşturma.
Adım 2 Platform ve profil tipinin seçilmesi
Açılan ekranda platform olarak Windows, profil tipi olarak da Restrictions seçilir. Diğer profil tipleri Malware, Exploit, Agent Settings ve Exceptions'tır; ancak BIOC tabanlı özel engelleme kuralları yalnızca Restrictions profilinde yer alır.
Şekil 5. Yeni profilde platform olarak Windows ve profil tipi olarak Restrictions seçimi.
Adım 3 Custom Prevention Rules bölümü
Restrictions profilinin sol menüsündeki Custom Prevention Rules sekmesine geçilir. Açıklamasında da belirtildiği gibi bu bölüm, kullanıcı tanımlı BIOC engelleme kuralları için ayrılmıştır. Action Mode değeri Enabled yapılır. Ayrıca "Auto-disable rules that trigger more than 100 times in 30 minutes" seçeneği, hatalı bir kuralın tüm endpointleri etkilemesini önleyen bir güvenlik önlemi olarak devrede tutulabilir.
Şekil 6. Restrictions profili içindeki 'Custom Prevention Rules' bölümü: BIOC tabanlı, kullanıcı tanımlı engelleme kuralları; Action Mode Enabled ve auto-disable güvenlik supabı.
Adım 4 BIOC kuralının profile eklenmesi
Son olarak, oluşturduğumuz BIOC kuralı engelleme kapsamına alınır. Detection Rules / BIOC altında ilgili kural seçilir, sağ tık menüsünden Add to restrictions profile seçeneğine tıklanır. Açılan pencerede kuralın uyumlu olduğu platform profilleri listelenir bu testte kural, Windows profillerinden TB TEST profiline eklenmiştir. Bu Restrictions profili bir prevention policy'e atandığında kural artık yalnızca görünürlük değil, gerçek zamanlı engelleme sağlar.
Şekil 7. 'Add to Restrictions Profile' penceresi: BIOC kuralının Windows profillerinden 'TB TEST' profiline eklenmesi.
VMware Tools Vakasının Önerileri
vCenter ve ESXi yönetim erişimleri çok faktörlü kimlik doğrulama (MFA) ile korunmalı, mümkün olduğunca out-of-band management üzerinden sağlanmalı ve yönetici hesapları PAM çözümleriyle izlenerek oturum kayıtları tutulmalıdır.
Guest Operations ayrıcalığı yalnızca gerçekten ihtiyaç duyan kullanıcı ve servis hesaplarına tanımlanmalı, kullanımı düzenli denetlenmeli ve olağan dışı kullanımlar için uyarı mekanizmaları kurulmalıdır.
Guest OS üzerinde PowerShell Constrained Language Mode, AppLocker veya WDAC gibi uygulama kontrol mekanizmaları etkinleştirilerek PowerShell ve benzeri interpreter'ların kontrolsüz çalışması sınırlandırılmalı, PowerShell aktivitelerinin görünürlüğü artırılmalıdır.
Cortex XDR tarafında vmtoolsd.exe altında başlatılan process'lere ilişkin mevcut exception'lar tekrar gözden geçirilmeli bu testte ele alınan CGO tabanlı BIOC kuralı devreye alınmalı ve bir Restrictions profiliyle engellemeye bağlanmalıdır.
Özellikle bu vakadaki parent-child ilişkisine yönelik davranışsal tespit kuralları tanımlanmalı ve düzenli threat hunting faaliyetleriyle kontroller sürdürülmelidir.
Bu yazı, gerçek bir Cortex XDR ortamında yürütülen kontrollü test sonuçlarına dayanmaktadır. Sunulan XQL sorguları ile BIOC ve Restriction yapılandırmaları örnek niteliğindedir.
Sorumluluk Reddi: Bu doküman yalnızca bilgilendirme ve savunma amaçlıdır. Sunulan sorgular ve yapılandırmalar örnek niteliğindedir; ürün sürümü, sensör politikası ve ortam yapılandırmasına göre farklılık gösterebilir ve devreye alınmadan önce kontrollü ortamda doğrulanmalıdır. İçerik herhangi bir saldırı prosedürü veya istismar kodu barındırmaz.
Hakan AKSUNGUR — L2 MDR Analyst
InfinitumIT MDR — Detection Engineering & Threat Hunting
