Анатомия кампании FortiBleed, основанная на анализе сервера, оставленного незащищенным (перевод)

Краткое содержание:​

19 июня 2026 года мы получили доступ к содержимому открытого в интернете каталога, оставленного самими операторами кампании, которую пресса назвала FortiBleed. Это была не утечка данных жертвы. Это был командный пункт злоумышленников: примерно 318 файлов, содержащих инструменты, скрипты, списки целей, операционные журналы и украденные данные глобальной операции по краже учетных данных у межсетевых экранов Fortinet FortiGate.

В ходе анализа выяснилось, что это была не группа «хакеров» в классическом понимании, а нечто, больше похожее на промышленный конвейер. Операция состояла из четырех взаимосвязанных этапов (массовое сканирование и перехват трафика, извлечение учетных данных, взлом хэшей в автономном режиме и перемещение внутри Active Directory), многооператорной команды с контролем, гибкой мощностью взлома, арендуемой по запросу, и, что удивительно, автономного агента для пентестинга на основе ИИ, встроенного в арсенал.

В этом отчете мы реконструируем эту операцию на основе проанализированных нами файлов. Участники кампании (приблизительно 73 932 межсетевых экрана в 194 странах, около 21 632 доменов, почти половина всех устройств Fortinet, подключенных к интернету) получают доступ к серверу и понимают, как именно происходил сбор данных, их очистка, как определялись приоритеты целей в зависимости от дохода и как доступ к межсетевому экрану приводил к компрометации домена.

Не удалось прогрузить медиа

1. Как мы к этому пришли​

1.1 Обнаружение открытого каталога​

Кампания FortiBleed стала достоянием общественности 17 июня 2026 года после того, как исследователь Владимир «Боб» Дяченко обнаружил доступный через интернет сервер, связанный с атакующей группой. Исследователь Кевин Бомонт лично проверил учетные данные из этого набора в нескольких организациях и подтвердил, что они реальны и активны. Уникальность этого случая заключается в простом факте: группа оставила свой собственный рабочий каталог открытым, с инструментами, строками подключения, скриптами и данными, доступными без аутентификации.

Именно этот набор файлов мы получили для анализа. Далее мы описываем то, что мы обнаружили после их открытия, в порядке, в котором результаты начали обретать смысл.

1.2 Что мы получили​

Материал представляет собой снимок работающего сервера. Файлы имеют дату копирования 7 июня 2026 года, но внутренние метки времени (логи, сборки, захваты) концентрируют активность в период с 19 мая по 7 июня 2026 года. Контент распределен по пяти уровням, которые стали дорожной картой нашего расследования:

1. Оркестрация взлома (Telegram-бот, Hashtopolis, hashcat, GPU).
2. Сбор и перехват учетных данных FortiGate (веб-автоматизация, захват сессий, сборщик трафика).
3. Конвейер обработки данных (очистка, дедупликация, удаление ловушек, OSINT и обогащение дохода).
4. Постэксплуатация и горизонтальное перемещение (impacket через LDAP, SMB и Kerberos, распыление паролей, аудит Active Directory).
5. Инфраструктура (виртуальные машины Kali на KVM, многооператорная SSH-сеть, пользовательская веб-панель и агент ИИ для наступательных операций).

​

1.3 Область применения, цели и ответственное обращение​

Наша цель – оборонительная: понять методы мошенничества, выявить действенные индикаторы и обеспечить оповещение жертв. Поэтому в данном отчете пароли и индивидуальные идентификаторы были скрыты или агрегированы. Индикаторы, которые мы публикуем полностью, относятся к стороне злоумышленника (IP-адреса командного пункта, токены, ваучеры, ключи, внедренные учетные записи), поскольку они служат защите.

2. Что такое FortiBleed​

2.1 Общая картина​

FortiBleed — это масштабная кампания по компрометации учетных данных устройств Fortinet FortiGate, то есть межсетевых экранов и SSL-VPN-концентраторов этих организаций. Опубликованные в прессе данные поражают: примерно 73 932 уникальных URL-адреса межсетевых экранов в 194 странах, около 21 632 затронутых доменов и почти половина всех устройств Fortinet, подключенных к интернету.

