Site icon Baki ÇUBUK

Active Directory’yi Ele Geçirme Teknikleri Serisi – Bölüm 14: Microsoft Entra Connect’in Ele Geçirilmesi

bakicubuk

Merhaba

Önceki bölümde federasyon senaryosunda (AD FS) token imzalama sertifikasının ele geçirilmesini inceledik. Bu bölümde hibrit kimlik mimarisinin bir başka kritik bileşenine Microsoft Entra Connect’e (eski adıyla Azure AD Connect) odaklanıyoruz. Birçok organizasyon federasyon yerine, ya da federasyonla birlikte, kurum içi Active Directory kimliklerini buluta senkronize etmek için bu aracı kullanır. Bu araç, doğası gereği hem kurum içi Active Directory’ye hem de buluta yazma yetkisine sahip olduğu için, ele geçirildiğinde inanılmaz derecede güçlü bir saldırı yüzeyi haline gelir.

Microsoft Entra Connect’in Ele Geçirilmesi

Microsoft Entra Connect, kurum içi Active Directory’deki kullanıcı, grup ve diğer nesneleri buluta (Microsoft Entra ID) senkronize etmekle görevli bir sunucu bileşenidir. Bu senkronizasyonu gerçekleştirebilmek için, Entra Connect sunucusu üzerinde çalışan “senkronizasyon hizmeti hesabı” (varsayılan olarak AAD_ önekiyle başlayan bir yerel veya domain hesabı) tipik olarak Active Directory üzerinde Replicating Directory Changes ve Replicating Directory Changes All haklarına sahiptir yani DCSync yapabilecek yetkidedir (Bölüm 9’u hatırlayın). Bu, Entra Connect’in normal işleyişi için gereklidir, ama aynı zamanda bu sunucunun ele geçirilmesinin doğrudan bir DCSync saldırısına eşdeğer sonuçlar doğurabileceği anlamına gelir.

Daha da kritik olanı, Entra Connect sunucusunun hem kurum içi hem de bulut tarafında ayrıcalıklara sahip olmasıdır. Sunucu üzerinde yerel yönetici erişimi sağlayan bir saldırgan, senkronizasyon veritabanında (varsayılan olarak yerel bir SQL Server Express örneği, ADSync veritabanı) saklanan kimlik bilgilerini ele geçirebilir. Bu veritabanı, hem kurum içi AD’ye bağlanmak için kullanılan hesabın (genellikle yüksek ayrıcalıklı DCSync hakları olan bir hesap) hem de buluta bağlanmak için kullanılan bir hizmet hesabının (Microsoft Entra ID’de Directory Synchronization Accounts rolüne sahip, özel ve gizli bir rol normal yönetici rollerinde bile görünmeyen) kimlik bilgilerini DPAPI ile şifrelenmiş olarak içerir.

Bu kimlik bilgilerini şifreleyen DPAPI anahtarları da yine yerel makinede, ADSync hizmet hesabının erişebildiği bir konumda saklanır bu da yerel yönetici ayrıcalığına sahip bir saldırganın, açık kaynaklı araçlarla (örneğin AADInternals PowerShell modülü, ADSyncDecrypt gibi topluluk araçları) bu veritabanını okuyup şifresini çözebileceği anlamına gelir. Sonuç olarak saldırgan, hem kurum içi Active Directory’de DCSync yapabilecek bir hesabın hem de bulutta Directory Synchronization Accounts rolüne sahip ve bu rol MFA/Koşullu Erişim politikalarından genellikle muaf tutulduğu için bir hesabın kimlik bilgilerini ele geçirmiş olur.

Directory Synchronization Accounts rolünün özel bir tehlikesi, bu rolün Microsoft Entra ID’nin kendi denetim ve güvenlik arayüzlerinde normal bir yönetici rolü gibi görünmemesi, standart Koşullu Erişim politikalarının çoğu zaman bu hesaba uygulanmamasıdır (senkronizasyonun kesintisiz çalışabilmesi için tasarım gereği böyledir). Bu, saldırganın bu hesap üzerinden bulut dizinine yazma işlemleri yapabileceği, hatta bazı senaryolarda (yanlış yapılandırılmış “soft-match” veya “hard-match” ayarları ile) kurum içinden kontrol ettiği bir nesneyi bulutta ayrıcalıklı bir hesapla eşleştirerek dolaylı bir yetki yükseltmesi gerçekleştirebileceği anlamına gelir.

Microsoft Entra Connect’i Mitigasyon Etmek

Bu tekniği mitigasyon etmek için aşağıdaki güvenlik kontrolleri uygulanmalıdır:

Microsoft Entra Connect’i Tespit Etmek

Bu tekniğin tespiti, hem kurum içi hem de bulut tarafı günlüklerinin birlikte izlenmesini gerektirir.

