Новый ZeroAccess: хроники внедрения кода

В конце весны текущего года произошло обновление семейства Win32/Sirefef и Win64/Sirefef, так же известных под именем ZeroAccess. Мы отследили появление новых модификаций в начале мая, примерно в это же время стартовала новая партнерская программа (PPI) по распространению ZeroAccess. Обновленная версия не содержит системных драйверов и скрытого хранилища для хранения файлов. Сначала разработчики в предыдущей версии избавились от драйвера для версии Win64/Sirefef, а теперь и для всего семейства целиком.  Как и в предыдущих версиях для монетизации используется схема по подмене поискового трафика в популярных поисковиках. Объявление призывающая участвовать в новой партнерской программе, размещенное на закрытом форуме verified.ms, выглядит следующем образом:

Авторы приведенного выше объявления особенно отмечают регионы US, Australia, Canada и United Kingdom, за которые готовы платить наибольший профит. Еще больше меня заинтересовала зависимость оплаты от системы на которой закрепился бот.

Панель со статистикой выглядит следующим образом:

Так же используется проверка на АВ-детект сразу после перепаковки нового дроппера:

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

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

Итак, обо всем по порядку, как работает схема инжекта в новом ZeroAccess:

1) На первом шаге извлекается шелл-код (x86/x64 в зависимости от платформы) из cab-файла, хранящегося в теле дроппера:

2) Далее создается скрытая директория, путь к которой зависит от выбранного метода внедрения в системный процесс. Ранее для этих целей использовалась скрытая файловая система. Варианты возможных директорий выглядят следующим образом:

"%USERPROFILE%\Local Settings\Application Data\

"%WINDOWS%\Installer\

3) На следующем шаге шелл-код внедряется в системный процесс services.exe (Service Control Manager). Граф вызовов функций этого шелл-кода выглядит так:

А псевдокод функции, которая осуществляет непосредственно внедрение кода, выглядит следующим образом:

4) В исследуемой версии ZeroAccess используется два типа внедрения кода:

• Первый использует прямую модификацию памяти процесса посредством получение доступа к нему через ZwOpenThread()/ZwOpenProcess() и внедрения кода через трюк с ZwQueueApcThread(). Этот способ используется для внедрения на х86 системах и в том случае, если другой способ отработал некорректно.
• Второй способ используется на х64 битных ситемах и осуществляет модификацию  services.exe, после изменения дескриптора безопасности.

Далее происходит непосредственно внедрение кода, создается объект секция при помощи вызова ZwCreateSection() и содержимое файла копируется туда. После этого вносятся изменения в функцию ScRegisterTCPEndpoint(). Удаляется поддержка редомизации адресного пространства ASLR, путем модификации PE-заголовка (эти изменения необходимы для стабильной работы шелл-кода с заранее заданными адресами).

Некоторые из последних модификаций осуществляют манипуляции с секцией перемещаемых элементов (.reloc) и создается Thread Local Storage (TLS) callback. О чем уже было сказано здесь.

5) На финальной стадии модификации создается файл с таким же именем services.exe, но только уже модифицированный. Новый файл создается при помощи вызова ZwCreateFile() с заполненными атрибутами NTFS extended. Полезная нагрузка из вредоносного кода не хранится непосредственно в файле services.exe, но загружается с использованием особой магии NTFS. Вся информация о файле (время создания, атрибуты и прочее) сохраняется полностью идентично оригинальному файлу. Внедренный шел-код на третьем шаге ищет расширенный атрибут "731" и получает к нему доступ через вызов ZwQueryEaFile(), после чего происходит выполнение полезной нагрузки. Следующий уровень шелл-кода находит вредоносный dll-модуль и подготавливает точку входа и выполет этот модуль. Граф вызова функций этого шелл-кода выглядит следующим образом:  

Антивирусные продукты ESET обнаруживают модифицированный файл и процесс services.exe, как Win64/Patched.B.Gen. Изменения в services.exe выглядят следующим образом (с лева оригинальный файл, справа модифицированный):

Изменения в коде в функции ScRegisterTCPEndpoint():

Статистика обнаружения по регионам от начала этого года для всех модификаций ZeroAccess, полученная пари помощи облачной технологии ESET LiveGrid®, выглядит следующим образом:

 

Статистика по количеству детектов Win64/Sirefef выглядит так:

На графике видно, что после обновления и перехода на user-mode стали расти инсталляции 64-битной версии руткита.

А, так выглядит статистика детектов Win64/Sirefef + Win32/Sirefef: 

До недавнего времени существование руткитов для 64-битных платформ обуславливалось наличием буткит части, которая осуществляла обход системных проверок цифровой подписи. Но на примере ZeroAccess мы видим, что в пользовательском режиме еще существуют трюки, которые позволяют оставаться незамеченными в системе и усложнять обнаружение защитным софтом.