Объем активности также впечатляет: примерно 1,16 миллиарда попыток взлома учетных данных против 320 777 целевых устройств FortiGate, плюс 2,1 миллиарда попыток перебора против 163 650 хостов Microsoft SQL Server, что показывает, что операция вышла далеко за пределы Fortinet.

Несмотря на название, напоминающее «Heartbleed», FortiBleed — это не ошибка памяти и не изолированная уязвимость. Это операция по сбору учетных данных в сочетании с взломом в автономном режиме в промышленных масштабах. Пресса связывает контекст с CVE-2026-24858 (уязвимость, позволяющая обойти аутентификацию FortiCloud SAML SSO с поддержкой CVSS до версии 9.8, раскрытая компанией Fortinet 27 января 2026 года), но подтверждения того, что весь сбор данных произошел именно из-за этой уязвимости, нет. Кампанию усилило хранение учетных данных со слабыми схемами хеширования (SHA-256 с солью) в старых конфигурациях, что делает возможным взлом в автономном режиме, а также повторное использование паролей и открытые интерфейсы управления и VPN.

2.2 Место этого сервера​

Проанализированный нами сервер является частью атакующей инфраструктуры этой кампании. Он содержит обе стороны истории: инструменты, генерирующие атаку, и результаты (учетные данные, хеши, списки жертв). Это возможность прочитать «производственную линию» изнутри.

Не удалось прогрузить медиа

​

3. Этап 1: массовое сканирование и перехват трафика​

Два самых больших файла в каталоге назывались crash_170.log и crash2.log и на первый взгляд выглядели как дампы ошибок. Но это было не так. Открыв их, мы обнаружили операционные журналы механизма сканирования и перехвата трафика, компонента, отличного от сборщика данных.

​

3.1 Механизм сканирования и перехвата трафика​

Журнал открывается с бинарным идентификатором: GOOS=windows GOARCH=amd64 CPUs=40 GOMAXPROCS=40. Другими словами, сканер — это инструмент, написанный на Go и работающий под управлением Windows с 40 ядрами. Он начинает с настройки системы для экстремального масштаба соединений с помощью netsh и редактирования реестра, а затем загружает базу данных GeoIP (ipgeo.csv) с 737 379 сетями.

Операция выполняется в конвейере 300-минутных (пятичасовых) циклов, с отображением статуса каждую минуту. В каждом цикле загружается региональный список целей (в данном случае EU.txt, содержащий 6127 устройств) и выполняется проверка с помощью 1000 одновременных потоков, отображая счетчики успеха, неудачи, таймаута и предупреждения. В первых циклах процент успешных проверок составлял около 90%. В этом журнале мы насчитали 22 запуска, 114 циклов и приблизительно 4202 различных публичных IP-адреса только из европейской кампании.

3.2 Защита от криминалистического анализа

Один параметр конвейера привлек наше внимание: delete_txt=true и, прежде всего, delete_pcapng=true. Система удаляет собственные перехваченные данные трафика после их обработки. Это преднамеренное решение, направленное на защиту от криминалистического анализа: необработанный трафик, который был бы наиболее весомым доказательством, уничтожается, и остаются только уже извлеченные учетные данные. Это уменьшает занимаемое дисковое пространство и затрудняет криминалистический анализ в случае захвата сервера.

Не удалось прогрузить медиа

4. Этап 2: сбор учетных данных​

Вот главный вывод всего расследования, скрытый в файле, который на начальном этапе был обозначен просто как «статический ELF, механизм сканирования».

Файл harvest_orig представляет собой 64-битный ELF-бинарный файл, статический, скомпилированный на Go (с присутствующей средой выполнения crypto/internal/fips140), не очищенный от символов, размером 4,3 МБ. Его хеш SHA-256 равен 2758f4d71a2a2dfdefab81737c2d776b2a3dafe5844fdd2157e089a28447ca98, а BuildID — 268a8420b791df46380ed9ad69905207e15d8a7c. Его флаги командной строки — –harvest-only и –threads=N. Когда мы запустили на нём строки, его роль стала очевидной. Сообщения типа «Найдено %d файлов захвата (%d больших >5 МБ, %d маленьких в %d пакетах)» и «Захвачено из PCAP» показывают, что он обрабатывает файлы захвата трафика (PCAP) в автономном режиме, пакетами, в многопоточном режиме, с отображением прогресса в гигабайтах обработанного трафика и МБ/с. Он является дополнением к сканеру первого этапа: сканер захватывает трафик, а harvest_orig его обрабатывает.

