Порой различия в стиле написания и применяемых принципах работы вредоносного программного обеспечения значительно отличается от образца к образцу. Одни делают ставку на полиморфизм, другие на rootkit компоненту. Особенно в плане развития руткит технологий отличилось семейство ВПО TDL (также называемое TDSS, Alureon, Olmarik, Tidserv). Как известно, новое — это хорошо забытое старое. На заре развития персональных ЭВМ, основную массу ВПО составляли вирусы, которые подразделялись на два класса — файловые и загрузочные (были и комбинированные, например, печально известный OneHalf). Достойным продолжателем дела загрузочных вирусов является буткит TDL-4, хоть и является троянской программой (не способной самостоятельно распространяться). Буткит – слово, образованное из слов бут (boot, загрузочная область) и руткит (rootkit, средство сокрытия признаков деятельности). Но прежде чем стать буткитом, TDL проделал большой путь.
Одна из первых версий руткита была обнаружена Kaspersky Lab в апреле 2008 года, она сохраняла в системе свой драйвер tdsserv.sys, от которого и произошло название TDSS. Впоследствии имя основного драйвера несколько раз менялось на clbdriver.sys, seneka*.sys, UACd*.sys, gaopdx*.sys, tdlserv.sys и другие.
Альтернативное наименование TDL произошло из-за наличия в коде многочисленных идентификаторов, начинающихся с символов 'tdl'. Дроппер TDL-1 содержал два главных файла: непосредственно драйвер-руткит и библиотеку, в которой и находился основной функционал (полезная нагрузка). На тот момент методы перехвата функций были достаточно тривиальными и не отличались новаторством, но позволяли обойти большинство средств антивирусной защиты.
Основные функции маскировки, реализуемые драйвером:
Также драйвер способен выполнять несколько других функций, направленных на активное противодействие антивирусам:
При инсталляции руткита для обхода поведенческой защиты использовалась следующая техника: вредоносный код размещается в системном кеше часто используемых библиотек \KnownDLLS, откуда вызывается легитимным системным приложением при использовании им одной из этих библиотек. Конкретно TDL-1 использовался патчинг библиотеки advapi32.dll, подгружаемой сервисом Microsoft Installer, в ходе инсталляции. Более новые версии использовали патчинг библиотеки msi.dll. Таким образом, вызов кода TDL-1 производился из контекста доверенного приложения. Подробнее о методах, используемых TDL-1 можно узнать в посте Алисы Шевченко.
Инсталляция происходила по аналогичной первой версии TDL методике, при этом патчилась библиотека msvcrt.dll. Для затруднения детектирования драйвера-руткита стали использоваться механизмы обфускации и шифрования. В частности, бинарный код был «разбавлен» случайными словами из произведения «Гамлет» Уильяма Шекспира. По сравнению с первой версией руткит мало поменялся функционально, однако методы сокрытия и защиты изменились, что, вероятно, связанно с попаданием предыдущей версии в антивирусные базы.
Осенью 2009 года появилась третья версия, содержащая в себе множество технических новинок. Техника обхода изменилась, теперь это был метод DLL hijacking, его сущность — ОС сначала ищет необходимую dll в текущей директории, а потом в системной, поэтому, разместив в директории легитимной программы вредоносную библиотеку с именем, совпадающим с именем одной из импортируемых библиотек, можно добиться запуска вредоносного кода. TDL-3 копировал себя в качестве библиотеки в директорию процессора печати, после чего обращался к нему. Это приводило к выполнению вредоносного кода в контексте системного процесса.
Для получения управления после перезагрузки применялся метод инфицирования системных компонентов ОС (драйверов). Для заражения использовался мини-порт/порт драйвер диска atapi.sys, в более поздних модификациях TDL-3 случайным образом выбирал и заражал системные драйверы, подходящие по некоторым параметрам. В драйвер atapi.sys внедрялся небольшой участок вредоносного кода размером 824 байт (917 байт для вариантов с случайными драйверами), который выполнял функции загрузчика, при этом исходный размер драйвера оставался неизменным. Исходные данные, которые замещались, сохранялись вместе с основным кодом в специально выделенном месте в конце жесткого диска. Последние несколько секторов диска организовывались в своеобразное зашифрованное хранилище данных со своей собственной файловой системой, для работы с ним создавалось виртуальное устройство. В этом хранилище так же располагались блоки данных конфигурации. TDL-3 перехватывал обращения к диску и, в случае просмотра его «личных» секторов, возвращал их содержимое в виде блока данных, заполненого нулями. Блок данных конфигурации (config.ini) неизменен для всех трех версий, он содержал следующие данные:
[main] — идентификационные данные
Quote — цитаты из кинофильмов, мультфильмов и т.д., которые выводятся при подключении отладчика;
Version — версия;
Botid — идентификатор бота для административной панели;
AffId — идентификатор «партнерской программы»;
SubId — служит для идентификации сети бота при разделении ботнета на несколько подсетей;
Installdate — дата установки в системе;
Builddate — дата компиляции.
[injector] — сопоставление внедряемых модулей и процессов
содержит список пар значений вида: имя процесса (по умолчанию “*”, означает все процессы) — имя DLL (динамической библиотеки, которую следует подгружать к указанному процессу).
[tdlcmd] — данные серверов
Servers — адреса административных панелей руткита, обычно три адреса;
Wspservers — адреса серверов для работы с поисковыми сервисами;
Popupservers — адреса серверов для открытия страниц;
Version — версия полезной нагрузки.
Распространение TDL осуществлялось при помощи так называемых «партнерских программ» или «партнерок». Согласно Википедии, «партнерская программа — это форма делового сотрудничества между продавцом и партнерами при продаже какого-либо товара или предоставлении услуг; позволяет продавцу сократить расходы на привлечение конечного покупателя». В сфере киберкриминала товаром являются вредоносные программы, а услугами — привлечение пользователей на зараженные веб-ресурсы и заражение их компьютеров. Деньги при этом платятся за каждую успешную установку. Именно для этого используется поле AffId в config.ini, для того, что бы знать, кому в каком объеме выплачивать деньги за установку бота с заданным идентификатором. Также это позволяет оценивать эффективность работы той или иной «партнерки». За содействие в распространении TDL владельцы «партнерок» получают за 1000 установок вредоносной программы от 20 до 200 USD — в зависимости от географического положения компьютера-жертвы. Конечная установка могла производиться различными способами, например путем установки фальшивых кодеков, путем внедрения бота в кейгены для популярного ПО, или распространение посредством cвязки эксплойтов (exploit pack).
Обмен данными с управляющим серверами TDL производился по протоколу HTTPS, для этого злоумышленниками использовался самоподписанный сертификат безопасности (который находился на сервере), выданный вымышленной компанией Internet Widgits Pty Ltd. Использование HTTPS не позволяло антивирусам детектировать и блокировать сетевой трафик по содержимому пакетов. Кроме того, в TDL-3 GET запросы дополнительно шифровались с использованием симметричного алгоритма RC4.
Основная цель TDL — монетизация, на основе созданного с его помощью ботнета. TDL имел модульную структуру и позволял загружать дополнительные модули (в виде DLL) по сети. Одним из модулей, устанавливаемый TDL по умолчанию, была библиотека tdlcmd.dll, выполняющая следующие задачи:
Список команд, поддерживаемых tldcmd.dll:
Перехват пользовательских запросов с целью подмены выдачи производился для популярных поисковых систем, таких как Google, Yahoo, Bing и др. При каждом запросе к таким сайтам tdlcmd.dll генерирует запрос к серверу, указанному в поле Wspservers файла конфигурации. В ответ от сервера приходит ссылка на страницу, которую необходимо отобразить пользователю. Ссылка может вести как на вредоносный сайт (например, для установки другого ВПО), так и на легитимный (накрутка баннеров).
Интересная функция tdlcmd.dll — механизм для недобросовестного «продвижения» сайтов по ключевым словам (Black Seo). Для его работы в хранилище TDK создается файл keywords, содержащий слова, которые необходимо адресовать поисковой системе. Затем в выдаче поисковой системы выбирается сайт, указанный злоумышленниками. При этом, для убедительной имитации работы пользователя, использовался JavaScript, встраиваемый в браузер и имитирующий нажатие на соответствующие элементы управления (кнопки, ссылки и т.д.).
Еще одним способом монетизации была продажа части ботнета, именно в этих целях в config.ini находился параметр SubId. Продаже подлежали подсети ботнета количеством до 20 000 компьютеров. В остальном свой преступный бизнес создатели TDL вели сами.
В феврале 2010 вышло неплановое обновление от Microsoft MS10-015. Данный патч устранял уязвимость, которая позволяет локально повысить свои привилегии, и вносил модификации непосредственно в ядро ОС. После этого патча некоторые пользователи стали жаловаться на появление BSOD. Позже выяснилось, что указанные компьютеры были заражены TDL-3 и BSOD вызывала его некорректная загрузка. Это связано с использованием неявных вызовов WinAPI функций по их смещению в памяти, при обновлении произошли модификации, в результате чего, адреса функций стали другими, и код TDL-3 перестал работать, как задумано. Из-за этой ошибки разработчиков численность ботнета значительно сократилась, особенно в США, где основная масса пользователей пользуется лицензионной Windows с включенным механизмом обновления (источник). Разработчики оперативно отреагировали выпуском TDL версии 3.26. Теперь вместо заражения заранее известного драйвера руткит заражал случайный драйвер, а поиск адресов функций ядра, используемых в этом коде, осуществлялся по контрольным суммам, подсчитанным от их имён. Шифрование хранилище сменилось на более простое с использованием однобайтовой операции XOR и увеличением значения этого байта, начальное значение 0x54 (источник).
Несмотря на некоторые уловки для защиты от потери управления, скрипты командного центра содержали в себе уязвимости, что позволило некоторым исследователям компьютерной безопасности успешно произвести взлом. Подробности одного из них доступны здесь. Согласно информации, полученной из баз данных взломанного сервера, общее количество компьютеров, заражённых руткитом TDL-3 в период с 12.08.2009 по 14.07.2010, составило более 16 000 000 компьютеров. Естественно, что это общее количество. Реально «живых» ботов было порядка 5 000 000. Большее их количество (43%), находилось в США. Это можно объяснить большей денежной отдачей от накрутки баннеров в этой стране.
Продолжение здесь.
TDL-1
Одна из первых версий руткита была обнаружена Kaspersky Lab в апреле 2008 года, она сохраняла в системе свой драйвер tdsserv.sys, от которого и произошло название TDSS. Впоследствии имя основного драйвера несколько раз менялось на clbdriver.sys, seneka*.sys, UACd*.sys, gaopdx*.sys, tdlserv.sys и другие.
Альтернативное наименование TDL произошло из-за наличия в коде многочисленных идентификаторов, начинающихся с символов 'tdl'. Дроппер TDL-1 содержал два главных файла: непосредственно драйвер-руткит и библиотеку, в которой и находился основной функционал (полезная нагрузка). На тот момент методы перехвата функций были достаточно тривиальными и не отличались новаторством, но позволяли обойти большинство средств антивирусной защиты.
Основные функции маскировки, реализуемые драйвером:
- сокрытие веток реестра;
- сокрытие файлов на диске;
- внедрение вредоносного кода в системные процессы из драйвера режима ядра;
- сокрытие сетевых портов TCP;
- сокрытие загруженных DLL библиотек.
Также драйвер способен выполнять несколько других функций, направленных на активное противодействие антивирусам:
- уничтожить поток;
- блокировать выполнение потока;
- уничтожить текущий процесс;
- получать имя текущего процесса;
- выгрузить драйвер;
- получить список запущенных процессов.
При инсталляции руткита для обхода поведенческой защиты использовалась следующая техника: вредоносный код размещается в системном кеше часто используемых библиотек \KnownDLLS, откуда вызывается легитимным системным приложением при использовании им одной из этих библиотек. Конкретно TDL-1 использовался патчинг библиотеки advapi32.dll, подгружаемой сервисом Microsoft Installer, в ходе инсталляции. Более новые версии использовали патчинг библиотеки msi.dll. Таким образом, вызов кода TDL-1 производился из контекста доверенного приложения. Подробнее о методах, используемых TDL-1 можно узнать в посте Алисы Шевченко.
TDL-2
Инсталляция происходила по аналогичной первой версии TDL методике, при этом патчилась библиотека msvcrt.dll. Для затруднения детектирования драйвера-руткита стали использоваться механизмы обфускации и шифрования. В частности, бинарный код был «разбавлен» случайными словами из произведения «Гамлет» Уильяма Шекспира. По сравнению с первой версией руткит мало поменялся функционально, однако методы сокрытия и защиты изменились, что, вероятно, связанно с попаданием предыдущей версии в антивирусные базы.
TDL-3
Осенью 2009 года появилась третья версия, содержащая в себе множество технических новинок. Техника обхода изменилась, теперь это был метод DLL hijacking, его сущность — ОС сначала ищет необходимую dll в текущей директории, а потом в системной, поэтому, разместив в директории легитимной программы вредоносную библиотеку с именем, совпадающим с именем одной из импортируемых библиотек, можно добиться запуска вредоносного кода. TDL-3 копировал себя в качестве библиотеки в директорию процессора печати, после чего обращался к нему. Это приводило к выполнению вредоносного кода в контексте системного процесса.
Для получения управления после перезагрузки применялся метод инфицирования системных компонентов ОС (драйверов). Для заражения использовался мини-порт/порт драйвер диска atapi.sys, в более поздних модификациях TDL-3 случайным образом выбирал и заражал системные драйверы, подходящие по некоторым параметрам. В драйвер atapi.sys внедрялся небольшой участок вредоносного кода размером 824 байт (917 байт для вариантов с случайными драйверами), который выполнял функции загрузчика, при этом исходный размер драйвера оставался неизменным. Исходные данные, которые замещались, сохранялись вместе с основным кодом в специально выделенном месте в конце жесткого диска. Последние несколько секторов диска организовывались в своеобразное зашифрованное хранилище данных со своей собственной файловой системой, для работы с ним создавалось виртуальное устройство. В этом хранилище так же располагались блоки данных конфигурации. TDL-3 перехватывал обращения к диску и, в случае просмотра его «личных» секторов, возвращал их содержимое в виде блока данных, заполненого нулями. Блок данных конфигурации (config.ini) неизменен для всех трех версий, он содержал следующие данные:
[main] — идентификационные данные
Quote — цитаты из кинофильмов, мультфильмов и т.д., которые выводятся при подключении отладчика;
Version — версия;
Botid — идентификатор бота для административной панели;
AffId — идентификатор «партнерской программы»;
SubId — служит для идентификации сети бота при разделении ботнета на несколько подсетей;
Installdate — дата установки в системе;
Builddate — дата компиляции.
[injector] — сопоставление внедряемых модулей и процессов
содержит список пар значений вида: имя процесса (по умолчанию “*”, означает все процессы) — имя DLL (динамической библиотеки, которую следует подгружать к указанному процессу).
[tdlcmd] — данные серверов
Servers — адреса административных панелей руткита, обычно три адреса;
Wspservers — адреса серверов для работы с поисковыми сервисами;
Popupservers — адреса серверов для открытия страниц;
Version — версия полезной нагрузки.
Распространение TDL осуществлялось при помощи так называемых «партнерских программ» или «партнерок». Согласно Википедии, «партнерская программа — это форма делового сотрудничества между продавцом и партнерами при продаже какого-либо товара или предоставлении услуг; позволяет продавцу сократить расходы на привлечение конечного покупателя». В сфере киберкриминала товаром являются вредоносные программы, а услугами — привлечение пользователей на зараженные веб-ресурсы и заражение их компьютеров. Деньги при этом платятся за каждую успешную установку. Именно для этого используется поле AffId в config.ini, для того, что бы знать, кому в каком объеме выплачивать деньги за установку бота с заданным идентификатором. Также это позволяет оценивать эффективность работы той или иной «партнерки». За содействие в распространении TDL владельцы «партнерок» получают за 1000 установок вредоносной программы от 20 до 200 USD — в зависимости от географического положения компьютера-жертвы. Конечная установка могла производиться различными способами, например путем установки фальшивых кодеков, путем внедрения бота в кейгены для популярного ПО, или распространение посредством cвязки эксплойтов (exploit pack).
Обмен данными с управляющим серверами TDL производился по протоколу HTTPS, для этого злоумышленниками использовался самоподписанный сертификат безопасности (который находился на сервере), выданный вымышленной компанией Internet Widgits Pty Ltd. Использование HTTPS не позволяло антивирусам детектировать и блокировать сетевой трафик по содержимому пакетов. Кроме того, в TDL-3 GET запросы дополнительно шифровались с использованием симметричного алгоритма RC4.
Основная цель TDL — монетизация, на основе созданного с его помощью ботнета. TDL имел модульную структуру и позволял загружать дополнительные модули (в виде DLL) по сети. Одним из модулей, устанавливаемый TDL по умолчанию, была библиотека tdlcmd.dll, выполняющая следующие задачи:
- получение и выполнение команд от центра управления;
- перехват пользовательских запросов к поисковым системам с целью подмены выдачи;
- создание заданных запросов к поисковым системам;
- эмуляция работы пользователя с сайтом.
Список команд, поддерживаемых tldcmd.dll:
- DownloadCrypted — загрузить зашифрованный файл;
- DownloadAndExecute — загрузить и исполнить файл;
- DownloadCryptedAndExecute — загрузить зашифрованный файл, расшифровать и исполнить его;
- Download — загрузить файл;
- ConfigWrite — внести изменения в файл конфигурации.
Перехват пользовательских запросов с целью подмены выдачи производился для популярных поисковых систем, таких как Google, Yahoo, Bing и др. При каждом запросе к таким сайтам tdlcmd.dll генерирует запрос к серверу, указанному в поле Wspservers файла конфигурации. В ответ от сервера приходит ссылка на страницу, которую необходимо отобразить пользователю. Ссылка может вести как на вредоносный сайт (например, для установки другого ВПО), так и на легитимный (накрутка баннеров).
Интересная функция tdlcmd.dll — механизм для недобросовестного «продвижения» сайтов по ключевым словам (Black Seo). Для его работы в хранилище TDK создается файл keywords, содержащий слова, которые необходимо адресовать поисковой системе. Затем в выдаче поисковой системы выбирается сайт, указанный злоумышленниками. При этом, для убедительной имитации работы пользователя, использовался JavaScript, встраиваемый в браузер и имитирующий нажатие на соответствующие элементы управления (кнопки, ссылки и т.д.).
Еще одним способом монетизации была продажа части ботнета, именно в этих целях в config.ini находился параметр SubId. Продаже подлежали подсети ботнета количеством до 20 000 компьютеров. В остальном свой преступный бизнес создатели TDL вели сами.
В феврале 2010 вышло неплановое обновление от Microsoft MS10-015. Данный патч устранял уязвимость, которая позволяет локально повысить свои привилегии, и вносил модификации непосредственно в ядро ОС. После этого патча некоторые пользователи стали жаловаться на появление BSOD. Позже выяснилось, что указанные компьютеры были заражены TDL-3 и BSOD вызывала его некорректная загрузка. Это связано с использованием неявных вызовов WinAPI функций по их смещению в памяти, при обновлении произошли модификации, в результате чего, адреса функций стали другими, и код TDL-3 перестал работать, как задумано. Из-за этой ошибки разработчиков численность ботнета значительно сократилась, особенно в США, где основная масса пользователей пользуется лицензионной Windows с включенным механизмом обновления (источник). Разработчики оперативно отреагировали выпуском TDL версии 3.26. Теперь вместо заражения заранее известного драйвера руткит заражал случайный драйвер, а поиск адресов функций ядра, используемых в этом коде, осуществлялся по контрольным суммам, подсчитанным от их имён. Шифрование хранилище сменилось на более простое с использованием однобайтовой операции XOR и увеличением значения этого байта, начальное значение 0x54 (источник).
Несмотря на некоторые уловки для защиты от потери управления, скрипты командного центра содержали в себе уязвимости, что позволило некоторым исследователям компьютерной безопасности успешно произвести взлом. Подробности одного из них доступны здесь. Согласно информации, полученной из баз данных взломанного сервера, общее количество компьютеров, заражённых руткитом TDL-3 в период с 12.08.2009 по 14.07.2010, составило более 16 000 000 компьютеров. Естественно, что это общее количество. Реально «живых» ботов было порядка 5 000 000. Большее их количество (43%), находилось в США. Это можно объяснить большей денежной отдачей от накрутки баннеров в этой стране.
Продолжение здесь.
