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

Хотя сначала я не понял, с чем я столкнулся, впервые Stuxnet попался мне на глаза 5 июля прошлого лета, когда я получил электронную почту от программиста с вложенным файлом драйвера Mrxnet.sys, который они идентифицировали как руткит. Драйвер, ведущий себя как руткит, не является чем-то особенным, однако данный файл отличался тем, что его информация о версии идентифицировала его как драйвер Microsoft, и он имел корректную цифровую подпись от Realtek Semiconductor Corporation - известного производителя компонентов для ПК (хоть я и очень благодарен программисту, отославшему этот руткит мне, официальным каналом оповещения Microsoft о вредоносном ПО является портал Malware Protection Center).

Я отправил этот файл команде Microsoft, занимающейся исследование вопросов безопасности и вредоносного ПО, и наш внутренний обзор рассказывает о том, что послужило началом саги Stuxnet и сделало драйвер, который я получил, одним из самых бесславных вредоносных программ из когда-либо созданных. Следующие несколько месяцев исследований показали, что Stuxnet использовал четыре уязвимости "нулевого дня" в Windows, чтобы распространиться и получить права администратора (каждая из этих уязвимостей была устранена вскоре после их обнаружения), и был подписан сертификатом, украденным у Realtek и JMicron. Интересно то, что аналитики обнаружили код, который перепрограммирует системы SCADA (Supervisory Control and Data Acquisition) от Siemens, используемые в некоторых центрифугах, и многие подозревали, что Stuxnet был специально разработан для уничтожения центрифуг, используемых для обогащения урана в иранской ядерной программе, причем, по сообщениям от иранского правительства, данная цель частично была достигнута.

В результате Stuxnet стал широко известен как одна из самых сложных вредоносных программ из когда-либо созданных. Основываясь на очевидных подсказках о назначении Stuxnet, найденных в его коде, некоторые исследователи полагают, что это первый известный пример вредоносного ПО, использованный в спонсируемой госслужбами кибервойне. Я рассказал о некоторых примерах вредоносного кода, ориентированного на системы производственной среды, в моем недавно опубликованном кибер-триллере Zero Day, а так как я написал эту книгу несколько лет назад, они могут показаться несколько преувеличенными. Stuxnet доказал, что мои примеры были гораздо ближе к истине, чем я предполагал (кстати, если вы читали Zero Day, пожалуйста, оставьте свой обзор на Amazon.com).


Вредоносное ПО и инструменты Sysinternals
В нескольких моих последних публикациях в блоге я рассказал о задокументированных случаях использования инструментов Sysinternals для очистки системы от вредоносного ПО, однако исследователи вредоносных программ также часто используют эти утилиты для анализа вирусов. Профессиональный анализ вредоносного кода - это выверенный и утомительный процесс, требующий разбора вредоносного кода с целью обратного ассемблирования их операций, однако инструменты мониторинга системы, такие как Sysinternals Process Monitor и Process Explorer могут помочь аналитикам получить полное представление об активности вредоносного ПО. Они также могут помочь понять цели, преследуемые вредоносной программой, и помогают найти точки входа и части кода, требующие более пристального анализа. Как было показано в моих предыдущих публикациях, эти поиски могут послужить руководством к созданию рецептов очистки системы от вредоносного кода для антивирусных продуктов.

Поэтому я решил, что будет интересно показать, как с помощью инструментов Sysinternals можно понять начальные стадии распространения вируса Stuxnet (отмечу, что при написании этой статьи ни одна центрифуга не пострадала). Я полностью покажу процесс заражения системы Windows XP и затем опишу способ, который вирус использует одну из уязвимостей "нулевого дня" для получения административных прав при запуске из стандартной учетной записи Windows 7. Имейте ввиду, что Stuxnet - это очень сложное вредоносное ПО. Оно размножается и взаимодействует, используя множество методов и выполняя различные операции в зависимости от версии инфицированной операционной системы и установленного на ней программного обеспечения. Этот лишь поверхностный обзор Stuxnet, и его целью является показать, как без специальной экспертизы инструменты Sysinternals могут раскрыть влияние вредоносного кода на систему. Подробный анализ действий Stuxnet приведен в документе W32.Stuxnet Dossier от Symantec.