Каталог выходных файлов сборщика, извлеченный из строк, объясняет происхождение почти всего набора данных сервера. Он извлекает учетные данные практически из каждого протокола, проходившего через захваченную сеть:

Аутентификация Windows и Kerberos: NTLMv1, NTLMv2, предварительная аутентификация Kerberos RC4, AS-REP, Kerberoast и предварительная аутентификация AES.

Веб-сервисы и каталоги: HTTP (Basic, Form и JSON), LDAP (привязка DN и пароля).
Базы данных и сервисы: MSSQL, MySQL, FTP, Telnet, RADIUS, SNMP (сообщества), SSH (баннеры).
Общие данные: открытый текст, токены аутентификации, сессионные cookie.

Каждые учетные данные выдаются с контекстом источника и назначения (формат источник -> назначение | протокол | тип | учетные данные), что в точности соответствует формату, который мы видели в файлах all_creds_with_context.txt, real_http_creds.txt и ldap_creds.txt. Сборщик также заблаговременно выделяет файл с привилегированными учетными записями и использует специальное регулярное выражение для извлечения имен пользователей из параметров HTTP.

Среди выходных файлов есть набор, посвященный электронной почте: адреса, сообщения с учетными данными, сводка и, что особенно важно, вложения электронной почты (emails/email_attachments.txt). Сборщик данных не ограничивается учетными данными; он восстанавливает и извлекает содержимое электронных писем, перехваченных во время передачи.

Это имеет значение для корректировки общедоступной информации. Говорят, что группа «перехватила хеши аутентификации SSL-VPN». В действительности все гораздо шире: из трафика, прошедшего через скомпрометированные устройства FortiGate (напомним, что существует робот, описанный в файле fg_capture.log, который каждые 20 минут заходит в панель администратора и выгружает таблицу сессий), harvest_orig извлекает все типы учетных данных и даже содержимое электронных писем, уже обогащенное контекстом и с выделенными привилегированными учетными записями. Этот бинарный файл является нулевой стадией, которая питает весь конвейер очистки и обогащения. Название harvest_orig, «собирать оригинал», предполагает, что это была эталонная версия инструмента.

5. Этап 3: взлом в офлайн-режиме в промышленных масштабах​

Уровень взлома хешей распределен. Скрипты setup_hashtopolis.sh и setup_agent.sh запускают сервер Hashtopolis по адресу 85.XX.1XX.8:8443 с ключом доступа HP_MASTER_KEY_2026 и настраивают агенты с ваучером VAST-GPU-2026. Префикс «VAST» многое говорит: графические процессоры предоставлены Vast.ai, торговой площадкой для аренды видеокарт по запросу. Другими словами, возможности взлома являются гибкими и одноразовыми: они включаются при наличии очереди хешей, выключаются после этого и практически невозможно отключить аппаратным способом. Файл ht_agent.zip в каталоге содержит официальный агент Hashtopolis (версия 0.7.2), который работает на каждом арендованном графическом процессоре.

5.1 Telegram-бот​

Управление кластером осуществляется через Telegram-бота, файл bot.py, содержащий 4525 строк кода. В заголовке он описывает себя как «Telegram Hashcat Bot, NetNTLMv2 Cracker v10». Администратором является @XXXXsome (пользователь XXXX), авторизация осуществляется по имени пользователя Telegram, а токен бота в коде находится в открытом виде. Бот объявляет пул из 10 видеокарт RTX 4090, управляет задачами параллельно и отправляет в чат только взломанные пароли и итоговое резюме, без лишнего шума.


Бот поддерживает девять режимов хеширования hashcat, и один только этот список демонстрирует широту его возможностей: NetNTLMv2 (5600), FortiGate в MD5 (7000) и SHA-256 (26300), IPMI RAKP (7300), MSSQL (1731) и вся цепочка Kerberos (предварительная аутентификация RC4 в 7500, AS-REP в 18200, Kerberoast в 13100 и предварительная аутентификация AES256 в 19900). Стратегия атаки состоит из нескольких этапов: прямой список слов, затем правила, затем атака PRINCE (через pp64, со словами от 8 до 16 символов), затем случайная атака с 500 000 символов и, наконец, пользовательские атаки с использованием списка слов оператора и правил. Сравнивая bot.py с его резервной копией bot.py.bak, мы обнаружили около 168 измененных строк, все они касались рефакторинга: поддержка хеш-режима для каждого задания (для более чистого параллельного выполнения различных типов) и ограничения времени выполнения для каждого шага, которые включают стоимость аренды графических процессоров. Это инструмент, находящийся в активной поддержке во время кампании.

