+38 (067) 372 39 55

English site

5 вразливостей, які ESKA знаходить у кожному другому пентесті

5 вразливостей, які ESKA знаходить у кожному другому пентесті

За результатами пентестів, які команда ESKA провела протягом 2024–2025 років, п'ять вразливостей зустрічаються з такою регулярністю, що ми починаємо шукати їх в першу чергу, ще до того, як запускаємо будь-який сканер. І знаходимо. Майже завжди.

Вразливість №1. Відкритий RDP назовні

Remote Desktop Protocol — протокол, який дозволяє підключатися до комп'ютера або сервера віддалено. Зручний інструмент для адміністраторів. І улюблена точка входу для зловмисників.

Що ми бачимо на практиці: порт 3389 відкритий у публічний інтернет, без додаткового захисту, без обмеження за IP-адресою, без VPN-шлюзу перед ним. Іноді з дефолтним іменем користувача Administrator і паролем, який адміністратор придумав три роки тому.

Чому це критично: сканери зловмисників знаходять відкритий RDP за лічені хвилини. Далі брутфорс або використання вкрадених облікових даних з публічних витоків (credential stuffing). За даними аналітики CERT-UA, атаки через RDP залишаються одним із ключових початкових векторів компрометації корпоративних мереж в Україні.

Що робити:

  • Закрити RDP від публічного інтернету. Доступ — виключно через VPN.
  • Якщо VPN поки немає, варто обмежити доступ до 3389 за білим списком IP.
  • Увімкнути Network Level Authentication (NLA).
  • Перейменувати стандартний обліковий запис Administrator або вимкнути його.

Вразливість №2. Відсутність MFA на критичних акаунтах

Багатофакторна автентифікація (MFA) — один із найефективніших і найдешевших засобів захисту. За даними Microsoft, увімкнена MFA блокує понад 99% атак на акаунти, заснованих на вкрадених паролях. І при цьому в кожній другій компанії, де ми проводимо пентест, MFA або відсутня взагалі, або увімкнена вибірково — там, де зручно, а не там, де потрібно.

Що ми бачимо на практиці: MFA є на корпоративній поштовій скриньці генерального директора, але відсутня на VPN-акаунтах, адміністративних панелях хмарної інфраструктури, облікових записах DevOps-інженерів у GitHub і AWS, доступі до систем резервного копіювання.

Чому це критично: один скомпрометований пароль без MFA і у зловмисника є повний доступ. Паролі витікають постійно: через фішинг, через злам сторонніх сервісів, через інсайдерів. MFA це той рубіж, який перетворює вкрадений пароль на марну річ.

Що робити:

  • Визначити перелік критичних акаунтів і систем: VPN, хмарні консолі, репозиторії коду, поштові сервіси, системи резервного копіювання, фінансові системи.
  • Увімкнути MFA на всіх без винятку. Починати з привілейованих акаунтів.
  • Вибір методу: TOTP-застосунок (Google Authenticator, Microsoft Authenticator) — мінімум. Апаратні токени (YubiKey) для найчутливіших ролей.
  • Заборонити обхід MFA через резервні коди без окремої процедури підтвердження.

Вразливість №3. Дефолтні або слабкі паролі на мережевому обладнанні

Це та вразливість, яка виглядає найбільш неймовірно і трапляється найчастіше. Комутатор Cisco з паролем cisco. Маршрутизатор MikroTik з паролем admin і без пароля взагалі. IP-камера з доступом через admin/admin. Принтер із відкритою веб-панеллю без автентифікації.

Що ми бачимо на практиці: мережеве обладнання, яке встановлювали три роки тому за тендером, ніхто після введення в експлуатацію більше не торкався з точки зору безпеки конфігурації. Дефолтні облікові дані залишилися на місці. Деколи їх можна знайти через звичайний пошук у Shodan — публічному пошуковику підключених до інтернету пристроїв.

Чому це критично: мережеве обладнання — це хребет корпоративної мережі. Отримавши доступ до керованого комутатора або маршрутизатора, зловмисник може перехоплювати трафік, змінювати маршрутизацію, ізолювати сегменти мережі або отримати стійку присутність, яку вкрай складно виявити.

Що робити:

  • Провести інвентаризацію всього мережевого обладнання, включно з тим, що «просто стоїть і працює».
  • Змінити всі дефолтні паролі. Використовувати унікальні складні паролі для кожного пристрою, зберігати їх у корпоративному менеджері паролів.
  • Закрити доступ до панелей керування з інтернету. Управління обладнанням, виключно з окремого захищеного сегменту мережі.
  • Регулярно перевіряти конфігурацію у рамках VA або внутрішніх аудитів.

