Kerberos-dan Golden Ticket-ə: Active Directory Hücumları və protokolları necə işləyir?

Müasir korporativ şəbəkələrin ‘onurğa sütunu’ hesab olunan Active Directory, düzgün konfiqurasiya edilmədikdə hücumçular üçün geniş bir oyun meydanına çevrilir. Bu məqalədə biz sadəcə alətlərdən istifadə etməyi deyil, Active Directory-nin daxili mexanizmlərini, Kerberos və LDAP kimi kritik protokolların işləmə məntiqini və bu məntiqin necə silaha çevrilə biləcəyini araşdıracağıq.

Yazı boyunca Kerberoasting, AS-REP Roasting, Golden Ticket və Silver Ticket kimi geniş yayılmış hücum metodlarının pərdəarxası məqamlarına toxunacağıq. Unutmayın ki, ən mürəkkəb hücumları həyata keçirməyin yolu onların təməlində yatan ‘sıxıcı’ görünən texniki detalları dərindən anlamaqdan keçir.

Gəlin sıxıcı da olsa təməl bilikləri öyrənəndən sonra hücumlara keçək, çünki təməl biliklərimiz olmadan bu hücumları anlamaqda çətinlik çəkəcəyik.

Active Directory nədir?

Şəkil — 1 (Süni İntellekt vasitəsilə düzəldilib — bəzi səhvlər ola bilər)

Active Directory (AD) Windows şəbəkə mühitləri üçün bir kataloq xidmətidir. O, istifadəçilər, kompüterlər, qruplar, şəbəkə cihazları, paylaşılan fayllar, qrup siyasətləri (group policies), cihazlar və etibarlar (trusts) daxil olmaqla, təşkilatın resurslarının mərkəzləşdirilmiş idarə olunmasına imkan verən paylanmış, iyerarxik bir strukturdur. AD Windows domen mühiti daxilində autentifikasiya (kimlik doğrulaması) və autorizasiya (səlahiyyətləndirmə) funksiyalarını təmin edir.

Son illərdə o, getdikcə daha çox hücumlara məruz qalır. AD geriyə uyumlu (backward-compatible) olacaq şəkildə hazırlanıb və bir çox funksiyasının “default olaraq təhlükəli” olduğu isə mübahisəli mövzudur; həmçinin o, asanlıqla səhv konfiqurasiya edilə bilər. Bu zəifliklərdən şəbəkə daxilində üfüqi (lateral) və şaquli (vertical) hərəkət etmək, habelə icazəsiz giriş əldə etmək üçün istifadə oluna bilər.

AD, mahiyyət etibarilə, səlahiyyət səviyyəsindən asılı olmayaraq domen daxilindəki bütün istifadəçilər üçün əlçatan olan kifayət qədər böyük, “yalnız oxunabilən” (read-only) bir verilənlər bazasıdır. Heç bir əlavə imtiyazı olmayan adi bir AD istifadəçi hesabı AD daxilindəki əksər obyektləri əldə (enumerate) edə bilər. Bu fakt Active Directory — nin düzgün şəkildə təhlükəsizliyinin təmin edilməsini son dərəcə vacib edir, çünki səlahiyyət səviyyəsindən asılı olmayaraq İSTƏNİLƏN istifadəçi hesabı domeni skan etmək (enumerate), səhv konfiqurasiyaları və qüsurları axtarmaq üçün istifadə edilə bilər.

Bu səbəbdən, ona hücum etməyə cəhd etməzdən əvvəl Active Directory-nin necə qurulduğunu və idarəetmənin əsaslarını başa düşməliyik. Əgər necə qurulduğunu bilsək, onu “sındırmaq” həmişə daha asan olur.

Active Directory — nin strukturu

Active Directory iyerarxik ağac strukturu şəklində təşkil olunur; ən yuxarıda bir və ya daha çox domeni özündə birləşdirən forest (meşə) yerləşir və bu domenlərin özlərinin də daxilində alt domenlər (subdomain-lər) ola bilər. Forest, bütün obyektlərin inzibati nəzarət altında olduğu təhlükəsizlik sərhədidir. Bir forest özündə bir neçə domeni saxlaya bilər və hər bir domen də öz növbəsində əlavə uşaq və ya alt domenlərdən (“child” və “subdomain”-lərdən) ibarət ola bilər.

Domen, daxilində yerləşən obyektlərin (istifadəçilər, kompüterlər və qruplar) özündə birləşdirən bir strukturdur. Onun daxilində əvvəlcədən qurulmuş bir çox Organizational Unit (OU) mövcuddur, məsələn: Domain Controllers, Users, Computers və ehtiyac olduqda yeni OU-lar yaradıla bilər. OU-lar həm obyektləri, həm də alt OU-ları özündə saxlaya bilər və bu da müxtəlif qrup siyasətlərinin (Group Policy) tətbiq olunmasına imkan verir.

Sadə şəkildə bir Active Directory belə görsənir:

COMPANY.LOCAL/
├── ADMIN.COMPANY.LOCAL
│   ├── GPOs
│   └── OU
│       └── EMPLOYEES
│           ├── COMPUTERS
│           │   ├── SQL01
│           │   └── DATA01
│           ├── GROUPS
│           │   └── IT Staff
│           └── USERS
│               ├── perviz.quluzade
│               └── fikret.tagiyev
├── CORP.COMPANY.LOCAL
└── DEV.COMPANY.LOCAL

Burada deyə bilərik ki, COMPANY.LOCAL kök domen (root domain) rolunu oynayır və özündə alt domenləri (uşaq və ya tree root domenlər) — ADMIN.COMPANY.LOCAL, CORP.COMPANY.LOCAL və DEV.COMPANY.LOCAL — saxlayır. Eyni zamanda, bu struktur domeni təşkil edən digər obyektləri də əhatə edir; məsələn istifadəçilər, qruplar, kompüterlər və digər inzibati komponentlər.

Active Directory (AD) Obyektləri:

İstifadəçilər (Users)

Bunlar təşkilatın Active Directory (AD) mühitində olan istifadəçilərdir. İstifadəçilər leaf object hesab olunur, yəni onların daxilində başqa obyektlər yerləşə bilməz. İstifadəçi obyekti security principal kimi qəbul olunur və onun Security Identifier (SID) və Globally Unique Identifier (GUID) kimi unikal identifikatorları olur.

İstifadəçi obyektləri bir çox atributlara malikdir, məsələn: göstərilən ad (display name), son giriş vaxtı (last login time), son parol dəyişmə tarixi, e-poçt ünvanı, hesabın təsviri (description), ünvan və digər məlumatlar.

Kompüterlər (Computers)

Kompüter obyekti Active Directory (AD) şəbəkəsinə qoşulmuş istənilən kompüterdir (istər iş stansiyası, istərsə də server). Kompüterlər leaf object hesab olunur, yəni onların daxilində başqa obyektlər yerləşmir. Bununla belə, onlar da security principal sayılır və özlərinə məxsus SID və GUID identifikatorlarına malik olurlar.

İstifadəçilər kimi, kompüter obyektləri də hücumçular üçün əsas hədəflərdən biridir. Çünki bir kompüter üzərində tam inzibati səlahiyyət əldə edildikdə (məsələn, NT AUTHORITY\SYSTEM hesabı səviyyəsində), bu, adi domen istifadəçisinə bənzər imkanlar verir və istifadəçi hesablarının görə bildiyi əksər məlumat toplama (enumeration) əməliyyatlarını həyata keçirməyə şərait yaradır.

Qruplar (Groups)

Qrup container object (konteyner obyekt) hesab olunur, çünki o, istifadəçilər, kompüterlər və hətta digər qruplar daxil olmaqla müxtəlif obyektləri özündə saxlaya bilər. Qrup həmçinin security principal kimi qəbul edilir və onun da SID və GUID identifikatorları olur.

Active Directory (AD) mühitində qruplar istifadəçilərin icazələrini və digər qorunan obyektlərə (istər istifadəçilər, istərsə də kompüterlər) çıxışı idarə etmək üçün istifadə olunur.

Məsələn, fərz edək ki, 20 nəfərlik help desk istifadəçisinə bir jump host üzərində Remote Management Users qrupuna giriş vermək istəyirik. İstifadəçiləri tək-tək əlavə etmək əvəzinə, onları bir qrupa daxil edib həmin qrupu lazımi yerə əlavə edə bilərik. Beləliklə, istifadəçilər qrup üzvlüyü vasitəsilə avtomatik olaraq tələb olunan icazələri miras (inherit) alırlar.

Qısa bir not: Organizational Unit (OU) ilə Group — ları qarışdırmayın, bunlar ayrı-ayrı məqsədlərlə istifadə olunurnar. OU — lar inzibati idarə etməni asanlaşdırmaq üçündür və Group Policy (GPO)-lər tərəfindən idarə oluna bilirlər. Group — lar isə resurslara (fayllar, qovluqlar, printerlər) giriş icazəsi (permissions) vermək üçün istifadə olunan bir kolleksiyadır və qətiyyən Group Policy (GPO)-lər tərəfindən idarə ola bilməz.

Domain

Domen Active Directory (AD) şəbəkəsinin əsas strukturunu təşkil edir. Domenin daxilində istifadəçilər və kompüterlər kimi obyektlər yerləşir və bu obyektlər container object olan qruplar və Organizational Unit (OU)-lar vasitəsilə təşkil olunur.

Hər bir domenin özünə məxsus ayrıca verilənlər bazası və həmin domen daxilindəki bütün obyektlərə tətbiq oluna bilən siyasətlər (policies) toplusu olur. Bəzi siyasətlər standart olaraq təyin edilir (və sonradan dəyişdirilə bilər), məsələn domen parol siyasəti.

Bununla yanaşı, təşkilatın ehtiyaclarına uyğun olaraq əlavə siyasətlər də yaradılır və tətbiq edilir. Məsələn, bütün qeyri-administrator istifadəçilər üçün cmd.exe girişinin bloklanması və ya istifadəçi sistemə daxil olarkən avtomatik olaraq şəbəkə paylaşılan diskərin (shared drives) qoşulması kimi qaydalar buna daxildir.

Domain Controllers

Domain Controller-lər Active Directory (AD) şəbəkəsinin “beyni” kimi qəbul olunur. Onlar autentifikasiya (kimlik yoxlanışı) sorğularını emal edir, şəbəkəyə daxil olan istifadəçilərin kimliyini təsdiqləyir və domen daxilində müxtəlif resurslara kimlərin giriş əldə edə biləcəyini idarə edir.

Bütün giriş sorğuları domain controller tərəfindən yoxlanılır və istifadəçilərə verilən səlahiyyətlər onların əvvəlcədən təyin olunmuş rollarına əsasən müəyyən edilir.

