Анатомія атаки: як ransomware потрапляє у мережу українського бізнесу. Реальний кейс

На початку 2026 року команда SHERIFF Кібербезпека завершила розслідування ransomware-інциденту в українській компанії фінансового сектору. Зловмисники з угруповання BlackField проникли в корпоративну мережу, отримали повний контроль над інфраструктурою та зашифрували критичні системи бухгалтерії. Уся операція зайняла менше трьох діб. Ця стаття — перша у серії «Анатомія атаки», де ми крок за кроком розбираємо реальний інцидент. Усі дані анонімізовано, але технічні деталі — справжні. Сьогодні говоримо про найважливіше: чому атака взагалі стала можливою. Фото: Фрагмент Ransom note Відчинені двері: RDP назовні через маршрутизатор Коли ми проаналізували конфігурацію периметрового маршрутизатора MikroTik, знахідка виявилась шокуючою, хоча й передбачуваною. На пристрої було налаштовано 8 правил dst-nat , які прокидали протокол RDP безпосередньо на внутрішні хости через нестандартні порти ( 13389, 23389, 33389 тощо). Фактично — 8 комп’ютерів компанії були доступні з будь-якої точки світу через віддалений робочий стіл. Фото: 8 правил RDP dst-nat — без обмежень за IP джерела Жодного VPN. Жодної двофакторної автентифікації. Жодного обмеження за IP-адресою джерела. При цьому адміністратори компанії щиро вважали, що «ми за NAT-ом, нас не видно». Це поширена помилка: NAT — це механізм трансляції адрес, а не засіб захисту. Якщо ви самі налаштували прокидання портів — ви самі відчинили двері. Контролер домену, якому 17 років Серцем мережі був контролер домену Active Directory на базі Windows Server 2008 SP2 — операційної системи, підтримку якої Microsoft припинила ще у 2020 році. Ця система вразлива до цілої низки критичних експлойтів: Zerologon ( CVE-2020−1472), EternalBlue, PrintNightmare — кожен з яких дозволяє отримати повний контроль навіть без пароля. Ми провели аудит домену за допомогою інструменту PingCastle. Результат — 100 балів зі 100 . Це не оцінка якості. Це шкала ризику, де 100 — найгірший можливий результат. Фото: Результат аудиту домену за допомогою PingCastle Серед знахідок: 52 облікові записи з правами адміністратора домену ( при нормі 3−5), відсутність політики зміни паролів для привілейованих акаунтів, увімкнений протокол SMBv1 та десятки робочих станцій на Windows 7 і навіть Windows XP. Ідеальний обліковий запис для зловмисника Для горизонтального переміщення мережею зловмисник обрав сервісний обліковий запис системи 1С: Підприємство. Чому саме його? Бо цей акаунт мав права Domain Admin, за своєю природою підключався до багатьох машин одночасно ( що маскує підозрілу активність) і, найголовніше, за ним не стояла жодна конкретна людина, яка могла б помітити щось незвичне. Пароль цього акаунту ніколи не змінювався. Акаунт мав дозвіл на інтерактивний вхід по RDP, хоча для роботи сервісу 1С це зовсім не потрібно. Централізоване збирання журналів подій ( логів) у компанії не було налаштовано. Усі логи зберігались локально на кожній машині. Зловмиснику достатньо було очистити один файл на контролері домену — і вся історія автентифікацій зникла. Що він і зробив. Без SIEM, без пересилання логів на захищене сховище, без моніторингу — компанія фактично працювала наосліп. Коли ми почали розслідування, більшість уражених систем вже були перевстановлені IT-командою. Ключовий сервер, з якого зловмисник координував усю атаку, було перевстановлено повністю — це найбільша втрата доказів в цьому кейсі. Цей інцидент не став наслідком якоїсь витонченої хакерської операції. Зловмисники не використовували zero-day вразливостей чи спеціалізованих C2-фреймворків на кшталт Cobalt Strike. Вони просто скористались тим, що їм дали: відкритим RDP, застарілою ОС, надпривілейованим сервісним акаунтом та відсутністю моніторингу. Перевірте просто зараз: чи є у вашій мережі прокидання RDP на зовнішній периметр? Скільки акаунтів мають права Domain Admin? Коли востаннє змінювались паролі сервісних облікових записів? Чи зберігаються ваші логи деінде, окрім самих серверів? Якщо хоча б одна відповідь вас непокоїть — час діяти до того, як цю відповідь знайде хтось інший. Наступна стаття серії: «48 годин усередині мережі: що робить зловмисник перед шифруванням» — покрокова хронологія дій BlackField від першого входу до запуску шифрувальника. Автор: команда DFIR, SHERIFF Кібербезпека Теги:   Sheriff Кібербезпека DFIR VPN Якщо ви знайшли помилку в тексті, виділіть її мишкою і натисніть Ctrl + Enter