Статья CVE-2026-35616: эксплуатация уязвимости FortiClient EMS — от API bypass до захвата Fortinet-инфраструктуры

31 марта 2026 года сенсоры watchTowr зафиксировали первые попытки эксплуатации уязвимости, для которой не было ни advisory, ни патча. Четырьмя днями позже, в пасхальную субботу, Fortinet выкатила бюллетень FG-IR-26-099. К этому моменту атакующие уже сидели внутри затронутых инфраструктур. Пасхальная суббота - серьёзно. SOC в полсилы, дежурный смотрит в потолок, а окно между компрометацией и детектом растягивается с часов до дней.

CVE-2026-35616 - pre-auth RCE с CVSS 9.8 в FortiClient EMS версий 7.4.5–7.4.6. Не академическая уязвимость из бюллетеня, а рабочий вектор, который эксплуатировался как zero-day. Бенджамин Харрис, CEO watchTowr, сказал CyberScoop прямо: атакующие давно поняли, что праздники - лучшее время для работы.

Здесь я разберу механику эксплуатации FortiClient EMS уязвимости с позиции пентестера: от разведки и API bypass до lateral movement через Fortinet-инфраструктуру, включая обход FortiSandbox и манипуляцию VPN-политиками. Без пересказа NVD - с объяснением, почему этот баг работает и как его ловить без официальных IOC.

FortiClient EMS в корпоративной сети: почему это главная цель пентестера​

FortiClient EMS - не просто сервер мониторинга. Это центральный management plane всей endpoint-инфраструктуры Fortinet. Через него проходит управление агентами FortiClient на каждом endpoint: установка, конфигурация, обновления, телеметрия, VPN-политики и compliance-проверки.

На red team-проектах я всегда рисую карту взаимодействий EMS с остальными компонентами Fortinet Security Fabric - и каждый раз удивляюсь, сколько всего завязано на одну точку:

• FortiClient-агенты на endpoint'ах получают политики и шлют телеметрию через EMS
• FortiGate использует compliance-данные от EMS для решений по сетевому доступу в рамках ZTNA
• FortiSandbox получает от EMS файлы на динамический анализ - и именно EMS-политики определяют, что уходит в песочницу, а что пропускается
• FortiAnalyzer собирает логи от EMS для корреляции событий

С точки зрения пентеста Fortinet-инфраструктуры, компрометация EMS - это джекпот. Атакующий получает возможность рулить защитой на всех endpoint'ах, раскатывать произвольные пакеты через легитимный push-механизм, получать доступ к телеметрии с VPN-токенами и манипулировать FortiSandbox-интеграцией. Один сервер - и вся endpoint-защита организации у тебя в кармане.

По данным Shadowserver, около 2000 экземпляров FortiClient EMS торчат в интернет. Даже если часть - honeypot'ы, это сотни реальных EMS-серверов с прямым внешним доступом, чего по всем рекомендациям Fortinet быть не должно. Но кого когда останавливали рекомендации.

Разбор CVE-2026-35616: Improper Access Control в API FortiClient EMS​

По NVD, уязвимость CVE-2026-35616 описана так: «An improper access control vulnerability in Fortinet FortiClientEMS 7.4.5 through 7.4.6 may allow an unauthenticated attacker to execute unauthorized code or commands via crafted requests». Классификация - CWE-284 (Improper Access Control). Затронуты FortiClient EMS 7.4.5 и 7.4.6.

Замечу отдельно: в некоторых русскоязычных источниках гуляет ошибочная формулировка - мол, «уязвимость затрагивает версии 7.4.5 и более ранние, а 7.4.6 устраняет недостатки». Это неверно. По данным NVD, уязвимы обе версии - и 7.4.5, и 7.4.6. Исправление - только через hotfix или обновление до 7.4.7.

CVSS-вектор 9.8 - что означает для Fortinet-пентеста​

Вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - один из наихудших возможных:

Компонент	Значение	Что это значит для атакующего
AV:N	Network	Эксплуатация удалённая, по сети. Физический доступ не нужен
AC:L	Low	Нет race condition, нет сложных зависимостей. Один запрос - один результат
PR:N	None	Pre-auth. Учётка не требуется
UI:N	None	Жертве не нужно ничего делать. Полная автоматизация
S:U	Unchanged	Формально scope ограничен EMS-сервером
C:H / I:H / A:H	High	Полная компрометация конфиденциальности, целостности и доступности

Fortinet в своём advisory указала CVSS 9.1, NVD присвоила 9.8. Разница - в интерпретации отдельных компонентов, но для практики это ничего не меняет: перед нами pre-auth RCE, доступный любому, кто может достучаться до EMS по сети.

Формально S:U (Scope: Unchanged) - impact ограничен самим EMS-сервером. Но в реальности (как я описал выше) захват EMS открывает дверь ко всей endpoint-инфраструктуре организации. До теоретических 10.0 не дотягивает только этот компонент, а blast radius фактически распространяется на каждую машину с FortiClient-агентом.

Корневая причина - отсутствие проверки аутентификации и авторизации на API-эндпоинтах. По данным Kudelski Security, уязвимость связана с «inadequate validation of user credentials or session tokens for sensitive API endpoints». По данным The Hacker News - «pre-authentication API access bypass leading to privilege escalation».

Ключевое слово из advisory - «bypass», а не «brute-force» или «injection». Механизм аутентификации не взламывается и не обходится через инъекцию - он просто не применяется к определённым запросам. Для пентестера это знакомый до зубной боли паттерн: routing-правила API не покрывают все комбинации path, HTTP-метода и заголовков, и конкретный endpoint оказывается голым - без auth-middleware. Разработчики добавляют новый route, забывают навесить auth-декоратор. Я видел такое десятки раз при аудите корпоративных REST API - классика жанра.

CVE-2026-21643: SQL-инъекция как параллельный вектор атаки​

CVE-2026-35616 FortiClient EMS уязвимость - не изолированный инцидент. CVE-2026-21643 - SQL-инъекция (CWE-89) в версии 7.4.4 с тем же CVSS 9.8 и идентичным вектором CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Параметр	CVE-2026-35616	CVE-2026-21643
Тип	Improper Access Control (CWE-284)	SQL Injection (CWE-89)
Версии	7.4.5 – 7.4.6	7.4.4
CVSS	9.8 (CRITICAL)	9.8 (CRITICAL)
Pre-auth	Да	Да
Условие	Нет дополнительных условий	Multitenancy: SITES_ENABLED=True
Zero-day	Да, эксплуатировалась с 31.03.2026	Да, кампании зафиксированы Defused Cyber
Исправление	Hotfix 7.4.5.2111 / 7.4.6.2170, полный патч в 7.4.7	Обновление до 7.4.5+

По данным Greenbone, CVE-2026-21643 внесли при рефакторинге слоя подключения к базе данных в версии 7.4.4. Эксплуатируемость зависит от включённой мультиарендности: при отключённой multitenancy middleware vdom захардкожен и не читает контролируемый атакующим заголовок Site, поэтому уязвимый путь остаётся, но становится недоступным.

Для Fortinet CVE 2026 разбора вектора атаки хронология примечательная: организация, обновившаяся с 7.4.4 до 7.4.5 для закрытия SQL-инъекции, немедленно попала под новый zero-day - improper access control. Обновился, закрыл одну дыру - и тут же влетел в другую. Два последовательных pre-auth RCE в одном продукте за считанные недели - это уже не случайность, а системная проблема quality assurance в кодовой базе. По данным Tenable, на CISA KEV сейчас 24 CVE от Fortinet, 13 из которых связаны с ransomware-кампаниями.

6 апреля CISA внесла CVE-2026-35616 в каталог Known Exploited Vulnerabilities с дедлайном для федеральных агентств 9 апреля - три дня на патчинг. Такой агрессивный срок однозначно указывает: атаки уже затронули правительственную инфраструктуру.

Эксплуатация FortiClient EMS: практический вектор атаки​

Требования к окружению​

Прежде чем переходить к практике, зафиксируем стенд:

• Целевая система: FortiClient EMS 7.4.5 или 7.4.6 без hotfix
• ОС EMS-сервера: Windows Server (EMS работает исключительно на Windows)
• Сетевой доступ: TCP/443 (HTTPS) к EMS-серверу. В боевых условиях - прямой доступ из интернета или из внутренней сети после initial access
• Инструменты: Burp Suite для перехвата и модификации запросов, curl для ручных проверок, nmap с http-скриптами для fingerprinting
• Опционально: Python 3.x для автоматизации, Wireshark / tcpdump для анализа трафика между агентом и EMS

