Изменение, произошедшее в этой индустрии за последние несколько лет, связано с тем, что сегодня большая часть пугающих программ (scareware) также становится программами, требующими мзду (ransomware). Примеры 2006 года просто изводили вас предупреждениями, что система заражена, но, тем не менее, позволяли использовать компьютер. Современное scareware, как минимум, предотвращает запуск диагностики и антивирусов, а зачастую вообще не позволяет запускать любые программы. Без специальных приемов очистки система, зараженная ransomware, позволяет лишь осуществить платеж по требованию шантажиста.

В этом сообщении я расскажу, как разные варианты ransomware блокируют пользователя в системе, как они выживают при перезагрузке, и как можно использовать программу Sysinternals Autoruns для выслеживания и удаления самых современных экземпляров таких программ из зараженной системы.

Добыча

Перед началом охоты стоит познакомиться с ее объектом. Наиболее распространенный тип программ-вымогателей денег, вроде ложного антивируса, обычно ставит целью постоянно раздражать пользователя, а не полностью изолировать его от системы. Наиболее распространенные штаммы используют встроенные списки исполняемых программ, чтобы знать, что именно они будут блокировать, обычно включающие большинство антивирусов и даже основные инструменты Sysinternals. Они, как правило, позволяют пользователю запускать системные приложения вроде Paint, но иногда блокируют некоторые из них. При блокировке они выводят диалоговое окно с ложным сообщением о блокировке из-за заражения:

Но за последнюю пару лет вредоносное ПО стало более агрессивным, не занимаясь ничем, кроме вымогания денег. В этом примере компьютер полностью захватывается, блокируется доступ ко всему, кроме собственного окна, и программа требует код разблокировки для восстановления контроля над системой, который пользователь должен купить, позвонив по приведенному номеру (в данном случае, с кодом России):

Есть вариант, когда подобным образом захватывается компьютер, но пользователя вынуждают сделать онлайн-покупки для восстановления контроля над компьютером (я не исследовал, сколько покупок возвращают контроль над ПК):

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

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

Что касается способов, которыми это ПО изолирует пользователя от компьютера, то на практике используются разные приемы. Один, наиболее общий, используется множеством ложных антивирусов, подобных Security Shield, и состоит в блокировании выполнения других программ путем отслеживания появления новых окон и насильственного прекращения соответствующих процессов. Другой способ, применяемый в примере с онлайновыми продажами, заключается в сокрытии всех окон (установке атрибута невидимости), которые не относятся к вредоносной программе. В этом случае вы можете запускать другие программы, но не можете взаимодействовать с ними. Похожий подход используется во вредоносном ПО, которое создает полноэкранное окно и постоянно поднимает его над остальными окнами системы, заслоняя собой окна других приложений. Я также наблюдал и обходной путь, когда создается новый рабочий стол и пользователь переключается на него, аналогично тому, как это делается в Sysinternals Desktops, и хотя ваши программы по-прежнему работают, вы не можете переключиться на исходный рабочий стол, чтобы взаимодействовать с ними.

Находим позицию для охоты

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

К несчастью, большинство систем оставляют лишь одну административную системную запись, удаляя альтернативные. Резервный вариант – попробовать безопасный режим загрузки системы Safe Mode, который запускается при нажатии на F8 в процессе загрузки (немного сложнее в Windows 8). Большая часть программ-вымогателей настраивается на автоматический запуск, создавая записи в ключах реестра Run или RunOnce раздела HKCU\Software\Microsoft\Windows\CurrentVersion (или вариантах HKLM), которые не обрабатываются в безопасном режиме, поэтому безопасный режим представляет собой удобную площадку для проведения очистки системы от такого ПО. Все большее число программ-вымогателей изменяет раздел HKCU\Software\Microsoft\Window NT\CurrentVersion\Winlogon\Shell (или HKLM), который обрабатывается как в режиме Safe Mode, так и в Safe with Networking. Однако режим загрузки Safe Mode with Command Prompt отменяет выбор программы-оболочки из реестра, поэтому с его помощью можно перехитрить большинство современных программ-вымогателей, и он является следующей запасной позицией:

Наконец, если вредоносная программа оказывается активной даже при загрузке в режиме Safe Mode with Command Prompt, у вас не остается выбора, кроме как отправится на охоту из альтернативной установки Windows. При этом возможен ряд вариантов. Если у вас стоит Windows 8, то идеальный вариант – создание установки Windows 8 To Go, так как это полная версия Windows. Другой способ – загрузить установочный диск и нажать Shift+F10 при достижении первого графического экрана, чтобы открыть окно командной строки:

У вас не будет доступа к Internet Explorer, и многие другие приложения не будут работать корректно в урезанном окружении Windows Setup, но вы сможете запустить инструменты Sysinternals. Наконец, можно создать загрузочный носитель Windows Preinstallation Environment (WinPE), имеющий окружение подобное Windows Setup и использовать что-то вроде Microsoft Diagnostic and Repair Tooltkit (MSDaRT).

Охота

Теперь, когда мы определились с объектом охоты, самое время подумать об оружии. Самое простое, конечно, использовать готовый антивирус. Если вы вошли с помощью альтернативной учетной записи или в безопасном режиме, то можете использовать стандартные продукты для онлайнового сканирования, многие из которых свободно доступны, подобно Windows Defender корпорации Microsoft. Если вы загружены из другой установки Windows, вам понадобиться использовать автономный сканер, подобный Windows Defender Offline. Если антивирус неспособен обнаружить или вычистить заражение, вам придется обратиться к более точному и ручному оружию.

Утилитой, способной перерубить путы вредоносного кода в системе, является Sysinternals Autoruns. Она знает более сотни мест, откуда зараза может стартовать при загрузке Windows, входе пользователя в систему, или запуске особых встроенных приложений. Способ ее запуска зависит от того, из какого окружения вы ведете охоту, но, в любом случае, она должна запускаться с правами администратора. Также Autoruns автоматически начинает сканирование при запуске, вы должны прервать его, нажав клавишу ESC, затем открыть диалог фильтрации и выбрать параметры проверки сигнатур и сокрытия всех входов Microsoft, так чтобы вредоносное ПО проявилось более отчетливо и уже после этого перезапустить сканирование:

Если вы вошли с помощью учетной записи, отличной от зараженной, то необходимо указать утилите на зараженную учетную запись из меню «Пользователи» (Users). В данном примере Autoruns запускается из учетной записи Fred, но поскольку заражена запись Abby, я выбрал профиль Abby:

Если вы загрузились из другой ОС, то придется воспользоваться поддержкой автономной работы, которая требует указания корневого каталога целевой установки Windows и целевого профиля пользователя. Откройте диалоговое окно «Analyze Offline System» из меню File и введите соответствующие каталоги:

