Файл: Руссинович М., Маргозис А. Утилиты Sysinternals. Справочник администратора 2012.pdf

Вредоносные программы 

Глава 18  433 

Определив, что «лишний» экземпляр Csrss.exe находился в %windir% и 

не прошел проверку подписи, Грег запустил утилиту Strings, чтобы понять, 
что это за файл (рис. 18-9). Проверка выявила несколько признаков вредо-
носной программы, включая код для создания файла Autorun.inf, копирую-
щегося на съемные диски и запускающего вирус при вставке диска с этим 
Autorun.inf в другой компьютер, а также перечисление компьютеров и об-
щих папок и копирование вируса в эти папки с обманчивыми именами и 
расширениями.

Рис. 18-9.  Выявление вредоносного ПО в поддельном файле Csrss.exe при помощи Strings

С помощью Stings Грег также обнаруживал файлы вредоносных программ 

по сигнатуре «UPX0» (свидетельствующей о сжатии файла) и «кустарным» 
путям к PDB-файлам символов вроде «d:\hack.86» и «c:\mystuff».

Убедившись, что этот поддельный компонент Windows действительно 

был вредоносной программой, Грег и его команда стали работать с Центром 
защиты от вредоносного ПО, чтобы документировать поведение этого виру-
са и выработать решение для защиты от него.

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

Грегу поручили дело клиента, представляющего крупную сеть больниц в 
США, в котором сообщалось об атаке и заражении вирусом Marioforever. 
Клиент обнаружил вирус, когда его принтеры стали печатать гигантские 
объемы случайного текста, что приводило к замедлению сети и большому 
расходу бумаги. Антивирусное ПО определило файл Marioforever.exe в пап-
ке %Systemroot% одного из компьютеров, как подозрительный, но после 

SIN_ch_18.indd   433

27.12.2011   14:42:27

434  Часть 

III   

Поиск и устранение сбоев: загадочные случаи

удаления при следующей перезагрузке этот файл появлялся снова. Другие 
антивирусные программы вообще не обращали на этот файл внимания.

Грег начал с поиска других подозрительных файлов в папке %SystemRoot% 

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

C:\>listdlls -d nvrsma.dll

ListDLLs v2.25 - DLL lister for Win9x/NT 
Copyright (C) 1997-2004 Mark Russinovich 
Sysinternals - www.sysinternals.com

-----------------------------------------------------------------
winlogon.exe pid:   416 
Command line:  winlogon.exe

Base          Size      Version     Path
0x10000000    0x34000               C:\WINDOWS\system32\nvrsma.dll

Winlogon — основной системный процесс, отвечающий за управление 

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

Winlogon запускается в ходе загрузки, поэтому Грег включил в Procmon 

функцию записи информации о загрузке, перезагрузил систему, запустил 
Procmon и загрузил полученный журнал. Затем он нажал Ctrl+F и выпол-
нил поиск текста «nvrsma». На рис. 18-10 показано, что он нашел: первая 
ссылка встречалась, когда Winlogon.exe запрашивал значение раздела рее-
стра HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Windows\
dzplnit_DLLs, которое возвращало текстовое значение «nvrsma». Несколько 
событий спустя Winlogon.exe открывал и проецировал nvrsma.dll в память.

После этого Грег просмотрел стек вызовов для этого первого события реест-

ра. Как видно на рис. 18-11, чтение реестра инициировано библиотекой User32.
dll. Грег знал, что имя «dzpInit_DLLs» очень похоже на хорошо известную и ши-

SIN_ch_18.indd   434

27.12.2011   14:42:28

Вредоносные программы 

Глава 18  435 

роко используемую вредоносными программами точку ASEP «AppInit_DLLs», 
определенную в том же разделе реестра и также инициируемую из User32.dll

2

. 

Но эта библиотека была не оттуда. Была ли dzpInit_DLLs новой точкой ASEP, 
о которой ни Грег, ни автор Autoruns никогда не слышали?

Рис. 18-10.  Procmon показывает, почему Winlogon.exe загрузил nvrsma.dll

Рис. 18-11.  Стек вызовов, показывающий событие реестра, инициированное User32.dll

Теперь Грег обратил внимание на User32.dll. Он заметил, что на инфици-

рованных системах дата последнего изменения User32.dll в папках System32 
и DllCache совпадала с датой первого заражения. Внимательнее просмотрев 
данные в Autoruns, он увидел, что подпись библиотеки User32.dll не про-
шла проверку (рис. 18-12), а значит, библиотека изменена или полностью 
заменена.

2

 Когда процесс в Windows XP и предыдущих версиях ОС запускает User32.dll, он также 

загружает все библиотеки DLL, указанные в значении реестра AppInit_DLLs. В Autoruns эти DLL 
показаны на вкладке AppInit.

SIN_ch_18.indd   435

27.12.2011   14:42:28

436  Часть 

III   

Поиск и устранение сбоев: загадочные случаи

Грег запустил Procexp в нормально работающей системе Windows XP и 

в инфицированной. В обеих он выбрал процесс Winlogon.exe, открыл пред-
ставление DLL, дважды щелкнул на имени User32.dll в нижней части окна, 
чтобы открыть диалоговое окно свойств, перешел на вкладку Strings и срав-
нил текст, показанный в двух системах. Совпадало все, кроме одного: на ин-
фицированной системе точка запуска AppInit_DLLs была заменена точкой 
dzpInit_DLLs (рис. 18-13). Сравнив двоичный код нормального и инфици-
рованного файлов User32.dll при помощи команды Windows 

fc /b

, Грег 

обнаружил, что эти два байта были единственным различием между двумя 
файлами. Вредоносная программа создала собственную точку ASEP, изме-
нив два байта в User32.dll, чтобы загружать DLL, заданные параметром рее-
стра dzpInit_DLLs, а не AppInit_DLLs.

Рис. 18-12.  Библиотека User32 не прошла проверку подписей в Autoruns

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

SIN_ch_18.indd   436

27.12.2011   14:42:29

Вредоносные программы 

Глава 18  437 

Зная, как именно активируется основная DLL вредоносной программы, 

Грег смог очистить систему. Поскольку библиотека User32.dll всегда блоки-
руется вредоносной программой во время работы системы, он загрузил сре-
ду WinPE с компакт-диска и скопировал оттуда нормальный файл User32.
dll, переписав инфицированный. Затем он удалил остальные вредоносные 
файлы, которые обнаружил во время поисков. После этого он перезагрузил 
систему и убедился, что она очищена. Дело было закрыто, администрато-
ры больничной сети получили инструкции по удалению вредоносного ПО, 
а антивирусная группа Microsoft — материал для добавления в Forefront и 
Malicious Software Removal Toolkit. Так Грег распутал загадочное на первый 
взгляд дело, используя несколько утилит Sysinternals, и помог восстановить 
нормальную работу больниц.

SIN_ch_18.indd   437

27.12.2011   14:42:29