Разведка и идентификация уязвимых инстансов​

Первый шаг - понять, что перед нами FortiClient EMS, и установить версию.

Fingerprinting по favicon. FortiClient EMS имеет характерную иконку. RunZero ищет по хешу: favicon.ico.image.mmh3:=-800551065. Тот же подход работает через Shodan и Censys - запрос по MurmurHash3 иконки позволяет найти EMS-инстансы без отправки подозрительных запросов к самому серверу. Тихо, аккуратно.

Nmap-сканирование. Базовый скан с определением сервиса: nmap -sV -p 443,8013 --script http-title,ssl-cert <target>. Порт 8013 часто используется FortiClient EMS для коммуникации с агентами. SSL-сертификат может содержать CN с упоминанием Fortinet.

Версия через HTTP-ответы. При обращении к веб-интерфейсу EMS через Burp Suite перехватите ответы - в JavaScript-файлах и HTML-meta иногда проскакивают строки с номером версии. Не всегда, но проверить стоит.

На GitHub появился публичный PoC (репозиторий 0xBlackash/CVE-2026-35616). По данным Tenable, на момент публикации PoC не был ими верифицирован. Настоятельно рекомендую не запускать непроверенные PoC на боевых проектах - сначала code review и тестирование в изолированной лабе. Видел случаи, когда «PoC» содержал бэкдор для автора.

API bypass и выполнение кода​

Fortinet не раскрыла конкретные уязвимые эндпоинты, но по совокупности данных из advisory и публичных исследований восстанавливается общий паттерн эксплуатации FortiClient EMS:

1. Идентификация API-endpoint'а: FortiClient EMS предоставляет REST API для управления endpoint'ами и административными операциями. Crafted requests направляются к эндпоинтам, которые должны быть защищены auth-middleware, но из-за CWE-284 обрабатываются без проверки аутентификации.
2. Обход аутентификации: специально сформированные HTTP-запросы полностью пропускают auth-слой. Определённые комбинации пути, метода и заголовков не попадают под проверку middleware - это не взлом аутентификации, а её отсутствие на конкретном маршруте. Auth просто не навесили.
3. Выполнение кода: после обхода аутентификации атакующий получает функциональность, эквивалентную административной, включая возможность выполнения произвольного кода на EMS-сервере от имени сервисного аккаунта.

# Разведка EMS API - проверка концепции
# НЕ рабочий эксплойт, только fingerprinting

# Проверяем, отвечает ли API без аутентификации
curl -sk -o /dev/null -w "%{http_code}" \
  https://<target>:443/api/v1/endpoints
# 200 = endpoint доступен без auth (потенциально уязвим)
# 401/403 = auth-middleware на месте

По данным watchTowr, к 6 апреля эксплуатация резко усилилась. Бенджамин Харрис отметил в CyberScoop: «Первоначально попытки были ограниченными - типичное стремление атакующих сохранить zero-day от обнаружения. После публикации hotfix'а и внимания исследователей эксплуатация резко возросла». Характерный паттерн: hotfix позволяет через diff-анализ восстановить точный вектор атаки. Выпустил патч - раздал атакующим карту.

Пост-эксплуатация: от FortiClient EMS до контроля Fortinet-инфраструктуры​

Kill chain по MITRE ATT&CK​

На основе характеристик CVE-2026-35616 и типичных сценариев компрометации EMS-серверов выстраивается цепочка:

📚 Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Корпоративная VPN атака через скомпрометированный EMS - не теоретический сценарий. Это прямое следствие любой компрометации control plane. По данным watchTowr, при аудите после инцидента необходимо проверять VPN-конфигурации, application firewall rules, endpoint compliance profiles и admin access controls. Всё, к чему EMS имел доступ - считай скомпрометированным.

Детектирование эксплуатации CVE-2026-35616: техники хантинга​

По данным watchTowr, Fortinet не опубликовала IOC для CVE-2026-35616. Вендор молчит - значит, детектирование целиком на нас. Вот конкретные подходы для хантинга:

Аномальный трафик к EMS API. Ищите нехарактерные HTTP-запросы к API-эндпоинтам - особенно POST/PUT с нестандартными заголовками. В логах веб-сервера EMS обратите внимание на запросы, возвращающие 200 OK к административным эндпоинтам с IP-адресов, не принадлежащих управляемым endpoint'ам. Если к /api/v1/admin/ стучится IP из Бангладеша - это повод напрячься.

