Атакуем домен. сбор критически важных данных.

Tartuga

Бывалый
ПРОВЕРЕННЫЙ ПРОДАВЕЦ
PREMIUM USER

Tartuga

Бывалый
ПРОВЕРЕННЫЙ ПРОДАВЕЦ
PREMIUM USER
Регистрация
7 Фев 2020
Сообщения
525
Реакции
98
Репутация
147
Для успешной атаки на Active Directory, захвата рабочих станций и перемещения по сети настоящему хакеру не обязательно владеть учетными данными пользователей. Но иногда без них не обойтись. А чтобы завладеть учеткой, нужно знать, где в сетях с Active Directory обычно хранятся пароли и как их оттуда добыть.

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

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


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

Скрипт

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

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


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

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

> vssadmin create shadow /for=C:

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

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

Копирование 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, входящего в пакет

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

.

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

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

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

Файл с хешами

Результат работы hashcat
Так мы получим некоторые пароли в открытом виде.

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

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

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

Сделать это можно с помощью инструмента

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

. Он обладает широким спектром возможностей, как и множеством вариантов запуска.


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


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


Файл с хешем
hashcat -a 0 -m 5600 NetNTLMv2.hashes dictionary.txt

Результат работы hashcat
Эта атака выполняется более скрытно по сравнению с использованием 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. Клиент передает аутентификационную информацию оператору.

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


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


Результат успешной атаки LLMNR Poisoning
Так оператор может узнать 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, узнать пароли от этих учетных записей.


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

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

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


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

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

Получение билета с помощью impacket
Для взлома используется hashcat.

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

Результат работы hashcat
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.


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

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

Получение пользователей с отключенной предварительной аутентификацией Kerberos
Теперь выполним запрос для найденного пользователя.

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


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


Список пользователей

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


Результат работы John
Другое различие между 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:[пользователь]

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


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


DCSync с помощью imрacket Получение открытого пароля с помощью DCSync
Но что делать, если хеш пароля не взламывается?


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

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

Add-ADFineGrainedPasswordPolicySubject -Identity ShareRoint -Subjects ShareRoint
Проверить, применилась ли парольная политика, очень легко.


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


Пароль пользователя в открытом виде в результате DCSyncХранилище паролей 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”

Cookie, хранящиеся в базе данных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

Расшифрованные Cookiemimikatz
# 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

Извлечение данных 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 (как в предыдущем пункте).


SID целевого пользователя
И теперь оператор может получить мастер-ключ.

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 целевого пользователя.


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

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

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

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


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

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

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