Кража SAM-файла
Итак, если благодаря ленивому админу первый бастион защиты — пароль BIOS — рухнул, и вы имеете полный доступ к компьютеру из-под альтернативных операционных систем, то можно, наконец, приступать к взлому локальных учётных записей Windows 2000, из которых наиболее ценными являются, конечно же, администраторские. Со времён Windows NT 4 каждому дошкольнику известно, что в этой ОС для получения имён пользователей и соответствующих им паролей достаточно скопировать файл реестра SAM — базу данных Security Account Manager, диспетчера защиты учётных записей, в которой и хранятся пароли, извлекаемые впоследствии с помощью специальных программ. Файл SAM Windows NT (и одна из его резервных копий SAM.SAV) находится в папке %SystemRoot%system32config, а ещё одну его копию можно обнаружить в папке %SystemRoot%repair (и там же попадается упакованный файл SAM._, который может быть распакован командой «EXPAND SAM._ SAM»). Из-под самой Windows доступ к этому файлу (а в грамотно настроенной системе — и к его резервной копии) получить невозможно, потому-то и требуется загрузка альтернативных ОС, которой мы так активно добивались чуть выше. Обычная DOS-дискета и программа NTFS for DOS Pro отлично справляются с такой задачей. Однако уязвимость SAM-файла Microsoft однажды попыталась устранить (в Windows NT 4 SP3) и в изучаемой нами сегодня Windows 2000, если говорить проще, файл SAM по умолчанию дополнительно шифруется с помощью специальной утилиты SYSKEY.EXE (вернее, SYSKEY дополнительно шифрует хэши паролей, http://support.microsoft.com/default.aspx?scid=KB;en-us;q143475). Поэтому, в отличие от Windows NT4, в Win2k кража одного только файла SAM уже не даст злоумышленнику возможности вычислить локальные пароли. Но! Существует малюсенькая программа SAMInside, которая способна извлечь пароли из файла SAM при условии, что в её распоряжении имеется и второй по значимости файл реестра подвергшегося атаке компьютера — файл SYSTEM. Файл SAM обычно невелик и легко влезает на дискету, а вот SYSTEM может достигать нескольких мегабайт и «утащить» его чуть сложнее, но при желании, наличии архиватора, привода флоппи-дисков и полудюжины дискет всё получится.
Этот способ взлома паролей очень хорош по нескольким причинам: он предельно прост; время, которое необходимо злоумышленнику для работы непосредственно на атакуемом ПК, довольно невелико; процедуру взлома SAM-файла можно проводить в любое время в любом месте на максимально мощной машине; благодаря работе из-под DOS практически никаких следов взлома на атакованном ПК не остаётся (разве что даты последнего доступа к файлам в их атрибутах). Недостаток у этой программы один — ее демо-версия имеет существенные функциональные ограничения, которые позволяют восстанавливать только самые простые пароли. Да ещё не хватает, пожалуй, опций настройки процесса перебора паролей, максимум что предусмотрено — атака по словарю да выбор используемых при подборе пароля символов. Но даже при таком раскладе программа «щёлкает» пароли длиной до 14 символов, как семечки.
Хотя полное шифрование диска, безусловно, сделает невозможным копирование файлов реестра, никакой специальной защиты непосредственно от кражи файлов SAM и SYSTEM (так называемой атаки на SAM-файл), пожалуй, нет. Всё, что касалось защиты паролей CMOS Setup, в равной мере касается и SAM-файлов. Главная задача в обоих случаях — не допустить загрузки компьютера со сменных носителей. Также администратор обязан предотвратить несанкционированный доступ ко всем резервным копиям файлов реестра из-под Windows, что легко делается установкой соответствующих разрешений для папки %SystemRoot%repair и других папок, в которых могут оказаться эти файлы при проведении регулярного резервного копирования. О защите же самих паролей от возможности их подбора программами, аналогичными SAMInside, мы поговорим чуть ниже.
BootDev
Операционная система Windows хранит всю информацию о своих учетных записях и группах в файле SAM. Расположен он по пути \Windows\System32\config\SAM.
Получить доступ к данному файлу в работающей операционной системе Windows не возможно. Система не допускает к нему никого кроме себя. А вот если загрузиться с другой операционной системы (к примеру WinPE), то функции защиты уже не будут работать, и можно спокойно производить все желаемые манипуляции над данным файлом.
Файл SAM, отчасти является файлом реестра Windows. То есть, его можно открыть в редакторе реестра, и посмотреть какие разделы и ключи в нем содержатся. Смысла в этом не очень много, вся информация в нем представлена в виде бинарных ключей. Пароли при этом не доступны для редактирования, они попросту не отображаются в редакторе, только параметры конкретных учетных записей.
Варианты Сброса
Программы для сброса очень просты по своему использованию. Вы запускаете программу, указываете расположение SAM-файла, выбираете необходимого пользователя, выполняете сброс пароля.
Сброс Пароля
В качестве подопытного кролика будет выступать операционная система Windows 10, установленная в виртуальной машине VirtualBox. В ней будет присутствовать учетная запись с намеренно забытым паролем.
Наша цель, получить доступ к данной учетной записи.
В общем берем в руки установочный Windows-диск и читаем дальше.
Среда Предустановки
Нажимаем на клавиатуре сочетание клавиш Shift+F10 . Запустится окно командной строки.
По приветствию ввода команд видно, что текущей рабочей директорией является X:\Sources. Нам же нужно перейти в директорию файла SAM, но прежде нужно понять под какой буквой расположен диск с установленной операционной системой Windows. Выполним команду mountvol , чтобы определить все подключенные диски.
В моем случае, в системе подключено четыре диска С, D, X и E. Диск X сразу исключаем, так как он принадлежит среде предустановки. Остальные проверяем командой dir .
В ходе поисков, целевым диском в моем случае, оказался диск D:\. Выполняем смену рабочего диска командной строки на диск D:\, и переходим в каталог \Windows\System32\config.
Проверим содержимое папки на наличие файла SAM командой dir .
Создадим копию данного файла. Выполним для этого команду copy SAM SAM.bkp .
Теперь перейдем на уровень выше, в директорию System32. Команда cd .. . Переименуем исполняемый файл Utilman.exe в _Utilman.exe ( ren Utilman.exe _Utilman.exe ). Скопируем исполняемый файл cmd.exe в эту же директорию, указав в качестве нового имени имя Utilman.exe ( copy cmd.exe Utilman.exe ). То есть, выполним подмену файла.
Перезагружаем компьютер с жесткого диска. На экране входа в учетную запись, нажимаем на кнопку специальных возможностей.
Вместо привычного окна запуска специальных возможностей, запустится окно командной строки.
Запущена она будет от имени пользователя SYSTEM. В этом можно убедиться выполнив команду echo %USERNAME% .
Выполним в консоли команду lusrmgr.msc . Запустится оснастка Локальные пользователи и группы. Через нее, можно будет без каких либо затруднений выполнить сброс, либо изменение пароля необходимого пользователя.
Сброс осуществляется установкой пустого пароля.
На этом сброс пароля можно считать завершенным. Остается только вернуть все как было, то есть переименовать обратно файл _Utilman.exe, предварительно удалив ненастоящий Utilman.exe. Сделать все это, можно уже в работающей основной системе, не обязательно грузиться снова с установочного диска.
Не Utilman’ом Единым
Чуть выше, был применен трюк с переименованием системной программы Utilman.exe. Отвечает она за панель специальных возможностей, вызывается сочетанием клавиш Win+U . Это не единственная программа подлог которой можно совершить. Ниже я перечислю перечень системных программ:
osk.exe — экранная клавиатура, вызывается из меню специальных возможностей.
Magnify.exe — экранная лупа, тоже является частью специальных возможностей. Может вызываться сочетанием клавиш Win++ .
sethc.exe — программа запускающаяся при пятикратном нажатии клавиш Shift . В Windows 10, на экране входа, она не работает. Но зато в ее предшественниках, должна.
Бэкап Файла SAM
В процессе описания процедуры сброса пароля, было произведено резервное копирование файла SAM в файл SAM.bkp. После данный файл больше никак не использовался. Зачем нужна резервная копия файла SAM? С помощью резервной копии файла SAM, можно выполнить откат к состоянию до сброса пароля, то есть вернуть сброшенный пароль обратно. Рассмотрим данный процесс более подробно.
Возврат Сброшенного Пароля
Как говорилось ранее, для осуществления отката к состоянию до сброса пароля, потрербуется резервная копия файла SAM, созданная до сброса пароля.
Необходимо снова загрузиться с установочного Windows-диска, войти в командную строку и перейти в ней папку \Windows\System32\config целевой операционной системы. То есть все то, что мы делали в начале процедуры сброса пароля.
Выполняем копирование, текущего файла SAM (сброшенный пароль) в файл _SAM, а файл SAM.bkp (несброшенный пароль) копируем в файл SAM. Делается это все командами copy SAM _SAM и copy SAM.bkp SAM .
Выполняем удаление файлов SAM.LOG* командой del /A SAM.LOG x , где x это цифра. Список всех файлов SAM.LOG можно получить командой dir /A SAM.LOG* . Удалять каждый придется по отдельности (команда del не понимает файловые маски к сожалению). Если этого не сделать, могут иногда возникнуть вот такие ошибки.
Перезагружаем компьютер, и проверяем результат.
Пароль запрашивается. В завершении, не забываем удалить бэкапы файла SAM, а именно SAM.bkp и _SAM. Делать это нужно естественно загрузившись в среде предустановки.
Мы рассмотрели, ручной способ сброса пароля локальной учетной записи Windows, без применения стороннего программного обеспечения. Все что требуется, это установочный диск Windows.
Сама идея данного способа, хороша тем, что с ее помощью мы получаем в свое распоряжение командную строку с правами системы. Что в свою очередь очень сильно развязывает руки. Хоть Explorer запускай.
3 Метода Работы С Занятыми Файлами (WASM.RU)
У многих из вас, несомненно, когда-либо возникала необходимость читать/писать файлы занятые другим процессом. Это бывает например при написании бекапера, или (как ни странно) трояна. Неплохо иметь возможность стянуть файл SAM с работающей системы, или прочитать какие-либо еще файлы, доступ к которым (по недоразумению Microsoft) получить стандартными средствами не удается. Это бывает например, когда файл открыт с флагом dwShareMode = 0. Хорошим примером может быть интернет пейджер Miranda, которая во время своей работы не дает открывать файл своей базы данных. Допустим нам нужно написать трояна, который при попадании на машину вытаскивает с нее пароли и самоудаляется, но тут и возникает проблема… Поэтому я и решил написать эту статью. Статья получилась небольшая, но возможно приведенная в ней информация может быть кому-нибудь полезной. Итак, приступим .
Поиск хэндла открытого файла.
Если файл открыт каким-либо процессом, то этот процесс имеет его хэндл. Во второй моей статье по перехвату апи я описывал открытие процесса путем поиска нужного хэндла, ничто не мешает нам использовать этот метод и для доступа к открытым файлам. Нам нужно перечислить хэндлы с помощью ZwQuerySystemInformation, скопировать каждый хэндл себе с помощью DuplicateHandle, определить файл к которому он относиться (ZwQueryInformationFile), и если это нужный файл, то наконец можно его копировать.
Все это хорошо и гладко в теории, а на практике придется столкнуться с двумя подводными камнями. Первая проблема состоит в том, что при вызове ZwQueryInformationFile для хэндла открытого именованного канала, (в случае если этот канал работает в блокирующем режиме) вызывающий поток будет ждать поступления сообщения в канал, а это событие может никогда и не произойти. Тоесть фактически, поток вызывающий ZwQueryInformationFile может повиснуть навсегда. Поэтому получение имен файлов не следует делать в основном потоке перебирающем хэндлы, для этого следует запускать отдельный поток и прибивать его по таймауту в случае зависания. Проблема номер два заключается в том, что после копирования хэндла, оба хэндла (наш и процесса открывшего файл) будут указывать на один FileObject, а следовательно текущий режим ввода-вывода, позиция в файле и другая связанная с файлом информация будут общими у двух процессов. При таком раскладе даже чтение файла будет вызывать изменение позиции чтения и нарушение нормальной работы программы открывшей файл. Чтобы этого избежать, нам нужно останавливать потоки процесса владельца файла, сохранять текущую позицию, копировать файл, восстанавливать текущую позицию и запускать процесс владелец снова. Такой метод может быть во многих случаях неприемлемым, например скопировать файлы реестра на работающей системе с его помощью не удастся.
Попробуем для начала реализовать перечисление всех открытых в системе файлов. При перечислении хэндлов, каждый хэндл будет описываться следующей структурой:
Поле ObjectType здесь определяет тип объекта к которому относиться хэндл. И тут нас опять поджидает проблема — ObjectType для типа File имеют разное значение в Windows 2000, XP и 2003, поэтому нам придется определить эту константу динамически. Для этого откроем с помощью CreateFile девайс NUL, найдем его хэндл и запомним его тип:
Теперь зная тип хзндла мы можем перечислить открытые в системе файлы. Для начала реализуем получение имени открытого файла по его хэндлу:
Вот теперь собственно можно и перечислить открытые файлы:
Теперь для копирования файла нам остается лишь прочитать его с помощью ReadFile при нахождении нужного хэндла. При необходимости следует принять вышеописанные меры осторожности.
Из достоинств этого метода можно отметить простоту его реализации, но недостатков к сожалению куда больше, поэтому этот метод стоит использовать разве что для определения того, каким процессом занят файл.
Изменение прав доступа существующего хэндла.
Все занятые файлы (за исключением файлов подкачек) обычно удается открыть на чтение атрибутов (FILE_READ_ATTRIBUTES), это позволяет читать атрибуты файла, получать его размер, перечислять NTFS потоки, но к сожалению ReadFile завершается неудачно. Чем отличается открытие файла с разными атрибутами доступа? Очевидно, что при открытии файла система запоминает атрибуты доступа, и потом сравнивает запрашиваемый доступ с этими атрибутами. Если найти то место, куда система сохраняет эту информацию и изменить атрибуты доступа, то можно будет не только читать, а даже писать в любой файл который удалось вообще как-либо открыть.
На уровне пользователя мы работаем с файлом не напрямую, а через его хэндл (этот хэндл указывает на FileObject), а функции ReadFile/WriteFile вызывают ObReferenceObjectByHandle указывая ему соответствующий тип доступа. Из этого можно сделать вывод, что права доступа хранятся в самой структуре описывающей хэндл. И действительно, структура HANDLE_TABLE_ENTRY содержит поле GrantedAccess, которое и есть ни что иное, как эти самые права доступа связанные с хэндлом. К сожалению, программисты Mocrosoft не предусмотрели API для изменения доступа хэндлов, поэтому, как вы поняли, нам придется писать драйвер чтобы это сделать.
Структуру таблиц хэндлов в Windows 2000 и XP я рассматривал в статье «Обнаружение скрытых процессов», к написанному там хочу лишь добавить, что таблицы хэндлов в Windows 2003 полностью аналогична XP. В отличии от той статьи, нам нужно будет не перечислять хэндлы в таблице, а найти какой-то конкретный (известный) хэндл, и работать мы будем не с PspCidTable, а с таблицей хэндлов своего процесса, указатель на которую находиться в его структуре EPROCESS (смещение 0x128 в 2000 и 0x0C4 в XP).
Для получения указателя на структуру хэндла случит неэкспортируемая функция ExpLookupHandleTableEntry, но искать мы ее не будем, так как на нее нет прямых ссылок из экспортируемых функций и поиск будет слишком ненадежным, к тому же нам тогда понадобиться еще и функция ExUnlockHandleTableEntry. Лучшим выходом будет написать свою функцию лукапа по таблицам хэндлов. В виду отличия структур таблиц хэндлов в Windows 2000 и XP, эта функция для них будет выглядеть по разному.
Для начала сделаем такую функцию для Windows 2000:
Этот код прост и понятен. Так как значение хэндла представляет из себя три индекса в трехуровневой таблице, то мы просто извлекаем их чисти и смотрим соответствующий элемент таблицы (если он конечно существует). Так как таблица хэндлов в Windows XP может иметь от одного до трех уровней, то код лукапа соответственно будет сложнее:
Как вы видите, хэндл в этом коде представлен не ULONG значением, а структурой EXHANDLE:
Как вы видите, хэндл содержит не только индексы в таблице, но и 2 бита служебных флагов. Наверное вы замечали, что одинаковый хэндл может иметь несколько разных значений, это связано с тем, что не все биты значения хэндла используются (зависит от числа уровней в таблице). Наиболее характерно это явление проявляется в Windows XP.
Итак, теперь мы можем получить нужный элемент таблицы хэндлов, пора писать функцию устанавливающую на хэндл нужные атрибуты доступа:
Теперь сделаем драйвер устанавливающие атрибуты доступа на хэндл переданный ему по DeviceIoControl. Его код будет выглядеть так:
Поле GrantedAccess в структуре хэндла к сожалению не соответствует атрибутам открытия файла (GENERIC_READ, GENERIC_WRITE e.t.c.), поэтому при установке новых атрибутов доступа нам понадобятся следующие константы:
Теперь напишем простую программку которая используя этот драйвер будет копировать SAM файл в корень диска c:
Самым большим недостатком этого метода является сильная зависимость от операционной системы. Также его применение вынуждает таскать с своей прогой драйвер, что не всегда приемлемо. Но в плане надежности этот способ один из лучших, поэтому я рекомендую его применять в бекаперах (но только после продолжительного тестирования и отладки!). Но так как способ не подходит для любых ситуаций, мы перейдем к следующему способу.
Чтение файла с помощью прямого доступа к диску.
«Прямой доступ к диску» это конечно круто, но спешу разочаровать некоторых любителей программирования в DOS, никакой работы с железом не будет, так как мелкомягкие позаботились о нашем благополучии и предоставили удобные и простые API через которые можно работать с диском почти «напрямую». Как вы уже поняли — речь идет об открытии тома в RAW режиме и чтении файла покластерно. Надеюсь никто еще не испугался ��
Если решать эту задачу «в лоб», вручную парся структуры файловой системы, то мы рискуем написать много лишнего кода и преждевременно нажить геморрой, поэтому делать мы это не будем, а еще раз обратимся к великому мануалу мелкомягких — MSDN. Очень полезным для нас будут разделы «Defragmenting Files » и «Disk Management Control Codes», именно там описаны управляющие коды драйвера файловой системы, которые используют в своей работе различные дефрагментаторы. Если вы удосужились открыть MSDN, то несомненно обнаружили, что IOCTL код FSCTL_GET_RETRIEVAL_POINTERS позволяет получить карту размещения файла. Тоесть нам достаточно с помощью этого IOCTL получить список кластеров занятых файлом и прочитать их.
При вызове DeviceIoControl с этим кодом, InputBuffer должен содержать структуру STARTING_VCN_INPUT_BUFFER описывающую начальный элемент цепочки кластеров с которого мы хотим получить карту размещения файла, а после успешного выполнения функции OutputBuffer будет содержать структуру RETRIEVAL_POINTERS_BUFFER которая описывает карту размещения. Давайте рассмотрим эти структуры подробнее:
С первой структурой все понятно, нам просто нужно передать 0 в StartingVcn.QuadPart, а вот формат выдаваемой структуры следует рассмотреть подробнее. Первое поле (ExtentCount) содержит количество элементов Extents в структуре. StartingVcn — номер первой цепочки кластеров файла. Каждый элемент Extents содержит поле NextVcn содержит количество кластеров в цепочке, а Lcn — номер ее первого кластера. Тоесть выходная информация представляет из себя массив описателей цепочек, каждая из которых может содержать по несколько кластеров.
Итак, теперь структура выходной информации понятна, и пришла пора написать функцию получающую полный список кластеров файла и представляющую его в виде массива:
На выходе этой функции мы имеем массив описывающий кластеры файла и число этих кластеров, теперь можно легко скопировать файл:
Вот собственно и все, скопировать SAM теперь просто как три рубля :). В примерах к статье есть программка копирующая SAM в файл указанный в ее командной строке.
Несомненно этот метод выглядит просто и кажется весьма мощным, но к сожалению и ему присущи недостатки. Таким способом можно читать только файлы которые можно открыть с доступом FILE_READ_ATTRIBUTES (не читаются только файлы подкачки), файл обязательно должен быть не сжат, не зашифрован (иначе мы прочитаем ерунду), и должен иметь свой кластер (маленькие файлы в NTFS могут целиком размещаться в MFT). Также следует учесть, что во время чтения файл может быть изменен (и мы получим в результате фиг знает что).
Итак, как работать с файловой системой на низком уровне, я думаю всем теперь понятно. Эта методика открывает немалые возможности для различных руткитов. Существуют программы защищающие системные файлы от модификации, (примером такой программы может быть антивирус), но при наличии прав достаточных для открытия тома в RAW режиме, такие ограничения быстро сходят на нет. К тому же хороший администратор может настроить ведение логов чтения/записи важных файлов на своем сервере, а прямой доступ к тому никаких логов не оставляет, но для полноценного доступа к файлам придется писать свой драйвер NTFS.
Nagits's Blog
userLevel2system и узнаем пароль администраторской учетной записи
Повышаем привилегии до системных с помощью сплоита KiTrap0d, а также вытягиваем пароль админа с помощью PWdump и L0phtCrack.
Итак, изложу суть дела. Представим очень знакомую ситуацию (для студентов и секретарш ): администраторская учетная запись заблокирована от кривых рук паролем, а мы находимся в обычной (гостевой) учетной записи. Не зная пароля или не имея прав администратора, мы не можем шариться на рабочем столе админа (типа «C:\Users\admin» — Отказано в доступе), не можем изменять папки Program Files и Windows … — а нам очень нужно! Что делать?
1. KiTrap0D forever! — повышаем привилегии аж до System
В начале 2010 года хакером T. Ormandy была опубликована 0-day уязвимость , позволяющая повысить привилегии в любой версии Windows. Этот сплоит получил название KiTrap0d и в нынешних базах антивирусов занесен в раздел типа Win32.HackTool («хакерский инструмент» ).
Итак, отключаем антивирус (ну, вы же мне доверяете! ). Далее скачивам сплоит из моих документов по адресу https://www.box.net/shared/1hjy8x6ry3 (пароль nagits — чтобы антивирус не ругался) или поищите на сайте http://exploit-db.com по имени Tavis Ormandy. Скомпилированный сплоит состоит из 2 файлов: библиотека vdmexploit.dll и исполняемый vdmallowed.exe. По щелчку на exe-шнике запускается сплоит и открывается командная строка cmd.exe с системными привилегиями NT AUTHORITY\SYSTEM!
А теперь, как говорится, флаг вам в руки! Обладая такими правами, можно скопировать нужные вам файлы, узнать ценную информацию…
2. Узнаем пароль администраторской учетной записи
…, но все таки будет гораздо полезнее узнать пароль админа.
Пароли учетных записей в Windows хранятся в виде хешей в специальных ветвях реестра HKLM\SAM и HKLM\SECURITY и доступ к ним закрыт даже администраторам. Соответствующие файлы базы данных Security Account Manager находятся в папке %SystemRoot%\system32\config в файлах SAM и SYSTEM, но скопировать их просто так также не получится, впрочем, об этом чуть позже. Поэтому так важно, что мы получаем именно системные права.
Я расскажу о двух подходах получения заведомого пароля. Один касается, как вы наверное поняли, реестра — дамп паролей. Второй подход, как советует капитан очевидность, заключается в получении файла SAM.
2. Способ 1. Дампим пароли
Пользоваться будем достаточно известной утилитой pwdump, которую вы можете скачать из Моих документов по адресу https://www.box.net/shared/9k7ab4un69 (пароль nagits). Переключаемся в командную строку cmd.exe с системными правами и запускаем pwdump.
утилита сбросит дамп паролей в файл.
Например, pass_dump.txt может выглядеть так:
Видно, что Uzver — обычный пользователь, не защищен паролем, а VirtualNagits — администратор, и приведен хеш его пароля.
Далее, остается воспользоваться брутфорсером для расшифровки дампа.
Я для примера буду пользоваться программой l0phtcrack. Скачать шароварную можете по адресу www.l0phtcrack.com/.
Начиная с Windows NT 3.1 (27 июля 1993) пароли хранятся в т.н. NTLM-хеше. К сожалению, программа l0phtcrack согласится атаковать NTLM-хеши только после регистрации\покупки программного продукта. Кстати установку необходимо запускать с правами администратора — как минимум. Поэтому установочный файл запускаем из под cmd.exe с правами System.
Итак, у меня есть установленная и зарегистрированная l0phtcrack v5.04 и pass_dump.txt: 
В программе l0phtcrack давим на кнопку Import:
Выбираем импорт из файла PWDUMP (From PWDUMP file), указываем наш pass_dump.txt.
Теперь необходимо в опциях 
отметить взлом NTLM паролей:
Подтверждаем выбор нажатием OK и нажимаем Begin Audit 
.
Есть! Хитроумный пароль «123456» администратора получен!
Вместо pwdump и l0phtcrack рекомендую также воспользоваться freeware программой Cain&Abel. Этим замечательным инструментом я похвастаюсь в другой статье).
2. Способ 2. Получаем пароли из файла SAM.
Вообще, скопировать файл SAM из С:\windows\system32\config\ нельзя даже под правами SYSTEM, поскольку они «заняты другим приложением». Диспетчер задач не поможет, поскольку если вы даже и найдете виновный, отвечающий за Security Account Manager процесс, завершить вы его не в силах, поскольку он системный. В основном все их копируют с помощью загрузочного диска, в таком случае нам даже и не нужны права администратора. Но зачастую в руках нет LiveCD…
Дак вот, считать эти файлы можно с помощью низкоуровнего доступа к диску.
Это очень хорошо описано на сайте http://wasm.ru/article.php?article=lockfileswork под заголовком (Чтение файла с помощью прямого доступа к диску).
Вот ссылка на скомпилированную программу: http://wasm.ru/pub/21/files/lockfileswork/RawRead.rar (Пример чтения SAM с помошью прямого доступа к тому).
С помощью команды (из cmd.exe с системными правами, не забыли еще KiTrap0D?):
программа копирует файл SAM из системной директории \config\SAM в файл, указанный в параметре, т.е. D:\TMP\SAM
Брутфорсер l0phtcrack поддерживает импорт SAM-файлов, но программа яросно предупреждает о шифровании SYSKEY:
L0phtcrack не обладает возможностью взлома расширенного SYSKEY-шифрования базы данных SAM. Поэтому, если на взламываемой системе используется SYSKEY-шифрование (помойму оно используется, начиная с Service Pack 3 for NT 4.0, в 2000/XP — по умолчанию), необходимо дополнительно расшифровывать SAM файл, либо пользоваться способом 1.