Son dönemde karşılaştığım bir kaç olay üzerinden çok kritik bir konuyu tekrar hatırlatmak istiyorum. Kurumların on-prem Active Directory ortamı kompromize ediliyor, yani saldırganlar AD tarafında yetki elde ediyor. Ekipler doğal olarak AD temizliği, sunucu kontrolleri, parola resetleri, domain controller incelemeleri gibi aksiyonlara odaklanıyor.
Ancak burada çok kritik bir soru var:
Bu ortam Microsoft Entra ID’ye AD Connect ile bağlıysa, sadece on-prem AD’yi temizlemek yeterli mi?
Benim cevabım net: Hayır, yeterli değil.
Çünkü AD Connect olan hibrit kimlik mimarilerinde on-prem Active Directory ile Microsoft 365 / Entra ID arasında doğrudan bir güven ilişkisi vardır. Eğer saldırgan on-prem AD’de yeterince yüksek yetki elde ettiyse, Entra ID tarafına pivot etmiş, kalıcılık mekanizması bırakmış veya kritik secret’ları ele geçirmiş olabilir. Bu durum okta ve benzeri ya da jump cloud gibi ürünler içinde geçerlidir, özetle local IDM ürünleri dışındaki diğer kimlik ürünlerine de odaklanmanız gerekli.
Bu nedenle böyle bir olayda sadece “AD’yi temizledik” demek bence eksik ve riskli bir yaklaşımdır. Ancak ekiplerin birden çok alanda uzmanlaşması zor, örnek BIG4TR grup şirketleri olarak biz bu tür müdahale gereken müşterilerimizde hem INFINITUM IT yani güvenlik şirketimiz, hem ITSTACK yani onprem Microsoft şirketimiz hem de UNIFYTECH yani cloud şirketimizin uzmanları ile birlikte eş zamanlı bir müdahalede bulunuyoruz. Bir güvenlik şirketinde bulut bilen uzman olamaz mı? Tabi ki olabilir ancak bir bulut uzmanın işi 3 ayda bir güncellenen bu tür platformları yakından takip etmek olduğu için şirketlerin bu şekilde uzmanlaşması her zaman daha kaliteli hizmet almanızı sağlar. Peki reklamlara ara verip konumuza geri dönelim :)
Böyle bir saldırı sonrasında ilk bakılması gereken yerlerden biri kesinlikle Azure AD Connect / Microsoft Entra Connect sunucusudur.
Bu sunucu, on-prem AD ile Entra ID arasındaki kimlik senkronizasyonunu sağladığı için saldırgan açısından çok değerli bir hedeftir. Eğer bu sunucuya erişim sağlandıysa, saldırgan şu bilgilere veya yetkilere ulaşmış olabilir:
- AD DS connector hesabı
- Entra ID connector hesabı
- Sync servis hesapları
- Password Hash Sync yapısı
- Pass-through Authentication agent bilgileri
- Seamless SSO yapılandırması
- Sertifika ve credential materyalleri
- Staging mode’da unutulmuş ikinci AD Connect sunucuları
Bu nedenle AD Connect sunucusu olay sonrası mutlaka detaylı incelenmeli, hatta mümkünse temiz bir sunucuya yeniden kurulmalıdır. En azından connector hesaplarının parolaları ve ilgili credential’lar rotate edilmelidir.
Entra ID Üzerindeki App Registration ve Secret’lar Kontrol Edilmeli
Bence en kritik başlıklardan biri de burası. Çünkü o karmaşada bu başlık genelde unutluyor, saldırganlar Microsoft 365 ve Entra ID tarafında kalıcılık sağlamak için kullanıcı hesabı yerine uygulama kimliklerini tercih edebilir. Çünkü uygulama secret’ları veya certificate credential’ları ele geçirildiğinde, saldırgan kullanıcı parolasına ihtiyaç duymadan API üzerinden erişim sağlayabilir.
Bu nedenle olay sonrası şu alanlar mutlaka kontrol edilmelidir:
- Yeni oluşturulan App Registration’lar
- Enterprise Applications altındaki şüpheli service principal’lar
- Yeni eklenen client secret’lar
- Yeni eklenen certificate credential’lar
- Uygulamalara verilen API permission’lar
- Admin consent verilmiş uygulamalar
- Uygulama owner’ları
- Uzun süreli veya süresi çok ileride biten secret’lar
- Publisher verified olmayan uygulamalar
Özellikle şu izinlere sahip uygulamalar ayrıca incelenmelidir:
- Directory.ReadWrite.All
- RoleManagement.ReadWrite.Directory
- Application.ReadWrite.All
- AppRoleAssignment.ReadWrite.All
- Mail.Read
- Mail.ReadWrite
- Mail.Send
- Files.Read.All
- Sites.FullControl.All
Global Admin ve Ayrıcalıklı Roller Yeniden İncelenmeli
On-prem AD tarafında ele geçirilen hesaplardan biri cloud admin yetkilerine sahipse, saldırgan Entra ID tarafında da yetki elde etmiş olabilir.
Bu nedenle aşağıdaki roller mutlaka incelenmelidir, bu tabi ki nispeten daha kolay tespit edilebilir, çünkü nasın onprem domain admins grubunu kontrol ediyorsak artık bulut üzerindeki gruplarıda kontrol etmek yavaş yavaş endüstri standartı olmaya başladı.
- Global Administrator
- Privileged Role Administrator
- Conditional Access Administrator
- Exchange Administrator
- SharePoint Administrator
- Application Administrator
- Cloud Application Administrator
- Security Administrator
- Intune Administrator
- User Administrator
- Directory Synchronization Accounts
Bu rollere sahip hesaplarda sadece parola değişikliği yeterli değildir. MFA methodları, registered device’lar, authentication method değişiklikleri ve PIM aktivasyonları da incelenmelidir.
Özellikle şu sorular sorulmalıdır:
- Son dönemde yeni bir MFA methodu eklenmiş mi?
- Şüpheli bir telefon, authenticator veya FIDO key tanımlanmış mı?
- Temporary Access Pass üretilmiş mi?
- Break-glass hesaplarında değişiklik var mı?
- PIM üzerinden beklenmeyen aktivasyon yapılmış mı?
AD FS Varsa Golden SAML Riski Dikkate Alınmalı
Eğer ortamda AD FS kullanılıyorsa risk seviyesi daha da artar. Bu genelde bizim banka, telekom, gsm, ödeme sistemleri, enerji sistemleri gibi müşterilerimizdeki aktif senaryolarda gördüğümüz bir konu. ADFS her zaman hassas bir konu olup uzmanlık gerektirir, özetle bu makaledeki her şeyi yapıp ADFS temizliği yapmasanız bile 3 ay sonra neden yine hacklendim diye gelebilirsiniz.
AD FS token-signing certificate ele geçirildiyse, saldırgan kullanıcı parolasına ihtiyaç duymadan geçersiz gibi görünmeyen token’lar üretebilir. Bu senaryo genellikle Golden SAML olarak bilinir.
Bu nedenle AD FS olan ortamlarda olay sonrası şu aksiyonlar kritik hale gelir:
- Token-signing certificate rotate edilmeli
- Token-decrypting certificate kontrol edilmeli
- Federation trust yeniden gözden geçirilmeli
- AD FS service account parolası değiştirilmeli
- AD FS ve WAP sunucuları temiz kabul edilmemeli
- Entra ID domain federation ayarları kontrol edilmeli
Kısacası AD FS varsa konu sadece AD temizliği değil, federation güven zincirinin yeniden kurulması meselesidir.
Seamless SSO ve PTA Agent’ları Unutulmamalı
Password Hash Sync dışında Seamless SSO veya Pass-through Authentication kullanan kurumlarda ek kontroller gerekir.
Özellikle:
- PTA agent kurulu sunucular
- Eski veya unutulmuş PTA agent’lar
- AZUREADSSOACC computer account
- Seamless SSO Kerberos key rotasyonu
kontrol edilmelidir.
Bu bileşenler kompromize edildiyse, saldırgan hibrit kimlik yapısında kalıcılık sağlayabilir.
Exchange Online Tarafı Ayrıca İncelenmeli
Microsoft 365 saldırılarında en çok gözden kaçan alanlardan biri Exchange Online’dır. Saldırganlar mailbox seviyesinde kalıcılık bırakabilir veya veri sızıntısı için kurallar tanımlayabilir.
Bu nedenle olay sonrası şu kontroller yapılmalıdır:
- Mailbox forwarding rule
- Inbox rule
- Transport rule
- Delegated mailbox permission
- FullAccess, SendAs, SendOnBehalf yetkileri
- eDiscovery ve Compliance rolleri
- Mail okuma izni olan OAuth uygulamaları
- Şüpheli mailbox login aktiviteleri
Özellikle kritik yönetici hesaplarının mailbox’ları ve finans, İK, hukuk gibi departmanların posta kutuları detaylı incelenmelidir.
Conditional Access Policy’leri Değiştirilmiş Olabilir
Saldırgan Entra ID tarafında kalıcılık sağlamak için sadece yeni hesap veya uygulama oluşturmak zorunda değildir. Mevcut güvenlik politikalarını zayıflatarak da kendisine alan açabilir.
Bu nedenle aşağıdaki ayarlar kontrol edilmelidir:
- Conditional Access policy değişiklikleri
- MFA istisnaları
- Trusted location değişiklikleri
- Legacy authentication durumu
- Authentication methods policy
- Security defaults
- External collaboration settings
- Cross-tenant access settings
- Guest user oluşturma ve davet geçmişi
- Intune enrollment ve device compliance ayarları
Özellikle Conditional Access policy’lerine eklenen küçük bir istisna, olay sonrasında saldırganın tekrar içeri girmesini sağlayabilir.
Audit Log ve Sign-in Log İncelemesi Şart
Olayın zaman çizelgesi çıkarılırken Entra ID audit log’ları ve sign-in log’ları mutlaka incelenmelidir.
Aranması gereken bazı olaylar
- Add service principal credentials
- Add app role assignment
- Consent to application
- Add member to role
- Update conditional access policy
- Add owner to application
- Add federated domain
- Set federation settings
- User registered security info
- Update user
- Add authentication method
- Mailbox forwarding enabled
- New-InboxRule
- Set-Mailbox
- New-TransportRule
Bu loglar sadece teknik inceleme için değil, saldırganın Entra ID tarafında kalıcılık bırakıp bırakmadığını anlamak için de kritiktir.
Benim Önerdiğim Olay Sonrası Kontrol Listesi
Böyle bir olayda biz ekip olarak aşağıdaki gibi bir kontrol listesi tutuyoruz, bunu mutlaka sizinde kontrol etmenizi öneririm;
- AD Connect sunucusunu temiz kabul etmeyin.
- Mümkünse AD Connect’i temiz bir sunucuya yeniden kurun.
- AD Connect connector hesaplarının parolalarını rotate edin.
- Tüm privileged Entra ID hesaplarının parolalarını değiştirin.
- Admin hesaplarındaki MFA methodlarını yeniden doğrulayın.
- Kritik App Registration secret ve certificate’larını rotate edin.
- Şüpheli Enterprise Application ve admin consent izinlerini temizleyin.
- AD FS varsa token-signing certificate ve federation trust’ı yeniden ele alın.
- PTA / Seamless SSO kullanıyorsanız agent ve Kerberos key kontrollerini yapın.
- Exchange Online tarafında forwarding, inbox rule ve delegation kontrollerini yapın.
- Conditional Access policy’lerini ve istisnaları inceleyin.
- Break-glass hesaplarını kontrol edin.
- PIM aktivasyon geçmişini inceleyin.
- Audit log ve sign-in log üzerinden saldırı zaman çizelgesini çıkarın.
- Olay tarihinden önce üretilmiş kritik secret’ları güvenilmez kabul edin.
AD ortamı hacklendiyse ve ortam Entra ID’ye AD Connect ile bağlıysa, Entra ID / Microsoft 365 tarafındaki secret’lar, app registration’lar, service principal’lar, admin roller, federation ayarları ve Exchange Online kalıcılık mekanizmaları mutlaka kontrol edilmeli; kritik olanlar sadece kontrol edilmemeli, rotate edilmelidir.
Umarım faydalı bir makale olmuştur, bir sonraki makalemizde görüşmek üzere.
