Windows: Как узнать пароли пользователей авторизованных в системе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Windows memory toolkit free edition

MoonSols Windows Memory Toolkit 2.0

MoonSols Windows Memory Toolkit is a powerful toolkit containing all the utilities needed to perform any kind of memory acquisition or conversion during an incident response, or a forensic analysis for Windows desktops, servers or virtualized environment.

MoonSols Windows Memory Toolkit 2.0 details

Author:	MoonSols Ltd.
License:	Freeware
Price:	FREE
Released:	Oct 16, 2013
File size:	492 kB
Downloads:	896
Keywords:	Windows Memory, Toolkit, Windows, Memory, conversion, acquisition, forensic, analysis
Author URL:	http://www.moonsols.com/

User Rating: 4.0 ( 6 votes)

Software Coupons

Windows 10 Blog

Windows 10 Tags

MoonSols Windows Memory Toolkit for Windows 10 — Full description

MoonSols Windows Memory Toolkit is a powerful toolkit containing all the utilities needed to perform any kind of memory acquisition or conversion during an incident response, or a forensic analysis for Windows desktops, servers or virtualized environment. MoonSols Windows Memory Toolkit is the most advanced toolkit for Windows physical memory snapshot management.

MoonSols Windows Memory Toolkit had been designed to deal with Microsoft Windows hibernation file (from Microsoft Windows XP to Microsoft Windows 7 in both 32-bits and 64-bits (x64) Editions), Microsoft full memory crashdump (in both 32-bits and 64-bits (x64) Editions), and raw memory dump files (from memory acquisition tools like win32dd or win64dd, or Virtualization application like VMWare). Moreover, MoonSols Windows Memory Toolkit also contains new version of win32dd and win64dd.

MoonSols Windows Memory Toolkit contains:

MoonSols DumpIt 2.0
MoonSols Hibr2Bin 2.0
MoonSols Hibr2Dmp 2.0
MoonSols Dmp2Bin 2.0
MoonSols Bin2Dmp 2.0

Восстанавливаем локальные и доменные пароли из hiberfil.sys

Утилита mimikatz, позволяющая извлекать учётные данные Windows из LSA в открытом виде, существует с 2012 года, однако помимо хорошо освещённого функционала восстановления паролей из памяти работающей ОС у неё есть ещё одна довольно интересная возможность. Далее я приведу пошаговую инструкцию, как при помощи нехитрых действий извлечь учётные данные из файла hiberfil.sys.

Подготовка

Действия

1. Получаем файл hiberfil.sys с целевой машины.

2. Конвертируем файл в формат понятный WinDbg.

hibr2dmp.exe d:\temp\hiberfil.sys c:\temp\hiberfil.dmp

Процесс может занять довольно продолжительное время

3. Запускаем WinDbg и открываем полученный файл.

File -> Open Crash Dump

4. Настраиваем отладочные символы.

Открываем File -> Symbol File Path… и вписываем следующую строчку:

Вместо c:\symbols, естественно, может быть любой каталог, в который будут загружены символы

В командной строке дебаггера пишем:

Ждём окончания загрузки символов:

5. Указываем путь к библиотеке mimilib.dll (находится в каталоге с mimikatz).

0: kd> .load z:\Soft\Security\Passwords\Mimikatz\x64\mimilib.dll

6. Находим адрес процесса lsass.exe.

0: kd> !process 0 0 lsass.exe

В данном случае адрес: fffffa800a7d9060.

7. Переключаем контекст процесса.

0: kd> .process /r /p fffffa800a7d9060

8. Запускаем mimikatz и получаем пароли в открытом виде.

Ссылки по теме

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Memory forensics, Rubber Duck и пароли GPO. Решение задач с r0от-мi. Часть 2

Disk forensics, memory forensics и log forensics. Volatility framework и Autopsy. Решение задач с r0от-мi. Часть 1

Обходим Windows Defender дешево и сердито: обфускация Mimikatz

Вакансии

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 60

Digest — в принципе фигня. Используется далеко не всеми, да и отключить можно. Куда веселее, что пароль в открытом виде нужен для обновления тикета Kerberos.

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

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

Для пролонгации пользовательского Kerberos-тикета пароль не нужен, он нужен только для получения первоночального или нового, если пролонгация больше невозможна.

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

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

С момента прихода suspend-to-ram наверное уже никто не будет гибернацию дорабатывать, а жаль.

Я вытащил hiberfil.sys (x64, 6.5Gb), но не могу конвертировать его в dmp.
hibr2dmp.exe выдает следующее:

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

Пробовал через двойную конвертацию утилитой volatility, сначала в raw потом в dmp, в raw проходит успешно, но raw2dmp выдает что не может понять данные которые я хочу конвертировать. В том числе не может отнести их к данным файла гибернации.

