May 30

XORDDoS: Анатомия угрозы для Linux-инфраструктур

Происхождение и контекст угрозы

Исследовательская группа MalwareMustDie зафиксировала XORDDoS в сентябре 2014 года — и с тех пор этот троян так и не утратил своей актуальности. Название отражает двойственную природу вредоноса: XOR — криптографический примитив, лежащий в основе всей его внутренней логики, DDoS — конечная цель операторов. По своей сути это многоплатформенный Linux-троян с руткитом уровня ядра, спроектированный для формирования ботнетов и организации разрушительных распределённых атак типа «отказ в обслуживании».

Почему Linux, а не Windows?

Linux формирует основу современной облачной инфраструктуры, корпоративных веб-сервисов и колоссального парка устройств IoT. Эти системы исторически администрируются менее строго, чем рабочие станции: SSH часто открыт наружу, пароли не ротируются, обновления выходят с опозданием. Злоумышленники получают не рабочие станции с ограниченными ресурсами, а мощные серверы или тысячи IoT-узлов для генерации колоссальных объёмов мусорного трафика.

Тревожная деталь: по данным Microsoft, за шесть месяцев активность XORDDoS возросла на 254%. Вредонос не просто выживает — он эволюционирует. Авторы внедряют полиморфизм для обхода сигнатурных анализаторов, совершенствуют антифорензику и расширяют векторы заражения с SSH-брутфорса до атак на открытые API Docker. XORDDoS всё чаще служит первичным вектором для развёртывания Tsunami-бэкдора и скрытых криптомайнеров XMRig, превращая скомпрометированный сервер в многофункциональный инструмент монетизации.

Архитектура трояна обеспечивает его работу на процессорах x86 (32-бит), x64 (64-бит) и ARM, что даёт операторам ботнета универсальный охват: от высокопроизводительных облачных серверов до маломощных сетевых хранилищ и маршрутизаторов.


XOR как системообразующий примитив

Побитовая операция XOR (исключающее ИЛИ) выбрана авторами не случайно: она обратима, вычислительно дешева и достаточна для обхода большинства средств статического анализа. Жёстко закодированный ключ:

BB2FA36AAA9541F0

применяется в трёх критически важных контекстах.

Обфускация кода и конфигурации. Все внутренние строки трояна — доменные имена C2-серверов, конфигурационные параметры, списки целей — хранятся в зашифрованном виде прямо в бинарном файле. Расшифровка происходит исключительно в оперативной памяти в момент выполнения. Статический анализатор или антивирус, сканирующий файл на диске, не найдёт ни одной читаемой строки, указывающей на вредоносную природу объекта.

Телеметрия и идентификация бота. При первом запуске троян генерирует (или считывает из /var/run/gcc.pid и /var/run/sftp.pid) уникальную 32-байтную «магическую строку» — идентификатор устройства в ботнете. Затем собирается системная телеметрия: версия ОС, версия вредоноса, статус руткита, объём RAM, данные о CPU, скорость сетевого интерфейса. Перед отправкой вычисляется CRC для контроля целостности, после чего весь пакет шифруется ключом XOR.

Двусторонний C2-канал. Весь трафик между ботом и командным сервером защищён тем же XOR-ключом. Сервер присылает зашифрованные пакеты команд с заголовком размером 0x1C байт; бот расшифровывает их в памяти и исполняет.


Вектор проникновения: SSH-брутфорс

Основной сценарий компрометации строится на атаке методом перебора паролей (brute force) по протоколу SSH. Выбор вектора обусловлен тем, что SSH используется повсеместно для удалённого администрирования, а порт 22 на огромном количестве серверов открыт без каких-либо ограничений доступа.

Операция разворачивается поэтапно. Сначала автоматизированные сканеры прощупывают сетевые диапазоны в поисках серверов с доступным извне портом 22. Перед непосредственным перебором паролей атакующие нередко отправляют HTTP-запросы для выявления уязвимостей обхода директорий (directory traversal). Эксплуатируя такую уязвимость, они читают /etc/passwd — не для получения паролей (они хранятся в shadow-файлах), а для извлечения реального списка имён пользователей. Точные логины резко повышают эффективность последующего брутфорса.

Масштаб атаки по цифрам

В ходе задокументированных кампаний XORDDoS исследователи фиксировали свыше 20 000 попыток аутентификации на один сервер за первые 24 часа. Атака ведётся с десятков IP-адресов параллельно, что дополнительно усложняет блокировку.

После успешного подбора учётных данных (чаще всего скомпрометированного аккаунта root или пользователя с правами sudo) злоумышленники выполняют удалённый bash-скрипт. Скрипт скачивает основную полезную нагрузку XORDDoS из удалённого источника, распаковывает и запускает её — и с этого момента сервер становится полноправным узлом ботнета.

Ключевая причина успеха атаки — не техническая изощрённость, а человеческий фактор: слабые или дефолтные пароли для привилегированных аккаунтов в сочетании с отсутствием элементарных мер защиты SSH.


Закрепление: многоуровневая персистентность

После первичного заражения XORDDoS немедленно интегрируется в три независимых механизма автозапуска. Каждый из них является резервным для остальных — удаление одного не устраняет угрозу.

System V Init (runlevels)

Троян копирует своё тело в /etc/init.d/ под случайным именем из 10 символов, затем создаёт символьные ссылки вида S90[случайные_цифры] в директориях /etc/rc1.d//etc/rc5.d/ и /etc/rc.d/rc1.d/. Для легитимной регистрации в системе загрузки вызываются штатные утилиты:

chkconfig --add [имя_службы]
update-rc.d [имя_службы] defaults

Cron — сторожевой процесс

В /etc/cron.hourly/ создаётся bash-скрипт (gcc.sh, cqqbnzzu.sh, obidhyb.sh — имена варьируются от кампании к кампании). В /etc/crontab добавляется правило запуска этого скрипта каждые 3 минуты. Скрипт выполняет роль watchdog: проверяет наличие основного тела трояна (обычно укрытого по пути /lib/libudev.so) и при его отсутствии немедленно скачивает и запускает копию. Именно поэтому простое удаление файла или завершение процесса через kill -9 не даёт никакого эффекта: через 3 минуты троян возвращается.

Systemd (современные версии)

В актуальных модификациях XORDDoS регистрирует пользовательскую службу с директивой Restart=always. Операционная система автоматически перезапускает процесс при любой попытке его остановить, делая команды systemctl stop и systemctl kill бесполезными.

Практический вывод

Наличие трёх независимых механизмов персистентности означает, что очистка системы требует их одновременного нейтрализации в строгой последовательности. Подробный алгоритм — в разделе «Обнаружение и реагирование».


Маскировка: арсенал антианалитических техник

Высокая выживаемость XORDDoS обеспечивается не только механизмами закрепления, но и развитым набором техник уклонения от обнаружения, охватывающим все уровни системы — от ядра до лог-файлов.

LKM-руткит (ring 0)

Наиболее технически опасный компонент — загружаемый модуль ядра (Loadable Kernel Module), функционирующий на уровне ring 0. Руткит исключает себя из системных списков ядра (утилита lsmod его не видит) и перехватывает системные вызовы через манипуляцию sys_call_table. Фильтрация вывода /proc позволяет скрыть вредоносные процессы, а перехват функций tcp4_seq_show() и tcp6_seq_show() делает невидимыми для netstat все активные сетевые соединения трояна. Взаимодействие основного процесса с руткитом осуществляется через системный вызов ioctl с идентификатором 0x9748712 через символьное устройство /proc/rs_dev.

Спуфинг имён процессов

XORDDoS динамически перезаписывает аргументы командной строки в оперативной памяти, обнуляя буферы и замещая свой истинный путь именем легитимной команды. Администратор, запустивший ps -aef или top, увидит вместо вредоносного процесса что-то вроде:

cat resolv.conf
netstat -an
bash
pwd
gnome-terminal

Демонизация и разрыв дерева процессов

Чтобы оборвать связь с сессией, через которую произошло проникновение, троян выполняет двойной fork() с последующим setsid(). Родительские процессы завершаются, вредоносный процесс «усыновляется» init — и отследить цепочку его происхождения стандартными средствами уже невозможно.

Антифорензика: уничтожение улик

Сразу после захвата системы XORDDoS перезаписывает нулевым байтом или символом новой строки ключевые журналы:

  • /var/log/wtmp — история входов в систему
  • /var/log/secure — журнал аутентификации
  • /root/.bash_history — история команд суперпользователя

Первоначальный дроппер нередко разворачивается в /dev/shm — виртуальной директории в RAM, которая полностью очищается при перезагрузке.

Полиморфизм: 26 000 уникальных копий

Для обхода сигнатурных детекторов, опирающихся на хэш-суммы файлов, XORDDoS генерирует случайную строку из 10 символов и дописывает её (вместе с нулевым байтом) в конец своего бинарника. Это немедленно меняет MD5/SHA-256 хэш, не нарушая работоспособности кода. В рамках одной кампании таким образом было сгенерировано свыше 26 000 уникальных образцов.


