В апреле 2012 года было опубликовано несколько сообщений о таинственной атаке с использованием вредоносного ПО, которая привела к отказу компьютерных систем в компаниях по всему Ирану.

В нескольких статьях говорилось, что ответственность за атаки лежит на вирусе под названием Wiper (в переводе - чистильщик). Однако не было найдено ни одного образца вредоносной программы, использованной в этих атаках, что заставило многих усомниться в точности сведений, содержащихся в этих сообщениях.

После этих инцидентов Международный союз электросвязи (МСЭ) обратился к 'Лаборатории Касперского' с просьбой провести расследование данных инцидентов и определить потенциальные деструктивные последствия активности этого нового вредоносного ПО.

Спустя несколько недель после начала расследования нам так и не удалось найти файлы вредоносного ПО, свойства которого совпадали бы с известными характеристиками Wiper. Однако мы обнаружили проводимую на государственном уровне кампанию по кибершпионажу, известную сегодня как Flame, а позднее - еще одну систему кибершпионажа, получившую название Gauss.

Мы убеждены в том, что Wiper был отдельной ветвью вредоносного ПО - другими словами, это не был Flame. Несмотря на то, что Flame - чрезвычайно гибкая платформа для проведения атак, следов особо деструктивного поведения мы не нашли. Учитывая сложность Flame, можно предположить, что программа использовалась для долговременной слежки за жертвами, а не для прямых атак, направленных на выведение компьютерных систем из строя. Конечно, не исключено, что одним из последних этапов слежки могло стать развертывание вредоносного функционала, имеющего отношение к Wiper, но на сегодняшний день никаких свидетельств этого мы не нашли.

Итак, несколько месяцев спустя мы по-прежнему задаемся вопросом: Wiper - что же это было такое?

Введение

Gauss – новейшая система кибер-слежки, открывшая еще одну страницу в саге о Stuxnet, Duqu и Flame. Вредоносная программа, по-видимому, была создана в середине 2011 года и впервые применена в августе-сентябре того же года.

Программа Gauss была обнаружена в ходе расследования, которое проводилось по инициативе Международного союза электросвязи (МСЭ), выдвинутой после обнаружения вредоносной программы Flame. Цель проводимой работы – снижение рисков, которые несет кибероружие. Это ключевой элемент усилий по достижению главной цели –мира в глобальном киберпространстве.

Если попытаться уложить описание не более чем в 140 символов, то: «Gauss – это «банковский» троянец, созданный государством, имеющий вредоносный функционал неизвестного назначения». В дополнение к краже разнообразных данных с зараженных Windows-компьютеров он содержит неизвестный пока вредоносный функционал, код которого зашифрован и который активируется только в системах с определенной конфигурацией.

Точно так же, как Duqu был основан на платформе Tilded, на базе которой создан Stuxnet, Gauss базируется на платформе Flame. Программа имеет некоторые общие функциональные элементы с Flame, такие как подпрограммы заражения USB-носителей.

В этой подборке «Часто задаваемых вопросов» (FAQ) мы ответим на некоторые из главных вопросов о функционировании Gauss. Кроме того, мы выпустили подробный технический документ (HTML/PDF), в котором описан полный функционал вредоносной программы.

Глубоко в одном из конфигурационных блоков Stuxnet заложена 8-байтовая переменная, которая содержит некое число, и если это число прочитать как дату, оно указывает на 24 июня 2012 года. А в действительности это день, когда подпрограммы распространения Stuxnet посредством LNK-файлов прекратили работу и перестали заражать USB-носители.

 

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

В 2012 никаких признаков Duqu в Сети не обнаруживалось. Но несколько дней назад коллеги из Symantec сообщили об обнаружении в «дикой природе» нового драйвера, практически аналогичного тем, которые ранее использовались в Duqu. Однако известные ранее драйверы были созданы 3 ноября 2010 и 17 октября 2011 года, а новый драйвер — 23 февраля 2012 года.

После четырех месяцев перерыва авторы Duqu вновь вернулись к работе.

Duqu вернулся

Новый драйвер Duqu совпадает по функциональности с предыдущими известными нам версиями. Отличия в коде незначительные, но свидетельствуют о проделанной «работе над ошибками», направленной на противодействие детектированию файла.

• Изменены настройки оптимизации компилятора и/или атрибуты разворачивания (inline) функций.
• На 32 байта увеличен размер EXE файла-заглушки, который используется для внедрения PNF DLL в процессы.
• В LoadImageNotifyRoutine сравнение имени модуля “KERNEL32.DLL” производится сравнением хеш-сумм; предыдущие версии сравнивали строки.
• Размер зашифрованного блока увеличен с 428 байт до 574 байт. Количество полей в блоке не изменилось, но при этом увеличен буфер, в котором хранится имя значения реестра «FILTER». Скорее всего, в этой версии драйвера это имя будет меняться.
• Изменилась функция расшифровки крипто-блока, ключа реестра и PNF. Это третья известная нам версия алгоритма шифрования в драйверах Duqu.
• Изменилась функция хеширования API функций, соответственно, и все хеши, которые используются для получения их адресов.

