Две недели назад, когда мы сообщили об обнаружении шпионской программы 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 — и ни на какой другой файл в нашей коллекции.

Вредоносная программа Flame использует для своего распространения несколько различных методов. Наиболее интересный – использование службы Microsoft Windows Update. Этот метод реализован в модулях SNACK, MUNCH и GADGET, входящих в состав Flame. Будучи составными частями Flame, эти модули легко поддаются перенастройке. Поведением этих модулей управляет глобальный реестр Flame – база данных, содержащая тысячи вариантов настроек.

SNACK: подмена NBNS

Модуль SNACK создает сетевой RAW-сокет для всех или предопределенных сетевых интерфейсов, после чего начинает получать все сетевые пакеты. Он ищет пакеты NBNS, посылаемые другими машинами, которые ищут в локальной сети компьютеры с определенными именами. При получении такого пакета он записывается в зашифрованный файл (“%windir%\temp\~DEB93D.tmp”) и передается на дальнейшую обработку.

Когда имя в запросе NBNS имеет вид «wpad*» или «MSHOME-F3BE293C», модуль SNACK отвечает отправкой IP-адреса компьютера, на котором он установлен. Если для переменной SNACK.USE_ATTACK_LIST установлено значение «True», то модуль также проверяет, какие из пакетов отправлены с IP-адресов, указанных в его списке SNACK.ATTACK_LIST, и отвечает тем машинам, адреса которых найдены в списке.

Wpad – это имя, используемое для автоматического обнаружения прокси-сервера. Отвечая на запросы «wpad» собственным IP-адресом, модуль SNACK объявляет зараженную машину прокси-сервером в локальной сети.

Модули SNACK и MUNCH также обмениваются данными с модулем GADGET, обеспечивающим обработку различных событий, приходящих из других модулей. Реестр Flame содержит модули, написанные на языке Lua, для обработки таких событий, как «MUNCH_ATTACKED», «SNACK_ENTITY.ATTACK_NOW».

MUNCH: поддельный прокси-сервер и перехват запросов в службу Windows Update

«MUNCH» – имя модуля Flame, выполняющего функции HTTP-сервера. Модуль запускается, только если переменная MUNCH.SHOULD_RUN установлена в значение «True» и не выполняются никакие программы, способные оповестить жертву о заражении. Эти программы (антивирусы, сетевые экраны, сетевые снифферы и т.д.) определены в реестре Flame в списке под названием «SECURITY.BAD_PROGRAMS»

При запуске модуля MUNCH он считывает буфер из переменной MUNCH.WPAD_DATA, заменяет шаблон «%%DEFAULT%%» IP-адресом наилучшего подходящего сетевого интерфейса и ожидает HTTP-запросов.

Содержимое переменной MUNCH.WPAD_DATA

Буфер MUNCH.WPAD_DATA – это фактически WPAD-файл, запрашиваемый сетевыми клиентами, в которых включено автоматическое обнаружение прокси-сервера. Код в файле WPAD сопоставляет MD5-хеш имени хоста, с которым соединяется клиент, с собственным списком и, если значение хеша найдено в списке, предлагает себя в качестве HTTP прокси-сервера. Нам удалось определить имена, соответствующие хешам:

download.windowsupdate.com
download.microsoft.com
update.microsoft.com
www.update.microsoft.com
v5.windowsupdate.microsoft.com
windowsupdate.microsoft.com
www.download.windowsupdate.com
v5stats.windowsupdate.microsoft.com
v4stats.windowsupdate.microsoft.com
v9stats.windowsupdate.microsoft.com
v5.windowsupdate.com
v7stats.windowsupdate.microsoft.com
v6stats.windowsupdate.microsoft.com
v8stats.windowsupdate.microsoft.com
v5.download.windowsupdate.com

Таким образом, когда компьютер, на котором настроено автоматическое определение прокси-сервера, пытается установить соединение с одним из серверов Windows Update, он получает от модуля SNACK IP-адрес зараженной машины, а затем получает IP-адрес той же машины в качестве прокси-сервера из файла wpad.dat, выданного модулем MUNCH. С этого момента все запросы в службу Windows Update проходят через сервер, поднятый модулем MUNCH.

Когда сетевой клиент устанавливает соединение с сервером MUNCH и запрашивает URI, отличающийся от «/wpad.dat» и «/view.php», сервер:

1) Запускает «MUNCH.SHOULD_ATTACK_SCRIPT» – скрипт на Lua, проверяющий, соответствует ли заголовок User-Agent хотя бы одному из шаблонов, указанных в «MUNCH.USER_AGENTS.CAB_PATTERN_*». В имеющихся у нас файлах реестра Flame содержатся следующие шаблоны:

MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*
MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.*
MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.*
MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.*

2) Проверяет, соответствуют ли запрашиваемые URI какому-нибудь из шаблонов, указанных в списке строк под названием «MUNCH.GENERIC_BUFFERS.*.data.PATTERN». Если одно из выражений соответствует запрашиваемому, сервер получает буфер, указанный в соответствующем значении «MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA», считывает значение имени вредоносного модуля в переменной «MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA» и отправляет соответствующий вредоносный модуль клиенту.

Все вредоносные модули перечислены в реестре Flame под именами, начинающимися с «MUNCH.GENERIC_BUFFERS_CONTENT.payload_name», и зашифрованы с помощью алгоритма RC4 с фиксированным 104-байтным ключом.

Шаблон URI	Имя вредоносного модуля
*v9/windowsupdate/redir/muv4wuredir.cab* *v8/windowsupdate/redir/muv3wuredir.cab* *v7/windowsupdate/redir/wuredir.cab* *v6/windowsupdate/redir/wuredir.cab* *ws03sp1/windowsupdate/redir/wuredir.cab*	WUREDIR
*/v9/windowsupdate/?/?elf?pdate/WSUS3/x86/Other/wsus3setup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/NetServer/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/XP/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/W2K/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/W2KSP2/*/wusetup.cab*	WUSETUP
*update.microsoft.com/v6/windowsupdate/selfupdate/wuident.cab*	XP_WUIDENT
*v5/redir/wuredir.cab*	XP_WUREDIR
*download.windowsupdate.com/v6/windowsupdate/?/SelfUpdate/ AU/x86/XP/en/wusetup.cab*	XP_WUSETUP
*muauth.cab*	MUAUTH
*muredir.cab*	MUREDIR
*muident.cab*	MUIDENT
*/version_s.xml	VISTA_7_VERSION_S
*/version.xml	VISTA_7_VERSION
*v9/windowsupdate/redir/muv4wuredir.cab* *v8/windowsupdate/redir/muv3wuredir.cab* *v7/windowsupdate/redir/wuredir.cab* *v6/windowsupdate/redir/wuredir.cab* *ws03sp1/windowsupdate/redir/wuredir.cab*	VISTA_7_WUREDIR
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WuSetupHandler.cab*	VISTA_7_WUSETUPHANDLER
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.0.6000.381.cab*	VISTA_7_WUCLIENT
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/wsus3setup.cab*	VISTA_7_WSUS3SETUP
*v9/windowsupdate/selfupdate/wuident.cab*	VISTA_7_WUIDENT

Большинство вредоносных модулей представляют собой подписанные CAB-архивы. Архивы, содержащие вредоносный код, подписаны «MS» в декабре 2010 и ноябре 2011 года, в то время как остальные архивы, по-видимому, действительно взяты из настоящей службы Windows Update и подписаны «Microsoft Corporation».

Имена вредоносных модулей	Содержимое	Подпись
WUREDIR_VISTA_7_WUREDIR_	wuredir.xml	Microsoft Corporation_01 июля 2009 г.
WUSETUP	Default/wuapplet2.ocx _Default/wuaucom.dat _Default/wuauinfo.ocx _Default/wuconf.ini _Default/wusetup.ocx _wsus3setup.cat _wsus3setup.inf _wuapplet2.ocx _wuaucom.dat _wuauinfo.ocx _wuconf.ini _wups2.cab _wups2.cat _wusetup.cat _wusetup.inf _wusetup.ocx_	MS 10 ноября 2011 г.
XP_WUIDENT	wuident.txt	Microsoft Corporation 25 мая 2005 г.
XP_WUREDIR	wuredir.xml	Microsoft Corporation 16 июня 2005 г.
XP_WUSETUP	Default/ wuapplet2.ocx _Default/wuaucom.dat _Default/wuauinfo.ocx _wups2.cab _wusetup.cat _wusetup.inf _wusetup.ocx_	MS 28 декабря 2010 г.
MUAUTH	authorization.xml	Microsoft Corporation 05 июня 2008 г.
MUREDIR	wuredir.xml	"Microsoft Corporation 01 июля 2009 г.
MUIDENT	muident.txt	MS 28 декабря 2010 г.
VISTA_7_VERSION_S	отсутствует	не подписано
VISTA_7_VERSION	92 bytes, not a CAB file	не подписано
VISTA_7_WUSETUPHANDLER	WuSetupV.exe	MS 28 декабря 2010 г.
VISTA_7_WUCLIENT	update.cat _update.mum_	MS 28 декабря 2010 г.
VISTA_7_WSUS3SETUP	WUClient-SelfUpdate- ActiveX~31bf3856ad364e35~x86~ ~7.0.6000.381.mum _WuPackages.xml_	MS 28 декабря 2010 г.
VISTA_7_WUIDENT	wuident.txt	MS 28 декабря 2010 г.

