Sysinternals Sysmon 6.10

Bu konumuzda Windows işletim sistemleri için geliştirilmiş, sistem kaynaklarını izleyen bir yazılım olan Sysmon ‘un 6.10 sürümünde gelen bir yenilik olan Permanent Event Tracking (Daimi Olay Takibi) konusunu ele alacağız.

WMI (Windows Management Instrumentation) daimi event logları (olay günlüğü) sysmon 6.10 sürümünde belirli eventleri loglamak için daimi event eylemlerine eklenmiştir.
Yeni Eventler:
Event ID 19: WmiEvent (WmiEventFilter etkinliği tespit edildiğinde)
Kötü amaçlı yazılımları çalıştırmak için kullanılan teknik olan WMI event filtresi kaydedildiğinde, WMI namespace ‘ini, filtre adını ve filtre ifadesini loglar.

Event ID 20: WmiEvent (WmiEventConsumer etkinliği tespit edildiğinde)
Bu event, WMI consumer kayıtlarını, ismini, loglar ve hedefi kaydeder.

Event ID 21: WmiEvent (WmiEventConsumerToFilter etkinliği tespit edildiğinde)
Bir consumer bir filtreye bağlandığında, bu event consumer adını ve filtre yolunu loglar.

Sysmon 6.10 sürümünde __EventFilter sınıfı, consumer sınıfları, __FilterToConsumerBinding sınıflarının oluşturulması ve silinmesi takip edilebilir.
Yakalanan eventlere göz atmak için WMI eventlerine giriş yapabilecek bir örnek config (yapılandırma) dosyası oluşturulmalıdır.
Örnek config dosyası:

<Sysmon schemaversion=”3.4”>
    <HasAlgorithms>SHA256</HasAlgorithms>
    <EventFiltering>
        <WmiEvent onmatch=’exclude’>
        </WmiEvent>
    </EventFiltering>
</Sysmon>

Bu dosyayı test.xml olarak kaydedip daha sonra sysmon -c .\\test.xml komutu ile yönetici bir konsolda (PowerShell ya da cmd) çalıştırırsak şu şekilde bir çıktı görürüz.

System Monitor v6.10 - System activity monitor
Copyright (C) 2014-2017 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

Current configuration:
- Service name:                  Sysmon
- Driver name:                   SysmonDrv
- HashingAlgorithms:             SHA256
- Network connection:            disabled
- Image loading:                 disabled
- CRL checking:                  disabled
- Process Access:               disabled

Rule configuration (version 3.40):
- WmiEvent                           onmatch: exclude
- WmiEvent                           onmatch: exclude
- WmiEvent                           onmatch: exclude

Service (hizmet) değişikliklerinin durumunu bir metin dosyasına kaydeden daimi bir event oluşturmak için Windows PowerShell ‘i kullanabiliriz.
Her 5 saniyede bir Win32_Service sınıfının değişip değişmediğini kontrol eden bir __EventFilter oluştururak başlayalım.

#event filter oluşturuyoruz.
$ServiceFilter = ([wmiclass]".rootsubscription:__EventFilter").CreateInstance()

# Özellikleri set ediyoruz.
$ServiceFilter.QueryLanguage = ’WQL’
$ServiceFilter.Query = "select * from __instanceModificationEvent within 5 where targetInstance isa ’win32_Service’"
$ServiceFilter.Name = "ServiceFilter"
$ServiceFilter.EventNamespace = ’rootcimv2’

# son dokunuşlar.
$FilterResult = $ServiceFilter.Put()
$ServiceFilterObj = $FilterResult.Path

Event oluşturulduğu zaman Event 19 ‘un oluşturulduğunu ve EventData altında Operation attribute (özniteliği) ‘ünün değerinin Created olduğunu görüyoruz.

Bazı APT gruplarının devlet aktörleri ile ilişkili olduğunu bildiğimden beri, daimi eventleri hedef ortamlara karıştırmak için değiştirmediği bilindiğinden mevcut filtre sorgusunu istenildiği gibi loglayıp loglamadığını görmek için PowerShell ekranında aşağıdaki gibi değiştirmeye karar verdim:

$ServiceFilter.Query = "select DisplayName from __instanceModificationEvent within 5 where targetInstance isa ’win32_Service’"
$FilterResult = $ServiceFilter.Put()

Event ID 19 olarak kaydedildi.
Operation kısmının şuan boş olduğunu görebiliriz ki bu da değişimi izlemek için 6.10 versiyonunda her hangi bir mantık olmadığı anlamına gelir. Fakat hala filtreleyebileceğimiz ve tetikleyebileceğimiz bir işlemi logluyor.
Microsoft geliştiricilerinden birini bu konuda bilgilendirdim ve bunu gelecek sürümde tüm log türleri için ele alacaklarını belirttiler.

Şimdi ise filtreyi oluşturduğumuz pencerede aşağıdaki PoweShell koları ile C:\\ sürücüsünde log oluşturacak consumer oluşturalım.

#yeni event consumer oluşturuyoruz
$LogConsumer = ([wmiclass]".rootsubscription:LogFileEventConsumer").CreateInstance()

# consumer özellikleri set ediyoruz
$LogConsumer.Name = ’ServiceConsumer’
$LogConsumer.Filename = "C:Log.log"
$LogConsumer.Text = ’A change has occurred on the service: %TargetInstance.DisplayName%’


#
$LogResult = $LogConsumer.Put()
$LogConsumerObj = $LogResult.Path

LogFileEventConsumer oluşturulmasının Event ID 20 ile loglandığını ve tüm özelliklerinin EventData Element yapısında loglandığını görebiliriz.

Daha önce oluşturduğumuz __EventFilter ve LogFileEventConsumer sınıf örneklerini kullanarak bir __FilterToConsumerBinding sınıf örneği oluşturalım.

#yeni event consumer oluşturuyoruz
$LogConsumer = ([wmiclass]".rootsubscription:LogFileEventConsumer").CreateInstance()

# consumer özellikleri set ediyoruz
$LogConsumer.Name = ’ServiceConsumer’
$LogConsumer.Filename = "C:Log.log"
$LogConsumer.Text = ’A change has occurred on the service: %TargetInstance.DisplayName%’


#
$LogResult = $LogConsumer.Put()
$LogConsumerObj = $LogResult.Path

Bu eylem Event ID 21 ile loglandı ve CIM veritabanındaki Filter ve Consumer yolları da EventData altına dahil edildi.

Sonuç olarak, Sysmon ‘da loglamanın Windows ‘un daha yeni sürümlerinde logladığımız gibi genişlediğini, daimi eventleri ve bunların bileşenlerini loglamada daha iyi tutarlılık ve içgörü sağladığını söyleyebilirim.
Geçici eventler, sağlayıcılar ve sorgu hatalarıyla bitmiyor tabii fakat güzel bir başlangıç.
WMI daimi eventlerle ilgili tüm eventlerin loglanmasını etkinleştirmeyi ve config dosyasında filtreleme uygulamamayı tavsiye ediyorum.