N-able випустила N-central 2026.3.1.7 після того, як зловмисники скористалися обходом автентифікації, отримали віддалений адміністративний доступ і дісталися до систем, якими керували через захоплені сервери. Важливе уточнення: простого оновлення до N-central 2026.3 недостатньо. CVE-2026-18577 охоплює збірки до аварійного виправлення, включно з 2026.3.0. Організаціям потрібно оновити сервер N-central, а потім перевірити підпорядковані йому пристрої. [1] [2]
Чому N-central 2026.3 усе ще вразливий
Інцидент почався з CVE-2026-18556 — шляху до захоплення облікового запису без автентифікації, який стосувався N-central до версії 2026.1. Спочатку N-able порадила перейти на 2026.3, але подальше розслідування виявило інший шлях, який перше виправлення не перекрило. Цю неповноту виправлення тепер відстежують як CVE-2026-18577 з оцінкою 8,2 за CVSS 4.0 і позначкою про реальні атаки в офіційному записі CVE. Перша неуразлива збірка у повідомленні N-able — 2026.3.1.7. [2]
| Стан середовища | Що робити |
|---|---|
| N-central 2026.3.0.13 або будь-яка попередня збірка | Система все ще вразлива. Потрібна саме 2026.3.1.7, а не просто перехід на гілку 2026.3. |
| Власний сервер N-central | Завантажте й установіть аварійне виправлення, а потім переконайтеся, що консоль показує збірку 2026.3.1.7. |
| Хмарний N-central (NCOD) | N-able встановлює оновлення за своїм графіком. Перевірте поточну збірку й повідомлення для конкретного екземпляра, а не покладайтеся на припущення, що розгортання завершене. |
| Будь-який індикатор або незрозумілий віддалений сеанс | Розглядайте сервер і задіяні пристрої як частини інциденту. Оновлення сервера не видаляє закріплення, яке вже з’явилося на іншому комп’ютері. |
Чому зона ризику не обмежується сервером N-central
N-central — це платформа віддаленого моніторингу й керування. Її штатні можливості дозволяють запускати завдання та відкривати віддалені сеанси на системах клієнтів. Після захоплення сервера зловмисники використали функцію Take Control, щоб перейти на керовані пристрої та зареєструвати тунелі Cloudflare як служби. Вихідний тунель не потребує нового вхідного правила міжмережевого екрана, а служба може пережити перезавантаження. Про злам Cloudflare не йдеться — зловмисники використали легітимну тунельну службу як інфраструктуру.
Ця межа визначає план очищення. Закриття маршруту через N-central або встановлення виправлення усуває вразливий шлях керування, але не видаляє автоматично тунель, сценарій, обліковий запис чи службу, уже розгорнуті на кінцевому пристрої. Таке саме правило діє в інших інцидентах із віддаленим керуванням через RMM: виявлення одного засобу доступу не доводить, що інших каналів немає.
Які індикатори перевірити насамперед
N-able і Huntress оприлюднили стислий набір артефактів для первинної перевірки. Huntress також застерігає, що частина адрес є вихідними вузлами комерційних VPN, тому сам збіг IP ще не є доказом. Пов’язуйте індикатор з активністю в консолі N-central, особою користувача, цільовим хостом, журналами пристрою та часом сеансу. [1] [3]
| Артефакт | Як його тлумачити |
|---|---|
svchost.exe у папці Documents користувача | Назва імітує компонент Windows, але шлях нетиповий. Збережіть файл і часові мітки для аналізу; не плутайте його з легітимним процесом із System32. |
Служба з назвою Cloudflared | З’ясуйте, чи дозволяла її організація, хто й коли її встановив, з яким командним рядком, конфігурацією та кінцевою адресою. Cloudflared може бути легітимним, тому важливе походження. |
ui_access_control.log | Перевірте віддалені сеанси, IP користувача, незвичні облікові записи підтримки, важливі цільові хости й активність без відповідної заявки. |
C:\ProgramData\GetSupportService_N-Central\Logs\BASupSrvc_*.log.gz | Використовуйте журнали Take Control на пристрої для зіставлення подій. Вони з’являються і після легітимних сеансів, тому мають значення лише разом із підозрілим часом та даними користувача. |
Шість оприлюднених мережевих індикаторів: 173[.]249[.]252[.]200, 87[.]249[.]138[.]34, 37[.]19[.]210[.]32, 37[.]153[.]90[.]88, 92[.]118[.]112[.]181 і 68[.]235[.]46[.]214. Huntress також назвала mousears[.]synology[.]me, wagoosh[.]direct[.]quickconnect[.]to і who-ripped-one[.]direct[.]quickconnect[.]to. Шукайте їх в історичних журналах міжмережевого екрана, проксі, WAF, N-central та кінцевих пристроїв, а не лише серед поточних з’єднань. [3]
Що адміністраторам N-central зробити зараз
- Перевірте точну збірку сервера. Потрібна 2026.3.1.7, а не будь-яка версія з позначенням 2026.3. Після оновлення звірте номер у консолі.
- Зменште доступність на час оновлення. Якщо власний сервер не можна виправити негайно, обмежте доступ до консолі відомими адміністративними мережами або вимкніть службу згідно з планом реагування. Блокування IP — лише тимчасовий захід, бо інфраструктура нападника змінюється.
- Збережіть докази до очищення. Скопіюйте журнали консолі, віддаленого доступу, міжмережевого екрана, WAF, проксі, ідентифікації та пристроїв. Зафіксуйте часові пояси й строки зберігання.
- Перевірте адміністративні зміни. Шукайте нових користувачів, зміну ролей, вимкнення MFA, розширені правила IP, невідомі завдання, сценарії, політики й віддалені сеанси, особливо без відповідної заявки підтримки.
- Складіть перелік усіх задіяних пристроїв. Зіставте сеанси N-central із журналами Take Control на Windows-хостах. Першими перевіряйте контролери домену, файлові сервери, системи резервного копіювання, служби ідентифікації та робочі станції технічних фахівців.
- Видаліть закріплення на пристроях. Розслідуйте недозволені служби Cloudflared, конфігурацію тунелів, скопійовані інструменти, заплановані завдання, нові облікові записи, автозапуск і виключення захисту. Перейменований тунель Cloudflare також фігурував в іншому інциденті на багатьох хостах, тому походження тунелю та локальне закріплення потрібно перевіряти разом.
- Змініть відкриті секрети з чистої системи. Після локалізації скиньте паролі адміністраторів N-central, задіяні секрети інтеграцій, API-токени та службові облікові дані. Відкличте невідомі сеанси й перевірте налаштування MFA.
- Продовжуйте перевірку на рівні пристроїв. Якщо до хоста підключалися віддалено, чиста консоль N-central не доводить, що сам комп’ютер не зазнав змін.
На момент перших повідомлень N-able не оприлюднила повну технічну першопричину на рівні запиту, загальну кількість уражених клієнтів або докази однакового розвитку подій у кожному середовищі. Відокремлюйте підтверджені факти від припущень: обхід автентифікації та активні атаки підтверджені, але конкретний індикатор потребує локального зіставлення, перш ніж стане доказом зламу.
Джерела
- N-able. “N-central 2026.3 Hotfix 1 – Mitigation for CVE-2026-18577.” N-able Status, 2 серпня 2026 року. status.n-able.com
- N-able (CNA). “CVE-2026-18577: Incomplete Patch Allows N-central Authentication Bypass and Account Takeover.” CVE Program, опубліковано 2 серпня 2026 року. cve.org
- Ben Bernstein, John Hammond. “Rapid Response: Critical N-able N-central Vulnerability and Active Exploitation.” Huntress, 3 серпня 2026 року. huntress.com
