Procdump чем открыть дамп

Обновлено: 15.01.2025

Во время пентестов мы часто оказываемся внутри систем на базе ОС Windows в поисках учетных записей. Цель этой статьи – изучить некоторые техники для получения информации об учетных записях Windows-систем, при этом оставаясь незаметным, насколько это возможно.

Автор: Себастьян Маке (Sebastien Macke, @lanjelot)

В основе всех этих техник лежит несколько базовых принципов:

Выгрузка учетных записей с хоста на базе ОС Windows

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

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

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

Скопируйте ветви реестра SYSTEM, SECURITY и SAM на свой локальный компьютер:

C:\> reg.exe save hklm\sam c:\temp\sam.save
C:\> reg.exe save hklm\security c:\temp\security.save
C:\> reg.exe save hklm\system c:\temp\system.save

При помощи утилиты secretsdump извлеките из сохраненных ветвей локальные аккаунты, закешированные учетные записи домена и секретные ключи LSA:

$ secretsdump.py -sam sam.save -security security.save -system system.save LOCAL
Impacket v0.9.11-dev - Copyright 2002-2013 Core Security Technologies

Подберите пароли к LM-хешам (если они есть) при помощи Ophcrack.

Подберите пароли к NT-хешам при помощи JtR и hashcat.

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

Это хеши учетных записей тех пользователей, которые уже прошли авторизацию на хосте. Пароли к этим хешам можно подобрать при помощи утилит JtR или hashcat. Не забудьте указать правильный формат: либо mscash (xp, w2k3), либо mscash2 (vista, w7, w2k8 …). Примечание: вы не можете использовать технику «pass-the-hash», используя этот вид хешей.

Здесь вы можете найти пароли учетных записей для служб, которые запускаются под существующими аккаунтами пользователей Windows (в отличие от Local System, Network Service и Local Service), пароли для автоматического входа и т. д.

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

Использовать эти учетные записи можно при помощи утилиты pth, если вы работайте в Kali Linux или wce если вы работаете в Windows-системе.

Пароли на общих ресурсах и в контроллере домена в Group Policy Preferences (GPP) можно расшифровать:

Учетные записи, находящиеся в оперативной памяти

Выгрузить пароли из памяти в чистом виде можно при помощи утилиты mimikatz, а при помощи Windows Task Manager можно сдампить процесс LSASS.

Для выгрузки процесса lsass.exe в файл в программе Task Manager кликните правой кнопкой на процессе «lsass.exe», а затем выберите «Create Dump File» (начиная с Vista). Также можно воспользоваться утилитой Procdump (для WinXP и более ранних версий ОС) или, в качестве альтернативы, powershell-fu (см. статью carnal0wnage):

C:\> procdump.exe -accepteula -ma lsass.exe c:\windows\temp\lsass.dmp 2>&1

Затем учетные записи выгружаются из дампа при помощи mimikatz и его модуля minidump.

C:\> mimikatz.exe log "sekurlsa::minidump lsass.dmp" sekurlsa::logonPasswords exit

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

Другой вариант: запуск на хосте утилиты wce, однако при этом вероятнее всего сработает антивирус (если он установлен на хосте). Обратите внимание, что wce-v1.41beta, кажется, не умеет выгружать пароли из внешних SMB-сессий (их список можно получить, если выполнить команду «net use» на скомпрометированном хосте), а mimikatz выгружает.

Диспетчер учетных записей (Credential Manager)

Когда пользователь авторизуется на общем сетевом ресурсе, прокси-сервере или в клиентском программном обеспечение выставляет флажок «Remember my password», в этом случае, как правило, пароль хранится в зашифрованном виде с использованием Windows Data Protection API. Все зашифрованные аккаунты можно увидеть в диспетчере учетных записей (доступ к нему можно получить через раздел «Учетные записи пользователей» в Панели управления). Эту информацию можно сдампить при помощи утилиты Network Password Recovery. Обратите внимание, что на 64-битной архитектуре надо запускать 64-битную версию утилиты, иначе у вас ничего не получится.

При помощи утилиты Protected Storage PassView вы можете выгрузить пароли, сохраненные в IE, Outlook или MSN.

Программное обеспечение от сторонних разработчиков

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

Выгрузка из контроллера домена хешей пользователей домена

