NotPetya: коли «шкідливе ПЗ» поводилося як кувалда

NotPetya в одній сторінці: що він робив і чому це було важливо

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

Практичний висновок: оплата викупу не гарантувала відновлення, бо процес «викуп → відновлення» був фактично зламаний.
Шкода полягала не в «заблокованих файлах», а в «машини не завантажуються, і відновлення — це перевстановлення + відновлення».
Якщо ваша модель відновлення передбачала «ми вилікуємо кінцеві пристрої», NotPetya перетворив це на «нам потрібно перевстановити парки й відновити ідентичність».

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

Одна інженерна максима лишається актуальною, і це цитата, яку варто тримати на стіні:
Надія — це не стратегія. — перефразована ідея, пов’язана з генералом Гордон Р. Салліваном

Жарт №1: NotPetya був «ransomware» так само, як бульдозер — це «ландшафтні роботи». Можна заплатити; двір все одно зник.

Факти та контекст, які варто запам’ятати

Це не дрібниці; це важелі, що пояснюють, чому інцидент розкручувався саме так.

• Він вдарив у червні 2017 року, розповсюдившись швидко корпоративними мережами й викликавши глобальні збої.
• Часто проникнення відбувалося через скомпрометований механізм оновлення ПЗ (класичне порушення ланцюга постачання), а не лише через фішинг.
• Він зловживав адміністративними інструментами Windows, такими як PSExec і WMIC — інструменти, які ваші адміністратори використовували щодня.
• Він використовував викрадення облікових даних (скребінг пам’яті / дампинг обліків) для бічного руху там, де патчинг сам по собі був недостатнім.
• Він також поширювався через SMB, використовуючи різні методи, включно з експлуатацією непатчених хостів і застосуванням дійсних облікових даних.
• Він пошкоджував завантажуваність, втручаючись у завантажувальні записи та шифруючи ключові структури диска; відновлення часто означало перевстановлення.
• Канал оплати викупу фактично не працював, отже навіть «успішна оплата» не гарантувала реального дешифрування.
• Спочатку його неправильно називали «Petya ransomware», що ускладнило плани реагування, заточені під фінансово-мотивований ransomware.
• Це підкреслило ризики плоских мереж: опинившись всередині, він знаходив спільні адміністративні шляхи, як вода знаходить тріщини.

Якщо запам’ятати лише одне: початковий вектор компрометації важить менше за ті внутрішні контролі, яких вам бракувало.
NotPetya не був фокусом; це був аудит повсякденних спрощень.

Як працював NotPetya: механіка «wiper у масці ransomware»

1) Вхід: ланцюг постачання перемагає театри периметра

Організації, які вважали, що «не є мішенню», все одно постраждали, бо точка входу в багатьох випадках не була персоналізованим spearphishing.
Скомпрометований механізм оновлення дає нападнику підписаний на вигляд бінарник з каналом розповсюдження, який ви вже дозволяєте.
Саме тому «ми блокуємо виконувані файли в пошті» — необхідно, але недостатньо; і саме тому фільтрація egress та дозволи на запуск додатків
стають реальними заходами безпеки, а не театром відповідності.

2) Поширення: експлойти + обліки + адмін-інструменти

NotPetya не ставив усе на один метод. Він комбінував кілька шляхів для переміщення:

• Поширення через експлойти проти вразливих реалізацій SMB на непатчених Windows-системах.
• Поширення на основі облікових даних — коли він отримував паролі/хеші, ваші власні права адміністратора ставали його транспортом.
• Віддалене виконання через PSExec/WMIC, яке часто проходило непоміченим, бо «це внутрішня мережа» і «адміністратори цього потребують».

Такий багатоплановий підхід важливий операційно. Менеджмент патчів сам по собі не врятує, якщо у вас погана гігієна облікових даних.
Навпаки, ідеальні паролі не врятують, якщо в тій же широкомовній доменній зоні залишилися непатчені старі машини.
Захист має бути багатошаровим, бо й атакуючий вже таким є.