Старая функция, используемая во всех предыдущих версиях драйвера:

Новая функция:

То, что данный драйвер был обнаружен в Иране, еще раз подтверждает, что большинство инцидентов Duqu связано с этой страной.

В поисках решения

В предыдущем блогпосте про Фреймворк Duqu я писал про одну из нерешенных нами задач — определение языка, на котором написан необычный код, отвечающий за общение Duqu с C&C серверами. Нам, техническим специалистам, задача показалась очень интересной, и мы решили предложить IT-сообществу поучаствовать в ее решении.

Мы получили намного больше ответов, чем ожидали — более 200 комментариев и 60+ писем с указанием различных языков и фреймворков, которые могли быть использованы при создании кода Фреймворка Duqu. Мы хотим поблагодарить всех, кто участвовал в решении и помогал идентифицировать загадочный код.

Самыми популярными вариантами, которые вы предложили, были:

• LISP (различные диалекты)
• Forth
• Erlang
• Google Go
• Delphi
• OO C
• Старые компиляторы C++ и других языков

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

Расположение кода

На первый взгляд, Payload DLL выглядит как обычная загружаемая библиотека формата Windows PE, скомпилированная Microsoft Visual Studio 2008 (версия компоновщика 9.0). Код, расположенный в точке входа, абсолютно стандартный. Единственная экспортируемая функция под номером 1 тоже написана на MSVC++. Эта функция вызывается из PNF DLL и реализует весь функционал данной библиотеки – соединение и общение с C&C серверами, получение и выполнение дополнительных модулей троянца. Интересные детали обнаруживаются при более глубоком анализе кода, который вызывается этой функцией в процессе работы.

Содержимое секции кода Payload DLL типично для исполняемого файла, скомпонованного из нескольких исходных модулей. Секцию можно условно разделить на несколько разделов, каждый из которых соответствует одному или нескольким файлам исходного кода. Большая часть разделов присутствует в любой программе, написанной на C++, — это, например, функции стандартной библиотеки шаблонов STL, функции стандартной библиотеки языка и собственно код программы. Однако самый большой раздел, реализующий всю логику общения с C&C серверами, отличается от них во всем.

Содержимое секции кода Payload DLL

Этот раздел не типичен для C++ программ, потому что его исходный код – не C++. Код внутри раздела не обращается к другим функциям программы, написанным на C++, и не использует стандартную библиотеку языка, хотя используемые парадигмы явно указывают, что исходный текст был написан на объектно-ориентированном языке программирования. Мы назвали это Фреймворком Duqu.

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

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

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

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

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

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

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

Читать

В последние несколько недель мы занимались исследованием инфраструктуры серверов управления, используемых Duqu.

Широко известен факт, что первоначально обнаруженные образцы Duqu использовали C&C в Индии, размещенный на площадке хостинговой компании WebWerks. Впоследствии был выявлен еще один сервер Duqu — базирующийся в Бельгии, у хостера Combell Group Nv.

«Лаборатория Касперского» в настоящий момент обнаружила более 12 различных вариантов Duqu. Среди них есть те, которые соединялись с серверами в Индии, в Бельгии, но также и с другими серверами — двумя во Вьетнаме и одним в Голландии. Кроме них, много других серверов были использованы авторами Duqu в организации всей сетевой инфраструктуры. Некоторые их них использовались как основные прокси-сервера, другие были предназначены для скрытия следов.

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

Прежде чем продолжить рассказ, мы должны сказать, что мы все еще не знаем, кто стоит за Duqu и Stuxnet. Хотя нам удалось захватить и проанализировать некоторые из серверов, атакующим удалось замести свои следы достаточно эффективно. 20 октября 2011 года, спустя три дня после публичного оглашения информации об обнаружении Duqu, они провели крупную операцию по «зачистке». Атакующие очистили каждый сервер, который они использовали как минимум с 2009 — в Индии, Вьетнаме, Германии, Великобритании и так далее. Тем не менее, несмотря на эту массовую акцию по скрытию следов, мы все же можем пролить некоторый свет на то, как работала сеть Duqu.

Драйвер

Драйвер является первым компонентом Duqu, который загружается в систему. По нашим данным, драйвер и другие компоненты этой вредоносной программы устанавливаются с помощью дроппера, использующего 0-day уязвимость (CVE-2011-3402). Драйвер прописывается в реестре по следующему пути: HKLM\System\CurrentControlSet\Services\. Конкретное имя ключа реестра отличается в разных версиях драйвера Duqu.

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

Все версии драйвера, которые нам известны, имеют одинаковое имя значения реестра: «FILTER».

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

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

Наибольшего же успеха нам удалось добиться в расследовании инцидента под порядковым номером #1, описанным в прошлой публикации. Нам удалось не только обнаружить все недостающие файлы этого варианта Duqu, но также обнаружить источник заражения и сам файл-дроппер, содержащий эксплойт уязвимости в win32k.sys (CVE-2011-3402).

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