Поскольку CAB-файлы имеют действительные подписи (на данный момент отозванные Microsoft), служба Windows Update принимает и обрабатывает их как обычные обновления Windows. Они загружаются и устанавливаются, что приводит к выполнению вредоносного модуля.

Основной вредоносный модуль, содержащийся в этих CAB-файлах, представляет собой компонент-загрузчик под названием «Wusetup.ocx» или «WuSetupV.exe». Он собирает общие данные о компьютере, в т.ч. информацию о часовом поясе, и пытается обратиться к «http://MSHOME-F3BE293C/view.php», причем к URI в запросе добавляется информация о хосте. Поскольку имя «MSHOME-F3BE293C» обрабатывается модулем SNACK, URL указывает на действующий сервер MUNCH, который обслуживается главным модулем Flame «mssecmgr.ocx».

WuSetupV загружает этот файл, сохраняет его в «%windir%\Temp\~ZFF042.tmp», загружает его как DLL и запускает его функцию «DDEnumCallback», представляющую собой процедуру установки Flame. Таким образом, еще один компьютер оказывается заражен.

Даже «лучше», чем эксплойт нулевого дня

Сразу же после того, как мы обнаружили Flame, мы принялись искать в его коде хотя бы один эксплойт, использующих уязвимость нулевого дня для распространения Flame и заражения других машин в локальной сети. Учитывая сложность программы и тот факт, что она заражала машины, работающие под управлением Windows 7 с установленными необходимыми обновлениями, такой эксплойт должен был присутствовать. То, что мы обнаружили, даже «лучше» любого эксплойта нулевого дня. Это, скорее, напоминает чит-код в компьютерной игре, который включает «режим бога» – код, подписанный сертификатами, которые изначально были выписаны Microsoft. Цифровая подпись была обнаружена и немедленно отозвана Microsoft, после чего компания сразу же опубликовала информационное сообщение об угрозе (security advisory) и выпустила обновление KB2718704.

27 мая 2012 года иранский координационный центр CERT (MAHER) опубликовал сведения об обнаружении новой целевой атаки, получившей название Flamer. 28 мая в 9 часов утра (часовой пояс восточного побережья США — EST) после проведения расследования, организованного по просьбе Международного союза электросвязи, «Лаборатория Касперского» и венгерская лаборатория CrySyS Lab объявили об обнаружении вредоносной программы Flame (она же Skywiper) — сложнейшего набора инструментов для кибершпионажа, мишенями которого стали прежде всего Windows-компьютеры в странах Ближнего Востока.

Несколько часов спустя, около 4 часов пополудни по Гринвичу, была отключена инфраструктура командных серверов Flame, проработавшая несколько лет.

В течение последних недель «Лаборатория Касперского» осуществляла детальный мониторинг инфраструктуры командных серверов (C&C) Flame. В сотрудничестве с GoDaddy и OpenDNS нам удалось переключить на sinkhole-маршрутизатор большинство вредоносных доменов, используемых инфраструктурой C&C Flame, и получить уникальные сведения о работе этой вредоносной программы.

«Лаборатория Касперского» хотела бы поблагодарить отдел по борьбе с сетевыми злоупотреблениями GoDaddy (GoDaddy Network Abuse Department) и Уильяма МакАртура (William MacArthur) за их быстрый отклик и неоценимую поддержку этого расследования. Группа исследования проблем безопасности OpenDNS (OpenDNS security research team) также оказала нам ценнейшее содействие в ходе расследования.

Результаты нашего анализа инфрастуктуры Flame приведены ниже.

Введение

Поскольку похоже, что и Flame, и Duqu нацелены на одни и те же регионы и создавались с учетом аналогичных целей, мы приводим сравнительный анализ инфраструктуры C&C-серверов Flame и Duqu.

Ранее «Лаборатория Касперского» проводила анализ инфраструктуры C&C-серверов Duqu и обнаружила несколько важных деталей (например то, что киберпреступники предпочитают CentOS и используют SharpSSH для контроля прокси-серверов), а также большое количество атакованных прокси-серверов, используемых для сокрытия подлинной identity киберпреступников.

В инциденте с Flame мы провели похожий анализ. Прежде всего, интересным является отличие от Duqu: в то время как все известные C&C Duqu работали под CentOS, все известные C&C Flame функционируют на Ubuntu.