5.2 Анализ взлома​

Мы собрали корпус из 30 945 паролей (5705 уникальных) из полей паролей файлов учетных данных и pot-файлов. Анализ состава показывает классический паттерн слабых паролей в длинном хвосте (P@ssw0rd, 123456, Month@Year, даты рождения), но верхняя часть списка частот выявила нечто иное, что мы рассмотрим в следующем разделе.

Не удалось прогрузить медиа

Cracking-agent bootstrap showing the VAST-GPU-2026 voucher, evidence that GPU power was rented on-demand from Vast.ai (elastic, disposable cracking capacity).

Не удалось прогрузить медиа

Setup script for the distributed cracking cluster, pointing agents at the Hashtopolis command server.

Бот: жертвы взлома очереди​

В коде не только упоминался Telegram-бот, но и его токен хранился в открытом виде в файле bot.py. Используя его, внешний агент получил доступ к работающему экземпляру «HASHBOT» и восстановил историю его пересылаемых операций. Эта история работает как реестр заданий: для каждой цели он записывает отправленный домен, тип хеша, режим атаки, выделенный графический процессор и результаты.

Реестр ясно показывает, что операция вышла далеко за пределы корпуса FortiGate. Наряду с ожидаемой пакетной обработкой Fortinet (задание «Fortigate256», обрабатывающее 258 546 хешей за раз), очередь содержала отдельные задания, помеченные именами или доменами конкретных организаций, каждое из которых проходило через тот же конвейер, описанный в отчете: домен, затем ключевые слова, затем режим (DEEP SMALL, L6 Hyb base+app, L8 Policy masks, COMBO Combo+rules).


Поведение точно соответствовало нашим предыдущим выводам: девять и более режимов Hashcat (NetNTLMv2, FortiGate, Kerberos RC4/AES-256, MSSQL), пул GPU с текущими счетчиками занятости/свободности (например, «GPU: 10/16 свободно»), расчетное время завершения каждого задания — 8 июня 2026 года, а также вывод, ограниченный взломанными паролями и файлом отчета по каждой цели (turk.com_report.txt, US_found_81.txt и аналогичные).

Среди целей, которые мы наблюдали в активно взламываемом режиме в очереди:

• BYD — автопроизводитель, запущенный как КОМБО-задание (комбо + правила) в пуле GPU.
• Lindab (теги задания LIAB / LIAB.LINDAB) — NetNTLMv2 и хеши доменов, с восстановленными учетными данными.
• Necotrans (NECOTRANS) — логистика; захват NetNTLMv2, отправленный с корпоративными ключевыми словами.
• Hennessey (hennesseyauto) – хеши Kerberos AES-256.
• CH Hanson (CH Hanson) – NetNTLMv2, обработано как сценарное задание.
• turk.com – взломаны учетные данные домена, включая учетную запись администратора, полученную в результате выполнения DEEP SMALL (учетные данные скрыты).
• Дополнительные помеченные задания, такие как BALSUGIDA, DTIS и пакет с меткой US (десятки взломанных хешей в каждом файле), находятся на разных этапах выполнения.

Вывод таков: сбор учетных данных FortiGate был лишь интерфейсом более широкой услуги по взлому учетных данных по запросу: один и тот же бот и пул графических процессоров использовались для взлома хешей Active Directory, Kerberos и баз данных для ряда несвязанных средних и крупных предприятий.

В соответствии с нашей политикой раскрытия информации, полный и подтвержденный список находится только в конфиденциальном документе, предоставленном жертве; Приведенные выше названия иллюстрируют масштаб проблемы, и каждая затронутая организация получает уведомление.

Не удалось прогрузить медиа

Header of the Telegram-controlled hashcat bot: a declared pool of 10× RTX 4090 GPUs, admin handle @Clarksome, the hardcoded bot token, and automatic detection of nine hash types (FortiGate, NetNTLMv2, MSSQL, and the full Kerberos chain).

Не удалось прогрузить медиа

Не удалось прогрузить медиа

Не удалось прогрузить медиа

Не удалось прогрузить медиа

Не удалось прогрузить медиа

Не удалось прогрузить медиа

6. Уровень постоянного доступа: учетные записи-бэкдоры​

При сортировке паролей по частоте встречаемости наиболее распространенные пары повторяются на тысячах различных IP-адресов. Это не органические учетные данные жертвы; это учетная запись, созданная злоумышленником. Пара adminin:ITAdmin@888 встречается на 3947 устройствах; fortiAdmin:fortiAdmin1qaz2wsx — на 1282; fgtsecure:F0rt!n3tS3cur3! — на 1152.

Когда одна и та же комбинация имени пользователя и пароля существует на тысячах межсетевых экранов, она была создана, а не обнаружена.

6.1 Маскировка поддержки FortiCloud и Fortinet​

Самая хитрая деталь — это маскировка. Имена созданных учетных записей имитируют легитимные сервисы Fortinet: forticloud-sync, forticloud-tech, support_fortinet, fgtsecure, fgtsec, Technical_support, fortinetadmin, tech-fortinet. Невнимательный администратор, увидевший в списке учетных записей forticloud-sync, склонен считать это чем-то легитимным из экосистемы FortiCloud. В этом-то и суть.

По меньшей мере 5868 учетных записей в наборе следуют этой схеме маскировки, а с учетом таких вариантов, как adminin и fgtsec, их число превышает девять тысяч. В подтвержденном списке доступа all_valid.txt указано 21976 устройств с административным доступом, 90,6% из которых подключены через SSH на порту 22. Защитные последствия прямы и серьезны: изменение исходного пароля администратора не вытесняет злоумышленника, поскольку у него есть собственная учетная запись. Для защитников эти имена учетных записей являются индикаторами немедленного использования.

7. Этап 4: проникновение в сеть, переход на VPN и Active Directory​

Взлом брандмауэра никогда не был конечной целью. Это был входной портал. Настоящая цель — Active Directory.

Файл vpn5.conf представляет собой конфигурацию клиента OpenFortivPN, указывающую на целевой SSL-VPN-концентратор (185.XX.XXX.XXX:444) с учетной записью sslvpn и паролем, заканчивающимся на «Audit». Название «audit» выбрано не случайно: это обеспечение постоянного присутствия, замаскированное под аудит безопасности. Конфигурация использует раздельное туннелирование (set-routes=0, set-dns=0), что позволяет избежать маршрутизации трафика оператора через целевую сеть, что является проблемой операционной безопасности, которая снова упоминается в файле README виртуальных машин.

7.1 Арсенал impacket​

Набор скриптов на Python использует библиотеку impacket для работы внутри сетей. Все они обладают одним общим приемом: они привязываются к сокету по адресу, назначенному VPN (например, 10.212.134.220 или 10.11.254.200), чтобы инициировать трафик через скомпрометированный VPN, как если бы они были легитимным внутренним хостом. Скрипт ad_full_audit.py выполняет аудит Active Directory в двенадцать шагов: проверка AS-REP, проверка Kerberos, неограниченное и ограниченное делегирование, пароли RBCD, LAPS и gMSA, пароли в поле описания, учетные записи с adminCount=1, старые и уязвимые операционные системы, группа DnsAdmins и подсчет групповых политик. Это полная проверка привилегий, подобная той, которую проводит профессиональный пентестер, но в автоматизированном режиме.

​

7.2 Распыление и сканирование​

Другие скрипты обрабатывают расширение. spray_da.py выполняет распыление паролей через Kerberos, spray_taroko.py проверяет уже полученные учетные данные на соответствие протоколу SMB, проверяя доступ к общей папке C$, а spider.py рекурсивно обходит общие папки, открывая файлы с расширениями, такими как .bat, .ps1, .ini и .config, в поисках слов «password», «secret» и «net use».

Также имеются пользовательские списки слов для каждого сотрудника (файлы pass_<name> с персидскими и арабскими названиями, содержащие числовые PIN-коды в формате даты или телефона), а файл spray_results.txt документирует успешную атаку на организацию, использующую арабский язык, где десятки учетных записей использовали простые пароли, такие как 12345 и 123456. Мы подтвердили глубокий взлом (взлом учетных данных домена) в организациях среднего размера во Вьетнаме, Тайване и Японии, среди прочих.