После сканирования системы утилитой Autoruns вы должны определить вредоносное ПО. Как я объяснял в своей презентации «Охота за вредоносным ПО с помощью инструментов Sysinternals», часто вредоносное ПО демонстрирует следующие свойства:

• Отсутствие иконки
• Отсутствие описания или имени компании
• Неподписанные Microsoft образы
• Живет в каталоге Windows или профиле пользователя
• Запаковано
• Включает странные URL в свои строки
• Имеет открытые конечные точки TCP/IP
• Содержит подозрительные DLL или сервисы

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

Один из недостатков автономного сканирования состоит в неверной работе проверки подписей. Это происходит потому, что Windows применяет подписывание каталогов, когда подписи хранятся в отдельных файлах, в противоположность прямой подписи в самих образах программ. Autoruns не обрабатывает автономные файлы каталогов (возможно, я добавлю такую поддержку в ближайшем будущем), поэтому все образы, подписанные через каталог, будут показываться как непроверенные и подсвечиваться красным. Так как большая часть вредоносного ПО не претендует на то, чтобы в поле компании стояло слово Microsoft, то можно попытаться выполнить первоначальное сканирование с отключенной опцией проверки кодов подписей. Ниже приведен результат автономного сканирования с отключенной проверкой подписей системы, зараженной ransomware, которое получило контроль над двумя позициями автостарта – поглядим, сможете ли вы их обнаружить:

Если вы не уверены в каком-то запускаемом файле, то можете попытаться загрузить его на сайт Virustotal.com для анализа примерно 40 наиболее популярными антивирусами, найти информацию в интернете, или посмотреть на встроенные в файл строки с помощью утилиты Sysinternals Strings.

Ликвидация

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

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

Удачной охоты!

Дело началось, когда сетевой администратор южноафриканской компании связался со службой поддержки Microsoft Services Premier Support и сообщил, что корпоративный Exchange-сервер, работающий под управлением Windows Server 2008 R2, создает исходящие FTP-соединения. Он заметил это только благодаря предупреждению установленного в компании Microsoft Forefront Endpoint Protection (FEP) о том, что тот вычистил с сервера кусок вредоносного кода. Предполагая, что сеть может быть по-прежнему скомпрометирована, несмотря на сообщение FEP о чистоте системы, администратор проверил журналы брандмауэров, защищающих периметр компании. К своему ужасу он обнаружил FTP-соединения, исчислявшимися сотнями в день на продолжении нескольких последних недель. Вместо попытки начать собственное расследование, администратор обратился в команду консультантов по безопасности Microsoft, специализирующуюся на помощи пользователям при восстановлении после атак.

Инженер поддержки Microsoft, которому было поручено дело, начал с пятиминутной трассировки событий сервера Exchange, выполненной с помощью программы Process Monitor. После завершения трассировки он открыл диалог Process Tree (дерево процессов), который находится в меню Tools и показывает отношения родитель-потомок для всех процессов, попавших в текущий журнал. Он сразу увидел, что за эти пять минут были запущены 20 FTP-процессов, каждый из которых был короткоживущим, за исключением одного, остававшегося по-прежнему активным (процесс 7324 на рисунке ниже):

Инженер обратился к командам, запускающим FTP-процессы, выбирая последние в дереве процессов, так чтобы их детали появились внизу диалога Process Tree. Причудливым образом половина команд содержала только аргумент “-?”, который выводит справку по FTP:

Другая половина была более интересна, она содержала ключи “-i” и “-s”:

Ключ “-i” выключает подсказку при пересылке нескольких файлов, а “-s” предписывает выполнить FTP-команды из файла, в данном случае, из файла “j”. Желая понять, что содержит файл “j”, инженер щелкнул на кнопке “Include Process” внизу диалога Process Tree, чтобы увидеть события, связанные с файлами процесса:

Он просмотрел результаты, отфильтровав журнал по “j” и обнаружил местоположение файла в нескольких событиях:

Он перешел в каталог C:\Windows\System32\i4333, но файла там не было. Это был тупик, и он переключил внимание на родительский процесс Cmd.exe и взглянул на его командную строку. Она была очень длинной и запутанной для простого понимания:

Он выделил ее, скопировал в буфер и вставил в Notepad, а затем разбил на составляющие, каждая из которых отделялась амперсандом “&”. Результат выглядел следующим образом:

Первая инструкция создавала каталог с именем i4333, а затем начиналось создание файла “j”. Команды, записанные в “j”, предписывали FTP соединиться с NUXZb.in.into4.info, зайти с именем «New» и паролем “123”, и загрузить все файлы с расширением “.exe”. После выполнения файл уничтожался и создавался командный файл, запускавший скачанные файлы, сначала с помощью Shell (параметр “start”), а затем из командной строки.

Краткое обращение к Whois показало, что имя хоста NUXZb относится к Protected Name Services и не содержит никакой полезной информации. Инженер отключил разрешение сетевых имен в Process Monitor и оставил в журнале исходящие FTP-соединения, чтобы увидеть IP-адрес, соответствующий разрешенному имени:

Определение местоположения IP-адреса в Интернет указало на IP-адрес ISP в Чикаго (теперь имя разрешается к другому IP-адресу), из чего инженер заключил, что либо соединение было со скомпрометированным сервером, либо атакующий располагался у этого ISP. Завершая анализ командной строки, он обратился к содержимому результирующего скрипта, D.bat, который по-прежнему был в каталоге и содержал единственную команду:

Не случайно, 134.exe оказался тем самым выполняемым кодом, на который среагировал Forefront, как на троян удаленного доступа (remote access Trojan, RAT) в предупреждении, с которого все началось. Поэтому скрипт не может найти его, и атака – или, по крайней мере, часть ее – была нейтрализована FEP. Также имейте в виду, что атака была автоматизирована и застряла в цикле, пытаясь активироваться.

Следующим шагом инженера было выяснить, как был запущен процесс командной строки. Взглянув на родительский процесс в дереве, он обнаружил, что все экземпляры запускались Sqlserver.exe:

Очевидно, это плохой знак, но не самое худшее: проверяя сетевую активность SQL Server в журнале, он обнаружил множество входящих подключений:

Поиск местоположений IP-адресов привел в Китай, Тунис, Тайвань и Марокко:

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

Он запустил специальный файл поддержки Microsoft, проверяющий различные установки безопасности SQL Server. Скрипт проработал несколько секунд и выдал обескураживающий результат: сервер имел административную учетную запись с пустым паролем, был настроен на аутентификацию в смешанном режиме и позволял хранимым процедурам запускать окно командной строки из-за разрешения «xp_cmdshell»:

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

