Введение

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-носители.

 

Две недели назад, когда мы сообщили об обнаружении шпионской программы Flame, мы говорили о том, что не усматриваем никакого совпадения в её коде или стиле программирования с платформой Tilded, на которой были основаны Stuxnet и Duqu.

Flame и Tilded совершенно разные проекты, основанные на разной архитектуре, и каждая использует свои уникальные трюки. Так, например, во Flame никогда не использовались драйвера, тогда как для Stuxnet и Duqu именно драйвер был основным способом загрузки модулей на исполнение.

Но мы оказались неправы. Неправы в том, что считали Flame и Stuxnet независимыми проектами.

Наше исследование выявило неизвестные ранее факты, которые полностью изменяют существующую на данный момент историю создания Stuxnet.

Flame внутри Stuxnet

Для начала необходимо вспомнить историю Stuxnet. Как считается, всего было создано три варианта этого червя – в июне 2009 года и в марте и апреле 2010.

Вариант от марта 2010 года вызвал наибольшее число заражений и был обнаружен в июне 2010 специалистами белорусской компании «ВирусБлокАда». Именно этот вариант и подвергся наиболее детальному исследованию со стороны антивирусных компаний.

Чуть позднее, когда о Stuxnet уже стало широко известно, были выявлены его файлы, относящиеся к июню 2009 года. Это так называемый Stuxnet.A (1.0), который достаточно сильно отличается от вариантов 2010 года.

Основными отличиями считались:

• Вариант 2009 не использует уязвимость в обработке LNK-файлов (MS10-046).
• В 2009 году Stuxnet содержал только один файл драйвера, в то время как в 2010 их стало два (второй был добавлен именно для распространения при помощи LNK-уязвимости).
• В 2009 году Stuxnet использовал трюк с autorun.inf для заражения USB-дисков.

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

Самым значительным из этих изменений стал ресурс 207, который в версии 2009 года имел размер 520 192 байта и полностью отсутствовал в версии 2010 года.

Список ресурсов в Stuxnet 2010 года

Список ресурсов в Stuxnet 2009 года

Несмотря на то, что Stuxnet был объектом детального исследования многих компаний и экспертов, и об его устройстве написано множество текстов, каким-то образом ресурс 207 от 2009 года остался практически неисследованным. Но именно он и оказался тем самым связующим звеном между, казалось бы, совершенно разными проектами – Flame и Stuxnet.

История Tocy

В октябре 2010 года наша автоматическая система обработки получила из «дикой природы» файл. Он был автоматически проанализирован и классифицирован как новый вариант Stuxnet – Worm.Win32.Stuxnet.s.

Stuxnet в тот момент был громкой темой, и мы посмотрели на файл более внимательно, пытаясь понять, что же это такое. Выяснилось, что он не был похож на Stuxnet от 2010 года, отличия были весьма значительными. Посетовав на «глупую автоматическую систему», мы решили переименовать его в Trojan-Spy.Win32.Tocy.

Когда в 2012 году мы обнаружили Flame, мы стали искать старые экземпляры этого червя, которые могли быть получены нами ранее. Среди файлов, которые выглядели почти идентичными Flame, мы нашли Tocy.

Проверив в логах историю обработки файлов, мы установили, что изначально этот файл был классифицирован как Stuxnet. Мы задумались — как это могло произойти? Почему система думала, что этот образец Flame был связан со Stuxnet? Более детальный анализ логов показал, что Tocy, один из ранних модулей Flame, в действительности очень похож на 207 ресурс из Stuxnet.

Они настолько похожи, что наша автоматическая система посчитала его Stuxnet-ом. Более того, Tocy похож только на Stuxnet — и ни на какой другой файл в нашей коллекции.

Два месяца продолжается наше исследование троянца 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.

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

История вопроса и несколько фактов:

В апреле этого года Иран заявил, что стал жертвой кибератаки, содержащей вирус Stars. В этой статье изложены некоторые дополнительные детали атаки.

Сегодня мы можем подтвердить, что некоторые цели Duqu были поражены 21 апреля с использованием того же самого метода, включая использование уязвимости CVE-2011-3402, эксплойта базового уровня для win32k.sys, внедренного через True Type Font (TTF) файл.

По данным IrCERT (Iran's Computer Emergency Response Team) Duqu — это усовершенствованная модификация Stars.

Прежде всего я должен сообщить об ошибке, допущенной в прошлом тексте.

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

Судите сами – Duqu в своей работе проверяет наличие подключения к интернету и пытается обратиться к серверу kasperskychk.dyndns.org, который должен находиться по адресу 68.132.129.18. Анализ информации по этому адресу показывает, что он находится в том же самом дата-центре, что и «обнаруженный» нами 63.87.255.149!

Но увы, на самом деле я ошибся при конвертации адреса. Ошибка была вызвана одним единственным аргументом – сравните “1062731669” и “-1062731669”. В первом случае это дает нам 63.87.255.149, а во втором – локальный адрес 192.168.0.107 – в котором, конечно, нет ничего интересного для нашего исследования :(

Дроппер и 0-day

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

Как нами и ожидалось – здесь не обошлось без использования уязвимости. Был обнаружен MS Word doc-файл, который был направлен хакерами одной из жертв. Файл содержит в себе эксплоит ранее неизвестной уязвимости Windows, в результате использования которой из файла извлекались и запускались компоненты Duqu.

В настоящий момент Symantec и Microsoft все еще не предоставили другим антивирусным компаниям ни сам файл дроппер, ни информации о том, в каком компоненте Windows содержится уязвимость, приводящая к повышению привилегий, однако по косвенным признакам, мы можем предположить уязвимость в win32k.sys.

Похожая уязвимость, MS10-073, была обнаружена нами год назад, в ходе анализа червя Stuxnet. Еще одна аналогичная проблема в win32k.sys (MS11-077) была исправлена 11 октября этого года.

Компания Microsoft сообщила, что работает над исправлением новой уязвимости, однако похоже, что патч не будет доступен в ноябрьском обновлении.

Важно отметить, что обнаружение дроппера и пути его проникновения в систему (целевая атака на выбранную жертву, по электронной почте) доказывает правильность нашего предположения о том, что атаки Duqu нацелены на крайне малое число жертв и в каждом случае могут использоваться уникальные наборы файлов.

Для заражения других компьютеров в сети, Duqu использует создание на удаленной машине задач в Планировщике Windows (Scheduler). Точно такую же технику мы уже видели в Stuxnet и это один из любимых трюков атакующих при проведении целевых атак. Все это, вместе с другими уже известными деталями, усиливает теорию о том, что Stuxnet и Duqu были созданы одними и теми же людьми

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

Наше исследование зафиксированных нами инцидентов с Duqu в Судане и Иране продолжается. На данный момент мы насчитываем 3 пострадавших в Судане и 4 в Иране. С некоторыми из них мы уже ведем работу по обнаружению всех компонент Duqu и установлению путей первоначального заражения.

Мы ожидаем этих результатов в самое ближайшее время и опубликуем их в очередных выпусках Mystery of Duqu.

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

Однако прежде чем сообщить о наших очередных находках, я должен выразить глубокое уважение к работе, проделанной венгерской исследовательской лабораторией Crysys. Именно они были первыми, кто исследовал компоненты Duqu и подготовил великолепный отчет, который затем был предоставлен ими другим антивирусным компаниям и стал основой для дальнейших исследований. К сожалению, наша компания не была в числе первых получателей этого отчета, но тем интересней эта задача для нас сейчас – выяснить про Duqu всё.

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