Суть этой техники заключается в получении базы данных (файл ntds.dit) Active Directory из Службы каталога (Directory Service), которая запущена на контроллере домена. При этом злоумышленник должен в интерактивном режиме авторизоваться на контроллере домена через Remote Desktop или «psexec». Идея заключается в том, чтобы использовать теневое копирование тома для получения файла ntds.dit, который в противном случае заблокирован и защищен от чтения.

Для начала посмотрите на состояние службы теневого копирования тома. Если служба не запущена (хотя по умолчанию это не так), используйте ntdsutil или vssadmin, как показано ниже, чтобы запустить службу. Не забудьте вернуть ее в первоначальное состояние после совершения всех манипуляций.

Затем найдите местонахождение файла ntds.dit, используя параметр «DSA Database file»:

C:\> reg.exe query hklm\system\currentcontrolset\services\ntds\parameters

После этого проверьте текущий размер файла ntds.dit и свободное место на диске. Его должно быть как минимум в два раза больше, чем размер файла. Теперь, используя встроенную командную утилиту ntdsutil, создайте снимок базы данных Active Directory.

C:\> ntdsutil
ntdsutil: snapshot
snapshot: activate instance NTDS
Active instance set to "NTDS".
snapshot: list all
No snapshots found.
// If there is a recent snapshot (ie. backups scheduled with Windows Server Backup),
then consider using that instead of creating a new one.)
snapshot: create
Creating snapshot.
Snapshot set generated successfully.
snapshot: list all
1: 2013/10/24:18:33
2: C:
snapshot: mount 2
Snapshot mounted as C:\$SNAP_201310241833_VOLUMEC$\

Теперь загрузите файл на свою машину файл ntds.dit, находящийся в C:\$SNAP_201310241833_VOLUMEC$\Windows\NTDS\. Заодно прихватите ветвь реестра SYSTEM (например, так: reg.exe save HKLM\SYSTEM c:\system.save). После этого удалите копию ветви реестра и созданный снимок.

Помимо ntdsutil вы также можете использовать встроенную утилиту vssadmin (как показано в этом howto), хотя vssadmin не создаст «единообразный» снимок, а ntdsutil лучше подходит для решения этой задачи. С другой стороны, если вы работаете с Windows 2003, то ntdsutil не сможет создать снимок, и в данном конкретном случае вам следует прибегнуть к использованию vssadmin.

Если ntds.dit поврежден, используйте встроенную утилиту esentutl для восстановления файла:

C:\> esentutl /p /o ntds.dit

Настало время выгрузить хеши паролей при помощи secretsdump:

$ secretsdump.py -system system.save -ntds ntds.dit LOCAL
Impacket v0.9.11-dev - Copyright 2002-2013 Core Security Technologies

[*] Target system bootKey: 0x24f65609994cdbec01b8b0b61cf6a332
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Searching for pekList, be patient
[*] Pek found and decrypted: 0xca47b3a8b3477cec0a774bed669c3d9f
[*] Reading and decrypting hashes from ntds.dit
Administrator:500:aad3b435b51404eeaad3b435b51404ee:a881324bad161293dedc71817988d944.
.

Вы также можете выгрузить историю паролей, используя опцию –history (начиная с версии r961).

Репликация Active Directory (экспериментальная техника)

Эта техника более незаметная, чем теневое копирование тома, поскольку здесь не требуется создания снимка базы данных Active Directory, запуска службы VSS, и даже интерактивного входа в контроллер домена. Использовать репликацию предпочтительнее, если у администраторов отсутствуют Se* привилегии (SeCreateTokenPrivilege, SeAssignPrimaryTokenPrivilege и т. д.), полностью отключена служба VSS и ей подобные, запрещено создание новых служб и т. д.

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

Насколько мне известно, пока не существует подобных инструментов для публичного пользования, однако об этой технике рассказывал Орельен Бордес (Aurelien Bordes) в своем коротком докладе «Fiabilisation d’outils» (дословно «инструменты надежности») перед конференцией SSTIC 2010, где продемонстрировал использование своей приватной утилиты.

Вместо написания собственной утилиты с нуля, мы можем просто модифицировать Samba для наших собственных целей, поскольку там уже реализована полная процедура добавления в домен контроллера домена. Наши изменения будут заключаться в том, чтобы отключить шаги, связанные с добавлением изменений в Active Directory, чтобы оставить только функцию репликации.

