Обнаруженный Linux-бэкдор с низкой детекцией нацелен на построение командной инфраструктуры

Обнаруженный объект представляет собой статически скомпонованный исполняемый файл формата ELF для архитектуры x86-64 под управлением Linux. Бэкдор написан на C++ и, судя по набору функций и отсутствию некоторых возможностей, может находиться на стадии активной разработки. После запуска программа выполняет классическую технику двойного fork для демонизации процесса, перенаправляет стандартные потоки ввода-вывода в /dev/null и меняет текущую директорию на /tmp. Вредонос проверяет, был ли он вызван с аргументом -nodel. Если аргумент присутствует, запускается основная логика бэкдора; в противном случае программа удаляет саму себя с диска. Это делает образец сложным для анализа в изолированных средах и затрудняет сбор исполняемого файла после инцидента.

Конфигурация бэкдора встроена в секцию .data и зашифрована с использованием AES-128 в режиме GCM. Согласно анализу структуры зашифрованного блоба, первые 16 байт содержат ключ шифрования, следующие 12 - вектор инициализации (nonce), затем идут зашифрованные данные, и последние 16 байт - аутентификационная метка (tag). Для десериализации конфигурации применяется бинарный формат MessagePack. После расшифровки извлекаются такие параметры, как тип узла, размер баннера, таймауты соединения, количество одновременных подключений, задержка между опросами (sleep_delay), случайная вариация задержки (jitter) и список адресов командно-контрольного сервера.

После запуска бэкдор генерирует уникальный идентификатор заражённой системы на основе хеша SHA-1. В состав идентификатора входят фиксированная строка nginx, идентификатор машины из /etc/machine-id (с запасным вариантом /proc/sys/kernel/random/boot_id), имя пользователя из переменных окружения $USER и $LOGNAME, MAC-адрес первого нелокального сетевого интерфейса и фиксированная строка reverse. Из полученного 20-байтового хеша извлекаются только первые 4 байта с преобразованием порядка байтов (byteswap). Такой подход позволяет сопоставлять действия одного и того же хоста при повторных регистрациях.

Затем вредонос генерирует случайный сессионный ключ AES-128 и выполняет профилирование заражённого хоста. Собираются следующие данные: имя процесса (из /proc/self/exe, с запасным значением agent), идентификатор процесса (PID), имя пользователя (через /etc/passwd или переменные окружения), имя хоста (системный вызов uname), IP-адрес (создаётся UDP-сокет с фиктивным адресом 8.8.8.8, затем выполняется connect и getsockname, при ошибке - 127.0.0.1), флаг наличия привилегий root (UID равен нулю), тип ОС (всегда linux) и версия ОС (парсинг /etc/os-release с запасными вариантами uname и строка "Linux").

После сбора профиля бэкдор формирует регистрационный бекон, который сериализуется в MessagePack. Сообщение состоит из двух вложенных словарей: внешний содержит идентификатор хоста, тип узла (из конфигурации) и внутренний словарь (data). Внутренний словарь включает все собранные данные профиля, а также три дополнительных поля: acp, oem и rootkit_scheme - все три установлены в 0. Назначение этих полей точно не определено, но есть предположение, что они могут относиться к версии бэкдора для Windows, где acp соответствует функции GetACP (кодовая страница ANSI), а oem - GetOEMCP. Регистрационное сообщение шифруется конфигурационным ключом AES-128, который известен командно-контрольному серверу, и отправляется на C2. Сессионный ключ передаётся внутри этого же зашифрованного сообщения.

После успешной регистрации бэкдор входит в цикл ожидания команд от C2. Входящие сообщения расшифровываются сессионным ключом и десериализуются. Извлекаются поля code (код команды), id (идентификатор для сопоставления команд и ответов) и data (дополнительные данные, например, командная строка). Бэкдор поддерживает более 30 команд, охватывающих практически все аспекты удалённого управления: получение и смена текущей директории, выполнение произвольных программ с аргументами, завершение работы агента, эксфильтрация файлов (в том числе крупных с разбивкой на блоки), запись файлов на диск с возможностью распаковки ZIP, чтение и копирование файлов, создание и удаление каталогов, удаление файлов через rm -rf, листинг директорий (аналог ls -la), листинг процессов (аналог ps aux), завершение процессов по PID, сжатие ZIP, получение скриншота (команда возвращает "screenshot not supported"), выполнение программы с полным псевдотерминалом (PTY) для интерактивного доступа, управление асинхронными заданиями, изменение задержки опроса, подмена временных меток файлов (timestomping), изменение прав доступа, переименование файлов, создание и запись файлов, обратный проброс порта (reverse port forward) для туннелирования трафика через заражённый хост, закрытие таких туннелей, интерактивное выполнение программ с PTY, передача данных через установленный туннель, соединение с одноранговым узлом (peer), разрыв такого соединения, открытие и закрытие слушающего сокета на всех интерфейсах (потенциально для внешнего доступа), перечисление корневой директории.

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

Domain Port Combination

• iot.981666.xyz:8080

URL

• https://zapier-logos.s3.amazonaws.com/gregbfdah.png

SHA256

• f264f04f597a2bdda372a27ae701c18d4036175b1eb8722db5f8531615b38788