Случай Таинственного ASEP

Грег был присвоен случай от клиента, представляющего большую сеть больницы US, которая сообщила, что это было поражено инвазией вируса Marioforever. Клиент ­обнаружил вирус, когда его принтеры начинали получать barraged с гигантскими заданиями печати текста мусора, заставляя его сеть замедлиться и принтеры, чтобы исчерпать бумагу. Их антивирусное программное обеспечение, идентифицированное файл под названием Marioforever.exe в %SystemRoot папке % одной из машин, извергающих файлы к принтерам как подозрительный, но удаляющих файл только, привело к этому вновь появляющийся в последующей перезагрузке. Другие антивирусные программы, отказавшие, чтобы отметить файл вообще.

Грег начинал искать подсказки, видя, были ли дополнительные подозрительные файлы в %SystemRoot каталоге % одной из зараженных систем. У одного файла, DLL под названием Nvrsma.dll, был штамп настоящего времени, и хотя это назвали так же к ­компонентам драйвера дисплея Nvidia­, у рассматриваемого компьютера не было адаптера дисплея Nvidia. Когда он попытался удалить или переименовать файл, он получил ошибку нарушения совместного использования, которая означала, что некоторый процесс имел открытый файл и препятствовал тому, чтобы другие открыли его. Есть несколько инструментов Sysinternals, которые перечислят процессы, у которых есть открытый файл или загруженный DLL, включая Проводник Процесса и Дескриптор. Поскольку файл был DLL, тем не менее, Грег, решенный об утилите Sysinternals Listdlls, которая показала, что DLL был загружен одним процессом, Winlogon.

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

Winlogon запускается во время процесса загрузки, таким образом, Грег регистрирующая начальную загрузку опция активированного Прокмона, перезагрузила систему, выполнила Procmon, и загрузила журнал начальной загрузки. Он тогда нажал Ctrl+F и искал "nvrsma". Рисунок 18-10 показывает то, что он нашел: первая ссылка произошла, когда Winlogon.exe запросил HKLM\SOFTWARE\Microsoft\Windows значения реестра NT\CurrentVersion\Windows\dzpInit_DLLs, который возвратил текстовое значение "nvrsma". Несколько событий позже, Winlogon.exe открытый и затем отображенный nvrsma.dll в память.

Рис. 18-10. Procmon, показывающий, почему Winlogon.exe загруженный nvrsma.dll.

Грег, на которого тогда смотрят стек вызова для того первого события реестра. Как можно видеть в рисунке 18-11, чтение реестра очевидно инициировалось от User32.dll. Грег знал, что имя "dzpInit_DLLs" очень подобно тому из известных и широко злоупотребленных "AppInit_DLLs" ASEP определенный в том же самом регистрационном ключе и который также инициируется от User32.dll2. Но это не было AppInit_DLLs. Действительно ли dzpInit_DLLs был новым ASEP, о котором никогда не слышал Грег (и Автовыполнения)?

Рис. 18-11. Вызовите стек, показывая событие реестра, инициируемое в пределах User32.dll.

Грег, теперь обращенный его внимание к User32.dll. Он заметил, что на зараженных машинах, последним образом измененная дата User32.dll и в папках System32 и в DllCache была датой начальной инфекции. Бросая более близкий взгляд на результаты Автовыполнений, Грег нашел, что User32.dll приводил проверку подписи к сбою (показанный в рисунке 18-12) и был поэтому или изменен или полностью заменен.

Грег выполнял Procexp на известном - хорошая машина Windows XP и на зараженном. На обоих он выбрал Winlogon.exe процесс, открытое Представление DLL, по которому дважды щелкают User32.dll в более низкой области, чтобы открыть ее диалоговое окно Свойств, и щелкнул по вкладке Strings. Он тогда сравнил текстовые строки, найденные в каждом. Все кроме каждый был полностью тем же самым. ­Различие было то, что AppInit_DLLs в известном - хороший был заменен dzpInit_DLLs в измененном. (См. рисунок 18-13.) Выполнение двоичного сравнения пользы и плохой User32.dll файлы с командой Windows ФК/b, Грег нашел, что те два байта были единственными различиями между этими двумя файлами. Вредоносное программное обеспечение создало свой собственный ASEP, изменяясь на два байта в User32.dll так, чтобы оно загрузило DLL, перечисленные в dzpInit_DLLs значении реестра вместо в AppInit_DLLs.

² Когда процесс на Windows XP и более ранние загрузки User32.dll, это также загружает любые DLL, названные в значении реестра AppInit_DLLs. Автовыполнения перечисляют эти DLL на его вкладке Appinit.

 Рис. 18-12. Автовыполнения показывая User32, приводя проверку подписи к сбою.

Рис. 18-13. Сравнение текстовых строк в известном - хороший User32.dll (оставленный) и зараженный (право)

Со знанием точно, как основной DLL вредоносного программного обеспечения активировался, Грег, изложенный, чтобы убрать вредоносное программное обеспечение от системы. Поскольку User32.dll был бы заблокирован вредоносным программным обеспечением всякий раз, когда Windows был онлайновым, он загружал Windows Preinstallation Environment (WinPE) от CD-ROM и, оттуда, копировал чистое User32.dll по злонамеренной версии. Затем он удалил связанные файлы вредоносного программного обеспечения, которые он обнаружил в своем исследовании. Когда он был сделан, он перезагружал систему и проверял, что это было чисто. Он закрыл случай, давая администраторам сети больницы шаги очистки, он следовал и представил вредоносное программное обеспечение команде антивредоносного программного обеспечения Microsoft так, чтобы они могли включить автоматизированную очистку в Центр деятельности и Инструментарий Удаления Вредоносного программного обеспечения. Он решил на вид невозможный случай, применяя несколько утилит Sysinternals и помог больнице возвратиться к нормальному функционированию.

[1] Примечание. Для запуска утилит с сайта необходимо, чтобы служба WebClient работала. В более новых версиях Windows служба не запускается автоматически. Запуск службы непосредственно (например, выполняя сетевой запуск webclient) требует административных прав. Можно запустить службу косвенно без административных прав с использованием \\live.sysinternals.com