«Intro»

Довольно часто можно встретить использование KeePass в различных компаниях.
Если рассматривать корпоративную среду, то системные администраторы являются пожалуй основными пользователями этой утилиты.
Так же часто можно встретить советы и рекомендации по переходу с хранения паролей в xls файлах на KeePass – как например
здесь.

KeePass действительно может защищать сохраненные пароли различными способами (например с использованием Windows аккаунтов или ключей), поэтому мы рассмотрим практически все возможные варианты пост-эксплуатации.

Сразу стоит заметить, что почти все описанное далее возможно без повышенных привилегий.

Программа KeePass не является уязвимой или какой-то забагованной — это гораздо лучше чем хранить пароли в xls файле. Но при этом она не является решением абсолютно всех проблем с хранением паролей.
Если вы используете KeePass — это не гарантируют что ваши пароли 100% защищены от кражи.
Но и с другой стороны KeePass весьма неплох, потому что он изначально содержит в себе механизмы для противодействия пост-эксплуатации, о которых знают далеко не все.

«Вначале осмотримся»

Самым первым действием будет обнаружение процесса KeePass, и какая его версия используется на целевой системе.
Разумеется, можно посмотреть список текущих процессов, например с помощью PowerShell:


Get-Process | Where-Object {$_.ProcessName -like '*kee*'}

kp01

После этого неплохо бы узнать где именно находятся сами файлы программы.
По дефолту для версии 1.x путь будет C:\Program Files (x86)\KeePass Password Safe\, а для версии 2.x — C:\Program Files (x86)\KeePass Password Safe 2\.
Это будет справедливо в случае если целевая ОС x64.
Но не стоит забывать, что еще существует и портативная версия, которую можно запустить с любого места без установки на диск.
Поэтому мы можем воспользоваться функционалом WMI, запросив процессы и значение ExecutablePath.


Get-WmiObject win32_process | Where-Object {$_.Name -like '*kee*'} | Select-Object -Expand ExecutablePath

kp02

Если же KeePass в данный момент не запущен, мы можем воспользоваться командлетом Get-ChildItem для поиска бинарников, или сразу .kdb баз.


Get-ChildItem -Path C:\Users\ -Include @("*kee*.exe", "*.kdb*") -Recurse -ErrorAction SilentlyContinue | Select-Object -Expand FullName | fl

kp03

«Переходим к БД»

Если удается получить БД KeePass целиком, то сразу стоит учесть несколько факторов.
Во-первых, в версии 1.x база будет .kdb, а в более новых 2.x версиях — .kdbx.
Во-вторых если версия 2.28-2.29 или 2.30 и база уже разлочена, существует возможность использования инструмента KeeFarce (https://github.com/denandz/KeeFarce) для извлечения паролей из памяти.
Но эта атака требует доставки файлов на диск жертвы, а некоторые из них вызовут алерты антивирусов. И самое главное уже появился более функциональный инструмент, но о нем позднее.
Поэтому можно поступить проще — запустить кейлогер, убить процесс KeePass и подождать пока не будет набран пароль.
Или же просто запустить кейлогер и подождать до начала следующего дня.
Здесь стоит упомянуть специальную фичу «secure desktop», которая призвана защищать от кейлогеров, но она всегда выключена по дефолту, и ее довольно редко включают. И ее тоже можно будет обойти в дальнейшем.

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

Одна из проекта john ripper, а именно — keepass2john

А другая написанная Will Schroeder на питоне

kp04

Затем уже можно использовать hashcat с опцией -m 13400.

«Что с ключами?»

Некоторые более опытные администраторы используют не только пароли, но и ключи для защиты БД KeePass.
Иногда ключи могут находится где-нибудь в Моих Документах, но чаще всего это неизвестный файл, в неизвестном месте.
На этом этапе стоит рассмотреть файл конфигурации KeePass, а точнее KeePass.config.xml.
В этом конфиге обычно указано где именно находится интересующий нас ключ.
Для удобства можно воспользоваться небольшим скриптом на PowerShell:

https://gist.github.com/HarmJ0y/e9daa76c7888e24b5e3943b82f1d1d4f

kp05

«Разбираемся с DPAPI»

Если опция UserAccount установлена в значение true (в конфиге KeePass.config.xml), то это автоматически означает, что мастер пароль для БД включает в себя опцию «Windows User Account».
В таком случае, KeePass будет смешивать элементы учетки текущего Windows пользователя с любым паролем и/или ключом для создания композитного (http://keepass.info/help/base/keys.html) мастер ключа.
Тогда получается, что даже кейлоггер или найденный ключ не помогут в открытии БД с паролями?
Не все так однозначно.
Для работы с композитным ключом KeePass использует DPAPI (Windows Data Protection Application Programming Interface).
Этот интерфейс предоставляет несколько простых крипто вызовов, которые в свою очередь позволяют легко шифровать/расшифровывать чувствительные данные.
Информация пользователя (в том числе и его пароль) используется для шифрования мастер ключа, который затем применяется с опциональной энтропией для шифрования уже данных самого приложения.

В результате, для восстановления композитного мастер ключа требуются следующие шаги:

1) Копирование каталога, содержащего пользовательский DPAPI мастер ключ. Этот каталог находится по адресу C:\Users\Имя_пользователя\AppData\Roaming\Microsoft\Protect\\. Имя каталога будет в формате SID, т. е. S-1-…

2) Копирование файла C:\Users\Имя_пользователя\AppData\Roaming\KeePass\ProtectedUserKey.bin. Этот файл используется при создании композитного мастер ключа.