Bundan əlavə, domain controller təhlükəsizlik siyasətlərini tətbiq edir və domen daxilindəki bütün obyektlər (istifadəçilər, kompüterlər, qruplar və s.) haqqında məlumatları saxlayır.

Kerberos və LDAP protokolu

Windows əməliyyat sistemləri ünsiyyət üçün müxtəlif protokollardan istifadə etsə də, Active Directory xüsusi olaraq bu protokolları tələb edir: Lightweight Directory Access Protocol (LDAP), Kerberos-un Microsoft versiyası, identifikasiya və ünsiyyət üçün DNS və müştəri-server modelinə əsaslanan tətbiqlər üçün istifadə edilən proseslərarası kommunikasiya texnikası olan Remote Procedure Call (RPC)-un Microsoft tətbiqi (implementasiyası) olan MSRPC.

Windows 2000-dən bəri Kerberos domen hesabları üçün standart autentifikasiya protokolu olmuşdur. Kerberos açıq bir standartdır və eyni standartdan istifadə edən digər sistemlərlə qarşılıqlı fəaliyyətə (interoperability) imkan verir. İstifadəçi öz kompüterinə (PC) daxil olduqda, Kerberos onları qarşılıqlı autentifikasiya (həm istifadəçinin, həm də serverin bir-birinin kimliyini təsdiqləməsi) vasitəsilə yoxlamaq üçün istifadə olunur.

Kerberos, istifadəçi şifrələrini şəbəkə üzərindən ötürmək əvəzinə, biletlərə əsaslanan və stateless bir autentifikasiya protokoludur. Active Directory Domen Xidmətlərinin (AD DS) bir hissəsi kimi, Domen Kontrollerləri (DC) biletləri təqdim edən Kerberos Açar Paylama Mərkəzinə (KDC — Key Distribution Center) malikdir.

Stateless protokollar — yaddaşı olmayan, səninlə etdiyi əvvəl ki sorğuları yadda saxlamadan, sənin kimliyivi (ticket) hər dəfə sübut etməyivi istəyən deməkdir. Bunu protokol prosesini anladanda daha rahat başa düşəcəksiniz.

İstifadəçi bir sistemə daxil olma sorğusu başlatdıqda, istifadə etdiyi müştəri proqram (client) sorğunu istifadəçinin şifrəsi ilə şifrələyərək KDC-dən bilet tələb edir. Əgər KDC həmin şifrədən istifadə edərək sorğunu (AS-REQ) deşifrə edə bilsə, o, Ticket Granting Ticket (TGT) yaradır və onu istifadəçiyə ötürür. Daha sonra istifadəçi öz TGT-sini Domen Kontrollerinə təqdim edərək, müvafiq xidmətin NTLM şifrə hashi ilə şifrələnmiş Ticket Granting Service (TGS) tələb edir. Sonda, müştəri həmin TGS-i tətbiqə və ya xidmətə təqdim edərək giriş icazəsi istəyir; xidmət isə bu bileti öz şifrə hashi ilə deşifrə edir. Əgər bütün proses lazımi qaydada tamamlanarsa, istifadəçiyə sorğu göndərilən xidmət və ya tətbiqə giriş icazəsi verilir.

Kerberos autentifikasiyası istifadəçilərin credentials-larını resurslara edilən sorğulardan effektiv şəkildə ayırır və beləliklə, şifrənin şəbəkə üzərindən ötürülməməsini təmin edir (məsələn, daxili SharePoint intranet saytına giriş zamanı).

Kerberos Key Distribution Centre (KDC) əvvəlki tranzaksiyaları qeydə almır. Bunun əvəzinə, Kerberos Ticket Granting Service (TGS) bileti etibarlı bir Ticket Granting Ticket (TGT)-yə əsaslanır. Sistem belə fərz edir ki, əgər istifadəçinin etibarlı bir TGT-si varsa, deməli o, artıq öz kimliyini sübut etmişdir. Aşağıdakı diaqram bu prosesi izah edir:

Kerberos autentifikasiya prosesinin addım-addım texniki tərcüməsi belədir:

1. İstifadəçi daxil olduqda, onun şifrəsi indi ki zaman damğasını (timestamp) şifrələmək üçün istifadə olunur (yəni ki şifrənin özü göndərilmir) və bu, deşifrə edilərək identifikasiyanın bütövlüyünü (integrity) yoxlamaq üçün Key Distribution Center (KDC)-ə göndərilir. KDC daha sonra krbtgt hesabının gizli açarı (secret key) ilə şifrələnmiş bir Ticket-Granting Ticket (TGT) təqdim edir. Bu TGT, şəbəkə resurslarına daxil olmaq üçün service tickets tələb etmək üçün istifadə olunur və istifadəçinin credentials-larını təkrar-təkrar ötürmədən identifikasiyaya imkan verir. Bu proses istifadəçinin şifrələrini resurslara edilən sorğulardan ayırır.
2. DC (Domain Controller) üzərindəki KDC xidməti authentication service request (AS-REQ)-i yoxlayır, istifadəçi məlumatlarını təsdiqləyir və bir Ticket Granting Ticket (TGT) yaradaraq istifadəçiyə çatdırır.
3. İstifadəçi TGT-ni DC-yə təqdim edərək spesifik bir xidmət üçün Ticket Granting Service (TGS) bileti tələb edir. Bu, TGS-REQ adlanır. Əgər TGT uğurla validasiya olunarsa, onun məlumatları bir TGS bileti yaratmaq üçün kopyalanır.
4. TGS, xidmətin bağlı olduğu hesabın və ya kompüter hesabının NTLM password hash-i ilə şifrələnir və TGS_REP daxilində istifadəçiyə çatdırılır.
5. İstifadəçi TGS-i xidmətə təqdim edir və əgər bilet etibarlıdırsa, istifadəçinin resursa qoşulmasına icazə verilir (AP_REQ).

