Про це доводиться говорити постійно: наразі зловмисники випереджають команди безпеки, оскільки ефективно співпрацюють між собою. Водночас вони не обмежені внутрішніми політиками, перевірками GRC, процедурами погодження або найкращими практиками безпеки. FortiBleed є прогнозованим наслідком цілеспрямованих дій кіберзлочинців, спрямованих на отримання доступу до цінних об’єктів будь-якими методами. Тут немає нового експлойта, який потрібно терміново відстежувати. Немає CVE, який можна додати в комірку дешборда й чекати, поки вона стане зеленою. Це історія про облікові дані. Вона більш заплутана, її важче виявити й усунути, ніж класичні вразливості, до яких усі звикли.
Ця стаття є аналізом загрози FortiBleed, проведеного фахівцями з Cynet. У ній розглянуто масштаб викриття облікових даних, потенційний вплив на організації та першочергові дії, які допоможуть зменшити ризики для середовищ із пристроями Fortinet.
Про FortiBleed
У середині червня дослідник Володимир «Bob» Дяченко випадково виявив сервер, яким керували зловмисники. Цей сервер команда необачно залишила відкритим для інтернету. На ньому були скрипти сканування, інструменти для перевірки облікових даних, журнали та база даних, акуратно відсортована за компаніями, секторами, доходом і країнами. Усередині був набір даних із робочими іменами користувачів і паролями приблизно 73 932 відкритих до інтернету Fortinet FortiGate міжмережевих екранів і SSL VPN-шлюзів у 194 країнах. Згідно з дослідженнями SOCRadar і Hudson Rock, а також незалежного дослідника Kevin Beaumont, дамп виглядає легітимним. Він походить з експортованих конфігурацій пристроїв, а не лише з фішингу через сторінки входу. Переважна більшість цих пристроїв досі перебуває онлайн. За оцінками аналітиків, це зачіпає приблизно половину всіх пристроїв Fortinet, які можна виявити в інтернеті.
Важлива частина: FortiBleed не є новою вразливістю zero-day. Для неї не призначено CVE. Це велика кампанія з викриття та перевірки облікових даних, яку проводить російськомовна група з кількома операторами. Вони провели масштабний пошук відкритих пристроїв Fortinet в інтернеті й перевірили їх на основі мільярдів облікових даних, що раніше потрапили до мережі. Йдеться приблизно про 1,16 млрд спроб входу щодо понад 320 000 цілей FortiGate, а також паралельну кампанію брутфорсу на 2,1 млрд спроб проти понад 160 000 серверів MSSQL. Там, де повторно використати пароль не вдавалося, вони перехоплювали хеші автентифікації SSL VPN і зламували їх офлайн на кластері GPU.
Дві важливі технічні деталі:
- Надійні паролі нікого не врятували. Значна частина скомпрометованих облікових даних містила дуже складні 20-символьні паролі. Довжина та складність паролів не мали значення, оскільки ці паролі вже існували у відкритому вигляді в дампах інфостілерів, зібраних з кінцевих пристроїв до застосування будь-якого шифрування. Складність не має значення, коли облікові дані вже витекли.
- Проблема з хешуванням реальна. Старіші версії FortiOS зберігали паролі адміністраторів як швидкі хеші SHA-256. Новіші випуски, починаючи з 7.2.11, використовують PBKDF2. Проте після оновлення старий слабкий хеш може зберігатися доти, доки адміністратор знову не ввійде в систему або не скине пароль. Тому навіть «пропатчений, актуальний» пристрій може досі містити застарілий хеш, який можна зламати.
Саме тому периферійне обладнання є настільки цінною ціллю. Отримавши доступ до пристрою, зловмисники використовують його як пункт спостереження: переглядають трафік, збирають додаткові облікові дані й повертають їх назад у сканер. Далі зловмисники вже можуть швидко дістатися до Active Directory. Після чого відлік до інциденту вже почнеться.
Хто під ризиком
Наявність назви організації в наборі даних не означає підтвердження зламу. Проте охоплення справді широке. Публічні повідомлення Hudson Rock, SOCRadar і Tech Times вказують на викриті облікові дані, пов’язані з організаціями майже з усіх секторів глобальної економіки. Серед згаданих назв: Accenture, PwC, Oracle, Samsung, Siemens, Foxconn, Lenovo, Comcast, AT&T, Chevron, Mercedes-Benz і Toyota. Також ідеться про невизначену кількість державних установ та операторів критичної інфраструктури.
- Географія: 194 країни, з найбільшою концентрацією пристроїв в Індії, США, Тайвані та Мексиці.
- Найбільш уражені галузі: ІТ-послуги, будівельні матеріали й телекомунікації.
- Погана новина: Дяченко повідомив про підтверджену повну компрометацію мережі та ексфільтрацію засекречених документів у турецького оборонного підрядника НАТО. Це не лише атаки на легкодоступні цілі. Bitsight виявила, що інструменти тунелювання, пов’язані з державними структурами, зокрема Chisel і Neo-reGeorg, які раніше спостерігалися в активності Volt Typhoon, використовували той самий пул облікових даних. Іншими словами, кіберзлочинці та добре забезпечені угруповання, що пов’язані з державними кіберопераціями беруть доступи з однієї й тієї самої полиці.
MSP і MSSP належать до категорії підвищеного ризику. Один скомпрометований обліковий запис адміністратора, який керує обладнанням Fortinet для багатьох клієнтів, може одночасно поставити під загрозу всіх нижче за ланцюгом. У таких умовах ситуацію потрібно розглядати як інцидент, що стосується багатьох клієнтів, а не як очищення одного пристрою.
Позиція Fortinet полягає в тому, що дані є повторним поширенням матеріалів із попередніх інцидентів разом з обліковими даними підібраних шляхом брутфорсу, а не пов’язані з жодним нещодавнім попередженням безпеки. Однак для організацій це нічого не змінює. Якщо дійсні облікові дані до шлюзу організації перебувають в обігу, це потребує термінової уваги.
Попередження та рекомендації урядових органів
18 червня 2026 року CISA опублікувала попередження, у якому прямо згадала FortiBleed і згадала облікові дані, пов’язані приблизно з 74 000 пристроїв Fortinet у державних і приватних мережах. Важливо, що CISA рекомендує перевіряти журнали контролерів домену разом із журналами міжмережевих екранів і VPN. Простіше кажучи, агентство не вважає, що все закінчується на міжмережевому екрані. Це інцидент облікового запису, замаскований під інцидент мережевого пристрою. Також це не перший випадок, коли Fortinet потрапляє в поле зору урядових структур. Раніше Нідерланди пов’язали окрему кампанію проти FortiGate, яка зачепила понад 20 000 пристроїв, із Китаєм.
Хоча сама FortiBleed не має CVE, кілька пов’язаних із Fortinet вразливостей активно експлуатуються, тому їх варто виправити в будь-якому разі. Деякі з них уже внесені до каталогу CISA Known Exploited Vulnerabilities:
- CVE-2026-35616 – неналежний контроль доступу у FortiClient EMS, у каталозі CISA KEV.
- CVE-2026-24858 – обхід автентифікації FortiCloud SSO, у каталозі CISA KEV.
- CVE-2026-21643 – SQL-ін’єкція у FortiClient EMS.
- CVE-2026-39813 – обхід шляху у JRPC API FortiSandbox, CVSS 9.1.
Ці вразливості є окремими від FortiBleed. Не можна дозволяти стверджувати, що їх виправлення «усуває» проблему з обліковими даними, адже це не так. Але виправити їх усе одно потрібно.
Що слід зробити командам безпеки
Варто пам’ятати ключову арифметику: вікно від розкриття інформації до експлуатації скоротилося приблизно з 32 днів до менш ніж одного дня. Причина полягає в тому, що зловмисники використовують ШІ для швидшого зворотного інжинірингу та створення робочих засобів експлуатації. Типові плани керування змінами ніколи не проєктувалися для такого темпу. Часу на повільне проходження повного сценарію реагування немає.
Відповідно до рекомендацій CISA та консенсусу дослідників, варто виконати такі дії:
- Завершити сесії та скинути паролі. Потрібно примусово завершити всі активні SSL VPN- та адміністративні сесії, а потім скинути всі паролі Fortinet VPN і адміністраторів. Насамперед це стосується систем, відкритих в інтернет. Будь-які облікові дані, які могли потрапити до набору даних, слід вважати скомпрометованими незалежно від того, наскільки надійними вони виглядали.
- Увімкнути стійку до фішингу MFA для кожного інтерфейсу віддаленого доступу й адміністрування без винятків. Саме це нейтралізує викрадений відкритий пароль. Перевагу слід надавати сертифікатам або апаратним/програмним токенам. SMS краще уникати.
- Виправити зберігання облікових даних. Потрібно підтвердити використання PBKDF2 і видалити застарілі хеші SHA-256, що могли залишитися, відповідно до рекомендацій Fortinet для версій FortiOS 7.2.11 і вище. Не слід припускати, що оновлення зробило це автоматично.
- Прибрати керування з інтернету. Адміністративні інтерфейси потрібно обмежити довіреними внутрішніми мережами за допомогою політик local-in, а неактивні або непотрібні облікові записи видалити чи вимкнути. Саме в таких забутих адміністративних облікових записах часто й живе ця проблема.
- Провести ретельний пошук ознак компрометації, а не обмежитися автоматизованою перевіркою. Потрібно переглянути журнали міжмережевих екранів, VPN, автентифікації та контролерів домену на предмет входів із локацій, між якими користувач не міг фізично переміститися за відповідний проміжок часу, а також неочікуваних адміністративних сесій, нових облікових записів або змін конфігурації. Успішний шкідливий вхід виглядає як успішний вхід, тому його потрібно цілеспрямовано шукати.
- Перевірити власну доступність через публічні інструменти перевірки, зокрема Fortinet checker від Hudson Rock і breached.company. Вони можуть бути корисною відправною точкою, але відсутність збігів у таких сервісах ще не означає, що ризик відсутній. Це не замінює перегляд журналів або ротацію облікових даних.
- Виправити пов’язані CVE, наведені вище. Пріоритет слід надати FortiClient EMS, FortiSandbox і всьому, що внесено до CISA KEV.
- Застосувати підхід припущення про компрометацію (assume-breach) на межі VPN. Одна лише ротація паролів не видаляє зловмисника, який уже закріпився в середовищі.
Висновок
FortiBleed не вкладається в рамки звичного сценарію інциденту безпеки з номером версії та чітким дедлайном для виправлення. Це незручна історія про гігієну облікових записів, адміністрування периферійних пристроїв і облікові дані, про викриття яких забули. Інакше кажучи, це нова норма критичного ризику. Міжмережевий екран давно перестав бути просто периметровим пристроєм. Тепер це брокер облікового запису та вхідні двері до домену. Захищати його потрібно відповідно до цієї ролі.
Не варто панікувати, але діяти потрібно терміново. Потрібні чіткість, процес і дисципліна, здатні відповідати швидкості та інтенсивності супротивників по інший бік екрана.
Ви можете отримати демо XDR платформи Cynet, щоб побачити, як платформа допомагає виявляти компрометацію, автоматизувати реагування та посилювати захист корпоративного середовища. Для цього залишіть ваші контактні дані у формі нижче.
