Siber güvenlik operasyonlarında (SOC/MDR) genellikle uç noktalara (endpoint) ve ağ trafiğine odaklanırız. Ancak son dönemde gerçekleştirdiğimiz kontrollü testler, sektörün önde gelen EDR/XDR çözümlerinin (varsayılan yapılandırmalarında) kör bir noktası olduğunu gösterdi: VMware vSphere Guest Operations API üzerinden yapılan kod yürütmeleri.
Bir tehdit aktörü vCenter/ESXi erişimi ve misafir işletim sistemi (Guest OS) kimlik bilgilerini ele geçirdiğinde, ağ üzerinden (RDP, WinRM, SMB) hiçbir iz bırakmadan, doğrudan hipervizör yönetim düzleminden komut çalıştırabilmektedir.
Bu makalede, bu mimari boşluğun Fortinet FortiEDR özelinde nasıl davrandığını, neden tespit edilemediğini ve bir MDR analisti gözüyle bu tehdidi nasıl avlayabileceğimizi (Threat Hunting) inceleyeceğiz.
FortiEDR'ın Davranışı: Neden Alarm Üretilmiyor?
FortiEDR, bilinen tehditleri engelleme ve davranışsal anomalileri yakalama konusunda oldukça güçlü bir kernel seviyesi mimariye sahiptir. Ancak bu spesifik senaryoda varsayılan ayarlarda sessiz kalmasının temel nedeni bir "ürün zafiyeti" değil, tasarımsal bir güven ilişkisidir.
Güvenilir Ebeveyn (Trusted Parent): Komut, misafir işletim sisteminde VMware tarafından dijital olarak imzalanmış meşru vmtoolsd.exe süreci tarafından başlatılır. FortiEDR'ın sınıflandırma motoru (Classification Engine), VMware imzalı bu süreci varsayılan olarak "Güvenilir (Trusted)" kabul eder.
Ağ Aktivitesi Yokluğu: Yürütme işlemi ağ üzerinden değil, doğrudan VMX/Hipervizör kanalı üzerinden gerçekleşir. FortiEDR'ın ağ tabanlı anomali kuralları tetiklenmez.
Post-Exploitation Beklentisi: FortiEDR, vmtoolsd.exe altından powershell.exe kalktığında bunu hemen zararlı olarak etiketlemez. Ancak o PowerShell, belleğe (LSASS) müdahale etmeye kalkar veya fidye yazılımı davranışı (dosya şifreleme) sergilerse o aşamada (Post-Exploitation) bloklar. Sorun şu ki; "Initial Access" ve "Execution" aşamasındaki bu gizli yürütmeyi kaçırmış oluruz.
FortiEDR Üzerinde Nasıl Tespit Edilir?
MDR ekipleri olarak sadece ürünün ürettiği alarmları bekleyemeyiz; proaktif tehdit avcılığı (Threat Hunting) şarttır. FortiEDR'ın "Threat Hunting" modülünü kullanarak bu davranışı yakalamak için aşağıdaki gibi sorgular (Query) oluşturulmalı ve bunlar Custom Rule (Özel Kural) haline getirilmelidir:
Örnek FortiEDR Threat Hunting Sorgusu:
Aksiyon ve Bulguların Analizi: Yukarıdaki görsellerde, oluşturduğumuz bu avcılık senaryosunun pratik yansımasını net bir şekilde görebilirsiniz. Arama sonucuna düşen olaylardan birinin süreç ağacına tıkladığımızda, atlatma tekniğinin (bypass) anatomisi tamamen ortaya çıkmaktadır. VMware'in meşru ve işletim sisteminde en yüksek ayrıcalık olan "Local System" haklarına sahip süreci olan vmtoolsd.exe'nin, uç noktanın geçici (Temp) dizinine powerclivmware43 adında şüpheli bir dosya bıraktığı (File Create) açıkça tespit edilmiştir.
Kuralların Sıkılaştırılması (Tuning) ve İstisnalar: Bu kuralı ortamınızda çalıştırdığınızda dikkat etmeniz gereken en önemli nokta, kurumun normalini (Baseline) belirlemektir. Eğer BT ekipleriniz vRealize gibi VMware otomasyon araçları üzerinden meşru PowerShell betikleri çalıştırıyorsa, bu sorgu ilk etapta onlara da çarpacaktır. Bir analistin buradaki görevi;
Süreç argümanlarında gizlenmiş (obfuscated) veya Base64 ile encode edilmiş şüpheli komutları ayrıştırmak,
Ortamdaki meşru IT otomasyon komut setlerini tespit edip kurala "İstisna (Exception)" olarak tanımlamak,
Kalan tüm beklenmedik vmtoolsd.exe alt süreç aktivitelerini potansiyel bir "Sistem İhlali" olarak değerlendirmektir.
Ürün Üreticisi (Fortinet) Bu Durumu Nasıl Yorumluyor?
Fortinet ve diğer EDR üreticileri, bu durumu bir "Zero-Day" veya açık olarak değerlendirmez. Üreticinin yaklaşımı şudur: "EDR, işletim sistemi sınırları içindeki süreçleri izler. Eğer yetkili bir hesap, meşru bir yönetim aracı (VMware Tools) kullanarak komut çalıştırıyorsa, bu IT operasyonudur. Yanlış pozitif (False-Positive) yorgunluğu yaratmamak için bu süreçleri varsayılan olarak engellemeyiz."
Fortinet, müşterilerine FortiEDR'ın "Playbook" ve "Custom Rule" özelliklerini kullanarak ortamın kendi normalini ("Baseline") belirlemelerini ve SIEM entegrasyonu ile görünürlüğü artırmalarını önermektedir.
Nelere Dikkat Etmeli? (Savunmayı Güçlendirmek)
Sadece FortiEDR'a güvenmek bu vektörde yeterli değildir. Siber güvenlikte "Defense in Depth" (Derinlemesine Savunma) ilkesi gereği şunlara dikkat edilmelidir:
SIEM Korelasyonu Şart: vCenter logları mutlaka SIEM'e (Örn: FortiSIEM veya Splunk) aktarılmalıdır. vSphere API — GuestProcessManager.StartProgramInGuest olayı (Event) SIEM üzerinde izlenmeli ve bu işlem yapıldığında anında SOC ekibine alarm düşmelidir.
vCenter/ESXi Sıkılaştırması (Hardening): Fidye yazılımı grupları doğrudan sanallaştırma altyapılarını hedef alıyor. vCenter arayüzlerine erişim kesinlikle MFA ile korunmalı ve sadece "Jump Server"lar üzerinden erişime izin verilmelidir.
Ayrıcalıklı Hesap Yönetimi (PAM): Misafir işletim sistemindeki yerel yönetici (Local Admin) parolaları LAPS gibi çözümlerle rotasyona tabi tutulmalıdır ki aktör, vCenter erişimi olsa bile kimlik doğrulamada takılsın.
Sonuç
Uç nokta güvenliği bir ürün değil, bir süreçtir. "Trusted Parent" istismarları, en pahalı güvenlik araçlarını bile atlatabilir. Infinitum IT gibi uzman kurumlarda yürüttüğümüz MDR süreçlerinde, ürünlerin varsayılan ayarlarıyla yetinmeyip, sürekli yeni saldırı tekniklerine karşı avcılık kuralları (Hunting Rules) yazmamızın temel sebebi tam olarak budur.
Asude Handan USLUKILIÇ — L1 MDR Analyst
InfinitumIT MDR — Detection Engineering & Threat Hunting
Bu yazı, kontrollü bir FortiEDR test ortamında gerçekleştirilen gözlemlere dayanmaktadır. Sunulan Threat Hunting sorgusu ve öneriler örnek niteliğindedir; ortam yapılandırmasına göre farklılık gösterebilir.