Şəkil — 2: HTB Academy-dəki diagramlardan referans alınmışdır. (Süni İntellekt vasitəsilə düzəldilib — bəzi səhvlər ola bilər)

Bu prosesi anlamaq Kerberoasting və AS-REP Roasting hücumlarının necə işlədiyini anlamaqda kömək olacaq. Ona görə də necə işlədiyini öyrənmək mühüm rol oyanyır.

Kerberos protokolu 88-ci portdan (həm TCP, həm də UDP) istifadə edir. “Active Directory” mühitini analiz edərkən (enumeration), biz çox vaxt “Nmap” kimi alətlərlə 88-ci portun açıq olub-olmadığını yoxlayaraq Domen Kontrollerlərini (Domain Controllers) tapa bilərik.

LDAP protokolu

Active Directory kataloq axtarışları üçün “Lightweight Directory Access Protocol” (LDAP) protokolunu dəstəkləyir. LDAP, müxtəlif kataloq xidmətlərinə qarşı autentifikasiya üçün istifadə olunan açıq mənbəli və müxtəlif platformalarda işləyə bilən (cross-platform) protokoldur. LDAP-ın AD mühitində necə işlədiyini dərindən başa düşmək həm hücumçular, həm də müdafiəçilər üçün mühümdür. LDAP 389-cu portdan, SSL üzərindən LDAP (LDAPS) isə 636-cı portdan istifadə edərək kommunikasiya qurur.

Active Directory (AD) istifadəçi hesabı məlumatlarını və parollar kimi təhlükəsizlik məlumatlarını saxlayır, həmçinin bu məlumatların şəbəkədəki digər cihazlarla paylaşılmasını asanlaşdırır. LDAP, tətbiqlərin kataloq xidmətləri göstərən digər serverlərlə əlaqə qurmaq üçün istifadə etdiyi “dil”dir. Başqa sözlə, LDAP şəbəkə mühitindəki sistemlərin AD ilə “danışa” bildiyi bir vasitədir.

Şəkil — 3: HTB Academy-dəki diagramlardan referans alınmışdır. (Süni İntellekt vasitəsilə düzəldilib — bəzi səhvlər ola bilər)

Active Directory (AD) və LDAP arasındakı əlaqəni “Apache” və HTTP ilə müqayisə etmək olar. Necə ki, “Apache” HTTP protokolundan istifadə edən bir veb serverdir, “Active Directory” də LDAP protokolundan istifadə edən bir kataloq serveridir.

Kerberoasting

Bu mövzunu ilk oxuyuşda başa düşməmək tamamilə normaldır. SPN, Active Directory arxitekturasının ən “baş ağrıdan” mövzularından biridir və ilk oxunuşda tam oturmaması çox təbiidir. Kerberoasting mövzusunun əsası da elə, Service Principal Name (SPN) — atributuna dayanır.

Texniki olaraq SPN, Active Directory-də müəyyən bir xidmətin (service instance) onu işlədən xüsusi hesabla (Service Logon Account) əlaqələndirən unikal identifikatordur. O, obyektin servicePrincipalName atributunda saxlanılır. Kerberos autentifikasiya protokolu SPN-lər olmadan işləyə bilməz.

SPN-in formatı: SPN-lər müəyyən bir sintaksisə malikdir. Əsas format belədir: ServiceClass/Host:Port/ServiceName

• ServiceClass: Xidmətin növü (məsələn: HTTP veb serverlər üçün, MSSQLSvc SQL serverlər üçün, cifs fayl paylaşımı üçün).
• Host: Xidmətin işlədiyi kompüterin tam adı (FQDN). (məsələn: sql-server.corp.local ).
• Port (İstəyə bağlı): Xidmətin dinlədiyi port (məsələn: 1433).

Nümunə SPN: MSSQLSvc/sql-server.corp.local:1433

1. İstifadəçi Domain Controller-ə müraciət edərək deyir: “Mənə MSSQLSvc/sql-server.corp.local SPN-i üçün TGS (Ticket Granting Service) bileti ver.
2. Domain Controller (DC) öz məlumat bazasında (NTDS.DIT) axtarış edir ki, görsün bu SPN hansı obyektin servicePrincipalName atributunda qeydiyyatdan keçib.
3. DC bu SPN-in sql_service_account adlı (obyektə) istifadəçiyə aid olduğunu tapır. KDC müştəri üçün TGS biletini yaradır və bu biletin daxilindəki məlumatları həmin **sql_service_account-un NTLM şifrə hashi (parolu) ilə şifrələyir**. Bura olan əsas nüans odur ki, TGS biletini daxilindəki bir hissəni bu servicePrincipalNameatributu olan istifadəçinin NTLM hashi ilə şifrələyir.
4. Müştəri bu şifrələnmiş bileti alır və SQL serverə göndərir.
5. SQL serverin arxasında işləyən xidmət-in (sql_service_account) öz şifrəsini bildiyi üçün bileti deşifrə edə bilir. Əgər bilet uğurla deşifrə olunursa, deməli bilet doğrudan da Domain Controller tərəfindən verilib və müştəri içəri buraxılır. (Deşifrə oluna bilir çünki bizim biletimiz elə girmək istədiyimiz SQL serveri idarə edən hesabın NTLM hashi ilə şifrələnib.)