Вразливість №4. Застарілі версії програмного забезпечення з відомими CVE

У другому півріччі 2024 року CERT-UA зафіксувала системну тенденцію: зловмисники експлуатують відомі вразливості буквально впродовж кількох годин після їх публічного розкриття. Вікно між «вразливість оприлюднена» і «вразливість активно використовується» скоротилося до мінімуму.

Що ми бачимо на практиці: на периметрі або всередині мережі регулярно зустрічаємо сервери з Windows Server 2012/2016 без актуальних патчів, Exchange Server із відомими критичними CVE (ProxyShell, ProxyLogon та їх аналоги у пізніших версіях), Confluence, GitLab, Jira або інші корпоративні системи на версіях з відомими вразливостями, VPN-шлюзи та файрволи з прошивками дво-, трирічної давнини.

Чому це критично: для цих вразливостей публічно доступні готові експлойти. Їх застосування не вимагає ні особливої кваліфікації, ні спеціальних інструментів. Достатньо запустити готовий скрипт.

Що робити:

  • Побудувати процес управління патчами: інвентаризація ПЗ → моніторинг нових CVE → тестування патчів → встановлення у встановлені вікна.
  • Для критичних систем на периметрі — пріоритет встановлення патчів протягом 24–72 годин після виходу.
  • Якщо оновлення неможливе одразу, то проводяться компенсуючі заходи: сегментація, додаткові правила на файрволі, посилений моніторинг.
  • Регулярне VA-сканування для виявлення застарілого ПЗ до того, як це зробить зловмисник.

Вразливість №5. Надмірні привілеї та відсутність принципу мінімальних прав

Принцип мінімальних привілеїв (Least Privilege) — базовий принцип кібербезпеки: кожен користувач і кожна система мають рівно стільки прав, скільки потрібно для виконання конкретних функцій, і ні на крок більше. На практиці він порушується майже скрізь.

Що ми бачимо на практиці: рядовий менеджер має права локального адміністратора на своєму ноутбуці. Обліковий запис служби резервного копіювання — права domain admin у Active Directory. Розробники мають прямий доступ до продакшн-баз даних. Колишній співробітник, який звільнився три місяці тому, все ще має активний акаунт у корпоративних системах.

Чому це критично: надмірні привілеї — мультиплікатор збитку. Якщо зловмисник компрометує обліковий запис звичайного користувача, але той має права адміністратора — наслідки такі ж, як при злому адміністратора. Lateral movement через мережу стає тривіальним завданням.

За даними Verizon DBIR 2024, зловживання привілеями присутнє у значній частині підтверджених інцидентів, пов'язаних із внутрішніми загрозами та постбрічними сценаріями.

Що робити:

  • Провести аудит облікових записів: активні/неактивні, рівні привілеїв, обґрунтованість прав.
  • Видалити права локального адміністратора у звичайних користувачів. Для тих, кому вони справді потрібні — окремий привілейований обліковий запис для конкретних задач.
  • Налаштувати автоматичне відключення акаунтів при звільненні співробітників.
  • Впровадити Privileged Access Management (PAM) для управління привілейованими акаунтами.
  • Перевіряти права облікових записів служб і технічних акаунтів.

Чому це все ще трапляється

Жодна з цих вразливостей не є складною технічно. Усі вони добре відомі. Про всі них написано в будь-якому керівництві з базової кібербезпеки.

Але вони залишаються через брак часу, через відсутність системного підходу, через «потім виправимо», через те що ніхто не перевіряв і все «начебто працює».

Пентест — це не спосіб довести, що у вас все погано. Це спосіб знайти ці речі до того, як їх знайде хтось із недобрими намірами. Різниця між «нам зробили пентест» і «нас зламали» часто вимірюється саме цими п'ятьма пунктами.

Що зробити прямо зараз

Якщо ви дочитали до цього місця і впізнали хоча б одну з описаних ситуацій — це вже важливий сигнал. Не обов'язково одразу замовляти повноцінний пентест. Почніть з простих перевірок:

  • Чи є у вас відкритий RDP назовні? Перевірте через Shodan або запитайте у свого системного адміністратора.
  • На яких критичних акаунтах увімкнена MFA? Складіть список — і подивіться, де її немає.
  • Коли востаннє оновлювалося ваше мережеве обладнання і серверне ПЗ?
  • Хто з колишніх співробітників все ще має доступ до корпоративних систем?

Ці питання коштують нуль гривень. Відповіді на них можуть заощадити значно більше.

Якщо хочете отримати повну картину — команда ESKA проводить пентест інфраструктури з детальним звітом і рекомендаціями щодо усунення знайдених вразливостей.