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

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

Файлы PNF

Моим первым шагом в поиске подсказок, указывающих на предназначение файлов PNF, было определения размеров этих файлов. Небольшие файлы, вероятно, были бы данными, а побольше – кодом. Ниже перечислены размеры файлов PNF, которые я определил с помощью Explorer:

MDMERIC3.PNF 90

MDMCPQ3.PNF 4,943

OEM7A.PNF 498,176

OEM6C.PNF 323,848

Я также сделал копию печатных символов, содержащихся в файлах, с помощью утилиты SysinternalsStrings, но не нашел значащих слов. Однако я не удивился, поскольку ожидал, что файлы будут сжаты и зашифрованы.

Я подумал, что посмотрев на способ, которым Stuxnet ссылается на PNF-файлы, я смог бы понять, для чего они используются. Чтобы получить более полное представление об их назначении, я записал загрузочный журнал Process Monitor перезагруженной системы после заражения. Протоколирование загрузки, которое можо включить с помощью опции Enable Boot Logging в меню Options, указывает 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:\Windows\Inf. Они сопровождались событиями Svchost.exe, которые напрямую связаны со службой планировщика задач. Процесс Scvhost.exe создает новый файл запланированной задачи в папке C:\Windows\System32\Tasks и затем устанавливает несколько связанных значений реестра. Стеки этих событий показывают, что 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.