Атакующие получали полный административный контроль над доступными из интернета роутерами MikroTik по SSH без пароля, без SSH-ключа и вообще без прохождения аутентификации. Цепочку, названную CERT Polska MikroTrick, использовали в дикой природе как минимум за сутки до того, как MikroTik выпустил патчи. Если роутер MikroTik стоит перед вашими серверами или хостинг-инфраструктурой, к этому стоит отнестись серьёзно, потому что скомпрометированный пограничный роутер — это не просто скомпрометированный роутер. Это плацдарм перед всем, что находится за ним.
MikroTik-железо постоянно встречается на периметре хостинг-инсталляций и сетей малого и среднего размера, и значимость этой атаки в том, что роутер — это то единственное устройство, которое видит весь ваш трафик и держит ключи к схеме вашей сети. Ниже разбор того, как работает цепочка, как понять, задело ли вас, и что с этим делать. Мы регулярно смотрим на такие устройства во время аудита безопасности инфраструктуры, и периметр почти никогда не проверяют так же тщательно, как веб-приложение за ним.
Цепочка: два бага, слабые по отдельности и разрушительные вместе
MikroTrick объединяет две отдельные SSH-уязвимости RouterOS. Ни одна из них сама по себе не является полным поражением. Составленные вместе, они отдают всё устройство.
Шаг первый: пропуск аутентификации (CVE-2026-67279)
Нормальный SSH работает в строгом порядке. Он устанавливает шифрованное соединение, аутентифицирует пользователя и только затем позволяет клиенту открыть сессию и выполнять команды. Сервер отправляет специальное подтверждающее сообщение, как только аутентификация пройдена, и ничего не должно продолжаться без него.
CVE-2026-67279 ломает этот порядок. Если клиент запускает переговоры о смене SSH-ключа (renegotiation) во время шага аутентификации, уязвимый RouterOS перескакивает прямо в командную фазу по завершении renegotiation, так и не подтвердив, кто пользователь. Сам по себе он не создаёт аутентифицированную сессию и не выдаёт привилегий. Что он делает, так это позволяет неаутентифицированному чужаку добраться до этапа, который должен быть заперт за завершённым логином. Это и есть подпёртая дверь.
Шаг второй: стать админом через программу логина (CVE-2026-86060)
Вот хитрая часть, и это хрестоматийная argument injection. Когда приходит сессия, RouterOS запускает программу логина по пути /nova/bin/login, и SSH-демон передаёт ей имя пользователя и уровень привилегий как аргументы командной строки. Проблема в том, что имя пользователя не проверяется. Значение, начинающееся с дефиса, трактуется как опция программы, а не как имя.
Поэтому атакующий отправляет -2 в качестве имени пользователя. Программа логина читает это как инструкцию взять свою личность и уровень привилегий из файлового дескриптора 2, который указывает на терминал, созданный SSH-сессией. А через SSH-канал атакующий уже записал в этот самый терминал выбранное имя пользователя и значение привилегий полного администратора. Программа логина покорно принимает оба и открывает консоль с полными привилегиями. Никакие учётные данные при этом не передавались.
В этом весь трюк: один баг доводит до этапа логина без аутентификации, второй велит программе логина доверять вводу, которым управляет атакующий.
Это эксплуатировали ещё до появления патча
Это не теоретическая цепочка. CERT Polska нашла логи атак, датированные как минимум 2 сентября, за сутки до того, как MikroTik выпустил исправления 3 сентября. CISA независимо подтвердила активную эксплуатацию, добавив CVE-2026-86060 в свой каталог Known Exploited Vulnerabilities 10 сентября.
Атака оставляет очень узнаваемый след. На одном устройстве, задокументированном на форуме MikroTik, последовательность была такой: отклонённый логин для пользователя -2, принудительный renegotiation, переход в channel-фазу и exec-запрос с попыткой создать пользователя ops с полными привилегиями. На этом конкретном устройстве SSH-процесс упал до завершения команды, но другие отчёты подтвердили, что аккаунт ops успешно создавался в других местах. В части инцидентов CERT Polska видела генерацию диагностических файлов с последующей передачей данных на IP атакующего, что убедительно указывает на то, что конфигурация роутера копировалась на инфраструктуру атакующего. Ваш конфиг — это карта вашей сети, ваши firewall-правила, ваши VPN-секреты. Именно то, что вы не хотите видеть в чужих руках.
Исправленные версии и кто реально в зоне риска
MikroTik закрыл цепочку в RouterOS 6.49.21, 7.23.4 и 7.24.2. Обновляйтесь как минимум до этих сборок на той ветке релиза, которую используете.
Предусловие для атаки в том, что SSH достижим для атакующего. MikroTik заявляет, что его домашняя конфигурация по умолчанию не выставляет SSH в интернет, так что коробочные домашние устройства в основном вне зоны. Группа повышенного риска — это все, кто менял свои firewall-правила или управляет устройствами по SSH из недоверенных сетей, а это описывает массу реальных хостинговых и бизнес-развёртываний. Если вы администрируете свой MikroTik удалённо по SSH, считайте, что вы в числе целей.
Один момент для ясности, потому что часть изданий это переврала: MikroTrick — это конкретно CVE-2026-67279 плюс CVE-2026-86060. Третий баг, CVE-2026-67276, ошибочно приплетают сюда. CERT Polska говорит, что это отдельная SSH-уязвимость, позволяющая атакующему подделать RSA-ключ и войти как существующий пользователь, но она требует знания имени аккаунта и его публичного ключа и даёт доступ только к этому одному аккаунту. Другой баг, другая критичность. Патчите всё, но не смешивайте эти две истории.
Как проверить, скомпрометированы ли вы
Патч останавливает атаку в дальнейшем. Он не отменяет то, что атакующий уже сделал до обновления. Это различие критично: пропатченный роутер не является автоматически чистым роутером. После обновления проверьте статус Flagged командой:
/system/device-mode/printНо не полагайтесь на Flagged как на доказательство безопасности. И CERT Polska, и MikroTik прямо говорят, что механизм Flagged детектирует лишь отдельные следы компрометации, и его отсутствие не доказывает, что устройство чистое.
CERT Polska опубликовала эти конкретные индикаторы из наблюдаемых атак. Проверьте их все:
- Имя пользователя
-2в логах SSH-логинов. - Аккаунт с именем
opsв группе полных привилегий. - IP атакующего
82.192.72.4, замечен в успешных атаках. - IP атакующего
103.102.31.18, использовался в попытках эксплуатации.
Помимо этого, ищите всё, что не можете объяснить: неизвестных пользователей, незнакомые скрипты, записи планировщика, туннели, прокси, неожиданные диагностические файлы .rif или fetch-активность, которую вы не инициировали. Это те артефакты закрепления и эксфильтрации, что оставляет за собой эта атака — их поиск на скомпрометированном устройстве и есть та работа, которую закрывает анализ вредоносной активности, когда своими силами разобраться не получается.
Если что-то из этого нашлось: считайте компрометацию полной
Если присутствует любой индикатор, считайте устройство полностью захваченным и не пытайтесь чистить его на месте. Рекомендации CERT Polska прямые:
- Изолируйте устройство от сети.
- Сохраните его логи и конфигурацию для расследования, прежде чем что-либо стирать.
- Сделайте factory reset и пересоберите из конфигурации, которой доверяете, а не из бэкапа, снятого со скомпрометированного устройства. Бэкап со скомпрометированного роутера может занести изменения атакующего обратно.
- Смените каждый пароль, ключ и учётные данные, которых касался роутер. Если конфиг был выкачан, считайте сгоревшим всё, что в нём было, включая VPN-секреты и любые общие креды.
Если весь этот процесс изоляции и пересборки страшно делать своими силами под давлением, это ровно то, чем занимается наш incident response на скомпрометированной сетевой инфраструктуре, а не только на взломанных сайтах.
Итог
MikroTrick — это чистый пример того, почему сцепленные уязвимости бьют сильнее изолированных и почему сетевой периметр заслуживает той же срочности патчинга, что и ваши серверы. Баг с пропуском аутентификации, сам по себе ничего не выдающий, плюс небрежный баг обработки аргументов во вспомогательной программе логина складываются в неаутентифицированного полного администратора на устройстве, которое видит весь ваш трафик. Его эксплуатировали ещё до того, как вышел фикс. Если у вас MikroTik с достижимым SSH, обновляйтесь до 6.49.21, 7.23.4 или 7.24.2 прямо сейчас, а затем пройдитесь по индикаторам выше, потому что патч закрывает дверь, но не выселяет того, кто уже внутри. Если хотите, чтобы периметр проверил кто-то снаружи, а не вы сами постфактум, для этого у нас есть отдельный пентест сетевой инфраструктуры.