Dijital Adli Bilişim - Bir Siber Saldırının Görünmeyen Hikâyesi: Windows Günlükleri, RAM, Zararlı Yazılım ve Ağ Trafiği

Bir sabah kurumun bilgi işlem birimine sıra dışı bir bildirim ulaşıyor. Bir çalışan, bilgisayarının önce yavaşladığını, ardından kısa süreliğine kendiliğinden açılıp kapanan bir pencere gördüğünü söylüyor.

Güvenlik yazılımı aynı saatlerde şüpheli bir faaliyet uyarısı üretmiş. Ancak bilgisayar şu anda normal çalışıyor. Çalışanın söylediğine göre herhangi bir program kurulmamış ve bilinmeyen bir dosya açılmamış. Peki gerçekten ne yaşandı?

Bilgisayarın normal çalışıyor olması, daha önce bir güvenlik olayı gerçekleşmediğini kanıtlamaz. Aynı şekilde güvenlik yazılımının uyarı vermesi de tek başına sistemin ele geçirildiği anlamına gelmez.

Olayı anlamanın yolu, birbirinden farklı teknik kaynaklara bakmaktır. Windows günlükleri ne kaydetti? Hangi süreçler çalıştı? Bellekte neler bulunabilir? Bilgisayar dış ağlarla iletişim kurdu mu? 

Bir siber olayın hikâyesi çoğu zaman tek bir dosyada değil, farklı kayıtların birbirleriyle kurduğu ilişkide saklıdır.

İlk hata: Güvenlik uyarısını doğrudan olayın tamamı sanmak

Bir güvenlik uygulaması şüpheli davranışı tespit etmiş olabilir. Ancak tespit edilen dosyanın kötü amaçlı olup olmadığı, gerçekten çalıştırılıp çalıştırılmadığı ve sistemde ne yaptığı ayrı konulardır.

Örneğin bir yürütülebilir dosyanın karantinaya alınması, onun mutlaka işlemci üzerinde çalıştığını göstermez.

Bazen güvenlik yazılımları dosyaları açılmadan da inceleyebilir. Bazen de çalışan bir uygulamanın davranışı güvenlik ürünü tarafından şüpheli olarak değerlendirilebilir.

Bu nedenle olayın ilk araştırma sorusu şudur: Tespit edilen nesne yalnızca sistemde mi bulundu, yoksa gerçekten bir faaliyet gerçekleştirdi mi? Bu ayrım, araştırılacak veri kaynaklarını belirler.

Windows olay günlükleriyle ilk izleri aramak

Windows, sistem, güvenlik ve uygulama faaliyetleriyle ilişkili olay kayıtları tutabilir. Bu kayıtlar çoğunlukla EVTX biçiminde saklanır. Özellikle güvenlik incelemelerinde oturum açma, süreç oluşturma ve yetki kullanımıyla ilişkili olaylar önemli olabilir.

Örneğin başarılı oturum açmayla ilişkili Event ID 4624, ilgili hesabın hangi oturum açma türüyle sisteme bağlandığını araştırmak için kullanılabilir. Burada önemli olan yalnızca olayın görülmesi değildir.

Oturum açma türü, hesap bilgileri, kaynak ve diğer alanlar değerlendirilmelidir. Çünkü ağ üzerinden gerçekleşen bir oturumla bilgisayar başında gerçekleştirilen etkileşimli oturum aynı şey değildir.

Event ID 4688 neden dikkat çeker?

Windows'ta uygun denetim yapılandırması mevcutsa yeni süreç oluşturulduğunda 4688 numaralı güvenlik olayı kaydedilebilir. Bu kayıt, hangi yürütülebilir dosyanın süreç olarak başlatıldığına ilişkin bilgi sağlayabilir. Bazı yapılandırmalarda komut satırı bilgileri de kaydedilebilir.

Ancak bu bilgi her zaman mevcut değildir. Süreç oluşturma denetiminin ve komut satırı kaydının önceden etkinleştirilmiş olması gerekebilir. Dolayısıyla olay sonrasında bu kayıtları aradığınızda bulamamanız, sürecin kesinlikle çalışmadığı anlamına gelmez.

Sysmon daha fazla ayrıntı sağlayabilir mi?

Microsoft Sysmon, uygun biçimde kurulmuş ve yapılandırılmışsa Windows'taki belirli sistem faaliyetlerine ilişkin daha ayrıntılı kayıtlar üretebilir. Örneğin:

  • Event ID 1: Süreç oluşturma
  • Event ID 3: Ağ bağlantısı
  • Event ID 22: DNS sorgusu

Ancak bu olay türlerinin üretilmesi kullanılan Sysmon sürümüne ve yapılandırmasına bağlıdır. Özellikle süreç kaydı, programın adı, yolu, üst süreç ilişkisi ve başka alanlar üzerinden değerlendirmeye yardımcı olabilir.

