Анализируем вирус Stuxnet с помощью инструментов Sysinternals (часть 2)

В первой части я начал исследование известного червя Stuxnet с помощью инструментов Sysinternals. Я использовал Process Explorer, Autoruns и VMMap для осмотра системы после ее заражения. Autoruns быстро показал сердце Stuxnet, два драйвера устройств с именами Mrxcls.sys и Mrxnet.sys, и оказалось, что для отключения Stuxnet (и предотвращения повторного заражения) необходимо просто удалить эти драйверы и перезагрузить систему. С помощью Process Explorer и VMMap мы увидели внедренный код Stuxnet в различных системных процессах и новые созданные процессы, запускающие системные исполняемые файлы для своих целей. К концу первой статьи я продвинулся в исследовании вируса насколько это было возможно, основываясь на обзоре вируса в снимке системы. В этой статье я продолжу свое исследование, проанализировав журнал Process Monitor, который был записан во время заражения, чтобы получить более глубокое понимание влияния Stuxnet на заражаемую систему и того, как он работает (кстати, если вам нравятся эти публикации в блоге и книги Тома Клэнси (Tom Clancy) и Майкла Кричтона (Michael Crichton), то вам стоит обратить внимание на мой новый кибертриллер Zero Day).

Фильтрация для поиска нужных записей

Process Monitor зафиксировал около 30000 событий во время мониторинга заражения, что слишком много для поиска записей, указывающих на заражение. Большая часть этих событий относится к фоновой деятельности Windows и операциям перехода Explorer к новой папке, непосредственно не относящимся к заражению. Так как по умолчанию Process Monitor исключает дополнительные события (обращения к файлу подкачки, внутренние IRP-функции, процесс System и операции с метаданными NTFS), на что указывает строка состояния, в моем случае Process Explorer показывает более 10000 событий:

Ключ к тому, чтобы использоваться Process Monitor эффективно, когда вы не знаете, что ищите –сократить объем получаемых данных. Фильтры – мощное средство для достижения этой цели, и у Process Monitor есть фильтры, которые предназначены для таких сценариев использования. Мы используем фильтр, который исключает все события, кроме связанных с модификацией файлов или ключей реестра. Настроить этот фильтр (“Category is Write then Include”) можно с помощью диалогового окна Filter:

События, сгенерированные процессом System обычно не нужны для диагностики, но я знаю, что у Stuxnet есть компоненты, работающие в режиме ядра, так что для полноты охвата я должен включить события, исполняемые в контексте процесса System, который является процессом, где некоторые драйверы устройств исполняют системные потоки. Вы можете удалить фильтры по умолчанию, выбрав опцию Enable Advanced Output в меню Filter, но я не хотел удалять другие фильтры, выставленные по умолчанию, которые исключают события обращения к файлу подкачки и операциям с метаданными NTFS, так что я удалил только фильтр, исключающий System (второй в списке фильтров). Число событий уменьшилось до 600:

На следующем шаге следует исключить события, которые точно не связаны с заражением. Определение ненужных событий требует опыта, поскольку это связано со знанием типичной активности Windows. Например, первые несколько сотен событий были связаны установкой Explorer значений в ключе реестра HKCU\Software\Microsoft\Windows\ShellNoRoam\BagsMRU:

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

Поскольку я хочу исключить любые ссылки на подключи или значения этого ключа, я открыл только что созданный фильтр, дважды щелкнул на нем для запуска редактора фильтров и изменил параметр «is» на «begins with» (начинается с):

Это сократило число событий до 450, что гораздо удобнее, но я все еще видел много событий, которые можно исключить. Следующий блок событий относился к системному процессу чтения и записи файлов улья реестра. Файлы улья хранят данные системного реестра, однако нам интересны сами операции реестра, а не факты чтения и записи файлов улья. Исключения этих записей сократило их общее число до 350. Я продолжил просматривать журнал, добавляя дополнительные фильтры для исключения других посторонних событий. После того, как я отфильтровал все фоновые операции, диалоговое окно Filter стало выглядеть так (некоторые из фильтров, которые я добавил, не видны на снимке):

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

Модификации системы вирусом Stuxnet

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

Чтобы убедится, что эта операция записи действительно инициализирована Stuxnet, а не Explorer.exe, я дважды щелкнул на ней, чтобы открыть диалоговое окно Event Properties, и перешел на страницу Stack. Кадр стека сразу над NtWriteFile API показывает "<unknown>" в поле имени модуля, что указывает на то, что данный адрес стека не лежит ни в одной DLL, загруженной в процесс:

Если вы смотрите на стеки со сторонним кодом, вы также можете увидеть записи <unknown>, когда код не использует стандартные правила вызовов, поскольку это вступает в противоречие с алгоритмом API трассировки стека, который использует Process Monitor. Однако когда я взглянул на адресное пространство Explorer с помощью VMMap, я нашел область данных, содержащую неизвестный адрес стека 0x2FA24D5, который имеет разрешения на запись и выполнение – контрольный признак внедренного вирусного кода:

После этих действий Explorer.exe следуют операции создания процессом Lsass.exe четырех файлов ~Dfa.tmp, ~Dfb.tmp, ~Dfc.tmp и ~Dfd.tmp во временном каталоге учетной записи. Многие компоненты в Windows создают временные файлы, так что я должен был проверить, что они связаны со Stuxnet, а не со стандартной активностью Windows. Сильным доводом в пользу того, что за этим стоит Stuxnet, являлся тот факт, что ID (PID) этого процесса Lsass.exe, равный 300 – не совпадает с PID настоящего системного процесса Lsass.exe, который я обнаружил в первой части статьи. Фактически, этот PID не соответствовал ни одному из трех процессов Lsass.exe, которые были запущены после заражения, что подтверждает, что Lsass.exe является еще одним процессом, запущенным Stuxnet.

Чтобы увидеть, как этот процесс Lsass.exe взаимодействует с другими, я нажал Ctrl+T, чтобы открыть диалоговое окно дерева процессов Process Monitor (его также можно открыть из меню Tools). Дерево процессов показало, что три дополнительных процесса Lsass.exe выполнялись во время заражения, включая тот, у которого был PID 300. Серые записи этих процессов в дереве процессов указывают на то, что они завершились прежде, чем Process Monitor закончил трассировку событий:

Теперь я знал, что это был поддельный процесс Lsass.exe, но я должен был убедиться, что эти временные файлы не были созданы обычной активностью Lsass.exe. Я снова посмотрел на их стеки и увидел маркер модуля <unknown>, как и в случае со стеком операций Explorer.exe.

В следующем блоке записей все становится еще интереснее, поскольку мы видим, что Lsass.exe перемещает один из двух драйверов Stuxnet – MRxCls.sys – в папку C:\Windows\System32\Drivers и создает соответствующие ему ключи реестра:

Я дважды щелкнул на операции WriteFile, чтобы увидеть ее стек, и заметил, что вызов API CopyFileEx означает, что Stuxnet скопировал содержимое драйвера из другого файла:

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

Process Monitor отобразил ссылки на файл ~DFD.tmp, который был создан ранее, так что я знал, что этот файл содержал копию драйвера:

Несколькими процессами позднее процесс System загрузил Mrxcls.sys, активировав этот драйвер:

Далее Stuxnet подготавливает и загружает свой второй драйвер Mrxnet.sys. Трассировка показывает, что Stuxnet сначала записал драйвер в ~DFE.tmp, скопировал этот файл в файл назначения Mrxnet.sys, и указал значение реестра для Mrxnet.sys:

Несколько операций спустя процесс System загрузил этот драйвер так же, как и Mrxcls.sys.

Последние модификации, проделанные вирусом, включают в себя создание четырех дополнительных файлов в папке C:\Windows\Inf: Oem7a.pnf, Mdmeric3.pnf, Mdmcpq3.pnf и Oem6c.pnf. Операции создания этих файлов стали видны вместе, когда я поставил фильтр, который включает только операции CreateFile:

Файлы PNF – это предварительно откомпилированные файлы INF, а файлы INF – это файлы с информацией об установке драйверов устройств. Папка C:\Windows\Inf хранит кэш этих файлов и обычно содержит файл PNF для каждого файла INF. В отличие от других файлов PNF в этом каталоге, нет ни одного файла INF, имя которого бы совпадало с файлами PNF от Stuxnet, но их имена позволяют им смешиваться с другими файлами в этой папке. Как и в случае с операцией записи файлов драйверов, стеки этих операций также имеют ссылки на CopyFileEx и отключение фильтра на запись показывает, что их файл-источник также является изначально созданным временным файлом Stuxnet. Здесь вы можете видеть, что Stuxnet копирует ~Dfa.tmp в Oem7a.pnf:

Все записи в эти файлы выполнены процессом Lsass.exe, за исключением нескольких записей в Mdmcpq3.pnf, выполненных зараженным процессом Services.exe:

Когда копирование завершено, Stuxnet проделывает дополнительные шаги, чтобы скрыть эти файлы, делая так, чтобы их параметры создания файла соответствовали другим файлам PNF этого каталога, в случае моей тестовой системы – 4 ноября 2009 года. Здесь операция SetBasicInformationFile устанавливает время для файла Oem7a.pnf:

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

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

В трассировке есть одна операция, которой я не могу дать объяснение, и назначение которой я не смог найти ни в одном опубликованном анализе Stuxnet. Речь идет о его попытке удалить значение реестра с именем HKLM\System\CurrentControlSet\Services\Network\FailoverConfig:

Это значение реестра и даже ключ Network не используется Windows или другим компонентом, который я смог найти. Поиск исполняемых файлов в каталоге C:\Windows не дал никаких подсказок. Возможно Stuxnet создает этот ключ в определенных ситуациях как маркер и код автоматически запускается чтобы удалить его.

Следующий шаг

На данный момент наш анализ вируса Stuxnet с помощью нескольких инструментов Sysinternals позволил зарегистрировать влияние Stuxnet на систему в момент заражения и метод реактивации при последующих загрузках, а также создать законченное решение для отключения Stuxnet и очистки пострадавшей системы. В третьей части я взгляну на Stuxnet с помощью инструментов Sysinternals, исследуя то, как Stuxnet использует каждый из четырех созданных им файлов PNF, чтобы узнать об их назначении. Я также проанализирую запись активности во время заражения Windows 7, чтобы показать метод, которым Stuxnet использовал уязвимость «нулевого дня» в Windows 7 (которая впоследствии была закрыта) для получения административных прав, тогда как изначально он был запущен с правами стандартного пользователя. Ждите третьей части …