Hücum isə bu prosesin 4-cü hissəsində yaranır, yəni bizim istifadəçi giriş etmək üçün şifrələnmiş bileti alır və SQL serverə göndərmək yerinə offline olaraq qırmağı dənəyir. İlk oxunuşda anlamamağınız normaldır, özümündə başa düşməsi vaxt almışdı, ona görə gəlin başqa bir nümunə ilə başa salım.

Vəzifə və işçi (Nümunə):

Təsəvvür et ki, böyük bir zavodda işləyirsən və otağında işıqlar sönüb. Sənə “Baş Elektrik” lazımdır.

Sən zavodun müdiriyyətinə (Domain Controller) zəng edib demirsən ki, “Mənə Elvin lazımdır”. Çünki sən hardan biləsən ki, elektrikin adı Elvindir? Bəlkə Elvin işdən çıxıb, yerinə Vəli gəlib? Sən sadəcə deyirsən: “Mənə Baş Elektrik lazımdır”.

Müdiriyyət öz dəftərini (Active Directory məlumat bazasını) açır və baxır:

• Vəzifə: Baş Elektrik
• Bu vəzifəyə baxan adam: Elvin

Müdiriyyət sənə deyir: “Get Elvinin yanına, elektrik işlərinə o baxır”.

Bax, SPN həmin o “Baş Elektrik” vəzifəsinin (etiketinin) adıdır. İstifadəçi hesabı (Elvin) isə arxada o işi görən real adamdır. Bizim bayaq ki nümunədə olan sql_service_accountistifadəçisi burda ki “Elvin” və servicePrincipalNameatributu isə “Baş Elektrik” vəzifəsini təsvir edir.

İndi bunu Active Directory-yə tətbiq edək:

Deyək ki, şirkət şəbəkəsində bir SQL məlumat bazası var (sql-server.local). Bu məlumat bazasının arxa planda işləməsi (run olması) üçün bir istifadəçi hesabı lazımdır. Administratorlar bunun üçün corp\sql_admin adlı bir istifadəçi yaradırlar və SQL-i onun adına işə salırlar.

İndi adi bir işçi (və ya başqa bir proqram) bu SQL-ə qoşulmaq istəyir. O, sadəcə SQL-in adını bilir, arxadakı sql_admin hesabından xəbəri yoxdur.

Buna görə də administratorlar Active Directory-də SPN (Service Principal Name) qeydiyyatı yaradırlar. Yəni AD-yə deyirlər ki:

“Hey AD, əgər kimsə MSSQLSvc/sql-server.local xidmətinə (SPN) qoşulmaq istəsə, bil ki, bu vəzifəyə corp\sql_admin hesabı baxır."

SPN sadəcə bu əlaqəni (Xidmət <- — -->İstifadəçi) quran bir körpüdür, qeydiyyat sətiridir.

Öyrəndiklərimizi toparlasaq Kerberoasting budur:

Kali Linux-da terminalı açıb impacket-GetUserSPNs komandasını yazanda arxa planda baş verən hadisə tam olaraq budur:

1. Sənin komandan Domain Controller-ə (DC) müraciət edir: “Salam DC, mən şəbəkədəki qanuni bir istifadəçiyəm. Zəhmət olmasa, mənə üzərində SPN (yəni hər hansı bir vəzifəsi) olan bütün istifadəçilərin siyahısını və onların yanına getmək üçün giriş biletlərini (TGS) ver.”
2. DC sənə inanır: Sənin qanuni istifadəçi olduğunu görüb, həmin o xidmətlər (məsələn, yuxarıdakı SQL xidməti) üçün sənə biletlər verir.
3. Biletin sirri: Active Directory-nin bir qaydası var — o verdiyi biletin üstünü, arxadakı real istifadəçinin (məsələn, sql_admin) parolunun hashi ilə kilitləyir.
4. Hücum (Kerberoasting): Sən o bileti alırsan. Sənin o xidmətə (SQL-ə) qoşulmaq kimi bir dərdim yoxdur. Sən sadəcə o bileti öz Kali maşınına yükləyirsən və hashcat və ya john işə salaraq biletin üstündəki o parolu oflayn rejimdə qırmağa (crack etməyə) başlayırsan.

Əslində şəbəkədəki kompüterlərin də (məsələn, DC01$, WEB-SERVER$) SPN-ləri var. Amma Impacket onları sənə göstərmir və Kerberoasting üçün onları hədəf almırıq. Çünki:

• Kompüter Hesabları: Şifrələri Active Directory tərəfindən avtomatik təyin olunur (məsələn, 120 simvoldan çox, qarışıq). Onu hashcat ilə qırmaq (brute-force) milyonlarla il çəkər.
• İstifadəçi Hesabları: Şifrələrini insanlar qoyur (məsələn, Admin123!, Baku2024). Bunları qırmaq çox asandır.

Texniki olaraq bütün istifadəçi SPN-ləri üçün bilet ala bilsən də, hər bilet sənə parol verməyəcək. Sən bileti alandan sonra onu bir fayla çıxarırsan (adətən .kirbi və ya .hash formatında) və hashcat ilə yoxlayırsan. Əgər adminin parolu güclüdürsə (məsələn, 25 simvollu təsadüfi simvollar), bilet əlində olsa da, parolu tapa bilməyəcəksən.