Это не поможет. Дело в том, что пароли в открытом виде хранятся не только для digest, но и для других способов аутентификации, в том числе для Kerberos. Не пробовал отключать Kerberos на недоменном компе, но в сети это, очевидно, не слишком разумная идея. 🙂

Похоже, единственный способ что-то сделать — не использовать вход по паролю (сертификаты, биометрия, и т.п.), но это надо проверять.

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

И теперь подрядчик может так вот «запросто» угнать пароли всех доменных пользователей, которые логинились на сервер после последней перезагрузки?

Итого это еще один повод админам иметь две учетки: с правами админа везде, кроме контроллера и с правами админа на контроллере; или что еще делать-то? О.о

Можно и нужно запретить группе администраторов грузить драйвера, такое правило есть в локальных политиках безопасности в назначениях прав пользователю («Загрузка и выгрузка драйверов устройств»).
Пусть загрузкой драйверов занимается отдельный специальный пользователь. Это чрезвычайно опасное право, им кстати пользуется Unlocker.
Кроме этого администраторам можно запретить отладку программ (не менее опасное право) и включить им «Блокировать страницы в памяти» чтобы всё запущенное от администраторов никогда не выгружалось в файл подкачки (злоупотреблять выставляя всем пользователям запускающим жирные приложения не стоит, а то получится как с линуксом — №12309, может и не хватить терпения дождаться отвиса системы).
Однако администратор может поставить в планировщик задач или в качестве службы зловредное приложение в режиме запуска от СИСТЕМЫ (рут) и такой программе уже класть на ограничения администратора насколько я понимаю (впрочем в Windows есть свои тонкости).
По крайней мере пользователь СИСТЕМА в ФС может сбросить любые права и любому объекту назначить себя владельцем (даже не смотря на запрет ей это делать, хотя все остальные запреты на неё работают — можно запретить ей писать и читать и будет действительно отказано в доступе, но ничто не мешает ей разрешить себе это делать).
Поэтому запускать службы от пользователя системы очень опасно и для всяких таких энтерпрайз служб надо выделять отдельного пользователя ровно с теми правами которые ему фактически нужны (даже не те что он запрашивает — его можно и обмануть).
Обычным админам надо как-то перекрыть краники с возможность запуска от пользователя система, я сильно глубоко ещё не копался, но возможно такая настройка где-то запрятана.
Группе администраторов кстати ещё можно запретить становиться владельцем тех объектов где им явно не разрешено это делать, выставляется через «Смена владельцев файлов и других объектов», только это делать надо с умом, например мной замечено что без него не будет работать откат на точку восстановления, пока не вернёшь это право пользователю.

Вообще система безопасности Windows навороченная, гибкая и к сожалению сложная, очень хотелось бы в ReactOS сделать её более понятной и предсказуемой, но не уверен что этот день настанет своевременно.
Например в Windows есть права для процессов которыми почти никто не пользуется. Можно определить какой пользователь что сможет сделать с определённым процессом, разрешено ли ему его убивать, приостанавливать, менять владельца, читать разрешения, писать и/или читать память и ещё разное (прав много). Эти права есть и для потоков/нитей процессов. Этими правами можно покрутить через Process Explorer (наверное и через Process Hacker но я уже не помню) и менять автоматизировано через subinacl.
Я например не очень понимаю почему по умолчанию (сужу по 8.1 Pro) один пользователь может убивать процессы другого пользователя (даже админа, если приложение не запущено как админское, админские-то да не даёт), при этом админ (от приложения запущенно с админскими правами) не может даже понизить приоритет процесса другого пользователя, данные потоков тоже закрыты от него, хоть убивать конечно может. Но это я возможно где-то случайно изменил что-то, надо будет проверить на другой системе.
Права существуют и для служб, для DCOM-объектов, реестра само собой, прочих системных объектов (можно увидеть их через WinObj от Руссиновича).
Где-то как я понимаю в дебрях реестра скрыты многие права и поведение по умолчанию менеджера безопасности (чего недоступно из локальной/групповой политики безопасности), но пока ещё до них не добрался. Знаю что не все ветки реестра показываются админу, если залезть в реестр от пользователя системы появится ветка SAM где можно крутить учётками, в том числе встроенными.

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

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

Касаемо подписанного драйвера, что мешает админу запретить этот сертификат (или же оставить/добавить свои только необходимые)

но для запрета одного сертификата центральный админ должен про него узнать

Так пусть оставит только самые необходимые и если надо добавит свой сертификат которым подпишет требуемые приложения. Ну и для надёжности запретит запуск приложений без цифровых подписей.

Например, подменив бинарник ненужного драйвера своим и дождавшись перезагрузки.

А на что права ФС? Можно запретить подменять файлы драйверов (да и вообще туда писать) админам и запретить им брать на себя права любого объекта, кроме явно разрешённых. Помимо этого я встречал групповые политики связанные с драйверами, но не помню конретики, там может что-то дополнительно поможет.