Windows Server’da Şüpheli Aktivite Tespiti: Sysmon Kurulumu

yazar

Bir sabah işe geldiğinde event log’lara baktığında garip bir şeyler fark ediyorsun: gece yarısı bir PowerShell süreci çalışmış, arkasından bir network bağlantısı kurulmuş ve ardından iz kayboluyor. Windows’un yerleşik event log’ları sana sadece “bir şeyler oldu” diyor ama “ne oldu, nasıl oldu, kim yaptı” sorularına cevap veremiyor. İşte tam bu noktada Sysmon devreye giriyor.

Sysmon (System Monitor), Microsoft Sysinternals tarafından geliştirilen ve Windows üzerinde son derece ayrıntılı sistem aktivitesi kaydı tutan bir araç. Normal Windows event log’larının görmezden geldiği process yaratma, network bağlantıları, dosya değişiklikleri, registry işlemleri gibi onlarca olayı detaylıca kaydediyor. Ücretsiz, hafif ve production ortamlarında kullanıma uygun. Bu yazıda Sysmon’u sıfırdan kuracak, yapılandıracak ve gerçek dünya senaryolarında nasıl kullanacağını öğreneceksin.

Sysmon Neden Bu Kadar Önemli?

Windows’un varsayılan loglama kapasitesi güvenlik açısından yetersiz. Bir saldırgan sisteme girip zararlı bir PowerShell komutu çalıştırdığında, Windows’un kendi event log’ları sana sadece “PowerShell çalıştı” diyebilir. Kim çalıştırdı? Hangi parent process’ten türedi? Hangi IP adresine bağlandı? Bu soruların cevapları yok.

Sysmon şunları izliyor:

  • Process oluşturma ve sonlanma: Tam komut satırı argümanları, hash değerleri, parent process bilgisi
  • Network bağlantıları: Kaynak/hedef IP, port, process adı
  • Driver ve DLL yükleme: İmzasız driver’lar, şüpheli DLL’ler
  • Dosya oluşturma zamanı değişiklikleri: Timestomping tespiti
  • Registry işlemleri: Kritik registry key değişiklikleri
  • Pipe oluşturma: Lateral movement tespiti için
  • WMI aktivitesi: Fileless malware tespiti
  • DNS sorguları: Zararlı domain tespiti

Bir SOC analistinin ya da sysadmin’in “bu sunucuda ne oldu?” sorusunu yanıtlaması için Sysmon neredeyse vazgeçilmez hale geldi.

Sysmon İndirme ve Kurulum

İndirme

Sysmon’u resmi Microsoft Sysinternals sayfasından indiriyorsun. İndirme işlemini PowerShell üzerinden de yapabilirsin:

# PowerShell ile indirme
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "C:ToolsSysmon.zip"
Expand-Archive -Path "C:ToolsSysmon.zip" -DestinationPath "C:ToolsSysmon"

Zip içinde üç dosya gelecek: Sysmon.exe (32-bit), Sysmon64.exe (64-bit) ve Sysmon64a.exe (ARM64). Modern Windows Server ortamlarında neredeyse her zaman Sysmon64.exe kullanacaksın.

Temel Kurulum

En basit kurulum şu komutla yapılır:

# Basit kurulum - EULA otomatik kabul
cd C:ToolsSysmon
.Sysmon64.exe -accepteula -i

Ama bu şekilde kurarsan Sysmon neredeyse hiçbir şey loglamaz, çünkü bir konfigürasyon dosyası vermedin. Production’da her zaman bir config dosyasıyla kurulum yapman gerekiyor.

Konfigürasyon Dosyasıyla Kurulum

# Konfigürasyon dosyasıyla kurulum
.Sysmon64.exe -accepteula -i C:ToolsSysmonsysmonconfig.xml

# Servis durumunu kontrol et
Get-Service Sysmon64

# Yüklü versiyonu görmek için
.Sysmon64.exe -s