Qısacası: SPN olmasaydı, sən Domain Controller-dən o biletləri istəyə bilməzdin. Çünki DC bilməzdi ki, hansı xidmət hansı istifadəçiyə aiddir. SPN sənə hədəf olaraq hansı istifadəçilərin (adətən admin yetkili hesabların) parollarını oğurlaya biləcəyini göstərən bir xəritədir.

Hər istifadəçiyə SPN yazmaq olar?

Bəli. İstənilən istifadəçi hesabına setspn komandası ilə və ya Active Directory-nin atribut redaktoru ilə SPN əlavə edə bilərsən. Bunu etdiyin an, həmin sıravi istifadəçi AD-nin gözündə bir "Xidmət Hesabı"na (Service Account) çevrilir. Yəni o, artıq sadəcə "Elvin" deyil, həm də "SQL Xidmətini işlədən məsul şəxsdir".

DC Elvinin TGT-sini verir?

Bax, ən önəmli hissə budur. DC heç vaxt birinin TGT-sini (Ticket Granting Ticket) başqasına vermir. TGT sənin “şəxsiyyət vəsiqəndir” və yalnız sənə məxsusdur.

DC-nin verdiyi şey TGS (Service Ticket) biletidir. Proses belə gedir:

• Sən (İstifadəçi): “Mən SQL-ə qoşulmaq istəyirəm.”
• DC: “Baxıram… Hə, sənin SQL-ə girməyə icazən var. Onda sənə bir TGS bileti verirəm.”
• DC-nin etdiyi sehrli hərəkət: DC bu TGS biletini hazırlayır və onun içini o xidməti işlədən adamın (məsələn, bayaq ki Elvinin) şifrəsinin hashi (parolu) ilə kilidləyir.

Şəkil — 4 (Süni İntellekt vasitəsilə düzəldilib — bəzi səhvlər ola bilər)

AS-REP Roasting

Bəzi istifadəçilərdə “Kerberos Pre-Authentication Required” xüsusiyyəti söndürülür. Bu o deməkdir ki, sən (hücumçu) kor-koranə KDC-yə deyə bilərsən: “Mənə Əli üçün TGT ver”. KDC sənə içində Əlinin şifrəsindən istifadə edilərək yaradılmış bir şifrəli mətn (AS-REP) göndərir. Sən bunu kompüterinə yükləyib (məsələn, Hashcat ilə) sındıraraq Əlinin parolunu tapırsan.

Hərbi baza parolu (Nümunə)

Hərbi bazaya girmək üçün parol “Qartal”dır. Amma parolu qapıdakı əsgərə səsli desən, kimsə eşidib sabah eyni parolla içəri girə bilər. Buna görə komandir deyir: “Mənə parolu demə. Cibindəki parolla (Qartal) indiki SAATIN neçə olduğunu şifrələ və mənə ver.” Sən saat 14:05-i “Qartal”la şifrələyib verirsən. Komandir özündəki “Qartal”la o şifrəni açır, baxır ki, içində 14:05 yazılıb. Deyir: “Hə, demək parolu bilirsən və bu mesajı da elə indicə yaratmısan.” Kimsə o şifrəli mesajı oğurlayıb sabah gətirsə, komandir açacaq və görəcək ki, içindəki saat dünənindir, deməli bu saxtadır.

Texniki İzah (PA-ENC-TIMESTAMP):

1. İstifadəçi şifrəsini yazanda Windows onu dərhal hash-ə (RC4 və ya AES key) çevirir. Parol şəbəkədə heç vaxt getmir.
2. İlk AS-REQ (Authentication Service Request) gedəndə, kompüter Pre-Authentication (Ön-doğrulama) edir. Yəni, cari zaman damğasını (Timestamp) istifadəçinin hash-i ilə şifrələyir və KDC-yə göndərir.
3. KDC LDAP-dan istifadəçinin hash-ini götürür, o paketi açmağa çalışır. Əgər açılırsa, demək istifadəçi parolu bilir.
4. KDC açılmış paketin içindəki vaxta baxır. Əgər Serverin saatı ilə o paketin içindəki saat arasında fərq 5 dəqiqədən çoxdursa, KDC sorğunu rədd edir (Kerberos Clock Skew Too Great xətası). Çünki o, bu paketin köhnə olduğunu və kimsə tərəfindən təkrar istifadə edildiyini düşünür. ntpdate məhz bu 5 dəqiqəlik limitə düşmək üçün hücumçu və ya pentester tərəfindən istifadə edilir.

TGT krbtgt hesabının gizli açarı ilə şifrələnibsə, necə içini açıb istifadəçinin parolunu qırırıq?

Sirr buradadır: KDC-nin bizə qaytardığı AS-REP paketi TƏK BİR şifrəli blokdan ibarət deyil. O, İKİ hissədən ibarətdir:

1. TGT-nin özü: Bəli, bu hissə krbtgt ilə şifrələnib. Biz ona toxuna, içini oxuya və ya dəyişdirə bilmərik. O bizim üçün sadəcə qapalı bir qutudur.
2. Logon Session Key (və metadata): Bu hissə isə TGT-dən ayrıdır. Bu, istifadəçinin növbəti addımlarda (TGS istəyəndə) KDC ilə danışmaq üçün istifadə edəcəyi müvəqqəti sessiya açarıdır. KDC bu açarı yalnız həqiqi istifadəçinin oxuya bilməsi üçün istifadəçinin öz parolunun hash-i ilə şifrələyir!