Microsoft Entra Connect’in Ele Geçirilmesini Tespit Eden Olaylar

Kaynak Açıklama
Entra Connect Sunucu Güvenlik Günlükleri Sunucuya beklenmeyen bir kullanıcı veya zamanda yapılan oturum açmalar (Event ID 4624/4625); özellikle ADSync veritabanı dosyalarına erişen süreçlerin (Event ID 4663) izlenmesi.
Microsoft Entra ID Denetim Günlükleri Directory Synchronization Accounts rolüne sahip hesabın normal senkronizasyon penceresi dışında, beklenmeyen hacimde veya türde işlemler yapması.
Microsoft Entra ID Oturum Açma Günlükleri Senkronizasyon hesabının beklenmeyen bir IP adresinden veya konumdan (Entra Connect sunucusunun bilinen IP’si dışında) oturum açması.
Kurum İçi DCSync Tespiti (Event 4662) Entra Connect’in senkronizasyon hesabından gelen replikasyon isteklerinin normal senkronizasyon aralıklarıyla (varsayılan 30 dakika) tutarlı olup olmadığının izlenmesi; anormal sıklıkta veya farklı bir kaynaktan gelen istekler şüphelidir.
ADSync Veritabanı Erişimi Yerel SQL Server Express örneğine (ADSync veritabanı) beklenmeyen bağlantılar veya sorgular; özellikle mms_server_configuration gibi kimlik bilgisi içeren tablolara erişim.

Lab Uygulaması

Bu tekniği kendi hibrit kimlik lab ortamımızda (kurulumunu ayrı bir yazı dizisinde detaylandırdığımız bakicubuk.tech ormanı etki alanı denetleyicisi W25DC, Windows Server 2025 üzerinde çalışan Entra Connect Sync sunucusu W25ENTRA) uçtan uca doğruladık. Amacımız iki soruyu netleştirmekti:

  1. Yukarıda anlatılan kimlik bilgisi çıkarma tekniği güncel bir Entra Connect Sync kurulumunda hala işe yarıyor mu?
  2. Application-Based Authentication gerçekten bulut tarafını koruyor mu?

    1. Adım: Eski yöntemin artık geçersiz olduğunu doğrulama

    Serinin önceki bölümlerinde bir cmdlet’i var sayıp kullanmadan önce doğrulamamak bize pahalıya patlamıştı; bu kez tersini yaptık. Popüler AADInternals PowerShell modülünü W25ENTRA’ya kurup, genellikle bu teknik için anılan Get-AADIntSyncCredentials cmdlet’inin gerçekten var olup olmadığını kontrol ettik:

Install-Module AADInternals -Force -Scope AllUsers
Import-Module AADInternals -Force
Get-Command -Module AADInternals -Name "*Sync*"
Get-Command -Module AADInternals -Name "*Credential*"
Get-Command -Module AADInternals | Select-Object Name | Sort-Object Name

Sonuç: kurulu sürümde (v0.9.8) böyle bir cmdlet yok. Araştırmamız bunun tesadüf olmadığını gösterdi bu cmdlet, Entra Connect’in eski, parola tabanlı bulut bağlayıcı hesabını hedefliyordu; Microsoft’un Application-Based Authentication’a geçişiyle bu hesap türü ortadan kalktığı için cmdlet de işlevsiz kalıp modülden kaldırılmış.

2. Adım: Güncel araçla kimlik bilgisi çıkarma

Bunun yerine, hâlâ bakımı yapılan ve güncel duruma uyarlanmış Dirk-jan Mollema’nın adconnectdump araç seti‘ni kullandık spesifik olarak ADSyncDecrypt bileşenini. Bu araç, ADSync veritabanındaki her bağlayıcının (hem kurum içi AD DS hem de bulut Entra ID bağlayıcısının) yapılandırmasını okuyup DPAPI ile çözüyor. W25ENTRA’da (yönetici olarak) kaynak koddan derleyip çalıştırdık:

& "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /target:exe /out:ADSyncDecrypt.exe /platform:x64 `
  /reference:"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Data.dll" /reference:"Lib\mcrypt.dll" `
  Program.cs Properties\AssemblyInfo.cs

.\ADSyncDecrypt.exe

Çıktı, iki ayrı bağlayıcının yapılandırmasını gösterdi:

Beklenmedik ama önemli bir bulgu: Bu adımı ilk denememizde, derlediğimiz .exe çalıştırılır çalıştırılmaz Windows Defender tarafından tespit edilip karantinaya alındı hatta bir dosya yolu hariç tutması eklememize rağmen, davranış tabanlı tespit yine devreye girip süreci sonlandırdı. Get-MpThreat çıktısı, Defender’ın bu spesifik aracı hem statik imzayla hem de davranışsal olarak beş ayrı tespit kuralıyla tanıdığını gösterdi:

Tespit Adı Tür Çalıştı mı?
HackTool:MSIL/ADSync.B Statik imza Evet
HackTool:MSIL/ADSyncDecrypt.B Statik imza Evet
Backdoor:Win32/AdSyncDump!EntraConnect Statik imza Hayır (engellendi)
Backdoor:MSIL/SuspAdsyncBin.D Statik imza Hayır (engellendi)
Behavior:Win32/SuspAdsyncProcessTree.A!EntraConnect Davranış tabanlı Evet

Bu, seri boyunca birkaç kez karşımıza çıkan bir örüntüyü doğruluyor: modern uç nokta korumaları artık genel “şüpheli davranış” sezgiselliğinin ötesinde, bu tür kimlik bilgisi çıkarma araçlarını isimle ve amaçla tanıyacak kadar olgunlaşmış durumda. (Lab amacıyla devam edebilmek için Add-MpPreference -ExclusionPath ve -ExclusionProcess ile hem dosya yolunu hem süreci hariç tutmamız gerekti üretim ortamında bu tür bir hariç tutma asla yapılmamalıdır.)

3. Adım: Çıkarılan kimlik bilgisiyle DCSync doğrulaması

Son olarak, çıkarılan MSOL_6f08519937c9 kimlik bilgisinin gerçekten DCSync yapabildiğini doğrulamak için, bu hesabın kimliğiyle ağ-only bir oturum açıp Mimikatz çalıştırdık. Seri boyunca uyguladığımız “gerçek ama zararsız hedef” prensibi gereği, hedef olarak krbtgt veya Administrator yerine zaten sync edilmiş sıradan bir test kullanıcısını seçtik:

runas /netonly /user:BAKICUBUK.TECH\MSOL_6f08519937c9 powershell.exe

Açılan oturumda:

mimikatz # privilege::debug
mimikatz # lsadump::dcsync /domain:bakicubuk.tech /user:nihat.cubuk

Sonuç, hedef kullanıcının NTLM hash’ini, LM hash’ini, Kerberos anahtarlarını (AES256/AES128/RC4) ve WDigest kimlik bilgilerini eksiksiz döndürdü MSOL_ hesabının Replicating Directory Changes ve Replicating Directory Changes All haklarına gerçekten sahip olduğunu ve bu hakların Entra Connect sunucusunun ele geçirilmesiyle doğrudan kullanılabilir olduğunu kanıtlıyor.

Özet: Bu lab, tekniğin iki ayağını da somut olarak gösterdi. Bulut tarafı gerçekten sertleşmiş artık çıkarılacak kullanılabilir bir bulut parolası yok ve saldırı araçlarının kendisi modern EDR tarafından isimle yakalanıyor. Ama kurum içi ayak (DCSync-yetkili MSOL_ hesabının ele geçirilmesi) aynen geçerliliğini koruyor; bu yüzden Entra Connect sunucusunu Tier 0 varlık olarak ele almak, bu bölümdeki mitigasyon listesinde de vurgulandığı gibi, hâlâ vazgeçilmez.

Uyumluluk ve Çerçeve Eşlemesi Tablosu

Çerçeve İlgili Kontrol/Madde
PCI DSS Gereksinim 7.1 (Erişim kısıtlaması), Gereksinim 8.2 (Güçlü kimlik doğrulama)
HIPAA 164.312(a)(1) – Erişim Kontrolü, 164.312(d) – Kimlik Doğrulama
ISO 27001 A.9.2 (Kullanıcı Erişim Yönetimi), A.9.4 (Sistem ve Uygulama Erişim Kontrolü)
KVKK Madde 12 – Veri Güvenliğine İlişkin Yükümlülükler
TCMB Bilgi Sistemleri Yönetimi Tebliğ – Erişim ve Yetkilendirme Kontrolleri
NIST CSF PR.AC-1 (Kimlik ve kimlik bilgisi yönetimi), PR.AC-7 (Kimlik doğrulama mekanizmaları)
CIS Controls CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi)

MITRE ATT&CK: T1114 (Email Collection – ilişkili taktikler), T1078.004 (Valid Accounts: Cloud Accounts), T1552.001 (Unsecured Credentials: Credentials In Files)

Sonuç

Microsoft Entra Connect, kurum içi ve bulut dünyaları arasındaki köprü olma işlevi nedeniyle, ele geçirildiğinde her iki tarafta da ayrıcalık sağlayan benzersiz bir hedef haline geliyor. Bu da onu, klasik Active Directory sertleştirme kontrolleri kadar bulut tarafı izleme ve erişim kontrollerini de gerektiren, hibrit ortamlara özgü bir risk noktası yapıyor.

Serinin bir sonraki bölümünde, iki domain arasındaki güven ilişkilerinin özellikle tek yönlü (one-way) trust’ların nasıl istismar edilebileceğini inceleyeceğiz.

Exit mobile version