Помимо этого, если Duqu использовал очень незаметный способ сокрытия настоящего IP-адреса основного сервера, используя для передачи SSH-порт, скрипты Flame просто работают на соответствующих серверах. Причина проста — в понедельник 28 мая все контрольные скрипты начали показывать ошибки 403/404. В случае с Duqu реальные вредоносные скрипты находились на удаленном сервере и не были ни разу обнаружены.

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

Ниже мы приводим сравнение инфраструктуры C&C-серверов Duqu и Flame:

Как уже упоминалось в прошлом блогпосте про Flame, его объем кода и функциональность настолько обширны, что их полный анализ займёт несколько месяцев. Мы планируем по мере обнаружения публиковать наиболее важные и интересные подробности, связанные с его функционалом.

В данный момент мы получаем множество запросов о том, как проверить компьютеры на наличие заражения Flame. Естественно, самый простой ответ (для нас) — это посоветовать использовать Анитвирус Касперского или Kaspersky Internet Security. Наши продукты успешно детектируют и удаляют все возможные модификации главного модуля и дополнительных компонентов Flame.

Однако для тех, кто хочет сам провести тщательную проверку, в конце статьи мы даем необходимые рекомендации и советы.

MSSECMGR.OCX

Основной модуль Flame — это DLL-файл под названием mssecmgr.ocx. Мы обнаружили две модификации этого модуля. На большинстве заражённых машин содержалась «большАя» версия — 6 Мбайт, которая содержит в себе и развёртывает дополнительные модули. «Малая» версия весит всего 900 Кбайт и не содержит дополнительных модулей. После установки малый модуль соединяется к одному из C&C-серверов и пытается загрузить оттуда и установить оставшиеся компоненты.

Вирусы Duqu и Stuxnet повысили градус кибервойны на Ближнем Востоке, однако недавно мы обнаружили, пожалуй, самое изощренное кибероружие на сегодняшний день. Червь Flame, созданный для кибершпионажа, попал в поле зрения экспертов «Лаборатории Касперского» при проведении исследования по запросу Международного союза электросвязи (МСЭ), обратившегося к нам за содействием в поиске неизвестной вредоносной программы, которая удаляла конфиденциальные данные с компьютеров, расположенных в странах Ближнего Востока. В процессе поиска этой программы, получившей название Wiper, мы обнаружили новый образец вредоносного ПО, который был назван Worm.Win32.Flame.

Хотя Flame имеет иной функционал, чем печально известные образцы кибероружия Duqu и Stuxnet, все эти вредоносные программы имеют много общего: географию атак, узкую целевую направленность в сочетании с использованием специфических уязвимостей в ПО. Это ставит Flame в один ряд с «кибернетическим супероружием», развертываемым на Ближнем Востоке неизвестными злоумышленниками. Без сомнения, Flame является одной из самых сложных киберугроз за всю историю их существования. Программа имеет большой размер и невероятно сложную структуру. Она заставляет переосмыслить такие понятия, как «кибервойна» и «кибершпионаж».

Подробную информацию об этой изощренной угрозе читайте ниже.

После того как в пятницу мы перехватили одно из доменных имен, которые использует Mac-троянец Flashfake, и установили специальный sinkhole-сервер, мы смогли собрать статистику о размере и географическом распределении ботнета. Информацию об этом мы публиковали в прошлом блогпосте.

Мы продолжаем перехват доменных имен и мониторинг размера ботнета. Суммарное количество зафиксированных нами уникальных ботов составляет более 670 тысяч.

Интересно, что в выходные дни (7-8 апреля) нами отмечено значительно снижение числа подключавшихся ботов:

Однако, это не говорит о том, что размер ботнета стремительно уменьшается – данные цифры обусловлены вероятно именно выходными днями.

На протяжении нескольких дней наш сервер регистрировал все данные обращения зараженных компьютеров и собирал базу их уникальных идентификаторов, передаваемых ботом. На основании этой информации мы реализовали специальный сервер онлайн-проверки для всех пользователей Mac OSX, желающих проверить наличие возможного заражения Flashback. Теперь мы можем установить, был ли ваш UUID зафиксирован в базе обращений ботов к нашему sinkhole-серверу.

Подробная информация о том, как пройти данную проверку, и рекомендации, что необходимо сделать в случае заражения, находится на сайте flashbackcheck.com

Пользователи Mac OSX также могут проверить, инфицирован ли их компьютер Flashfake, и удалить вредоносную программу в случае ее наличия, используя специальную утилиту «Лаборатории Касперского».

В конце прошлого года авторы 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.

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

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

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

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

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

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

Читать

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

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

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

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

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

При анализе 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.