Недавно мы столкнулись с интересным образцом вредоносного кода, который обнаруживается ESET как Win32/Syndicasec.A. Он обращал на себя внимание по ряду следующих причин:
Мы провели детальное исследование этого бэкдора и выяснили детали его установки на скомпрометированный компьютер, используемые им механизмы по поддержанию своего присутствия, а также детали взаимодействия с C&C сервером.
Установка и поддержание присутствия
Для установки вредоноснго кода Win32/Syndicasec используется эксплойт. Несмотря на то, что были зафиксированы операции блокирования действий этого эксплойта нашими антивирусными продуктами, мы не смогли получить его целиком, поэтому мы не уверены какой именно эксплойт использовался для атаки. Далее начинается двухэтапный процесс установки бэкдора.
На первом этапе дроппер проводит некоторые подготовительные действия. Осуществляется проверка существования файла %SYSTEM32%\sysprep.exe. В случае его присутствия вредоносный код копирует извлеченный из себя .cab файл в директорию %TEMP%. Далее содержимое этого архива будет скопировано в файл %SYSTEM32%\cryptbase.dll с использованием инструмента Windows Update Standalone Installer (wusa.exe). Для этого используется команда, представленная ниже.
Сам .cab файл хранится в дроппере в открытом виде, за исключением того, что отсутствует сигнатура архива — первые несколько байт. Эти байты будут дописаны в буфер памяти перед его записью в файл на диск.
Для повышения привилегий дроппер пытается эксплуатировать уязвимость известную как COM Elevation (UAC whitelist). Аналогичный способ повышения привилегий в системе использовался дроппером руткита Avatar, который был рассмотрен нами.
Внутри этой библиотеки мы обнаружили отладочную строку, дающую некоторое представление о проекте.
Второй этап заключается в исполнении другого дроппера, который хранится в %TEMP%\gupdate.exe. В случае присутствия инструмента sysprep.exe в системе, дроппер запускается с использованием этого инструмента. При исполнении дроппера также используется техника повышения привилегий путем эксплуатирования UAC whitelist. Если sysprep не найден в системе, для исполнения gupdate.exe используется обычный интерпретатор командной строки cmd.exe.
Исполняемый файл gupdate.exe отвечает за установку полезной нагрузки в систему. Для этого используется WMI. Следует отметить, что во вредоносном ПО такой метод встречается довольно редко. Такая тактика была замечена в черве Stuxnet. Вы можете найти подробное ее описание в документе наших коллег из Trend Micro.
Метод установки полезной нагрузки с использованием WMI имеет ряд очень полезных особенностей с точки зрения атакующего, например, вредоносный код не обязан постоянно хранится в виде файла на диске. Такой подход значительно понижает шансы обнаружения вредоносной активности с использованием инструментов типа Process Explorer.
Установка полезной нагрузки в систему происходит по следующему сценарию. На первом этапе фрагмент кода Javascript расшифровывается в дроппере gupdate.exe с использованием обычного XOR. Пример этого кода представлен ниже на скриншоте.
Затем происходит создание собственных WMI классов.
1. Класс __TimerInstruction
Вредоносный код создает класс __TimerInstruction для установки события с именем “ProbeScriptInit” в сигнальное состояние каждые 60,000 миллисекунд.
2. Класс __EventFilter
Этот класс отвечает за логическое объединение специального таймера с вредоносным кодом, содержащимся в __EventConsumer.
3. __EventConsumer
Этот класс содержит вредоносный код, который исполняется при каждой установке события кодом __TimerInstruction.
Вышеперечисленные объекты располагаются в пространстве имен root\subscription, что обеспечивает их достаточную скрытность.
Возможности бэкдора и взаимодействие с сетью
Рассмотрим вредоносный скрипт, который содержится в объекте __EventConsumer. Код из этого скрипта достаточно прост для анализа. Видно, что он содержит жестко зашитые в код URL-адреса, которые выбираются произвольным образом, и далее используются для работы с командным C&C сервером через обычный GET запрос HTTP протокола. Мы называем эти адреса: URL-адреса первого уровня (Stage One URLs). Фактически, все эти жестко зашитые адреса ведут на веб-страницы поддельных блогов, в которых осуществляется отслеживание (RSS feed) адресов второго уровня для связи с C&C серверами. На скриншоте ниже представлен пример одного из таких блогов:
Ключевым элементом в этом RSS-канале является тэг , который содержит зашифрованную строку между двух разделителей ‘@’.
Ниже на скриншоте показан код скрипта, в котором видно какая процедура используется для расшифровки этой строки.
В результате расшифровки строки получается другой адрес, который называется URL-адрес второго уровня (Stage Two URL). Этот адрес и будет использован для фактической связи с командным C&C сервером.
Первоначальное сообщение отправляется на URL-адрес второго уровня с использованием POST запроса HTTP-протокола и содержит некоторую основную информацию о зараженном компьютере. Ответ на это сообщение представляет из себя HTML контейнер div, который содержит одну или несколько команд.
Статический анализ показывает, что получаемый буфер команд включает в себя обфусцированный Javascript сценарий, который посредством преобразований eval() извлекает из себя другой скрипт.
Наблюдаемая активность
Параллельно с анализом кода, мы отслеживали поведение специального тестового компьютера, который был заражен с использованием Win32/Syndicasec. После нескольких первых дней мониторинга были зафиксированы команды от C&C. По наблюдаемому взаимодействию бота с C&C очевидно, что это взаимодействие не является автоматическим, а управляется человеком, находящимся за консолью управления ботами. Мы пришли к такому выводу, поскольку каждый день фиксировалось различное количество команд, посылаемых в нерегулярные промежутки времени.
Ниже на скриншоте представлен фрагмент одной из первых сессий взаимодействия бота с C&C сервером. Если вы обратите внимание на отметки времени, то обнаружите, что все команды были получены в течение более 30 минут. Следует отметить, что каждая команда включает в себя сценарии Javascript, необходимые для исполнения. Для краткости мы включили полный код только для некоторых функций. Команды с идентичными временными отметками были получены в одном буфере команд.
Можно констатировать, что оператор просматривал на зараженной машине файловую систему, а также настройки сети, подключенные диски и запущенные программы.
На следующий день оператор использовал другой набор команд для сбора данных о зараженной системе.
В этой сессии оператор использовал схожие команды для осуществления аналогичных целей, но они были сделаны несколько по-другому. Это позволяет предположить, что в данном случае мы имели дело с другим оператором, отличным от первого. Можно отметить, например, следующую явную опечатку или ошибку в следующей строке:
ExecuteCommand(‘dir c:\\dir c:’);
Адреса URL второго уровня оставались неизменными до 2013-04-22. После чего был добавлен новый домен netfortibt.info. Информацию о нем смотрите в следующем разделе.
История вредоносного кода
Мы обнаружили одну из версий основного вредоносного скрипта, которая датируется июлем 2010 года. Этот скрипт был загружен на один из онлайн Javascript-анализаторов. Скриншот ниже показывает различия в первых строках кода скрипта для двух версий: 0.5.2 и 1.2.0.
При дальнейшем анализе различий между этими двумя версиями, мы можем увидеть зашифрованные данные в теле контейнера title, которые относятся к RSS ленте и не были изменены в более новой версии. С другой стороны видно, что в более старой версии, C&C сервер не применял шифрование к командам, отправляемым ботам, а посылал их в виде открытого текста. Команды подвергались шифрованию уже в версии 1.2.0 основного скрипта (см. функцию circleDecode())
Мы можем увидеть, что версия 0.5.2 скрипта выполняет вызовы функций WMI API, необходимые для регистрации объектов в пространстве имен root\subscription. Эта схема отличается от той, что используется в более новой версии 1.2.0, в которой эта операция зависит от дроппера для выполнения вызовов WMI.
Старая версия скрипта содержит только один жестко зашитый URL первого уровня, который был все еще активен на момент написания этого анализа. Ниже представлена веб-страница этого URL.
Видно, что только 25 пользователей посетили эту страницу с даты начала ее публикации в сентябре 2010 г. Расшифрованное содержимое контейнера title показывает неактивный URL второго уровня (hxxp://.hostaim.com/summer/ieupdate.php).
Еще один скрипт был найден с использованием того же самого Javascript-анализатора. Мы можем увидеть диалог между зараженным хостом и командным C&C сервером начиная с 2012 г. Строка запроса показывает, что на зараженном хосте запущен скрипт версии 1.0.1.
Вышеприведенная информация довольно ясно показывает, что эта угроза была активна и использовалась в течение нескольких лет.
Ниже приведена информация о доменах, которые использовались для URL-адресов второго уровня.
В отличие от одного DoD IP-адреса, другие три осуществляли хостинг для сотен доменов. Большинство из этих доменов были зарегистрированы менее года назад и указывают на любительские веб-сайты для малого бизнеса, в которых используются азиатские языки.
В названии домена nedfortibt.info присутствует акроним NED, который расшифровывается как National Endowment for Democracy (Национальный Фонд Поддержки Демократии). Эта организация так описывает себя на сайте:
Фонд открыто поддерживает тибетцев в их конфликтах с Китаем.
- Наша система телеметрии показывает весьма небольшой масштаб заражений данной угрозой, а география распространения ограничивается такими странами как Непал и Китай. Предыдущие версии этого вредоносного кода фиксировались нами начиная с 2010 года.
- Полезная нагрузка представляет из себя небольшой фрагмент кода на Javascript, который регистрируется с использованием подсистемы Windows WMI.
- Бэкдор использует веб-сайты поддельных блогов для получения информации о командных C&C серверах. Эти веб-сайты размещаются на доменах, зарегистрированных в Тибете.
- По своим характеристикам эта операция очень похожа на предыдущие шпионские кампании, направленные против тибетских активистов, такие как OS X Lamadai и другие.
Мы провели детальное исследование этого бэкдора и выяснили детали его установки на скомпрометированный компьютер, используемые им механизмы по поддержанию своего присутствия, а также детали взаимодействия с C&C сервером.
Установка и поддержание присутствия
Для установки вредоноснго кода Win32/Syndicasec используется эксплойт. Несмотря на то, что были зафиксированы операции блокирования действий этого эксплойта нашими антивирусными продуктами, мы не смогли получить его целиком, поэтому мы не уверены какой именно эксплойт использовался для атаки. Далее начинается двухэтапный процесс установки бэкдора.
На первом этапе дроппер проводит некоторые подготовительные действия. Осуществляется проверка существования файла %SYSTEM32%\sysprep.exe. В случае его присутствия вредоносный код копирует извлеченный из себя .cab файл в директорию %TEMP%. Далее содержимое этого архива будет скопировано в файл %SYSTEM32%\cryptbase.dll с использованием инструмента Windows Update Standalone Installer (wusa.exe). Для этого используется команда, представленная ниже.
Сам .cab файл хранится в дроппере в открытом виде, за исключением того, что отсутствует сигнатура архива — первые несколько байт. Эти байты будут дописаны в буфер памяти перед его записью в файл на диск.
Для повышения привилегий дроппер пытается эксплуатировать уязвимость известную как COM Elevation (UAC whitelist). Аналогичный способ повышения привилегий в системе использовался дроппером руткита Avatar, который был рассмотрен нами.
Внутри этой библиотеки мы обнаружили отладочную строку, дающую некоторое представление о проекте.
Второй этап заключается в исполнении другого дроппера, который хранится в %TEMP%\gupdate.exe. В случае присутствия инструмента sysprep.exe в системе, дроппер запускается с использованием этого инструмента. При исполнении дроппера также используется техника повышения привилегий путем эксплуатирования UAC whitelist. Если sysprep не найден в системе, для исполнения gupdate.exe используется обычный интерпретатор командной строки cmd.exe.
Исполняемый файл gupdate.exe отвечает за установку полезной нагрузки в систему. Для этого используется WMI. Следует отметить, что во вредоносном ПО такой метод встречается довольно редко. Такая тактика была замечена в черве Stuxnet. Вы можете найти подробное ее описание в документе наших коллег из Trend Micro.
Метод установки полезной нагрузки с использованием WMI имеет ряд очень полезных особенностей с точки зрения атакующего, например, вредоносный код не обязан постоянно хранится в виде файла на диске. Такой подход значительно понижает шансы обнаружения вредоносной активности с использованием инструментов типа Process Explorer.
Установка полезной нагрузки в систему происходит по следующему сценарию. На первом этапе фрагмент кода Javascript расшифровывается в дроппере gupdate.exe с использованием обычного XOR. Пример этого кода представлен ниже на скриншоте.
Затем происходит создание собственных WMI классов.
1. Класс __TimerInstruction
Вредоносный код создает класс __TimerInstruction для установки события с именем “ProbeScriptInit” в сигнальное состояние каждые 60,000 миллисекунд.
2. Класс __EventFilter
Этот класс отвечает за логическое объединение специального таймера с вредоносным кодом, содержащимся в __EventConsumer.
3. __EventConsumer
Этот класс содержит вредоносный код, который исполняется при каждой установке события кодом __TimerInstruction.
Вышеперечисленные объекты располагаются в пространстве имен root\subscription, что обеспечивает их достаточную скрытность.
Возможности бэкдора и взаимодействие с сетью
Рассмотрим вредоносный скрипт, который содержится в объекте __EventConsumer. Код из этого скрипта достаточно прост для анализа. Видно, что он содержит жестко зашитые в код URL-адреса, которые выбираются произвольным образом, и далее используются для работы с командным C&C сервером через обычный GET запрос HTTP протокола. Мы называем эти адреса: URL-адреса первого уровня (Stage One URLs). Фактически, все эти жестко зашитые адреса ведут на веб-страницы поддельных блогов, в которых осуществляется отслеживание (RSS feed) адресов второго уровня для связи с C&C серверами. На скриншоте ниже представлен пример одного из таких блогов:
Ключевым элементом в этом RSS-канале является тэг , который содержит зашифрованную строку между двух разделителей ‘@’.
Ниже на скриншоте показан код скрипта, в котором видно какая процедура используется для расшифровки этой строки.
В результате расшифровки строки получается другой адрес, который называется URL-адрес второго уровня (Stage Two URL). Этот адрес и будет использован для фактической связи с командным C&C сервером.
Первоначальное сообщение отправляется на URL-адрес второго уровня с использованием POST запроса HTTP-протокола и содержит некоторую основную информацию о зараженном компьютере. Ответ на это сообщение представляет из себя HTML контейнер div, который содержит одну или несколько команд.
Статический анализ показывает, что получаемый буфер команд включает в себя обфусцированный Javascript сценарий, который посредством преобразований eval() извлекает из себя другой скрипт.
Наблюдаемая активность
Параллельно с анализом кода, мы отслеживали поведение специального тестового компьютера, который был заражен с использованием Win32/Syndicasec. После нескольких первых дней мониторинга были зафиксированы команды от C&C. По наблюдаемому взаимодействию бота с C&C очевидно, что это взаимодействие не является автоматическим, а управляется человеком, находящимся за консолью управления ботами. Мы пришли к такому выводу, поскольку каждый день фиксировалось различное количество команд, посылаемых в нерегулярные промежутки времени.
Ниже на скриншоте представлен фрагмент одной из первых сессий взаимодействия бота с C&C сервером. Если вы обратите внимание на отметки времени, то обнаружите, что все команды были получены в течение более 30 минут. Следует отметить, что каждая команда включает в себя сценарии Javascript, необходимые для исполнения. Для краткости мы включили полный код только для некоторых функций. Команды с идентичными временными отметками были получены в одном буфере команд.
Можно констатировать, что оператор просматривал на зараженной машине файловую систему, а также настройки сети, подключенные диски и запущенные программы.
На следующий день оператор использовал другой набор команд для сбора данных о зараженной системе.
В этой сессии оператор использовал схожие команды для осуществления аналогичных целей, но они были сделаны несколько по-другому. Это позволяет предположить, что в данном случае мы имели дело с другим оператором, отличным от первого. Можно отметить, например, следующую явную опечатку или ошибку в следующей строке:
ExecuteCommand(‘dir c:\\dir c:’);
Адреса URL второго уровня оставались неизменными до 2013-04-22. После чего был добавлен новый домен netfortibt.info. Информацию о нем смотрите в следующем разделе.
История вредоносного кода
Мы обнаружили одну из версий основного вредоносного скрипта, которая датируется июлем 2010 года. Этот скрипт был загружен на один из онлайн Javascript-анализаторов. Скриншот ниже показывает различия в первых строках кода скрипта для двух версий: 0.5.2 и 1.2.0.
При дальнейшем анализе различий между этими двумя версиями, мы можем увидеть зашифрованные данные в теле контейнера title, которые относятся к RSS ленте и не были изменены в более новой версии. С другой стороны видно, что в более старой версии, C&C сервер не применял шифрование к командам, отправляемым ботам, а посылал их в виде открытого текста. Команды подвергались шифрованию уже в версии 1.2.0 основного скрипта (см. функцию circleDecode())
Мы можем увидеть, что версия 0.5.2 скрипта выполняет вызовы функций WMI API, необходимые для регистрации объектов в пространстве имен root\subscription. Эта схема отличается от той, что используется в более новой версии 1.2.0, в которой эта операция зависит от дроппера для выполнения вызовов WMI.
Старая версия скрипта содержит только один жестко зашитый URL первого уровня, который был все еще активен на момент написания этого анализа. Ниже представлена веб-страница этого URL.
Видно, что только 25 пользователей посетили эту страницу с даты начала ее публикации в сентябре 2010 г. Расшифрованное содержимое контейнера title показывает неактивный URL второго уровня (hxxp://.hostaim.com/summer/ieupdate.php).
Еще один скрипт был найден с использованием того же самого Javascript-анализатора. Мы можем увидеть диалог между зараженным хостом и командным C&C сервером начиная с 2012 г. Строка запроса показывает, что на зараженном хосте запущен скрипт версии 1.0.1.
Вышеприведенная информация довольно ясно показывает, что эта угроза была активна и использовалась в течение нескольких лет.
Ниже приведена информация о доменах, которые использовались для URL-адресов второго уровня.
В отличие от одного DoD IP-адреса, другие три осуществляли хостинг для сотен доменов. Большинство из этих доменов были зарегистрированы менее года назад и указывают на любительские веб-сайты для малого бизнеса, в которых используются азиатские языки.
В названии домена nedfortibt.info присутствует акроним NED, который расшифровывается как National Endowment for Democracy (Национальный Фонд Поддержки Демократии). Эта организация так описывает себя на сайте:
Национальный Фонд Поддержки Демократии (NED) является частной некоммерческой организацией, деятельность которой направлена на развитие и укрепление демократических институтов по всему миру. Ежегодно фонд NED выплачивает более 1.000 грантов на поддержку проектов неправительственных организаций за рубежом, работающих над достижением демократических целей в более чем 90 странах.
Фонд открыто поддерживает тибетцев в их конфликтах с Китаем.
