Windows Sistemde Şüpheli Süreç Tespiti

Yazar:komut.io ekibi
0 Yorum

Bir gün ofise geliyorsunuz, kahvenizi alıyorsunuz ve mailbox’ınızda SIEM’den gelen bir uyarı görüyorsunuz: “Şüpheli outbound bağlantı tespit edildi.” İşte o an, bir Windows sysadmin olarak gerçek oyunun başladığı andır. Şüpheli süreç tespiti, hem en kritik hem de en çok göz ardı edilen konulardan biri. Bu yazıda, Windows sistemlerde şüpheli süreçleri nasıl tespit edeceğinizi, hangi araçları kullanacağınızı ve gerçek dünya senaryolarında nasıl hareket edeceğinizi ele alacağız.

Neden Süreç Analizi Bu Kadar Önemli?

Modern saldırıların büyük çoğunluğu artık “fileless” ya da “living off the land” tekniklerini kullanıyor. Yani saldırganlar sisteme zararlı bir .exe atmak yerine, Windows’un kendi araçlarını kullanarak sistem içinde hareket ediyor. powershell.exe, wscript.exe, mshta.exe gibi meşru sistem araçları kötü amaçlarla kullanılabiliyor. Bu yüzden sadece antivirüs’e güvenmek artık yeterli değil. Süreçleri, bağlantıları ve davranışları analiz etmek şart.

Bir saldırgan sisteme sızdığında genellikle şu adımları izler: önce bir foothold kurar, sonra lateral movement yapar, ardından persistence mekanizması kurar ve son olarak veriyi dışarı sızdırır. Bu zincirin her halkasında bir şeyler bırakır ve bu izleri süreç analiziyle yakalamak mümkündür.

Temel Araçlar ve Kullanımları

Task Manager’ın Ötesine Geçmek

Task Manager herkesin bildiği araç ama sysadmin olarak bize yetmez. Process Explorer ve Process Monitor olmadan gerçek analiz yapılamaz. Sysinternals suite’i indirip hemen kullanmaya başlayabilirsiniz.

Process Explorer ile bir sürecin tam yolunu, parent process’ini, yüklediği DLL’leri ve ağ bağlantılarını görebilirsiniz. Özellikle VirusTotal entegrasyonu altın değerinde. Options > VirusTotal.com > Check VirusTotal.com seçeneğiyle tüm çalışan süreçlerin hash’lerini otomatik olarak kontrol edebilirsiniz.

PowerShell ile Süreç Analizi

PowerShell, Windows sistemlerde süreç analizinin omurgasıdır. Şüpheli süreçleri tespit etmek için aşağıdaki komutları kullanabilirsiniz:

# Tüm çalışan süreçleri process ID, parent ID ve komut satırıyla listele
Get-WmiObject Win32_Process | Select-Object ProcessId, ParentProcessId, Name, CommandLine | Format-List

Bu komut size sadece süreç adını değil, komut satırı argümanlarını da gösterir. Bir powershell.exe‘nin -EncodedCommand parametresiyle çalışması hemen dikkat çekmelidir.

# Şüpheli PowerShell süreçlerini filtrele
Get-WmiObject Win32_Process -Filter "Name='powershell.exe'" | 
Select-Object ProcessId, ParentProcessId, CommandLine | 
Format-List

Gerçek bir senaryoda bu komutun çıktısında şöyle bir şey görebilirsiniz:

CommandLine : powershell.exe -WindowStyle Hidden -EncodedCommand JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAFMAeQBzAHQAZQBtAC4ATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAA7AA==

Bu encoded command’ı hemen decode etmeniz gerekir. Base64 encoded PowerShell komutları klasik bir IOC’dir.

# Base64 encoded komutu decode et
$encodedCmd = "JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAFMAeQBzAHQAZQBtAC4ATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAA7AA=="
[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($encodedCmd))

Ağ Bağlantılarını Süreçlerle Eşleştirmek

Sadece süreçlere bakmak yetmez, hangi sürecin hangi ağ bağlantısını kurduğunu da bilmek gerekir. netstat bu iş için temel araçtır ama PowerShell versiyonu çok daha güçlüdür:

# Aktif ağ bağlantılarını process adlarıyla eşleştir
Get-NetTCPConnection -State Established | 
ForEach-Object {
    $proc = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        LocalAddress  = $_.LocalAddress
        LocalPort     = $_.LocalPort
        RemoteAddress = $_.RemoteAddress
        RemotePort    = $_.RemotePort
        State         = $_.State
        ProcessName   = $proc.Name
        ProcessId     = $_.OwningProcess
        ProcessPath   = $proc.Path
    }
} | Sort-Object RemoteAddress | Format-Table -AutoSize

Bu komutun çıktısında svchost.exe‘nin beklenmedik bir IP adresine bağlandığını görürseniz, o IP’yi hemen araştırmanız gerekir. Özellikle Tor çıkış noktaları, bilinen C2 altyapıları veya geoblock’lanmış ülkelere yapılan bağlantılar ciddi red flag’dir.

Persistence Mekanizmalarını Kontrol Etmek

Bir saldırgan sisteme sızdıktan sonra mutlaka persistence kurmaya çalışır. Bu sayede sistem yeniden başlatıldığında da erişimini korur. En yaygın persistence mekanizmaları şunlardır:

  • Registry Run Keys: HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun
  • Scheduled Tasks: Zamanlı görevler çok sık kullanılan bir vektördür
  • Services: Sahte Windows servisleri oluşturma
  • Startup Folder: C:ProgramDataMicrosoftWindowsStart MenuProgramsStartup
  • WMI Subscriptions: Görünmez ve kalıcı persistence yöntemi
  • DLL Hijacking: Meşru uygulamaların DLL arama sıralamasını istismar etme

Registry Run key’leri kontrol etmek için:

# Tüm Run key'lerini listele ve şüpheli girişleri tespit et
$runKeys = @(
    "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionRun",
    "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionRunOnce",
    "HKCU:SOFTWAREMicrosoftWindowsCurrentVersionRun",
    "HKCU:SOFTWAREMicrosoftWindowsCurrentVersionRunOnce"
)

foreach ($key in $runKeys) {
    Write-Host "=== $key ===" -ForegroundColor Yellow
    Get-ItemProperty -Path $key -ErrorAction SilentlyContinue | 
    Select-Object * -ExcludeProperty PS* | 
    Format-List
}

Scheduled task’ları kontrol ederken sadece task adına değil, çalıştırdığı komuta bakın:

# Şüpheli scheduled task'ları bul
Get-ScheduledTask | Where-Object {$_.State -ne "Disabled"} | 
ForEach-Object {
    $action = $_.Actions | Select-Object -First 1
    [PSCustomObject]@{
        TaskName    = $_.TaskName
        TaskPath    = $_.TaskPath
        Execute     = $action.Execute
        Arguments   = $action.Arguments
        State       = $_.State
        Author      = $_.Author
    }
} | Where-Object {$_.Execute -match "powershell|cmd|wscript|mshta|rundll32|regsvr32"} | 
Format-List

Gerçek Dünya Senaryosu: LOLBin Saldırısı

Bir müşteri ortamında şu durumla karşılaştım: Antivirüs hiçbir şey bulmamıştı ama SIEM’de düzenli aralıklarla dışarıya doğru garip HTTP istekleri vardı. Analiz ettiğimde şunu buldum: mshta.exe adlı meşru bir Windows aracı, scheduled task aracılığıyla 4 saatte bir çalıştırılıyor ve bir C2 sunucusuna bağlanıyordu.

Bu tür LOLBin (Living Off the Land Binaries) kullanımını tespit etmek için şu yaklaşımı uygulayın:

# Şüpheli parent-child süreç ilişkilerini tespit et
# Örnek: Word'den PowerShell spawn edilmesi
Get-WmiObject Win32_Process | 
ForEach-Object {
    $parent = Get-WmiObject Win32_Process -Filter "ProcessId=$($_.ParentProcessId)" -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        ChildProcess  = $_.Name
        ChildPID      = $_.ProcessId
        ParentProcess = $parent.Name
        ParentPID     = $_.ParentProcessId
        CommandLine   = $_.CommandLine
    }
} | Where-Object {
    ($_.ParentProcess -match "winword|excel|powerpnt|outlook") -and 
    ($_.ChildProcess -match "powershell|cmd|wscript|mshta")
} | Format-List

Bu komut size WINWORD.EXE‘nin powershell.exe spawn ettiği durumları gösterir. Bu klasik bir macro saldırısı veya CVE exploit’inin göstergesidir. Eğer böyle bir çıktı görürseniz o makineyi hemen network’ten izole edin.

Bellek Enjeksiyonu ve Process Hollowing Tespiti

Gelişmiş saldırganlar meşru süreçlerin içine kod enjekte eder. Bu tekniğe process hollowing veya process injection denir. svchost.exe veya explorer.exe gibi meşru süreçlerin hafızasına zararlı kod yerleştirilerek çalıştırılır.

Bu durumu tespit etmek için en iyi yöntem süreçlerin dijital imzalarını kontrol etmektir:

# İmzasız veya şüpheli imzalı süreçleri tespit et
Get-Process | ForEach-Object {
    $proc = $_
    try {
        $signature = Get-AuthenticodeSignature -FilePath $proc.Path -ErrorAction Stop
        [PSCustomObject]@{
            Name      = $proc.Name
            PID       = $proc.Id
            Path      = $proc.Path
            Status    = $signature.Status
            SignedBy  = $signature.SignerCertificate.Subject
        }
    } catch {
        [PSCustomObject]@{
            Name      = $proc.Name
            PID       = $proc.Id
            Path      = $proc.Path
            Status    = "PathNotFound_or_Error"
            SignedBy  = "N/A"
        }
    }
} | Where-Object {$_.Status -ne "Valid"} | Format-List

Bir sürecin path’i C:WindowsSystem32 değil de C:UsersPublic veya C:Temp gibi bir yerden çalışıyorsa bu ciddi bir uyarı işaretidir. Meşru svchost.exe her zaman C:WindowsSystem32svchost.exe yolundan çalışır.

Sysmon ile Gelişmiş Süreç İzleme

Eğer ortamınızda henüz Sysmon kurulu değilse, bunu okuduğunuz anda kurun. Sysmon, Windows’un native event logging’inin çok ötesinde detaylı süreç, ağ ve registry logları üretir.

Sysmon kurulduktan sonra Event ID’leri şu şekilde sorgulayabilirsiniz:

# Sysmon Event ID 1 - Process Creation loglarını sorgula
# Son 1 saat içinde çalışan şüpheli süreçler
$startTime = (Get-Date).AddHours(-1)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-Sysmon/Operational'
    Id        = 1
    StartTime = $startTime
} -ErrorAction SilentlyContinue | 
ForEach-Object {
    $xml = [xml]$_.ToXml()
    $data = $xml.Event.EventData.Data
    [PSCustomObject]@{
        Time          = $_.TimeCreated
        ProcessName   = ($data | Where-Object {$_.Name -eq 'Image'}).'#text'
        CommandLine   = ($data | Where-Object {$_.Name -eq 'CommandLine'}).'#text'
        ParentProcess = ($data | Where-Object {$_.Name -eq 'ParentImage'}).'#text'
        User          = ($data | Where-Object {$_.Name -eq 'User'}).'#text'
        Hashes        = ($data | Where-Object {$_.Name -eq 'Hashes'}).'#text'
    }
} | Where-Object {$_.CommandLine -match "-enc|-EncodedCommand|IEX|Invoke-Expression|DownloadString|WebClient"} | 
Format-List

Sysmon Event ID’lerinden en önemlileri şunlardır:

  • Event ID 1: Process creation, yeni bir süreç başladığında tetiklenir
  • Event ID 3: Network connection, bir süreç ağ bağlantısı kurduğunda tetiklenir
  • Event ID 7: Image loaded, bir süreç DLL yüklediğinde tetiklenir
  • Event ID 8: CreateRemoteThread, process injection tespiti için kritik
  • Event ID 10: ProcessAccess, bir süreç başka bir sürece eriştiğinde tetiklenir
  • Event ID 11: FileCreate, yeni dosya oluşturulduğunda tetiklenir
  • Event ID 13: Registry value set, registry değişikliklerini takip eder

Triage ve İlk Müdahale Checklist’i

Bir şüpheli süreç tespit ettiğinizde paniklemeden sistematik hareket etmeniz gerekir. İşte sahada uyguladığım triage süreci:

İlk 5 dakika – Hızlı Değerlendirme

  • Sürecin tam path’ini ve hash’ini kaydet
  • VirusTotal’da hash’i sorgula
  • Parent process’i kontrol et
  • Aktif ağ bağlantılarını listele
  • Süreci kill etme, önce bellek dump al

