Кампания FortiBleed затронула более 430 тысяч межсетевых экранов FortiGate по всему миру и, похоже, вышла далеко за рамки очередной утечки логинов и паролей. В ходе атак на FortiGate злоумышленники, получив админский доступ, запускали на устройстве собственный инструмент для перехвата аутентификационного трафика и вытаскивали из него учетные данные, хэши и другие секреты, сообщает BleepingComputer.
Для русскоязычной IT-аудитории здесь важен не только масштаб, но и сам подход. Если исследование SOCRadar верно описывает механику кампании, то FortiGate в скомпрометированной инфраструктуре превращается из средства защиты в точку сбора корпоративных учетных данных. И это уже история не только про VPN, но и про возможный вход в AD, почту, базы данных и удаленный доступ.
SOCRadar пишет, что активность наблюдается как минимум с февраля 2026 года. Ранее компания уже связывала FortiBleed с массивом VPN-учеток Fortinet, который относился более чем к 80 тысячам URL-адресов файрволов. Теперь картина выглядит шире: речь идет о продолжающейся операции, где атакующий действует как initial access broker, то есть зарабатывает на первичном доступе в корпоративные сети. Набор методов вполне прозаичный и потому неприятный: credential stuffing, brute force, сбор учетных данных и офлайн-взлом паролей.
Ключевая находка исследователей — Go-инструмент, который они назвали FortigateSniffer. По их данным, он подключается к устройству по SSH и использует штатную команду FortiOS diagnose sniffer packet. Для администраторов это обычный диагностический механизм: посмотреть трафик, разобраться с маршрутизацией, проблемами аутентификации или сетевыми сбоями. Для атакующего с админскими правами — готовый сенсор внутри периметра, который видит то, что проходит через файрвол в реальном времени.
По описанию SOCRadar, инструмент отслеживал 24 протокола и сервисы, где можно поймать полезный аутентификационный материал. В списке фигурируют Kerberos, LDAP, SMB, RADIUS, RDP, WinRM, Microsoft SQL Server, MySQL, PostgreSQL, SMTP, IMAP, POP3, FTP и Telnet. То есть под угрозой оказывались не только VPN-сессии, а довольно широкий слой корпоративной инфраструктуры: доменная аутентификация, удаленное администрирование, почтовые сервисы и доступ к БД. Если коротко, атаки на FortiGate в такой модели дают злоумышленнику не один пароль, а шанс собрать целый каталог точек входа.
Дальше цепочка выглядела как вполне промышленный пайплайн. Захваченные пакеты, по данным исследователей, передавались в компонент SNIFTRAN, который восстанавливал трафик в PCAP-файлы. После этого уже Python-набор для глубокого анализа PCAP извлекал открытые пароли, хэши, Kerberos tickets, NTLM-материал, почтовые логины и данные для подключения к базам. Там, где пароль в трафике не лежал открытым текстом, система готовила файлы под Hashcat. Это уже не хакер с одним ноутбуком и плохим кофе, а аккуратно выстроенная конвейерная обработка добычи.
Отдельно неприятно, что история не сводится к одному вектору получения хэшей. BleepingComputer напоминает о комментарии исследователя Кевина Бомонта: по его версии, злоумышленники также могли скачивать конфигурационные файлы с уже скомпрометированных FortiGate, вытаскивать из них хэшированные секреты и затем ломать их через Hashcat. Бомонт указал, что для этого использовалась арендованная GPU-инфраструктура на 36 enterprise-class ускорителях. Ирония в том, что мощности, которые многие компании бронируют под GenAI-проекты, здесь работали на более прикладную задачу — массовый взлом паролей.
Важный нюанс: Fortinet ранее говорила BleepingComputer, что речь идет не о новой уязвимости, а о наборе уже ранее скомпрометированных учетных данных. Новый отчет SOCRadar не спорит напрямую с этим тезисом по части zero-day, но сдвигает акцент. Проблема не только в том, что кто-то где-то однажды потерял пароль от VPN. Проблема в том, что кампания, судя по этим данным, жива, масштабна и использует уже захваченные FortiGate для дальнейшего сбора секретов внутри сетевого трафика. Для служб ИБ это гораздо хуже, чем разовая публикация базы в даркнете: это намек на активную эксплуатацию доверенного узла в инфраструктуре.
Для разработчиков, DevOps-команд и IT-руководителей вывод довольно приземленный. Админский доступ к пограничному устройству больше нельзя рассматривать как локальную неприятность, изолированную в зоне сетевой безопасности. Если FortiGate стоит между пользователями, доменной инфраструктурой, почтовыми системами и внутренними сервисами, то его компрометация быстро становится вопросом lateral movement и повторного захвата учетных записей. Особенно там, где еще живы устаревшие протоколы, слабые пароли, повторное использование секретов и сервисные аккаунты без нормальной сегментации прав.
Практическая часть тоже лежит на поверхности. Если в компании используются FortiGate, нужно проверять не только факт утечки VPN-логинов, но и признаки административного доступа к устройству, запуск диагностических команд, аномальную активность по SSH, выгрузку конфигурации и попытки последующего использования доменных или почтовых учеток. Отдельный вопрос — сколько организаций вообще воспринимают сетевой файрвол как потенциальный источник кражи credentials, а не только как объект защиты. Судя по масштабу FortiBleed, атакующие уже определились с ответом.
Следующий этап этой истории, вероятно, будет связан не с поиском очередной громкой уязвимости, а с переоценкой доверия к пограничным устройствам и к диагностическим функциям внутри них. Когда штатный инструмент troubleshooting превращается в сенсор для кражи секретов, граница между «администрированием» и «эксплуатацией после компрометации» становится слишком тонкой. Первоисточник с деталями кампании опубликован .