Создание новых admin-аккаунтов. По данным Critical Path Security, это один из первых шагов атакующих. Мониторьте EMS audit logs на предмет создания пользователей вне плановых окон изменений.

Неожиданные процессы на EMS-сервере. EDR-телеметрия с самого EMS-сервера - главный источник. Ищите cmd.exe, powershell.exe или certutil.exe, запущенные от имени сервисного аккаунта EMS, а также сетевые подключения к внешним IP, не входящим в список FortiGuard-серверов.

# Поиск подозрительных дочерних процессов EMS (Windows Security Log)
Get-WinEvent -LogName Security -FilterXPath `
  "*[System[(EventID=4688)]]" |
  Where-Object {
    $_.Properties[13].Value -match "FortiClientEMS" -and
    $_.Properties[5].Value -match "(cmd|powershell|certutil)"
  } | Select-Object TimeCreated,
    @{N='NewProcess';E={$_.Properties[5].Value}},
    @{N='ParentProcess';E={$_.Properties[13].Value}}

Массовое изменение endpoint-политик. Любое изменение политик безопасности, не подтверждённое в change management - повод для немедленного расследования. Особенно если одновременно отключаются модули защиты или меняются VPN-конфигурации на множестве endpoint'ов. Массовое изменение = кто-то рулит вашим EMS.

Сетевой мониторинг. Настройте Zeek или Suricata-алерты на HTTP-запросы к EMS-серверу с нехарактерных IP. Если EMS должен взаимодействовать только с endpoint'ами внутренней сети, любой запрос с внешнего адреса - индикатор компрометации.

Ключевой принцип: если EMS был доступен из интернета на затронутых версиях - исходите из предположения, что он уже скомпрометирован. Не «возможно скомпрометирован», а «скомпрометирован, пока не доказано обратное». По рекомендации Critical Path Security, проведите forensic review: системные логи, список admin-аккаунтов, изменения endpoint-политик, VPN-конфигурации. Если не можете подтвердить целостность - полный rebuild EMS-инстанса с миграцией данных.

Патчинг и компенсирующие меры для Fortinet-инфраструктуры​

Fortinet выпустила hotfix'ы для обеих затронутых версий:

Версия	Hotfix	Полный патч
FortiClient EMS 7.4.5	7.4.5.2111	Обновление до 7.4.7
FortiClient EMS 7.4.6	7.4.6.2170	Обновление до 7.4.7

Hotfix применяется без downtime. Это снимает главный аргумент против экстренного патчинга - нет необходимости останавливать EMS. Отговорки кончились. FortiClient EMS 7.2 и более ранние версии не затронуты CVE-2026-35616.

Компенсирующие меры, пока патч не применён:

1. Ограничить сетевой доступ - EMS не должен торчать в интернет. Ограничьте trusted management-сетью. Самая эффективная мера, и она же самая очевидная
2. Сегментация - EMS-сервер в отдельном management-сегменте, изолированном от пользовательской сети
3. Максимальное логирование - включите audit logging на EMS и настройте отправку в SIEM в реальном времени
4. Аудит аккаунтов - проверьте список администраторов EMS, удалите неопознанные учётные записи. Если видите аккаунт, который никто не создавал - у вас проблемы
5. Service account hardening - убедитесь, что EMS работает от аккаунта с минимально необходимыми привилегиями

Относитесь к EMS как к Tier 0 активу - наравне с контроллерами домена Active Directory. SLA на патчинг для internet-facing EMS: менее 24 часов. Как сказал Бенджамин Харрис из watchTowr: «Лучшее время применить hotfix - вчера. Второе лучшее - прямо сейчас».

Вопрос к читателям​

Для тех, кто проводил forensics или red team против FortiClient EMS версий 7.4.5–7.4.6: при анализе логов EMS-сервера какой паттерн HTTP-запросов оказался наиболее показательным для детектирования API bypass - аномальные User-Agent, нестандартные пути к API-эндпоинтам, или специфические комбинации HTTP-методов с заголовками? Если настраивали Suricata-правила для мониторинга трафика к EMS на порту 443/8013 без официальных IOC от Fortinet - поделитесь сигнатурой, интересно сравнить подходы к детекту CVE-2026-35616 в условиях, когда вендор молчит.