5-15 dakika – Derinlemesine Analiz

  • Yüklenen DLL’leri incele
  • Açılan dosya handle’larını kontrol et
  • Registry erişimlerini gözden geçir
  • Lateral movement işaretlerini ara
  • Diğer sistemlerde aynı IOC’leri sorgula

15 dakika sonrası – Containment

  • Sistemi network’ten izole et
  • Forensik image al
  • Incident response sürecini başlat
  • Etkilenen hesapların şifrelerini değiştir
  • SIEM’de ilgili IOC’ler için kural oluştur

Windows Defender ve ETW ile Entegrasyon

Windows Defender ATP (şimdiki adıyla Microsoft Defender for Endpoint) varsa, PowerShell üzerinden gelişmiş sorgular yapabilirsiniz. Yoksa bile Windows’un kendi ETW (Event Tracing for Windows) mekanizması çok değerli veriler üretir.

# Windows Security event log'larında şüpheli süreç aktivitesi
# Event ID 4688: Process Creation
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4688
    StartTime = (Get-Date).AddDays(-1)
} -MaxEvents 1000 -ErrorAction SilentlyContinue

$events | ForEach-Object {
    $msg = $_.Message
    if ($msg -match "powershell|cmd.exe|wscript|mshta|rundll32|certutil|bitsadmin") {
        [PSCustomObject]@{
            TimeCreated  = $_.TimeCreated
            Message      = $msg | Select-String "New Process Name:|Process Command Line:|Creator Process Name:" | 
                           ForEach-Object {$_.Line.Trim()}
        }
    }
} | Format-List

certutil.exe ve bitsadmin.exe gibi araçlara dikkat edin. Bu araçlar saldırganlar tarafından sıkça dosya indirmek için kullanılır çünkü güvenlik duvarları genellikle bunları güvenilir kabul eder.

Otomatik Tespiti Hızlandırmak

Birden fazla makineyi analiz etmeniz gerektiğinde tek tek bağlanmak zaman kaybı. Aşağıdaki script ile ağdaki birden fazla makineyi toplu olarak tarayabilirsiniz:

# Birden fazla remote sistemde şüpheli süreç taraması
$computers = @("SERVER01", "SERVER02", "WORKSTATION01")
$suspiciousProcesses = @("mshta", "wscript", "cscript", "regsvr32", "rundll32", "certutil")

$computers | ForEach-Object {
    $computer = $_
    Write-Host "Taranıyor: $computer" -ForegroundColor Cyan
    
    try {
        $procs = Invoke-Command -ComputerName $computer -ScriptBlock {
            param($suspects)
            Get-WmiObject Win32_Process | 
            Where-Object {$suspects -contains ($_.Name -replace '.exe$', '')} |
            Select-Object Name, ProcessId, CommandLine, 
                @{N='ComputerName'; E={$env:COMPUTERNAME}}
        } -ArgumentList (,$suspiciousProcesses) -ErrorAction Stop
        
        $procs | Format-List
    } catch {
        Write-Warning "$computer erişilemedi: $($_.Exception.Message)"
    }
}

Sonuç

Windows sistemlerde şüpheli süreç tespiti bir kerelik yapılan bir iş değil, sürekli bir süreçtir. Saldırganlar her geçen gün daha sofistike teknikler kullanırken, savunma tarafında da aynı hızla gelişmek zorundayız.

Özetlemek gerekirse en önemli pratik tavsiyelerim şunlardır: Sysmon’u mutlaka kurun ve iyi bir konfigürasyonla çalıştırın. Sysinternals araçlarını kullanmayı alışkanlık haline getirin. PowerShell script logging’ini aktif edin. Parent-child süreç ilişkilerine dikkat edin çünkü meşru süreçlerin anormal child process üretmesi her zaman bir uyarı işaretidir. LOLBin’leri tanıyın ve bunların ağ dışına bağlantı kurmasını proxy üzerinden kontrol altına alın.

En önemlisi, baseline oluşturun. Normal ortamınızda hangi süreçlerin çalıştığını, hangi bağlantıların kurulduğunu bilmeden anormali tespit edemezsiniz. Bir sistemin “normal” haritasını çıkardıktan sonra sapmaları bulmak çok daha kolay hale gelir. Bu yazıda ele aldığımız araçlar ve teknikler, o anormallikleri yakalamak için sağlam bir başlangıç noktası sunuyor.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir