Stuxnet (информация взята из аналитического отчета компании Symantec «W32.Stuxnet Dossier», version 1.4, February 2011, pdf):
основной модуль представляет собой dll;
в dll содержится несколько ресурсов, в том числе два подписанных файла — драйвер автозагрузки и руткит для сокрытия факта заражения USB Flash носителя;
присутствует блок данных конфигурации (первая его половина зашифрована при помощи операции XOR 0xFF, вторая — другим способом).
При инсталляции основной модуль и подписанные файлы сохранялись на диск под именами, заданными в блоке данных конфигурации.
Для автозапуска создавалась служба, которая использовала подписанный драйвер.
В реестре по адресу ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MrxCls’ в ключе ‘Data’ в зашифрованном виде сохранялись имена целевых процессов (services.exe, S7tgtopx.exe, CCProjectMgr.exe), в которые производился инжект.
Duqu (информация взята из аналитического отчета компании Symantec «W32.Duqu The precursor to the next Stuxnet», version 1.4, November 2011, pdf):
инсталлятор представляет собой dll;
в dll содержится три блока данных, содержащих подписанный драйвер, основной модуль и данные конфигурации инсталлятора;
блок данных конфигурации инсталлятора зашифрован при помощи 7-байтового ключа (0x2b 0x72 0x73 0x34 0x99 0x71 0x98).
При инсталляции основной модуль и подписанные драйвера сохранялись на диск под именами, заданными в блоке данных конфигурации.
Для автозапуска создавалась служба, которая использовала подписанный драйвер.
В реестре по адресу ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\JmiNET3’ в ключе ‘FILTER’ в зашифрованном виде сохранялись имя целевого процесса (services.exe), в который производился инжект.
В целом просматривается общий алгоритм:
загрузка подписанного драйвера -> расшифровка им данных в реестре (содержащего сопоставление ‘целевой процес — модуль’) -> инжект модуля в целевой процесс.
Однако это не значит, что его реализовывали в коде одни и те же люди.
Stuxnet и Duqu используют для вызова функции библиотек dll одинаковую методику, направленную на обход мониторинга средствами антивирусной защиты использования LoadLibrary. Для Ntdll.dll устанавливается перехватчик (hook) функций:
ZwMapViewOfSection;
ZwCreateSection;
ZwOpenFile;
ZwCloseFile;
ZwQueryAttributesFile;
ZwQuerySection.
Далее производится вызов LoadLibrary по специально выбранному имени библиотеки dll, несуществующей в системе. В обычных условиях (без перехвата) это вызвало бы ошибку. Именно перехватчик и производит загрузку настоящей библиотеки в адресное пространство.
Так же по информации компании Eset, Stuxnet и Duqu используют одинаковую систему межпроцессорного взаимодействия (RPC), предназначенную для обновления компонентов ВПО в локальной сети.
Являются ли указанные факты явным доказательством связи Stuxnet и Duqu между собой? По-видимому, нет. Вышеописанное вполне может быть результатом заимствования метода внедрения в систему или кода процедуры RPC.
Теперь что касается драйверов. В Stuxnet использовался драйвер mrxcls.sys, подписанный сертификатом Realtek. Чуть позже был обнаружен другой драйвер, jmidebs.sys, подписанный JMicron. Последний везде был анонсирован как очередной драйвер Stuxnet, однако основной модуль с таким драйвером так и не был найден. Также были другие расхождения, драйвер mrxcls.sys использовал прямой вызов функций API по именам, драйвер jmidebs.sys — искал функции по их хэшам. Для внедрения основного модуля mrxcls.sys создавал файл-заглушку (exe) размером 6332 байта, jmidebs.sys — размером 7061 байта. Необычно то, что для расшифровки строк в реестре mrxcls.sys и jmidebs.sys использовали одинаковый ключ — 0xAE240682, который, впрочем, в других версиях Duqu был уже другим. Один из драйверов Duqu имел идентичные jmidebs.sys характеристики (размер файла-заглушки и ключ расшифровки). Таким образом, можно утверждать, что jmidebs.sys, ранее связываемый со Stuxnet, на самом деле — часть Duqu. Есть еще косвенный признак — для ветки Duqu название параметра в реестре набрано заглавными буквами — ‘IDE’ и ‘FILTER’, а у ветки Stuxnet — нет (‘Data’, ‘Config’ и ‘Action’). Специалисты Dell SecureWorks считают, что сходство некоторых элементов обеих вредоносных программ является случайностью. Например, аналогичные методики применяются в других образцах ВПО. Использование имен рабочих файлов, начинающихся с символа ‘~’, также не свидетельство родства. Не стоит также сбрасывать со счетов такую вещь, как подражательство. Исходя из временных отметок компиляции отдельных частей Duqu, его разработка могла относиться к началу 2007 года. Наиболее раннее его проявление в «диком» виде относится к 28 ноября 2008 года. Stuxnet, таким образом, был создан позже, с использованием нескольких технологий Duqu, либо их разработчики черпали информацию (или исходный код) из одного источника. Так что утверждение Микко Хиппонен из F-Secure: «Сходство кодов Duqu и Stuxnet очевидно. Драйвер ядра Duqu (jminet7.sys) настолько схож с драйвером Stuxnet (mrxcls.sys), что наши системы решили, что это и есть Stuxnet» — не совсем соответствует действительности (jminet7.sys и cmi4432.sys — драйвера Duqu, обнаруженные в Венгрии сотрудниками лаборатории CrySyS).
P.S. С целью повышения качества материала, приветствуется указание толковых источников информации на русском и английском языках по данной тематике в комментариях. На их основе будут дорабатываться существующие материалы. Так, в данный момент готовится статья непосредственно о Duqu, а так же дополнение информации о Stuxnet.
ссылка на оригинал статьи http://habrahabr.ru/post/159533/
Добавить комментарий