WannaCry: програма-вимагач, що нагадала всім про патчування

Що сталося насправді (і чому це спрацювало)

WannaCry вразив у травні 2017 року й зробив те, чого боїться кожен SRE: перетворив внутрішню гігієнічну проблему на видиму клієнту катастрофу з інтернет-швидкістю.
Ядро спалаху не було фішинговим листом із ідеальним соціальним інженерством. Це був експлойт SMB, поєднаний з хробаком.
Якщо хост Windows був вразливим і доступним по TCP/445, його могли уражати, шифрувати і використовувати як стартову точку для атаки на наступний.

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

Ось частина, яку люди недооцінюють: Microsoft випустив патч для вразливості SMB (MS17-010) до спалаху. Індустрія все одно була збита з ніг.
Це не тому, що «патчування складне». Це тому, що багато підприємств побудували процеси, які робили патчування добровільним, повільним або політично небезпечним.
Системи, які не могли перезавантажитися. Додатки «занадто крихкі», щоб їх тестувати. Легасі-версії Windows, про які ніхто не хотів визнавати, що вони ще є. Мережі, які вважали «всередині = довірено».

WannaCry не виграв, бо був геніальним. Він виграв, бо знайшов той самий шов між «ми знаємо, що треба» і «ми зробимо це пізніше».

Короткі факти й історичний контекст (те, що люди забувають)

• MS17-010 (березень 2017) закривав критичні SMB-вразливості, які потім експлуатував WannaCry; патч існував до спалаху.
• EternalBlue — назва експлойта, пов’язана з SMB-вразливістю; він входив до набору інструментів, який потім був оприлюднений.
• WannaCry мав хробакоподібне поширення, автоматично розповсюджуючись через SMB на інші вразливі машини без взаємодії користувача.
• У шкідливому коді був «kill switch» домен, реєстрація якого зменшила поширення; багато інфекцій все одно відбулись у сегментованих або з DNS-блокуванням мережах.
• SMBv1 був великим фактором ризику; вимкнення SMBv1 і загартування SMB зменшили площу атаки і радіус ураження.
• Легасі Windows (особливо старі, непідтримувані релізи на той час) постраждали найбільше; для деяких з них пізніше випустили аварійні патчі.
• Охорона здоров’я та державні служби зазнали помітних збоїв; у цих середовищах часто довгоживучі пристрої й обмежені вікна змін.
• Плата викупу не була головними витратами; простої, робота з відновлення, втрата продуктивності та репутаційні збитки становили більшу частину рахунку.
• Плоскі внутрішні мережі перетворювали локальні інфекції на масштабні відмови через те, що SMB був маршрутизованим і широко дозволеним.

Механіка: EternalBlue, SMB і поведінка хробака

Чому SMB зробив це таким вибуховим

SMB — це протокол, через який Windows обмінюється файлами, принтерами та різними «корпоративними зручностями». Це також дорога до всього, якщо ви дозволяєте TCP/445 без обмежень.
У багатьох середовищах SMB дозволений скрізь, бо файлові шари є скрізь і «так було завжди».
Це припущення — подарунок для атакуючих: одна скомпрометована машина може дістатися до багатьох інших через протокол, який ОС трактує як першокласний.

Поширення WannaCry опиралося на помилку реалізації SMB. Експлойт вдавався, відбувалося виконання коду, після чого шифрувальний модуль запускався, а компонент-хробак продовжував сканувати.
Результат: швидкість. Не терпіння APT. Швидкість.

Kill switch: не магічний щит

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

Мережі з обмеженим DNS, блокуванням вихідного HTTP, sinkhole-поведінкою або частковою зв’язністю все ще могли бачити інфекції.
Крім того, швидко з’являлися варіанти і копії. Сподіватися на kill switch — це не стратегія; це випадковість, яка може не повторитися.

Операційний висновок: патчування необхідне, але недостатнє

Так, патч MS17-010 має значення. Але вам також потрібні: точний інвентар, можливість швидко ізолювати кінцеві точки, контролі на латеральний рух і бекапи, які не можна записати з тих самих машин, що шифруються.
WannaCry покарав слабкі ланки в кожній з цих сфер.

Парафразована ідея від Werner Vogels (CTO Amazon): «Усе ламається, весь час — проектуйте це.»
WannaCry — це те, як виглядає система, коли ви проектуєте так, ніби патчування відбудеться зрештою, а «зрештою» ніколи не настає.

Реальні режими відмов: патчування, інвентаризація і довіра

Режим відмов 1: «Ми патчили… в основному»

У реальності підприємства «паштчено» часто означає: підмножина систем під центральним управлінням, плюс кілька виключень, плюс бекап «спеціальних» серверів, плюс ноутбуки, що пропустили VPN.
Шкідливий код не цікавиться вашими намірами. Йому важлива та єдина непаштчена коробка з відкритим TCP/445.

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

Режим відмов 2: «Ми не відкриваємо SMB в інтернеті»

Добре. Але інтернет — не єдина модель загрози. Внутрішнє поширення саме те, що перетворило WannaCry на генератор відмов.
Плоска мережа з ліберальним east-west трафіком робить кожну кінцеву точку внутрішнім атакуючим після компрометації.

Режим відмов 3: «Бекапи існують»

Багато жертв мали бекапи. Деякі були онлайн і записувані — а значить, їх також зашифрували. Деякі були офлайн, але не тестовані — отже відновлення провалювалось у найгірший момент.
Якщо ви не можете відновити файловий сервер до чистого стану на секундомірі, у вас немає бекапів; у вас є заспокійлива історія.

Режим відмов 4: «Легасі системи неминучі»

Деякі — так. Це не дає дозволу запускати їх голими в корпоративній LAN.
Якщо ви мусите тримати стару ОС або пристрій, обгорніть його: сегментуйте, обмежте трафік, контролюйте адміністративний доступ і моніторьте його як радіоактивний об’єкт. Тому що так воно і є.

Жарт 1: «Наша політика патчування була: якщо не горить, не чіпай. WannaCry приніс вогонь.»

Швидкий план діагностики: що перевірити першим/другим/третім

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

Спочатку: зупиніть кровотечу (контейнмент)

1. Визначте інфіковані хости за симптомами: файли з нотатками викупу, раптова зміна розширень, масове сканування SMB, сповіщення EDR.
2. Ізолюйте підозрілі машини від мережі (відключення порту комутатора, карантин VLAN через NAC, ізоляція через EDR). Не «просто перезавантажуйте і дивіться».
3. Заблокуйте латеральний рух: тимчасово обмежте TCP/445 між підмережами на ядрових фаєрволах. Якщо SMB потрібно залишити, дозвольте його лише від відомих файлових серверів до відомих клієнтів.
4. Підтвердіть статус патчів на решті флоту, особливо на всьому, що доступне по 445.

Другим: визначте експозицію (куди може поширитися далі?)

1. Проскануйте внутрішню мережу на прослуховувачі TCP/445 і зіставте їх з власниками/ролями.
2. Перевірте наявність SMBv1 і його використання; плануйте широке вимкнення.
3. Знайдіть непаштчені системи і пріоритезуйте ті, що мають широкі зв’язки (jump boxes, shared service hosts, VDI брокери, файлові сервери, системи поруч із доменом).

Третім: рішення про відновлення (відновити чи перебудувати)

1. Прийміть рішення: rebuild vs restore: кінцеві точки зазвичай перебудовують; сервери залежать від ролі та зрілості бекапів.
2. Підтвердіть бекапи офлайн і переконайтеся, що цілі для відновлення чисті та запатчені.
3. Гігієна облікових даних: припускайте, що локальні admin-паролі та кешовані доменні креденшіали можуть бути скомпрометовані; ротувати їх за потреби.

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

Ці завдання написані так, ніби ви на хості Linux робите мережевий триаж і опитуєте Windows стандартними інструментами, де це можливо.
В реальних інцидентах ви також використовуватимете EDR/MDM, пересилку Windows-журналів і CMDB. Але команди не брешуть, і вони швидкі.

1) Швидко виявити внутрішню експозицію SMB

cr0x@server:~$ nmap -n -Pn -p 445 --open 10.20.0.0/16 -oG smb-445.gnmap
Starting Nmap 7.94 ( https://nmap.org ) at 2026-01-22 10:17 UTC
Nmap scan report for 10.20.12.34
Host is up (0.0031s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds
Nmap scan report for 10.20.55.10
Host is up (0.0020s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds
Nmap done: 65536 IP addresses (4212 hosts up) scanned in 98.40 seconds

Що це означає: Ці хости приймають SMB-з’єднання. Вони потенційні мішені й потенційні розповсюджувачі.
Рішення: Пріоритезуйте перевірку патчів і правила сегментації для цих IP в першу чергу. Не починайте з машин, що «виглядають ризиковано»; почніть з тих, що досяжні.

2) Перевірити підтримку SMBv1 на цілі (швидкий сигнал)

cr0x@server:~$ smbclient -L //10.20.12.34 -N
protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

Що це означає: Це може вказувати на загартовані налаштування SMB, перешкоду фаєрволом або що переговори SMBv1 заблоковані/вимкнені.
Рішення: Не припускайте, що це «добре». Підтвердіть, перевіривши конфігурацію сервера централізовано. Якщо ви все ще дозволяєте SMBv1 десь ще, продовжуйте шукати.

3) Визначити версії Windows по SMB (коли дозволено)

cr0x@server:~$ crackmapexec smb 10.20.55.10
SMB         10.20.55.10     445    FS-LEGACY01       [*] Windows 7 Professional 7601 Service Pack 1 (name:FS-LEGACY01) (domain:WORKGROUP) (signing:False) (SMBv1:True)

Що це означає: Вимкнута підписка SMB і ввімкнений SMBv1 — множники ризику; ОС стара і вимагає підвищеної уваги.
Рішення: Якщо система критична для бізнесу і не може бути оперативно оновлена, ізолюйте її в жорсткий VLAN і обмежте доступ до SMB лише необхідними шляхами.

4) Виявити активне сканування SMB (поведінка хробака)

cr0x@server:~$ sudo tcpdump -ni eth0 'tcp dst port 445 and (tcp[tcpflags] & (tcp-syn) != 0)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:21:11.102938 IP 10.20.88.44.51532 > 10.20.12.34.445: Flags [S], seq 10293812, win 64240, options [mss 1460,sackOK,TS val 89123 ecr 0,nop,wscale 7], length 0
10:21:11.103114 IP 10.20.88.44.51533 > 10.20.55.10.445: Flags [S], seq 7736123, win 64240, options [mss 1460,sackOK,TS val 89123 ecr 0,nop,wscale 7], length 0
10:21:11.103290 IP 10.20.88.44.51534 > 10.20.101.9.445: Flags [S], seq 5512312, win 64240, options [mss 1460,sackOK,TS val 89123 ecr 0,nop,wscale 7], length 0
10 packets captured

Що це означає: Один хост розсилає SYN на багато SMB-цілей. Це класична поведінка для розповсюдження хробака.
Рішення: Ізолюйте 10.20.88.44 негайно. Потім шукайте інших сканерів; хробаки рідко мандрують поодинці у великій мережі.

5) Зіставити скануючий хост з MAC і портом комутатора (готовність до контейнменту)

cr0x@server:~$ arp -n | grep 10.20.88.44
10.20.88.44 ether 00:25:90:ab:12:ef C eth0

Що це означає: У вас є MAC-адреса підозрілого хоста.
Рішення: Використайте свій комутатор/контролер, щоб закрити порт або перемістити його в карантинний VLAN. Не витрачайте час на листування з десктоп-командою.

6) Перевірити, чи ваші Linux файлові сервери обстрілюють (кількість SMB-з’єднань)

cr0x@server:~$ sudo ss -tn sport = :445 | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port
ESTAB  0      0      10.20.55.200:445   10.20.88.44:51533
ESTAB  0      0      10.20.55.200:445   10.20.88.44:51534
ESTAB  0      0      10.20.55.200:445   10.20.88.44:51535

Що це означає: Один клієнт відкриває багато SMB-з’єднань до вашого сервера. Це може бути легітимно, може бути скануванням, може бути програмою резервного копіювання або шкідливим ПЗ.
Рішення: Корелюйте з tcpdump і Windows-логами. Якщо peer підозрілий — блокуйте його на фаєрволі хоста, поки мережевий контейнмент не наздожене.