3) Навантаження: ламати завантажувальний ланцюг, а не лише файли

Родина «Petya-ish» відома тим, що ламає процес завантаження. NotPetya йшов на низькорівневі структури диска.
Це та частина, яка перетворює інцидент із шкідливим ПЗ на логістичний інцидент: конвеєри іміджів, надійність USB/PXE-завантаження,
драйверні пакети, ключі BitLocker і відхилення «золотих образів» раптово стають критичними.

Ви також швидко дізнаєтеся, які «бекапи» були просто снапшотами вже зашифрованих даних, а які справді були незмінними,
офлайн і відновлюваними під тиском.

4) Часування та поведінка при перезавантаженні: чому відчуття було, ніби підлога впала

NotPetya часто ініціював перезавантаження, щоб виконати свій завантажувальний саботаж. Це психологічно важливо: користувач бачить перезавантаження,
знехтує, піде за кавою і повернеться до екрану з черепом і кістками. Потім службу підтримки викликають ІТ. Потім ІТ кличуть всіх.
Тим часом бічний рух уже відбувся.

Ось чому «ми його вимкнемо, коли помітимо» зазвичай запізно. Якщо ваше виявлення залежить від уваги кінцевих користувачів,
ви будуєте систему безпеки на основі надії та кофеїну.

5) Справжній вплив: ідентичність, DNS і спільні сервіси

NotPetya вбивав не лише робочі станції. Він ламав речі, якими ці станції користувалися: контролери домену, файлові сервери, сервери розгортання,
точки розповсюдження програмного забезпечення, колектори моніторингу. Коли вони падають, бізнес виявляє, що не може навіть координувати відновлення.

Якщо ваш план реагування вимагає «натиснути й розгорнути агент на всіх хостах», а ваша система розподілу ПЗ недоступна, вітаю:
ваш план — це документ, а не спроможність.

Де організації зазнали невдач: передбачувані слабкі місця

Плоскі мережі: стандартна архітектура жалю

Багато корпоративних LAN досі поводяться як дружнє селище, де всі будинки ділять один коридор.
Коли NotPetya потрапляє на один кінцевий пристрій, він бачить файлові шари, адміністративні порти та шляхи віддаленого виконання скрізь.
Сегментація не гламурна. Вона також найпростіший спосіб перетворити «глобальний збій» на «локальний інцидент».

Розростання облікових даних: доменний адміністратор на робочій станції — заряджена зброя

NotPetya любив облікові дані, бо вони універсальні. Експлойти вибагливі; паролі — ні.
Якщо доменні адміністратори або облікові записи з високими привілеями заходять на кінцеві пристрої, ці секрети опиняються в пам’яті, а пам’ять — це буфет.
Виправлення нудне й суворе: модель рівнів адміністрування, привілейовані робочі станції, LAPS/Windows LAPS і видалення прав адміністратора у користувачів.

Віддалене виконання залишено відкритим: PSExec — не лиходій, ваші контролі —

PSExec і WMIC популярні, бо працюють. NotPetya використовував їх, бо ви дозволяли їм працювати всюди.
Ви можете зберегти віддалене адміністрування і одночасно зменшити радіус ураження: обмежити, хто може викликати ці інструменти, звідки це можна робити,
логувати виклики та ізолювати адмін-інструменти в підмережах управління.

Бекапи, які не відновлювалися в масштабі

«У нас є бекапи» — це речення нічого не означає, якщо ви не можете відповісти: відновити що, як швидко, у якій послідовності і без AD.
NotPetya змусив підприємства виявити, що їхній процес відновлення залежить від продакшн AD, продакшн DNS і продакшн файлових шарів.
Коли вони виведені з ладу, сценарій відновлення стає інтерпретативним танцем.

Моніторинг, який вимкнувся разом з мережею

Централізований логінг і моніторинг гарні — поки вони не лежать в тій самій мережі, що щойно була заблокована.
Вам потрібен принаймні один позасітовий огляд: tap, окрема мережа управління або хмарна телеметрія, яка витримує внутрішній хаос.
Якщо ви не бачите — ви не можете триажити і не можете довести ізоляцію.

Швидкий план діагностики: що перевіряти першочергово/другим/третім, щоб швидко знайти вузьке місце

Це для першої години, коли всі кричать, а ваше завдання — перетворити паніку в чергу.
Мета — визначити: (1) чи ми ще поширюємося, (2) яка спільна служба є вузьким місцем, (3) що ми можемо відновити першочергово.

Перше: зупиніть кровотечу (поширення)

1. Підтвердіть активний бічний рух шляхом перевірки сплесків трафіку SMB/RPC, аномалій аутентифікацій та створення віддалених сервісів.
2. Втрутіться в мережу стратегічно: блокуйте SMB (445) між сегментами; обмежте адмін-протоколи до підмереж управління.
3. Тимчасово відключіть відомі зловживані шляхи інструментів: створення сервісів PSExec, віддалений WMI та адмінські шари між VLAN користувачів.

Друге: захистіть і перевірте служби ідентичності

1. Перевірте контролери домену: чи доступні вони, здорові, синхронізовані за часом і чи не перезавантажуються в нісенітницю?
2. Заморозьте привілейовані облікові записи: відключіть або скиньте обліки з високим ризиком, обертайте сервісні паролі, де можливо.
3. Підтвердьте цілісність DNS і DHCP: якщо розв’язування імен спотворено або недоступне, інструменти відновлення працюватимуть дивно.

Третє: визначте стратегію відновлення (перевстановлення проти відновлення)

1. Виберіть «золоту острів»: чистий сегмент мережі з чистими адмін-робочими станціями та чистими інструментами.
2. Пріоритезуйте бізнес-сервіси: ERP, доставку, виробництво, ідентичність, пошту — те, що тримає бізнес на плаву.
3. Підтвердіть бекапи, відновивши репрезентативну систему в «золотій острівній» мережі. Не сперечайтесь; відновлюйте.

Ваш найшвидший виграш часто — відновити здатність (ідентичність + мінімальні додатки), а не ганятися за ідеальною судовою експертизою.
Форензика важлива. Але також важливий зарплатний розрахунок у п’ятницю.

Практичні завдання: команди, виводи та рішення (12+)

Це практичні завдання, які можна виконувати під час інциденту типу NotPetya або під час вправ з жорсткості. Виводи — приклади.
Сенс не в тому, щоб їх зазубрити; а в тому, щоб мати м’язову пам’ять щодо того, що означає вивід і що робити далі.

Завдання 1: Виявити раптові хвилі підключень SMB на Linux-шлюзі

cr0x@server:~$ sudo ss -tnp '( sport = :445 or dport = :445 )' | head
ESTAB 0 0 10.10.20.5:51234 10.10.30.12:445 users:(("smbd",pid=2140,fd=45))
SYN-SENT 0 1 10.10.20.5:51301 10.10.30.19:445 users:(("smbclient",pid=9921,fd=3))
ESTAB 0 0 10.10.20.8:49822 10.10.30.12:445 users:(("smbd",pid=2140,fd=52))
...

Що це означає: Порція нових спроб SMB (SYN-SENT) плюс багато встановлених сесій може вказувати на сканування або масовий доступ до шарів — схожі на хробака активності.

Рішення: Якщо це аномально, негайно блокуйте 445 між VLAN користувачів і обмежте SMB лише до підмереж файлових серверів.

Завдання 2: Подивитись топ-джерела трафіку до порту 445 на маршрутизаторі/фаєрволі

cr0x@server:~$ sudo conntrack -L | grep dport=445 | awk '{print $5}' | cut -d= -f2 | sort | uniq -c | sort -nr | head
  482 src=10.10.20.5
  219 src=10.10.20.8
   77 src=10.10.21.33
...

Що це означає: Невелика кількість джерел, що генерують сотні SMB-потоків, підозріла в офісних мережах.

Рішення: Ізолюйте топ-джерела на рівні порту комутатора або VLAN. Не чекайте, поки інструменти кінцевих точок стануть співпрацювати.

Завдання 3: Перевірити здоров’я реплікації домену Windows з хосту управління (через WinRM)

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"repadmin /replsummary\""
Replication Summary Start Time: 1/22/2026 02:14:50

Source DSA          largest delta    fails/total %%   error
DC1                 00:01:12         0 / 20    0
DC2                 00:00:58         0 / 20    0

Destination DSA     largest delta    fails/total %%   error
DC1                 00:01:12         0 / 20    0
DC2                 00:00:58         0 / 20    0

Що це означає: Здорова реплікація свідчить, що AD наразі не розвалюється. Під час wiper-події стабільність AD — це кисень.

Рішення: Якщо кількість збоїв реплікації зростає або затримки збільшуються, пріоритетом має бути ізоляція й відновлення DC, а не прикладні сервери. Все інше від цього залежить.

Завдання 4: Виявити неочікуване створення віддалених сервісів (поширено з PSExec)

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045; StartTime=(Get-Date).AddHours(-2)} | Select-Object -First 5 | Format-List\""
ProviderName : Service Control Manager
Id           : 7045
Message      : A service was installed in the system. Service Name: PSEXESVC Display Name: PSEXESVC
...

Що це означає: Подія з Id 7045 з PSEXESVC вказує на віддалене виконання у стилі PSExec.

Рішення: Якщо це неочікувано, блокуйте вхідні адмін-шари та віддалені SCM-виклики між сегментами робочих станцій; негайно розслідуйте джерелові хости.

Завдання 5: Перевірити сліди віддаленого виконання WMIC

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-2)} | Where-Object { $_.Message -match 'wmic.exe' } | Select-Object -First 3 | Format-Table -Auto\""
TimeCreated           Id Message
-----------           -- -------
1/22/2026 01:42:10 4688 A new process has been created... New Process Name: C:\Windows\System32\wbem\WMIC.exe ...

Що це означає: Події створення процесів із згадкою WMIC можуть указувати на віддалене виконання команд або інвентаризаційні інструменти. Контекст важливий.

Рішення: Якщо це з’являється на кінцевих пристроях користувачів або походить від незвичних батьківських процесів, трактуйте як активну компрометацію і ізолюйте хост.

Завдання 6: Підтвердити, чи увімкнено SMBv1 на Windows-хостах

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol\""
FeatureName      : SMB1Protocol
State            : Enabled

Що це означає: Увімкнений SMBv1 — постійний фактор ризику; це не «причина», але збільшує швидкість поганих днів.

Рішення: Вимикайте SMBv1 широко, але поетапно: спочатку ідентифікуйте застарілі залежності, потім ізолюйте їх. Не дозволяйте одному старому копіювальному пристрою диктувати безпеку мережі.

Завдання 7: Побачити, які хости відкривають адмін-шари з Linux-сканера

cr0x@server:~$ for ip in 10.10.20.{1..20}; do timeout 1 bash -c "echo >/dev/tcp/$ip/445" 2>/dev/null && echo "$ip:445 open"; done
10.10.20.5:445 open
10.10.20.8:445 open
10.10.20.12:445 open

Що це означає: Велика кількість робочих станцій, які приймають 445 від однокоординатних ворогів, означає, що бічний рух має легкі лінії.

Рішення: Впровадьте правила брандмауера на хості або мережеві ACL, щоб робочі станції не приймали SMB від сусідніх робочих станцій.

Завдання 8: Виявити машини, які несподівано перезавантажуються (перспектива Linux-хоста віртуалізації)

cr0x@server:~$ sudo journalctl -u libvirtd --since "2 hours ago" | grep -E "shutdown|reboot|destroy" | head
Jan 22 01:31:02 hv01 libvirtd[1120]: Domain win-app-03 destroyed
Jan 22 01:31:18 hv01 libvirtd[1120]: Domain win-app-03 started
...

Що це означає: Раптові шаблони перезавантажень на Windows-VM можуть збігатися з тим, що шкідливе ПЗ ініціює перезавантаження для виконання змін на рівні завантаження.

Рішення: Призупиніть автоматичні рестарти; зніміть снапшоти для судової експертизи при потребі; ізолюйте мережеве підключення підозрілих VM.

Завдання 9: Перевірити видимість MBR/таблиці розділів з Linux-рятувального середовища

cr0x@server:~$ sudo fdisk -l /dev/sda | head -n 15
Disk /dev/sda: 240 GiB, 257698037760 bytes, 503316480 sectors
Disk model: SSD 860 EVO
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1  *     2048 503316479 503314432   240G  7 HPFS/NTFS/exFAT

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

Рішення: Не намагайтеся робити «швидкі виправлення» на продукційних дисках. Зберігайте образи для розслідування; переходьте на перевстановлення + відновлення, якщо у вас немає доведеної процедури відновлення.

Завдання 10: Підтвердити незмінність/повітряні припущення бекапів (приклад об’єктного сховища через s3cmd)

cr0x@server:~$ s3cmd info s3://corp-backups/windows/DC1-2026-01-22.vhdx
File size: 68719476736
Last mod: Tue, 22 Jan 2026 01:10:02 GMT
MIME type: application/octet-stream
MD5 sum: 1b2c3d4e5f...
Server side encryption: AES256

Що це означає: Бекап існує і метадані виглядають коректно. Це не доводить, що він незмінний або відновлюваний, але це перший фільтр.

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

Завдання 11: Перевірити «всі є локальними адміністраторами» на Windows

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-LocalGroupMember -Group 'Administrators' | Select-Object Name\""
Name
----
BUILTIN\Administrator
CORP\Domain Admins
CORP\Helpdesk
CORP\someuser

Що це означає: Доменні групи та випадкові користувачі в локальній групі Administrators роблять викрадення обліків значно ціннішим.

Рішення: Приберіть широкі групи з локальних адміністраторів; впровадьте LAPS; вимагайте привілейованого доступу через присвячені адміністраторські обліки та пристрої.

Завдання 12: Підтвердити, чи політики кешування облікових даних занадто ліберальні

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"reg query 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' /v CachedLogonsCount\""
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    CachedLogonsCount    REG_SZ    10

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

Рішення: Налаштуйте кешування відповідно до бізнес-потреб. Для високоризикових сегментів (фінанси, адміністратори) зменшіть кеш і впровадьте MFA + привілейовані робочі станції.

Завдання 13: Знайти хвилі автентифікацій Kerberos, що натякають на зловживання обліками

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddMinutes(-30)} | Measure-Object\""
Count    : 18423
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

Що це означає: Раптовий сплеск запитів на видачу квитків може корелювати з масовими аутентифікаційними спробами і бічним рухом.

Рішення: Обмежте швидкість і ізолюйте підозрілі підмережі; дослідіть топ-хости-заявники; розгляньте екстрену зміну паролів для вразливих сервісних обліків.

Завдання 14: Перевірити, чи ваш «золотий образ» справді доступний і актуальний

cr0x@server:~$ ls -lh /srv/images/windows-2019-golden.wim
-rw-r--r-- 1 root root 5.3G Jan 10 03:12 /srv/images/windows-2019-golden.wim

Що це означає: У вас є файл образу. Мітка часу вказує, що він може бути застарілим щодо циклів патчів.

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

Жарт №2: Ваш план реагування, який залежить від «віддалитися в інфікований хост і запустити інструмент», милий.
Це як планувати гасіння пожежі, надсилаючи електронного листа з димом.

Три корпоративні міні-історії з радіуса ураження

Міні-історія 1: Інцидент через хибне припущення

Середньої величини виробнича компанія мала змішане Windows-середовище: сучасну офісну мережу плюс застарілі машини суміжні з OT,
які «не можна чіпати», бо вони керували лініями пакування. Команда безпеки припустила, що OT-пристрої ізольовані,
бо вони були в іншому діапазоні IP. Насправді вони не були ізольовані. Вони просто мали інші номери.

Коли первинне зараження з’явилося в бухгалтерії, перша реакція була класичною: вимкнути вкладення в пошті, заблокувати кілька хешів
і попросити користувачів не клацати. Команда вірила, що загроза залишиться на місці, бо «це ransomware».
За годину кількість звернень у службу підтримки різко зросла: файлові шари недоступні, логіни зависають, випадкові перезавантаження.

Хибне припущення виявилося у фаєрволі: практично не існувало внутрішніх правил «схід-захід». SMB, RPC та адмін-шари текли вільно.
«OT-діапазон» був повністю доступний із офісних десктопів, бо хтось одного разу відкрив правило для оновлення ПЗ і ніколи не прибрав його.
Той старий дозвіл став магістраллю.

Відновлення було жорстким, але повчальним. Їм довелося масово перевстановити кінцеві пристрої, потім відновити довіру: рівні AD, LAPS, сегментація за функціями
і явна заборона «робоча станція → робоча станція SMB». Болісний урок полягав не в тому, що шкідливе ПЗ хитре. Урок — мережі чесні:
якщо маршрут існує — ресурс доступний.

Міні-історія 2: Оптимізація, що обернулася проти

Ритейл-компанія оптимізувала адміністрування Windows заради швидкості. Команда управління кінцевими пристроями використовувала один високо-привілейований
сервісний обліковий запис для розгортання ПЗ через віддалене виконання на тисячах машин. Це було ефективно, послідовно й улюблене.
«Один обліковий запис, щоб ними керувати», — казали вони з надлишком впевненості.

Під час спалаху дампинг облікових даних перетворив цю оптимізацію на катастрофічний посилювач.
Коли на одній машині зібралися матеріали облікового запису сервісу, він став скелетом-ключем для всього парку.
Шкідливе ПЗ не потрібно було брутфорсити. Воно просто імітувало те, від чого компанія залежала.

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

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

Міні-історія 3: Нудна, але правильна практика, що врятувала

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

Коли поведінка типу NotPetya вдарила (вхід через ланцюг постачання, швидкий бічний рух, проблеми з завантаженням), їхній моніторинг загорівся,
і вони зробили непривабливе одразу: зупинили схід-захід SMB у ядрі, а потім виокремили чисту підмережу управління.
Вони прийняли, що деякі хости втрачено, і перейшли прямо до перевстановлення.

Вправи з відновлення окупилися дуже конкретно: у них були офлайн-копії матеріалів для відновлення AD і вони знали, як підняти
мінімальну службу ідентичності без залежності від інфікованого домену. Вони також знали, які бекапи «приємно мати», а які
критичні для виставлення рахунків і виконання клієнтських завдань.

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

Поширені помилки: симптом → коренева причина → виправлення

1) Симптом: «Ми ізолювали перший заражений ноутбук, але більше машин продовжують падати.»

Коренева причина: Бічний рух уже стався через облікові дані та адміністративні інструменти; початковий хост не був єдиним розповсюджувачем.

Виправлення: Блокуйте SMB та віддалені адмін-протоколи між сегментами робочих станцій; обертайте високовартісні облікові дані; шукайте активність PSExec/WMIC у масштабі.

2) Симптом: «Патчі не допомогли; ми були патчені і все одно постраждали.»

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

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

3) Симптом: «Бекапи є, але зараз відновлення неможливе.»

Коренева причина: Процес відновлення залежить від продакшн AD/DNS/файлових шарів, які недоступні або недовірені.

Виправлення: Створіть чисте середовище для відновлення; зберігайте офлайн-обліки/ключі; практикуйте відновлення при недоступності AD; тримайте незмінні/офлайн-копії.

4) Симптом: «Ми не можемо ніде увійти; автентифікація повсюди падає.»

Коренева причина: Контролери домену вражені, зсув часу, проблеми з DNS або масова зміна паролів без правильної послідовності.

Виправлення: Спершу стабілізуйте DC; перевірте синхронізацію часу; підтвердіть роботу DNS; виконуйте контрольовану ротацію облікових даних починаючи з tier-0.

5) Симптом: «Інструменти кінцевої точки показують зелений статус, але користувачі повідомляють про петлі перезавантаження та проблеми із завантаженням.»

Коренева причина: Пошкодження завантажувальних записів і дискового рівня; агенти не можуть доповісти, якщо ОС не завантажується.

Виправлення: Перейдіть на конвеєр іміджів/перевстановлення; зберігайте судові образи дисків; не витрачайте години на «очищення» несумісних із завантаженням систем.

6) Симптом: «Утримання не вдалося, бо ми не встигли швидко запустити правила фаєрвола.»

Коренева причина: Надмірна залежність від централізованого управління, яке розділяє долю з інфікованою мережею.

Виправлення: Попередньо підготуйте мережеві ACL-плейбуки на основних комутаторах/фаєрволах; тримайте позасітовий доступ; тестуйте екстрені шляхи змін.

7) Симптом: «Лише один філіал отримав оновлення, але штаб-квартира теж впала.»

Коренева причина: Хаб-енд-спок підключення з широкою довірою; спільні адмін-облікові дані або спільні сервіси між мережами.

Виправлення: Сегментуйте за межами довіри; обмежте використання адмін-обліків між сайтами; використовуйте окремі домени управління або PAM jump-хости.

Контрольні списки / покроковий план

Фаза 0 (зараз, до наступного спалаху): зменшити радіус ураження

1. Сегментуйте мережу: за замовчуванням блокуйте SMB/RPC між робочими станціями. Дозвольте лише до потрібних серверів.
2. Вимкніть SMBv1 широко; винятки ізолюйте за жорсткими ACL.
3. Впровадьте LAPS/Windows LAPS, щоб локальні адмін-паролі були унікальними й ротованими.
4. Розподіліть рівні адміністраторів: забороніть логіни доменних адміністраторів на робочих станціях; використовуйте привілейовані робочі станції.
5. Обмежте PSExec/WMIC: визначте, хто може віддалено виконувати; логujte створення сервісів та підозрілі WMI-виклики.
6. Зробіть бекапи живучими: незмінні копії, офлайн/air-gapped де можливо, і вправи з відновлення передбачаючи недоступність AD.
7. Підготуйте «золоту острів»: чисті джамп-хости, чисті інструменти та підмережа управління, що може працювати під час інциденту.
8. Інструментуйте рух схід-захід: якщо ви не бачите бічного руху, ви не зможете його стримати.

Фаза 1 (перша година): стримати

1. Оголосіть інцидент рано і заморозьте ризикові зміни. Потрібен один технічний командир, а не комітет.
2. Заблокуйте SMB (445) і віддалені адмін-протоколи між VLAN робочих станцій на ядрі мережі.
3. Ізолюйте топ-джерела трафіку, виявлені за мережею (хвилі SMB, аутентифікаційні хвилі).
4. Захистіть контролери домену: логічно ізолюйте їх; дозвольте доступ лише з підмереж управління.
5. Вимкніть або скиньте обліки з високими привілеями, якщо є підозра на компрометацію (домени адміністраторів, обліки розгортання).

Фаза 2 (день 1–3): відновити здатність, потім довіру

1. Підніміть чисте середовище управління (джамп-хост, іміджинг, логування) окремо від інфікованих сегментів.
2. Перевстановлюйте з відомо добрих образів, а не «лікуйте» кінцеві пристрої. Wiper карає оптимізм.
3. Відновлюйте пріоритетні сервіси у порядку залежностей: ідентичність/DNS/DHCP → ядро додатків → файлові служби → кінцеві пристрої.
4. Систематично обертайте облікові дані, починаючи з tier-0. Документуйте, що і коли було змінено.
5. Доведіть ізоляцію за даними мережі та журналів подій перед тим, як з’єднувати сегменти назад.

Фаза 3 (тиждень 2+): не витрачайте біль даремно

1. Напишіть хронологію, поки спогади свіжі: початковий доступ, поширення, виявлення, стримування, відновлення.
2. Честно виміряйте MTTR: не коли сервери завантажилися, а коли бізнес відновився.
3. Перетворіть знахідки на контролі: правила сегментації, рівні обліків, вправи з бекапів і моніторинг, що переживає відмови.

Питання й відповіді

NotPetya — це ransomware чи wiper?

Операційно ставтеся до нього як до wiper. Він показував записку з вимогою викупу, але відновлення через оплату було ненадійним.
Ефект був руйнівним і системним.

Чому він так швидко ширився всередині компаній?

Бо комбінував кілька методів: експлуатацію SMB, викрадення облікових даних і віддалене виконання через стандартні адмін-інструменти.
Плоскі мережі та спільні облікові дані зробили внутрішнє середовище єдиною великою зоною довіри.

Чи запобігло б вимкнення SMBv1?

Це зменшило б один високоризиковий шлях поширення, але не ліквідувало б поширення на основі облікових даних і зловживання адмін-інструментами.
Потрібні сегментація, мінімальні привілеї та гігієна облікових даних на додаток до патчів і жорсткого налаштування протоколів.

Який єдинальний найважливіший крок для стримування?

Зупиніть рух схід-захід: блокуйте SMB і віддалені адмін-протоколи між сегментами робочих станцій на мережевому рівні.
Ізоляція кінцевих пристроїв чудова, коли працює; мережеві контролі працюють, коли кінцеві пристрої вже вогні.

Чи слід вимикати інфіковані машини?

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

Як бекапи зазвичай виходять з ладу в таких подіях?

Зазвичай через залежності: відновлення вимагає продакшн AD/DNS, каталог бекапів знаходиться на інфікованому шарі, або бекапи не є незмінними й теж видаляються.
Вирішення — вправи з відновлення в чистому середовищі й хоча б одна офлайн/незмінна копія.

Що слід моніторити, щоб виявити бічний рух, схожий на NotPetya?

Сплески підключень SMB, журнали подій про створення віддалених сервісів (наприклад, PSEXESVC), неочікуване виконання WMI, аутентифікаційні хвилі (Kerberos/NTLM)
і раптові перезавантаження на багатьох хостах.

Чи допомагає списки дозволених додатків (application allowlisting)?

Так, особливо проти несподіваних бінарників і підозрілих запусків із шляхів, доступних для запису користувача.
Але allowlisting не врятує вас, якщо нападник виконує легітимні адмін-інструменти з викраденими обліковими даними. Використовуйте його як шар, а не як талісман.

Як безпечно відновити Active Directory, якщо DC були вражені?

З документованим, відрепетированим планом: ізолюйте підозрілі DC, перевірте реплікацію/здоров’я, вирішіть, відновлювати з відомо добрих бекапів чи ні,
і обертайте привілейовані облікові дані після відновлення довіри. Якщо ви ніколи практично не відновлювали AD — не починайте імпровізувати в кризі.

Який найкращий довгостроковий захист проти проникнення через ланцюг постачання?

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

Практичні подальші кроки

NotPetya не був вражаючим через новизну. Він був вражаючим, бо сумісний з тим, як підприємства реально працюють:
спільні облікові дані, широка придатність мережі і надмірна впевненість, що «внутрішнє» означає «безпечно».

Якщо ви керуєте продукційними системами, зробіть три речі цього кварталу:

1. Впровадьте сегментацію, яка блокує SMB/RPC між робочими станціями і доведіть це тестами.
2. Виправте гігієну облікових даних: LAPS, рівні адміністрування і заборона сесій доменних адміністраторів на кінцевих пристроях.
3. Проведіть вправу з відновлення, припускаючи недоступність AD, у чистому мережевому просторі з вимірюваною метою часу.

Вам не треба передбачати наступний NotPetya. Треба зробити ваше середовище нудним для знищення: повільним у поширенні, важким для переходу між обліками
і простим для відновлення з чистих частин. Ось як виглядає стійкість, коли «шкідливе ПЗ» приходить з кувалдою.