Ниже показан прекрасный патч для samba-4.1.0:

--- ./src/samba-4.1.0/python/samba/join.py 2013-11-17 04:08:05.393333375 +1100
+++ /usr/lib/python2.7/site-packages/samba/join.py 2013-11-17 04:29:22.209999075 +1100
@@ -1053,6 +1053,11 @@
ctx.nc_list = [ ctx.config_dn, ctx.schema_dn ]
ctx.full_nc_list = [ctx.base_dn, ctx.config_dn, ctx.schema_dn ]

После установки патча, подготовьте вашу систему для выполнения репликации:

Теперь запустите репликацию:

Затем, используйте утилиту pdbedit (она идет в комплекте с Samba), чтобы сдампить NT-хеши локально:

Кажется, у Samba нет инструмента для выгрузки истории паролей или LM-хешей (если они присутствуют в контроллере домена), однако вы можете использовать простой python-скрипт samba-pwdump.py для их извлечения напрямую из базы данных LDB.

Чтобы выяснить различия до и после репликации, я сравнил LDIF-экспорты из Root DSE и основные DN’ы (Distinguished name) в Active Directory.

Единственные отличия – атрибуты logonCount и lastLogon учетной записи администратора домена, которые были увеличены и, соответственно, атрибут highestCommitedUSN в Root DSE также был увеличен. Однако во время репликации сгенерировались события «Directory Service Access» (event ID 4672) в журнале безопасности Windows (Windows Security log) из-за того, что был получен привилегированный доступ к Active Directory. Другие события также могут отобразиться, если доступны некоторые другие категории (4932, 4928 …). Кроме того, во время репликации не были добавлены никакие изменения в реестр.

Пожалуйста, помните о том, что эта техника экспериментальная. Тесты проводились в контроллере домена на базе Windows 2008 R2 SP1 со стороны хоста с Archlinux и пакетом samba-4.1.0-1 с установленным патчем, о котором говорилось выше.

Для выявления причин сложных ошибок в программе TSLab может понадобится дамп памяти программы. Далее я расскажу в каких случаях он поможет и как его получить. Что такое дамп можно почитать здесь.

программа просто аварийно завершается без передачи управления в программу. В этом случае ни о какой записи в лог и речи не идет. В данном случае для выяснения причин где и из-за чего произошла ошибка поможет дамп.

Еще в одном случае он поможет в выяснении причины. Это в случае когда программа “зависает”, т.е. перестает реагировать на действия пользователя. В этом случае в логе программы тоже ничего не будет. Но здесь надо отличать зависание программы от замедленной реакции программы под нагрузкой. Такое поведение например получается когда на слабом компьютере запустить многопоточную оптимизацию и одновременно открыть много окон с быстроменяющимися инструментами.

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

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

Также есть еще один путь создания лога при падении программы, который работает на Windows 7. Для этого надо загрузить файл dump.reg (делается полный дамп) и кликнуть на нем. При этой операции требуются права администратора. Появится окно подтверждения, на котором надо ответить утвердительно.

После этого при падении программы TSLab в каталоге CrashDumps на диске с: будет создаваться дамп. В файле настроено, что максимально число дампов будет 2, далее новый дамп будет переписывать предыдущий. Более подробно можно почитать в msdn (на английском).

Дамп будет создаваться только при падении программы TSLab.

В дальнейшем, чтобы удалить данную функциональность, надо с помощью программы regedit удалить ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps.

Расширение DMP зарезервировано за файлами дампов памяти: снимков состояния RAM в определённый момент работы системы или отдельного приложения, которые нужны разработчикам для последующей отладки. Такой формат используют сотни видов ПО, и рассмотреть их все в объёмах данной статьи невозможно. Наиболее же часто встречающийся тип DMP-документа – так называемый малый дамп памяти, где записаны подробности сбоя системы, который привёл к появлению синего экрана смерти, потому на нём и сосредоточимся.

Способ 1: BlueScreenView

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

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

Утилита BlueScreenView рассчитана на продвинутых пользователей, потому её интерфейс может показаться сложным для новичка. Кроме того, доступна она только на английском языке.

Способ 2: Microsoft Debugging Tools for Windows