7) Підтвердити патч MS17-010 через наявність пакета (перевірка артефактів офлайн)

cr0x@server:~$ strings WS2012R2-C_drive/Windows/Logs/CBS/CBS.log | grep -E 'KB4012213|KB4012216|KB4012598' | tail -n 3
2017-04-02 08:14:09, Info                  CBS    Package: Package_for_KB4012213~31bf3856ad364e35~amd64~~6.3.1.0, state: Installed
2017-04-02 08:14:10, Info                  CBS    Mark store corruption flag because of package: Package_for_KB4012213~31bf3856ad364e35~amd64~~6.3.1.0
2017-04-02 08:14:15, Info                  CBS    Session: 30712533_1972450825 finalized. Reboot required: no

Що це означає: Здається, на хості встановлено відповідний KB (точний KB залежить від ОС).
Рішення: Розглядайте це як допоміжний доказ, а не як остаточне підтвердження. Підтверджуйте стан SMBv1 і загальну вразливість; бувають часткові патчі та відкати.

8) Перевірити стан SMBv1 на Windows-хості через віддалений запит (коли є WinRM)

cr0x@server:~$ evil-winrm -i 10.20.55.10 -u 'ops' -p 'REDACTED' -s . -c "powershell -NoProfile -Command \"Get-SmbServerConfiguration | Select EnableSMB1Protocol,EnableSMB2Protocol\""
EnableSMB1Protocol EnableSMB2Protocol
------------------ ------------------
True               True

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

9) Перевірити, чи дозволений TCP/445 east-west через фаєрвол (швидкий тест реальності)

cr0x@server:~$ sudo traceroute -T -p 445 10.20.12.34
traceroute to 10.20.12.34 (10.20.12.34), 30 hops max, 60 byte packets
 1  10.20.88.1 (10.20.88.1)  0.421 ms  0.388 ms  0.361 ms
 2  10.20.0.1 (10.20.0.1)    0.910 ms  0.899 ms  0.885 ms
 3  10.20.12.34 (10.20.12.34)  1.914 ms  1.902 ms  1.890 ms

Що це означає: Нічого не блокує шлях для TCP/445 між мережами; трафік, ймовірно, вільно проходить.
Рішення: Впровадьте тимчасові ACL на ядрі для обмеження 445. Короткострокова зміна, яка «ламає деякі робочі процеси», дешевша ніж довгостроковий «повний ребілд» після збою.

10) Шукати артефакти нотаток викупу на знімку файлового шару (триаж без торкання кінцевих точок)

cr0x@server:~$ find /srv/samba/shares -maxdepth 4 -type f -iname '@Please_Read_Me@.txt' -o -iname '*WanaDecryptor*' | head
/srv/samba/shares/finance/@Please_Read_Me@.txt
/srv/samba/shares/hr/@Please_Read_Me@.txt

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

11) Перевірити, що бекапи не змонтовані як записувані у продакшні (класична самопідстава)

cr0x@server:~$ mount | grep -E 'backup|repo|vault'
backup01:/repo on /mnt/backup_repo type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.55.200,local_lock=none,addr=10.20.1.50)

Що це означає: Ваш репозиторій бекапів змонтований для запису на продакшн-сервері. Це запрошення зашифрувати вашу безпеку.
Рішення: Перейдіть на модель pull-based або змонтніть тільки для читання там, де можливо. Впровадьте незмінність/WORM для цілей бекапу. Якщо не можете — ізолюйте креденшіали та мережеві шляхи.

12) Перевірити наявність знімків для швидкого відновлення (перше питання інженера зберігання)

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/shares@2026-01-22_0000  Wed Jan 22 00:00 2026
tank/shares@2026-01-22_0100  Wed Jan 22 01:00 2026
tank/shares@2026-01-22_0200  Wed Jan 22 02:00 2026
tank/shares@2026-01-22_0300  Wed Jan 22 03:00 2026
tank/shares@2026-01-22_0400  Wed Jan 22 04:00 2026

Що це означає: У вас часті знімки. Це ваш найкращий друг під час подій з рансомваром, бо це швидко й детально.
Рішення: Визначте останній чистий знімок (до шифрування). Плануйте клон/відкат, який не перезаписує докази і мінімізує простої.

13) Виявити, який клієнт модифікував зашифровані файли (аудит-логи Samba)

cr0x@server:~$ sudo journalctl -u smbd --since "2026-01-22 03:00" | grep -E 'rename|unlink|pwrite' | head -n 6
Jan 22 03:07:12 fileserver smbd[1823]: [2026/01/22 03:07:12.221] rename finance/q1.xlsx -> finance/q1.xlsx.WNCRY
Jan 22 03:07:12 fileserver smbd[1823]: [2026/01/22 03:07:12.223] pwrite finance/q1.xlsx.WNCRY (client 10.20.88.44)
Jan 22 03:07:13 fileserver smbd[1823]: [2026/01/22 03:07:13.004] rename finance/payroll.csv -> finance/payroll.csv.WNCRY
Jan 22 03:07:13 fileserver smbd[1823]: [2026/01/22 03:07:13.009] pwrite finance/payroll.csv.WNCRY (client 10.20.88.44)

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

14) Перевірити, чи DNS не робить щось «корисне», що ламає kill-switch

cr0x@server:~$ dig +short -t a example-killswitch-domain.invalid @10.20.0.53
10.20.0.10

Що це означає: Ваш внутрішній DNS підключає NXDOMAIN до локального IP. Така «допомога» може непередбачувано змінити поведінку шкідливого ПЗ.
Рішення: Вимкніть wildcarding для невідомих доменів у корпоративному DNS. Контролі безпеки мають бути явними, а не залежати від сюрпризів.

Жарт 2: «Нічого так не збирає командну взаємодію, як рансомвар. Раптом всі знають, де сидить команда фаєрвола.»

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

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

Середня компанія використовувала поєднання сучасних Windows-серверів і наполегливо старих робочих станцій для моніторингу промислового контролю.
Усі «знали», що ті робочі станції ізольовані. Адже вони були в виділеному VLAN. Мережна схема це показувала, а в схемі був навіть логотип.

Під час рутинної сесії віддаленої підтримки технік підключив одну з тих робочих станцій до зручної розетки в загальному офісі.
Порт був налаштований на звичайний користувацький VLAN через «hhoteling». Робоча станція отримала нормальний IP, нормальний роутинг, нормальне все. Вона могла бачити файлові шари, принтери й інші робочі станції.
Ніхто не помітив, бо нічого негайно не зламалося.

Коли в середовище прийшло сканування SMB у стилі WannaCry (не обов’язково оригінальний штам 2017 року — варіанти і схожі хробаки існують), та робоча станція була вразливою й досяжною.
Вона стала джерелом спроб латерального інфікування, і в неї також були кешовані креденшіали від попередньої адмін-роботи.
Спалах не зупинила «VLAN», бо VLAN був реальним лише настільки, наскільки порт комутатора був налаштований в той момент.

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

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

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

Інша організація пишалася своїм лаконічним ІТ-підходом. Вони зменшили «марні» вікна технічного обслуговування, розтягнувши цикли патчування.
Замість частих малих батчів вони робили великі квартальні патч-іквенти. Менше перезавантажень, менше тестів додатків, менше сердитих листів.
Дашборд виглядав чистим. Реєстр ризиків — теоретичним.

Вони також оптимізували мережеві операції: широка east-west доступність, мінімальне внутрішнє фаєрволінг, бо внутрішня сегментація «складна» і «важка для діагностики».
Вони казали собі, що endpoint AV зловить усе важливе. Це була приємна історія — поки не стала неприємною.

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

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

Урок: оптимізація під менше змін — це добре, доки світ сам по собі не змінюється. Хробаки дуже люблять зміни.

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

Третя компанія мала репутацію надмірно дисциплінованої. Вони проводили тижневі перевірки відповідності патчам. Не захопливо.
У них було постійне вікно змін. Також не захопливо.
Вони застосовували рівні адміністрації: креденшіали адміністрування робочих станцій не потрапляли на сервери, а серверні креденшіали не використовувалися для контролерів домену без потреби. Дуже не захопливо.

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

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

Інцидент все одно коштував часу й стресу — без казок — але це не стало загальною відмовою компанії.
«Нудні» контроли зробили виживання нормою.

Урок: нудні практики накопичуються. Вони не потрапляють у заголовки. Вони роблять виживання повсякденним.

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

1) «Ми запатчили MS17-010, тож у безпеці»

Симптом: Ви все одно бачите сканування SMB і інфекції на деяких хостах.
Корінна причина: Відповідність патчам була неповною (пропущені ноутбуки, ізольовані підмережі, ручні сервери, дрейф образів), або SMBv1 лишився увімкненим і відкритим.
Виправлення: Вимірюйте відповідність через активну верифікацію (скани та перевірки конфігурацій), а не через «WSUS каже схвалено». Вимкніть SMBv1. Обмежте TCP/445 east-west.

2) «Ми заблокували SMB на периметрі, чому воно поширюється?»

Симптом: Спалах повністю внутрішній і продовжує розширюватися.
Корінна причина: Плоска внутрішня мережа з необмеженим TCP/445; ігнорування внутрішньої моделі загрози.
Виправлення: Сегментація: дозвольте SMB лише між клієнтами і призначеними файловими серверами. Заблокуйте workstation-to-workstation SMB. Використовуйте правила фаєрвола, що відповідають бізнес-потокам, а не субнетам за політикою.

3) «EDR каже: ізольовано, але файлові шари продовжують шифруватися»

Симптом: Попередження кінцевих точок припинились, але файли продовжують змінюватися на зашифровані або з’являються нотатки викупу.
Корінна причина: Інфікований, але не ізольований хост досі має доступ до шару; або другий хост скомпрометовано; або зловживають сервісним акаунтом.
Виправлення: Використайте логи файлового сервера, щоб ідентифікувати IP-клієнтів, що модифікують вміст. Тимчасово зробіть шари лише для читання. Скасуйте токени, вимкнувши акаунти за потреби, потім ротутуйте креденшіали.

4) «Відновлення не працюють»

Симптом: Бекап-завдання є, але відновлення повільне, неповне або пошкоджене.
Корінна причина: Бекапи були онлайн і зашифровані; бекапи ніколи не тестувалися; сервер бекапів використовував доменні адмін-креденшіали, доступні кінцевим точкам.
Виправлення: Впровадьте незмінні бекапи і розділені креденшіали. Регулярно робіть тести відновлення. Тримайте репозиторії бекапів за межами тих самих меж довіри, що й кінцеві точки.

5) «Ми не можемо вимкнути SMBv1, бо щось може зламатися»

Симптом: Нескінченні винятки і затримки; SMBv1 залишається ввімкненим за замовчуванням.
Корінна причина: Невідомі залежності і відсутність власника для легасі-додатків/пристроїв.
Виправлення: Інвентаризуйте використання SMBv1, назвіть власників і встановіть дедлайни. Якщо пристрій вимагає SMBv1 — ізолюйте його і заплануйте заміну з датою.

6) «Ми не можемо перезавантажити сервери для патчів»

Симптом: Критичні системи накопичують місяці відсутніх оновлень.
Корінна причина: Крихкі сервіси без HA, відсутність вікна обслуговування або страх змін через попередні відмови.
Виправлення: Побудуйте HA або перебудуйте архітектуру, щоб перезавантаження були рутинними. Якщо ви не можете перезавантажити Windows-сервер — це не «критично», це «є одиничною точкою відмови, яку ви відмовляєтесь визнавати».

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

1) Чекліст аварійного реагування (перші 4 години)

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

2) Чекліст загартування (наступні 7 днів)

1. Вимкніть SMBv1 масово; відслідковуйте й ізолюйте винятки.
2. Запровадьте підписування SMB де можливо, особливо на серверах.
3. Сегментуйте мережі: блокуйте workstation-to-workstation SMB; дозвольте лише необхідний client-to-server SMB.
4. Відповідність патчам: визначте SLA (наприклад, критичні — у межах днів) і впровадьте звітність + автоматизацію.
5. Принцип найменших привілеїв для адміністраторів: рівневе адміністрування; заборона доменного admin на кінцевих точках.
6. Загартування бекапів: незмінні копії, офсайтні копії і тести відновлення.
7. Логування: централізувати Windows-логи і аудіт-логи файлових серверів для швидкої атрибуції клієнта.

3) Інженерний чекліст (наступні 30–90 днів)

1. Перебудуйте конвеєр патчування як продукт: фазові кільця, canary, відкат, метрики.
2. Точність інвентарю активів: зіставте DHCP, AD, EDR і мережеві скани; невідомі пристрої стають інцидентами.
3. Проектуйте під перезавантаження: HA там, де потрібно; реальні вікна обслуговування; ліквідуйте фольклор «не перезавантажувати».
4. Сервісні акаунти: регулярно ротувати; обмежити права логону; моніторити аномальну SMB-активність і масові зміни файлів.
5. Тренування на столі та вправи: проводьте дрилі щодо wormable-ransomware, а не слайд-дек. Перевіряйте ізоляцію й час відновлення.

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

1) Чи був WannaCry здебільшого фішинг-атакою?

Визначальною особливістю було хробакоподібне поширення через SMB із використанням вразливостей класу MS17-010. Для поширення між вразливими хостами взаємодія користувача не була потрібна.

2) Якщо ми сьогодні запатчили MS17-010, чи все вирішено?

Ні. Запатчіть, а потім обмежте експозицію SMB, вимкніть SMBv1 і загартуйте бекапи. Випадки wormable спалахів живуть за рахунок досяжності і слабкої внутрішньої сегментації, а не лише відсутності KB.

3) Чому SMBv1 досі з’являється в підприємствах?

Тому що старі пристрої й додатки залишаються, і люди бояться їх зламати. Правильний крок — жорстко ізолювати залежності від SMBv1 і замінити їх у визначений строк.

4) Чи варто платити викуп?

З операційної точки зору платіж не гарантує відновлення і може створити додаткові проблеми (включно з повторним таргетингом). Найкраща інвестиція — можливість відновлення: знімки, незмінні бекапи і відпрацьоване відновлення.

5) Який найшвидший крок для контейнменту під час події на кшталт WannaCry?

Заблокуйте TCP/445 east-west (особливо workstation-to-workstation) і ізолюйте скануючі хости. Ви відрубаєте ноги хробаку.

6) Як швидко знайти «ту одну непаштчену коробку»?

Почніть з мережевої реальності: скануйте на прослуховувачі TCP/445, а потім верифікуйте стан патчів/конфігурації для цих хостів. CMDB корисна, але потік пакетів — це реальність.

7) Чи можуть бекапи бути зашифровані також?

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

8) Чи вимкнення SMB зламає файловий обмін Windows?

Повне вимкнення SMB зламає його, але зазвичай ви вимикаєте SMBv1 (старий, ризиковий) і зберігаєте SMBv2/v3. Ви також обмежуєте, де дозволений SMB, замість того, щоб давати йому вільно ходити мережею.

9) Чому «вікна патчування» зазнають невдач у практиці?

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

Наступні кроки, які можна зробити цього тижня

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

1. Запустіть внутрішній скан TCP/445 і передайте список тим, хто дійсно може змінити політику фаєрвола.
2. Визначте дату для вимкнення SMBv1 по всьому підприємству. Почніть з пілотного кільця, потім рухайтеся швидко. Винятки потрапляють у ізольовані VLAN з підписом власника.
3. Вимірюйте відповідність патчам ззовні (мережеві скани + перевірки конфігурацій), а не лише з точки зору інструменту патчування.
4. Зміцніть бекапи, як серйозно: незмінна копія, офсайтна копія і відпрацювання відновлення, що показує реальний час відновлення, а не слайди.
5. Реалізуйте «контейнмент-ключ»: аварійний набір правил фаєрвола для обмеження SMB east-west, який можна увімкнути за хвилини, а не години.

Зробіть це — і наступна хвиля wormable-рансомварів все ще буде дратівливою. Просто вона вже не буде екзистенційною. Це потрібний бар’єр. Пройдіть його.