Практический кейс: разбор заражения по системным логам

Нижеследующее — реконструкция реального инцидента по данным первичного расследования, проведённого мной. Временная точка отсчёта установлена по syslog: 2026-05-30T13:58:30 (время сервера).

Фаза 1 — Брутфорс SSH

Именно с указанного timestamp в журналах зафиксированы массовые попытки аутентификации под различными именами пользователей. Атака велась с 19 IP-адресов одновременно.

Все 19 адресов атакующих были проверены на VirusTotal и признаны причастными к ранее задокументированным вредоносным кампаниям, в том числе к SSH-брутфорсу:

Фаза 2 — Компрометация и установка полезной нагрузки

Точный IP-адрес, с которого была успешно подобрана пара логин/пароль, по имеющимся логам установить не удалось — что само по себе является артефактом антифорензики (перезапись auth-логов). Тем не менее сценарий однозначен: пароль был подобран, после чего сервер был включён в ботнет XORDDoS.

Атрибуцию к конкретному семейству вредоносов подтверждают два независимых факта. Первый — сценарий атаки идентичен задокументированному паттерну XORDDoS (описание SecureLab):

Второй — вредонос установил соединение с литовским IP-адресом 141.98.10.115, задокументированным как C2-инфраструктура именно данного семейства:

141.98.10.115 - Проверить

Фаза 3 — Закрепление: что было найдено в системе

Я обнаружил два активных Cron-задания, обеспечивавших персистентность.

Задание 1 — w.sh выполнялось при каждой перезагрузке из crontab пользователя root. По своей роли это оркестратор ботнета: он запускал модуль SSH-брутфорса других серверов (на это указывают аргументы ssh 2 ranges в теле строки).

Задание 2 — gcc.sh — файл с намеренно вводящим в заблуждение именем, имитирующим утилиту компилятора. Фактически это генератор бинарных полезных нагрузок — тех самых исполняемых файлов с нечитаемыми именами («кракозябры»).

Каждый из сгенерированных бинарников сопровождался регистрацией системного сервиса с явно выраженной маскировкой: поле cmdline процесса отображало rpc.statd — легитимный демон службы статуса NFS, — хотя реальной связи с ним не было. Сервис был зарегистрирован в init-скриптах с параметрами, игнорирующими команды stop, restart и аналогичные: попытка остановить его через systemctl stop [имя] завершалась без какого-либо эффекта.

Ключевой вывод по кейсу

Троян использовал одновременно три из пяти задокументированных механизмов персистентности (Cron, init-скрипты, запрет управляющих команд systemd) и как минимум один метод маскировки (спуфинг имени процесса под rpc.statd). Это стандартный, а не расширенный сценарий XORDDoS, что свидетельствует о высокой степени автоматизации кампании.


Коммуникация с C2 и функционал DDoS

Сетевая архитектура XORDDoS устроена так, чтобы минимизировать обнаруживаемость трафика при максимальной эффективности управления ботнетом.

Для резолвинга IP-адресов C2-серверов троян использует публичные DNS-серверы Google (8.8.8.8 и 8.8.4.4), что позволяет ему маскировать DNS-запросы под легитимную активность. Первичный контакт с сервером включает отправку пакета телеметрии (идентификатор устройства + системные метаданные), зашифрованного XOR-ключом с предварительно вычисленной CRC-суммой. В ответ сервер присылает командные пакеты с заголовком 0x1C байт.

Система команд C2 покрывает полный спектр управления ботом:

2 - Немедленная остановка текущей DDoS-атаки

3 - Инициализация пула потоков для новой атаки

6 - Скачивание произвольного файла с удалённого ресурса

7 - Эксфильтрация локального файла на C2-сервер

8 - Принудительная отправка обновлённой системной телеметрии

9 - Получение конфигурационного файла (в т.ч. с инструкциями по устранению конкурирующих процессов)

При получении команды 3 троян максимально утилизирует ресурсы хоста: опрашивает число доступных CPU и создаёт пул потоков в двойном размере от числа ядер. Каждый поток циклически генерирует и отправляет по 65 535 пакетов к цели.

Поддерживаются три типа атак: SYN-флуд (код 0x4) — истощение ресурсов сетевого оборудования через массовые незавершённые TCP-соединения; DNS-флуд (код 0x5) — забивание канала UDP-пакетами с вредоносными DNS-запросами; ACK-флуд (код 0xA) — перегрузка серверов пакетами-подтверждениями. Для обхода базовых фильтров провайдеров (uRPF) троян модифицирует третий или четвёртый октет IP-адреса источника, имитируя трафик из того же адресного пространства /24 или /16. Совокупная мощь скоординированных атак задокументированных кампаний достигала свыше 150 Гбит/с.


