Специалисты подразделения Unit 42 компании Palo Alto Networks обнаружили ботнет для IoT-устройств, которого раньше никто не видел. Назвали его TuxBot v3 Evolution. Разбирали находку исследователи Крис Наваррете, Ашер Давила и Доэль Сантос — и то, что они нашли внутри кода, оказалось интереснее самого факта появления нового ботнета.
В нескольких файлах прямо в комментариях остались рассуждения языковой модели — то самое пошаговое «мышление вслух», которое обычно скрыто от пользователя. Модель прерывала сама себя, принимала решения по ходу дела, упоминала «пользователя» — то есть разработчика, который ей эти задачи ставил. Разработчик просто не вычистил это из финального кода. Более того, в одном месте осталось предупреждение о безопасности — модель честно предупредила, что генерирует потенциально вредоносный функционал, а автор ботнета это предупреждение тоже не удалил перед тем, как выкатить код в мир.
Получилась почти комичная ситуация: часть функций в изученных образцах попросту не работает. Unit 42 прямо пишет — обычная ручная проверка кода эти ошибки бы устранила. То есть разработчик доверился ИИ настолько, что даже не перечитал сгенерированное. При этом исследователи не исключают, что где-то в сети уже гуляют более отлаженные версии того же ботнета — эта могла быть промежуточной сборкой.
Сама архитектура TuxBot собрана довольно основательно для одного разработчика. Бот-агент написан на C и кросс-компилируется сразу под семь архитектур: ARM, MIPS, MIPSEL, MIPS64, x86_64, PowerPC и RISC-V. Управляющий сервер написан на Go и включает панель для DDoS-услуг по найму — то есть предполагается коммерческое использование. К этому добавляется собственная виртуальная машина для эксплойтов, тестовая инфраструктура на Docker и система автоматической сборки.
Функционал самого бота тоже не бедный. Для взлома Telnet используется набор из 1496 пар логин-пароль — классика для IoT-ботнетов, но с довольно широким охватом. Эксплойты нацелены на более чем 30 семейств IoT-устройств с известными уязвимостями. Для связи с управляющим сервером предусмотрено сразу несколько каналов: зашифрованный TCP, алгоритм генерации доменов на основе SHA512, P2P-протокол со сплетнями (gossip), где команды подписаны через Ed25519, IRC, DNS TXT-запросы и HTTP-опрос как запасной вариант на случай, если остальные способы связи заблокированы.
Закрепление в системе организовано через systemd-сервис, записи в cron и отдельный процесс-наблюдатель, который следит, чтобы TuxBot не отключился на зараженной машине.
По описанию самого фреймворка, разработчик ставил перед собой амбициозную задачу — создать «профессиональную C2-платформу» с многопользовательской админ-панелью, автоматическим развертыванием и модульной системой атак. То есть это очередной форк Mirai и попытка построить что-то более сложное — с несколькими каналами управления, генерацией доменов и модульной системой эксплойтов, которая, впрочем, в изученной версии пока не заработала как следует.
Родословную TuxBot исследователи проследили до трёх ботнетов — Mirai, AISURU и Wuhan. Часть функций перенесена из открытого Python-инструмента для DDoS-атак под названием MHDDoS. Хронология тоже восстановлена: как минимум один образец загружен на VirusTotal 20 января 2026 года, а сама разработка началась примерно на год раньше — именно тогда автор скопировал репозиторий MHDDoS с GitHub. На момент раскрытия информации вредонос существует уже больше полугода.
По совпадению инфраструктуры — с инструментами Kaitori v3.9 и AISURU — исследователи связывают оператора TuxBot с экосистемой Keksec. Эта группа известна тем, что параллельно поддерживает сразу несколько вариантов IoT-ботнетов, и TuxBot, судя по всему, стал ещё одним пунктом в их портфеле.
Итоговая оценка Unit 42 сдержанная: TuxBot v3 Evolution — проект незавершённый, часть функций сломана, часть работает нормально. Но сам факт, что один человек с помощью языковой модели смог собрать многофункциональный инструментарий с несколькими каналами связи, собственной виртуальной машиной для эксплойтов и панелью для DDoS-услуг, говорит о том, что порог входа в разработку такого рода инструментов заметно снизился. Раньше на сборку подобного набора уходили месяцы работы команды, теперь — судя по всему, значительно меньше, пусть и ценой качества.
В нескольких файлах прямо в комментариях остались рассуждения языковой модели — то самое пошаговое «мышление вслух», которое обычно скрыто от пользователя. Модель прерывала сама себя, принимала решения по ходу дела, упоминала «пользователя» — то есть разработчика, который ей эти задачи ставил. Разработчик просто не вычистил это из финального кода. Более того, в одном месте осталось предупреждение о безопасности — модель честно предупредила, что генерирует потенциально вредоносный функционал, а автор ботнета это предупреждение тоже не удалил перед тем, как выкатить код в мир.
Получилась почти комичная ситуация: часть функций в изученных образцах попросту не работает. Unit 42 прямо пишет — обычная ручная проверка кода эти ошибки бы устранила. То есть разработчик доверился ИИ настолько, что даже не перечитал сгенерированное. При этом исследователи не исключают, что где-то в сети уже гуляют более отлаженные версии того же ботнета — эта могла быть промежуточной сборкой.
Сама архитектура TuxBot собрана довольно основательно для одного разработчика. Бот-агент написан на C и кросс-компилируется сразу под семь архитектур: ARM, MIPS, MIPSEL, MIPS64, x86_64, PowerPC и RISC-V. Управляющий сервер написан на Go и включает панель для DDoS-услуг по найму — то есть предполагается коммерческое использование. К этому добавляется собственная виртуальная машина для эксплойтов, тестовая инфраструктура на Docker и система автоматической сборки.
Функционал самого бота тоже не бедный. Для взлома Telnet используется набор из 1496 пар логин-пароль — классика для IoT-ботнетов, но с довольно широким охватом. Эксплойты нацелены на более чем 30 семейств IoT-устройств с известными уязвимостями. Для связи с управляющим сервером предусмотрено сразу несколько каналов: зашифрованный TCP, алгоритм генерации доменов на основе SHA512, P2P-протокол со сплетнями (gossip), где команды подписаны через Ed25519, IRC, DNS TXT-запросы и HTTP-опрос как запасной вариант на случай, если остальные способы связи заблокированы.
Закрепление в системе организовано через systemd-сервис, записи в cron и отдельный процесс-наблюдатель, который следит, чтобы TuxBot не отключился на зараженной машине.
По описанию самого фреймворка, разработчик ставил перед собой амбициозную задачу — создать «профессиональную C2-платформу» с многопользовательской админ-панелью, автоматическим развертыванием и модульной системой атак. То есть это очередной форк Mirai и попытка построить что-то более сложное — с несколькими каналами управления, генерацией доменов и модульной системой эксплойтов, которая, впрочем, в изученной версии пока не заработала как следует.
Родословную TuxBot исследователи проследили до трёх ботнетов — Mirai, AISURU и Wuhan. Часть функций перенесена из открытого Python-инструмента для DDoS-атак под названием MHDDoS. Хронология тоже восстановлена: как минимум один образец загружен на VirusTotal 20 января 2026 года, а сама разработка началась примерно на год раньше — именно тогда автор скопировал репозиторий MHDDoS с GitHub. На момент раскрытия информации вредонос существует уже больше полугода.
По совпадению инфраструктуры — с инструментами Kaitori v3.9 и AISURU — исследователи связывают оператора TuxBot с экосистемой Keksec. Эта группа известна тем, что параллельно поддерживает сразу несколько вариантов IoT-ботнетов, и TuxBot, судя по всему, стал ещё одним пунктом в их портфеле.
Итоговая оценка Unit 42 сдержанная: TuxBot v3 Evolution — проект незавершённый, часть функций сломана, часть работает нормально. Но сам факт, что один человек с помощью языковой модели смог собрать многофункциональный инструментарий с несколькими каналами связи, собственной виртуальной машиной для эксплойтов и панелью для DDoS-услуг, говорит о том, что порог входа в разработку такого рода инструментов заметно снизился. Раньше на сборку подобного набора уходили месяцы работы команды, теперь — судя по всему, значительно меньше, пусть и ценой качества.