В составе среды разработки Windows SDK распространяется инструмент для отладки, который называется Debugging Tools for Windows. Приложение, рассчитанное на разработчиков, способно открывать в том числе и DMP-файлы.

Для экономии места можно выбрать только Debugging Tools for Windows, отметив соответствующий пункт в процессе загрузки компонентов.

Для запуска программы используйте ярлык «WinDbg».

Внимание! Для открытия DMP-файлов используйте только x64- или x86-версии дебаггера!

Утилита Debugging Tools for Windows ещё более сложная, чем BlueScreenView, и тоже не имеет русской локализации, однако предоставляет более подробную и точную информацию.

Заключение

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

Мы рады, что смогли помочь Вам в решении проблемы.

Отблагодарите автора, поделитесь статьей в социальных сетях.

Опишите, что у вас не получилось. Наши специалисты постараются ответить максимально быстро.

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

Инструменты диагностики

До сих пор для диагностики проблем высокого показателя использования центрального процессора в компьютерах Windows применялись в основном следующие инструменты.

При использовании XPERF необходимо учитывать, что инструмент собирает данные обо всех процессах и активности в системе и лишь впоследствии позволяет сузить зону поиска. Поэтому нельзя сформулировать условие: «Пройти стек для XYZ.EXE», приходится собирать данные обо всей системе. Сбор и запись всех данных об активности в поисках проблемы, которая возникает лишь один раз в сутки, могут оказаться нецелесообразными, в зависимости от типичной рабочей нагрузки контролируемых компьютеров. Дополнительные сведения об Xperf приведены в статье «Изучаем Xperf», опубликованной в предыдущем номере журнала.

Введение в ProcDump

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

Например, замечено, что wmiprvse.exe (процесс WMI Provider Host) в произвольные моменты времени занимает до 90% ресурсов центрального процессора, и нужно получить несколько дампов для анализа. Следующая команда записывает дамп процесса диспетчера очереди печати три раза, когда потребление ресурсов центрального процессора программой wmiprvse.exe достигает или превышает 90% в течение трех секунд, и сохраняет дамп в заранее подготовленном каталоге c:procdumps:

Параметр -c задает порог нагрузки центрального процессора. Параметр -s указывает, в течение какого времени служба должна занимать ресурсы центрального процессора на пороговом уровне, прежде чем начнется формирование дампа. Параметр -n указывает, сколько дампов нужно создать, а wmiprvse.exe — имя процесса, который предстоит отслеживать.

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

(тильда), чтобы выяснить, какой номер потока соответствует числу 0 x1194. На экране 2 показана командная строка и ее результат. Как видно, поток 2 (с числом 1194 в строке) является потоком, соответствующим 0x1194.

ProcDump также создаст процесс, если зависает любое из окон процесса (параметр -h); как всегда при использовании ProcDump, для запуска задачи не обязательно находиться у консоли.

Запуск процесса в отладчике

Особенно полезный параметр ProcDump (-x) обеспечивает запуск процесса непосредственно в отладчике. Параметр -x взаимодействует с разделом реестра Image File Execution Options. На экране 4 приведен пример команды, в которой параметр -x указан с процессом lsass.exe, и формируются три дампа lsass.exe, когда процесс занимает 90% ресурсов центрального процессора.

При следующем запуске lsass.exe утилита ProcDump отслеживает процесс с заданными параметрами. Это чрезвычайно удобный подход, так как существуют процессы, которые могут захватить ресурсы центрального процессора немедленно после запуска и приостановить систему до тех пор, пока центральный процессор не разгрузится, но к тому времени записывать в дамп будет нечего, так как перегрузка центрального процессора произошла. Благодаря параметру -x можно собрать данные об этих перегрузках.

Таким образом, ProcDump может быть оптимальным инструментом для диагностики большинства проблем высокой загрузки центрального процессора. Утилита ProcDump спроектирована в результате инициативы сотрудников группы Global Escalation Services компании Microsoft. Особая благодарность — старшему инженеру Мин Ченю, который первым обратился к Марку; ведущему инженеру Джеффу Дейли — за руководство и ценные указания; и, конечно, огромная благодарность Марку Русиновичу, ведущему техническому специалисту Microsoft, за то, что он прислушивается к нашим пожеланиям и быстро вносит изменения.

Читайте также: