Дело о вредоносном автозапуске

Учитывая то, что мой роман, Zero Day, будет опубликован через несколько недель и основой повествования в нем является использование вредоносного ПО террористами в качестве оружия, я решил опубликовать статью, которая рассказывает о борьбе с вредоносным ПО средставами утилит Sysinternals. Этот случай начался с того, что в службу поддержки Microsoft поступил звонок от клиента, работающего в сети большой больницы США, который сообщил о том, что они подверглись атаке вируса Marioforever. Они обнаружили этот вирус, когда их принтеры стали печатать огромные объемы ненужного текста, замедляя работу сети и расходуя бумагу. Их антивирусное программное обеспечение обнаружило на одной из машин файл с именем Marioforever.exe в папке %SystemRoot%, который отсылал файлы на печать, однако удаление этого файла не дало результата – после перезагрузки он появлялся вновь. Другие антивирусные программы вообще не смогли обнаружить этот файл.

Инженер поддержки Microsoft взялся исследовать этот случай, начав с поиска других подозрительных файлов в папке %SystemRoot% одной из зараженных систем. Один из файлов, Nvrsma.dll, недавно открывался и, хотя он имел такое же имя, как компонент драйвера видеокарты Nvidia, в рассматриваемом компьютере не было установлено адаптера этой фирмы. Когда он попытался удалить или переименовать файл, он столкнулся с ошибкой совместного доступа, что означало, что некоторый процесс открыл этот файл и препятствовал его открытию другими процессами. У Sysinternals есть несколько инструментов, которые могут перечислить процессы, у которых есть открытые файлы или загруженные библиотеки DLL, в том числе Process Explorer и Handle. Тем не менее, поскольку речь шла о файле DLL, инженер выбрал утилиту Sysinternals Listdlls, которая показала, что данный DLL был загружен одним процессом, Winlogon:

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

Если бы он смог понаблюдать за запуском Winlogon с помощью утилиты для работы с файловой системой и реестром, такой как Process Monitor, он смог бы определить причину, почему Winlogon загружает Nvrsma.dll. Winlogon запускается во время процесса загрузки, так что ему нужно было использовать функцию Process Monitor, которая ведет журнал загрузки системы. Когда вы настраиваете Process Monitor для ведения журнала активности процесса загрузки, он устанавливает свой драйвер так, чтобы он загружался в самом начале и осуществлял мониторинг, записывая активность системы в файл с именем %SystemRoot%\Procmon.pmb. Драйвер прекращает запись в этот файл либо после того, как кто-то запустит утилиту Process Monitor, либо после выключения системы.

После настройки Process Monitor для регистрации загрузочной активности и перезагрузки системы инженер запустил Process Monitor и открыл журнал загрузки. Он выполнил поиск строки “nvrsma” и нашел этот запрос Winlogon ключа реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\bwpInit_DLLs, который возвращал строку “nvrsma”:

Инженер никогда раньше не видел ключ bwpInit_DLLs, но его название было поразительно похоже на точку входа автозапуска, которая была ему известная – AppInit_DLLs. Значение AppInit_DLLs считывает главная библиотека для управления окнами, User32.dll, при загрузке процесса. User32.dll загружает любые DLL, на которые ссылается этот ключ, так что любой процесс Windows, у которого есть графический пользовательский интерфейс (в противоположность интерфейсу с командной строкой, загружает DLL, записанные в этом ключе. Ниже по списку операций он увидел, как Winlogon загрузил Nvrsma.dll:

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

В журнале загрузки не было никакой ссылки на AppInit_DLLs, что очевидно указывало на то, что вредоносный код каким-то образом принудил User32.dll запрашивать альтернативное расположение. Это также объясняло, почему эта запись не отображалась в Autoruns. Он задался вопросом, почему ни один другой процесс не загружал Nvrsma.dll, однако ниже в журнале он увидел, что попытка загрузить эту DLL другим процессом привела к той же ошибке совместного доступа, с которой столкнулся он:

Простая загрузка DLL не заставит обработчик остаться открытым и не вызовет такой тип ошибки, так что он стал искать другие операции CreateFile в этой DLL, которым не соответствовали операции CloseFile. Последняя такая операция перед возникновением ошибки совместного доступа была выполнена Winlogon:

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

Теперь он должен был определить, как была атакована User32.dll. User32.dll – одна из доверенных системных DLL. Это означает, что поскольку для оптимизации производительности Windows во время загрузки создается отображение файлов, которое может использоваться любым процессом, который загружает DLL. Эти доверенные DLL перечислены в ключе реестра, который Autoruns вывод во вкладке KnownDLLs, так что инженер вернулся к Autoruns, чтобы более внимательно просмотреть результаты сканирования. Самый эффективный способ определить потенциальное вредоносное ПО с помощью Autoruns – запустить его с набором опций Verify Code Signatures, с помощью которых Autoruns проверяет цифровые подписи образов, которые он находит. После более пристального просмотра инженер обратил внимание на то, что User32.dll, в отличие от остальных доверенных DLL, не имел достоверной цифровой подписи:

Поддельный User32.dll вел себя практически идентично настоящему User32.dll, иначе бы приложения с графическим пользовательским интерфейсом завершались бы с ошибкой, однако он запрашивал альтернативное значение в системном реестре. Чтобы проверить это, инженер запустил утилиту Sysinternals Sigcheck на измененной копии и на одной из незараженных систем, на которой работал тот же выпуск Windows. Сравнение результатов запуска утилиты, включающих в себя хэши MD5, SHA-1 и SHA-256 файла, подтвердило, что они различались:

В качестве финальной проверки того, эти отличия были ответственны за различия в поведении файлов, инженер решил просмотреть код DLL. Любые ключи реестра и их значения, так же как и имена файлов, используемые исполняемым файлом, сохраняются в файле образа исполняемого файла и видны из утилиты для сканирования строк кода. Он попытался использовать утилиту Sysinsternals Strings, но ошибка совместного доступа не дала Strings открыть измененный User32.dll, так что он обратился к Process Explorer. Когда вы открываете просмотр DLL для процесса и открываете свойства этой DLL, Process Explorer показывает печатные строки во вкладке Strings. Результат, который показал измененную строку APPInit_DLLs, подтвердил правильность этой теории:

Зная то, как активируются первичные DLL вредоносного кода, он принялся за очистку от них целевой системы. Поскольку User32.dll блокировался вредоносным ПО всякий раз при запуске Windows (иначе вы могли бы переименовать файл и заменить его, что и сделала вредоносная программа в данном случае), он загрузил Windows Preinstallation Environment (WinPE) с CD и оттуда скопировал чистый User32.dll поверх вредоносной версии. Затем он удалил связанные с вирусной программой файлы, которые обнаружил во время своего исследования. После этого он перезагрузил систему и проверил, очистилась ли она от вируса. Он закрыл это случай, дав администраторам сети больницы подробное описание шагов по очистке системы, которые он проделал и предоставил данное вредоносное ПО в команду Microsoft, занимающуюся решением проблем безопасности, чтобы они могли включить автоматический процесс очистки системы в Forefront и Malicious Software Removal Toolkit. Он нашел решение, казалось бы, неразрешимой задачи, используя несколько утилит Sysinternals, и помог больнице вернуться к нормальному режиму работы.

Comments

• Anonymous
  December 27, 2013
  Pingback from ???????? ?? ?????????????????????? ?????????????????????? | UC3