hacktricks/windows-hardening/active-directory-methodology

Active Directory Methodology

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

• Якщо ви хочете побачити вашу компанію рекламовану на HackTricks або завантажити HackTricks у PDF-форматі, перевірте ПЛАНИ ПІДПИСКИ!
• Отримайте офіційний PEASS & HackTricks мерч
• Дізнайтеся про Сім'ю PEASS, нашу колекцію ексклюзивних NFT
• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @carlospolopm.
• Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв GitHub.

Основний огляд

Active Directory служить як основна технологія, що дозволяє адміністраторам мережі ефективно створювати та керувати доменами, користувачами та об'єктами в мережі. Вона розроблена для масштабування, сприяючи організації великої кількості користувачів у керовані групи та підгрупи, контролюючи права доступу на різних рівнях.

Структура Active Directory складається з трьох основних рівнів: домени, дерева та ліси. Домен охоплює колекцію об'єктів, таких як користувачі або пристрої, які діляться спільною базою даних. Дерева - це групи цих доменів, з'єднаних спільною структурою, а ліс представляє собою колекцію кількох дерев, які взаємодіють через довіру, утворюючи верхній рівень організаційної структури. На кожному з цих рівнів можна призначити конкретні права доступу та комунікації.

Ключові концепції в Active Directory включають:

1. Каталог - Містить всю інформацію, що стосується об'єктів Active Directory.
2. Об'єкт - Позначає сутності в каталозі, включаючи користувачів, групи або спільні папки.
3. Домен - Служить як контейнер для об'єктів каталогу, з можливістю існування кількох доменів у лісі, кожен з яких підтримує власну колекцію об'єктів.
4. Дерево - Групування доменів, які мають спільний кореневий домен.
5. Ліс - Вершина організаційної структури в Active Directory, складена з кількох дерев з довірчими відносинами між ними.

Служби доменів Active Directory (AD DS) охоплюють ряд служб, критичних для централізованого управління та комунікації в мережі. Ці служби включають:

1. Служби доменів - Централізує зберігання даних та керує взаємодіями між користувачами та доменами, включаючи функції аутентифікації та пошуку.
2. Служби сертифікації - Керує створенням, розподілом та управлінням безпечними цифровими сертифікатами.
3. Служби легкого каталогу - Підтримує додатки, що підтримують каталог через протокол LDAP.
4. Служби федерації каталогів - Надає можливості одноразового входу для аутентифікації користувачів у кількох веб-додатках під час однієї сесії.
5. Управління правами - Допомагає захищати авторські матеріали, регулюючи їх незаконне поширення та використання.
6. Служба DNS - Критична для розрішення доменних імен.

Для отримання більш детального пояснення дивіться: TechTerms - Визначення Active Directory

Аутентифікація Kerberos

Щоб вивчити, як здійснювати атаку на AD, вам потрібно добре розуміти процес аутентифікації Kerberos.
Прочитайте цю сторінку, якщо ви все ще не знаєте, як це працює.

Шпаргалка

Ви можете перейти на https://wadcoms.github.io/, щоб швидко переглянути, які команди можна виконати для переліку/експлуатації AD.

Рекон Active Directory (Без облікових даних/сесій)

Якщо у вас є доступ до середовища AD, але ви не маєте жодних облікових даних/сесій, ви можете:

• Пентест мережі:
• Сканувати мережу, знаходити машини та відкриті порти та спробувати експлуатувати вразливості або витягти облікові дані з них (наприклад, принтери можуть бути дуже цікавими цілями.
• Перелік DNS може надати інформацію про ключові сервери в домені, такі як веб, принтери, ресурси, vpn, медіа тощо.
• gobuster dns -d domain.local -t 25 -w /opt/Seclist/Discovery/DNS/subdomain-top2000.txt
• Перегляньте загальну Методологію пентесту, щоб дізнатися більше про це.
• Перевірте доступ до smb-сервісів для null та Guest (це не працюватиме на сучасних версіях Windows):
• enum4linux -a -u "" -p "" <DC IP> && enum4linux -a -u "guest" -p "" <DC IP>
• smbmap -u "" -p "" -P 445 -H <DC IP> && smbmap -u "guest" -p "" -P 445 -H <DC IP>
• smbclient -U '%' -L //<DC IP> && smbclient -U 'guest%' -L //
• Докладний посібник з переліку сервера SMB можна знайти тут:

{% content-ref url="../../network-services-pentesting/pentesting-smb/" %} pentesting-smb {% endcontent-ref %}

• Перелік Ldap
• nmap -n -sV --script "ldap* and not brute" -p 389 <DC IP>
• Докладний посібник з переліку LDAP можна знайти тут (приділіть особливу увагу анонімному доступу):

{% content-ref url="../../network-services-pentesting/pentesting-ldap.md" %} pentesting-ldap.md {% endcontent-ref %}

• Забруднюйте мережу
• Збирайте облікові дані, підробляючи сервіси за допомогою Responder
• Отримуйте доступ до хосту, зловживаючи атакою реле
• Збирайте облікові дані, використовуючи фальшиві служби UPnP з evil-SDP
• OSINT:
• Витягайте імена користувачів/імена з внутрішніх документів, соціальних мереж, служб (головним чином веб-сервісів) в середовищах домену та також з загальнодоступних.
• Якщо ви знаходите повні імена працівників компанії, ви можете спробувати різні конвенції імен користувачів AD (прочитайте це). Найпоширеніші конвенції імен: Ім'яПрізвище, Ім'я.Прізвище, Ім'яПрізвище (3 літери кожного), Ім'я.Прізвище, ПрізвищеІм'я, Прізвище.Ім'я, ПрізвищеІ, Прізвище.І, 3 випадкові літери та 3 випадкові числа (abc123).
• Інструменти:
• w0Tx/generate-ad-username
• urbanadventurer/username-anarchy

Перелік користувачів

• Анонімне SMB/LDAP перелікування: Перевірте сторінки pentesting SMB та pentesting LDAP.
• Kerbrute перелік: Коли запитується недійсне ім'я користувача, сервер відповість за допомогою помилки Kerberos KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN, що дозволяє нам визначити, що ім'я користувача є недійсним. Дійсні імена користувачів викличуть або TGT у відповіді AS-REP, або помилку KRB5KDC_ERR_PREAUTH_REQUIRED, що вказує на необхідність користувача виконати попередню аутентифікацію.

./kerbrute_linux_amd64 userenum -d lab.ropnop.com --dc 10.10.10.10 usernames.txt #From https://github.com/ropnop/kerbrute/releases

nmap -p 88 --script=krb5-enum-users --script-args="krb5-enum-users.realm='DOMAIN'" <IP>
Nmap -p 88 --script=krb5-enum-users --script-args krb5-enum-users.realm='<domain>',userdb=/root/Desktop/usernames.txt <IP>

msf> use auxiliary/gather/kerberos_enumusers

crackmapexec smb dominio.es  -u '' -p '' --users | awk '{print $4}' | uniq

• Сервер OWA (Outlook Web Access)

Якщо ви знайшли один з цих серверів в мережі, ви також можете виконати перелік користувачів проти нього. Наприклад, ви можете використати інструмент MailSniper:

ipmo C:\Tools\MailSniper\MailSniper.ps1
# Get info about the domain
Invoke-DomainHarvestOWA -ExchHostname [ip]
# Enumerate valid users from a list of potential usernames
Invoke-UsernameHarvestOWA -ExchHostname [ip] -Domain [domain] -UserList .\possible-usernames.txt -OutFile valid.txt
# Password spraying
Invoke-PasswordSprayOWA -ExchHostname [ip] -UserList .\valid.txt -Password Summer2021
# Get addresses list from the compromised mail
Get-GlobalAddressList -ExchHostname [ip] -UserName [domain]\[username] -Password Summer2021 -OutFile gal.txt

{% hint style="warning" %} Ви можете знайти списки імен користувачів у цьому репозиторії GitHub та цьому (statistically-likely-usernames).

Однак вам слід мати ім'я людей, які працюють у компанії з кроку реконнесансу, який ви повинні були виконати до цього. З ім'ям та прізвищем ви можете використовувати скрипт namemash.py для генерації потенційно дійсних імен користувачів. {% endhint %}

Знання одного або кількох імен користувачів

Добре, ви вже знаєте, що у вас є дійсне ім'я користувача, але немає паролів... Тоді спробуйте:

• ASREPRoast: Якщо у користувача немає атрибуту DONT_REQ_PREAUTH, ви можете запитати повідомлення AS_REP для цього користувача, яке буде містити деякі дані, зашифровані похідним від пароля користувача.
• Парольне розпилення: Спробуйте найпоширеніші паролі з кожним з виявлених користувачів, можливо, деякі користувачі використовують поганий пароль (пам'ятайте про політику паролів!).
• Зверніть увагу, що ви також можете розпилювати сервери OWA, щоб спробувати отримати доступ до поштових серверів користувачів.

{% content-ref url="password-spraying.md" %} password-spraying.md {% endcontent-ref %}

Отруєння LLMNR/NBT-NS

Ви можете отримати деякі хеші виклику для взлому, отруюючи деякі протоколи мережі:

{% content-ref url="../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md" %} spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md {% endcontent-ref %}

Пересилання NTML

Якщо вам вдалося перелічити активний каталог, ви матимете більше електронних листів та краще розуміння мережі. Ви можете спробувати змусити пересилання NTML атак **** для отримання доступу до середовища AD.

Крадіжка облікових даних NTLM

Якщо ви можете отримати доступ до інших ПК або ресурсів за допомогою нульового або гостьового користувача, ви можете розмістити файли (наприклад, файл SCF), які, якщо вони будуть якимось чином доступні, спричинять аутентифікацію NTML проти вас, щоб ви могли вкрасти виклик NTLM для його взлому:

{% content-ref url="../ntlm/places-to-steal-ntlm-creds.md" %} places-to-steal-ntlm-creds.md {% endcontent-ref %}

Перелік активних каталогів З обліковими даними/сесією

Для цієї фази вам потрібно було компрометувати облікові дані або сесію дійсного доменного облікового запису. Якщо у вас є деякі дійсні облікові дані або оболонка як доменного користувача, пам'ятайте, що варіанти, наведені раніше, все ще є варіантами для компрометації інших користувачів.

Перед початком аутентифікованого переліку вам слід знати, що таке проблема подвійного стрибка Kerberos.

{% content-ref url="kerberos-double-hop-problem.md" %} kerberos-double-hop-problem.md {% endcontent-ref %}

Перелік

Компрометація облікового запису є великим кроком для початку компрометації всього домену, оскільки ви зможете почати перелік активних каталогів:

Щодо ASREPRoast ви можете знайти кожного можливого вразливого користувача, а щодо Парольного розпилення ви можете отримати список усіх імен користувачів та спробувати пароль облікового запису, порожні паролі та нові перспективні паролі.

• Ви можете використовувати CMD для виконання базового рекону
• Ви також можете використовувати powershell для рекону, що буде більш прихованим
• Ви також можете використовувати powerview для отримання більш детальної інформації
• Ще одним дивовижним інструментом для рекону в активному каталозі є BloodHound. Він не дуже прихований (залежно від методів збору, які ви використовуєте), але якщо ви не турбуєтеся про це, вам слід абсолютно спробувати. Знайдіть, де користувачі можуть підключатися за допомогою RDP, знайдіть шлях до інших груп тощо.
• Інші автоматизовані інструменти для переліку AD: AD Explorer, ADRecon, Group3r, PingCastle.
• DNS-записи AD, оскільки вони можуть містити цікаву інформацію.
• Інструмент з графічним інтерфейсом, який ви можете використовувати для переліку каталогу, це AdExplorer.exe з SysInternal Suite.
• Ви також можете шукати в базі даних LDAP за допомогою ldapsearch для пошуку облікових даних у полях userPassword та unixUserPassword, або навіть для Description. див. Пароль в коментарі користувача AD на PayloadsAllTheThings для інших методів.
• Якщо ви використовуєте Linux, ви також можете перелічити домен за допомогою pywerview.
• Ви також можете спробувати автоматизовані інструменти, такі як:
• tomcarver16/ADSearch
• 61106960/adPEAS
• Видобуток усіх користувачів домену

Дуже легко отримати всі імена користувачів домену з Windows (net user /domain, Get-DomainUser або wmic useraccount get name,sid). У Linux ви можете використовувати: GetADUsers.py -all -dc-ip 10.10.10.110 domain.com/username або enum4linux -a -u "user" -p "password" <DC IP>

Навіть якщо цей розділ Переліку виглядає невеликим, це найважливіша частина. Звертайтеся до посилань (головним чином до посилань на cmd, powershell, powerview та BloodHound), вивчайте, як перелічити домен, і практикуйте, поки не почуєте себе впевнено. Під час оцінки це буде ключовий момент для знаходження шляху до DA або вирішення питання, чи можна щось зробити.

Kerberoast

Kerberoasting включає отримання TGS-квитків, які використовуються службами, пов'язаними з обліковими записами користувачів, та взлому їх шифрування—яке базується на паролях користувачів—офлайн.

Докладніше про це в:

{% content-ref url="kerberoast.md" %} kerberoast.md {% endcontent-ref %}

Віддалене підключення (RDP, SSH, FTP, Win-RM, тощо)

Після того, як ви отримали деякі облікові дані, ви можете перевірити, чи маєте ви доступ до будь-якої машини. Для цього ви можете використовувати CrackMapExec, щоб спробувати підключитися до кількох серверів за допомогою різних протоколів, відповідно до результатів сканування портів.

Підвищення привілеїв на локальному рівні

Якщо у вас є компрометовані облікові дані або сесія як звичайного користувача домену і ви маєте доступ до будь-якої машини в домені за допомогою цього користувача, вам слід спробувати знайти спосіб підвищення привілеїв локально та викрадення облікових даних. Це тому, що лише з привілеями локального адміністратора ви зможете витягти хеші інших користувачів у пам'яті (LSASS) та локально (SAM).

У цій книзі є повна сторінка про підвищення привілеїв на локальному рівні в Windows та чеклист. Також не забудьте використовувати WinPEAS.

Поточні квитки сесії

Дуже малоймовірно, що ви знайдете квитки поточного користувача, які надають вам дозвіл на доступ до неочікуваних ресурсів, але ви можете перевірити:

## List all tickets (if not admin, only current user tickets)
.\Rubeus.exe triage
## Dump the interesting one by luid
.\Rubeus.exe dump /service:krbtgt /luid:<luid> /nowrap
[IO.File]::WriteAllBytes("ticket.kirbi", [Convert]::FromBase64String("<BASE64_TICKET>"))

NTML Relay

Якщо вам вдалося перелічити активний каталог, ви матимете більше електронних листів та краще розуміння мережі. Ви, можливо, зможете змусити атаки пересилання NTML.

Пошук облікових даних в розділах комп'ютерів

Тепер, коли у вас є деякі базові облікові дані, ви повинні перевірити, чи можете ви знайти які-небудь цікаві файли, які діляться всередині AD. Ви можете зробити це вручну, але це дуже нудна повторювана задача (особливо, якщо ви знаходите сотні документів, які потрібно перевірити).

Перейдіть за цим посиланням, щоб дізнатися про інструменти, які ви можете використовувати.

Вкрадіть облікові дані NTLM

Якщо ви можете отримати доступ до інших ПК або розділів, ви можете розмістити файли (наприклад, файл SCF), які, якщо їх якось отримають доступ, спричинять аутентифікацію NTML проти вас, щоб ви могли вкрасти виклик NTLM, щоб розшифрувати його:

{% content-ref url="../ntlm/places-to-steal-ntlm-creds.md" %} places-to-steal-ntlm-creds.md {% endcontent-ref %}

CVE-2021-1675/CVE-2021-34527 PrintNightmare

Ця уразливість дозволяла будь-якому аутентифікованому користувачеві компрометувати контролер домену.

{% content-ref url="printnightmare.md" %} printnightmare.md {% endcontent-ref %}

Підвищення привілеїв на Active Directory З привілейованими обліковими даними/сесією

Для наступних технік звичайного користувача домену недостатньо, вам потрібні деякі спеціальні привілеї/облікові дані для виконання цих атак.

Вилучення хешу

Сподіваюсь, вам вдалося компрометувати деякий локальний обліковий запис адміністратора за допомогою AsRepRoast, Password Spraying, Kerberoast, Responder, включаючи пересилання, EvilSSDP, підвищення привілеїв локально.
Тоді час витягнути всі хеші в пам'яті та локально.
Прочитайте цю сторінку про різні способи отримання хешів.

Передача хешу

Якщо у вас є хеш користувача, ви можете використовувати його для імітації.
Вам потрібно використовувати деякий інструмент, який буде виконувати аутентифікацію NTLM, використовуючи цей хеш, або ви можете створити новий sessionlogon та впровадити цей хеш всередину LSASS, тому коли буде виконано будь-яку аутентифікацію NTLM, цей хеш буде використаний. Остання опція - це те, що робить mimikatz.
Прочитайте цю сторінку для отримання додаткової інформації.

Передача хешу через Kerberos/Передача ключа

Ця атака спрямована на використання хешу NTLM користувача для запиту квитків Kerberos, як альтернативу звичайному передачі хешу через протокол NTLM. Таким чином, це може бути особливо корисним в мережах, де відключений протокол NTLM, і дозволено лише Kerberos як протокол аутентифікації.

{% content-ref url="over-pass-the-hash-pass-the-key.md" %} over-pass-the-hash-pass-the-key.md {% endcontent-ref %}

Передача квитка

У методі атаки Pass The Ticket (PTT) зловмисники крадуть аутентифікаційний квиток користувача замість їх пароля або хешів. Цей викрадений квиток потім використовується для імітації користувача, отримуючи несанкціонований доступ до ресурсів та служб всередині мережі.

{% content-ref url="pass-the-ticket.md" %} pass-the-ticket.md {% endcontent-ref %}

Повторне використання облікових даних

Якщо у вас є хеш або пароль локального адміністратора, вам слід спробувати ввійти локально на інші ПК з ним.

# Local Auth Spray (once you found some local admin pass or hash)
## --local-auth flag indicate to only try 1 time per machine
crackmapexec smb --local-auth 10.10.10.10/23 -u administrator -H 10298e182387f9cab376ecd08491764a0 | grep +

{% hint style="warning" %} Зверніть увагу, що це досить шумно і LAPS допоможе це пом'якшити. {% endhint %}

Зловживання MSSQL та Довірені посилання

Якщо користувач має привілеї для доступу до екземплярів MSSQL, він може використовувати це для виконання команд на хості MSSQL (якщо він працює як SA), вкрасти хеш NetNTLM або навіть виконати атаку ретрансляції.
Також, якщо екземпляр MSSQL є довіреним (посилання на базу даних) іншим екземпляром MSSQL. Якщо у користувача є привілеї щодо довіреної бази даних, він зможе використовувати довіреність для виконання запитів також в іншому екземплярі. Ці довіри можуть бути ланцюжковими, і на певному етапі користувач може знайти неправильно налаштовану базу даних, де він може виконувати команди.
Посилання між базами даних працюють навіть через довіреність лісів.

{% content-ref url="abusing-ad-mssql.md" %} abusing-ad-mssql.md {% endcontent-ref %}

Неконтрольована делегація

Якщо ви знаходите будь-який об'єкт Комп'ютера з атрибутом ADS_UF_TRUSTED_FOR_DELEGATION і маєте привілеї домену на комп'ютері, ви зможете витягти TGT з пам'яті кожного користувача, який увійшов на комп'ютер.
Таким чином, якщо Адміністратор домену увійшов на комп'ютер, ви зможете витягти його TGT та уособлювати його, використовуючи Pass the Ticket.
Завдяки обмеженій делегації ви навіть можете автоматично скомпрометувати Друковий сервер (сподіваємося, що це буде DC).

{% content-ref url="unconstrained-delegation.md" %} unconstrained-delegation.md {% endcontent-ref %}

Обмежена делегація

Якщо користувачу або комп'ютеру дозволено "Обмежену делегацію", він зможе уособлювати будь-якого користувача для доступу до деяких служб на комп'ютері.
Отже, якщо ви компрометуєте хеш цього користувача/комп'ютера, ви зможете уособлювати будь-якого користувача (навіть доменних адміністраторів) для доступу до деяких служб.

{% content-ref url="constrained-delegation.md" %} constrained-delegation.md {% endcontent-ref %}

Обмеження делегації на основі ресурсів

Маючи привілеї ЗАПИСУ на об'єкт Active Directory віддаленого комп'ютера, можна отримати виконання коду з підвищеними привілеями:

{% content-ref url="resource-based-constrained-delegation.md" %} resource-based-constrained-delegation.md {% endcontent-ref %}

Зловживання ACL

Компрометований користувач може мати деякі цікаві привілеї щодо деяких об'єктів домену, які можуть дозволити вам переміщатися бічно/підвищувати привілеї.

{% content-ref url="acl-persistence-abuse/" %} acl-persistence-abuse {% endcontent-ref %}

Зловживання служби друкування

Виявлення служби спулера, яка прослуховує в межах домену може бути зловживано для отримання нових облікових даних та підвищення привілеїв.

{% content-ref url="acl-persistence-abuse/" %} acl-persistence-abuse {% endcontent-ref %}

Зловживання сеансами сторонніх вендорів

Якщо інші користувачі отримують доступ до компрометованого комп'ютера, можливо збирати облікові дані з пам'яті та навіть впроваджувати маяки в їх процеси для уособлення їх.
Зазвичай користувачі отримують доступ до системи через RDP, отже, ось як виконати кілька атак над сеансами RDP сторонніх вендорів:

{% content-ref url="rdp-sessions-abuse.md" %} rdp-sessions-abuse.md {% endcontent-ref %}

LAPS

LAPS надає систему для управління паролем локального адміністратора на комп'ютерах, приєднаних до домену, забезпечуючи його випадковість, унікальність та часту зміну. Ці паролі зберігаються в Active Directory, а доступ контролюється через ACL лише для авторизованих користувачів. З достатніми дозволами для доступу до цих паролів стає можливим перехід на інші комп'ютери.

{% content-ref url="laps.md" %} laps.md {% endcontent-ref %}

Крадіжка сертифікатів

Збір сертифікатів з компрометованого комп'ютера може бути способом підвищення привілеїв всередині середовища:

{% content-ref url="ad-certificates/certificate-theft.md" %} certificate-theft.md {% endcontent-ref %}

Зловживання шаблонами сертифікатів

Якщо налаштовані вразливі шаблони, можна їх зловживати для підвищення привілеїв:

{% content-ref url="ad-certificates/domain-escalation.md" %} domain-escalation.md {% endcontent-ref %}

Післяексплуатація з обліковим записом високих привілеїв

Витягування облікових даних домену

Як тільки ви отримаєте привілеї Адміністратора домену або навіть краще Адміністратора підприємства, ви можете витягти базу даних домену: ntds.dit.

Додаткова інформація про атаку DCSync може бути знайдена тут.

Додаткова інформація про те, як викрасти NTDS.dit, можна знайти тут

Підвищення привілеїв як постійність

Деякі з технік, про які йшлося раніше, можуть бути використані для постійності.
Наприклад, ви можете:

• Зробити користувачів вразливими до Kerberoast

Set-DomainObject -Identity <username> -Set @{serviceprincipalname="fake/NOTHING"}r

• Зробити користувачів вразливими до ASREPRoast

Set-DomainObject -Identity <username> -XOR @{UserAccountControl=4194304}

• Надати привілеї DCSync користувачеві

Add-DomainObjectAcl -TargetIdentity "DC=SUB,DC=DOMAIN,DC=LOCAL" -PrincipalIdentity bfarmer -Rights DCSync

Срібний квиток

Атака Срібний квиток створює легітимний квиток служби отримання квитків (TGS) для певної служби, використовуючи хеш NTLM (наприклад, хеш облікового запису ПК). Цей метод використовується для доступу до привілеїв служби.

{% content-ref url="silver-ticket.md" %} silver-ticket.md {% endcontent-ref %}

Золотий квиток

Атака Золотий квиток передбачає, що зловмисник отримує доступ до хешу NTLM облікового запису krbtgt в середовищі Active Directory (AD). Цей обліковий запис особливий, оскільки він використовується для підпису всіх Квитків для отримання квитків (TGT), які є важливими для аутентифікації в мережі AD.

Як тільки зловмисник отримує цей хеш, він може створювати TGT для будь-якого облікового запису, який вибере (атака срібний квиток).

{% content-ref url="golden-ticket.md" %} golden-ticket.md {% endcontent-ref %}

Атака алмазним квитком

Це схоже на золоті квитки, сфальсифіковані таким чином, що обхід механізмів виявлення золотих квитків.

{% content-ref url="diamond-ticket.md" %} diamond-ticket.md {% endcontent-ref %}

Постійність облікового запису сертифікатів

Мати сертифікати облікового запису або мати можливість запитувати їх - це дуже хороший спосіб мати можливість персистувати в обліковому записі користувача (навіть якщо він змінює пароль):

{% content-ref url="ad-certificates/account-persistence.md" %} account-persistence.md {% endcontent-ref %}

Персистентність домену сертифікатів

Використання сертифікатів також можливо для постійного збереження з високими привілеями всередині домену:

{% content-ref url="ad-certificates/domain-persistence.md" %} domain-persistence.md {% endcontent-ref %}

Група AdminSDHolder

Об'єкт AdminSDHolder в Active Directory забезпечує безпеку привілейованих груп (таких як Domain Admins та Enterprise Admins), застосовуючи стандартний список керування доступом (ACL) для цих груп, щоб запобігти несанкціонованим змінам. Однак цю функцію можна зловживати; якщо зловмисник змінює ACL AdminSDHolder, щоб надати повний доступ звичайному користувачеві, цей користувач отримує широкий контроль над усіма привілейованими групами. Ця захисна міра, призначена для захисту, може відбитися назад, дозволяючи неправомірний доступ, якщо не буде уважно контрольовано.

Додаткова інформація про групу AdminDSHolder тут.

Облікові дані DSRM

У кожному контролері домену (DC) існує обліковий запис локального адміністратора. Отримавши права адміністратора на такому пристрої, хеш локального адміністратора можна витягнути за допомогою mimikatz. Після цього необхідно внести зміни в реєстр для активації використання цього пароля, що дозволить віддалений доступ до облікового запису локального адміністратора.

{% content-ref url="dsrm-credentials.md" %} dsrm-credentials.md {% endcontent-ref %}

Постійність ACL

Ви можете надати деякі спеціальні дозволи користувачеві для деяких конкретних об'єктів домену, що дозволить користувачеві підвищити привілеї у майбутньому.

{% content-ref url="acl-persistence-abuse/" %} acl-persistence-abuse {% endcontent-ref %}

Дескриптори безпеки

Дескриптори безпеки використовуються для зберігання дозволів, які об'єкт має над об'єктом. Якщо ви просто внесете невелику зміну в дескриптор безпеки об'єкта, ви можете отримати дуже цікаві привілеї над цим об'єктом, не будучи членом привілейованої групи.

{% content-ref url="security-descriptors.md" %} security-descriptors.md {% endcontent-ref %}

Скелетний ключ

Змініть LSASS в пам'яті, щоб встановити універсальний пароль, надаючи доступ до всіх облікових записів домену.

{% content-ref url="skeleton-key.md" %} skeleton-key.md {% endcontent-ref %}

Власний SSP

Дізнайтеся, що таке SSP (Постачальник підтримки безпеки) тут.
Ви можете створити свій власний SSP, щоб захопити в чистому тексті облікові дані, які використовуються для доступу до машини.\

{% content-ref url="custom-ssp.md" %} custom-ssp.md {% endcontent-ref %}

DCShadow

Це реєструє новий контролер домену в AD та використовує його для передачі атрибутів (SIDHistory, SPNs...) на вказані об'єкти без залишення будь-яких журналів щодо змін. Вам потрібні привілеї DA та бути всередині кореневого домену.
Зверніть увагу, що якщо ви використовуєте неправильні дані, з'являться досить неприємні журнали.

{% content-ref url="dcshadow.md" %} dcshadow.md {% endcontent-ref %}

Постійність LAPS

Раніше ми обговорювали, як підвищити привілеї, якщо у вас є достатньо дозволів для читання паролів LAPS. Однак ці паролі також можуть бути використані для збереження постійності.
Перевірте:

{% content-ref url="laps.md" %} laps.md {% endcontent-ref %}

Підвищення привілеїв лісу - Довіри доменів

Microsoft розглядає Ліс як межу безпеки. Це означає, що компрометація одного домену може потенційно призвести до компрометації всього Лісу.

Основна інформація

Довіра домену - це механізм безпеки, який дозволяє користувачеві з одного домену отримувати доступ до ресурсів в іншому домені. По суті, вона створює зв'язок між системами аутентифікації двох доменів, що дозволяє безперервному потоку перевірок аутентифікації. При налаштуванні довіри обмінюються та зберігаються конкретні ключі в їх контролерах домену (DC), які є важливими для цілісності довіри.

У типовому сценарії, якщо користувач має намір отримати доступ до служби в довіреному домені, він повинен спочатку запросити спеціальний квиток, відомий як міждоменний TGT, від свого власного DC. Цей TGT шифрується за допомогою спільного ключа, на якому домени домовилися. Потім користувач представляє цей TGT DC довіреного домену, щоб отримати квиток служби (TGS). Після успішної перевірки міждоменного TGT DC довіреного домену видає TGS, надаючи користувачеві доступ до служби.

Кроки:

1. Клієнтський комп'ютер в Домені 1 починає процес, використовуючи свій хеш NTLM для запиту Квитка на надання доступу (TGT) від свого Контролера домену (DC1).
2. DC1 видає новий TGT, якщо клієнт успішно аутентифікується.
3. Потім клієнт запитує міждоменний TGT від DC1, який потрібний для доступу до ресурсів в Домені 2.
4. Міждоменний TGT шифрується ключем довіри, який ділиться між DC1 та DC2 як частина двосторонньої довіри.
5. Клієнт бере міждоменний TGT до Контролера домену Домену 2 (DC2).
6. DC2 перевіряє міждоменний TGT за допомогою спільного ключа довіри та, якщо він є дійсним, видає Квиток служби на надання доступу (TGS) для сервера в Домені 2, до якого клієнт хоче отримати доступ.
7. Нарешті, клієнт представляє цей TGS серверу, який шифрується хешем облікового запису сервера, щоб отримати доступ до служби в Домені 2.

Різні довіри

Важливо помітити, що довіра може бути односторонньою або двосторонньою. У варіантах двосторонньої довіри обидва домени будуть довіряти один одному, але в односторонньому відношенні довіри один з доменів буде довіреним, а інший - довіряючим доменом. У останньому випадку ви зможете отримати доступ лише до ресурсів всередині довіряючого домену з довіреного.

Якщо Домен A довіряє Домену B, A є довіряючим доменом, а B - довіреним. Крім того, в Домені A це буде Вихідний довір; а в Домені B - Вхідний довір.

Різні відносини довіри

• Батьківські-Дитячі Довіри: Це загальна настройка всередині одного лісу, де дитячий домен автоматично має двосторонню транзитивну довіру з батьківським доменом. По суті, це означає, що запити аутентифікації можуть безперервно переходити між батьківським та дитячим.
• Перехресні Довіри: Їх називають "скороченими довірами" і вони встановлюються між дитячими доменами для прискорення процесів посилань. У складних лісах зазвичай референції аутентифікації повинні подорожувати до кореня лісу, а потім до цільового домену. Створюючи перехресні посилання, маршрут скорочується, що особливо корисно в географічно розподілених середовищах.
• Зовнішні Довіри: Вони встановлюються між різними, не пов'язаними доменами і є неперехідними за своєю природою. Згідно з документацією Microsoft, зовнішні довіри корисні для доступу до ресурсів в домені поза поточним лісом, який не підключений за довірою лісу. Безпеку підсилюється за допомогою фільтрації SID зовнішніх довір.
• Довіри Кореня Дерева: Ці довіри автоматично встановлюються між коренем лісу та ново доданим коренем дерева. Хоча це не зустрічається часто, довіри кореня дерева важливі для додавання нових дерев доменів до лісу, дозволяючи їм зберігати унікальне ім'я домену та забезпечуючи двосторонню транзитивність. Додаткову інформацію можна знайти в посібнику Microsoft.
• Довіри Лісу: Цей тип довіри - це двостороння транзитивна довіра між двома кореневими доменами лісу, також зміцнюється фільтрацією SID для підвищення заходів безпеки.
• Довіри MIT: Ці довіри встановлюються з непристр

Інші відмінності в довірчих відносинах

• Довірчий зв'язок може бути також транзитивним (A довіряє B, B довіряє C, тоді A довіряє C) або нетранзитивним.
• Довірчий зв'язок може бути налаштований як двосторонній довірчий (обидва довіряють один одному) або як односторонній довірчий (лише один з них довіряє іншому).

Шлях атаки

1. Перелічіть довірчі відносини
2. Перевірте, чи має який-небудь безпечний принципал (користувач/група/комп'ютер) доступ до ресурсів іншого домену, можливо за допомогою записів ACE або за наявності в групах іншого домену. Шукайте відносини між доменами (довіра була створена, ймовірно, для цього).
3. У цьому випадку може бути ще один варіант - kerberoast.
4. Компрометуйте акаунти, які можуть перехоплювати через домени.

Зловмисники можуть мати доступ до ресурсів в іншому домені за допомогою трьох основних механізмів:

• Членство в локальній групі: Принципали можуть бути додані до локальних груп на машинах, таких як група "Адміністратори" на сервері, що надає їм значний контроль над цією машиною.
• Членство в групі іншого домену: Принципали також можуть бути членами груп у іншому домені. Однак ефективність цього методу залежить від характеру довіри та обсягу групи.
• Списки керування доступом (ACL): Принципали можуть бути вказані в ACL, зокрема як сутності в ACE в межах DACL, що надає їм доступ до конкретних ресурсів. Для тих, хто бажає докладніше вивчити механіку ACL, DACL та ACE, біла книга під назвою "An ACE Up The Sleeve" є невичерпним джерелом інформації.

Підвищення привілеїв лісу від дитини до батька

Get-DomainTrust

SourceName      : sub.domain.local    --> current domain
TargetName      : domain.local        --> foreign domain
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : WITHIN_FOREST       --> WITHIN_FOREST: Both in the same forest
TrustDirection  : Bidirectional       --> Trust direction (2ways in this case)
WhenCreated     : 2/19/2021 1:28:00 PM
WhenChanged     : 2/19/2021 1:28:00 PM

{% hint style="warning" %} Є 2 довірених ключі, один для Дитина --> Батько і інший для Батько --> Дитина.
Ви можете використовувати той, який використовується в поточному домені, за допомогою:

Invoke-Mimikatz -Command '"lsadump::trust /patch"' -ComputerName dc.my.domain.local
Invoke-Mimikatz -Command '"lsadump::dcsync /user:dcorp\mcorp$"'

{% endhint %}

Впровадження SID-History

Ескалація до рівня адміністратора підприємства в дитячому/батьківському домені, зловживаючи довірою за допомогою впровадження SID-History:

{% content-ref url="sid-history-injection.md" %} sid-history-injection.md {% endcontent-ref %}

Використання записуваного NC конфігурації

Розуміння того, як можна використовувати NC конфігурації (Configuration Naming Context) є критичним. NC конфігурації служить центральним сховищем для даних конфігурації у всьому лісі в середовищах Active Directory (AD). Ці дані реплікуються на кожен контролер домену (DC) у лісі, з записними DC, які підтримують записну копію NC конфігурації. Для використання цього, потрібно мати привілеї SYSTEM на DC, краще на дитячому DC.

Посилання GPO на кореневий DC сайт

Контейнер сайтів NC конфігурації містить інформацію про всі сайти комп'ютерів, приєднаних до домену, у лісі AD. Операцію з привілеями SYSTEM на будь-якому DC, зловмисники можуть посилати GPO на сайти кореневого DC. Ця дія потенційно компрометує кореневий домен шляхом маніпулювання політиками, які застосовуються до цих сайтів.

Для докладної інформації можна дослідити дослідження про Обхід фільтрації SID.

Компрометація будь-якого gMSA в лісі

Вектор атаки включає націлювання привілейованих gMSA в межах домену. Ключ KDS Root, необхідний для обчислення паролів gMSA, зберігається в NC конфігурації. З привілеями SYSTEM на будь-якому DC можливий доступ до ключа KDS Root та обчислення паролів для будь-якого gMSA у всьому лісі.

Детальний аналіз можна знайти в обговоренні Атак на довірчість Golden gMSA.

Атака на зміну схеми

Цей метод вимагає терпіння, очікуючи створення нових привілейованих об'єктів AD. З привілеями SYSTEM зловмисник може змінити схему AD, щоб надати будь-якому користувачеві повний контроль над усіма класами. Це може призвести до несанкціонованого доступу та контролю над новими створеними об'єктами AD.

Додаткову інформацію можна знайти в Атаках на довірчість зміни схеми.

Від DA до EA з ADCS ESC5

Уразливість ADCS ESC5 націлює контроль над об'єктами Інфраструктури відкритих ключів (PKI) для створення шаблону сертифіката, який дозволяє аутентифікацію як будь-якого користувача у лісі. Оскільки об'єкти PKI розташовані в NC конфігурації, компрометація записного дитячого DC дозволяє виконання атак ESC5.

Додаткові деталі можна прочитати в Від DA до EA з ESC5. У сценаріях, де відсутній ADCS, зловмисник має можливість налаштувати необхідні компоненти, як обговорюється в Ескалація від адміністраторів дитячих доменів до адміністраторів підприємства.

Зовнішній лісовий домен - односторонній (вхідний) або двосторонній

Get-DomainTrust
SourceName      : a.domain.local   --> Current domain
TargetName      : domain.external  --> Destination domain
TrustType       : WINDOWS-ACTIVE_DIRECTORY
TrustAttributes :
TrustDirection  : Inbound          --> Inboud trust
WhenCreated     : 2/19/2021 10:50:56 PM
WhenChanged     : 2/19/2021 10:50:56 PM

У цьому сценарії ваш домен довіряється зовнішньому, що надає вам невизначені дозволи над ним. Вам потрібно знайти які принципали вашого домену мають доступ до зовнішнього домену і спробувати використати це:

{% content-ref url="external-forest-domain-oneway-inbound.md" %} external-forest-domain-oneway-inbound.md {% endcontent-ref %}

Зовнішній Лісовий Домен - Однобічний (Вихідний)

Get-DomainTrust -Domain current.local

SourceName      : current.local   --> Current domain
TargetName      : external.local  --> Destination domain
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : FOREST_TRANSITIVE
TrustDirection  : Outbound        --> Outbound trust
WhenCreated     : 2/19/2021 10:15:24 PM
WhenChanged     : 2/19/2021 10:15:24 PM

У цьому сценарії ваш домен надає деякі привілеї принципалу з інших доменів.

Проте, коли домен довіряється довіряючим доменом, довірений домен створює користувача з передбачуваним ім'ям, яке використовується як пароль довіреного пароля. Це означає, що можливо отримати доступ до користувача з довіреного домену, щоб потрапити в довірений для його переліку та спроби підвищення привілеїв:

{% content-ref url="external-forest-domain-one-way-outbound.md" %} external-forest-domain-one-way-outbound.md {% endcontent-ref %}

Іншим способом компрометування довіреного домену є знаходження SQL довіреного посилання, створеного в протилежному напрямку довіри до домену (що не є дуже поширеним).

Ще одним способом компрометування довіреного домену є очікування на машині, де користувач з довіреного домену може отримати доступ, щоб увійти через RDP. Потім зловмисник може впровадити код у процес сеансу RDP та отримати доступ до домену жертви звідти.
Більше того, якщо жертва підключила свій жорсткий диск, з процесу сеансу RDP зловмисник може зберігати задні входи в папці автозапуску жорсткого диска. Ця техніка називається RDPInception.

{% content-ref url="rdp-sessions-abuse.md" %} rdp-sessions-abuse.md {% endcontent-ref %}

Зменшення зловживання довіри до домену

Фільтрація SID:

• Ризик атак, які використовують атрибут історії SID через довіру між лісами, зменшується за допомогою фільтрації SID, яка активується за замовчуванням на всіх міжлісових довірах. Це ґрунтується на припущенні, що внутрішні ліси є безпечними, вважаючи ліс, а не домен, як границю безпеки згідно з позицією Microsoft.
• Однак є підводний камінь: фільтрація SID може порушити роботу додатків та доступ користувачів, що призводить до її випадкового вимкнення.

Вибіркова аутентифікація:

• Для міжлісових довір, використання вибіркової аутентифікації забезпечує, що користувачі з двох лісів не автоматично аутентифікуються. Замість цього для доступу користувачів до доменів та серверів у довіряючому домені або лісі потрібні явні дозволи.
• Важливо зауважити, що ці заходи не захищають від експлуатації записуваного контексту імені конфігурації (NC) або атак на обліковий запис довіри.

Додаткова інформація про довіру до доменів на ired.team.

AD -> Azure & Azure -> AD

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-lateral-movements/azure-ad-connect-hybrid-identity" %}

Деякі загальні заходи захисту

Дізнайтеся більше про захист облікових даних тут.\

Захисні заходи для захисту облікових даних

• Обмеження адміністраторів домену: Рекомендується, щоб адміністратори домену могли увійти тільки на контролери доменів, уникнувши їх використання на інших хостах.
• Привілеї облікових записів служб: Служби не повинні запускатися з привілеями адміністратора домену (DA) для забезпечення безпеки.
• Обмеження тимчасових привілеїв: Для завдань, які вимагають привілеїв адміністратора домену, їх тривалість повинна бути обмежена. Це можна досягти за допомогою: Add-ADGroupMember -Identity ‘Domain Admins’ -Members newDA -MemberTimeToLive (New-TimeSpan -Minutes 20)

Впровадження технік обману

• Впровадження обману включає встановлення пасток, таких як манекени користувачів або комп'ютерів, з функціями, такими як паролі, які не закінчуються або позначені як довірені для делегування. Детальний підхід включає створення користувачів з конкретними правами або додавання їх до груп високих привілеїв.
• Практичний приклад включає використання інструментів, таких як: Create-DecoyUser -UserFirstName user -UserLastName manager-uncommon -Password Pass@123 | DeployUserDeception -UserFlag PasswordNeverExpires -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose
• Додаткову інформацію про впровадження технік обману можна знайти на Deploy-Deception on GitHub.

Виявлення обману

• Для об'єктів користувача: Підозрілі показники включають нетиповий ObjectSID, рідкісні входи, дати створення та низькі показники поганих паролів.
• Загальні показники: Порівняння атрибутів потенційних об'єктів-пасток з атрибутами справжніх може розкрити неузгодженості. Інструменти, такі як HoneypotBuster, можуть допомогти в ідентифікації таких обманів.

Обхід систем виявлення

• Обхід виявлення Microsoft ATA:
• Перелік користувачів: Уникання переліку сеансів на контролерах доменів для запобігання виявленню ATA.
• Імітація квитків: Використання ключів aes для створення квитків допомагає уникнути виявлення, не знижуючи до NTLM.
• Атаки DCSync: Виконання з недоменного контролера домену для уникнення виявлення ATA рекомендується, оскільки пряме виконання з контролера домену спричинить сповіщення.

Посилання

• http://www.harmj0y.net/blog/redteaming/a-guide-to-attacking-domain-trusts/
• https://www.labofapenetrationtester.com/2018/10/deploy-deception.html
• https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/child-domain-da-to-ea-in-parent-domain

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

• Якщо ви хочете побачити вашу компанію рекламовану в HackTricks або завантажити HackTricks у PDF, перевірте ПЛАНИ ПІДПИСКИ!
• Отримайте офіційний PEASS & HackTricks мерч
• Дізнайтеся більше про Сім'ю PEASS, нашу колекцію ексклюзивних NFT
• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @carlospolopm.
• Поділіться своїми хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud github репозиторіїв.