Средняя
- Теги: Платформа сетевой безопасности, NSPM, Fire Ant, Cisco, SOC
В августе 2026 года компания Sygnia опубликовала исследование активности группировки Fire Ant. Ранее её связывали прежде всего с атаками на VMware-инфраструктуру, но в новой кампании в фокус попали Cisco IOS XR, TACACS-серверы и Linux-хосты управления.
Это важный сдвиг. Целью атакующего становится не отдельный сервер или рабочая станция, а инфраструктура, которая определяет маршрутизацию, административный доступ и достоверность журналов событий.
Именно поэтому история Fire Ant интересна не только как очередная APT-кампания. Она показывает, почему сетевое оборудование необходимо рассматривать как полноценный объект информационной безопасности.
Содержание
Как работала атака Fire Ant?
Расследование Sygnia началось с довольно необычной аномалии.
На маршрутизаторе Cisco IOS XR появился работающий GRE-туннель. При этом соответствующей настройки не было ни в running configuration, ни в истории commit.
Фактическое состояние устройства перестало соответствовать тому, что видел администратор через стандартный интерфейс управления.
Дальнейшее расследование показало, что злоумышленники использовали специально разработанные компоненты для IOS XR. Они взаимодействовали непосредственно с механизмами логирования, выполнения CLI-команд, AAA, маршрутизации и VRF.
В частности, вредоносное ПО могло:
- подавлять часть syslog-сообщений;
- изменять вывод CLI-команд;
- скрывать элементы конфигурации туннеля;
- обеспечивать скрытый внешний канал связи;
- предоставлять интерактивный доступ к устройству.
То есть маршрутизатор продолжал работать, администратор мог выполнять привычные команды, а система мониторинга — получать события. Но часть этой информации уже контролировалась атакующим.
Маршрутизатор превратился в точку наблюдения
Fire Ant использовал сетевое оборудование не только для закрепления.
Злоумышленники снимали PCAP с нескольких маршрутизаторов и отправляли полученные файлы на внешние FTP-серверы. Такой доступ позволяет увидеть значительно больше, чем компрометация отдельного endpoint: внутреннюю топологию, административные соединения, потоки аутентификации и взаимодействие различных сегментов сети.
Обнаруженный GRE-туннель вёл на Linux-систему, которая использовалась как промежуточная точка. Через неё проводилось сканирование доступных сетей и сервисов — SSH, HTTP/HTTPS, SMB/RPC и RDP.
Таким образом, компрометированный маршрутизатор становился мостом в другие связанные среды. Sygnia называет такую модель target behind the target: непосредственная жертва интересна атакующему прежде всего как доверенная точка доступа к следующей инфраструктуре.
Следующая цель — система аутентификации
Отдельное внимание Fire Ant уделял TACACS.
Исследователи обнаружили набор инструментов TacTap, который внедрял вредоносную библиотеку непосредственно в процесс tac_plus.
Это позволяло перехватывать TACACS-сессии и собирать учётные данные администраторов сетевого оборудования.
С точки зрения защиты это особенно неприятная ситуация.
Обычно TACACS рассматривается как средство повышения безопасности: централизованная аутентификация, авторизация команд и аудит административных действий.
Но после компрометации самого TACACS атакующий получает доступ не только к учётным данным. Под сомнение попадает достоверность журнала административных действий.
Возникает важный вопрос:
Если система, которая должна сообщать нам, кто изменил маршрутизатор, сама скомпрометирована — можем ли мы доверять её данным?
В случае Fire Ant ответ оказался отрицательным.
Когда инфраструктура начинает «лгать»?
Это, пожалуй, самая интересная часть атаки.
Fire Ant целенаправленно воздействовал не только на инфраструктуру, но и на источники доказательств.
На маршрутизаторах злоумышленники скрывали сообщения, изменяли вывод CLI, подавляли часть AAA — и SNMP-событий. На Linux-серверах меняли журналы, отключали SELinux и удаляли следы команд.
Sygnia прямо указывает: при расследовании нельзя было полагаться на один источник телеметрии. Состояние сети приходилось восстанавливать путём сопоставления данных из памяти, файловой системы, сетевого трафика, систем аутентификации и конфигураций.
Для SOC это довольно важный вывод.
Обычно мы предполагаем:
Устройство → отправляет событие → SIEM получает достоверную информацию.
Fire Ant показывает другой сценарий:
Атакующий → контролирует устройство → устройство само решает, какую информацию показать SIEM.
Именно здесь классического мониторинга событий становится недостаточно.
Что предлагает Cisco?
Здесь важно разделить две истории.
2 сентября Cisco выпустила большой IOS XR Software Security Hardening Release, закрывающий несколько классов уязвимостей. Максимальный CVSS — 9.8, а затронуты все релизы IOS XR, включая IOS XR7.
Но Cisco не утверждает, что именно эти уязвимости использовал Fire Ant. Более того, Cisco сообщает, что на момент публикации не знает случаев их эксплуатации. Sygnia также не установила первоначальный способ получения доступа злоумышленников к маршрутизатору. Поэтому называть сентябрьское обновление «патчем от Fire Ant» некорректно.
Тем не менее реакция Cisco хорошо показывает общий подход к защите IOS XR.
1. Обновить IOS XR
Для опубликованных в сентябре уязвимостей workaround отсутствует.
Cisco рекомендует перейти на поддерживаемый релиз и установить соответствующие SMU. Для будущих версий 26.2.2 и 26.3.1 исправления должны уже входить непосредственно в релиз.
Но обновление ПО — только первый уровень защиты.
2. Ограничить management plane
В IOS XR Cisco предлагает использовать Management Plane Protection — MPP.
Он позволяет явно определить интерфейсы, через которые вообще допускается управление маршрутизатором. Management-трафик с остальных интерфейсов блокируется.
Это существенно уменьшает поверхность атаки.
Управление устройством не должно быть доступно «из сети вообще». Оно должно осуществляться только из определённых административных сегментов через известные маршруты.
3. Усилить административный доступ
В IOS XR Hardening Guide Cisco рекомендует:
- отключать неиспользуемые сервисы;
- использовать SSH/SFTP/HTTPS вместо Telnet, FTP и HTTP;
- применять TACACS+ over TLS или RADIUS;
- включать AAA accounting;
- ограничивать SNMP с помощью SNMPv3 и ACL;
- централизованно отправлять логи;
- использовать secure logging;
- контролировать management-, control- и data-plane отдельно.
По сути Cisco предлагает классическую модель: минимизировать доступность management plane и максимально контролировать все пути административного доступа к устройству.
Но здесь появляется другая проблема — в большой инфраструктуре проверить выполнение этих рекомендаций вручную практически невозможно.
Где здесь появляется NSPM?
NSPM не должен искать бинарник Fire Ant внутри IOS XR. Это задача средств обнаружения угроз, forensic-инструментов и incident response.
Задача NSPM находится на другом уровне: постоянно контролировать состояние сетевой инфраструктуры и условия, которые позволяют такой атаке развиваться.
Можно выделить несколько сценариев.
1. Контроль hardening сетевого оборудования
Рекомендации Cisco можно превратить из документа на несколько десятков страниц в набор автоматически проверяемых требований.
Например
- Включён ли Management Plane Protection?
- С каких интерфейсов разрешён management-доступ?
- Доступны ли Telnet или HTTP?
- Используется ли SSH?
- Настроен ли централизованный AAA?
- Включён ли accounting?
- Куда отправляется syslog?
- Используется ли SNMPv3?
- Какие ACL защищают management plane?
- Есть ли доступ к интерфейсам управления из пользовательских или внешних сегментов?
NSPM может регулярно пересобирать конфигурации устройств и показывать отклонения от утверждённого security-профиля.
Таким образом, рекомендация Cisco превращается из разовой проверки после публикации статьи об атаке в постоянный контроль Security Posture.
2. Контроль изменений конфигурации
Fire Ant особенно интересен тем, что расследование началось с несоответствия между ожидаемым и фактическим состоянием сети.
Для сетевой инфраструктуры любое новое изменение — интерфейс, VRF, маршрут, ACL, туннель или изменение management-доступа — имеет смысл рассматривать в контексте:
Почему оно появилось?
Если NSPM знает предыдущую конфигурацию и интегрирован с Service Desk, изменение можно сопоставить с согласованной заявкой.
Появление нового административного доступа, изменения маршрутизации или туннеля без соответствующей заявки становится отдельным security-событием — Unauthorized Change.
Это не означает, что NSPM автоматически обнаружит имплант Fire Ant: в исследованной атаке вредоносное ПО специально изменяло вывод CLI и могло скрывать состояние устройства.
Но NSPM позволяет найти другой класс проблем — легитимные с точки зрения устройства, но несанкционированные с точки зрения процесса изменения сети.
3. Контроль доступности management plane
Ещё одна важная часть Fire Ant — дальнейшее движение из скомпрометированной инфраструктуры.
Здесь вопрос уже не в конкретной CVE:
Куда вообще можно попасть после компрометации маршрутизатора или jump-host?
NSPM может построить модель сетевой связности и определить:
- Какие системы имеют доступ к SSH/NETCONF/SNMP маршрутизаторов?
- Откуда доступен TACACS?
- Какие management-сегменты связаны между собой?
- Существуют ли неожиданные пути между пользовательской сетью и инфраструктурой управления?
- Куда можно двигаться после компрометации конкретного узла?
Появление нового пути можно рассматривать как New Exposure / Attack Path.
Таким образом, security-команда видит не только сам факт изменения ACL, но и его реальное последствие:
Раньше эта система не могла управлять маршрутизатором — теперь может.
4. Независимая проверка разных уровней сети
Fire Ant показывает ещё одну проблему: конфигурация устройства не всегда равна его фактическому состоянию.
Поэтому перспективная задача NSPM — сопоставлять несколько представлений сети:
Конфигурация → маршрутизация → интерфейсы и VRF → рассчитанная связность → фактическая доступность.
Если конфигурация говорит, что пути нет, но независимая проверка показывает доступность — это уже отдельный объект расследования.
Именно такая логика особенно важна в сценариях, где само сетевое оборудование потенциально нельзя считать абсолютно достоверным источником информации.
Патч необходим, но его недостаточно
Fire Ant — хороший пример того, как меняется роль сетевой инфраструктуры в модели угроз.
Маршрутизатор — это уже не просто устройство, которое пересылает пакеты. Он знает топологию сети, видит трафик, определяет маршруты, взаимодействует с AAA и часто имеет доверенные связи с десятками других систем. После его компрометации атакующий получает одновременно доступ, наблюдение и возможность влиять на доказательства своей активности. Поэтому защита такой инфраструктуры должна состоять минимум из трёх уровней:
Обновление ПО → hardening → непрерывный контроль конфигураций, изменений и сетевой связности.
Cisco закрывает первый уровень и даёт рекомендации для второго.
NSPM позволяет сделать третий уровень постоянным процессом: понимать, соответствует ли оборудование требованиям, кто и почему изменил сеть и не появился ли в результате новый путь атаки.
Главный вывод Fire Ant поэтому значительно шире конкретной атаки на IOS XR:
Сетевой инфраструктуре нельзя доверять просто потому, что она является сетевой инфраструктурой. Её состояние необходимо проверять так же системно, как состояние серверов и рабочих станций.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
