Файрволы нового поколения FortiGate, которые компании ставят для защиты своих сетей, стали для злоумышленников удобной точкой входа. Исследователи из SentinelOne — Алекс Деламотт, Стивен Бромфилд, Мэри Брейден Мёрфи и Эйми Патне — описали два независимых друг от друга инцидента, в которых атакующие проникали через устройства FortiGate NGFW, вытаскивали конфигурационные файлы и добирались до учётных данных сервисных аккаунтов. Фактически файрвол, призванный охранять инфраструктуру, отдавал нападающим карту сети и ключи от неё.
Целями атак стали организации из сфер здравоохранения, государственного управления и управляемых сервисов (MSP). Эксплуатировались известные уязвимости — CVE-2025-59718, CVE-2025-59719 и CVE-2026-24858, а в некоторых случаях хватало обычных слабых паролей. Проблема в том, что файрволы нового поколения по своей природе глубоко интегрированы в корпоративную среду: они подключены к Active Directory через LDAP для реализации ролевых политик, и компрометация такого устройства даёт атакующему куда больше, чем доступ к одному серверу.
Первый инцидент, зафиксированный в ноябре 2025 года, развивался по классической схеме работы брокера начального доступа (Initial Access Broker). Злоумышленники взломали устройство FortiGate, создали новую локальную учётную запись администратора с именем «support» и настроили четыре дополнительные политики файрвола, снимающие ограничения на прохождение трафика между зонами. После этого они периодически заходили, проверяя работоспособность доступа — поведение, типичное для тех, кто собирается продать точку входа другим преступным группам.
В феврале 2026 года те же или другие злоумышленники перешли к активной фазе. Из устройства был извлечён конфигурационный файл с зашифрованными LDAP-учётками. Шифрование не помогло: файл расшифровали и получили пароль сервисного аккаунта «fortidcagent» в открытом виде. С этими данными атакующие аутентифицировались в Active Directory и зарегистрировали в домене свои рабочие станции, обеспечив себе стабильный плацдарм внутри сети.
Второй инцидент произошёл в конце января 2026 года, и действовали здесь гораздо быстрее. Пробив файрвол, нападавшие моментально развернули средства удалённого управления — Pulseway и MeshAgent. Через PowerShell подтянули вредоносное Java-приложение из облачного хранилища Amazon Web Services. Запустили его с помощью DLL side-loading, после чего украли файл NTDS.dit и ветку реестра SYSTEM — по сути, полную базу доменных паролей. Данные ушли на внешний сервер по адресу 172.67.196[.]232 через порт 443. Между моментом кражи и моментом обнаружения взлома злоумышленники, правда, не успели воспользоваться украденными учётками для дальнейшего проникновения.
Алекс Деламотт в комментарии изданию The Hacker News отметила, что между двумя инцидентами нет доказанной связи. Техника после получения начального доступа существенно отличалась, что указывает на разных акторов. Среди тех, кого интересуют подобные атаки, — и прогосударственные шпионские группировки, и обычные вымогатели-рансомщики.
Одна из ключевых проблем, общая для обоих случаев, — отсутствие нормального логирования на файрволах. Защитники попросту не могли восстановить точную картину: когда именно произошло первичное проникновение и какой конкретно вектор использовался. Без логов расследование инцидента превращается в гадание. Специалисты SentinelOne дали по этому поводу прямую рекомендацию: хранить логи файрволов минимум 14 дней и обязательно отправлять их в SIEM-систему. Если логи хранятся только на самом устройстве, атакующий просто удалит их и замёт следы.
Показательно, что промежуточные файлы в обоих случаях размещались по путям USOShared — это нестандартные каталоги, которые злоумышленники выбирают, чтобы не привлекать внимание среди системных файлов. Мелочь, но характерная: профессиональные атакующие думают о маскировке на каждом этапе.
Эти инциденты показывают неприятную реальность. Устройства, которым компании доверяют периметровую защиту, сами становятся слабым звеном, когда администраторы не обновляют прошивки, используют слабые пароли и не настраивают журналирование. А учитывая, что FortiGate NGFW по архитектуре имеет доступ к доменным учёткам и видит структуру сети, цена ошибки здесь выше, чем при компрометации рядового сервера.
Изображение носит иллюстративный характер
Целями атак стали организации из сфер здравоохранения, государственного управления и управляемых сервисов (MSP). Эксплуатировались известные уязвимости — CVE-2025-59718, CVE-2025-59719 и CVE-2026-24858, а в некоторых случаях хватало обычных слабых паролей. Проблема в том, что файрволы нового поколения по своей природе глубоко интегрированы в корпоративную среду: они подключены к Active Directory через LDAP для реализации ролевых политик, и компрометация такого устройства даёт атакующему куда больше, чем доступ к одному серверу.
Первый инцидент, зафиксированный в ноябре 2025 года, развивался по классической схеме работы брокера начального доступа (Initial Access Broker). Злоумышленники взломали устройство FortiGate, создали новую локальную учётную запись администратора с именем «support» и настроили четыре дополнительные политики файрвола, снимающие ограничения на прохождение трафика между зонами. После этого они периодически заходили, проверяя работоспособность доступа — поведение, типичное для тех, кто собирается продать точку входа другим преступным группам.
В феврале 2026 года те же или другие злоумышленники перешли к активной фазе. Из устройства был извлечён конфигурационный файл с зашифрованными LDAP-учётками. Шифрование не помогло: файл расшифровали и получили пароль сервисного аккаунта «fortidcagent» в открытом виде. С этими данными атакующие аутентифицировались в Active Directory и зарегистрировали в домене свои рабочие станции, обеспечив себе стабильный плацдарм внутри сети.
Второй инцидент произошёл в конце января 2026 года, и действовали здесь гораздо быстрее. Пробив файрвол, нападавшие моментально развернули средства удалённого управления — Pulseway и MeshAgent. Через PowerShell подтянули вредоносное Java-приложение из облачного хранилища Amazon Web Services. Запустили его с помощью DLL side-loading, после чего украли файл NTDS.dit и ветку реестра SYSTEM — по сути, полную базу доменных паролей. Данные ушли на внешний сервер по адресу 172.67.196[.]232 через порт 443. Между моментом кражи и моментом обнаружения взлома злоумышленники, правда, не успели воспользоваться украденными учётками для дальнейшего проникновения.
Алекс Деламотт в комментарии изданию The Hacker News отметила, что между двумя инцидентами нет доказанной связи. Техника после получения начального доступа существенно отличалась, что указывает на разных акторов. Среди тех, кого интересуют подобные атаки, — и прогосударственные шпионские группировки, и обычные вымогатели-рансомщики.
Одна из ключевых проблем, общая для обоих случаев, — отсутствие нормального логирования на файрволах. Защитники попросту не могли восстановить точную картину: когда именно произошло первичное проникновение и какой конкретно вектор использовался. Без логов расследование инцидента превращается в гадание. Специалисты SentinelOne дали по этому поводу прямую рекомендацию: хранить логи файрволов минимум 14 дней и обязательно отправлять их в SIEM-систему. Если логи хранятся только на самом устройстве, атакующий просто удалит их и замёт следы.
Показательно, что промежуточные файлы в обоих случаях размещались по путям USOShared — это нестандартные каталоги, которые злоумышленники выбирают, чтобы не привлекать внимание среди системных файлов. Мелочь, но характерная: профессиональные атакующие думают о маскировке на каждом этапе.
Эти инциденты показывают неприятную реальность. Устройства, которым компании доверяют периметровую защиту, сами становятся слабым звеном, когда администраторы не обновляют прошивки, используют слабые пароли и не настраивают журналирование. А учитывая, что FortiGate NGFW по архитектуре имеет доступ к доменным учёткам и видит структуру сети, цена ошибки здесь выше, чем при компрометации рядового сервера.
