Stuxnet/Duqu: эволюция драйверов

Два месяца продолжается наше исследование троянца Duqu — истории его появления, ареала распространения и схем работы. Несмотря на громадный объем полученных данных (большую часть которых мы пока не публикуем), у нас все еще нет ответа на главный вопрос – кем был создан Duqu.

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

С точки зрения архитектуры платформа, на которой созданы Duqu и Stuxnet, одинакова. Это файл-драйвер, который осуществляет загрузку основного модуля, выполненного в виде зашифрованной библиотеки. При этом существует отдельный файл конфигурации всего вредоносного комплекса и специальный блок в системном реестре, определяющий местоположение загружаемого модуля.

Условная схема архитектуры платформы.

Данную платформу можно условно назвать, скажем, «Tilded» — из-за странной тяги авторов к использованию имен файлов, начинающихся с «~d».

Мы считаем, что Duqu и Stuxnet были параллельными проектами, которые поддерживала одна и та же команда разработчиков.

Ряд выявленных нами фактов указывает на возможное существование как минимум еще одного шпионского модуля, основанного на той же платформе, в 2007-2008 годах и нескольких других программ неизвестного функционала в период 2008-2010 годов.

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

«Официальная» история Stuxnet

Позвольте начать с вопроса — сколько известно файлов драйверов Stuxnet? До сего дня правильным ответом было — четыре. Вот информация о них:

Первая модификация червя Stuxnet, созданная в 2009 году, использовала только один файл драйвера — mrxcls.sys, — и в нем отсутствовала цифровая подпись.

В 2010 году авторы создали второй драйвер mrxnet.sys (его целью было сокрытие файлов червя на USB-дисках) и снабдили mrxnet.sys и драйвер mrxcls.sys цифровыми сертификатами компании Realtek. Драйвер mrxnet.sys в рамках нашей истории не представляет большого интереса, поскольку является отдельным модулем и не входит в общую архитектуру платформы.

17 июля 2010 года компания ESET обнаружила в «дикой природе» еще один драйвер — jmidebs.sys, — который был весьма схож с уже известным mrxcls.sys, но был создан всего лишь за три дня до обнаружения. Этот драйвер был подписан новым сертификатом — на этот раз компании Jmicron.

До недавних пор оставалось неизвестным назначение этого файла, но, согласно общепринятому мнению, драйвер относился именно к Stuxnet. Одной из версий было его возможное распространение через C&C Stuxnet для замещения старой версии с сертификатом Realtek на новую. Таким образом авторы червя якобы пытались обойти его детектирование антивирусными программами либо стали использовать новый сертификат вместо уже заблокированного.

Увы, но эта версия не подтвердилась — Jmidebs.sys больше никогда и нигде не обнаруживали. Какого-либо нового варианта Stuxnet, который мог бы устанавливать этот файл, также найдено не было.

Так выглядит «официальная» история Stuxnet. Точнее, выглядела. Как я уже сказал выше, в ходе исследования мы обнаружили новые факты, и далее речь пойдет о них.

Неизвестные ранее драйверы

rtniczw.sys

В ходе анализа одного из инцидентов с Duqu нам удалось обнаружить кое-что новое — и это может изменить сложившуюся историю червя Stuxnet.

На компьютере пострадавшего пользователя был обнаружен странный файл, который детектировался нашим антивирусом как «Rootkit.Win32.Stuxnet.a». Этот детект должен был бы соответствовать известному файлу mrxcls.sys, описанному выше, однако контрольная сумма и имя файла отличались!

Это был файл rtniczw.sys размером в 26872 байт,
MD5 546C4BBEBF02A1604EB2CAAAD4974DE0.

Размер файла был чуть больше, чем у mrxcls.sys, снабженного цифровой подписью Realtek. Это означало, что файл rtniczw.sys тоже обладает цифровой подписью. Нам удалось получить копию данного файла, и вы можете представить наше изумление, когда оказалось, что в нем использован тот же цифровой сертификат компании Realtek, однако дата подписания файла отличается от даты подписи в mrxcls.sys: файл rtniczw.sys был подписан 18 марта 2010 года, тогда как драйвер mrxcls — 25 января того же года.

Кроме этого rtniczw.sys работает с ключом и блоком системного реестра, не использовавшимися в Stuxnet. В Stuxnet использовался ключ «MRxCls» и значение «Data», здесь же был указан ключ «rtniczw» и значение «Config».

Детальный анализ кода rtniczw.sys не выявил других отличий от «эталонного» драйвера — это был тот же самый mrxcls.sys, созданный в тот же год, день и час — 1 января 2009 года.

Мы попробовали найти дополнительную информацию о пользователях, у которых встречался такой же файл, но не нашли ни одного! Более того, нам не удалось найти никакой информации ни об имени файла (rtniczw.sys), ни о его MD5 ни в одной поисковой системе. Данный файл обнаруживался лишь однажды — в мае 2011 года он был отправлен для проверки на VirusTotal из Китая.

Судя по всему, исследуемая нами система в Иране была поражена в конце августа 2011 года. Важно отметить, что нам не удалось обнаружить там заражения Stuxnet — из комплекта Stuxnet не было найдено ни одного дополнительного файла. Зато были обнаружены файлы Duqu.

Мы пришли к выводу, что могут существовать и другие похожие на «эталонный» mrxcls.sys файлы драйвера, которые не относятся к известным вариантам Stuxnet.

rndismpc.sys