Вектор заражения Stuxnet
Stuxnet получил распространение прошлым летом прежде всего через USB-драйвы, так что я начну заражение с помощью вируса, установленного на такой брелок. Вирус состоит из шести файлов: четыре вредоносных ярлыка с именами типа "Copy of Shortcut to.lnk" и двумя файлами с именами, которые позволяют им выглядеть как обычные временные файлы. Я использовал все один ярлык для этого анализа, так как все они служат одной и той же цели:

В этом векторе инфекции Stuxnet начинает выполняться без вмешательства пользователя, используя преимущества уязвимости "нулевого дня" в коде ярлыка Windows Explorer Shell (Shell32.dll). Все что пользователю нужно сделать - это открыть папку, содержащую файлы Stuxnet, в Проводнике. Чтобы заражение прошло успешно, я для начала удалил исправление KB2286198, которое было встроено в обновлении безопасности Windows от августа 2010. Когда Explorer открывает ярлык на непропатченной системе, чтобы найти файл, на который указывает ярлык, с целью отобразить иконку, Stuxnet заражает систему и использует технику руткита, чтобы скрыть файлы, заставляя их исчезнуть из Проводника.


Stuxnet на Windows XP
Прежде чем заразить систему, я загрузил Process Monitor, Process Explorer и Autoruns. Я настроил Autoruns для выполнения сканирования с выбранными опциями "Hide Microsoft and Windows Entries" и "Verify Code Signatures":

Он удаляет все записи, которые имеют цифровую подпись Microsoft или Windows, так что остаются только записи, содержащие сторонний код, включая код, подписанный другими издателями. Я сохранил результаты работы утилиты, так что я мог сравнить этот список Autoruns с полученными позже и выделить любые записи, добавленные Stuxnet. Точно также я остановил обновление Process Explorer, нажав клавишу пробел, что поможет мне обновить его после заражения и показать любые процессы, запущенные Stuxnet, выделенные зеленым цветом, который Process Explorer использует для новых процессов. В то время как Process Monitor производил регистрацию обращения к реестру, файловой системе и DLL-библиотекам, я перешел в корневую папку флешки, дождался исчезновения временных файлов, дал вирусу немного времени, чтобы завершить заражение, после чего остановил Process Monitor и обновил Autoruns и Process Explorer.

После обновления Autoruns, я использовал функцию Compare из меню File, чтобы сравнить обновленные записи с сохраненными ранее. Autoruns обнаружил две регистрации новых драйверов устройств, Mrxnet.sys и Mrxcls.sys:

Mrxnet.sys - это драйвер, который изначально прислал мне программист и который реализовывал функции руткита, скрывающего файлы; Mrxcls.sys - это второй файл драйвера Stuxnet, который запускал вредоносный код при загрузки системы. Авторы Stuxnet могли бы легко расширить файл функциональность Mrxnet, чтобы он скрывал эти файлы он утилит, подобных Autoruns, однако они, очевидно, были уверенны, что действительные цифровые подписи от известной компании убедят кого угодно, что эти файлы можно оставить в автозагрузке. Оказывается, что Autoruns показал нам все, что нам нужно знать, чтобы устранить заражение, для чего нужно всего лишь удалить или отключить две записи драйверов.

Обратив свое внимание на Process Explorer, я также увидел две зеленых записи, которые обе относились к экземплярам процесса Local Security Authority Subsystem (Lsass.exe):

Обратите внимание, что экземпляр Lsass.exe находится сразу после этих записей и выделен розовым: в нормальной установке Windows XP есть всего один экземпляр Lsass.exe, который создает процесс Winlogon при загрузке системы (в Windows Vista и старше его создает процесс Wininit). Дерево процессов показывает, что два новых экземпляра Lsass.exe были созданы процессом Services.exe (не видно на этом скриншоте), Service Control Manager, что означает, что Stuxnet каким-то образом вставил свой код в этот процесс.