С помощью программы Process Monitor и обсуждения с администратором компании, инженер службы поддержки составил ясное представление о случившемся: администратор компании установил SQL Server на Exchange Server компании за несколько недель до инцидента. Не осознавая, что сервер находится на периметре, он открыл порт SQL Server в локальном брандмауэре, оставил его с пустым паролем администратора и разрешил xp_cmdshell. Это произошло, несмотря на то, что даже если сервер не имеет связи с Интернет, такая конфигурация оставляет его безо всякой сетевой защиты. Спустя недолгое время, автоматическое вредоносное ПО, сканируя интернет в поисках незащищенных целей, столкнулось с открытым портом SQL, заразило сервер вредоносным кодом и, скорее всего, включило его в списки ботнета. Сигнатуры FEP для нового кода были доставлены на сервер спустя некоторое время, и программа удалила заражение. Вредоносное ПО по-прежнему пыталось реинтегрировать сервер в ботнет, когда было открыто дело в службе поддержки Microsoft. Хотя компания и не узнала, сколько данных было украдено в процессе заражения (и вообще было ли хоть сколько), это был очень громкий и ясный звоночек.

Вы можете проверить собственные знания о кибербезопасности, пройдя мой тест «Операция «Опустошение».

История разворачивалась в позапрошлую неделю, когда я отправился в Орландо выступить на конференции Microsoft TechEd North America. Когда я был там, я столкнулся с пятиминутными задержками при входе в свою систему Windows 7, сопровождавшимися черным экраном:

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

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

Как только выдался свободный момент, я запустил программу Sysinternals Autoruns, усовершенствованную утилиту управления автозапуском программ, чтобы запретить все образы, расположенные на разделяемых сетевых ресурсах. Из прошлого опыта запуска Autoruns на лаптопе мне было известно, что служба Microsoft IT настраивает несколько плановых задач для выполнения командных файлов, расположенных на корпоративных разделяемых сетевых ресурсах, и подозревал, что таймауты связаны с попыткой запустить их:

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

Теперь моей целью было установить, что удерживало от переключения на рабочий стол. Мне требовался способ увидеть, что происходит во время регистрации в системе непосредственно после загрузки. Способ, сразу приходящий в голову, – использовать Sysinternals Process Monitor для регистрации событий процесса загрузки. Process Monitor – инструмент, регистрирующий общесистемные операции с файловой системой, реестром, процессами, DLL и сетью, – способен записывать действия с самых ранних этапов загрузки до момента, когда система выключается или пока вы не запустите пользовательский интерфейс Process Monitor. Я выбрал запись загрузки из меню Options и открыл диалог записи загрузки:

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

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

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

Предполагая, что, возможно, последовательность процессов, запущенная при входе в систему могла вызвать что-то похожее, я открыл диалог дерева процессов из меню Tools. Этот диалог показывает взаимоотношения родитель-ребенок для всех активных процессов при записи журнала, что в случае загрузки означает все процессы, выполняющиеся во время загрузки и входа в систему. Сфокусировавшись на Winlogon.exe, интерактивном менеджере входа в систему, я заметил, что процесс Atbroker.exe запустился приблизительно тогда, когда я ввел свои учетные данные, и затем Userinit.exe выполнился, когда, наконец, возник рабочий стол:

Ключ к решению загадки находился в длинной паузе между этими событиями. Я знал, что Logonui.exe просто выводит интерфейс для входа пользователя, а Atbroker.exe – просто вспомогательный механизм для перехода от интерфейса входа к сеансу пользователя, что исключает паузы, по крайней мере первоначально. Черный экран исчезает при запуске Userinit.exe, так что его родительский процесс Winlogon.exe остался под подозрением. Я настроил фильтр на включение событий только от Winlogon.exe и добавил столбец относительного времени, чтобы легко контролировать, когда случилось событие по отношению к началу загрузки. Когда я взглянул на результаты, я сразу увидел, что задержка составляет около шести минут, но в этот период времени нет активности, которая указала бы на ее причину:

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

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

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

Когда я впервые запустил в системе Process Monitor, я настроил его на получение символов для образов Windows с публичного сервера символов Microsoft, используя DLL механизма отладки из средств отладки для Windows, чтобы видеть во фреймах стека осмысленные имена функций исполняемых модулей Windows, а не просто смещения в файлах.

Стек первого потока определяет его как поток «конечного автомата» ядра Winlogon, ожидающего какого-то неизвестного оповещения, и не содержит ничего интересного:

Стек следующего потока тоже ничего не разъясняет, показывая, что поток является общим исполняющим потоком:

Стек третьего потока оказался намного более интересным. Он был многоуровневым, включая вызовы функций Multiple UNC Provider (MUP) и драйверов клиентской распределенной файловой системы, ответственных за доступ к файловым серверам:

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

Следующая функция фрейма, WNetRestoreAllConnectionsW, вместе с последующими вызовами функций файлового сервера, привела меня к заключению, что Winlogon старался восстановить соответствие букв дисков файлового сервера перед тем, как продолжить запуск оболочки и дать доступ к рабочему столу. Я открыл Explorer, вспомнив, что у меня были два накопителя, отображаемые на разделяемые сетевые диски, расположенные на компьютерах внутри сети Microsoft, один для моей системы разработки, а другой для внутреннего ресурса Sysinternals, куда я публикую предварительные версии утилит. Находясь на конференции, я не имел доступа к интрасети, поэтому Winlogon не мог подсоединить их во время процедуры входа и в итоге, через много минут, выдавал:

Уверенный, что нашел отгадку, я щелкнул правой клавишей мыши на каждом ресурсе и отсоединил его. Я перезагрузил лэптоп, чтобы проверить исправление (точнее, обходной маневр) и к своему огромному удовлетворению убедился, что время от процедуры входа, до появления рабочего стола заняло лишь несколько секунд. Дело было закрыто! Исследовать, почему эти задержки настолько продолжительны, я не имел ни времени, ни необходимости. Мораль этой истории заключается не в самой проблеме, а в том, как с помощью инструментов Sysinternals и приемов поиска ошибок решать проблемы.

Прошедший в Амстердаме TechEd Europe предоставил мне возможность повторить выступление, которое было на TechEd US. Я прочитал ту же лекцию по поиску и устранению неисправностей «Дело о необъяснимом», которая была и на TechEd US, но на этот раз я имел удовольствие поделитться этим свежим случаем, произошедшим лично со мной. Вы можете посмотреть запись этой лекции среди других лекций TechEd, зайдя на страницу моих веб-кастов, на которой выложен список записей моих основных выступлений, либо обратится к непосредственным ссылкам ниже:

Windows Azure Virtual Machines and Virtual Networks
Windows Azure Internals
Malware Hunting with the Sysinternals Tools
Case of the Unexplained 2012

А также можно посмотреть записи всех выступлений на обоих мероприятиях на соответствующих сайтах:

TechEd North America 2012 On-Demand Recordings
TechEd Europe 2012 On-Demand Recordings

Надеюсь, вам понравилось это дело!

«Троянский конь» выйдет в свет 4 сентября, но вы можете сделать заказ уже сейчас на своем любимом онлайновом книжном магазине (в Штатах только теперь, но корейский издатель «Дня ноль» уже выкупил права на публикацию за рубежом). Найдите ссылки для заказа, почитайте еще о «Троянском коне», посмотрите мои остальные книги, загляните в мой книжный блог и найдите, где я рассказываю о своем новом сайте markrussinovich.com. Закажите «Троянского коня» и расскажите о нем своим друзьям!

Однако на этот раз я столкнулся не просто с обычной проверкой. Мама недавно приобрела новый ПК, так что в результате я провел жуткий час, удаляя кучи OEM-овского мусора, загруженного в него (теперь я буду рекомендовать Microsoft Signature PC, который свободен от мусорных программ). Я сказал жуткий, потому, что это заняло время и потому, что даже простые приложения были сделаны как монстры, со сложной и продолжительной процедурой деинсталляции. Даже у гарантии OEM и файлов справки были полновесные процедуры установки. Ухудшая ситуацию, несколько приложений не смогли успешно деинсталлироваться либо выдавая сообщение об ошибке, либо оставляя после себя «бродячие» фрагменты, заставляя меня выслеживать их и наносить точные удары.

Когда чистка подходила к концу, я заметил, что антивирус, который OEM поместил на ПК, имеет годовую лицензию, после чего придется покупать новую, чтобы продолжить обслуживание. Имея на рынке прекрасные бесплатные антивирусные решения, пользователям нет причин для покупки антивирусов, так что я сразу деинсталлировал его (что, конечно, оказалось многошаговой процедурой, занявшей около 20 минут и выдавшей несколько ошибок). Затем я отправился в Интернет чтобы скачать то, что я считаю – и неудивительно, принимая во внимание мою принадлежность – наилучшим бесплатным антивирусным решением, Microsoft Security Essentials (MSE). Спустя пару минут программа установки загрузилась, и запустился мастер установки. После нескольких щелчков на первых нескольких страницах он сообщил, что собирается установить MSE, но затем немедленно пожаловался на ошибку, которая не дает мастеру установки Security Essentials завершиться успешно:

Предложение «перезапустить компьютер и попробовать снова» предназначено для решения проблем, вызванных вмешательством от незавершенной деинсталляции существующего антивирусного ПО (или дает надежду на то, что условия, вызвавшие проблему с неожиданной ошибкой, являются преходящими). Я только что перезагрузился, поэтому это не подходило. Щелчок по ссылке «Получить помощь по ошибке» рекомендует самые общие шаги по устранению неисправности, вроде деинсталлировать другие антивирусы, убедиться в том, что сервис Windows Installer сконфигурирован и запущен (хотя по умолчанию он не работает в Windows 7, так как запускается по требованию), и если все не сработает, обратится в службу поддержки.

Я предположил, что ситуация, с которой я столкнулся – достаточно редкая, и служба поддержки пользователей не сможет мне помочь (и что они скажут, если узнают, что Марк Руссинович обращается в службу поддержки?) , особенно после того как в Интернете не обнаружилось помощи по ошибке с кодом 0x80070643. Мой шурин, который также является программистом и одновременно специалистом по технической поддержке для своих соседей, заглядывал мне через плечо и подавал советы, так что я испытывал некоторое давление, пытаясь исправить ситуацию. Запустил свой любимый инструмент диагностики, Sysinternals Process Monitor (помните, «когда сомневаетесь запускайте Process Monitor»).

Я перезапустил установку MSE, попутно записывая трассировку с помощью Process Monitor. Затем открыл представление дерева процессов программы, чтобы найти процессы, вовлеченные в предпринятую попытку установки, и идентифицировал Msiexec.exe (Windows Installer) и насколько запускающих процессов. Также я увидел, что Setup.exe запустил Wermgr.exe (Windows Error Reporting Manager), вероятно, для отправки в Microsoft отчета об ошибке:

Я переключил свое внимание назад к результатам трассировки и настроил фильтр так, чтобы исключить всё, кроме этих интересных процессов. Затем я начал трудоемкую работу прохождения по десяткам тысяч операций, надеясь найти иголку в стоге сена, объясняющую, почему установка подавилась ошибкой 0x80070643.

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

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

Через несколько минут я решил, что необходимо вернуться в журнале трассировки туда, где произошла ошибка, поэтому я перешел в дерево, выбрал Wermgr.exe и щелкнул «Go to event» (Перейти к событию):

Эта запись располагалась сразу после того, как setup встретил роковое условие. Затем я пролистал в журнале на несколько страниц вверх, ища следы. После нескольких минут поиска я обнаружил шаблон, встречающийся почти во всех операциях выше данной точки: Setup.exe пересчитывает все приложения, установленные системой. Я определил, что в реестре есть множество связанных с установками мест и смог определить имена приложений, найденные в колонке Details для некоторых из них. Например, здесь находится одна из OEM-программ, представляющая собой другой файл справки, выполненный как приложение, который я не догадался ранее удалить:

Теперь я мог быстро пробежаться по журналу, ища имена приложений. Минуту спустя я резко остановился, обнаружив то, чего я не должен был видеть – Microsoft Security Essentials:

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

Почему здесь были следы MSE, если она не была установлена, и фактически не устанавливалась? Я не был уверен, но после размышлений в течение нескольких минут, я пришел к заключению, что ПО, которое моя мам использовала для переноса файлов и настроек с ее старой системы, скопировало части установки MSE, которая находилась в старой системе. Вероятно, она использовала какую-то OEM-утилиту, размещенную на ПК, хотя я рекомендую использовать для этого Windows Easy Transfer. Но на самом деле причина не имела значения в тот момент, нужно было просто успешно установить MSE, и я считал, что нашел неисправность. Я удалил все эти разделы реестра, перезапустил Setup и … столкнулся с той же ошибкой.

Не готовый сдаться, я сделал еще одну трассировку установки. Подозревая, что setup прерывается на других фрагментах фантомной установки, я поискал «security essentials» в новом журнале трассировки и нашел еще ссылку до момента его падения. Чтобы избежать многократного повторения этой процедуры, я зашел в реестр и выполнил тот же поиск, уничтожив пару дюжин других разделов, в которых имелось упоминание о «security essentials».

Я затаил дыхание и снова запустил установщик, но с тем же результатом:

Код ошибки был другой, так что очевидно я несколько продвинулся, но поиск в Интернете по-прежнему не давал никаких зацепок. Я сделал еще одну трассировку и начал двигаться по операциям. Установка проделала свой финт с перечислением установленных приложений, сгенерировав десятки тысяч операций. Я просматривал журнал назад от места запуска Wermgr.exe, но быстро утомился. Я по-прежнему не мог заметить, что стало причиной неудачи, и не мог предположить, как это должно выглядеть в трассировке. Мой шурин был настроен скептически, но я сказал ему, что не сдамся. Я был мотивирован проблемой, и тем фактом, что не мог позволить ему рассказать своим сотрудникам, о том, что он наблюдал мой провал.

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

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

Наконец, спустя примерно 10 минут я нашел операцию, на которой были видны существенные различия: открытие раздела реестра HKCR\Installer\UpgradeCodes\11BB99F8B7FD53D4398442FBBAEF050F на проблемной машине возвращало в качестве результата значение SUCCESS:

В то время как на работающей результат был NAME NOT FOUND:

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

Есть, программа установки пыхтела несколько секунд и завершилась, поздравив меня с успешной интсалляцией:

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

Я сообщил об этом команде MSE и они работают над исправлением кодов ошибок и усовершенствованием программы установки, которое позволит ей стать более устойчивой к таким типам ошибок. Они также сообщили мне о дополнительных ресурсах на случай, если я столкнусь с подобными проблемами. Во-первых, это MscSupportTool.exe, извлекающий файлы журнала установки MSE, в которых может быть дополнительная информация. А также Microsoft ‘fix-it tool’, который исправляет некоторые проблемы установки.

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

Сообщение об ошибке из этого диалога переводится следующим образом: «Нельзя получить доступ к сервису Windows Installer. Это может быть из-за неверной установки Windows Installer. Для помощи свяжитесь с обслуживающим персоналом.»

Администратор, видевший одну из моих презентаций «Случай необъяснимого», где я советую: «когда не уверен, запускай Process Monitor», загрузил копию программы с сайта Sysinternals.com и зафиксировал процесс неудавшейся установки. Он следовал стандартным приемам поиска неисправности, двигаясь назад по журналу и ища операции, послужившие причиной сбоя, но после получасового анализа он отказался от такого занятия и переключился на другой подход. Вместо поиска зацепок в трассировке он решил, что проще найти проблему, сравнивая трассировку отказавшей системы с трассировкой, где установка клиента прошла успешно.

Спустя несколько минут у него была другая трассировка событий для пошагового сравнения. Он установил фильтр, включающий только события сгенерированные программой Msiexec.exe, программой установки клиента, и продолжил сравнение событий проблемной системы, сопоставляя их с соответствующими событиями работающей системы. В конечном счете, он определил точку расхождения трассировок. Обе трассировки ссылались на HKLM\System\CurrentControlSet\Services\BFE, но в проблемной трассировке после этого шел запрос к разделу реестра ComputerName:

С другой стороны, в трассировке работающей системы после этого продолжались операции с новым экземпляром Msiexec.exe, администратор заметил это потому, что ID процесса последующего процесса Msiexec.exe отличался от первоначального:

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

Он немедленно увидел, что в трассировке на рабочей системе было множество событий от процесса Svchost.exe, которых не было в проблемной системе. Предположив, что активность Svchost.exe не имеет отношения к делу, он добавил фильтр, чтобы исключить ее. Теперь трассировки снова были сопоставлены и включали события от Services.exe, совпадающие в обоих случаях:

Однако совпадающие операции не продолжались слишком долго. Всего дюжину или около того операций спустя, в трассировке проблемной системы обнаружилась ссылка на HKLM\System\CurrentControlSet\Services\Msiserver\ObjectName с ошибкой NAME NOT FOUND (имя не найдено):

В трассировке рабочей системы присутствовала та же операция, но с успешным результатом:

Действительно, кликнув правой клавишей мыши на пути и выбрав «Перейти к…» (jump to) из контекстного меню Process Monitor он убедился, что не только параметр ObjectName пропущен в разделе реестра Msiserver проблемной системы, но и весь раздел пуст. На рабочей системе он был заполнен параметрами, требующимися для настройки сервиса Windows:

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

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

Другие советы по использованию Process Monitor, а также дополнительные иллюстрации к случаям поиска неисправностей можно найти в книге «Windows Sysinternals Administrator’s Reference», которую я недавно опубликовал совместно с Аароном Марголисом. Если вы прочли ее, пожалуйста, оставьте ее обзор на Amazon.com.

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

Сигнатуры дисков

Сигнатура диска представляет собой четырехбайтовый идентификатор, расположенный по смещению 0x1B8 в главной загрузочной записи (MBR), записанной в первом секторе диска. Следующий снимок экрана дискового редактора показывает, что сигнатура диска на мой системе равна 0xE9EB3AA5 (величина записана в формате с порядком следования байтов начиная с младшего, поэтому байты идут в обратной последовательности – little-endian format):

Windows использует сигнатуры дисков внутри себя для отображения объектов, подобных томам, на физические диски. Начиная с Windows Vista, система хранит их в своей базе загрузочных конфигураций (Boot Configuration Database – BCD), в которой находится информация, используемая в процессе загрузки для нахождения загрузочных файлов и параметров загрузки. При изучении содержимого BCD с помощью встроенной утилиты Bcdedit, можно найти три места, связанные с сигнатурами дисков:

В действительности BCD имеет дополнительные ссылки на дисковые сигнатуры в альтернативных загрузочных конфигурациях, вроде Windows Recovery Environment, продолжение из режима hibernate и загрузка процесса диагностирования памяти, которые не показаны в основном выводе Bcdedit. Исправление коллизий требует небольшого знания структуры BCD, которая на самом деле является файлом куста (hive) реестра, который Windows загружает в HKEY_LOCAL_MACHINE\BCD00000:

Дисковые сигнатуры можно найти по смещению 0x38 в параметре реестра, называемом Element, в разделах 0x11000001 (загрузочное устройство Windows) и 0x2100001 (устройство загрузки OS):

Здесь показан элемент, соответствующий одной из записей вывода Bcdedit, где можно видеть ту же самую сигнатуру, которая хранится в MBR моего диска:

Коллизии сигнатур дисков

Windows требует чтобы сигнатуры были уникальными, поэтому когда вы подсоединяете диск с сигнатурой, совпадающей с сигнатурой одного из уже подключенных, Windows выводит этот диск в режим «offline» и не читает его таблицу разделов и не монтирует тома. Следующий снимок показывает, как административная утилита Windows Disk Management представляет отключенный диск, который я получил при подсоединении VHD, созданного с помощью программы Disk2vhd из моего системного диска, к этой же системе:

Если щелкнуть правой клавишей мыши на этом диске, утилита предложит перевести его в режим «Online», что заставит Windows проанализировать его таблицу разделов и смонтировать его тома:

Когда вы выберете пункт меню «Online», Windows без предупреждения сгенерирует новую случайную дисковую сигнатуру и присвоит ее диску, записав в MBR. После этого можно обработать MBR и смонтировать существующие тома, но когда Windows обновляет дисковую сигнатуру, запись BCD становится подвисшей, связанной с предыдущей сигнатурой, а не с новой. Загрузчик не сможет идентифицировать заданный диск и загрузочные файлы при загрузке с диска и выдаст следующую ошибку:

Восстановление сигнатуры диска

Одним способом восстановления дисковой сигнатуры является определение новой сигнатуры, которую Windows присвоила диску, загрузка BCD-куста диска и ручное редактирование всех параметров реестра, которые содержат старую сигнатуру диска. Однако это трудоемкий процесс, чреватый ошибками. Иногда можно использовать команды Bcdedit для задания элементам устройства новых сигнатур диска, но этот метод не работает с присоединенными VHD и потому ненадежен. К счастью есть более простой способ. Вместо обновления BCD можно вернуть диску исходную сигнатуру.

Сначала необходимо определить исходную сигнатуру, вот где нам пригодятся знания о BCD. Подключите к работающей системе Windows диск, который надо исправить. Он будет доступен и Windows присвоит буквы накопителей томам на диске, поскольку никакой коллизии сигнатур пока не будет. Загрузите BCD с диска, запустив Regedit, зайдя в HKEY_LOCAL_MACHINE и выбрав из меню File пункт Load Hive:

В диалоге File перейдите на диске в скрытый каталог \Boot, который расположен в корневом каталоге тома и выберите файл с именем «BCD». Если на диске расположены несколько томов, найдите каталог Boot, вводя «x:\boot\bcd», где вместо «x:» подставляется буква соответствующего тома на диске. Когда найдете BCD, выберите имя раздела, в который он загружается, и найдите «Windows Boot Manager». Вы найдете эту надпись в разделе с именем 12000004, как здесь:

Выберите раздел с именем 11000001 в том же самом родительском разделе Elements и запишите четырехбайтную сигнатуру диска, расположенную по смещению 0x38 (помните об обратном порядке байтов).

С сигнатурой диска в руках, откройте административное окно командной строки и запустите утилиту управления дисками из командной строки Diskpart. Введите «select disk 2», заменив «2» на ID диска, который утилита Disk Management показывает для диска. Теперь вы готовы к последнему шагу, возвращению сигнатуре диска своего исходного значения с помощью команды «uniqueid disk id=e9eb3aa5», подставив вместо ID то, что вы увидели в BCD:

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

Можно подробнее прочесть о Disk2vhd в книге Sysinternals Administrator’s Reference, написанной мною и Аароном Марголисом.

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

Поскольку он не мог получить доступа к сети, он не мог легко восстановить поврежденную установку MSE. Задавшись вопросом, могли ли инструменты Sysinternals ему помочь, он скопировал Process Explorer и Autoruns на USB-носитель, и затем скопировал их на ноутбук, который, по его убеждению, был заражен. Запустив Process Explorer, он увидел следующее дерево процессов:

В моей презентации на конференции Blackhat, «Zero Day Malware Cleaning with the Sysinternals Tools», я представил список характеристик, который обычно свойственны вредоносным процессам. Среди них отсутствие значка, названия компании или описания, расположение в директориях %Systemroot% или %Userprofile%, а также наличие сжатия или шифрования. Хотя есть класс вредоносного софта, у которого эти свойства отсутствуют, большинство вредоносных программ отвечают этому описанию. Этот случай – прекрасный пример такой программы. Process Explorer ищет подписи общеупотребимых инструментов сжатия исполняемых файлов, таких как UPX, а также эвристики, который содержат в себе метку Portable Executable, используемую системами сжатия, и выделяет найденные совпадения специальным цветом, установленным в настройках для подобных файлов (по умолчанию это цвет фуксии). Этим цветом выделилось около дюжины процессов. На снимке снизу видно, что у каждого такого процесса отсутствовало описание и название компании (хотя у некоторых из них были значки).

Названия многих из них либо совпадают, либо очень похожи на названия системных исполняемых файлов Windows. На скриншоте снизу выделен один такой процесс, название которого соответствует имени исполняемого файла Windows Svchost.exe, однако у него есть значок (позаимствованный у Adobe Flash) и он находится в нестандартной директории (C:\Windows\Update.1):

У другого процесса, чье имя хоть и не совпадало ни с одним из исполняемых файлов Windows (Svchostdriver.exe), но было весьма похоже на их имена, что могло ввести в заблуждение неопытных пользователей Windows, были открыты сокеты TCP/IP на прослушивание соединений:

Не осталось никаких сомнений в том, что компьютер серьезно заражен. Autoruns показал, что вредоносные процессы использовали несколько другие точки активации, что объясняло, почему даже безопасный режим с командной строкой не работал должным образом, поскольку поддельный исполняемый файл с именем Services32.exe (еще одно имя, подобное имени настоящего системного файла) зарегистрировался как Safe Mode AlternateShell (альтернативная оболочка безопасного режима), каковой по умолчанию является cmd.exe (командная строка):

В качестве моей первой рекомендации по очистке системы от вредоносного софта я советую запустить антивирусные утилиты, если это возможно. Подобное ПО могло бы удалить некоторые или даже все заражения, так почему бы этим не воспользоваться? Однако данная система не могла подключиться к Интернету, делая невозможным простое восстановление установки MSE или загрузку другого антивирусного приложения, такого как Microsoft Malicious Software Removal Tool (MSRT). Наш опытный пользователь видел, как я использовал Process Explorer на конференции для приостановки вредоносных процессов, поскольку в случае их завершения они могли перезапускать друг друга. Может быть, если бы он приостановил все процессы, которые выглядели подозрительно, то смог бы подключиться к сети и система не перезагрузилась бы? Стоило попытаться.

Щелкая правой кнопкой мышки на каждом вредоносном процессе, он выбирал Suspended из контекстного меню, чтобы приостановить его:

Когда он это сделал, дерево процессов стало выглядеть следующим образом (серым цветом выделены приостановленные процессы):

Теперь настало время посмотреть, сработал ли этот трюк: он подключился к беспроводной сети. Бинго, никаких перезагрузок! Теперь с подключением к Интернету он загрузил MSE, установил его и выполнил полное сканирование системы. Антивирусный движок заработал, выдавая сообщения об обнаруженных заражениях. Когда сканирование закончилось, он обнаружил четыре разных вредоносных программы: Trojan:Win32/Teniel, Backdoor:Win32/Bafruz.C, Trojan:Win32/Malex.gen!E, и Trojan:Win32/Sisron:

После перезагрузки, которая прошла заметно быстрее, чем прежде, он без проблем подключился к сети. В качестве заключительной проверки он запустил Process Explorer, чтобы посмотреть, остались ли какие-либо вредоносные процессы. К его облегчению, дерево процессов выглядело чистым:

Еще один случай разрешен с помощью утилит Sysinternals! Новое издание Windows Sysinternals Administrator’s Reference за авторством Аарона Маргозиса (Aaron Margosis) и моим собственным подробно описывает все утилиты и их функции, предоставляя вам инструменты и приемы для решения проблем, связанных с низкой производительностью, непонятными сообщениями об ошибках и сбоями приложений. И если вы интересуетесь кибербезопасностью, обратите внимание на мой технотриллер Zero Day.

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

Когда у меня появляется свободное время, я иногда играю в компьютерные игры, чтобы расслабиться и отвлечься от повседневных забот. На протяжении последних нескольких лет моей любимой игрой является Portal. Мне так понравилась первая Portal, что я сделал предзаказ на Portal 2 в сети Steam как только это стало возможно, и уже через несколько часов после выпуска я играл в нее. С тех пор я играю на сделанных сторонними разработчиками картах. В прошлую субботу я открыл особенно забавную карту – победителя конкурса игровых карт, проводившегося в сообществе пользователей игры – однако я не смог пройти ее за один раз. Следующим утром я вернулся к своему ПК, дважды кликнул на иконке Portal 2 на рабочем столе и увидел стандартное диалоговое окно запуска игры Steam. Обычно игра запускается за несколько секунд, однако на этот раз диалоговое окно так и осталось на экране:

Я завершил процесс Steam и еще раз дважды щелкнул по иконке игры, однако диалоговое окно запуска игры опять зависло. Я записал трассировку активности из Process Monitor и посмотрел на стек потоков Steam в Process Explorer, но не увидел ничего необычного. Предположив, что конфигурационные или установочные файлы Portal 2 были повреждены, я удалил Portal 2, повторно загрузил ее и переустановил. Однако проблема осталась. Следовательно, причиной были либо Steam, либо какая-то общая ошибка Windows. Следующим шагом была переустановка Steam.

Сначала я зашел в диалоговое окно «Установка и удаление программ» из «Панели управления», однако дважды щелкнув на записи Steam, я увидел диалоговое окно, просящее подтвердить удаление и предупреждающее, что при этом также удалится весь локальный контент. Я не хотел теряться все мои игровые настройки или все мои установленные игры, так что я отменил удаление. Большинство MSI-установщиков имеют опцию восстановления, которая повторно устанавливает приложение без удаления пользовательских данных или настроек, так что я зашел на домашнюю страничку Steam, скачал и запустил установщик Steam. Мастер установки предложил мне опцию восстановления:

Нажав кнопку Next, я увидел сообщение, которое сообщало о сетевой ошибке при попытке чтения локального файла:

Я снова включил Process Monitor и записал активность системы во время неудачной операции восстановления. В сообщении об ошибке упоминался файл под названием SteamInstall[1].msi, так что я искал в файле журнала строку с этим именем. Первым совпадением было чтение данных в запросе к значению ключа реестра HKCR\Installer\Products с именем PackageName:

Далее через несколько операций установщик попытался произвести чтение из папки файла, упоминавшегося в сообщении об ошибке:

То, что установщик пытался прочитать имя файла из существующего ключа реестра и расположение этого файла было в кэше Internet Explorer, навело меня на мысль, что он пытался запустить свою копию, которая выполнила начальную установку. Поскольку в первый раз я запускал установщик через IE напрямую с сайта Valve, и точно также я сделал и сейчас, папка загрузки была в кэше загрузки IE, однако с тех пор файл уже должен был быть удален.

Трассировка активности Process Monitor показала, что установщик считывал оригинальное значение расположения файла из реестра, так что если бы указал в реестре новую папку загрузки, я мог заставить его запускать самого себя, вместо того, чтобы искать предыдущую копию, которая сейчас отсутствует. Я просмотрел файл журнала на наличие новой папки для загрузки, ища Steaminstall.msi и путь к нему:

Затем я вернулся к записи запроса реестра, щелкнул по ней правой кнопкой мыши, и выбрал из контекстного меню команду «Jump To». Process Monitor запустил Regedit и перешел непосредственно к ключу реестра, где я обновил значения LastUsedSource и PackageName, чтобы обозначить новую папку для загрузки:

Затем я проигнорировал сообщение об ошибке установщика, которое я ранее оставил открытым, и нажал кнопку Next, чтобы снова попробовать запустить восстановление. На этот раз Steam продолжил переустановку, и мастер завершился с сообщение об успешном восстановлении:

Скрестив пальцы, я запустил Portal 2. Диалоговое окно Steam «Preparing to Launch» на секунду появилось, после чего на экран вышла игровая заставка Portal 2: дело закрыто. Удаление и последующая повторная установка Steam и всех игр, вероятно, привели бы к тому же результату, но Process Monitor сэкономил мне много времени и, возможно, мои игровые сохранения и настройки. Всего за несколько минут я вернулся к своей любимой игре-головоломке.

Обратите внимание на новую книгу Windows Sysinternals Administrator’s Reference, написанную мной и Аароном Маргозисом (Aaron Margosis), в которой вы найдете другие рекомендации по использованию более чем 70-ти инструментов Sysinternals для задач диагностики и управления вашими системами Windows!

Файлы PNF

Моим первым шагом в поиске подсказок, указывающих на предназначение файлов PNF, было определения размеров этих файлов. Небольшие файлы, вероятно, были бы данными, а побольше – кодом. Ниже перечислены размеры файлов PNF, которые я определил с помощью Explorer:

MDMERIC3.PNF 90

MDMCPQ3.PNF 4,943

OEM7A.PNF 498,176

OEM6C.PNF 323,848

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

Я подумал, что посмотрев на способ, которым Stuxnet ссылается на PNF-файлы, я смог бы понять, для чего они используются. Чтобы получить более полное представление об их назначении, я записал загрузочный журнал Process Monitor перезагруженной системы после заражения. Протоколирование загрузки, которое можо включить с помощью опции Enable Boot Logging в меню Options, указывает Process Monitor фиксировать системную активность с самых ранних моментов при следующей перезагрузке и заканчивать запись либо при следующем запуске Process Monitor, либо при выключении системы:

После записи загрузочного журнала, включающего себя повторный вход в систему, я загрузил его в одном окне Process Monitor, и первоначальную трассировку процесса заражения – во втором. Затем я сбросил фильтры в обеих трассировках, удалил дополнительный фильтр, который исключал активность процесса System, и добавил включающий фильтр для Mdmeric3.pnf, чтобы увидеть всю активность, связанную с первым файлом. Трассировка заражения включала в себя события, связанные с созданием этого файла, и ничего более, и этот файл вообще не упоминался в загрузочном журнале. Казалось, что Stuxnet не использовал этот файл во время начального заражения или последующей активации. Небольшой размер файла – 90 байт – указывает на то, что это данные, но я не мог определить его назначение на основании тех немногих фактов, которые я увидел в журнале. Фактически, этот файл мог вообще не служить какой-либо полезной цели, так как ни в одном опубликованном отчете о Stuxnet ничего не говорилось об этом файле, кроме того, что это файл с данными.

Далее я проделал все те же операции для Mdmcpq3.pnf. В журнале заражения я увидел, что процесс Services.exe трижды во время заражения производил запись в этот файл, однако позже к нему никто не обращался. В трассировке загрузки я увидел, что процесс Services.exe производил чтение этого файла сразу после старта:

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

Третий файл, Oem7a.pnf, был самым большим. В моей предыдущей статье во время анализа журнала заражения я заметил, что после того, как фальшивый Lsass.exe создал этот файл во время процесса заражения, другой экземпляр Lsass.exe полностью считывал его, так же как и зараженный процесс Services.exe. Исследование загрузочного журнала показало, что Services.exe полностью считывает этот файл после старта:

Странно то, что эти операции чтения были первым, что сделал Services.exe, даже раньше загрузки системной библиотеки Ntdll.dll. Эта библиотека загружается раньше любого исполнительного файла пользовательского режима, так что за любую активность до этого момента должен отвечать код режима ядра. Стек показывает, что фактически они были инициированы Mrxcls.sys, одним из драйверов Stuxnet, из режима ядра:

Стек показывает, что Mrxcls.sys был вызван функцией ядра PsCallImageNotifyRoutines. Это означает, что Windows будет вызывать его каждый раз, когда исполняемый образ, такой как DLL или драйвер устройства, отображается в память. Здесь Windows регистрирует драйвер, который был загружен в память файлом образа Services.exe, для запуска Services.exe. Stuxnet явно регистрируется в обратном вызове, так что он может наблюдать за запуском Services.exe. Ирония здесь в том, что Process Monitor также использует этот функционал обратных вызовов для мониторинга загрузки образов.

Отсюда следует, что Mrxcls.sys – это драйвер, который запускает заражение процессов пользовательского режима при загрузках системы после ее первоначального заражения. Размер этого файла – 498,176 байт (487 Кб) – почти точно соответствует размеру области в виртуальной памяти, 488 Кб, из которой, как мы видели в первой части серии статей, запускались операции Stuxnet. Эта область содержала действительную DLL, так что похоже, что Oem7a.pnf – это зашифрованная дисковая форма главной DLL-библиотеки Stuxnet, и эту гипотезу подтверждают исследователи вирусного ПО.

Последний файл, Oem6c.pnf, вообще отсутствует в загрузочном журнале. Единственными обращениями к нему в трассировке заражения являются операции записи из начального процесса Lsass.exe, который также производит запись в другие файлы. Таким образом, этот файл был создан во время начального заражения, но никогда не считывался. Есть несколько возможных объяснений такому поведению. Первое – этот файл может быть считан при возникновении определенных обстоятельств, которые я не воспроизвел в своей тестовой среде. Второе – это файл журнала, в который записывается информации о заражении для последующего анализа разработчиками Stuxnet. Это невозможно подтвердить, основываясь на данных трассировки, однако исследователи вредоносного ПО полагают, что это файл журнала.

Повышение прав в Windows 7

Многие операции, выполненные Stuxnet, включая заражение системных процессов, таких как Services.exe, и установку драйверов устройств, требуют административных прав. Если бы Stuxnet не мог заражать системы, пользователи которых не обладали этими правами, его возможности к распространению были бы сильно ограничены, особенно это касается чувствительных сетей, на которые он прежде всего был нацелен, где большинство пользователей обладали стандартными правами. Чтобы получить административные права из стандартных учетных записей пользователей, Stuxnet использовал две уязвимости нулевого дня.

В Windows XP и Windows 2000 вирус Stuxnet использовал ошибку, связанную с проверкой индекса в Win32k.sys, которая могла быть вызвана специально настроенными файлами раскладок клавиатуры (исправлена в MS10-073). Эта ошибка позволяла Stuxnet внедрить код в режиме ядра и работать с привилегиями ядра. На Windows Vista и более поздних системах Stuxnet использовал ошибку в защите доступа к файлам запланированных задач, что позволило ему получить административные права (исправлено в MS10-92). Стандартные пользователи могут создавать запланированные задачи, но эти задачи могут работать только с теми же привилегиями, что и пользователь, создавший их. Прежде, чем эта ошибка была исправлена, Windows создавала файл, сохраняющий задачу с разрешением, позволяющим стандартному пользователю изменять этот файл. Stuxnet использовал эту узявимость в своих целях, создавая новую задачу и устанавливая в результирующем файле задачи флаг, указывающий на то, что задача должна запускаться под учетной записью System, которая имеет полные административные права.

Чтобы понаблюдать, как Stuxnet использует ошибки в Windows 7, я для начала удалил связанное с этой ошибкой обновление на тестовой системе, и понаблюдал за процессом заражения Stuxnet через Process Monitor. После того, как журнал был получен, я проделал те же самые шаги, которые описывал в последней статье, т.е. установку фильтра, которые скрывал все операции за исключением изменяющих файлы и ключи реестра (“Category Is Write”), после чего я стал последовательно исключать ненужные события. Когда я закончил, окно Process Monitor стало выглядеть так:

Первые события были связаны с тем, что Stuxnet копировал временные файлы, которые он ранее скопировал в PNF-файлы, в папку C:\Windows\Inf. Они сопровождались событиями Svchost.exe, которые напрямую связаны со службой планировщика задач. Процесс Scvhost.exe создает новый файл запланированной задачи в папке C:\Windows\System32\Tasks и затем устанавливает несколько связанных значений реестра. Стеки этих событий показывают, что Schedsvc.dll – библиотека, которая реализует службу планировщика задач – ответственна за эти действия:

Несколько операций спустя Explorer записал некоторые данные в новый файл задачи:

Эта операция должна быть невыполнима, поскольку стандартная учетная запись пользователя не должна иметь возможность управлять системным файлом. В последней статье мы видели, что кадры <unknown> в стеке операции указывают на работу Stuxnet:

Последние операции в трассировке, связанные с файлом задачи, показывают, что планировщик задач удаляет данный файл, таким образом, очевидно, что Stuxnet изменяет задачу, запускает ее, а затем удаляет:

Чтобы удостовериться в том, что планировщик задач действительно запускает данную задачу, я удалил фильтр на запись и применил другой фильтр, который включает только ссылки на наш файл задачи. После этого в окне Process Monitor появилось событие, показывающее, что Svchost.exe считывает этот файл после того, как Stuxnet произвел запись в него:

В качестве окончательного подтверждения, я посмотрел на стек операции и увидел функцию планировщика задач SchRpcEnableTask, чье название указывает на то, что она предназначена для активации задачи:

Stuxnet раскрыт с помощью инструментов Sysinternals

В этой заключительной части моего расследования Stuxnet мне удалось использовать функцию Process Monitor по протоколированию загрузки системы, чтобы найти подсказки, указывающие цель различных файлов Stuxnet, которые он размещает в системе во время заражения. Process Monitor также раскрыл способ, которым Stuxnet использовал уязвимость в службе планировщика задач в Windows 7, чтобы открыть для себя административные права.

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