Burada araştırılması gereken önemli sorulardan biri şudur: Bir program nasıl başladı ve onu hangi süreç başlattı?

Örneğin beklenmedik bir uygulamanın belge görüntüleyicisinden sonra çalıştığına ilişkin kayıt bulunması araştırmaya değer olabilir. Fakat yalnızca üst süreç–alt süreç ilişkisine bakarak kötü amaçlı davranış sonucuna ulaşmak doğru değildir. Meşru yazılımlar da başka programlar başlatabilir.

Süreç ağacı neden önemlidir?

Bir bilgisayarda yüzlerce süreç bulunabilir. Bazıları işletim sisteminin parçasıdır. Bazıları kullanıcı uygulamalarıdır. Bazılarıysa arka plan hizmetleridir.

Süreç ağacı, belirli bir sürecin hangi başka süreçle ilişkili başlatıldığını anlamaya yardımcı olabilir. Örneğin: "explorer.exe → uygulama.exe → yardımcı_program.exe"

Bu yapı tek başına zararlı değildir. Ancak aynı süreç ilişkisi, olayın zamanı, çalıştırılan dosyanın yolu, komut satırı ve ağ faaliyetleriyle birlikte değerlendirildiğinde daha anlamlı hâle gelir.

Ayrıca süreç kimliklerinin zaman içinde yeniden kullanılabileceği dikkate alınmalıdır. Farklı zamanlarda, aynı PID değerinin görülmesi, bunların aynı süreç olduğu anlamına gelmez. Bu nedenle süreç ilişkilendirmesinde zaman ve mümkünse benzersiz süreç tanımlayıcıları önemlidir.

RAM neden olayın farklı bir yüzünü gösterir?

Disk üzerindeki dosyalar kalıcı veri kaynaklarından biridir. RAM ise çalışan sistemin geçici durumuna ilişkin bilgiler barındırabilir. Bir bilgisayar hâlâ açıksa çalışan süreçler, bellek eşlemeleri ve bazı bağlantı yapıları RAM üzerinde bulunabilir.

Örneğin disk üzerindeki dosyası artık bulunmayan bir sürecin belirli bellek yapılarının incelenebilmesi mümkün olabilir. Ancak burada iki önemli sınır vardır.

  • Birincisi, bellek sürekli değişir. İncelemenin yapıldığı an, elde edilebilecek bilgileri etkiler.
  • İkincisi, çalışan sistemden bellek edinmek için kullanılan yazılımın kendisi de sistem durumunu değiştirebilir.

Bu nedenle bellek edinimi gelişigüzel gerçekleştirilecek bir işlem değildir. Mevcut sistem durumu, yetki, kullanılacak yöntem ve olası veri kaybı önceden değerlendirilmelidir.

Bilgisayarın kapatılması bazı uçucu verilerin kaybına neden olabilir. Buna karşılık sistemi açık bırakmak da yeni faaliyetlerin devam etmesine yol açabilir. Bellek incelemesinin değeri kadar edinim kararının da teknik gerekçesi önemlidir.

Zararlı yazılım her zaman dosya bırakır mı?

Bir saldırıyla ilişkili yazılım diskte kalıcı dosya oluşturabilir. Ancak bütün kötü amaçlı faaliyetler aynı biçimde gerçekleşmez.

Bazı işlemler mevcut sistem araçlarından yararlanabilir. Bazıları belirli geçici dosyalar oluşturabilir. Bazılarıysa davranışlarının bir bölümünü bellek üzerinde gerçekleştirebilir. Bu nedenle yalnızca bilinmeyen ".exe" dosyalarını aramak, kapsamlı güvenlik incelemesi için yeterli değildir.

Şüpheli faaliyetlerin araştırılmasında; süreç, dosya, Registry, hizmet, zamanlanmış görev ve ağ kayıtları gibi kaynaklar birlikte değerlendirilebilir.

Kalıcılık göstergeleri neden önemlidir?

Bazı yazılımlar sistem yeniden başlatıldığında da çalışmaya devam etmek amacıyla belirli otomatik başlatma mekanizmalarını kullanabilir.Windows hizmetleri, görev zamanlayıcısı ve bazı Registry başlangıç alanları buna örnektir. Ancak otomatik başlayan her uygulama zararlı değildir.

Güvenilir bir inceleme için programın kaynağı, davranışı, imza durumu, oluşturulma koşulları ve ilgili olay kayıtları değerlendirilmelidir.

Ağ trafiği olayı tamamlayabilir mi?

