Исследователи Nozomi Networks Labs 27 июля 2026 года описали ботнет, который отличается от типичных наследников Mirai одной особенностью — он умеет заставлять заражённое устройство перезагрузиться, если администратор или средство защиты убивает его основной процесс. Зловред получил название Tengu, а обнаружили его благодаря атакам подбора учётных данных Telnet, которые фиксировались на honeypot-ловушках компании.
Сама по себе принадлежность к семейству Mirai уже говорит о многом: набор функций у Tengu стандартный для этой линии малвари. Он поддерживает 25 отдельных методов проведения DDoS-атак, может развернуть на заражённой машине SOCKS5-прокси, выполнять произвольные shell-команды, собирать данные о системе и сети, обновляться самостоятельно и подгружать дополнительные payload-файлы в формате ELF или APK. Работает всё это на широком спектре архитектур — от i386 и amd64 до MIPS, ARM, PowerPC и даже устаревшего m68k, что типично для оборудования из категории IoT: роутеров, видеорегистраторов, всевозможных встраиваемых систем.
А вот механизмы самозащиты у Tengu заметно богаче, чем у большинства родственных вредоносов. В Nozomi прямо отметили: «Большинство вариантов Mirai реализуют мало таких функций самозащиты, если реализуют вообще хоть какие-то». Здесь их набралось сразу несколько. Малварь создаёт фиктивный systemd-сервис, дописывает себя в init- и rc-скрипты, вмешивается в файлы автозапуска shell, а установленный бинарник помечает флагом неизменяемости — immutable. Есть и попытка закрепиться через cron, хотя реализация выглядит незавершённой или сломанной — код ссылается на /proc/self/exe так, будто разработчики не довели идею до конца.
Главная находка отчёта — это, конечно, эксплуатация аппаратного watchdog-таймера. Фоновый процесс маскируется под системную задачу с именем [kworker/0:0], если находит доступное устройство watchdog — открывает его повторно и взводит с таймаутом около 30 секунд. Пока основной процесс Tengu жив, он посылает keepalive-сигналы этому таймеру. Как только процесс убивают, сигналы прекращаются, watchdog не получает подтверждения и через полминуты аппаратно перезагружает устройство. После перезапуска в дело вступают уже описанные механизмы персистентности — systemd, init-скрипты, автозагрузка — и малварь возвращается на устройство почти без участия оператора.
Отдельный штрих — порча заголовков ELF-файлов у системных утилит reboot и shutdown. В коде вредоноса хранится список таких бинарников, и Tengu переписывает их ELF-заголовки строкой «ELFOOD», из-за чего команды перезагрузки или выключения перестают нормально работать у защитников, пытающихся вручную привести устройство в порядок.
Управляющая инфраструктура завязана на один сервер с адресом 64.89.163.8 и портом TCP 9931. Регистрация заражённого узла, heartbeat-трафик и вывод выполненных команд передаются открытым текстом, а вот команды и обновления, приходящие от сервера, зашифрованы — используется собственная схема аутентифицированного шифрования, похожая на ChaCha20/Poly1305. Интересная деталь — интеграция с IPFS: Tengu может запросить у C2-сервера идентификатор контента и получить файл через шлюз InterPlanetary File System, работающий на том же сервере. Полученный результат проверяется — это ELF или APK, — после чего исполняется или устанавливается соответственно.
Наличие APK-варианта наводит аналитиков Nozomi на мысль, что часть кампании может метить в плохо защищённые Android TV-приставки или похожие устройства на Android. Но это именно предположение — подтверждённых жертв среди Android-устройств в отчёте не зафиксировано.
Независимая проверка через сервис URLhaus дала любопытный, но неполный результат. По тому же IP 64.89.163.8 сервис зафиксировал 17 адресов с вредоносным содержимым — начиная с 17 июня 2026 года. Среди файлов был shell-скрипт, несколько ELF-файлов с меткой Mirai и один APK. Последние записи о новых payload появились 7 июля, а к 28 июля все 17 адресов оказались уже недоступны. Но здесь есть нюанс: URLhaus не называет эти файлы Tengu — это просто общая маркировка «связано с Mirai». Хеши SHA-256, зафиксированные в записях URLhaus для этого хоста, не совпали с хешем образца Tengu, опубликованным Nozomi, — по крайней мере, по состоянию на 28 июля совпадений не нашли. То есть подтвердить, что именно эти 17 URL относятся к Tengu, а не просто к какому-то другому Mirai-производному, нельзя.
Отчёт оставляет открытыми немало вопросов. Не названы ни конкретные модели устройств-жертв, ни производители затронутого оборудования. Нет данных об операторе или группировке, стоящей за ботнетом. Отсутствуют цифры по масштабу заражения — сколько устройств скомпрометировано, неизвестно. Не зафиксировано ни одной реальной DDoS-атаки с участием Tengu против конкретной жертвы. Остаётся неясным, был ли доступен и активен C2-сервис на порту 9931 в момент публикации, работал ли IPFS-шлюз на порту 8080, и отдавал ли сервер управления хоть какие-то команды заражённым узлам. Важно понимать: статус «офлайн» у URLhaus относится только к перечисленным адресам загрузки файлов, а не к самому C2-серверу или IPFS-инфраструктуре — те могли продолжать работать независимо.
The Hacker News направил в Nozomi Networks запрос с просьбой уточнить масштаб заражений, текущий статус инфраструктуры и подтвердить связь образцов из URLhaus с Tengu — на момент публикации ответа не поступило, материал обещают обновить при получении данных.
Рекомендации защитников достаточно предсказуемы для устройств такого класса, но от этого не менее актуальны. Nozomi советует убрать Telnet и прочие административные сервисы из открытого доступа в интернет, заменить заводские пароли на устройствах, обновить прошивку и разделить сети IoT-устройств от остальной инфраструктуры сегментацией. Отдельный пункт — перед возвратом устройства в эксплуатацию после подозрения на заражение стоит вручную проверить systemd-сервисы, init-скрипты, файлы автозапуска shell и всё, что связано с cron: именно там Tengu прячет свои точки возврата.
Сама по себе принадлежность к семейству Mirai уже говорит о многом: набор функций у Tengu стандартный для этой линии малвари. Он поддерживает 25 отдельных методов проведения DDoS-атак, может развернуть на заражённой машине SOCKS5-прокси, выполнять произвольные shell-команды, собирать данные о системе и сети, обновляться самостоятельно и подгружать дополнительные payload-файлы в формате ELF или APK. Работает всё это на широком спектре архитектур — от i386 и amd64 до MIPS, ARM, PowerPC и даже устаревшего m68k, что типично для оборудования из категории IoT: роутеров, видеорегистраторов, всевозможных встраиваемых систем.
А вот механизмы самозащиты у Tengu заметно богаче, чем у большинства родственных вредоносов. В Nozomi прямо отметили: «Большинство вариантов Mirai реализуют мало таких функций самозащиты, если реализуют вообще хоть какие-то». Здесь их набралось сразу несколько. Малварь создаёт фиктивный systemd-сервис, дописывает себя в init- и rc-скрипты, вмешивается в файлы автозапуска shell, а установленный бинарник помечает флагом неизменяемости — immutable. Есть и попытка закрепиться через cron, хотя реализация выглядит незавершённой или сломанной — код ссылается на /proc/self/exe так, будто разработчики не довели идею до конца.
Главная находка отчёта — это, конечно, эксплуатация аппаратного watchdog-таймера. Фоновый процесс маскируется под системную задачу с именем [kworker/0:0], если находит доступное устройство watchdog — открывает его повторно и взводит с таймаутом около 30 секунд. Пока основной процесс Tengu жив, он посылает keepalive-сигналы этому таймеру. Как только процесс убивают, сигналы прекращаются, watchdog не получает подтверждения и через полминуты аппаратно перезагружает устройство. После перезапуска в дело вступают уже описанные механизмы персистентности — systemd, init-скрипты, автозагрузка — и малварь возвращается на устройство почти без участия оператора.
Отдельный штрих — порча заголовков ELF-файлов у системных утилит reboot и shutdown. В коде вредоноса хранится список таких бинарников, и Tengu переписывает их ELF-заголовки строкой «ELFOOD», из-за чего команды перезагрузки или выключения перестают нормально работать у защитников, пытающихся вручную привести устройство в порядок.
Управляющая инфраструктура завязана на один сервер с адресом 64.89.163.8 и портом TCP 9931. Регистрация заражённого узла, heartbeat-трафик и вывод выполненных команд передаются открытым текстом, а вот команды и обновления, приходящие от сервера, зашифрованы — используется собственная схема аутентифицированного шифрования, похожая на ChaCha20/Poly1305. Интересная деталь — интеграция с IPFS: Tengu может запросить у C2-сервера идентификатор контента и получить файл через шлюз InterPlanetary File System, работающий на том же сервере. Полученный результат проверяется — это ELF или APK, — после чего исполняется или устанавливается соответственно.
Наличие APK-варианта наводит аналитиков Nozomi на мысль, что часть кампании может метить в плохо защищённые Android TV-приставки или похожие устройства на Android. Но это именно предположение — подтверждённых жертв среди Android-устройств в отчёте не зафиксировано.
Независимая проверка через сервис URLhaus дала любопытный, но неполный результат. По тому же IP 64.89.163.8 сервис зафиксировал 17 адресов с вредоносным содержимым — начиная с 17 июня 2026 года. Среди файлов был shell-скрипт, несколько ELF-файлов с меткой Mirai и один APK. Последние записи о новых payload появились 7 июля, а к 28 июля все 17 адресов оказались уже недоступны. Но здесь есть нюанс: URLhaus не называет эти файлы Tengu — это просто общая маркировка «связано с Mirai». Хеши SHA-256, зафиксированные в записях URLhaus для этого хоста, не совпали с хешем образца Tengu, опубликованным Nozomi, — по крайней мере, по состоянию на 28 июля совпадений не нашли. То есть подтвердить, что именно эти 17 URL относятся к Tengu, а не просто к какому-то другому Mirai-производному, нельзя.
Отчёт оставляет открытыми немало вопросов. Не названы ни конкретные модели устройств-жертв, ни производители затронутого оборудования. Нет данных об операторе или группировке, стоящей за ботнетом. Отсутствуют цифры по масштабу заражения — сколько устройств скомпрометировано, неизвестно. Не зафиксировано ни одной реальной DDoS-атаки с участием Tengu против конкретной жертвы. Остаётся неясным, был ли доступен и активен C2-сервис на порту 9931 в момент публикации, работал ли IPFS-шлюз на порту 8080, и отдавал ли сервер управления хоть какие-то команды заражённым узлам. Важно понимать: статус «офлайн» у URLhaus относится только к перечисленным адресам загрузки файлов, а не к самому C2-серверу или IPFS-инфраструктуре — те могли продолжать работать независимо.
The Hacker News направил в Nozomi Networks запрос с просьбой уточнить масштаб заражений, текущий статус инфраструктуры и подтвердить связь образцов из URLhaus с Tengu — на момент публикации ответа не поступило, материал обещают обновить при получении данных.
Рекомендации защитников достаточно предсказуемы для устройств такого класса, но от этого не менее актуальны. Nozomi советует убрать Telnet и прочие административные сервисы из открытого доступа в интернет, заменить заводские пароли на устройствах, обновить прошивку и разделить сети IoT-устройств от остальной инфраструктуры сегментацией. Отдельный пункт — перед возвратом устройства в эксплуатацию после подозрения на заражение стоит вручную проверить systemd-сервисы, init-скрипты, файлы автозапуска shell и всё, что связано с cron: именно там Tengu прячет свои точки возврата.