3) Отметить для себя логин и домен пользователя, который создавал БД KeePass.

4) Переместить каталог в %APPDATA%\Microsoft\Protect\ на подконтрольной атакующему Windows машине. Эта машина не обязательно должна входить в домен.

5) Создать несколько ключей в реестре, в ветке HKCU:\SOFWARE\Microsoft\WindowsNT\CurrentVersion\DPAPI\MigratedUsers. Подробнее почитать про это можно в KeePass вики (https://sourceforge.net/p/keepass/wiki/Recover%20Windows%20User%20Account%20Credentials/attachment/DPAPI%20migration.reg.txt)

6) Запустить утилиту для миграции C:\Windows\system32\dpapimig.exe, и ввести старый пароль пользователя.

7) Открыть KeePass версии 2.x, выбрать добытую БД в формате .kdbx, ввести пароль/ключ и установить опцию «Windows User Account» для открытия уже самой БД с паролями.

Разумеется, все эти действия можно автоматизировать.
Скрипт на PowerShell позволяющий ускорить эти действия (https://gist.github.com/HarmJ0y/2af9ac57f95e6663a26742774c822b10)
Для его работы нужно указать SID каталог, имя юзера и файл ProtectedUserKey.bin


Restore-UserDPAPI -Path .\S-1-5-21-3666375278-850114672-3647310776-1107 -UserName richard -UserDomain pentestit.local -ProtectedUserKey .\ProtectedUserKey.bin

kp06

kp07

«А если ключ хранится не на локальном диске, а только на USB флешке?»

В этом случае опять нужно будет обратиться к возможностям подсистемы WMI.
Matt Graeber провел исследование и обнаружил WMI класс «Win32_VolumeChangeEvent», который срабатывает каждый раз при подключении USB флешки.
Поэтому ничто не мешает написать небольшой скрипт, который будет взаимодействовать с подключенной флешкой.
При этом на выбор есть два варианта — с сохранением функционала после перезагрузки, либо до тех пор пока запущен наш процесс powershell.exe.

Если не требуется выживание после ребута, то можно использовать Register-WmiEvent и Win32_VolumeChangeEvent:


Register-WmiEvent -Query 'SELECT * FROM Win32_VolumeChangeEvent WHERE EventType = 2' -SourceIdentifier 'DriveInserted' -Action {$DriveLetter = $EventArgs.NewEvent.DriveName;if (Test-Path "$DriveLetter\key.jpg") {Copy-Item "$DriveLetter\key.jpg" "C:\Temp\" -Force}}

Этот код позволит скопировать файл в C:\temp\ в тот момент когда флешка будет подключена к системе.
Кстати, этим же способом можно мониторить события и на удаленных хостах (если есть соответствующие привилегии) с помощью опций -ComputerName и -Credential.

Если же нужно чтобы отслеживание работало и после перезагрузки, то придется использовать WMI_Backdoor (https://github.com/mattifestation/WMI_Backdoor) авторством того же Matt Graeber.

«Ситуация если ключ на сетевом диске»

В некоторых случаях администраторы могут хранить ключи где-нибудь на сетевых дисках.
Для поиска таких ключей можно применять различные инструменты, а самый удобный это наверное модуль PowerView и его функция Get-RegistryMountedDrive.
Эта функция как раз проверит все подключенные сетевые диски для всех пользователей на локальном или удаленном хосте.

kp08

«Завершающие штрихи»

И самое интересное напоследок.
Буквально на днях появился инструмент KeeThief (в том числе и на PowerShell).
Чем же он примечателен?
1) KeeThief не требует прав локального администратора, ему нужны только права к процессу KeePass.exe, который и атакуется.
2) Скрипт KeeThief.ps1 полностью самодостаточен, никаких зависимостей, никакие файлы не падают на диск, и кроме того поддерживается PowerShell начиная со второй версии, т.е. работает от Windows 7 и дальше.
3) Настройка secure desktop, никак не повлияет, так как не требуются кейлогеры.
4) KeeThief особенно отличается от KeeFarce, тем что восстанавливает пароли и ключи из памяти вместо того чтобы вызывать различные внутренние методы для экспортирования содержимого БД.
5) Естественно требуется чтобы база KeePass была разблокирована для получения паролей. Если же база пока не подключена, можно периодически запускать KeeThief.

kp09

«Что в итоге?»

Использование KeePass или любого другого менеджера паролей это конечно всегда лучше чем хранить все чувствительные данные в простом xls файле.
Но если атакующему удается получить привилегии пользователя (или уже тем более локального администратора), то затем уже практически невозможно его остановить от сбора любых данных с жертвы.
С использованием возможностей PowerShell и WMI, мы можем достаточно быстро находить конфиги KeePass и собирать ключи.
Разумеется, с помощью WMI можно извлекать самую разнообразную информацию, как из системы, так и с USB устройств при их подключении.

«Использованные материалы и дополнительная информация»

Will Schroeder http://www.harmj0y.net/blog/

Matt Graeber https://twitter.com/mattifestation

Abusing Windows Management Instrumentation (WMI) to Build a Persistent, Asynchronous, and Fileless Backdoor