8. Искусственный интеллект: CyberStrike​

Один из элементов подготовки виртуальных машин привёл нас к одному из наиболее важных открытий исследования.

Скрипты final-setup.sh, rebuild-vms.sh и fix-vms.sh устанавливают на хосте и на всех семи виртуальных машинах инструмент под названием CyberStrike с помощью команды curl -fsSL https://cyberstrike.io/install.sh | bash. Поиск в интернете прояснил, что это такое: CyberStrike — это автономный агент для тестирования на проникновение с использованием искусственного интеллекта, с открытым исходным кодом под лицензией AGPL, написанный на TypeScript в среде выполнения Bun и запускаемый в виде TUI в терминале. Он превращает подписку на LLM в автоматизированную команду «красных», включающую более 13 специализированных агентов, более 7300 навыков, более 2000 атомарных тестов MITRE ATT&CK, встроенный браузер Chromium с перехватом HTTP (HackBrowser), восемь параллельных субтестеров (IDOR, обход авторизации, SSRF, внедрение, бизнес-логика и другие) и механизм удаленного выполнения под названием Bolt, использующий протокол MCP с аутентификацией Ed25519. Он поддерживает более 15 поставщиков LLM в модели BYOK («используй свой ключ»), включая Anthropic, OpenAI, Google, а также офлайн-варианты, такие как Ollama.

8.1 Как они его использовали​

Доказательства использования согласуются. CyberStrike был установлен на хосте и на семи виртуальных машинах Kali, добавлен в PATH и упомянут в README оператора как инструмент первой линии. Имеется SSH-ключ Ed25519 с комментарием cyberstrike@pentestlab, что соответствует механизму удаленного выполнения Bolt. На хосте также находится кэш библиотеки терминального интерфейса libopentui.so (36 идентичных копий), что согласуется с тем, что там работало приложение TUI на основе Bun, подобное самому CyberStrike. Сочетая документированные возможности с наблюдаемой инфраструктурой, наиболее правдоподобная интерпретация — это наличие одного агента ИИ на каждого оператора, каждый в своей виртуальной машине под контролируемой сессией tmux: HackBrowser и субтестеры автоматизируют веб-этап (включая взаимодействие с панелями FortiGate и внутренними порталами), Bolt координирует инструменты в сети виртуальных машин, а модуль OSINT обеспечивает часть информации для анализа цели. Мы не обнаружили в дампе никаких ключей LLM злоумышленника, что соответствует модели BYOK, в которой ключи хранятся в локальной конфигурации среды выполнения.

8.2 Значение​

Необходимо честно оценить ситуацию: CyberStrike — это легитимный инструмент, предназначенный для авторизованного тестирования, с четко определенным кодексом поведения. Мы же документируем злоупотребление им со стороны преступника, который просто проигнорировал этот кодекс поведения и направил агента на цели без согласия злоумышленника в больших масштабах. Таким образом, FortiBleed — это конкретный случай криминального использования агентного пентестинга. Преимущество злоумышленника заключается не в новом эксплойте, а в интеграции: ИИ для разведки и веб-этапа, пользовательские скрипты для Active Directory, арендованные графические процессоры для хеширования и Telegram-бот для управления. Точный объем действий, выполняемых ИИ, является предположением, поскольку в дампе нет стенограмм CyberStrike, но использование инструмента — это факт.

Не удалось прогрузить медиа

9. Сбой в обеспечении операционной безопасности, который их разоблачил​

В основе этого дела лежит ирония. Группа обучала своих операторов операционной безопасности, используя подробный файл README, запрещающий утечку инфраструктуры через сеть жертвы, применяла раздельное туннелирование, шифровала списки целей в панели, обнаруживала ловушки и удаляла собственные перехваченные данные. И тем не менее, она оставила весь рабочий каталог открытым в интернете, с открытым закрытым ключом SSH (cyberstrike_key), токеном бота Telegram и ключами доступа Hashtopolis. Именно этот сбой привел к прекращению операции. Тактическая дисциплина не выдержала ошибки конфигурации в инфраструктуре.

10. Оценка последствий​

