Как кэшированные учетные данные Windows хранятся на локальном компьютере?

26

Как кэшированные учетные данные домена Active Directory хранятся на клиенте Windows? Хранятся ли они в локальной базе данных SAM, что делает их восприимчивыми к тем же атакам радужных таблиц, к которым подвержены учетные записи локальных пользователей, или они хранятся по-другому? Обратите внимание, что я понимаю, что они соленые и хэшированные, чтобы не быть сохраненными в виде простого текста, но хешируются ли они так же, как локальные учетные записи, и хранятся ли они в одном месте?

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

windows active-directory security

— MDMarra
источник

17

«Кэшированные учетные данные»

Кэшированные учетные данные для домена AD на самом деле представляют собой двойные хэши паролей с солью и хранятся в кусте HKLM \ Security. Расположение файла улья: %systemroot%\System32\config\SECURITY

Только системный пользователь имеет доступ к разделам реестра:
HKLM\Security\Cache\NL$nгде nиндекс от 1 до максимального количества кэшированных учетных данных.

Восприимчивость к атакам

WinNT to WinXP использовали хэши «Lan Manager» для локальных учетных записей, которые легко ломаются на современном оборудовании. Взлом обычно занимает несколько минут (я недавно сделал 3 пароля в 00:08:06) только с обычным настольным компьютером. Хэши Lan Manager не засолены, поэтому есть общедоступные радужные таблицы.

Vista и более поздние версии используют NT-хэши для локальных учетных записей. Windows 2000 и более поздние версии используют NT-хэши и для учетных записей домена . NT-хэши - это соленые двойные хэши MD4. Соль для каждой записи предотвращает использование радужных таблиц, но MD4 может выполняться очень быстро на современном оборудовании: около 6 вычислительных лет для 60-битного пароля. При удаче и кластере с 6 GPU взломщик может взломать пароль такого типа за ~ 6 месяцев. Принимая это к облаку, около $ 35 тыс. На Amazon EC2 GPU - в зависимости от доступности, это могут быть часы.

— Крис С
источник

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

— хэшируются

Обновился ... Vista + это все тоже самое. Старые версии были разные.

— Крис С

«NT-хэш пароля вычисляется с использованием несоленного хеш-алгоритма MD4». - Прямо из TechNet: technet.microsoft.com/en-us/library/hh994565(v=ws.10).aspx

— thepip3r

Эта страница неправильная, NT-хэши засолены. См. Ответ Джо ниже для ссылки на КБ.

— Крис С

4

Учетные данные фактически не кэшируются на локальном компьютере. Смотрите этот отрывок из MS:

Безопасность кэшированных учетных данных домена

Термин кэшированные учетные данные не совсем точно описывает, как Windows кэширует информацию о входе в систему для входа в домен. В Windows 2000 и более поздних версиях Windows имя пользователя и пароль не кэшируются. Вместо этого система хранит зашифрованный верификатор пароля. Этот верификатор представляет собой соленый хеш MD4, который вычисляется два раза. Двойное вычисление фактически делает верификатор хэшем хеша пароля пользователя. Это поведение отличается от поведения Microsoft Windows NT 4.0 и более ранних версий Windows NT.

http://support.microsoft.com/kb/913485

— joeqwerty
источник

Правильно, я понимаю, что сами учетные данные на самом деле не кэшируются, но мой вопрос был скорее в следующем: «Полученные хеши хранятся в локальной базе данных SAM так же, как локальные учетные записи, что делает их уязвимыми к тем же атакам. " Я отредактирую это через минуту, чтобы быть немного более ясным.

— MDMarra

1

Мех .. для меня это чепуха. природа "хеширования" - это односторонний процесс, который создает в основном запутанное значение пароля с использованием криптографически безопасного алгоритма. Проблема в том, что MD4, возможно, был криптографически защищен 10-15 лет назад, но даже больше не близок (ни MD5, ни SHA1 с точки зрения криптографа). Так что, если у вас есть современное оборудование, которое может быстро перебрать ключевое пространство алгоритма или обнаружить коллизию, то вы можете легко получить пароль из хэша ...

— thepip3r

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

— NiKiZe

4

Они обрабатываются диспетчером учетных данных, для которого существует API диспетчера учетных данных. Соленые хэши хранятся на диске в некоторой степени безопасным способом и доступны через HKLM \ Security. (К которому может получить доступ только LocalSystem по умолчанию, но его легко обойти, например, с помощью psexec -i -s regedit.exe.)

Однако в работающей системе Windows ситуация более тяжелая, поскольку недавно использованные учетные данные можно легко перевести и преобразовать в обычный текст, подключив DLL к Lsass. (См. Мимикац.)

Так что да, вы найдете какой-нибудь хеш (или хеш хэша, или «верификатор», или как вы хотите его называть) в HKLM \ Security \ Cache на клиенте. Но я не думаю, что есть какой-либо реальный способ атаковать хэш на диске. Это не тот старый хэш NTLM, который можно атаковать.

— Райан Райс
источник

Взлом пароля в автономном режиме в SAM полностью отличается от перехвата LSASS в памяти, как это делают Mimikatz и WCE. И в зависимости от сложности пароля взломать пароль SAM в автономном режиме может быть ОЧЕНЬ легко (см. Samdump2)

— thepip3r