Process Explorer также может проверять цифровые подписи у файлов, которые вы можете увидеть, открыв диалоговое окно свойств процесса или DLL и нажав кнопку Verify, или выбрав опцию Verify Image Signatures в меню Options. Проверка поддельных процессов Lsass подтвердила, что они были запущенны готовым образом Lsass.exe:

У двух дополнительных процессов Lsass очевидно имеется какая-то вредоносная цель, но главный исполняемый файл и командная строка не указывают нам на то, что это может быть. Однако помимо запуска в качестве дочернего процесса от Services.exe, другой подозрительной особенностью двух лишних процессов является тот факт, что они загружают очень мало DLL-библиотек, как показано на следующем скриншоте Process Explorer:

Настоящий Lsass загружает гораздо больше динамических библиотек:

В списке загруженных модулей Services.exe, Lsass.exe и Explorer.exe нет никаких DLL, принадлежащих не Microsoft, так что вероятно именно в них был внедрен вредоносных код. Разбор этого кода потребовал бы продвинутых навыков от программиста, но мы могли бы с помощью утилиты Sysinternals VMMap определить, где в процессе находится этот код, и, соответственно, что конкретно надо будет анализировать специалисту с указанными навыками. VMMap - это анализатор памяти процесса, который визуализирует использование адресного пространства процессом. Чтобы выполниться, код должен быть сохранен в областях памяти, которые имеют разрешение на выполнение, и, поскольку внедренный код, вероятно, будет сохранен в памяти, обычно используемой для данных и потому не исполняемой, будет возможно найти этот код, посмотрев на память, не используемую DLL или исполняемыми файлами, которые имеют разрешение на выполнение. Если эта область имеет разрешение на запись, это делает ее еще более подозрительной, поскольку для заражения потребовалось бы разрешение на запись, которое, вероятно, по-прежнему было необходимо и после внедрения вредоносного кода. Достоверно известно, что у настоящего Lsass не исполняемых областей данных, однако оба новых процесса Lsass обладают областями памяти с разрешениями на запись и выполнение в их адресном пространстве в одном и том же месте и одного и того же размера:

Диалоговое окно VMMap Strings, которое вы открываете из меню View, показывает любые печатаемые строки в выбранной области. Область 488K имеет строку, которая начинается с "This program cannot be run in DOS mode", что является стандартным сообщением, сохраненным в заголовке каждого исполняемого файла Windows. Это означает, что данный вирус внедрил не просто участок кода, а целую DLL:

В данной области практически нет другого распознаваемого текста, так что, вероятно, она сжата, однако в конце этой области находятся строки Windows API из таблицы импорта DLL:

Explorer.exe, изначально зараженный процесс, и Services.exe, процесс, который запустил процессы Lsass, также не загружают никаких подозрительных DLL, но имеют необычные области с исполняемыми данными:

Два драйвера Mrx также видны в списке загруженных драйверов, который вы можете увидеть в представлении DLL в Process Explorer для процесса System. Из общего числа драйверов они выделяются только тем, что согласно их информации о версии драйвера они принадлежат Microsoft, однако их подписи относятся к Realtek (данные сертификаты были отозваны, но, так как тестовая система была отключена от Интернет, она не смогла сделать запрос к серверам Certificate Revocation List):

Смотрим вглубь
На данный момент мы сделали все, что только можно сделать с помощью Autoruns и Process Explorer. Пока что мы знаем только то, что Stuxnet внедряет в систему два драйвера, регистрирует их для запуска во время загрузки системы и запускает их. Он также заражает Services.exe и создает два процесса Lsass.exe, которые работают до выключения системы, цель которых не может быть определена по их командной строке или загруженным DLL. Однако VMMap указал нам на внедренный код и Autoruns предоставил нам простой способ избавиться от вируса. Трассировка активности заражения от Process Monitor содержит около 30000 записей, которые в дальнейшем помогут нам глубже разобраться в том, что происходит во время заражения, где на диске хранится зараженный код, и как Stuxnet активирует этот код во время загрузки. Продолжение во второй части …


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