Kerberos AS-REP (Cavab Paketi)
│
├── 1. Açıq Mətn Hissəsi (Cleartext)
│   ├── İstifadəçi Adı: jsmith
│   └── Domen: CORP.LOCAL
│
├── 2. TGT Bileti (ticket)  <--- BURA TOXUNA BİLMİRİK
│   ├── (İçində İstifadəçinin hüquqları, qrupları PAC olaraq yerləşir)
│   └── Şifrələmə: krbtgt hesabının NTLM Hash-i (və ya AES açarı) ilə şifrələnib.
│
└── 3. Şifrəli Hissə (enc-part) <--- BİZİM SİNDİRDİĞİMİZ HİSSƏ BUDUR!
    ├── (İçində Logon Session Key və KDC-nin təsdiq etdiyi zaman damğası var)
    └── Şifrələmə: İSTİFADƏÇİNİN (jsmith) öz parolunun Hash-i ilə şifrələnib!

AS-REP Roasting necə baş verir?

Normalda KDC sənə bu paketi vermək üçün səndən Yuxarıda (2-ci bölmədə) danışdığımız Pre-Authentication (zaman damğası) tələb edir. Amma əgər AD-də istifadəçinin üzərində “Do not require Kerberos preauthentication” açıqdırsa, KDC sənin kimliyini yoxlamadan sənə AS-REP paketini göndərir. Sən (hücumçu) paketi alırsan. TGT olan hissəni kənara atırsan (çünki onu qıra bilməzsən). Amma Logon Session Key olan ikinci hissəni götürürsən (hansı ki, hədəf istifadəçinin parolu ilə şifrələnib) və onu Hashcat/John the Ripper-ə verərək offline olaraq brute-force edirsən. O şifrəli paketi hansı söz (parol) aça bilsə, deməli istifadəçinin parolu odur!

Şifrələmə Alqoritmləri

Active Directory illər ərzində inkişaf etdiyi üçün fərqli şifrələmə alqoritmləri dəstəkləyir:

• RC4 (Type 23): Çox köhnə və zəif alqoritmdir. Əgər şəbəkədə RC4 aktivdirsə (çox vaxt köhnə sistemləri dəstəkləmək üçün açıq qoyurlar), Kerberoasting və ya AS-REP roasting zamanı çıxardığımız hash birbaşa NTLM hash formatında olur və onu sındırmaq (crack etmək) qat-qat sürətlidir.
• AES-128 / AES-256 (Type 17 / Type 18): Müasir Windows sistemlərində standartdır. Bu daha güclüdür. Hash-i sındırmaq üçün lazım olan zaman və hesablama gücü xeyli çoxdur. Lakin, əgər istifadəçinin parolu sadədirsə (məsələn, Summer2026!), AES də olsa lüğət hücumu (dictionary attack) ilə qırıla bilər.

Golden Ticket

Bu, Active Directory-də Mütləq Hakimiyyətdir. AD şəbəkəsinin ən böyük qorxusudur.

Sadə dilə desək:

Sən əyləncə parkındakı Kassanı yarmısan. Amma pulu yox, qolbaq çap edən maşını (krbtgt) oğurlamısan. Artıq sən kimsədən icazə almırsan. Evdə oturub özün üçün, dostların üçün və hətta mövcud olmayan “Super Administrator” adlı bir adam üçün 10 il keçərli olan VİP qolbaqlar (TGT) çap edirsən. Kassadakılar (Domain Controller) sənə baxa-baxa qalır, çünki qolbaqdakı möhür onların öz möhürüdür, saxta olduğunu sübut edə bilmirlər.

Golden ticket hücumunun belə gərçəkləşir:

Kerberos izahında demişdik ki, TGT biletləri krbtgt hesabının NTLM Hash-i ilə şifrələnir.

1. Sən Domain Controller-i bir dəfə ələ keçirib (və ya başqa yollar ilə), krbtgt hesabının hash-ini oğurlayırsan.
2. Sonra öz kompüterində oflayn şəkildə saxta bir TGT (Ticket Granting Ticket) yaradırsan.
3. Biletin içinə PAC (Privilege Attribute Certificate) adlı bir məlumat qoyursan. Bura yazırsan: “Mənim adım SaxtaAdmin-dir və mən Domain Admins, Enterprise Admins qruplarının üzvüyəm”.
4. Bu bileti krbtgt hash-i ilə şifrələyib şəbəkəyə təqdim edirsən.
5. KDC bu bileti görür, öz möhürü ilə açır, içində sənin “Domain Admin” olduğunu oxuyur və şübhələnmədən sənə şəbəkənin istənilən yerinə girmək üçün TGS biletləri verir. Qeyd: Bu biletin ömrünü istədiyin qədər (məsələn, 10 il) edə bilərsən. Parollar dəyişsə belə, krbtgt hash-i dəyişməyənə qədər sən şəbəkədə qalacaqsan.

PAC Nədir və Biletin (Ticket) Anatomiyası

PAC (Privilege Attribute Certificate) biletin içində yerləşən “İcazələr Siyahısı”-dır. Kerberos (KDC) sənə bilet verəndə sənin kimliyini (Authentication) təsdiqləyir. Amma sən serverə gedəndə, server bilməlidir ki, sən adi işçisən, yoxsa Admin (Authorization). Məhz KDC sənin bütün qruplarını (məsələn, Domain Admins, Enterprise Admins), SID və RID nömrələrini paketləyib bu PAC-ın içinə qoyur.

