Дамп учетных данных RDP

Администраторы обычно используют протокол удаленного рабочего стола (RDP) для удаленного управления Windows системами. Также типичным является включение протокола RDP в системах, которые действуют как переходная станция, позволяющая пользователям подключаться к другим сетям. Однако, несмотря на то, что этот протокол широко используется, в большинстве случаев он не защищен и не контролируется должным образом.

С точки зрения Red Team, дамп учетных данных из процесса lsass может привести либо к горизонтальному перемещению по сети, либо напрямую к полной компрометации домена, если учетные данные для учетной записи администратора домена были сохранены. Процессы, связанные с протоколом RDP, которые также могут входить в сферу интересов красных команд для сбора учетных данных:

1. svchost.exe
2. mstsc.exe

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

Svchost

Главный процесс (svchost.exe) - это системный процесс, который может обслуживать несколько служб для предотвращения потребления ресурсов. Когда пользователь аутентифицируется через RDP соединение, служба терминала обслуживается процессом svchost. Основываясь на том, как работает механизм проверки подлинности Windows, учетные данные хранятся в памяти процесса svchost в виде обычного текста в соответствии с открытием Джонаса Лика. Однако, если посмотреть на список процессов, там есть несколько процессов svchost, поэтому определение того, какой процесс и какие хосты подключены к терминальной службе, можно выполнить с помощью одной из следующих команд.

Запрос терминальной службы:

sc queryex termservice

Запрос для выяснения, какая задача загрузила rdpcorets.dll:

tasklist /M:rdpcorets.dll

Запустив netstat:

netstat -nob | Select-String TermService -Context 1

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

Дамп процесса из Sysinternals также можно использовать для дампа памяти, указав PID и каталог, в который будет записан файл .dmp.

procdump64.exe -ma 988 -accepteula C:\Users\pentestlab

Файл .dmp можно передать на другой хост для автономного анализа. А с помощью grep, можем идентифицировать пароль, хранящийся в файле памяти под именем пользователя.

strings -el svchost* | grep Password123 -C3

Вышеупомянутый метод не считается полностью надежным, и до сих пор неизвестно, в каких условиях учетные данные удерживаются в процессе svchost. Однако Mimikatz поддерживает получение учетных данных из существующих подключений RDP, с помощью следующих команд:

privilege::debug
ts::logonpasswords

mstsc

Процесс mstsc.exe создается, когда пользователь открывает приложение для подключения к удаленному рабочему столу, чтобы подключиться к другим системам по протоколу RDP. Перехват API может использоваться для захвата учетных данных, предоставленных пользователем, и использования их для горизонтального перемещения. Rio Sherri разработал инструмент проверки концепции под названием RdpThief, который пытается перехватить функции, используемые процессом mstsc (CredIsMarshaledCredentialW и CryptProtectMemory), чтобы получить учетные данные и записать их в файл на диске. Подробности об инструменте можно найти в статье на сайте MDSec.

Для системы, которая была скомпрометирована и в которой запущен mstsc.exe, необходимо внедрить DLL в процесс.

SimpleInjector.exe mstsc.exe RdpThief.dll

Как только пользователь вводит учетные данные для аутентификации на целевом хосте, они будут захвачены и записаны в файл в папке C:\temp.

В файле creds.txt будет также указан IP-адрес. Эта информация может использоваться для горизонтального перемещения по сети или даже для повышения привилегий, если используется учетная запись с высокими полномочиями.

Инструмент был переписан на C# Джошем Магри. Однако по сравнению с RdpThief, SharpRDPThief использует сервер IPC для получения учетных данных от процесса mstsc.exe. В случае, если mstsc.exe завершается, сервер продолжит работу, и при повторном запуске процесса попытается выполнить перехват. Это снимает ограничение RdpThief на то, что процесс уже должен существовать.

Файлы RDP

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

Учетные данные Windows расположены на диске по данному пути:

C:\Users\username\AppData\Local\Microsoft\Credentials

Файл можно просмотреть через бинарник Mimikatz:

dpapi::cred /in:C:\Users\pentestlab\AppData\Local\Microsoft\Credentials\ACC240EEE479C1B634EC496F9838074B

Поле «pbData» содержит информацию в зашифрованном виде. Однако главный ключ для дешифровки хранится в lsass, и его можно получить, запустив следующий модуль Mimikatz. «GuidMasterKey» также важен, поскольку при запросе lsass может существовать несколько записей, и это необходимо для сопоставления GUID с мастер-ключом.

sekurlsa::dpapi

Повторное выполнение модуля dpapi::cred с указанием главного ключа приведет к расшифровке содержимого и учетных данных RDP, которые будут раскрыты в виде обычного текста.

dpapi::cred /in:C:\Users\pentestlab\AppData\Local\Microsoft\Credentials\ACC240EEE479C1B634EC496F9838074B
/masterkey:05d8e693421698148d8a4692f27263201f1c65e0b3ac08e3be91ea75f43e71e9b398e2418ba0f0c62ea70a317bdba88f11da3adebd07d65d2b349f933eab85e1

Выполнение следующей команды предоставит подробную информацию о том, какому серверу принадлежат эти учетные данные.

vault::list

Видео демонстрация методов из статьи представлена в данном видео:

На этом все. Спасибо за просмотр!