9- ESXI live triage collect

ESXi ortamlarında bir güvenlik olayına müdahale ederken zaman en kritik değişkendir. Bu noktada Live Triage Collection, kapsamlı bir adli incelemeye geçmeden önce sistemden hızlı, hedef odaklı ve minimum etkiyle kritik verilerin toplanmasını sağlayan ilk adımdır. Amaç; olayın kapsamını kısa sürede belirlemek, olası tehdit aktörünün izlerini kaybetmeden yakalamak ve daha derin analizler için güvenilir bir veri seti oluşturmaktır. Özellikle ESXi gibi çok sayıda sanal makineyi barındıran ortamlarda, yanlış veya gecikmiş bir müdahale ciddi veri kaybına ve operasyonel kesintilere yol açabileceğinden, triage süreci hem teknik doğruluk hem de hız açısından son derece hassas bir denge gerektirir. ESXi özel bir çekirdektir. Linux çekirdekleri için tasarlanmış IR araçları burada başarısız olacaktır.

Amaç

Minimum sürede maksimum kritik veri
Incident scope belirleme

Live Response Yaparken Toplanması Gerekenler

Tüm /var/log/ dizini
/etc/ altındaki config dosyaları
Running process listesi
Network state
VM inventory bilgileri

Forensics Artifack başlığında anlattığım path lere giderek artifackleri manuel bir şekilde toplayabiliriz fakat bu uzun zaman ve çok zahmetli bir iş bunu otomatize etmek için github’ta farklı farklı scripler hazırda mevcut bu scripleri alarak ESXI sistemlerinde çalışıtırıp artifackleri toplayabiliriz.

Benim sıkça kullandığım ve olay müdahalesi esnasında kullandığım tool listesi şu şekilde;

ESXtract (https://github.com/mikecybersec/ESXtract)
ESXiTri (https://github.com/DCScoder/ESXiTri)
Quick ESXI Log Parser (QELP) (https://github.com/strozfriedberg/qelp)
ESXIe0x (https://github.com/corvus0x/ESXIe0x)

Bu toolar haricinde toollar olabilir fakat ve kullanıp test etmediğim araçları önermiyorum 🙂 sizin beğendiğiniz kullandığını araçlar varsa benim paylaşabilirsiniz.

Blog yazısı çok uzamaması için bir script ile nasıl triage verisi toplanır göstereceğim diğer scriplerde benzer şekilde çalışmaktadır.

ESXiTri

ESXiTri, özellikle olay müdahale (incident response) ve ilk analiz (triage) süreçlerini kolaylaştırmak amacıyla geliştirilmiş hafif bir araçtır. Sistem üzerinde minimum etki bırakarak çalışması sayesinde canlı sistemlerde güvenli bir şekilde kullanılabilir. Araç, ESXi host üzerinde çalışan sanal makineler, aktif süreçler, ağ bağlantıları ve sistem konfigürasyonları gibi kritik bilgileri hızlıca toplayarak analiz edilebilir bir çıktı sunar.

Kullanımı

Aracı GitHub üzerinden indirin:
https://github.com/DCScoder/ESXiTri
Aracı çalıştırılabilir hale getirin:
chmod +x esxitri.sh

Script’i çalıştırın:
./ESXiTri.sh

Araç, sistemden topladığı verileri bir çıktı klasörü veya log dosyası olarak sunacaktır.

QELP ile Analiz

ESXi sunucularını analiz ederken, ESXi sunucularına erişmek için kullanılan kaynak sistemlerin ve tehdit aktörlerinin ESXi’de gerçekleştirdiği faaliyetlerin hızlı bir şekilde belirlenmesi çok önemlidir. Ancak, birden fazla ESXi sunucusundan gelen çok sayıda log dosyasını işlerken bu zaman alıcı olabilir. Ayrıca, ESXi log dosyaları genellikle tehdit aktörleri tarafından kısmen şifrelenir, bu da veri kaybına yol açar, ancak yine de olayla ilgili şifrelenmemiş bilgiler içerebilir. En alakalı bilgileri içeren ESXi log dosyalarını manuel olarak belirlemek ve olayların zaman çizelgesini oluşturmak değerli analiz zamanına mal olabilir.

Bu zorlukların üstesinden gelmek için Stroz Friedberg, ESXi log işleme ve zaman çizelgesi oluşturmayı otomatikleştirmek üzere QELP adlı açık kaynaklı bir Python betiği geliştirmiştir

QELP’nin yetenekleri şunlardır:

Birden fazla ESXi sunucusundan gelen ESXi loglerini zamanında ve verimli bir şekilde ayrıştırmak.
Kısmen şifrelenmiş ESXi loglerinin ayrıştırılması.
Kolay erişim ve analiz için CSV raporlarına çıktı alınır.
ESXi sunucusunda meydana gelen olayların genel bir resmini oluşturmak için en alakalı olayların zaman çizelgesinin oluşturulması.

QELP, ESXi desteği içeren bir giriş dizini veya yalnızca zip, tar, gz veya tgz uzantılarına sahip log arşivleri ve sonuçları depolamak için bir çıkış dizini gerektirir.

https://github.com/strozfriedberg/qelp aracını kullanarak analiz sağlanabilir.

QELP, ilgili ESXi loglarında elde edilen sonuçları içeren CSV dosyalarının yanı sıra, olay müdahalesi açısından önemli olan olayları içeren bir zaman çizelgesi CSV dosyası da üretir.

10- ESXi Triage Analysis

Bir güvenlik olayına müdahalede veri toplamak tek başına yeterli değildir; asıl değer, toplanan verinin doğru ve hızlı şekilde anlamlandırılmasında ortaya çıkar. ESXi Triage Analysis aşaması, live triage sırasında elde edilen loglar, konfigürasyon dosyaları ve sistem çıktılarının korele edilerek saldırının izlerinin ortaya çıkarıldığı kritik bir analiz sürecidir. Bu aşamada amaç; saldırganın sisteme nasıl eriştiğini, hangi adımları izlediğini ve hangi varlıkların etkilendiğini kısa sürede belirleyerek olayın kapsamını netleştirmektir. Özellikle zaman baskısının yüksek olduğu incident response senaryolarında, doğru bir triage analizi hem müdahale stratejisinin şekillendirilmesini sağlar hem de daha derin forensic incelemeler için sağlam bir temel oluşturur.

Analiz Hedefleri

Initial access nasıl sağlandı?
Persistence var mı?
Hangi VM’ler etkilendi?
Data exfiltration var mı?

Analiz Teknikleri

Log Correlation

auth.log + hostd.log
- Kim, ne zaman login oldu?
shell.log
- Hangi komutlar çalıştırıldı?

Timeline Oluşturma

Log timestamp normalize edilerek
Attack chain çıkarılır

Anomali Tespiti

Normalde olmayan:
- SSH enable
- Yeni user
- Gece saatlerinde activity

VM Impact Analysis

Hangi VM’ler shutdown oldu?
.vmdk erişim patternleri

Timeline Oluşturma: shell.log, auth.log ve hostd.log dosyalarını birleştirerek saldırganın hangi saatte girdiğini, hangi VM’leri hedeflediğini ve hangi komutları çalıştırdığını kronolojik olarak dizmek.
Lateral Movement Tespiti: Saldırganın ESXi üzerinden diğer VM’lere geçip geçmediğini veya vCenter’a doğru bir hareket olup olmadığını belirlemek.
Persistence (Kalıcılık) Kontrolü: /etc/rc.local.d/ gibi başlangıç scriptlerine veya crontab kayıtlarına eklenmiş zararlıların analizi.
Indicator of Compromise (IOC) Tarama: Bilinen ransomware uzantıları, şifreleme araçları (encrypt, ra.exe vb.) veya spesifik stringlerin loglar içinde aranması.

Güvenlik İhlali yaşayan ESXi sisteminiz varsa Yapmamanız gerekenler;

Sanal makineleri hemen yeniden başlatmayın veya kapatmayın; ransomware şifreli dosyaları değiştiremez ve bir sanal makine hala açıksa kilitli kabul edilir.
zararlı prosesler, dosyalar, kalıcılıklar tanımlanıp giderilene kadar, bilinen şekilde tehlikeye girmiş ESXi cluster veya sistemlerinin sanal makinelerini geri yüklemeyin.
Enfekte olan sistemleri ağdan ayırın
Sunucu enfekte olmuş ağ segmentinden ayrılana kadar SSH/ESXi Shell erişimini devre dışı bırakın.
Etkilenen ESXi cluster Mantıksal Birim Numarasını (LUN)/Veri Deposunu (VMDK’ların depolandığı yer) ayırın.

ESXI Sistemi THOR İle Tarama

THOR, olay müdahale (Incident Response) ve tehdit avcılığı (Threat Hunting) süreçlerinde kullanılan, imza ve davranış tabanlı analiz yapabilen gelişmiş bir tarama aracıdır.

Öne çıkan özellikleri:

IOC (Indicator of Compromise) taraması
YARA kuralları ile dosya analizi
Rootkit ve anomali tespiti
Linux ve ESXi desteği

ESXi, standart bir Linux dağıtımı olmadığı için ajan kurulumu veya klasik tarama yöntemleri her zaman mümkün olmayabilir. Bu nedenle tarama süreci genellikle offline veya dolaylı yöntemlerle gerçekleştirilir.

THOR taraması güvenli ve önerilen yöntemlerden biri, ESXi datastore’un başka bir Linux sisteme mount edilerek taranmasıdır.

THOR ile ESXI sistemi tarayabilmek için;

1- ESXI sisteminin SSH bağlantısının açık olması gerekir. Bu sayede sisteme erişim sağlanabilir.

2- Bir linux distrosu üzerinde “sshfs” kurulu olması gerekir. (https://github.com/libfuse/sshfs) sshfs, SSH protokolünü kullanarak uzak bir sistemdeki dosya sistemini yerel makineye mount etmeye yarayan bir araçtır. Bu sayede uzak sunucudaki dosyalara, sanki yerel diskteymiş gibi erişebilir ve işlem yapabilirsin.

3- mount edilecek dizin oluşturulur ve ESXI sistemi mount edilmeye çalışırlır

sudo mkdir -p /mnt/esx

sudo sshfs -o reconnect root@esx1.company:/ /mnt/esx

Öncelikle yeni bir klasör oluşturuyoruz ve uzak dosya sistemini bu yerel klasöre bağlıyoruz:

4- THOR uzak sistemin daha yoğun bir şekilde taranması için farklı bir bayrak kombinasyonu kullanırız. Laboratuvar lisansına sahip tam sürüm, bu –lab bayrağı kullanmamıza olanak tanır.

sudo ./thor-linux-64 –lab -p /mnt/esx –virtual-map /mnt/esx:/ -j esx1

11- ESXI Sistemler İçin Öneriler

VMware Tools Oturum Açma İşlemi Sanal Makine Konuk Oturumunda

bu varsayılan olarak etkinleştirilmemiş özel bir VMware tools logudur. etkinleştirilmesi olaydır ancak çok fazla log ürettiğinde disk alanında aşırı kaynak kullanabilir bunu bir SIEM platformuna göndermek en uygun yaklaşımdır.

Bu log dosyasını etkinleştirmek için “C:\ProgramData\VMware\VMware Tools” yolunda bulununa Tools.conf dosyasını yapılandırmasını şu şekilde yapmalaıyız;

vmsvc.level parametresini “Debug” olarak ayarladığımızıda logların ayrıntılı bir şekilde göreceğiz

VIX API’sinde doğrudan gerçekleştirilen aksiyonları temsil eden “OpCode” lar üretmektedir.

sık kullanılan OpCode’lar;

OpCode	Vix Command	Guest Operation Equivalent
177	VIX_COMMAND_LIST_FILES	ListFilesInGuest
185	VIX_COMMAND_START_PROGRAM	StartProgramInGuest
186	VIX_COMMAND_LIST_PROCESSES_EX	ListProcessesInGuest
188	VIX_COMMAND_INITIATE_FILE_TRANSFER_FROM_GUEST	InitiateFileTransferFromGuest
189	VIX_COMMAND_INITIATE_FILE_TRANSFER_TO_GUEST	InitiateFileTransferToGuest

ESXİ Sistemleri Üzerinden En sık Karşılaşılan hatalar;

Kimlik doğrulama için domain alanına katılma yönetim arayüz sağlanması. Bu durum, saldırganların yalnızca ağ üzerinde yatay olarak hareket ederek ESXi yönetim arayüzlerine ulaşabilmelerine değil, aynı zamanda AD’ye saldırarak ESXi’ye kimlik doğrulamalı ve ayrıcalıklı erişim elde etmelerine de olanak tanır.
Yönetim arayüzlerini geliştirme, üretim vb. ortamlardan ayrı, özel bir VLAN ağı üzerine ayırmamak, saldırganların yatay olarak hareket etmelerine ve mevcut ek yapılandırma hatalarını, zayıflıkları ve güvenlik açıklarını istismar etmelerine olanak tanır.
SLP kullanılmıyorsa kapatılmalı. (https://knowledge.broadcom.com/external/article?legacyId=76372)
ESXi’yi internete açmak
ESXi yönetim arayüzlerine erişimi, statik IP adreslerine sahip özel cihazlardan (örneğin yönetici cihazlarından) kısıtlamamak.
ESXi kimlik doğrulaması için yalnızca güvenli bir parola kasasında saklanan son derece güçlü bir parola kullanılmaması yedeklemelerin olmaması

Sanal Sistem için öneriler

ESXI ve vCenter sunucularında SSH ve shell erişimini devre dışı bırakın
ESXİ ve vCenter sunucularında yerel firewall kullanarak VMware sunucularına erişimi belirli bir ip adresiyle sınırlandırın
VMware sunucularında internet erişimini devre dışı bırakın
VMware altyapısına yönetimsel erişimini devre dışı bırakın
VMware altyapısını yönetmek için güvenli atlama sunucuları kullanın
vCenter için mfa aktif hale getir
Vmware altyapısıyla ilişkili hesaplar için güçlü parolaların kullanılmasını zorunlu kılın.
oluşan logları SIEM çözümü aracılığıyla toplayın
VIX API sinin kullanımını yalnızca belirlenmiş kullanıcı hesaplarıyla sınırlandırın.
komut geçmişininde zaman damgalarını etkinleştirin.
veri kurtmayı sağlamak için backup çözümlerini uygulayın ve test edin
ESXi sunucularına / vCenter Server Appliance’larına erişimi izole edin ve kısıtlayın.
Sanal makinelerin yedeklerinin mümkünse izole edilmiş, güvenli ve değiştirilemez olduğundan emin olun.
Sanallaştırma platformlarına yönetimsel erişim için kimlik doğrulamasını merkezi kimlik sağlayıcısından (IdP) ayırın. Bu, bireysel ESXi sunucularını ve vCenter Sunucularını içerir.
Sanallaştırma platformlarıyla ilişkili ayrıcalıklı kimlikler için yerel root / yönetimsel parolaları proaktif olarak değiştirin.
Mümkünse, sanallaştırma altyapısına tüm yönetimsel erişim için daha güçlü MFA kullanın ve yerel SSO’ya bağlayın.
Toplu havuzun parçası olan her sanallaştırılmış sunucuyla ilişkili yerel root / yönetimsel kimlikler için rastgele parolalar uygulayın. Denetlenen ve izlenen ayrı bir parola/gizli kasada saklayın.
Sanallaştırma platformlarına SSH (shell) erişimini devre dışı bırakın / kısıtlayın.
Tüm ESXi sunucularında kilitlenme modunu etkinleştirin.
Sanallaştırma platformlarıyla ilişkili olası kötü amaçlı/şüpheli kimlik doğrulama girişimlerini ve etkinliklerini belirlemek için izlemeyi geliştirin.
SLP’yi devre dışı bırakın.

Kaynak:

Muhammed AYGÜN

ESXI Forensics Part-3

9- ESXI live triage collect

10- ESXi Triage Analysis

Analiz Hedefleri

Analiz Teknikleri

Log Correlation

Timeline Oluşturma

Anomali Tespiti

VM Impact Analysis

11- ESXI Sistemler İçin Öneriler

Related Posts

ESXI Forensics Part-2

ESXI Forensics Part-1

DFIR All Post

Bir yanıt yazın Yanıtı iptal et