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

Поиск учетных записей и служб в сетях 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 можно следующим образом:

Cookie, хранящиеся в базе данных
Cookie, хранящиеся в базе данных

Данные форм авторизации, хранящиеся в базе данных
Данные форм авторизации, хранящиеся в базе данных

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

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

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

Расшифрованные Cookie
Расшифрованные Cookie

Расшифрованные данные форм авторизации
Расшифрованные данные форм авторизации

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

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

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

Неудачное расшифрование данных форм авторизации
Неудачное расшифрование данных форм авторизации

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

Извлечение данных DPAPI
Извлечение данных DPAPI
Ключевая информация целевого пользователя
Ключевая информация целевого пользователя

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

Расшифрованные данные формы авторизации пользователя
Расшифрованные данные формы авторизации пользователя

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

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

SID целевого пользователя
SID целевого пользователя

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

Получение мастер-ключа
Получение мастер-ключа

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

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

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

Экспорт ключа резервного копирования
Экспорт ключа резервного копирования

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

GUID целевого пользователя
GUID целевого пользователя

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

Получение мастер-ключа пользователя
Получение мастер-ключа пользователя

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *