Таймінг атак та пошук слабких місць компаній критичної інфраструктури
Інциденти відбулися 29 грудня 2025 року в період між католицьким Різдвом та Новим роком. Цей часовий проміжок обрано дійсно не випадково. По-перше, це період зниженої пильності IT-відділів та SOC-команд, що збільшує час реакції на інциденти безпеки. По-друге, на новорічні та передноворічні свята, зазвичай, як Польща, так і Україна, перебувають под впливом зимових погодних умов: низьких температур та навіть іноді снігових штормів. Звісно, зараз ми говоримо про статистику і логіку, яких часто притримуються зловмисники (ударити в у період найвищої вразливості через обмеженість людських ресурсів). Так історично вже склалося, що для тих, хто зустрічав зиму в Україні в 1990-х та на початку 2000-х - це були засніжені, холодні, але візуально просто прекрасні місяці зими. Тому в нас складається асоціація: зима (особливо у святкові дні) - це має бути сніг та холод.
Атака на енергетику в такий момент є класичним прикладом гібридної війни, де такий вплив на суспільство має на меті викликати соціальну паніку та фізичні наслідки (наприклад, втрату опалення і електроенергії на досить довгий час). Хоча кібератаки не призвели до масового блекауту, втрата керованості устаткуванням в умовах негоди могла стати критичною для балансування енергосистеми. На це, очевидно, й розраховувала сторона атаки. Розмірковування тут досить прості: будь-яка країна, в якій громадяни звикли до звичайного життя (не в умовах війни), такого комфорту позбавляється у найбільш некерований час (майже всі перебувають у відпустках з родинами або на канікулах та готуються зустрічати Новий 2026 Рік). Українці, як ніхто інший, знають, наскільки підступним та нелогічним може бути ворог.
Згідно зі статистичними даними, раніше (у 2015-2016 роках) атаки були спрямовані на великі вузли розподілу або передачі електроенергії, як це відбувається в Україні. Атаки в Польщі вказують на те, що новою ціллю є виробництво відновлюваної енергії. Зловмисники знайомі з тим, що розподілена генерація зараз є життєво важливою частиною енергосистеми, атакуючи точки підключення вітрових та сонячних електростанцій до мережі.
Інцидент виявив проблему, поширену в усій галузі, про яку знають співробітники служби безпеки, а саме різницю між політиками безпеки та їх впровадженням на практиці. Більшість використовуваних технологій (RTU, шлюзи) були розроблені багато років тому, до того, як “Secure by design” став стандартною практикою. Паролі за замовчуванням зазвичай доступні через складність системи, встановленої підрядниками, а не через простий недогляд.
Використання підрядниками дефолтних паролів — це не просто технічна помилка, а катастрофічна "дірка" у Vendor Risk Management. Зловмисники більше не "зламують" мережі, вони в них "логіняться". Безпека має бути інтегрована в контракти з постачальниками (SLA/Safety clauses), включаючи обов'язкову зміну дефолтних налаштувань перед підписанням акту виконаних робіт.
Важливо також зазначити, що стандартні SLA та плани реагування на інциденти (IRP) були неефективними проти зловмисників, які перетворювали OT-пристрої на “мертві цеглини” (brick status) за лічені хвилини. Це виклик, який має подолати вся галузь.
Від Initial Access до вайпу систем
Навіть будучи Junior Security Engineer, ти розумієш, що захист периметру організації - це його перша лінія оборони. Тут немає місця “Shadow IT” і відсутності SIEM-системи, не говорячи вже про інші міри захисту.
Насправді, багато мікро- та малих бізнесів мають проблеми захисту периметра. Стартапи також. Основна проблема: бізнес запускається, щоб якомога швидше з’явився продукт, який можна продавати і почати на цьому заробляти. Безпека активів відходить на другий план.
На своєму досвіді я не раз стикався з проблемами захисту периметру, коли доступ під час пентесту до мережевих пристроїв чи серверів було отримано в межах першої години тестування. Більше того, окрім нас, зловмисники вже там “сиділи” роками. І це при тому, що ми писали кастомний експлоїт, а не користувалися публічним. Тут хочеться зробити акцент на тому, що мережа Інтернет кишить ботами, які виконують сканування всіх “цікавих” діапазонів IP-адрес в мережі, і зловмисники дуже швидко отримують розуміння, куди саме є змога їм “залізти”. Звісно, ніхто не виключає використання онлайн-сервісів пасивної розвідки, таких як Shodan, Censys та Fofa, які збирають дані про відкриті порти та сервіси в мережі Інтернет.
Яскравий приклад: відкрийте “в світ” доступ до сервісу SSH з вавої VPS. Якщо немає можливості виконувати моніторинг запитів, то встановіть рішення Fail2Ban і залиште на 2 години. Ви здивуєтеся кількості брутфорс-запитів на ваш SSH в логах, напевно, вже в перші 20-30 хвилин. Це простенький приклад, що ми з вами проживаємо в часи, коли будь-яка похибка в налаштуваннях чи відсутність компетенцій або нехтування принципами кібергігієни може коштувати вам безповоротної втрати всієї інформації та навіть бізнесу.
В рамках етапу Initial Access було також використано вразливості Fortinet NGFW (core-рівень), які виконували ролі Firewall та VPN-концентраторів. Зокрема, всім відомий Fortinet SSL-VPN, який мало чи не кожного кварталу отримує якийсь новий CVE критичного рівня безпеки. Його необхідно заміняти на Ipsec (з версії FortiOS 7.6.3 SSL VPN Tunnel Mode прибрано як в GUI, так і в CLI).
Приклад: Маючи впроваджений SIEM, до якого надсилаються логи з Fortinet NGFW, ви побачили, що на відкритий порт SSL-VPN налітає мінімум по 1200 запитів зі спробами брутфорсу в межах 24 годин - це робота ботів. Якщо бачите кратно більше невдалих спроб авторизації - хтось таргетовано намагається підібрати облікові дані.
Скріншот зі звіту інциденту на ТЕЦ (CHP Plant)
RDP bookmark з конфігурації Fortinet (скріншот зі звіту)
Це приклад того, що часто спроби піти “коротким” шляхом для зручності повертаються дуже неприємними наслідками для компанії. Фактично, далі зловмисник вже здійснював стандартні дії в мережі - виконав фазу Reconnaissance, визначив вектори атак та отримав доступи до декількох робочих станцій. Все використане в подальшому ним ПЗ є абсолютно публічним - нічого кастомного: Advanced IP Scanner, Edge браузер в приватному режимі, Impacket та інструмент rsocx для створення Reverse SOCKS Proxy, що дозволило обійти NAT та Firewall зсередини мережі.
Фаєрвол на периметрі не врятує, якщо внутрішня мережа - це flat network. Ми повинні будувати архітектуру за принципом Assume Breach (маємо припускати постійний злам). ІТ та ОТ мережі не можуть співіснувати в єдиному "просторі довіри", а тим більше - в одній підмережі. Система безпеки повинна виявляти аномалії всередині мережі, а не лише аналізувати вхідний трафік на периметрі.
Після успішного етапу розвідки, зловмисники йдуть вже знайомим та класичним шляхом, який дуже добре знайомий тим, хто має досвід як Network Pentester чи проходив сертифікаційні іспити CPTS або OSCP:
- дамп LSASS
- створення копій SYSTEM та SAM hives
- створення shadowcopy розділу “C:” для ханту за ntds.dit
Всю інформацію зловмисник спакував у zip-архів та надіслав собі на сервер для подальшої обробки та дампу інформації. Цікаво, що підготовка до атаки почалася задовго до "години Ч": зміни в конфігурацію HMI (відкриття SMB, правила фаєрволу) вносилися ще 8 грудня, тобто зловмисники мали часу на наступний ривок як мінімум 3 тижні.
Після цього було викрадено конфігурацію Fortinet та внесено нові політики в роботу пристрою. Вранці 29.12.2025 на один з контролерів домену (DC) було залито DynoWiper (wiper malware):
Причому файли вайпера були доступні для всіх робочих станцій в підмережі. Антивірус не відреагував на дані файли, а EDR зміг визначити потенційно підозрілу поведінку через модифікацію файлів, які підлягають посиленому контролю (зазвичай це системні каталоги або окремо задані файли) на більш ніж 100 робочих станціях. До речі, так само можна розгорнути так звані canary-файли, які мають зацікавити зловмисника своїм потенційним виглядом або вмістом.
Використавши KVM на одному з домен-контролерів, зловмисник розгорнув образ Tiny Core Linux та мав змогу переписати інформацію на накопичувачах на рандомні дані. В кінці було помічено спробу змінити конфігурацію RAID-масиву на одному з серверів.
У випадку з наступним інцидентом (Manufacturing Sector Company) зловмисник отримав доступ через мережевий пристрій Fortinet (core-рівень). Цей пристрій раніше мав вразливості, за допомогою яких його конфігурація була викрадена і оприлюднена зловмисниками на онлайн-форумі, який використовують злочинні угруповання. Отримавши доступ до пристрою, зловмисник вніс зміни, спрямовані на збереження постійного доступу навіть у разі зміни паролів користувачів, у вигляді CLI-скриптів із щотижневим виконанням.
Особливу увагу слід звернути на метод ексфільтрації даних. Один зі скриптів на FortiGate збирав результати виконання команд та відправляв їх на зовнішній Slack Webhook. Це чудовий приклад техніки Living off the Land, який дозволяє обійти стандартні DLP-системи, оскільки трафік на hooks.slack.com часто є дозволеним:
Не все, що має “хорошу” назву є легітимним
Далі атака розгорнулася схожим способом, як було з ТЕЦ. Використано вайпер сімейства LazyWiper, код якого, скоріш за все, було розроблено за допомогою ШІ.
Також після виявлення облікових даних, для яких існували відповідні облікові записи в службі Microsoft 365, зловмисник завантажив дані з таких служб, як Exchange, Teams і SharePoint. Він був особливо зацікавлений у файлах та електронних листах, пов'язаних із модернізацією мережі OT, системами SCADA та технічною роботою, що виконувалася в організаціях.
Застарілі прошивки OT-обладнання як основа зупинки підприємства
Тут ми переходимо до найцікавішої частини для нас як для фахівців, що розуміють різницю між IT та OT. Атака на промислову автоматику була спрямована не на маніпуляцію процесом (як Stuxnet, наприклад), а на Denial of Service (DoS) через незворотне пошкодження прошивок та конфігурацій контролерів Hitachi RTU560. Вони є критичними елементами механіки на подстанціях.
Тут потрібно виділити 2 ключові проблеми, що призвели до Initial Access:
- Зловмисники використали вбудований обліковий запис Default, який часто ігнорується при налаштуванні. Цей акаунт має привілеї на завантаження прошивки через веб-інтерфейс.
- Навіть наявність механізму перевірки підпису прошивки не зупинила атаку. По-перше, функція часто буває вимкненою. По-друге, також існує вразливість CVE-2024-2617, яка дозволяє обійти цю перевірку авторизованому користувачу. Тобто, в будь-якому разі зловмисник отримав би бажане.
Далі зловмисник завантажив модифікований файл прошивки у форматі ELF, в якому перші 240 байтів були перезаписані послідовністю 0xFF.
Скріншот зі звіту
Фактично, тепер при спробі завантаження такої прошивки виконується зчитування саме 0xFF. Це так званий “invalid opcode”. Виникає апаратне виключення (hardware fault), яке призводить до перезавантаження системи. Оскільки "бита" прошивка вже записана у флеш-пам'ять, пристрій потрапляє у нескінченний цикл перезавантаження (bootloop). Відновлення вимагає фізичного втручання до кожного пристрою, що в масштабах 30 підстанцій є певною мірою логістичним кошмаром.
Окрім RTU, під удар потрапили пристрої релейного захисту Hitachi Relion 650 (IEDs). Атака на них здійснювалася через FTP з використанням дефолтних облікових даних, що дозволило зловмисникам видалити критичні системні файли. Це свідчить про те, що атака зачепила не тільки рівень телеметрії, а й рівень захисту підстанцій.
Ще один недобрий фактор: використання дефолтних налаштувань (облікових даних) - зловмисник отримав доступ до Mikronika RTU (контролери) та Moxa NPort систем:
- Атака на Mikronika RTU здійснювалася через SSH з використанням пароля для root за замовчуванням. Команда знищення була тривіальною (імовірно rm -rf /* або перезапис блочних пристроїв через dd), що призвело до повного видалення файлів та даних.
- Moxa NPort пристрої використовуються для конвертації RS-232/485 в Ethernet. Зловмисник скинув їх до заводських налаштувань, змінив пароль адміністратора та встановив IP-адресу на 127.0.0.1 (localhost). Це класичний приклад “logical bomb”: пристрій працює, але недоступний з мережі, а його інтерфейс "слухає" сам себе. Відновлення можливе лише через консольний порт на місці (фізично).
І останнє, на чому варто обов’язково наголосити, це вкотре дефолтні конфігурації облікових записів. У деяких випадках як HMI використовувалося програмне забезпечення Mikronika Syndis, встановлене на системах Windows 10. Машини були налаштовані з використанням стандартного пароля, встановленого під час розгортання облікового запису з правами локального адміністратора.
Зловмисник використав ці дані та отримав доступ до робочої станції за допомогою RDP. Далі, зловмисники використали PowerShell скрипти з метою замаскувати розшарені каталоги (SMB):
Скріншот зі звіту
- Скрипт PowerShell виконував модифікацію реєстру.
- Встановлено значення 0 для AutoShareWks та AutoShareServer
(
HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters). - Це призводить до відключення прихованих адміністративних ресурсів SMB (C$, ADMIN$, IPC$).
Далі зловмисники використали Impacket та DynoWiper для того, щоб вивести з ладу робочі станції.
Атрибуція гібридної атаки
Наразі ми бачимо злиття інструментарію та тактик, які раніше приписувалися різним спецслужбам РФ (як би це не звучало дивно). Досить коротенько розглянемо, які саме індикатори кому належать.
У звітах CERT-груп це угруповання фігурує під назвою Static Tundra. Це команда, яка спеціалізується на атаках на критичну інфраструктуру. Аналіз коду використаних вайперів та інструментів вказує на їхній зв'язок з іншим відомим угрупованням - Sandworm.
Спільні риси в коді Static Tundra та Sandworm (яку часто пов’язують із Berserk Bear, Dragonfly чи Energetic Bear) - це не просто збіг. Це робота однієї структури. Використання вайперів замість шифрувальників чітко вказує на мету: не викуп, а саботаж та дестабілізація енергосистеми Європи.
- Static Tundra
Аналіз мережевих індикаторів (IP-адреси, проксі-сервери, скомпрометовані роутери) чітко вказує на групу Static Tundra (також відому як Berserk Bear, Dragonfly, Energetic Bear). Що саме видає почерк:
- Використання вразливостей для компрометації роутерів та використання їх як проксі.
- "Harvesting" облікових даних та даних конфігурацій з VPN-концентраторів та шлюзів.
- Довготривала, прихована присутність у мережах енергетичного сектору (до цього використовувалася переважно для шпигунства).
- Sandworm
Щодо тактичних маневрів та ключової цілі (судячи зі звіту), ми бачимо деструктивний почерк - це є візитною карткою Sandworm (Voodoo Bear, Seashell Blizzard, ГРУ, в/ч 74455). Що саме видає:
- Використання вайперів (KillDisk, CaddyWiper, Industroyer).
- Атаки на OT з метою викликати відключення електроенергії.
- Таймінг (зима, свята) - елементи психологічного тиску.
Стратегічні рекомендації для посилення захисту
Проаналізувавши звіт від CERT-PL, маю наголосити, що, як би не здавалося, що в цих випадках у всьому винні лише злиті облікові дані чи конфіги пристроїв периметру і що достатньо поміняти паролі - це далеко не так.
Враховуючи розглянуті кейси, хочеться наголосити на контролях безпеки та принципах архітектури мережі, про які варто пам’ятати. При цьому, важливо розбити рекомендації на окремі рівні:
- Захист на рівні архітектури мережі
- Відмовитись від “flat network”. Ні в якому разі не розміщувати ІТ та ОТ-пристрої в одній підмережі або VLAN.
- Доступ до ОТ-пристроїв має відбуватися лише з Jump Hosts або PAW, які не мають прямого виходу в мережу Інтернет.
- Для ОТ-пристроїв маємо завжди тримати версії прошивок актуальними. Так, є випадки, коли це зробити майже неможливо через певні впроваджені додаткові рішення в компанії. В такому випадку - максимально ізолювати доступ до пристроїв, моніторити трафік, миттєво реагувати на інциденти та проводити Threat Hunting.
- Чудово, якщо ОТ-пристрої мають перемикачі “write protect”, що дозволяють уникнути перезапису чи несанкціонованого втручання в програмну частину пристроїв.
- Розгорнути Deception-рішення (для прикладу, протестуйте T-POT) для відведення уваги та миттєвого реагування на активність зловмисників.
- Вимагати від виробників обладнання ОТ реалізації апаратного Secure Boot, який неможливо вимкнути програмно або обійти через CVE/Zero-Day.
- Захист на рівні ОС
- Налаштувати або розгорнути SIEM (модуль FIM, хоча більш інформативним в даному випадку буде саме SysMon) та моніторити цілісність і зміни критичних файлів ОС, а також зміни реєстру.
- Розмістити Ransomware Canaries на критичних робочих станціях для швидкого реагування при доступі до файлів. EDR має реагувати на спробу зміни цих файлів миттєвою ізоляцією хоста.
- Моніторинг спроб входу під дефолтними акаунтами (Default, admin, root) та спроб завантаження файлів (SCP, HTTP).
- Не забуваємо про EDR-рішення як такі. Стандартне антивірусне рішення ОС Windows не є тим рішенням, яке добре захищає навіть у більшості досить тривіальних випадків.
- Без IAM та PAM ніяк
- Впровадження MFA для доступу до всіх критичних сервісів.
- Відмовитись від постійних адміністративних прав. Адміністратори повинні отримувати права тільки на час виконання робіт (т.зв. JIT admin access).
- Впровадити AD Tier Model.
- Впровадити LAPS для автоматизованої ротації паролів сервісних акаунтів та локальних адміністраторів.
- Перейти від ручного управління паролями до автоматизованих систем, які забезпечують ротацію паролів та ізоляцію сесій.
- Incident Response Tabletop Exercises (TTX): Регулярне тренування топ-менеджменту та технічних команд реагувати на сценарії подібних атак, перш ніж вони стануть реальністю.
Інцидент 29 грудня став важливим уроком для всієї спільноти. Він показав, що в епоху гібридних воєн кібербезпека є невід’ємною частиною фізичної безпеки країни. Позитивним сигналом є те, що польська енергосистема вистояла, а на окремих об’єктах атака була успішно відбита технічними засобами.
Наше завдання - використати цей досвід для зміцнення власних рубежів. Пам’ятайте: безпека - це не стан, а процес. І в цьому процесі "дрібних проблем" не буває.
Будьте в безпеці!