Bu makalede8 bölüm
- Teknoloji
- Microsoft Defender for Identity, Active Directory, Advanced Audit Policy, gMSA, Defender XDR, PowerShell
- Konu
- AD tehdit tespiti sensör kurulumu ve uyarı triyajı
- Seviye
- Orta–ileri
- Ön koşullar
- Defender for Identity içeren lisans
- DC’lerde yerel yönetici ve GPO yönetim yetkisi
- DC’lerden bulut hizmetine 443/TCP erişim
Defender for Identity kurulmuş, sensörler yeşil, portal sessiz. Bu sessizlik çoğu zaman temiz bir ortamı değil, eksik denetim politikalarını, yanlış izinli hizmet hesabını ya da sensörü olmayan bir DC’yi gösterir. Microsoft Defender for Identity, şirket içi Active Directory’ye yönelik saldırı davranışlarını DC’lere ve kimlik altyapısı sunucularına kurulan sensörlerle izleyen bulut tabanlı bir tespit hizmetidir. Bu rehberde sensör gerekliliklerini, denetim yapılandırmasını, uyarı türlerinin anlamını, triyaj sırasını ve güvenlik duruşu değerlendirmelerini, kurulumda sahada en çok takılınan noktalarla birlikte anlatıyoruz.
Defender for Identity neyi görür, neyi görmez
Sensör, kurulduğu sunucuda üç kaynaktan veri toplar: DC’ye gelen ve DC’den çıkan ağ trafiği (Kerberos, NTLM, LDAP, DNS, SMB, RPC), Windows olay günlükleri ve dizin sorgularıyla elde edilen nesne bilgileri. Veri bulutta davranış modelleriyle işlenir ve Microsoft Defender XDR portalında uyarı ve olay (incident) olarak görünür.
Sınırlarını bilmek de kurulumun parçası. Defender for Identity uç noktadaki işlem davranışını görmez (bu Defender for Endpoint’in alanı), Entra ID bulut oturum açmalarını tek başına analiz etmez, sensör kurulmamış bir DC üzerinden geçen saldırıyı hiç görmez. Görmediği DC, karanlık odadır. Statik yapılandırma zayıflıklarını güvenlik duruşu değerlendirmeleriyle kısmen raporlar; derin ACL ve ayrıcalık yolu analizi için AD saldırı yolu analizi ayrı bir çalışma olarak kalır.
Sensör gereklilikleri ve kurulum
Sensörün kurulacağı sunucular:
- Tüm yazılabilir DC’ler ve RODC’ler. Tek bir DC’nin dışarıda kalması, o DC üzerinden geçen etkinliğin görünmemesi demektir; saldırgan hangi DC ile konuşacağını seçebilir.
- AD FS, AD CS (sertifika yetkilisi) ve Entra Connect sunucuları. Bunlar Tier 0 kimlik altyapısıdır ve kendilerine özgü saldırıların hedefidir.
Kurulum öncesi kontrol listesi:
- Sürüm ve kaynak: Desteklenen Windows Server sürümleri ve sensörün donanım gereksinimleri için Microsoft’un güncel gereksinim sayfasını ve kapasite planlama aracını kullanın; DC’nin mevcut yüküne göre ek CPU ve bellek gerekebilir.
- Bağlantı: Sensör, Defender for Identity bulut hizmetine 443/TCP üzerinden erişmelidir. Proxy varsa kurulum parametreleriyle tanımlanır ve SSL inspection’dan hariç tutulur.
- Ağ adı çözümleme (NNR): Sensör IP adreslerini cihaz adlarıyla eşlemek için istemcilere NTLM over RPC (135/TCP), NetBIOS (137/UDP), RDP (3389/TCP, yalnız ilk paket) ve ters DNS sorguları kullanır. İç firewall’larda DC’lerden istemci ağlarına bu bağlantılara izin verilmelidir; aksi halde uyarılarda cihaz adı yerine yalnız IP görünür ve her triyaj bir DHCP kaydı aramasıyla başlar.
- Sanal DC’ler: VMware üzerindeki DC’lerde sanal ağ kartının Large Send Offload ayarıyla ilgili Microsoft’un belgelediği bir uyumluluk notu vardır; kurulumdan önce kontrol edin.
Klasik sensör, portaldan indirilen paket ve çalışma alanına özgü erişim anahtarıyla kurulur. Sessiz kurulum örneği:
"Azure ATP Sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<portaldaki-erisim-anahtari>"
Defender for Endpoint’e kayıtlı ve desteklenen sürümdeki DC’lerde, ayrı paket kurmadan portal üzerinden etkinleştirilen yeni nesil sensör seçeneği de var. Hangi sensör tipinin ortamınıza uyduğunu ve iki tipin hangi özellikleri desteklediğini Defender for Identity dokümantasyonundan karşılaştırın.
Denetim politikaları ve dizin hizmeti hesabı
Tespitlerin önemli kısmı Windows olaylarına dayanır. Gerekli gelişmiş denetim ilkeleri (Advanced Audit Policy) DC’lere uygulanmamışsa sensör sağlıklı görünür ama bazı uyarılar hiç üretilmez. Sağlıklı sensör, çalışan tespit demek değildir. Başlıca ayarlar:
| Denetim alt kategorisi | Değer | Örnek olaylar |
|---|---|---|
| Credential Validation | Success, Failure | 4776 |
| Computer Account Management | Success, Failure | 4741, 4743 |
| Security Group Management | Success, Failure | 4728, 4729, 4732, 4733, 4756, 4757 |
| User Account Management | Success, Failure | 4726 |
| Directory Service Access | Success, Failure | 4662 |
| Directory Service Changes | Success, Failure | 5136 |
| Security System Extension | Success, Failure | 7045 |
Bunlara ek olarak 4662 olaylarının üretilmesi için domain kökünde nesne denetimi (SACL) tanımlanmalı, NTLM tespitleri için DC’lerde NTLM denetimi açılmalıdır (8004 olayları; ayrıntılar NTLM denetimi ve kısıtlama yazısında). AD FS, AD CS ve Entra Connect sunucuları için ek denetim ayarları gerekir.
Microsoft’un DefenderForIdentity PowerShell modülü mevcut yapılandırmayı raporlar ve gerekli ayarları GPO olarak uygulayabilir. Elle GPO kurcalamadan önce ilk çalıştırılacak araç budur:
Install-Module DefenderForIdentity -Scope CurrentUser
# Domain genelinde gerekli denetim yapılandırmalarının durumu
New-MDIConfigurationReport -Path C:\mdi -Mode Domain
# Eksik ayarları yeni bir GPO ile uygula (önce raporu inceleyin)
Set-MDIConfiguration -Mode Domain -Configuration All
Dizin hizmeti hesabı (DSA): Sensör dizin sorguları için bir hizmet hesabı kullanır. Önerilen tip gMSA; parolası AD tarafından otomatik döndürülür. Hesabın tüm nesnelerde ve Deleted Objects kapsayıcısında okuma izni olmalı; sensörün kurulduğu sunucuların bilgisayar hesapları (pratikte bunları içeren bir grup) gMSA’nın PrincipalsAllowedToRetrieveManagedPassword listesine eklenmelidir. Sensör sunucularında “Log on as a service” hakkını kısıtlayan bir GPO varsa gMSA bu hakka da eklenir. Sahada en sık gördüğümüz hata burada: gruba yeni eklenen DC’nin bilgisayar hesabı Kerberos biletini yenilemeden gMSA parolasını alamaz; yeniden başlatma veya bilet temizliği gerekir. Yanal hareket yolu hesaplaması için hesabın uç noktalarda SAM-R sorgusu yapabilmesi gerekir; bu, “Network access: Restrict clients allowed to make remote calls to SAM” ilkesine DSA’nın eklenmesiyle sağlanır ve yalnız gereken bilgisayar kapsamına uygulanmalıdır.
Uyarı türleri ve anlamları
Uyarılar saldırı zincirinin aşamalarına göre gruplanır. Sık görülen türler ve savunma tarafındaki ilk yorumları:
| Uyarı | Aşama | İlk yorum |
|---|---|---|
| Security principal reconnaissance (LDAP) | Keşif | Toplu LDAP sorgusu; yetkili analiz araçları da tetikler |
| User and IP address reconnaissance (SMB) | Keşif | DC’de oturum listeleme denemesi |
| Suspected Kerberos SPN exposure | Kimlik bilgisi erişimi | Kerberoasting olasılığı; hedef hizmet hesaplarını inceleyin |
| Suspected AS-REP Roasting attack | Kimlik bilgisi erişimi | Ön kimlik doğrulaması kapalı hesaplara istek |
| Suspected brute-force attack (Kerberos, NTLM, LDAP) | Kimlik bilgisi erişimi | Parola deneme veya password spray |
| Suspected identity theft (pass-the-ticket) / overpass-the-hash | Yanal hareket | Çalınmış bilet veya özet kullanımı |
| Suspected DCSync attack | Kimlik bilgisi erişimi | DC olmayan kaynaktan çoğaltma isteği; yüksek öncelik |
| Suspected Golden Ticket usage | Kalıcılık | Sahte TGT; krbtgt’nin ele geçirildiğini düşündürür |
| Suspicious additions to sensitive groups | Ayrıcalık yükseltme | Ayrıcalıklı gruba beklenmeyen üye |
Kerberos tabanlı uyarıların arka planı için Kerberoasting ve AS-REP roasting yazısına bakabilirsiniz.
Uyarı triyajı ve inceleme adımları
Her uyarıda aynı sırayla ilerlemek hem hızı hem karar tutarlılığını artırır. Analist değişse de sonuç değişmemeli:
- Kaynak: Etkinlik hangi cihazdan ve hangi hesaptan geldi? Kaynak cihaz bir yönetim sunucusu, tarayıcı veya izinli bir analiz aracı mı?
- Hedef: Hangi DC, hangi hesaplar veya gruplar etkilendi? Hedef Tier 0 mı?
- Zaman çizelgesi: Aynı kaynaktan önceki ve sonraki etkinlikler; Defender XDR olay görünümünde uç nokta ve e-posta uyarılarıyla ilişki.
- Doğrulama: Kaynak cihazda Defender for Endpoint zaman çizelgesiyle ilgili işlemi bulun; değişiklik kaydı veya planlı iş ile eşleşiyor mu?
- Sınıflandırma ve eylem: True positive ise hesabı devre dışı bırakma, parola sıfırlama, cihazı izole etme; zararsız ama beklenen etkinlikse (benign true positive) gerekçesiyle kapatma ve gerekirse hariç tutma tanımlama.
Hariç tutmaları dar tutun. Belirli bir tarayıcı sunucusunu belirli bir tespit için hariç tutmak kabul edilebilir; bir alt ağın tamamını tüm keşif tespitlerinden çıkarmak, saldırganın o alt ağdan görünmez kalması demektir. Geniş hariç tutma, kör noktadır.
Güvenlik duruşu değerlendirmeleri
Defender for Identity, sensörlerin topladığı veriden yapılandırma zayıflıklarını da çıkarır ve bunları Microsoft Secure Score içinde öneri olarak sunar. Öne çıkan değerlendirmeler:
- Güvensiz Kerberos delegasyonu (kısıtlanmamış delegasyona sahip hesap ve bilgisayarlar).
- Ağ üzerinden açık metin kimlik bilgisi gönderen hizmetler (ör. basit LDAP bind).
- Hassas gruplarda uzun süredir kullanılmayan hesaplar.
- Eski protokol ve zayıf şifreleme kullanımı (NTLMv1, RC4).
- DC’lerde Print Spooler hizmetinin çalışması.
- Güvensiz hesap öznitelikleri (parolası süresiz, ön kimlik doğrulaması kapalı, tersinir şifrelemeli parola).
- İzlenmeyen DC’ler (sensör kurulmamış).
Bu öneriler sabit bir kontrol listesi değil, ortamınızdaki gerçek nesnelerin listesidir. Her birine sahip atayıp düzeltmeyi takip etmek, kurumsal siber güvenlikte tespit katmanını önleme katmanıyla birleştirir. Sahipsiz öneri, sonsuza dek açık kalır.
Sık kurulum hataları
- Eksik sensör kapsamı: Yalnız birkaç DC’ye kurulum, AD CS ve Entra Connect sunucularının unutulması. Sonradan eklenen DC’ye sensör kurmayı unutmak da aynı sonuçtur; DC terfi prosedürüne sensör kurulumunu yazın.
- Denetim ilkelerinin eksik olması: Default Domain Controllers Policy, Defender for Identity’nin gerektirdiği gelişmiş denetim alt kategorilerinin tamamını yapılandırmaz; sensör sağlık uyarılarını düzenli kontrol edin.
- NNR’nin firewall’da engellenmesi: Uyarılarda cihaz eşleşmesinin başarısız olması.
- SSL inspection: Sensörün bulut bağlantısının araya giren proxy nedeniyle kesilmesi.
- Sağlık uyarılarının sahipsiz kalması: Sensör durduğunda veya olay akışı kesildiğinde kimsenin fark etmemesi. Sağlık bildirimlerini SOC kuyruğuna yönlendirin.
Sensör uyarılarının 7/24 izlenmesi ve diğer kaynaklarla ilişkilendirilmesi SOC ve yönetilen güvenlik modelinin konusudur; kurulum öncesi denetim yapılandırması ve duruş bulgularının düzeltilmesi ise Active Directory güvenlik denetimi ile birlikte planlanabilir.
Sık sorulan sorular
Defender for Identity sensörü DC performansını etkiler mi?
Sensör trafik ve olay işlediği için DC üzerinde ek CPU ve bellek kullanır. Etkinin kabul edilebilir kalması için kurulumdan önce Microsoft’un kapasite planlama aracıyla mevcut yükü ölçün, gerekirse DC kaynaklarını artırın.
Sensörü yalnız bazı DC’lere kurmak yeterli mi?
Hayır. Saldırgan hangi DC ile konuşacağını seçebilir; sensörü olmayan DC üzerinden geçen etkinlik görünmez. Tüm DC’lere ve AD FS, AD CS, Entra Connect sunucularına kurulum önerilir.
Dizin hizmeti hesabı için neden gMSA öneriliyor?
gMSA parolası AD tarafından otomatik ve karmaşık biçimde döndürülür, interaktif oturum açmada kullanılamaz ve parolayı yalnız izin verilen sunucular alabilir. Sabit parolalı bir hizmet hesabına göre çok daha düşük risk taşır.
Yetkili bir zafiyet taraması uyarı üretirse ne yapılmalı?
Uyarıyı zararsız ama beklenen etkinlik olarak sınıflandırın, gerekçesini kaydedin. Tarama düzenliyse yalnız ilgili tarayıcı cihazı ve ilgili tespit türü için dar bir hariç tutma tanımlayın; geniş alt ağ hariç tutmalarından kaçının.
- Teknoloji
- Microsoft Defender for Identity, Active Directory, Advanced Audit Policy, gMSA, Defender XDR, PowerShell
- Konu
- AD tehdit tespiti sensör kurulumu ve uyarı triyajı
- Seviye
- Orta–ileri
- Ön koşullar
- Defender for Identity içeren lisans
- DC’lerde yerel yönetici ve GPO yönetim yetkisi
- DC’lerden bulut hizmetine 443/TCP erişim
Kimlik ve Microsoft 365