От нула до Domain Admin: разчитане на пътищата за атака в Active Directory с BloodHound

Почти всеки вътрешен тест показва не единичен експлойт, а път за атака: верига от на пръв поглед обичайни права, която води от стандартен потребителски акаунт до пълен контрол над домейна. BloodHound прави тези пътища видими. Тук разглеждаме как го използваме при реални оценки и как защитниците могат да прекъснат всяка стъпка.

Методологията е добре документирана, присъства в обучения като OSCP, CRTO и CRTE, а техниките са описани в MITRE ATT&CK. Всяка секция включва признаците, които помагат за откриване на атаката, и промените, които ограничават риска. Целта е администраторите на Active Directory да знаят какво да наблюдават и отстранят.

Защо анализираме пътища за атака

Скенерът разглежда отделни хостове: липсваща актуализация, стара версия на TLS. При Active Directory може да няма нито един очевидно уязвим сървър. Рискът често е в натрупаните отношения: членства в групи, делегирани права, локален административен достъп чрез GPO и служебни акаунти с прекомерни привилегии.

Поотделно тези права може да имат обяснение. В комбинация могат да образуват път за компрометиране. Подходът на BloodHound, разработен първоначално от Andy Robbins, Will Schroeder и Rohan Vazarkar, е да моделира AD като насочен граф и да отговори на въпроса: „Кой е най-краткият път от достъпа, който имам сега, до Domain Admin?“

Моделът: възли и връзки

Възлите представляват обекти в директорията:

• Потребители, включително служебни акаунти.
• Компютри: работни станции, сървъри и домейн контролери.
• Групи, включително вложени групи за сигурност.
• Организационни единици, GPO, домейни и обекти на AD CS: шаблони за сертификати и удостоверяващи органи.

Връзките показват отношения, които нападател може да използва. Всяко отношение има конкретно значение:

Задачата се превръща в търсене на маршрут: започвате от контролиран възел, следвате използваеми отношения и достигате привилегирован обект. BloodHound визуализира възможните маршрути.

Стъпка 1 — събиране на данни

Първо изграждаме графа чрез събиране на информация за обектите и отношенията в директорията. Обикновен удостоверен потребител може да прочете голяма част от тези данни, защото AD трябва да позволява на членовете си да намират ресурси. Това обяснява стойността дори на един компрометиран акаунт.

Колекторите SharpHound и bloodhound-python събират информация чрез:

1. LDAP заявки за обекти, членства и ACL. Това е основната част от информацията.
2. Проверка на сесиите по машините за изграждане на връзки HasSession. Тази активност може да бъде забелязана от защитниците.
3. Проверка на локалните групи за изграждане на връзки AdminTo.

Получените JSON файлове се импортират в BloodHound. При оценка съобразяваме честотата и обхвата на събирането с правилата на проекта, без едновременно да обхождаме всички хостове. Тази активност е и възможност за ранно откриване на нападател.

Стъпка 2 — ориентиране от началния достъп

Да приемем, че разполагаме с един акаунт, получен при разрешена фишинг симулация или проверка на пароли. Маркираме го като Owned чрез Mark as Owned и изпълняваме заявката Shortest Paths from Owned Principals to Domain Admins.

Обикновено виждаме един от три резултата:

• Няма път. Това означава само, че не е намерен път от този акаунт с наличните данни. Проверяваме достижимите ресурси, групите и сесиите.
• Кратък път. В слабо поддържан домейн понякога само две или три стъпки водят до Domain Admins.
• По-дълъг път с ключови пресечни точки. Това е примерът, който разглеждаме по-долу.

Илюстративният сценарий използва променени имена. Последната връзка предполага неправилно делегирани права върху домейн обекта, а не стандартни права на операторска група:

[Owned] j.doe@corp.local
   │ MemberOf
   ▼
IT-SUPPORT
   │ AdminTo
   ▼
WKS-DEV-04
   │ HasSession
   ▼
svc-backup
   │ MemberOf
   ▼
SERVER-OPERATORS
   │ GenericAll (custom delegation)
   ▼
DOMAIN-OBJECT ──DCSync──► Domain control

Следваме всяка връзка и проверяваме дали тя действително може да бъде използвана. Графът показва хипотези; практическата проверка доказва въздействието.

Стъпка 3 — група с локални административни права

Потребителят j.doe членува в IT-SUPPORT, която има връзка AdminTo към WKS-DEV-04. Често поддръжката получава такива права чрез GPO, Restricted Groups или Group Policy Preferences.

Членството дава на j.doe значителен контрол над WKS-DEV-04. Дали той води до използваеми credentials зависи от типовете влизане, защитите и наличния материал. Проверете възможността, преди да я приемете за завършена стъпка; връзката в графа сама не доказва извличане на credentials.

Стъпка 4 — сесия на привилегирован акаунт

Връзката HasSession показва, че svc-backup има сесия на WKS-DEV-04. Причината може да е агент за резервни копия или инструмент, стартиран от администратор.

Привилегирована сесия на компрометиран хост е потенциален път за разкриване на credentials. HasSession не доказва възстановими хешове, tickets или пароли: Credential Guard, Remote Credential Guard и методът на влизане могат да променят резултата. Документирайте отделно извличането или равностойна разрешена проверка, преди да маркирате профила като контролиран. Pass-the-hash и pass-the-ticket зависят и от възстановения материал и защитите на целта.

Стъпка 5 — опасно членство в група

svc-backup членува в SERVER-OPERATORS или в специална група със сходни права. Системите за резервни копия често натрупват широк достъп, защото четат и възстановяват файлове на много сървъри.