• Hər biletdə PAC varmı? Bəli! Həm TGT-nin, həm də TGS-in içində PAC olur (çox nadir xüsusi konfiqurasiyalar istisna olmaqla).
• Hücumun Məntiqi: Golden və Silver Ticket hücumlarında biz məhz biletin içindəki bu PAC hissəsini saxtalaşdırırıq. Sistemin bizi “Admin” sanmasının yeganə səbəbi, bizim saxta biletin içinə “Bu adam Domain Admin qrupundadır (RID 512)” yazmağımızdır.

Biletin Quruluşu (Sadələşdirilmiş Diaqram)

Bir bilet (TGT və ya TGS) Wireshark-da açılanda təxminən bu quruluşda olur (ağlınızda şəkillənəndə daha rahat başa düşmək olur):

KERBEROS TICKET (TGT və ya TGS)
│
├── 1. Biletin Başlığı (Açıq Mətn - Cleartext)
│   ├── KDC-nin adı (Domenin adı)
│   └── Hədəf Servisin adı (TGT üçündürsə 'krbtgt', TGS üçündürsə məsələn 'MSSQLSvc')
│
└── 2. Şifrələnmiş Hissə (Encrypted Data)
    │  (Golden biletində bu hissə 'krbtgt' ilə, Silver biletində hədəf servisin parolu ilə şifrələnir)
    │
    ├── Sessiya Açarı (Session Key - KDC ilə istifadəçi arasındakı müvəqqəti açar)
    ├── İstifadəçi Məlumatları (Client Name, Realm)
    ├── Zaman Damğaları (Auth Time, Start Time, End Time, Renew Till)
    │
    └── PAC (Privilege Attribute Certificate) <--- ƏSAS HƏDƏFİMİZ
        ├── İstifadəçinin SID nömrəsi
        ├── Üzvü olduğu qrupların Siyahısı (Domain Admins, Print Operators və s.)
        └── PAC İmzaları (KDC tərəfindən vurulan möhürlər)

Praktika üçün istifadə edə biləcəyiniz HTB lablar: Certificate — https://app.hackthebox.com/machines/Certificate Ghost — https://app.hackthebox.com/machines/Ghost Forest — https://app.hackthebox.com/machines/Forest

Silver Ticket

Golden Ticket çox səs-küylüdür və böyük səlahiyyət tələb edir. Silver Ticket isə daha səssizdir və birbaşa hədəfə vurur.

Sadə dilə desək:

Bu dəfə sən parkın əsas qolbaq aparatını oğurlaya bilməmisən. Amma getmisən yalnız bir spesifik karuselin (məsələn, Qorxu Otağı) bilet yoxlayanını aldatmısan və onun bilet kəsən möhürünü oğurlamısan. Sən parkdakı digər karusellərə minə bilməyəcəksən. Amma evdə Qorxu Otağı üçün minlərlə saxta bilet çap edib, Kassaya heç yaxınlaşmadan birbaşa o karuselə gedib pulsuz minə bilərsən. Kassanın səndən heç xəbəri də olmayacaq.

Silver ticket hücumunun belə gərçəkləşir:

Kerberos-da son addımda Client TGS biletini alıb birbaşa Servisə (məsələn, SQL Serverinə və ya Fayl Serverinə) gedir. TGS bileti həmin Servisin (Service Account) parol hash-i ilə şifrələnir (Bayaq nümunə də istifadə olununan Elvinin kimi).

1. Sən şəbəkədə (məsələn, Kerberoasting vasitəsilə və ya lokal admin olaraq) hədəf servisin (məsələn, MSSQLSvc) NTLM hash-ini əldə edirsən.
2. KDC-yə (Domain Controller-ə) ümumiyyətlə müraciət etmirsən! Yəni AS-REQ və TGS-REQ sorğuları getmir.
3. Öz kompüterində saxta bir TGS bileti (Silver Ticket) yaradırsan. İçinə PAC əlavə edib yazırsan: “Mən bu SQL serveri üçün ən yetkili Adminəm”.
4. Bu bileti həmin SQL Servisinin hash-i ilə şifrələyirsən. (Elvinin)
5. Bileti (AP-REQ paketi olaraq) birbaşa SQL serverinə göndərirsən. SQL server baxır ki, bilet onun öz hash-i ilə şifrələnib, deməli bunu guya KDC verib. Açır, içində sənin Admin olduğunu görür və səni içəri buraxır. Üstünlüyü: DC-də heç bir log/qeyd yaranmır, çünki sən DC ilə əlaqə qurmadan birbaşa serverə saxta bilet təqdim edirsən.

Son sözlər:

Bu məqalə ilə biz Active Directory mühitində ən çox rast gəlinən hücum metodlarının və protokolların ‘rentgenini’ çəkməyə çalışdıq. Gördüyümüz kimi, bu hücumların əksəriyyəti sistemin proqram təminatı xətalarından deyil, protokolların təbiətindən və yanlış konfiqurasiyalardan qaynaqlanır.

Mövzunu ilk oxunuşda tam qavramamaq tamamilə normaldır; Active Directory dəryasında SPN və bilet mexanizmləri ən təcrübəli mütəxəssislər üçün belə bəzən ‘baş ağrısı’ ola bilər. Əgər qaranlıq qalan məqamlar varsa və ya öz təcrübənizi bölüşmək istəyirsinizsə, aşağıdakı ‘responses’ bölməsində suallarınızı gözləyirəm. Şərh bölməsində yaradacağımız müzakirələr həm sizin, həm də digər oxucuların biliklərini daha da dərinləşdirəcək. Öyrənməyə və araşdırmağa davam edin!

Active Directory security and Kerberos attack visualization