Windows Event ID’lerin Önemi

Zararlı ya da zararsız, iyi ya da kötü niyetli, içeriden mi dışarıdan mı?

Kurum içi ağlarda güvenlik vaka yöneticileri bu soruların cevabını arar da arar.

Peki Windows, vaka yönetimlerinde Güvenlik departmanına ne gibi kolaylıklar sağlamıştır?

Windows olay kimlikleri (Event ID) her türlü olayın çözümlenmesinde fikir verebilir, başka bir vaka için ön ayak olabilir ya da kolaylık sağlayabilir.

Önemli Olay Kimliklerinden bazıları aşağıdaki tabloda yer almıştır

Olay Kimliği
(EventID)
Açıklama
4624 Başarılı Login
4625 Başarısız Login
4672 Admin Hesabı Logini
4634,4647 Başarılı Logoff
4771 Etki alanında ön kimlik doğrulama başarısız oldu
4768 DC TGT hakkında sorun bildirdi
4776 Etki alanında başarılı ya da başarısız login
7034 Servis beklenmedik bir şekilde çöktü
7035 Servis, başlatma veya durdurma komutu gönderdi
7036 Servis durdu veya başladı
7040 Servis başlangıç tipi değiştirildi (Başlangıçta, elle vs.)
5140 Ağ paylaşımı planlandı
4778 RDP oturum isteği
4779 RDP oturumu kapandı

 

Yukarıda görüldüğü üzere 4624 ve 4625 in 4776 ID lerinin birbirinden farkları net olarak ortaya konmaktadır. Özellikle 4624 ve 4625 lokal makine üzerinde alınan ve DC’ye erişilemediğinde üretilen ID’lere örnektir. Makine DC’ye bağlıysa ise 4771, 4768 ve 4776 ID’leri üretilir.

Farklı ID’leri birbirleriyle ilişkilendirmek de önemlidir. Örneğin 4624 akabinde görülen 4634/4647 ID’leri tamamlanmış bir oturum fikri verebilir. Çok fazla 4625 ID’si görmek bir sözlük saldırısının ya da bir zararlı yazılımın işareti olabilir.

Windows Oturum Türleri de (Login tipleri) araştırma için daha fazla yol kat edilmesini sağlayabilir.

Oturum Türü Açıklama
2 Yerel login (Örn: Klavye ile)
3 Network Login
4 Batch Login- zamanlanmış görevler için kullanılır
5 Windows servis login – (Görünür/Interaktif olmayacaktır)
7 Kilit ekranını açmak/kapatmak için kimlik bilgileri kullanıldı
8 Ağ üzerinden kimlik bilgileri clear text olarak gönderildi
9 Şu anki oturumu açan haricinde ”run as” komutuyla (Yönetici vs. olarak çalıştır ) yeni kimlik bilgileri kullanıldı
10 RDP (Uzak Masaüstü)
11 Login kimliği cachten getirildi
12 Cachten RDP yapıldı
13 Cachten kilit açıldı (oturum zaten açık)

 

Görüldüğü üzere 2 nolu login tipi yerel bir oturum açıldığına işaret verirken, 3 ise ağ üzerinden oturumun açıldığına yorumlanmalıdır.

Diğer önemli bir olay örneğin 7 numaralı login tipi ile 11 numaralı login tipinin farklarıdır. 7 numaralı login bilgileri DC’den eşleştirilirken, 11 nolu login tipi makine DC’ye erişilemediğinde görülür. Windows o makineye oturum açmayı başaran son 10 kimlik bilgilerini (kullanıcı adı ve şifre) hash olarak saklar. Buradaki son 10 kimlik bilgisinden kasıt birbirinden farklı olan değil, aynısı veya farklısı da olsa son 10 oturum açılmış kimlik bilgileridir.

Aşağıdaki EventID ve Login Tipi örnekleri ile yorumlarımızı pekiştirebiliriz.

1

Event ID:4625 Başarısız Login –Bilinmeyen kullanıcı ya da yanlış şifre

Login ID:7 Account Name ve Account Domainde yazan kimlik bilgileri kullanıldı

—————————————————————————————————–

2

Event ID:4624 Başarılı Login

Login ID:7 Account Name ve Account Domainde yazan kimlik bilgileri kullanıldı

——————————————————————————————————

3

Event ID:4624 Başarılı Login

Login ID:11 Login kimliği cachten getirildi,  bu makina login olunduğu anda DC’ye ulaşmadı, yani son 10 kimlik bilgisinden birisi (Account bölümünde yazan kimlik) kullanıldı

 

Windows’ta olay yönetiminde yer alan numaraların varsa asıl olayın çözülmesinde ne kadar faydalı olabileceğini görmüş olduk. Bunlarla birlikte Windows içerisinde “zamanlanmış görev” logları bilgisayarımızın ele geçirilip geçirilmediği hususunda bize fikir verebilir. Örneğin bir servisin günün belli saatlerinde oturum açılması için görev zamanlaması gerçekleştirmesi şüpheli bir harekettir.

Olay Kimliği Açıklama
106 Görev zamanlandı
200 Görev başlatıldı
201 Görev tamamlandı
141 Görev silindi

Kurumiçi sistemlerde yaşanan sorun veya olaylara müdahalenin nereye yapılacağının bilinmesi önemlidir. Zira en ufak bir rakam kurum açısından maddi manevi devasa zararlara yol açabilir. Peki zararlı bir yazılım bulaştığı ve ağ üzerinde yayılmaya başladığı anda kurum içerisindeki sistemde neler yapılabilir?

  1. Zararlı yazılım ilk önce bulaşmış olduğu sistem üzerinden ağa yayılmak için 4624 olay kimliğini 3 nolu oturum türüyle kullanacaktır. Bunu tespit ettiğiniz loglarda zamanı bi kenara not edin.
  2. O zamana yakın diğer sistemlerde 4672 yani yönetici hakları ile oturum açılıp açılmadığına bakın.
  3. Eğer bulursanız o sistem üzerinde artık zararlı dosya yönetici hakları ile çalıştığından kendisini diğer sistemlere bulaştırmak için 5140 olay kimliğini kullanarak ağ paylaşımı planlayacaktır. Bu sistem kurum içindeki çatlak olacaktır. Ki buradan zararlının bağlantı sağlanmış olduğu C&C sunucusunun IP bilgileri gibi kritik bilgilere dahi ulaşılabilir.
  4. Artık sistemdeki bu çatlak sayesinde zararlı çalıştırabilir kodlar hedef kurum ağını ele geçirecektir.
  5. Olay kimliklerinde zamanlanan, başlatılan, tamamlanan, silinen görevler fikir vermelidir. Örneğin hedefli bir APT kurum içerisinde işini tamamladıktan sonra kendisini ve logları silmek ile mükelleftir. Zararlı dosyanın ismi ile birlikte zamanlanmış 200 kodlu bir log silme işlemi varsa vay halimize
  6. Logları da temizleyen zararlı son olarak kendi oturumunu 4634 olay kimliği ile kapatarak başarının doruklarına ulaşarak sistemi tamamıyla terk edecektir.

 

Peki RDP yani uzak masaüstü ile ele geçirilmiş bir sistemde olay logları karşımıza nasıl çıkacaktır?

  1. 4778 nolu RDP oturumu talebi ile bir uzak masaüstü oturumu isteği gelir. Ancak bu başlamış bir oturum olarak yorumlanmamalıdır. Burada görülen IP adres ve sistem adı gibi bilgiler işe yarayabilir.
  2. 4778 in akabinde görülen 4624 olay kodu ve 10 nolu oturum tipi oturumun artık RDP ile açıldığı kesin bilgisini verecektir.
  3. Bu kısımdan sonra bir önceki bölümün 3. Maddesindeki ağ paylaşımı ya da 5. Maddesindeki görev zamanlama şeklinde bir senaryo ile karşılaşılabilir.
  4. Oturum ise 4634/4647 kodlarının akabinde 4779 RDP’in sonlandırıldığında dair bir bilgi verecektir. Tek başına görülen 4778 ve 4779 RDP istek ve kapanmalarına aldanmamak gerekir. RDP oturumunun açıldığına kesin emin olmak için mutlaka 4778-4624…..4634-4779 sıralaması ile logları görmek gerekir. 4778 ve 4779’un ayrıntılarından çeşitli fikirler elde edilebilir.

 

Bunlar gibi çeşitli senaryolar ile karşılaşılabilir. Şüphelenilen sistem üzerinde yapılacak log incelemelerinde (genellikle!) sistemi karantina altına almak olay yönetiminin başarıya ulaşmasında fayda sağlayacaktır. Özellikle bir APT’nin ortalama 200 gün kurum içerisinde kaldığı düşünüldüğünde…

Herkese güvenli günler…

Pin It

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Time limit is exhausted. Please reload CAPTCHA.