Kurulumdan sonra Sysmon bir Windows servisi olarak çalışır ve sistem başlangıcında otomatik olarak yüklenir. Event’ler Applications and Services Logs > Microsoft > Windows > Sysmon > Operational altında görünür.

Sysmon Konfigürasyon Dosyası Oluşturma

Konfigürasyon dosyası Sysmon’un kalbini oluşturuyor. Neyi loglayıp neyi loglamaması gerektiğini buradan belirliyorsun. Kötü bir konfigürasyon ya çok fazla gürültü üretir (event log’lar dolup taşar) ya da kritik olayları kaçırır.

Temel Konfigürasyon Yapısı

# Temel sysmonconfig.xml içeriği
# Bu dosyayı Not Defteri veya VS Code ile oluştur
<Sysmon schemaversion="4.90">
  <HashAlgorithms>md5,sha256,IMPHASH</HashAlgorithms>
  <CheckRevocation/>
  <EventFiltering>

    <!-- Process Oluşturma - Event ID 1 -->
    <RuleGroup name="" groupRelation="or">
      <ProcessCreate onmatch="exclude">
        <Image condition="is">C:WindowsSystem32conhost.exe</Image>
        <Image condition="is">C:WindowsSystem32wermgr.exe</Image>
      </ProcessCreate>
    </RuleGroup>

    <!-- Network Bağlantıları - Event ID 3 -->
    <RuleGroup name="" groupRelation="or">
      <NetworkConnect onmatch="include">
        <DestinationPort condition="is">4444</DestinationPort>
        <DestinationPort condition="is">8080</DestinationPort>
        <Image condition="contains">powershell</Image>
        <Image condition="contains">cmd.exe</Image>
      </NetworkConnect>
    </RuleGroup>

  </EventFiltering>
</Sysmon>

Üretim Ortamı İçin Hazır Konfigürasyon

Sıfırdan bir config yazmak ciddi zaman alır ve bilgi birikimi gerektirir. Bu yüzden topluluk tarafından geliştirilen SwiftOnSecurity konfigürasyonunu başlangıç noktası olarak kullanmanı şiddetle tavsiye ederim. GitHub’da açık kaynak olarak mevcut:

# SwiftOnSecurity config'ini indir
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile "C:ToolsSysmonsysmonconfig.xml"

# Konfigürasyonu uygula (Sysmon zaten kuruluysa güncelleme için -c kullan)
.Sysmon64.exe -c C:ToolsSysmonsysmonconfig.xml

Bu config, yıllar içinde topluluk tarafından test edilmiş ve gerçek saldırı senaryolarına göre optimize edilmiş durumda. Kendi ortamına göre üzerine ekleme yaparak kullanabilirsin.

Kritik Event ID’leri Anlamak

Sysmon’un ürettiği her event’in bir ID’si var. Hangisinin ne anlama geldiğini bilmek, alarm yorumlamak için kritik:

  • Event ID 1: Process Create – En önemli event. Çalışan her process hakkında detaylı bilgi
  • Event ID 3: Network Connection – Process bazlı network bağlantıları
  • Event ID 5: Process Terminate – Process sonlanması
  • Event ID 7: Image Loaded – DLL yükleme olayları
  • Event ID 8: CreateRemoteThread – Process injection tespiti için kritik
  • Event ID 10: ProcessAccess – Credential dumping tespiti
  • Event ID 11: FileCreate – Dosya oluşturma
  • Event ID 12/13: RegistryEvent – Registry değişiklikleri
  • Event ID 15: FileCreateStreamHash – Alternate Data Stream
  • Event ID 17/18: PipeEvent – Named pipe aktivitesi
  • Event ID 22: DNSEvent – DNS sorguları
  • Event ID 25: ProcessTampering – Process güvenlik açığı girişimleri

Gerçek Dünya Senaryoları ve Tespit

Senaryo 1: PowerShell Tabanlı Saldırı Tespiti

Bir ransomware vakasını düşün. Saldırgan sisteme giriyor ve PowerShell üzerinden encoded bir komut çalıştırıyor. Sysmon olmadan bunu tespit etmek neredeyse imkansız.

Sysmon Event ID 1 ile şunu yakalarsın:

# PowerShell encoded komut tespiti için PowerShell sorgusu
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | 
  Where-Object { $_.Id -eq 1 } | 
  Where-Object { $_.Message -like "*-enc*" -or $_.Message -like "*-encodedcommand*" } |
  Select-Object TimeCreated, Message | 
  Format-List

Bu sorgu sana encoded PowerShell komutlarını çalıştıran tüm süreçleri gösterir. Eğer bir muhasebe bilgisayarından gece yarısı powershell.exe -enc SQBuAHYAbwBrAGUA... gibi bir şey görürsen, bu kırmızı alarm.

Senaryo 2: LSASS Dump Tespiti (Mimikatz Tarzı)

Credential dumping, saldırıların en yaygın adımlarından biri. Mimikatz gibi araçlar LSASS process’ine erişerek parola hash’lerini çalıyor. Event ID 10 bunu yakalıyor:

# LSASS erişimi tespiti
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | 
  Where-Object { $_.Id -eq 10 } | 
  Where-Object { $_.Message -like "*lsass*" } |
  Select-Object TimeCreated, @{N='Details';E={$_.Message}} |
  Format-List

Konfigürasyon dosyanda LSASS erişimini özellikle izlemek için şu kuralı ekleyebilirsin:

<!-- Credential Dumping Tespiti -->
<RuleGroup name="LSASS Access" groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage condition="is">C:Windowssystem32lsass.exe</TargetImage>
  </ProcessAccess>
</RuleGroup>

Senaryo 3: Reverse Shell Tespiti

Saldırgan sistemde bir foothold kazandıktan sonra genellikle bir reverse shell açar. Bu, cmd.exe veya powershell.exe’nin beklenmedik bir IP’ye bağlanması demek:

# Komut yorumlayıcılardan gelen network bağlantıları
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | 
  Where-Object { $_.Id -eq 3 } | 
  ForEach-Object {
    $xml = [xml]$_.ToXml()
    $data = $xml.Event.EventData.Data
    $image = ($data | Where-Object { $_.Name -eq 'Image' }).'#text'
    $destIP = ($data | Where-Object { $_.Name -eq 'DestinationIp' }).'#text'
    $destPort = ($data | Where-Object { $_.Name -eq 'DestinationPort' }).'#text'
    if ($image -like "*cmd*" -or $image -like "*powershell*") {
      [PSCustomObject]@{
        Time = $_.TimeCreated
        Process = $image
        DestIP = $destIP
        DestPort = $destPort
      }
    }
  }

Sysmon Loglarını Merkezi Sisteme Gönderme

Sysmon’u tek başına kurmak yeterli değil. Logları merkezi bir SIEM sistemine göndermezsen, sunucu ele geçirildiğinde saldırgan logları silebilir. Bu yüzden Windows Event Forwarding (WEF) veya bir log agent kullanman gerekiyor.

Windows Event Forwarding ile

# Collector sunucuda WecUtil ile subscription oluşturma
wecutil cs subscription.xml

# Kaynak bilgisayarı WinRM ile yapılandırma
winrm quickconfig -q

# Sysmon loglarını forward etmek için subscription XML
# (subscription.xml dosyası içeriği)
<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
  <SubscriptionId>Sysmon-Logs</SubscriptionId>
  <SubscriptionType>SourceInitiated</SubscriptionType>
  <Description>Sysmon Logs Collection</Description>
  <Enabled>true</Enabled>
  <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
  <ConfigurationMode>MinLatency</ConfigurationMode>
  <Query>
    <![CDATA[
      <QueryList>
        <Query Id="0">
          <Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>
        </Query>
      </QueryList>
    ]]>
  </Query>
  <TransportName>HTTP</TransportName>
</Subscription>

Winlogbeat ile Elastic/Splunk’a Gönderme

Eğer Elastic Stack veya Splunk kullanıyorsan, Winlogbeat en pratik çözüm:

# winlogbeat.yml konfigürasyonu - ilgili kısım
winlogbeat.event_logs:
  - name: Microsoft-Windows-Sysmon/Operational
    event_id: 1, 3, 5, 7, 8, 10, 11, 12, 13, 15, 17, 18, 22, 25
    ignore_older: 72h

output.elasticsearch:
  hosts: ["https://elk-server:9200"]
  username: "sysmon_shipper"
  password: "gizli_sifre"
  ssl.certificate_authorities: ["C:/certs/ca.crt"]

Toplu Deployment: Group Policy ile Sysmon Dağıtımı

Onlarca veya yüzlerce sunucuya tek tek Sysmon kurmak yerine Group Policy kullanarak merkezi dağıtım yapabilirsin.

# GPO ile Sysmon dağıtımı için startup script
# Bu scripti SYSVOL'a koy ve GPO'ya ekle

$sysmonPath = "\domain.localSYSVOLdomain.localscriptsSysmon64.exe"
$configPath = "\domain.localSYSVOLdomain.localscriptssysmonconfig.xml"
$localPath = "C:WindowsSysmon64.exe"
$service = Get-Service -Name "Sysmon64" -ErrorAction SilentlyContinue

if (-not $service) {
    Copy-Item $sysmonPath $localPath -Force
    & $localPath -accepteula -i $configPath
    Write-EventLog -LogName Application -Source "SysmonDeploy" `
      -EventId 1000 -Message "Sysmon kurulumu tamamlandi"
} else {
    # Config guncelleme
    & $localPath -c $configPath
}

Sysmon Konfigürasyonunu Güncelleme ve Yönetme

# Mevcut konfigürasyonu görme
.Sysmon64.exe -s

# Konfigürasyonu güncelleme (servis yeniden başlatmaya gerek yok)
.Sysmon64.exe -c C:ToolsSysmonyeni-config.xml

# Sysmon'u kaldırma
.Sysmon64.exe -u force

# Servis durumu ve log boyutu kontrolü
Get-Service Sysmon64
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 1 | 
  Select-Object -ExpandProperty TimeCreated

# Log maksimum boyutunu artırma (varsayılan 64MB, production'da artır)
wevtutil sl "Microsoft-Windows-Sysmon/Operational" /ms:1073741824

Log boyutunu artırmak önemli. Varsayılan 64MB ile yoğun bir ortamda birkaç saatte log’lar dolup üzerine yazılmaya başlar. Production’da en az 1GB olarak ayarlamanı öneririm.

Performans Etkisi ve Optimizasyon

Sysmon’un sistem performansına etkisi, konfigürasyonuna bağlı olarak değişiyor. Yanlış yapılandırılmış bir Sysmon her şeyi loglarken CPU’yu ciddi oranda meşgul edebilir.

Dikkat etmen gereken noktalar:

  • Hash algoritmaları: MD5 + SHA256 + IMPHASH üçlüsü iyi bir denge. SHA512 eklersen CPU yükü artar
  • Exclusion kuralları: Windows Update, antivirus gibi bilinen gürültülü süreçleri exclude listesine al
  • Event ID 7 (DLL load): Bu event çok fazla log üretir, dikkatli kullan
  • Event ID 3 (Network): DNS ve NTP trafiğini exclude et
<!-- Gürültü azaltmak için tipik exclusion örnekleri -->
<ProcessCreate onmatch="exclude">
  <!-- Windows Defender -->
  <Image condition="begin with">C:ProgramDataMicrosoftWindows Defender</Image>
  <!-- WSUS/Windows Update -->
  <Image condition="is">C:WindowsSystem32wuauclt.exe</Image>
  <!-- Antivirus scan engine - kendi AV'ına göre ayarla -->
  <ParentImage condition="contains">MsMpEng</ParentImage>
</ProcessCreate>

<NetworkConnect onmatch="exclude">
  <!-- DNS trafiği -->
  <DestinationPort condition="is">53</DestinationPort>
  <!-- NTP -->
  <DestinationPort condition="is">123</DestinationPort>
  <!-- LDAP -->
  <Image condition="is">C:WindowsSystem32lsass.exe</Image>
</NetworkConnect>

Pratik Monitoring: Günlük Kontroller

Sysmon kurulumu bitti, peki artık ne yapacaksın? İşte günlük rutin kontroller için kullanabileceğin scriptler:

# Son 24 saatin şüpheli aktivite özeti
$baslangic = (Get-Date).AddHours(-24)

# Şüpheli parent-child ilişkileri
$supheli = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" |
  Where-Object { $_.Id -eq 1 -and $_.TimeCreated -gt $baslangic } |
  Where-Object { 
    $_.Message -like "*cmd.exe*" -and (
      $_.Message -like "*word*" -or 
      $_.Message -like "*excel*" -or 
      $_.Message -like "*outlook*"
    )
  }

if ($supheli) {
    Write-Warning "DIKKAT: Office uygulamasindan cmd.exe spawning tespit edildi!"
    $supheli | Select-Object TimeCreated, Message | Format-List
} else {
    Write-Host "Son 24 saatte Office->cmd spawning tespit edilmedi." -ForegroundColor Green
}

Bu kontrol, en yaygın macro-based malware senaryolarından birini yakalıyor: Word veya Excel üzerinden cmd.exe çalıştırılması. Kulağa basit geliyor ama bu senaryo hala çok yaygın ve başarılı.

Sigma Kuralları ile Entegrasyon

Sysmon loglarını Sigma kurallarıyla birleştirirsen gerçek anlamda güçlü bir detection mekanizması oluşturursun. Sigma, SIEM bağımsız detection kuralları yazmak için kullanılan açık kaynak bir format.

Örnek bir Sigma kuralı:

# sigma_lsass_access.yml
title: LSASS Memory Dump via Sysmon
status: stable
description: Detects LSASS memory dump attempts using common tools
logsource:
    product: windows
    service: sysmon
    definition: Use this rule with Sysmon EventID 10
detection:
    selection:
        EventID: 10
        TargetImage|endswith: 'lsass.exe'
        GrantedAccess|contains:
            - '0x1010'
            - '0x1038'
            - '0x40'
    condition: selection
falsepositives:
    - AV Products
    - EDR Solutions
level: high

Bu kuralı sigma-cli ile SIEM sorgusuna dönüştürebilirsin. Splunk, Elastic, Azure Sentinel hepsi destekleniyor.

Sonuç

Sysmon, Windows güvenliğini bir üst seviyeye taşıyan güçlü bir araç. Ama unutma, Sysmon tek başına bir güvenlik çözümü değil, görünürlük sağlayan bir temel. Kurulumu tamamladıktan sonra yapman gerekenler:

  • Logları merkezi bir sisteme gönder, lokal tutma
  • Konfigürasyonu ortamına göre özelleştir, hazır template’i olduğu gibi kullanma
  • Log boyutlarını production ihtiyacına göre ayarla
  • Düzenli olarak yeni Sysmon versiyonlarını takip et, şema güncellemeleri önemli
  • SwiftOnSecurity ve MSTIC gibi toplulukların config güncellemelerini takip et

İlk kurulumdan sonra belki bir hafta boyunca çok fazla alarm alacaksın. Bu normal. Gürültüyü azaltmak için exclude kurallarını geliştirmen zaman alacak. Ama bir süre sonra ortamın “normal” trafiğini öğrenirsin ve gerçek anormallikleri çok daha hızlı fark edersin.

Sysmon’u WDAC (Windows Defender Application Control), EDR çözümleri ve düzgün yapılandırılmış Windows audit policy ile birleştirdiğinde, saldırganlara karşı ciddi bir görünürlük katmanı oluşturmuş olursun. Ve bir sabah logları incelediğinde, “gece yarısı ne oldu?” sorusunun cevabını bulmak için saatler harcamak yerine, birkaç dakika içinde tam resmi görebilirsin. Bu fark paha biçilemez.

Yorum yapın