Викрадена конфігурація фаєрвола може залишатися небезпечною й після усунення початкового зламу. У новому розслідуванні Unit 42 простежила, як зловмисники забрали архів керування телеком-провайдера, повторно використали облікові дані та впровадили PEERSTITCH у штатні процеси FortiGate. Архів містив інформацію про понад 500 керованих фаєрволів. Це масштаб витоку конфігурацій, а не підтвердження зламу 500 клієнтських мереж. [1]
Звіт опубліковано 14 жовтня 2026 року. Вторгнення почалося у вересні 2024-го; дослідники перевіряли середовище провайдера, а не його клієнтів. Практичний висновок актуальний зараз: патч для сервера керування не анулює паролі, сертифікати та приватні ключі, які вже забрав нападник.
Підставний пристрій відкрив архів керування
Точкою входу став FortiManager — центральна система керування власними та клієнтськими фаєрволами FortiGate. Зловмисники використали CVE-2024-47575, відому як FortiJump, і зареєстрували підставний віртуальний пристрій з іменем localhost. Потім вони створили й викрали архів конфігурацій .tm.
У ньому була карта довірених зв’язків: серійні номери й публічні IP-адреси пристроїв, робочі конфігурації, бази керування, маршрути, облікові дані у вигляді оборотно зашифрованого тексту та криптографічні матеріали. Unit 42 змогла відновити адміністративні й SSL/VPN-паролі з викрадених конфігурацій. Згодом нападники використовували справжні облікові дані для несанкціонованих VPN-сеансів у сегментах керування мережею.
Тому виправлення початкової вразливості та відкликання викрадених ідентичностей — різні завдання. Сервер може вже мати патч, але його колишні секрети й далі відкриватимуть доступ.
Імплант сховався у процесах журналювання та VPN
Отримавши адміністративний доступ, зловмисники використали другу вразливість, CVE-2025-61624, для виходу до базової операційної системи. Вона дозволяла привілейованому користувачу записувати файли поза призначеним каталогом сценаріїв. Це важлива межа: адміністративний інтерфейс FortiOS обмежений, тоді як системні служби під ним працюють із правами root.
Інжектор PEERSTITCH націлювався на /bin/miglogd, службу журналювання, та /bin/iked, службу VPN. Впроваджений код не відкривав власного порту й не створював вихідного з’єднання, а переглядав дані, які вже проходили через ці процеси. Знайдену мітку він передавав безпосередньо в пам’ять іншого процесу. VPN-сеанс із відповідною міткою переходив до гілки виконання, що обходила звичайну перевірку безпеки.
Тут є важлива деталь для пошуку слідів: 8550 і 169.254.0.1 були маркерами у вмісті даних. Це не означає, що PEERSTITCH слухав порт 8550. Звичний трафік служби та знайоме ім’я процесу не гарантували цілісності коду всередині.
Робота в пам’яті також не означає, що вся атака не залишала файлів. Ланцюжок доставки зберігав компоненти на диску. Окремо нападники зловживали функціями керування сертифікатами Apache, щоб створити вихідний канал віддаленої командної оболонки. Відсутність нових з’єднань у самого імпланта не можна переносити на всі етапи вторгнення.
Обліковий запис, якого провайдер не створював
Показовим слідом стало завантаження конфігурацій від імені FortiGateCloud. Провайдер не мав середовища FortiManager Cloud і не створював такого облікового запису на цих пристроях. Unit 42 із середнім рівнем упевненості припустила підміну платформи керування. Наявні докази не дозволяли відрізнити використання викрадених матеріалів довіри від окремого обходу автентифікації.
Тому видимі ідентичності керування потрібно зіставляти з реальною інфраструктурою. Правдоподібна назва облікового запису мало заспокоює, якщо відповідної служби взагалі не повинно бути. В іншому недавньому випадку підмінена команда sudo копіювала пароль і водночас виконувала звичну роботу. Обидва розслідування показують, чому нормальна зовнішня поведінка сама собою не доводить цілісності.
Оновити систему та замінити викрадену довіру
Поточне повідомлення Fortinet називає FortiOS 7.6.5 і 7.4.10 виправленими версіями для CVE-2025-61624. Для вразливих гілок 7.2, 7.0 та 6.4 виробник вимагає перейти на виправлений випуск. Адміністраторам слід дотримуватися підтримуваного шляху оновлення для своєї моделі та версії, а FortiManager окремо перевірити за повідомленням про FortiJump. [2]
За підозри на компрометацію узгодьте збір доказів до перезавантаження, яке знищить вміст оперативної пам’яті. Серед напрямів перевірки Unit 42 — нетипова виконувана пам’ять у двох службах, записи в пам’ять іншого процесу, аварійні завершення та об’єкти сценаріїв із переходами за межі каталогу. Це орієнтири для фахового розслідування; їх відсутність не гарантує чистоти пристрою.
Рекомендації Fortinet щодо відновлення після FortiJump передбачають перевірку подій на керованих пристроях і термінову заміну облікових даних, які могли витекти. Відновлюйте або перебудовуйте сервер керування за процедурою виробника, перевіряйте цілісність конфігурацій та замінюйте відкриті нападнику паролі, ключі й сертифікати у відповідних довірених зв’язках. [3]
Межа проходить між відновленим пристроєм і відновленою системою довіри. PEERSTITCH ускладнював перевірку першого, а викрадений архів керування дозволяв другій залишатися скомпрометованою навіть після встановлення патча.
Джерела
- Деніел Ґотт і Шон Вестфолл. «Unit 42 Uncovers PEERSTITCH, a Stealthy FortiGate Implant». Palo Alto Networks Unit 42, 14 жовтня 2026 року. Розслідування та ознаки для перевірки.
- Fortinet PSIRT. «FG-IR-26-122», CVE-2025-61624. Опубліковано 14 квітня 2026 року; перевірено 17 жовтня 2026 року. Уразливі версії та виправлення.
- Fortinet PSIRT. «FG-IR-24-423», CVE-2024-47575. Перевірено 17 жовтня 2026 року. Повідомлення про FortiJump і відновлення.
