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

В первой статье этой серии я использовал Autoruns, Process Explorer и VMMap для статического анализа вируса Stuxnet на Windows XP. Эта фаза данного исследования показала, что Stuxnet заразил множество процессов, запустил зараженные процессы, которые казались запущенными системой исполнительными файлами, и установил и загрузил два драйвера устройства. Во второй фазе я обратился к трассировке активности Process Monitor, записанной во время заражения, и узнал, что Stuxnet запустил несколько дополнительных процессов во время заражения. Данная запись активности также показала, что Stuxnet скопировал два файла с разрешением PNF в папке C:WindowsInf. В этой заключительной статье я использую инструменты Sysinternals, чтобы попытаться определить назначение данных файлов PNF и посмотреть на то, как Stuxnet использовал уязвимость нулевого дня в Windows 7 (уже закрытую) для запуска с правами администратора.


Файлы 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, и первоначальную трассировку процесса заражения - во втором окне 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:WindowsInf. Они сопровождались событиями Svchost.exe, которые напрямую связаны со службой планировщика задач. Процесс Scvhost.exe создает новый файл запланированной задачи в папке C:WindowsSystem32Tasks и затем устанавливает несколько связанных значений реестра. Стеки этих событий показывают, что 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.


Источник: http://blogs.technet.com/mark_russinovich
Перевод: Dazila