Проверка нашей вирусной коллекции выявила еще один интересный файл, попавший к нам более года назад. Файл имеет название «rndismpc.sys», размер 19968 байт,
MD5 9AEC6E10C5EE9C05BED93221544C783E.

Это оказался еще один драйвер, полностью аналогичный по функционалу mrxcls.sys за исключением следующих пунктов:

1. rndismpc.sys работает с ключом системного реестра, отличным и от mrxcls, и от rtniczw — ключ «rndismpc» со значением «Action»;
2. использован отличный от mrxcls/rtniczw ключ шифрования — 0x89CF98B1;
3. дата компиляции файла — 20 января 2008 года, т.е. на год раньше, чем дата создания mrxcls/rtniczw.

Файл rndismpc.sys также никогда и нигде не встречался у наших пользователей. Неизвестно, какая вредоносная программа устанавливала его, и c каким основным модулем он должен был работать.

Связующее звено: mrxcls.sys —> jmidebs.sys —> драйверы Duqu

Добавив к полученным данным известную информацию о драйверах, использованных в Duqu (см. Тайна Duqu, часть первая и часть вторая), можно составить следующую таблицу:

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

Анализ показывает, что jmidebs.sys является связующим звеном между mrxcls.sys и драйверами, использованными затем в Duqu.

Код драйверов mrxcls и jmidebs в значительной мере совпадает. Некоторые различия могут быть вызваны разными настройками компилятора и минимальными изменениями в исходном коде, смысл кода при этом неизменен.

Однако в нескольких функциях присутствуют более серьезные изменения:

1. Служебная функция, получающая адреса API-функций.
   Версия функции в mrxcls использует для этого функцию MmGetSystemRoutineAddress и, соответственно, использует текстовые имена получаемых адресов API функций.
   Версия в jmidebs вызывает собственные функции для получения адресов API по хеш-суммам от их имен. Точно такие же функции используются в драйверах Duqu, при этом список хешей функций в них увеличен вдвое.
2. Функция, создающая модуль-заглушку для внедрения PNF DLL в процессы.
   Версия mrxcls использует заглушку общим размером 6332 байта.
   Версия jmidebs и драйвера Duqu используют заглушки общим размером 7061 байта.
   Код модулей-заглушек во всех этих драйверах идентичен, при этом различаются даты их компиляции.

Схема эволюции драйверов

Мы составили карту-схему связей между известными драйверами, на которой легко можно проследить их эволюцию и ключевые точки развития.

Схема эволюции драйверов

rndismpc.sys, rtniczw.sys и jmidebs.sys

Как видно, для трех драйверов — rndismpc.sys, rtniczw.sys и jmidebs.sys — неизвестна основная вредоносная программа, с которой они взаимодействовали. Логичный вопрос здесь — использовались ли они в Stuxnet? С нашей точки зрения правильный ответ — нет.

Во-первых, если бы они использовались в Stuxnet, их распространенность была бы гораздо больше, чем выявленные нами единичные случаи. Во-вторых, не было обнаружено ни одного варианта Stuxnet, способного работать с этими драйверами.

Файл rtniczw.sys был подписан 18 марта 2010 года, но 14 апреля 2010 года авторы Stuxnet создали новый вариант червя, в котором использовали «эталонный» mrxcls.sys. Очевидно, что предназначение у rtniczw.sys было иным. Это же утверждение относится и к jmidebs.sys. Мы считаем, что эти три драйвера однозначно следует убрать из истории Stuxnet — они имеют к ней косвенное отношение.

Еще один вопрос — могли ли эти драйверы использоваться для работы с Duqu?

Здесь нет однозначного ответа. Несмотря на то, что все известные варианты Duqu относятся к периоду ноябрь 2010 — октябрь 2011 года, мы считаем, что существовали и более ранние варианты троянца-шпиона, созданного для кражи информации. Эти три драйвера вполне могли быть использованы либо в ранних вариантах Duqu, либо для работы с какими-то другими троянцами, тоже основанными на платформе Stuxnet/Duqu. Вероятней всего, также как и Duqu, эти троянцы использовались для проведения точечных атак — как до появления Stuxnet (как минимум в 2008 году), так и во время его существования и после закрытия его C&C. Это были параллельные проекты, и Stuxnet базировался на уже накопленном опыте и созданном программном коде, при этом он был не единственным проектом стоящих за ним людей.

Процесс создания драйверов

Давайте представим себе, как может выглядеть процесс создания драйверов. Несколько раз в год их авторы компилируют новую версию файла драйвера, получая «эталонный» файл. Его основная задача — загрузка основного модуля, который создается отдельно. Это может быть Stuxnet, или Duqu, или что-то еще.

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

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

В зависимости от задачи и объекта, против которого применяются троянцы, некоторые файлы-драйверы затем могут быть подписаны легальными цифровыми сертификатами, происхождение которых все еще неизвестно.

Заключение

Исходя из полученных нами данных, можно с большой долей уверенности говорить о том, что платформа «Tilded» была разработана как минимум в конце 2007 — начале 2008 года, и наиболее значительные изменения претерпела летом — осенью 2010 года. Эти изменения были вызваны развитием кода и необходимостью обхода детектирования со стороны антивирусов. На протяжении 2007-2011 годов существовало несколько проектов по созданию программ на основе платформы «Tilded», из которых известны Stuxnet и Duqu. Остальные же проекты неизвестны до сих пор. Платформа продолжает развиваться, но очередной раз требует внесения в нее изменений, вызванных обнаружением Duqu.