Обнаружение и реагирование

Индикаторы компрометации (IoC)

На что смотреть при первичном аудите

Процессы и ресурсы:

  • CPU 100% без объяснимой нагрузки - Майнинг или генерация DDoS-трафика
  • Процессы с именами из 8–10 случайных символов запущены от root - Основное тело трояна (efueyo, jwvwvxoupv, kagbjahdic и подобные)
  • ps -aef показывает cat resolv.conf / netstat -an / bash / pwd - Спуфинг имени процесса
  • netstat не показывает активных соединений при высокой сетевой нагрузке - LKM-руткит фильтрует вывод

Файловая система:

  • /lib/libudev.so или /lib/libudev.so.6 - Типичное местоположение основного тела трояна
  • /var/run/gcc.pid, /var/run/sftp.pid, /var/run/udev.pid - Файлы с 32-байтным bot-ID
  • /etc/cron.hourly/gcc.sh, cqqbnzzu.sh, obidhyb.sh, udev.sh - Watchdog-скрипты
  • Симлинки S90[случайные_цифры] в /etc/rc*.d/ - Инициализационная персистентность
  • Пустые /root/.bash_history, /var/log/wtmp, /var/log/secure - Антифорензика: перезапись нулевым байтом

Сеть:

  • Тысячи Failed password в auth-логах - Брутфорс-атака — входящая или уже совершившаяся
  • Массовые исходящие SYN/ACK/DNS на нетипичные IP - Бот участвует в DDoS-атаке
  • DNS-запросы к 8.8.8.8 / 8.8.4.4 с нехарактерной частотой - Резолвинг C2-адресов
  • Соединения на порты 53, 3306, 8005 к неизвестным хостам - C2-коммуникация

Алгоритм очистки системы

Критически важно

Простое завершение процесса (kill -9) и удаление файла без предварительного нейтрализации watchdog-механизмов приведёт к восстановлению трояна через 3 минуты. Следуйте алгоритму в строгой последовательности.

Этап 1 — Заморозка процесса (не завершение)

Найдите PID вредоносного процесса через top или:

ps -aef | grep -E '[a-z]{8,10}'

Приостановите выполнение сигналом SIGSTOP — это предотвращает срабатывание watchdog-скриптов, мониторящих статус процесса:

kill -STOP [PID]

Этап 2 — Поиск вредоносных скриптов

Выявите недавно изменённые файлы в системных директориях конфигурации:

sudo find /etc -printf '%T@ %t %p\n' | sort -k 1 -n | cut -d' ' -f2-

Этап 3 — Уничтожение механизмов персистентности

# Удаление watchdog-скриптов из cron
rm -f /etc/cron.hourly/gcc.sh /etc/cron.hourly/cqqbnzzu.sh /etc/cron.hourly/obidhyb.sh

# Удаление симлинков автозапуска
rm -f /etc/rc?.d/S90*

# Удаление init-скрипта (замените [имя] реальным именем файла)
rm -f /etc/init.d/[имя]

# Снятие с регистрации в системе загрузки
chkconfig --del [имя]
update-rc.d [имя] remove

Этап 4 — Удаление основного тела трояна

# Поиск основного файла
find / -type f -name libudev.so

# Снятие прав, удаление и блокировка директории на запись
chmod 0000 /lib/libudev.so && rm -rf /lib/libudev.so && chattr +i /lib

Этап 5 — Предотвращение повторного заражения

# Смена пароля root
passwd root

# Отключение парольной аутентификации SSH (предпочтительно — переход на ключи)
# В /etc/ssh/sshd_config:
# PasswordAuthentication no
# PermitRootLogin prohibit-password

# Установка и настройка fail2ban
apt install fail2ban
systemctl enable --now fail2ban

# Закрытие API Docker (если применимо)
# Убедиться, что порт 2375 недоступен снаружи

Дополнительные меры защиты

Разверните EDR-решение в режиме блокировки для автоматического обнаружения многоуровневых атак. Используйте YARA-правила для регулярного сканирования: в отличие от хэш-сигнатур, они эффективны против полиморфных версий трояна. Настройте IPS и правила межсетевого экрана для блокировки известной C2-инфраструктуры на уровне IP и домена, а также для ограничения нетипичных исходящих соединений (массовые DNS-запросы, порты 3306, 8005).