Преглеждайте внимателно членствата в Account Operators, Backup Operators, Server Operators, Print Operators и DnsAdmins. Те имат легитимни функции, но определени конфигурации позволяват повишаване на привилегиите. Не приемайте, че всяко членство автоматично дава Domain Admin; проверете конкретните права и конфигурация.

Стъпка 6 — контрол върху домейн обекта

В примера операторската група има неправилно делегирано право GenericAll върху домейн обекта. При други оценки това може да е WriteDacl. Такива права позволяват промяна на ACL и предоставяне на права за репликация. Контролът само върху компютърния обект на домейн контролер е различна ситуация и не дава автоматично DCSync.

Правата за репликация могат да разкрият паролен материал за засегнатите профили, включително krbtgt. Неговите ключове могат да позволят подправяне на TGT; service tickets включват и ключовете на целевата услуга. Възстановяването след компрометиране на домейна изисква координиран план, премахване на устойчивия достъп и контролирани reset операции за krbtgt с изисквания за репликация и време. Само две смени не са цялостен план.

Важното за защитниците е веригата: няколко права, които изглеждат приемливи поотделно, могат заедно да доведат до пълен контрол.

BloodHound за защитния екип

Инструментът на нападателя е полезен и за защитниците. Можете да съберете същите данни за собствения си домейн и да зададете същите въпроси преди реален нападател.

1. Събирайте данни ежемесечно. Използвайте определен акаунт, график и защитено съхранение. Промени в членства и права могат да създадат нов маршрут.
2. Маркирайте критичните активи като high value. Изпълнявайте Shortest paths to high-value targets. Включете финансови приложения, резервни копия и PKI, а не само Domain Admins.
3. Сравнявайте резултатите във времето. Особено важни са новите връзки към Tier-0.
4. Отстранявайте ключовите пресечни точки. Една или две промени често прекъсват десетки маршрути. Използвайте изгледа за най-кратък път, за да приоритизирате работата.

Основни изводи

• Компрометирането на AD често е верига от легитимни права. Отстраняването на отделна уязвимост не прекъсва непременно веригата.
• Основни мерки са разделяне на административния достъп по нива, LAPS, Credential Guard и ограничени локални административни и операторски групи.
• DCSync от машина, която не е домейн контролер, и достъп до примамлив обект са ценни сигнали за откриване.
• Използвайте BloodHound редовно срещу собствената си среда и проверявайте новите пътища за атака.

Същият граф от гледната точка на SOC

Графът може да бъде приоритизиран списък за укрепване на защитите. Събирайте данни за собствения домейн, маркирайте Tier-0 активите и проверявайте най-кратките маршрути. Сравнявайте резултатите ежемесечно и разглеждайте всяка нова връзка към Tier-0 като потенциален риск. Пресечните точки показват къде малък брой промени могат да прекъснат много пътища.

В пет реда

• AD може да бъде компрометиран чрез верига от права, без единичен експлойт.
• Отстранете ключовите пресечни точки, които прекъсват най-много маршрути.
• Разделянето по нива, LAPS и Credential Guard ограничават много от тези пътища.
• Следете за DCSync от други машини и достъп до примамливи обекти.
• Проверявайте собствения си домейн редовно и сравнявайте новите връзки към Tier-0.

Злоупотреба с ACL: права, които променят графа

Членството в групи е само част от картината. DACL на всеки обект определя допълнителни правомощия. GenericAll върху потребител дава широк контрол; WriteDacl позволява промяна на правата; AddSelf позволява добавяне на собствения акаунт към група. AddKeyCredentialLink позволява запис в атрибута msDS-KeyCredentialLink.

Последното е основа на техниката shadow credentials: нападателят добавя контролиран от него ключов материал и се удостоверява като целевия акаунт чрез PKINIT, без да сменя паролата му.

[Compromised user]
   --AddKeyCredentialLink--> [Target account]
   --PKINIT auth as--> [Target account]
   --MemberOf / further ACL--> [Higher-privileged object]

AD CS: неправилно конфигурирани шаблони за сертификати

Шаблон за сертификат може да позволи представяне за друг потребител. Семейството ESC описва различни конфигурационни проблеми. Често рискът възниква, когато стандартен потребител може да поиска сертификат за клиентско удостоверяване и сам да зададе самоличността в Subject Alternative Name. Други варианти включват правила за агенти за записване, опасни EKU и прекомерни права върху удостоверяващия орган.

Делегиране: когато услуга действа от ваше име

Kerberos делегирането е полезно за многослойни приложения, но е опасно при прекалено широк обхват. Unconstrained delegation може да остави препращаеми TGT билети на услугата. Constrained delegation ограничава целевите услуги, но вариантите с protocol transition също изискват внимателна оценка. При Resource-based constrained delegation (RBCD) целевият ресурс определя кой може да действа от чуждо име чрез msDS-AllowedToActOnBehalfOfOtherIdentity. Право за запис в този атрибут може да позволи добавяне на контролиран от нападателя делегат.

Как се събират сесиите и локалните права

HasSession и AdminTo се изграждат чрез проверки на хостовете за сесии, влезли потребители и членства в локалната група Administrators. Използват се стандартни RPC/SMB интерфейси. Масови заявки от един източник към стотици хостове могат да бъдат наблюдавани.

Източници и допълнително четене

• Microsoft: права за DCSync и репликация върху домейн обекта
• Документация на BloodHound — SpecterOps
• MITRE ATT&CK — каталог на техниките
• Модел на Microsoft за привилегирован достъп
• Преглед на Windows LAPS
• Windows Credential Guard