Последствия оцениваются на трех уровнях. На поверхности – десятки тысяч межсетевых экранов Fortinet с скомпрометированными учетными данными и установленными бэкдорами, что означает постоянный административный доступ. На промежуточном уровне – перехват и обработка конфиденциального трафика бесчисленных организаций, включая учетные данные из различных протоколов и содержимое электронной почты. На глубоком уровне были взломаны сотни доменов Active Directory, некоторые — до уровня учетных данных домена. Поскольку уже скомпрометированные учетные данные остаются действительными до тех пор, пока не будут сменены, основной риск заключается не в разовой атаке, а в постоянном и перепродаваемом доступе в модели брокера первоначального доступа.

11. Защита и обнаружение​

Для любого FortiGate, у которого был открыт интерфейс управления или SSL-VPN, рекомендуется исходить из предположения о компрометации и действовать: сменить все учетные данные (локального администратора, учетные записи служб и все учетные записи VPN), отозвать ключи SSH администратора, отключить интерфейс управления от интернета, ввести многофакторную аутентификацию для VPN и обновить FortiOS, не забывая заставить администраторов повторно войти в систему, чтобы хеши перешли на PBKDF2.

11.1 Поиск учетных записей с бэкдорами​

Это действие с наибольшей отдачей в кратчайшие сроки. Проведите аудит локальных административных учетных записей устройств FortiGate и рассматривайте как инцидент наличие любых учетных записей с именами типа forticloud-sync, forticloud-tech, support_fortinet, fgtsecure, fgtsec, fortiAdmin, adminin или Technical_support. Эти учетные записи имитируют легитимные службы Fortinet, но таковыми не являются.

11.2 Правила обнаружения​

В поведении следите за периодическими административными входами с одного IP-адреса (петля захвата), аномальным повторным использованием сессионных cookie FortiGate, а в Active Directory — за всплесками атак AS-REP и Kerberoasting, сканированием C$ по SMB и аномальным чтением LAPS и gMSA. Также стоит отслеживать трафик, типичный для атакующего ИИ-агента: сканирование с перехватом, параллельное сканирование IDOR и SSRF из одного источника, неожиданные туннели Cloudflare и исходящие вызовы к API LLM из административных сегментов.

12. Ответственное раскрытие информации и уведомление жертв​

На основе индексов украденных данных мы составили список уведомлений, содержащий организации, в которых произошла компрометация Active Directory: 623 домена, из которых 616 имеют идентифицированную компанию и 32 с уже взломанными хэшами (и, следовательно, риском для администраторов домена). В принципе, этот список не содержит паролей или индивидуальных имен пользователей, только то, что необходимо CERT или самой организации для идентификации и принятия мер. Это конфиденциальный документ, предназначенный для доверенных каналов раскрытия информации (национальные CERT или прямое уведомление жертв), и он не публикуется в этом отчете, который ограничивается агрегированными данными. Предлагаемая приоритезация начинается с 32 доменов со взломанными учетными данными домена и двенадцати доменов с более чем сотней захваченных хэшей.

13. Заключение​

FortiBleed демонстрирует зрелость рынка первичного доступа как отрасли. Эффективность этой группы заключалась не в волшебном трюке, а в тщательной организации: механизм сканирования и перехвата трафика, который в больших масштабах улавливает данные и стирает улики, многопротокольный сборщик данных, преобразующий этот трафик в учетные данные, кластер гибкого взлома, арендуемый и управляемый через чат, агент ИИ, который увеличивает количество операторов, и конвейер обработки данных, который определяет приоритетность жертв по доходу. Каждый элемент доступен по отдельности; вместе они образуют фабрику.

Урок для защитников двоякий. Во-первых, дорогостоящий межсетевой экран не защищает от пароля 12345, и глубокая компрометация произошла именно из-за слабых паролей сотрудников и устаревших хешей, а не из-за уязвимости нулевого дня. Во-вторых, тенденция, которую предвещает этот случай, — это сочетание наступательного ИИ, гибкого взлома и модели брокера первоначального доступа, то есть индустриализация первоначального доступа с минимальным количеством квалифицированных специалистов на одну цель.

Ирония заключается в том, что группа, настолько дисциплинированная в обучении своих операторов не разглашать инфраструктуру в сети жертвы, раскрыла всю свою операцию через открытый каталог. Эта ошибка дала нам редкую возможность заглянуть внутрь производственной линии, и этот отчет — результат нашей работы.

14. Приложения​