В феврале 2013 г. появилась информация о новом рутките Avatar, которая, судя по-всему, имеет происхождение с одного из подпольных форумов. В частности, на сервисе pastebin было опубликовано описание его возможностей. Информация о новом рутките горячо обсуждалась в security-сообществе, поскольку описываемые возможности этого руткита действительно впечатлали. Среди них, например, возможности загрузки драйвера без участия жесткого диска, заражение бут-драйверов ОС, новые схемы защиты ботнета и другие. Также заявлялся обход нескольких security/AV-продуктов и известных антируткитов.
Когда нами были найдены дропперы этого руткита, мы сразу же приступили к его анализу. Нужно сказать, что он был добавлен нами в базу как Win32/Rootkit.Avatar. Коллеги Антон Черепанов и Александр Матросов проделали детальный анализ этого руткита, его полезной нагрузки и основных возможностей.
В марте наша антивирусная лаборатория обнаружила два дроппера, которые взаимодействовали с различными C&C серверами и имели разные даты компиляции.
Как упоминалось в объявлении, Win32/Rootkit.Avatar содержит в себе инфектор драйверов, но кроме этого, он использует эту технику дважды: во-первых в дроппере, чтобы обойти обнаружения со стороны HIPS и во-вторых в драйвере, для выживания после перезагрузки. В первом случае используется преимущество загрузки драйвера руткита непосредственно из режима ядра с привлечением стандартного драйвера ОС, а во втором случае руткит обеспечивает свой запуск после перезагрузки. Разумеется такая тактика имеет недостатки с точки зрения нарушения целостности файла и контроля целостности со стороны проверки цифровой подписи для драйверов, поэтому руткит может работать только в x86 системах.
Дропперы
Avatar использует подход на основе дропперов, состоящих из нескольких уровней. Дроппер первого уровня осуществляет декомпрессию (LZMA) для дроппера второго уровня и драйвера. Фактически, дроппер второго уровня и сам драйвер представляют из себя уникальные файлы, генерируемые какждый раз при распаковке, поскольку начальный дроппер генерирует случайные имена для мьютексов и событий, которые используются в их коде и выполняет эти модификации непосредственно в теле каждого из модулей. Начальный дроппер использует интересный трюк в качестве анти-отладки, он основан на сравнении времени из структуры KUSER_SHARED_DATA.InterruptTime (KUSER_SHARED_DATA располагается на странице, доступной как в пользовательском режиме, так и в режиме ядра). Вредоносный код выполняет модификацию вызова функции RtlDispatchException внутри другой функции KiUserExceptionDispatcher. На следующем шаге генерируется иключение и управление переходит к нужному обработчику исключения.
При этом текущее время для замера берется из KUSER_SHARED_DATA.InterruptTime и далее сравнивается на последующих этапах исполнения. Этот механизм позволяет обнаруживать эмуляцию и отладку кода дроппера.
Дроппер второго уровня проверяет окружение на предмет виртуальных машин, при этом для этого используются довольно известные проверки. Перед тем как исполнить код, отвечающий за проверку на VM, дроппер расшифровывает его с использованием ключа “explorer”.
На следующем шаге дроппер выполняет проверку версии ОС и текущих привилегий. При этом используются два метода повышения привилегий:
Процесс заражения системы дроппером представлен на диаграме ниже.
Эксплойт для уязвимости MS11-080 использует код, схожий с кодом эксплойта из Metasploit Framework, но с некоторыми незначительными изменениями. После проверки версии драйвера afd.sys, дроппер использует следующий код для эксплуатации.
На следующем скриншоте представлен код, который с использованием IOCTL 0x000120BB вызывает функцию afd!AFDJoinLeaf для перезаписи указателя в HalDispatchTableна нужную руткиту функцию.
После успешной эксплуатации и передачи управления на шелл-код, он инициирует загрузку драйвера руткита.
Фактически, драйвер руткита не хранится на диске отдельным файлом, а загружается из буфера памяти. Ниже представлен граф вызовов для функции, которая загружает драйвер.
После успешного повышения привилегий, вредоносный код осуществляет поиск подходящего драйвера для заражения в каталоге %WINDIR%\system32\drivers. После того, как заражение было выполнено, точка входа в драйвер (GsDriverEntry) модифицируется для исполнения вредоносного кода (заглушка). Модифицированная точка входа выглядит следующим образом:
Одна из основных задач этой заглушки, подключиться к процессу исполнения дроппера второго уровня и прочитать тело драйвера руткита в память. Код заглушки представлен на рисунке ниже.
После успешного заражения, модифицированный драйвер копирует себя в каталог %TEMP% и пытается загрузить себя с использованием стандартных механизмов ОС (через диспетчер управления сервисами или напрямую через ZwLoadDriver).
Таким образом, файл драйвера руткита Avatar действительно не хранится на жестком диске, а будет загружен кодом, который вызывается путем эксплуатации MS11-080. Такой метод загрузки руткита, с использованием заражения системного драйвера, является эффективным методом обхода HIPS и позволяет загружать другой модуль режима ядра из доверенного системного драйвера.
Драйвер
После того как драйвер успешно загружен в память, вредоносный код выполняет заражение системного драйвера уже с целью обеспечить свою выживаемость после перезагрузки. Для выбора нужного драйвера используется специальный алгоритм. При этом Avatar случайным образом выбирает драйвер и проверяет его имя по черному списку, специфичному для разных версий ОС.
Поток исполнения кода зараженного драйвера происходит по следующему сценарию:
1. В точке входа исполняется заглушка.
2. Затем происходит установка callback-функции Pnp Notify для класса GUID_DEVINTERFACE_DISK, в которой произойдет загрузка тела драйвера из скрытой файловой системы руткита. Подобная техника наблюдалась в TDL3, TDL4 и Olmasco (MaxSS/SST).
3. Происходит восстановление исходных байт точки входа.
Драйвер руткита способен заразить несколько системных драйверов, не меняя исходный размер оригинального файла.
Avatar использует интересный прием для обнаружения среды виртуальной машины. Он вызывает функцию nt!MmMapIoSpace для чтения данных BIOS по адресу 0xF0000 и проверяет присутствие следующих строк:
Также в коде присутствуют дополнительные проверки для KVM и Hyper-V с использованием уже известных трюков инструкции CPUID.
Скрытая FS используется для хранения полезной нагрузки пользовательского режима и вспомогательных файлов. Все файлы зашифрованы с использованием симметричного алгоритма. Ниже показан граф вызовов для функции, которая работает со скрытой FS.
Существуют специальные атрибуты для файлов, хранящихся на скрытой FS.
Вредоносный код допускает загрузку из сети и дальнейшее исполнение дополнительной полезной нагрузки в виде модулей пользовательского режима и режима ядра. Такая полезная нагрузка также хранится на скрытой FS. Win32/Rootkit.Avatar не хранит ни один из своих компонентов на томе NTFS, за исключением зараженного системного драйвера. Такое сочетание скрытой, зашифрованной FS, наряду с зараженным системным драйвером делает более сложным использование обычных методов криминалистической экспертизы для расследования случаев заражения Avatar.
Для внедрения полезной нагрузки пользовательского режима используется функция KeInitializeApc для инициализации объекта APC, который затем используется для исполнения требуемой функции руткита.
Полезная нагрузка
Полезная нагрузка исследуемой модификации руткита Avatar не отличается оригинальностью. Основные возможности:
При исследовании этой модификации руткита, мы заметили, что полезная нагрузка в виде avcmd.dll была внедрена в системный процесс svchost.exe. Этот модуль отвечает за работу с C&C, IP-адреса которых хранятся в файле конфигурации. Этот файл имеет следующую структуру.
Примеры расшифрованной конфигурационной информации из двух различных дропперов приведены ниже.
Для ботнета с идентификатором BTN1.
Для ботнета с идентификатором NET1.
В целях защиты взаимодействия с C&C, Avatar использует свой собственный алгоритм шифрования с применением base64. В то же время все сетевое взаимодействие в пользовательском режиме осуществляется с использованием обычных функций WinInet API.
Avatar также обладает дополнительным способом общения с C&C, если при использовании других способов возникают проблемы. Он пытается искать сообщения в группах Yahoo с использованием специальных параметров.
Осуществляется поиск последовательности на основе следующих параметров (в нашем случае это 17BTN1 и 17NET1).
После того как эти строки будут соединены, полученная байтовая последовательность шифруется с помощью собственного алгоритма с применением 1024-битного ключа из конфигурационного файла.
BTN1 key = 6mQ98EXP3v7TKMdk704uOUzGqvikuoHt98n8IPp4K19
a3qyZ96LoOc54sb3g9eJVyAs7VmPxQjkkM9R960ev275K24PQ550K1
9fNk8305jRDUTb4cEut4579Zg9i32qU
NET1 key = E623J5XKJ9NF4bseM5J2nkwhs1K2766DUOMUDSee3c
7xu06Q9QayV61U4fm5H89ppuNgLt9M5D2XTCLcd0aS3m9CO1aZg9h9
o2zb2EIC437IU3X1P3ec07481E0j2Tdr
После шифрования к полученной последовательности применяется base64 и затем буквы переводятся в верхний регистр, при этом некоторые символы отфильтровываются. Пример для ботнета с идентификатором BTN1 показан ниже.
SymFilter(UpperCase(Base64(Encrypt(17BTN1)))) = EZTFDHWP
Строка EZTFDHWP используется для последующего поиского запроса для группы Yahoo. Если такой запрос выполнен успешно, следующим шагом будет проверка номеров найденной группы и чтение ее данных описания.
Далее описание группы шифруется с использованием RSA и 1024-битного приватного ключа. Такие данные можно расшифровать зная публичный ключ, хранящийся в файле конфигурации. Мы полагаем, что эта информация может быть найдена в зашифрованных сообщениях, используемых для возврата управления ботнету при отсутствии активных C&C серверов.
После нахождения этой функции, мы проверили возможные такие сообщения на Yahoo Groups. Была обнаружена одна группа, подпадающая под заданные параметры (11BTN1 = EFS9KHRF). Поисковый запрос выглядит так:
hxxp://groups.yahoo.com/search?query=EFS9KHRF&sort=relevance
Видно, что зашифрованное сообщение присутствует в описании этой группы.
Мы расшифровали это сообщение с использованием RSA-1024 ключа, найденным в одном из файлов конфигурации. При этом использовался ключ от файла конфигурации с идентификатором ботнета BTN1.
dZ8FsJ4z0::http://www.avatarbut.info www.avatarsbut.info
Эта информация похожа на один из URL для C&C, который мы видели в самом файле конфигурации BTN1. Похоже на то, что эта группа использовалась киберпреступниками для обката этого способа взаимодействия, поскольку она включает в себя информацию из самого файла конфигурации.
Такая схема поддержания ботнета с использованием сообщения в группах Yahoo обеспечивает отличную защиту от попыток синхолинга ботнета, поскольку информация о доменах серверов C&C шифруется с использованием ассиметричного алгоритма шифрования, основанного на RSA. В процессе исследования ресерчеры могут извлечь только публичный ключ для расшифровки сообщений, но этот ключ не может быть использован для шифрования новых сообщений и создания фиктивных групп.
Avatar Runtime Library
Вредоносный код Win32/Rootkit.Avatar имеет специальный API для разработки вспомогательных компонентов. Использование этого API основано на библиотеке Avatar Runtime Library и специальном SDK, которое описывает разработку дополнительных модулей пользовательского режима. Эти модули также могут взаимодействовать с драйвером руткита. Библиотека Avatar Runtime Library включает следующие API:
Структура хранения полезной нагрузки, которая будет внедряться в процессы выглядит так.
После анализа Avatar SDK мы сделали вывод, что данный проект развивался довольно квалифицированными разработчиками. Очевидно, что разработчики вредоносного кода работали над кодом руткита не менее полугода для того, чтобы протестировать основной функционал и обеспечить нужную стабильность компонента режима ядра.
Заключение
Семейство руткитов Win32/Rootkit.Avatar содержит интересные техники для обхода обнаружения с точки зрения AV-продуктов. Руткит Avatar, наряду с буткитом Gapz может быть использован для обеспечения длительной по времени инфекции системы. Avatar не хранит свои файлы на обычном томе, а использует для этого свой скрытый FS, кроме того он использует технику заражения стандартных драйверов, что является более сложным случаем для расследования, с точки зрения проведения криминалистической экспертизы.
Угроза также имеет дополнительные пути поддержания управления над ботнетом, если командные C&C серверы недоступны. Для полной дезинфекции зараженной системы, прежде всего необходимо деактивировать драйвер руткита и его полезную нагрузку пользовательского режима и уже после этого пытаться восстановить зараженный системный драйвер.
Когда нами были найдены дропперы этого руткита, мы сразу же приступили к его анализу. Нужно сказать, что он был добавлен нами в базу как Win32/Rootkit.Avatar. Коллеги Антон Черепанов и Александр Матросов проделали детальный анализ этого руткита, его полезной нагрузки и основных возможностей.
В марте наша антивирусная лаборатория обнаружила два дроппера, которые взаимодействовали с различными C&C серверами и имели разные даты компиляции.
Как упоминалось в объявлении, Win32/Rootkit.Avatar содержит в себе инфектор драйверов, но кроме этого, он использует эту технику дважды: во-первых в дроппере, чтобы обойти обнаружения со стороны HIPS и во-вторых в драйвере, для выживания после перезагрузки. В первом случае используется преимущество загрузки драйвера руткита непосредственно из режима ядра с привлечением стандартного драйвера ОС, а во втором случае руткит обеспечивает свой запуск после перезагрузки. Разумеется такая тактика имеет недостатки с точки зрения нарушения целостности файла и контроля целостности со стороны проверки цифровой подписи для драйверов, поэтому руткит может работать только в x86 системах.
Дропперы
Avatar использует подход на основе дропперов, состоящих из нескольких уровней. Дроппер первого уровня осуществляет декомпрессию (LZMA) для дроппера второго уровня и драйвера. Фактически, дроппер второго уровня и сам драйвер представляют из себя уникальные файлы, генерируемые какждый раз при распаковке, поскольку начальный дроппер генерирует случайные имена для мьютексов и событий, которые используются в их коде и выполняет эти модификации непосредственно в теле каждого из модулей. Начальный дроппер использует интересный трюк в качестве анти-отладки, он основан на сравнении времени из структуры KUSER_SHARED_DATA.InterruptTime (KUSER_SHARED_DATA располагается на странице, доступной как в пользовательском режиме, так и в режиме ядра). Вредоносный код выполняет модификацию вызова функции RtlDispatchException внутри другой функции KiUserExceptionDispatcher. На следующем шаге генерируется иключение и управление переходит к нужному обработчику исключения.
При этом текущее время для замера берется из KUSER_SHARED_DATA.InterruptTime и далее сравнивается на последующих этапах исполнения. Этот механизм позволяет обнаруживать эмуляцию и отладку кода дроппера.
Дроппер второго уровня проверяет окружение на предмет виртуальных машин, при этом для этого используются довольно известные проверки. Перед тем как исполнить код, отвечающий за проверку на VM, дроппер расшифровывает его с использованием ключа “explorer”.
На следующем шаге дроппер выполняет проверку версии ОС и текущих привилегий. При этом используются два метода повышения привилегий:
- Эксплуатирование уязвимости MS11-080.
- COM Elevation (UAC whitelist).
Процесс заражения системы дроппером представлен на диаграме ниже.
Эксплойт для уязвимости MS11-080 использует код, схожий с кодом эксплойта из Metasploit Framework, но с некоторыми незначительными изменениями. После проверки версии драйвера afd.sys, дроппер использует следующий код для эксплуатации.
На следующем скриншоте представлен код, который с использованием IOCTL 0x000120BB вызывает функцию afd!AFDJoinLeaf для перезаписи указателя в HalDispatchTableна нужную руткиту функцию.
После успешной эксплуатации и передачи управления на шелл-код, он инициирует загрузку драйвера руткита.
Фактически, драйвер руткита не хранится на диске отдельным файлом, а загружается из буфера памяти. Ниже представлен граф вызовов для функции, которая загружает драйвер.
После успешного повышения привилегий, вредоносный код осуществляет поиск подходящего драйвера для заражения в каталоге %WINDIR%\system32\drivers. После того, как заражение было выполнено, точка входа в драйвер (GsDriverEntry) модифицируется для исполнения вредоносного кода (заглушка). Модифицированная точка входа выглядит следующим образом:
Одна из основных задач этой заглушки, подключиться к процессу исполнения дроппера второго уровня и прочитать тело драйвера руткита в память. Код заглушки представлен на рисунке ниже.
После успешного заражения, модифицированный драйвер копирует себя в каталог %TEMP% и пытается загрузить себя с использованием стандартных механизмов ОС (через диспетчер управления сервисами или напрямую через ZwLoadDriver).
Таким образом, файл драйвера руткита Avatar действительно не хранится на жестком диске, а будет загружен кодом, который вызывается путем эксплуатации MS11-080. Такой метод загрузки руткита, с использованием заражения системного драйвера, является эффективным методом обхода HIPS и позволяет загружать другой модуль режима ядра из доверенного системного драйвера.
Драйвер
После того как драйвер успешно загружен в память, вредоносный код выполняет заражение системного драйвера уже с целью обеспечить свою выживаемость после перезагрузки. Для выбора нужного драйвера используется специальный алгоритм. При этом Avatar случайным образом выбирает драйвер и проверяет его имя по черному списку, специфичному для разных версий ОС.
Поток исполнения кода зараженного драйвера происходит по следующему сценарию:
1. В точке входа исполняется заглушка.
2. Затем происходит установка callback-функции Pnp Notify для класса GUID_DEVINTERFACE_DISK, в которой произойдет загрузка тела драйвера из скрытой файловой системы руткита. Подобная техника наблюдалась в TDL3, TDL4 и Olmasco (MaxSS/SST).
3. Происходит восстановление исходных байт точки входа.
Драйвер руткита способен заразить несколько системных драйверов, не меняя исходный размер оригинального файла.
Avatar использует интересный прием для обнаружения среды виртуальной машины. Он вызывает функцию nt!MmMapIoSpace для чтения данных BIOS по адресу 0xF0000 и проверяет присутствие следующих строк:
- Parallels Software
- Virtual Machine
- VirtualBox
- QEMU BIOS
- VMware
- Bochs
Также в коде присутствуют дополнительные проверки для KVM и Hyper-V с использованием уже известных трюков инструкции CPUID.
Скрытая FS используется для хранения полезной нагрузки пользовательского режима и вспомогательных файлов. Все файлы зашифрованы с использованием симметричного алгоритма. Ниже показан граф вызовов для функции, которая работает со скрытой FS.
Существуют специальные атрибуты для файлов, хранящихся на скрытой FS.
Вредоносный код допускает загрузку из сети и дальнейшее исполнение дополнительной полезной нагрузки в виде модулей пользовательского режима и режима ядра. Такая полезная нагрузка также хранится на скрытой FS. Win32/Rootkit.Avatar не хранит ни один из своих компонентов на томе NTFS, за исключением зараженного системного драйвера. Такое сочетание скрытой, зашифрованной FS, наряду с зараженным системным драйвером делает более сложным использование обычных методов криминалистической экспертизы для расследования случаев заражения Avatar.
Для внедрения полезной нагрузки пользовательского режима используется функция KeInitializeApc для инициализации объекта APC, который затем используется для исполнения требуемой функции руткита.
Полезная нагрузка
Полезная нагрузка исследуемой модификации руткита Avatar не отличается оригинальностью. Основные возможности:
- Взаимодействие с командным C&C.
- Разбор информации о конфигурации.
- Работа со скрытой FS.
- Взаимодействие с драйвером руткита.
- Установка в систему полезной нагрузки.
При исследовании этой модификации руткита, мы заметили, что полезная нагрузка в виде avcmd.dll была внедрена в системный процесс svchost.exe. Этот модуль отвечает за работу с C&C, IP-адреса которых хранятся в файле конфигурации. Этот файл имеет следующую структуру.
- Идентификатор (название) ботнета.
- URL командных серверов C&C.
- 1024-битный ключ для алгоритма шифрования.
- Публичный ключ для RSA-1024.
- Имена процессов для внедрения полезной нагрузки.
Примеры расшифрованной конфигурационной информации из двух различных дропперов приведены ниже.
Для ботнета с идентификатором BTN1.
Для ботнета с идентификатором NET1.
В целях защиты взаимодействия с C&C, Avatar использует свой собственный алгоритм шифрования с применением base64. В то же время все сетевое взаимодействие в пользовательском режиме осуществляется с использованием обычных функций WinInet API.
Avatar также обладает дополнительным способом общения с C&C, если при использовании других способов возникают проблемы. Он пытается искать сообщения в группах Yahoo с использованием специальных параметров.
Осуществляется поиск последовательности на основе следующих параметров (в нашем случае это 17BTN1 и 17NET1).
После того как эти строки будут соединены, полученная байтовая последовательность шифруется с помощью собственного алгоритма с применением 1024-битного ключа из конфигурационного файла.
BTN1 key = 6mQ98EXP3v7TKMdk704uOUzGqvikuoHt98n8IPp4K19
a3qyZ96LoOc54sb3g9eJVyAs7VmPxQjkkM9R960ev275K24PQ550K1
9fNk8305jRDUTb4cEut4579Zg9i32qU
NET1 key = E623J5XKJ9NF4bseM5J2nkwhs1K2766DUOMUDSee3c
7xu06Q9QayV61U4fm5H89ppuNgLt9M5D2XTCLcd0aS3m9CO1aZg9h9
o2zb2EIC437IU3X1P3ec07481E0j2Tdr
После шифрования к полученной последовательности применяется base64 и затем буквы переводятся в верхний регистр, при этом некоторые символы отфильтровываются. Пример для ботнета с идентификатором BTN1 показан ниже.
SymFilter(UpperCase(Base64(Encrypt(17BTN1)))) = EZTFDHWP
Строка EZTFDHWP используется для последующего поиского запроса для группы Yahoo. Если такой запрос выполнен успешно, следующим шагом будет проверка номеров найденной группы и чтение ее данных описания.
Далее описание группы шифруется с использованием RSA и 1024-битного приватного ключа. Такие данные можно расшифровать зная публичный ключ, хранящийся в файле конфигурации. Мы полагаем, что эта информация может быть найдена в зашифрованных сообщениях, используемых для возврата управления ботнету при отсутствии активных C&C серверов.
После нахождения этой функции, мы проверили возможные такие сообщения на Yahoo Groups. Была обнаружена одна группа, подпадающая под заданные параметры (11BTN1 = EFS9KHRF). Поисковый запрос выглядит так:
hxxp://groups.yahoo.com/search?query=EFS9KHRF&sort=relevance
Видно, что зашифрованное сообщение присутствует в описании этой группы.
Мы расшифровали это сообщение с использованием RSA-1024 ключа, найденным в одном из файлов конфигурации. При этом использовался ключ от файла конфигурации с идентификатором ботнета BTN1.
dZ8FsJ4z0::http://www.avatarbut.info www.avatarsbut.info
Эта информация похожа на один из URL для C&C, который мы видели в самом файле конфигурации BTN1. Похоже на то, что эта группа использовалась киберпреступниками для обката этого способа взаимодействия, поскольку она включает в себя информацию из самого файла конфигурации.
Такая схема поддержания ботнета с использованием сообщения в группах Yahoo обеспечивает отличную защиту от попыток синхолинга ботнета, поскольку информация о доменах серверов C&C шифруется с использованием ассиметричного алгоритма шифрования, основанного на RSA. В процессе исследования ресерчеры могут извлечь только публичный ключ для расшифровки сообщений, но этот ключ не может быть использован для шифрования новых сообщений и создания фиктивных групп.
Avatar Runtime Library
Вредоносный код Win32/Rootkit.Avatar имеет специальный API для разработки вспомогательных компонентов. Использование этого API основано на библиотеке Avatar Runtime Library и специальном SDK, которое описывает разработку дополнительных модулей пользовательского режима. Эти модули также могут взаимодействовать с драйвером руткита. Библиотека Avatar Runtime Library включает следующие API:
- aTakeProcessToken — присвоить маркер доступа (access token) одного процесса другому.
- aExecute — выполнить модуль в контексте удаленного процесса.
- aLoadDriver — загрузить драйвер с расположения скрытой FS.
- aLoadFileFromAvatarDisk — прочитать файла из скрытой FS.
- aSaveFileOrAttrToAvatarDisk — записать файл в скрытую FS.
- aSendReport — отправить информацию на удаленный C&C.
Структура хранения полезной нагрузки, которая будет внедряться в процессы выглядит так.
После анализа Avatar SDK мы сделали вывод, что данный проект развивался довольно квалифицированными разработчиками. Очевидно, что разработчики вредоносного кода работали над кодом руткита не менее полугода для того, чтобы протестировать основной функционал и обеспечить нужную стабильность компонента режима ядра.
Заключение
Семейство руткитов Win32/Rootkit.Avatar содержит интересные техники для обхода обнаружения с точки зрения AV-продуктов. Руткит Avatar, наряду с буткитом Gapz может быть использован для обеспечения длительной по времени инфекции системы. Avatar не хранит свои файлы на обычном томе, а использует для этого свой скрытый FS, кроме того он использует технику заражения стандартных драйверов, что является более сложным случаем для расследования, с точки зрения проведения криминалистической экспертизы.
Угроза также имеет дополнительные пути поддержания управления над ботнетом, если командные C&C серверы недоступны. Для полной дезинфекции зараженной системы, прежде всего необходимо деактивировать драйвер руткита и его полезную нагрузку пользовательского режима и уже после этого пытаться восстановить зараженный системный драйвер.