Şimdi örnek olayda şüpheli uygulamanın çalıştığı saate yakın bir zamanda bilgisayarın dış ağla iletişim kurduğunu düşünelim.

  • Bu iletişime ait kayıtlar varsa hangi teknik ayrıntılar incelenebilir?
  • Paket yakalama dosyalarında kaynak ve hedef adresler, portlar, protokoller, bağlantı zamanları ve belirli trafik özellikleri araştırılabilir.
  • Wireshark gibi bir araçla PCAP dosyaları incelenebilir.
  • DNS trafiğini görüntülemek için: dns
  • TCP paketlerini görmek için: tcp
  • Belirli bir TCP bağlantısına odaklanmak için ise: tcp.stream == 0

gibi bir görüntüleme filtresi kullanılabilir. Son örnekteki 0, seçilmiş bağlantının akış numarasına göre değiştirilmelidir. Bu filtreler yalnızca görüntülenen paketleri sınırlar; PCAP dosyasındaki bütün verileri silmez.

DNS kaydı neyi anlatır?

Bir DNS sorgusu, belirli alan adıyla ilgili çözümleme faaliyeti olduğunu gösterebilir. Ancak sorgunun görülmesi, ilgili web sayfasının kullanıcı tarafından görüntülendiğini garanti etmez.

Sorgu uygulama tarafından otomatik gerçekleştirilmiş olabilir. Ayrıca DNS trafiği her zaman klasik biçimde görünmeyebilir. Şifreli DNS mekanizmaları, önbellek veya farklı yapılandırmalar elde edilen kayıtları etkileyebilir.

Şifreli bağlantıdan dosya içeriği öğrenilebilir mi?

Her zaman değil. HTTPS gibi şifreli iletişimlerde ağ kayıtları belirli bağlantı bilgilerini gösterebilirken uygulama içeriği şifreli olabilir.

Bu nedenle büyük miktarda dış ağ trafiği görülmesi, kesin olarak gizli dosya gönderildiğini kanıtlamaz. Olayı anlamak için ağ bulgularının uç nokta ve uygulama kayıtlarıyla ilişkilendirilmesi gerekebilir.

Dört kaynağın birlikte anlattığı olay

Bu dört kaynak birbirini destekleyebilir. Ancak yine de programın ne amaçla çalıştığı, bağlantının içeriği ve kullanıcı niyeti hakkında ayrı değerlendirmeler gerekebilir.

Özellikle güvenilirlik değerlendirmesinde veri kaynağının bağımsızlığı önemlidir. Aynı kayıt iki farklı analiz aracında görüntülenmişse bu otomatik olarak iki bağımsız delil oluşturmaz.

Güvenlik uyarısından olayın gerçek etkisine

Bir kurumda güvenlik olayını yalnızca "Virüs bulundu" veya "Şüpheli bağlantı var" şeklinde tanımlamak çoğu zaman yeterli değildir. Olayın kapsamı ve etkisi araştırılmalıdır.

Hangi cihazlar etkilenmiş olabilir? Hangi hesaplar kullanılmış? Hangi süreçler başlatılmış? Hangi ağ bağlantıları kurulmuş? Veri bütünlüğüne veya erişilebilirliğine ilişkin bir değişiklik var mı? Bu sorular yanıtlanmadan olayın tamamen anlaşıldığını söylemek güçtür.

Ayrıca teknik bulguların, kurumsal kararlara dönüştürülmesi gerekir. Bir olayın izole edilmesi, sistemin toparlanması ve tekrarının önlenmesi için doğru sorumluluk ve müdahale süreçleri önemlidir.

Sonuç: Bir saldırı tek bir kayıtta saklanmaz

Bilgisayarın bir süre yavaşlaması tek başına saldırı kanıtı değildir. Bir güvenlik ürününün uyarısı da olayın bütün hikâyesini açıklamaz.

Windows olay günlükleri, süreç kayıtları, bellek incelemesi ve ağ trafiği birlikte değerlendirildiğinde çok daha güçlü bir teknik görünüm elde edilebilir. Fakat her kaynak yalnızca belirli bir bölüm hakkında bilgi sağlar.

Gerçek uzmanlık, veriler arasında makul ilişkiler kurarken desteklenmeyen sonuçlardan kaçınmaktır. Bir siber olayın nasıl başladığını anlamak, yalnızca kötü amaçlı dosyayı bulmakla değil; olayın sistem üzerinde bıraktığı farklı etkileri doğru birleştirmekle mümkündür.

Kaynaklar

  1. Microsoft — Sysmon: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
  2. Microsoft — Audit Process Creation: https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-process-creation
  3. Microsoft — Get-WinEvent: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent
  4. Wireshark — User's Guide: https://www.wireshark.org/docs/wsug_html/
  5. NIST — Guide to Integrating Forensic Techniques into Incident Response: https://doi.org/10.6028/NIST.SP.800-86