ACTIVE DIRECTORY SALDIRILARI
KERBEROS NASIL ÇALIŞIR
KERBEROS NEDİR
Kerberos bir kimlik doğrulama protokolüdür. NTLM den daha güvenli olduğu için günümüzde en sık kullanılan protokoldür.
KERBEROS NASIL ÇALIŞIR
Kerberos bir bilet sistemi kullanarak doğrulamalar gerçekleştirir. Adını Yunan mitolojisinde bulunan yeraltı kapısının bekçisi üç başlı köpek Cerberus’ dan alır. Bu köpekten adını almasının sebebi, kerberos’ un üç adet ana doğrulama bileşeni olması ve “kapı bekçisi” olmasından kaynaklıdır.
KERBEROS TERİMLERİ
Kerberos doğrulaması sırasında bir çok terim kullanılır, bu terimleri anlatımım sırasında kullanacağım için önceden tek tek açıklamalarını yapacağım.
Kerberosun bahsettiğim “üç başlı köpek” benzetmesi, Kerberosun içerisinde üç ana doğrulama bileşeni bulundurmasındandır. Bunlar; Authentication Service(AS), Ticket Granting Service(TGS) ve Database(DB) dir.
Şimdi bu terimleri daha ayrıntılı ve yakından inceleyelim;
KDC: Key Distribution Center anlamına gelir. Bu yapı AS ve TGS’yi içerisinde barındırır, Kerberos içerisinde Authentication ve Autorization işlemlerinden sorumludur.
AS: KDC içerisinde authentication adımını gerçekleştirir. Bir domain üzerinde girilen credential bilgilerini doğrulayarak domain üzerinde doğrulanmış kullanıcı olmamamızı sağlar, bir session key ve TGT verir.
TGS: Ticket Granting Service anlamına gelir ve KDC’nin ikinci bileşenidir. Authenticated kullanıcılara bir Autorization işlemi gerçekleştirir. Bu işlem alınan “bilet isteme bileti” yani TGT ile sağlanır ve bir TGS ticket elde edilir. TGS bileti bağlanmak istediğimiz sunucuya gitmek için gerekli bir bilettir. TGT olmadan TGS’ in kapısı bile çalınamaz!
TGT: Ticket Granting Ticket(Bilet isteme bileti), AS ile authentication işlemi sırasında bize verilen, TGS’den TGS ticket almamızı sağlayan bilettir.
PAC: Biletin içerisinde istemci bilgilerinin bulunduğu kısımdır. İstemcinin SID(security identifier numarası) ve kullanıcı adı gibi bilgileri tutar. PAC, TGS biletinin içine yazılır ve kullanıcıya gönderilirken servis key ve KDC key ile imzalanır.
SPN: Service Principal Name, servisin kimlik numarasıdır ve domain üzerinde benzersiz olarak tanımlanmasını sağlar, bunu kullanıcıları benzersiz olarak tanımlayan SID’ ye benzetebiliriz.
SESSION KEY: Session key, authentication ve autorization adımları olmak üzere iki kere alınır. Bu iki keyin birbirine karıştırılmaması gerekir. AS üzerinden alınan session key, domain üzerinde doğrulanmış bir kullanıcı olduğumuzu belirtirken, TGS üzerinden alınan session key, istediğimiz servis üzerinde oturum açmamıza olanak tanır.
SERVICE KEY: PAC’ i imzalar ve bu key ile encrypt edilen veriler(servise ait veriler) servis tarafından okunabilir.
CLIENT KEY: Client’a ait verileri encrypt eder. Client’ın kendine ait verileri okumasını sağlar.
KDC KEY: PAC’i imzalar ve bu imza yardımı ile serverın pac’i doğrulamasını sağlar. Aynı zamanda TGT’ yi encrypt eder.
LSASS: Domain controller üzerinde KDC ile beraber çalışır, Kerberos biletlerini ve credentialları yöneten bir servistir.
KERBEROS ÇALIŞMA ADIMLARI
Oluşturduğum resmin adımlarını tek tek inceleyelim;
- Girdiğim kullanıcı adı ve şifre ile Authentication service ’ e giderek, bir kimlik doğrulaması ile TGT talebinde bulunduğum kısımdır.
- AS’nin bu verdiğim verileri veritabanından kontrol ederek, doğru olması koşulunda, KDC’nin bana bir TGT + SESSION KEY verdiği kısımdır. Bu session key servis için değil, domain üzerinde doğrulandığımı göstermek için aldığım session key dir.
- Aldığım TGT ,SESSION KEY ve kullanmak istediğim servisin SPN değeri ile TGS’ ye giderim ve bir Servis ticket(TGS bileti) talep ederim.
- TGS(Ticket Granting Service), benim AS üzerinden giriş bilgilerimi doğrulayarak aldığım session key’in, verdiğim SPN’e sahip servisi kullanma yetkim olup olmadığını veritabanından kontrol eder. Eğer yetkim var ise bana server üzerinde kullanmam için bir session key ve TGS bileti verir. Bu TGS bileti kullanacağım servisin hashli olacak şekilde şifresini de barındırır. Eğer burası kafa karıştırıcı olduysa şu şekilde akılda kalabilir; Ben, “sergen” adında bir kullanıcı ile oturum açtım ve bu kullanıcı domain user yetkisinde. Domain user ne yetkileri var o kontrol edilir.
- TGS biletini ve SESSION KEY’ i servisin çalıştığı server üzerinde kullanacağım ve bir istek göndereceğim. TGS biletinin üzerinde bulunan PAC kısmını iki değerle imzalamıştık, bunlardan ilki server key yani sunucu anahtarıydı. Sunucu bu kısmı çözerek Server key ile imzalanan kısmı kontrol eder.
- Sunucu kendi server key imzasını kontrol ettikten sonra KDC ye gönderir ve KDC ise KDC key ile imzalanan imzayı çözerek PAC değerini kontrol eder.
- Eğer KDC key ile imzalanan değer doğru ise sunucuya bildirir.
- Sunucu, servisi kullanabileceğini client(sergen)’a söyler.
NOT: Servislerin de hesapları vardır. Bu hesaplar, doğrulama yapar ve o servisi kullanmamızı sağlarlar. TGS bileti üzerinde servislerin şifreleri hashli olarak gönderilir. Örneğin bir sql-service hesabı, sql server ‘a erişebilir ve yönetebilir.
KERBEROS SALDIRILARI
Kerberosun nasıl çalıştığını anladığımıza göre saldırı yöntemlerine geçebiliriz.
USER ENUMERATION
Domain enumeration için powershell ve çeşitli toollar kullanılır fakat bazen domain çok karışık olabilir. Böyle durumlarda bizim için bu powershell komutlarını otomatik olarak çalıştırıp topladığı bilgileri bir dosya haline getiren SharpHound aracını hedef sistemde çalıştırabilir ve bu dosyaları bize görsel arayüz ile gösteren BloodHound aracını kullanabiliriz. BloodHound neo4j’yi veritabanı olarak kullanır, bundan dolayı onu da yüklememiz gerekir.
Manuel olarak Powershell ile yapmak için aşağıda bulunan siteden komutlara bakabilirsiniz.
Powershell ile domain enumeration yapmak için powershell’e, github üzerinden powerview.ps1 modülü indirerek import etmeliyiz.
BLOODHOUND
sudo apt install -y bloodhound
sudo apt install -y neo4j
Neo4j yüklendikten sonra başlatmamız ve bize verilen port üzerinde daha sonra bloodhound’a giriş yaparken kullanacağımız veritabanı şifresini belirlememiz gerekiyor.
İlk giriş şifresi neo4ji , kullanıcı adı neo4j dir.
SCP bir SSH komutudur ve ssh üzerinden dosya kopyalamayı sağlar. Burada indirdiğim SharpHound.exe dosyamı hedefte çalıştırmak için gönderiyorum.
SharpHound çalıştırarak bizim powershell ile manuel yaptığımız komutları otomatik yapmasını ve json dosyaları oluşturmasını sağlıyorum.
SharpHound bizim için json dosyalarını zip şeklinde oluşturdu ve bunları scp ile ana bilgisayarıma analiz etmek için alıyorum. Aldığım zip dosyasını bloodhound içine sürükleyerek upload etmem gerekiyor.
Menü üzerinde bulunan filtrelemeleri kullanarak bize bir görselleştirme ile bunları göstermesini talep edebiliriz.
KERBRUTE PASSWORD SPRAY , USERENUM
Domain üzerinde bulunan kullanıcıları tespit etmek için bir wordlist vererek Kerbrute aracını kullanabilirim. Kerbrute aracının password spray gibi başka özellikleri de bulunur.
Userenum için;
./kerbrute_linux_amd64 userenum -d controller — dc <ip-address> <userlist> -v
Password spray için;
./kerbrute_linux_amd64 passwordspray -d controller — dc <ip-address> <userlist> <password > -v
AS-REP(Pre authentication)
Pre authentication domain üzerinde bulunan hesaplara AS request yapmadan doğrulama yapmasını sağlar. Bu özellik aktif edilirse pre authentication gerekmez. Eğer doğrulama gerekmez ise yukarıda vermiş olduğum adımları gösteren resmin üzerinde bulunan ilk adım atlanır ve bu pre authentication gerektirmeyen kullanıcılar domain üzerinde herhangi bir servise TGT bileti talep edilebilir. Bu işleme AS-REP saldırısı denir. Eğer domain üzerinde bunu aktif etmiş bir kullanıcı var ise onun ismi ile gidilip herhangi bir servise bilet almak için TGT talebinde bulunulabilir.
NOT: Bu özelliğin bazı durumlarda açılmasının sebebi pre authentication failed hatasıdır.
Bu zafiyetin sömrülmesinde Rubeus aracı, Kerbrute ve Impacket aracının GetNPUsers.py modülü kullanılabilir. Rubeus çok yönlü bir araçtır ve Post explotation kısmında kullanılır. Rubeus aracını kullanmamız için hedef sistemin içerisine kurmamız gerekir.
RUBEUS
./rubeus.exe asreproast
Rebeus aracını verdiğim linkten indirip, compile edip, exe haline getirdikten sonra yukarıda yaptığım gibi scp komutu ile hedef bilgisayara aktarabilirsiniz.
IMPACKET
İmpacket daha önce NTLM konusunda anlattığım ve birçok modülü bulunan bir araçtır. Sistem üzerine kurulu olması gerekmez fakat bu işlemi yapacak GetNPUsers modülü için kullanıcı adı listesi gerektirir.
python3 GetNPUsers.py <domain FQDN> -dc-ip <dc-ip> -usersfile <userfile> -no-pass
Bu iki uygulamayı da kullandık ve pre-authentication adımını atlayarak bir AS-REP paketi aldık, bu paket içerisinde almış olduğum kullanıcının parola bilgileri hashli olarak tutulduğu için eğer hashi çözersem kullanıcı şifresine erişebilirim. Bu işlem için ise hashcat kullanacağım.
TICKET HARVESTING
Ticket harvesting işlemi için artık bilgisayara sızmış ve domain üzerinde bir kullanıcı edinmiş olmam gerekir. Bu işlem daha önce KDC aktarılmış biletlerin dump edilmesi ile gerçekleşir. Bu saldırıyı Rubeus aracı ile gerçekleştirebiliriz Yakalanan biletler Rubeus aracının cache kısmında tutulur daha sonra brute force, password spray, pass the ticket saldırıları gibi saldırılarda kullanılabilir.
Bu aldığımız biletler içerisinde encode kullanıcı adları bulunduğu için password spray ve brute force deneyelim.
./Rubeus.exe harvest /interval:<kaç saniyede bir getirsin>
KERBEROASTING
Kerberoasting saldırı TGS biletleri üzerinden gerçekleştirilen bir saldırı türüdür. Bu saldırıyı gerçekleştireceğimizde artık Kerberosun birinci ve ikinci adımını geçmiş olmamız gerekiyor. Doğrulanmış bir kullanıcı hesabına sahip olmamız gerekir. Kerberos adımlarının üçüncü ve dördüncü kısmında işlem yapacağız. Bir TGS bileti talep edeceğiz ve aldığımız TGS bileti üzerinde hashli olarak gönderilen servis hesabı parolasına erişeceğiz. Bu parolanın hash değerini kırmayı deneyebiliriz, eğer kırarsak servis hesabının şifresine ulaşırız.
Bu işlemleri Rubeus veya Impacket aracının GetUserSPNs.py modülü ile gerçekleştirebilirim.
./Rubeus.exe kerberoast
python3 GetUserSPNs.py -dc-ip <dc ip-address> <domain/username:password>
PASS THE TICKET SALDIRILARI
Daha önce NTLM konusunda anlattığım PtH saldırıları gibi bu saldırı şifreler yerine biletleri kullanır.
Bu saldırı için mimikatz aracını kullanabiliriz. Bu araç LSASS üzerinde bulunan Kerberos biletlerini dump ederek PtT saldırılarında kullanmamızı sağlar.
Dump ettiğimiz biletleri “.kirbi” uzantılı olarak kaydetmek için mimikatz üzerinde şu komutu kullanabiliriz;
sekurlsa::tickets /export
Daha sonra oluşan .kirbi uzantılı biletlerden, ptt saldırı için kullanmak istediğimizin ismini kopyalayıp şu şekilde kullanabiliriz;
kerberos::ptt <bilet-ismi.kirbi>
bileti kullandığımızı teyit etmek amacı ile “klist” komutunu çalıştırarak kullandığımız biletleri görebiliriz.
NOT: mimikatz çok yönlü bir araçtır ve sekurlsa’in yanı sıra lsadump vs. gibi komutları bulunur. Bunlar NTDS , SAM gibi veritabanlarından LSA gibi belleklerden verileri dump etmemizi sağlar.
IPV6 DNS TAKEOVER
SLAAC(Stateless Address Auto Configuration): Bu yapı clientların kendi kendine Ipv6 adresi alarak bir DHCPv6 sunucusuna ihtiyaç duymamasını sağlar.
Stateful Address Configuration: RA paketindeki preferix ile bir ipv6 adresi yaratmaktansa, hostlar dhcp6 üzerinden ipv6 adresi almaya itilir.
DNS Takeover saldırısı, LLMNR zehirlenmesine benzer. Burada mitm6 adında kullanılan araç sahte bir sunucu olarak belirtilen domain üzerinde broadcast ile gelen DHCPv6 paketlerini yanıtlamaya çalışır. mitm6 önce bir RA(Router Advertisement) paketini hostlara gönderir. Bu paket bir Router cihazın kendini ağ üzerinde tanıtmasını sağlamakla beraber aynı zamanda Ipv6 adresinin ve DNS adreslerinin nasıl alacağını client’a bildiren bir konfigürasyon içeriği sunar. Bu paketler içerisinde doğru bayrakları 1 olarak set eder ve istemcilere, dhcpv6 sunucusu üzerinden ipv6 ve DNS bilgilerini almalarını söyler. Daha sonra sahte DHCPv6 sunucusu olarak isteklere cevap verir ve DNS spoofing yaparak saldırganın IP adresi üzerine yönlendirir.
Bunlardan sonra ntlmrelayx aracı kullanılarak WPAD protokolü spoof edilir. Bu proxy bilgilerinin sağlandığı bir sunucudur ve bu bilgileri wpad.dat ile client cihazlara gönderir. ntlmrelayx ile bu dosya spoof edilerek karşıya gönderilir ve proxy bilgileri değiştirilmiş olur. Daha sonra tüm trafik saldırgan üzerinden geçmeye başlar. Bu sırada saldırgan proxy için ntlm doğrulaması da ister ve bunu ntlmrelayx aracı ile relay ederek yeni kullanıcı oluşturma, shell alma, domain bilgilerini toplama gibi birçok saldırı yapılabilir.
Yukarıda kullanılan -i parametresi bir shell istediğimi belirtir. Bunun sonucunda 127.0.0.1:11000 üzerinde benim için bir shell açıldığını görebiliriz. Bu shell’e bağlanmak için nc aracını kullanabiliriz.
GOLDEN TICKET && SILVER TICKET SALDIRILARI
Bu saldırı türü bizim kendi biletlerimizi oluşturarak yetkimiz bulunmayan yerlere erişmemizi sağlar.
Golden Ticket: Adından da anlaşılacağı gibi bir altın bilettir ve elde edildiği taktirde tüm servislere erişim hakkı tanır.
Silver Ticket: Silver ticket belirli bir servise erişim sağlamamızı sağlar.
Mimikatz aracında lsadump switchi ile hesap bilgilerine erişebiliriz.
lsadump::lsa /patch
Silver Ticket oluşturma
Silver ticket oluşturma işlemini kısaca örnekler ile anlatayım. Biz sergen kullanıcısıyız fakat SQL sunucusuna erişimimiz bulunmuyor. Eğer ben mimikatz aracı ile LSA, NTDS gibi depolamalardan SQL service hesabının bilgilerini ele geçirebilirsem o bilgiler ile kendi TGS biletimi oluşturabilirim.
kerberos::golden /id <service-id> /rc4:<NTLM/RC4 hash> /domain:<domain-FQDN> /sid:<sid> /user:<kullanıcı(op> /service:<service-name>
NOT:Golden ticket ile silver ticket arasında ki fark birinde krbtgt diğerinde ise service ismini kullanıyor olmamız. kerberos::silver diye bir şey yoktur. Bilet oluşturmak için golden kullanılır.
Golden Ticket oluşturma
Golden Ticket ise krbtgt servis hesabının bilgilerini ele geçirerek kopyalamayı ve kullanmayı sağlayan, oturum açmamıza yarayan bir kerberos bileti oluşturmayı hedefler. Bu hesap KDC üzerinde işlem yapmaya yetkilidir ve bu sayede tüm sunuculara ve servislere erişimimiz olur. Bu saldırı Domain admin yetkileri gerektirir.
kerberos::golden /id:<kullanıcı rid> /krbtgt:<NTLM/RC4 hash> /domain:<domain-FQDN> /sid<sid> /user<kullanıcı adı>
Golden ticket ve Silver ticket için kullanılan SID kısmı aslında Domain’nin SID’dir. Aşağıda ki kullanımına bakarsak zaten sonunda herhangi bir RID yazmadığını göreceksiniz yani bir kullanıcıyı veya grubu temsil etmiyor bu SID.
Örnek sergen kullanıcısının RID kısmı 101 olsaydı ve SID’i 123456789-123456789 olan bir Domain üzerinde bulunsaydı, sergen kullanıcısının SID’si şu şekilde görünürdü 123456789–123456789–101, son kısım RID’i temsil eder.
NOT: Bu iki bileti de oluştururken, LSA üzerinden dump ettiğimiz bilgileri kullanarak kendi yeni biletimizi oluştururuz. Örneğin biletimin adı sergenbilet ama dump ettiğim krbtgt’nin Service Key kısmının NTLM hashini ve bu dump ettiğimiz hesap bilgilerini hangi Domainin SID’si üzerinde kullanarak sanki benim oluşturduğum sergenbilet’i bir krbtgt biletiymiş gibi göstereceğimi belirtirim . Bu oluşturduğum bilet PtT saldırısında kullanılabilir.
Bu işlem Rubeus aracı ile de yapılabilir.
Kerberos ve saldırı yöntemleri karışık olduğundan dolayı yazıyı birkaç kere okumak ve bu konu hakkında daha fazla araştırma yapmak gerekebilir.
NOT: Altın bilet bir TGT, Gümüş bilet ise bir TGS’dir.
PASS THE CERTIFICATE
Şimdi bir AD üzerinde tam yetkili kullanıcı olduğumuzu varsayalım. Her şeye erişimimiz bulunuyor fakat kalıcılığı sağlamamız lazım, yukarıda kullandığımız bilet oluşturma ve diğer yöntemler bunu sağlıyor ama bu yöntemler mavi ekip tarafından şifreler değiştirilerek ve biletler silinerek engellenebilir. Unutmayın sertifikalar bazı izinlere sahiptir ve bu izinler yanlış verilirse ve kullanılırsa sömürülebilir. Aşağıdaki örnekte bulduğumuz sertfika da kimlik doğrulama izinleri verilmiş ve sertfikanın sahibi Administrator kullanıcısı, yani User Principal Name’i Administrator olarak verilmiş anlamına geliyor.
PKI: Public Key Infrastructure, sertifikaların ve Public Keylerin şifrelenmesini yöneten bir sistemdir.
AD CS: Active Directory üzerinde çalışan PKI uygulamasıdır.
CA: Certificate Authority, sertifikayı imzalayan otorite.
CSR: Certificate Siging Request, içerisinde kullanıcının public key gibi bilgileri bulunan, CA’ dan sertifikanın imzalanmasını istemek için kullanılan istektir.
Engellenemeyecek ve geri dönüşü olmayan bir yöntemden bahsedeceğiz. Bu yöntem çok tehlikeli bir yoldur ve eğer sızma testi sırasında onay almadıysanız, direk olarak değil simülasyon olarak gerçekleştirmeniz gerekir.
Bu teknikte kullanacağımız şeyler sertifikalar olacak. Domain üzerinde bu sertifikaların yönetildiği bir CS(Certificate Service) bulunur, bu service AD üzerinde certifica işlemlerini yönetir. Senaryomuz gereği tam yetkilerimiz olduğu için sertifikaları mimikatz aracı ile dump edeceğiz ve elimizde kimlerin sertifikaları var bakacağız. Bu işleme geçmeden önce biraz sertifikalar hakkında konuşacağız.
Sertifikalar kerberos doğrulamasında ek bir güvenlik önlemi olarak kullanılır. Sertifikaları ele geçirmemizde ki asıl amaç yukarıda anlattığım kerberos doğrulamasında ki birinci adım diyebiliriz. Bu olay aslında bizim ile AS arasındaki iletişimi ilgilendiriyor. Eğer yetkili bir sertifika bulup onu daha düşük yetkili bir kullanıcıda yeni bir sertifika oluşturmak için kullanırsak, yetkili sertifikayı taklit edip kendi yetkisiz kullanıcımıza yeni bir yetkili sertifikası oluşturabiliriz. Bunu yaptıktan sonra artık bir Domain Admin gibi TGT isteyebilir ve daha sonra bu TGT’yi istediğimiz servise erişmemizi sağlayan bir TGS almak için kullanabiliriz, çünkü bu TGT aslında KDC üzerinden Domain Admin özellikli bir sertifikayı taklit ederek oluşturulan bir sertifika ile alındı.
Crypto ile Certifica Store üzerinden dump ettiğim sertifikalardan, bizim kullanmamız gereken za-THMDC-CA.pfx olandır. Bu sertifikayı önce kendi kali makinama oradan ise başka bir bilgisayara kopyaladım. Bu sertifikalar dump edilirken şifre oluşturulması gerekir ve mimikatz bunu kendi adı olarak “mimikatz” yapar.
Kopyaladığım diğer bilgisayarda ForgeCert toolu ile kendime yeni sertifika yarattım. Aynı mimikatz’ın dump ederken yaptığı gibi bende kendime yeni bir sertifika oluştururken şifre vermeliyim.
Yukarıda yarattığım sertifika ile Rubeus aracını kullanarak KDC’den bir TGT talep ettim.
Bu oluşturduğumuz .kirbi uzantılı TGT biletini daha yukarıda anlattığım gibi mimikatz kullanarak PTT saldırılarında kullanabilirsiniz.
NOT:Bu saldırının sonuçlarının temizlenemiyor olmasının sebebi, oluşturulan sertifikanın normal yollardan değil ForgeCert ile oluşturulması ve bunu mavi takım üyelerinin diğer sertifikaların yanında görüntüleyememesidir. Bundan kurtulmanın tek yolu tüm Sertifika sunucusunu sıfırlamaktır fakat bu işlem tüm domain üzerinde bulunan sertifikaları kaldırmak demektir.
SKELETON KEY
Skeleton key LSASS belleğine bir rc4 ile encrypt edilmiş veri kaydetmemiz ile domain üzerinde authentication yapan tüm kullanıcıların şifrelerinin mimikatz olmasını sağlar. Bu işlemi mimikatz aracı ile gerçekleştireceğiz. NOT: Domain controller üzerinde yapılır.
misc::skeleton
SID HISTORY INJECTION
SID geçmişi birden çok AD arasında geçiş yaparken kullanıcının bir problem yaşamadan bu işlemi gerçekleştirmesini amaçlar. Eğer bir kullanıcının SID geçmişine istediğimiz bir SID yazabiliyorsak o zaman işler karışır.
Get-ADUser <kullanıcı> -properties sidhistory,memberof
Bir kullanıcının SID geçmişini yukarıdaki şekilde powershell üzerinden sorgulayabiliriz.
Gördüğümüz gibi boş. Şimdi burayı doldurmak istediğimiz SID’yi bulalım. Domain Admin grubunun SID kısmını buraya ekleyebiliriz, böylece kullanıcıyı Domain Admin yetkilerine yükseltmiş ve Domain Admin olan bir arka kapı oluşturmuş oluruz.
Get-ADGroup “Domain Admins”
Domain admin grubunun SID kısmını kopyaladık şimdi sıra bunu düşük yetkili kullanıcımızın SID History kısmına eklemekte. Bu işlem için DSInternals adı verilen bir araç kullanacağız fakat farklı araçlarda deneyebilirsiniz, unutmayın bu işlem aslında Domain’nin veritabanı olan NTDS üzerinde değişiklikler yapmaktan geçiyor.
İlk olarak ntds servisini üzerinde işlem yapmak için durduruyoruz.
Stop-Service -Name ntds -f
Daha sonra indirip import ettiğimiz powershell modülünü çalıştırarak SID history injection yapıyoruz.
Add-ADDBSidHistory -SamAccountName ‘<Eklemek istedigimiz kullanıcı>’ -SidHistory ‘<Eklemek istedigimiz SID>’ -DatabasePath C:\Windows\NTDS\ntds.dit
Ve son olarak ntds servisini tekrardan başlatıyoruz.
Start-Service -Name ntds
Yukarda da gördüğümüz gibi artık SID history kısmı artık dolu.
KERBEROS CONSTRAINED && UNSCONTRAINED DELEGATION
Delegasyon kısaca bir kullanıcının veya grubun yetkilerinin yetmemesine rağman özel izinler ile o yetklileri kullanabilmesi için Microsoft’un kullanıcılar ve bilgisayarların özellikler kısmına eklediği bir özelliktir.
Kerberos delegasyonu aktif olan servis hesapları, kendi TGT’si ile başka bir kullanıcı adına veya servise TGS isteyebilir. Normal koşullarda bir kullanıcı kendi TGT’si ile kendi hesabını doğrulayacağı için sadece kendi için bir TGS isteyebilir, fakat delegasyon sayesinde kendi TGT’si ile erişimi olan servislere başka bir kullanıcı adına TGS isteyebilir. Bu işlem yetkisi olmayan bir kullanıcının yetkisi olan bir kullanıcı tarafından TGS’e sahip olması sebebiyle, yetkisiz erişimlere sebep olabilir. Bu işlemlerin yapılmasını sağlayan Kerberosun iki özelliği olan S4U ve S4UProxy’dir.
Constrained: Kısıtlanmış yani belirli hizmetler için delegation kullanabilen anlamına gelir.
Unconstrained: Kısıtlanmamış, yani tüm hizmetler için delegation kullanabilir.
S4U: servis hesabının başka bir kullanıcı hesabı için TGS bileti almasını sağlar.
S4UProxy: Bir servis hesabının başka bir servis hesabı için TGS bileti almasını sağlar. Bu işlem genelde HTTP sunucu ve SQL server gibi bir biri ile iletişim kurması ve erişim sağlaması gereken iki hizmet için kullanılır.
ÖRNEK:
Sergen => Delegation Trusted Any Service özelliği açık olan şifresini veya NTLM hashini bildiğimiz bir servis hesabı.
Can => Şifresini dahi bilmediğimiz kullanıcı hesabı(yetkili).
- Sergen kullanıcısı ile önce bir TGT isteyelim. Domain üzerinde kayıtlı bir kullanıcı olduğundan dolayı herhangi bir sorun olmadan AS bunu doğrulayacak ve ona bir TGT verecektir.
- Bu aldığımız TGT ile SQL server’a erişim sağlamak istiyoruz ve kendi adımıza bir TGS bileti talep ediyoruz. Eğer yetkimiz var ise TGS biletini alıyoruz ve erişim sağlayabiliyoruz. Peki TGS denilen bileti kendi adımıza değil Can adına alsaydık ?
- Şimdi Sergen’in TGT’si ile TGS’e gidip bir TGS bileti talep ediyoruz. TGT sergene ait olmasına rağmen TGS’i Can adına talep ediyoruz, böylece Can kullanıcısının yetkileri ile bir servise erişmek için TGS’e sahip olmuş oluyoruz.
- Bu yetkilendirmeler, AD Users and Computers’a girerek istenilen kullanıcıya sağ tıklanarak ve delegation sekmesi üzerinden değiştirilebilir. Trusted All Service, tüm servisler için TGT talep etme hakkı doğurur. Trusted Specify Service, add ile eklenen servisler üzerinde servis biletleri için TGS talep etmemizi sağlar. Bu özellik tüm kullanıcılar için default olarak No Trusted gelir, yani hiç bir servis için güvenme anlamındadır.
- Bu oluşturulan TGS bileti, PtT(Pass the Ticket) saldırıları için kullanılabilir.
PRATİK
kullandığım kullanıcı: t2_henry.shaw
tgs almak istedğim kullanıcı : t1
Daha önce anlattığım powerview.ps1 modülünü import ediyorum ve Get-NetUser -TrustedToAuth ile domain üzerinde kimlerin Kerberos Delegation yetkisi var sorguluyorum.
Yukarıdaki çıktı da svcIIS hesabının http ve WSMAN adı verilen iki servis üzerinde bir Kerberos delegasyonu olduğunu görüyorum. Burada bir Constrained Delegation mevcut. Bunu yukarıda ki resimde msds-allowedtodelegateto kısmına bakarak görebilirsiniz.
Daha sonra mimikatz aracını kullanarak hesap ismini bulduğum servis hesabının bilgilerini register üzerinden lsadump::secrets komutu ile dump ediyorum.
Servis hesabının şifresinin Password1@ olduğunu görüyorum ve bununla beraber bu servis hesabı ile AS’den bir TGT istiyorum. Bu tgt isteme işlemi Rubeus vb. araçlarla yapılabilir fakat sistemde mimikatz’ın bir modülü olan kekeo yüklü olduğu için onu kullanarak bir TGT istedim.
Oluşturduğum TGT ile bir TGS bileti isteyeceğim, fakat dikkat edin user kısmında bu sefer svcIIS değil, t1_duncan.moran kullanıcısı bulunuyor TGS biletini onun adına istiyorum. Diğer dikkat edilecek nokta ise ask komutu yerine s4u kullanıyorum, bunun size ne olduğunu anlatmıştım, yani bir hizmet hesabı TGT’si ile normal bir hesaba TGS bileti isteyeceğimi belirtiyorum. Üzerinde delegasyonum olan iki servis (WSMAN ve HTTP) için ayrı ayrı TGS biletleri talep ettim.
Aldığım TGS biletlerini mimikatz’ın kerberos::ptt komutu ile kullanıyorum.
Ve son olarak kullanılan biletlerimi görmek için klist komutunu çalıştırıyorum, görünüşe göre başardık :)
Şimdi t1_duncan.moran kullanıcısının TGS biletlerine sahip olduğuma göre artık THMSERVER1 bilgisayarına erişim sağlayabilirim. Bunun için New-PSSession komutu ile bir powershell oturumu oluşturuyorum ve Enter-PSSession ile oturuma giriş yapıyorum.
Bu işlemleri önlemek için kullanıcı hesabının özellikler kısmından “Account is Sensitive And Cannot Be Delegated” özelliği aktif edilebilir.
NOT: Bu kerberos delegasyon özellikleri sadece servis hesaplarına değil, istemcilere de uygulanabilir.
DELEGATION CONTROL
Kerberos Delegasyonu, Control delegasyonları ile karıştırılmamalıdır. Kontrol delegasyonları bir OU veya Grup üzerinde belirtilen kişilerin belirtilen yetkileri almasını sağlar. Örneğin bir OU oluşturup sağ tıklarsak ve Delegation Control’e gelirsek, burada açılan wizard üzerinden hangi kullanıcının bu OU içindeki şeylere neler yapabileceğini belirtebiliriz, Forced Password Change gibi.
Bu delegasyon yetkisini kullanarak T 2 admin grubunun üyelerinin şifrelerini değiştiriyorum.
AdminSDHolder & SDProp (ACL)
AdminSDholder adı verilen bir şablon, AD kullanıcıları pencerisinde system’in altında bulunur. Bu şablonlar otomatik olarak SDProp hizmeti tarafından bir saatte bir çalıştırılır. Bu şablonlar izinleri kopyalamak için kullanılır.
Bu şablona gidip sağ tıklayıp güvenlik özelliklerine düşük ayrıcalıklı kullanıcımızı eklersek ve tüm izinleri verirsek her saat başı yenileneceğinden dolayı sistem yetkilileri bizim ayrıcalıklarımızı kaldırsalar bile her saat başı tekrardan alacağız.
