Міф про «найкращий антивірус»: що насправді запобігає програмам-вимагачам

Міф: «найкращий антивірус» як стратегія безпеки

Антивірус (AV) і навіть сучасні інструменти для кінцевих точок не є марними. Вони просто не є основним контролем проти програм-вимагачів. Ставити їх як «те, що зупиняє ransomware» — це як вважати ремені безпеки планом уникнення автокатастроф. Добре мати, але не там, де попереджають аварії.

Оператори програм-вимагачів більше не роблять ставку на масове шкідливе ПЗ. Вони працюють за сценаріями. Купують доступ. Зловживають ідентичностями. Живуть «off the land». Використовують підписані інструменти, віддалене управління, легітимні адмін-утиліти й вкрадені облікові дані. Вони не поспішають. Вони відключають те, що ви купили для захисту, або обходять його.

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

Холодна реальність: якщо супротивник став domain admin і може дістатися до вашої системи резервного копіювання, ваш «рейтинг найкращого AV» уже не має великого значення.

Цитата, яку варто приколоти на стіну: «Надія — не стратегія.» — Vince Lombardi

Жарт №1 (короткий, по темі): Антивірус — як дезодорант: допомагає, але не замінює купання.

Факти та історія: як ми сюди потрапили (і чому це важливо)

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

• 1989: Троян AIDS часто згадується як ранній попередник програм-вимагачів — розповсюджувався на дискетах, використовував примітивне шифрування та оплату поштою. Модель працювала навіть коли криптографія не була надійною.
• Середина 2000-х: «Scareware» і фейкові AV монетизували страх. Це навчило злочинців, що поведінка користувачів і механізми оплати важливіші за технічну досконалість.
• 2013–2016: CryptoLocker та нащадки індустріалізували сильне шифрування у масштабі. Почався період «шифруй усе якнайшвидше».
• 2017: WannaCry та NotPetya поширювалися через уразливості, що чергуються, і слабку гігієну патчів. NotPetya був руйнівним під виглядом ransomware — страхування і плани реагування мусили адаптуватися.
• 2019–2021: «Big game hunting» змістив фокус на підприємства: ручні вторгнення, підвищення привілеїв і цілеспрямований вплив. Шифрування стало лише фінальним актом.
• Double extortion: Зловмисники почали перед шифруванням красти дані, перетворивши «відновлення з резервної копії» лише напівзаходом.
• Ransomware-as-a-service: Афілійований доступ демократизував вторгнення. Навички розподілені; обсяг зростає; тактики стандартизуються.
• Війни EDR: Оператори навмисно тестують і налаштовують payload під популярні EDR-стекі. Кінцева точка стає полем змагання, а не безпечною зоною.
• Хмарний поворот: Зловживання ідентичністю та API може знищити об’єктне сховище або зашифрувати дані SaaS. Ваш «endpoint AV» не має значення для вкраденого OAuth-токена.

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

Що насправді робить програма-вимагач у вашому середовищі

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

Фаза 1: Початковий доступ

Поширені точки входу: скомпрометовані VPN-облікові дані без MFA, відкритий RDP, фішинг, що захоплює токени, непатчені периферійні пристрої або інструменти віддаленого доступу третіх сторін. Нападник хоче опору, що виглядає як звична віддалена робота.

Фаза 2: Крадіжка облікових даних і підвищення привілеїв

Дампінг облікових даних, викрадення токенів, зловживання Kerberos, password spraying, повторне використання локальних адмін-акаунтів. Якщо ваші адміністратори заходять на робочі станції з доменним обліковим записом адміністратора, завдання нападника значно спрощується.

Фаза 3: Виявлення та латеральний рух

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

Фаза 4: Крадіжка даних (опціонально, все частіше)

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

Фаза 5: Наслідок

Шифрування кінцевих точок і серверів, видалення shadow copies/snapshots, відключення сервісів, масові зміни GPO і — якщо не пощастить — знищення резервних копій. Це момент «все горить», але почалося це за години або дні до того.

Контрзаходи, які реально запобігають програмам-вимагачам (і чому)

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

1) Закріплення ідентичностей важливіше за героїчні дії на кінцевих точках

Якщо ви не можете захистити ідентичності, ви нічого не захистите. Оператори програм-вимагачів люблять середовища, де облікові дані довготривалі, надмірно привілейовані й використовуються повторно.

• MFA всюди (VPN, пошта, адмін-панелі, хмарні консолі). Для адміністративних ролей обирайте MFA, стійкий до фішингу.
• Окремі облікові записи для адмінів (щоденна робота vs привілейована). Жоден domain admin не повинен переглядати веб.
• Привілейовані робочі станції (PAW) або захищені jump hosts для адміністративних дій.
• Модель рівнів (Domain Controllers — Tier 0; тримайте Tier 0 облікові дані поза нижчими рівнями).
• Зменшення постійних привілеїв за допомогою механізмів just-in-time, де можливо.

2) Резервні копії: єдина «лікувальна» опція, але тільки якщо їх не можна видалити

Резервні копії — це не галочка. Це система з опонентами. Якщо нападник може використати ваші адміністративні інструменти, щоб видалити резервні копії, у вас їх немає. У вас є дорога хибна надія.

Що означає «добре»:

• 3-2-1: три копії, два типи носіїв, одна — офсайт/ізольована. Дотепер надійна база.
• Immutability: snapshots/object lock або політики WORM, які звичайні адміністратори не можуть швидко відмінити.
• Offline/air-gapped копія (логічна або фізична). Не все має бути офлайн, але щось має.
• Тестування відновлення: заплановане, вимірюване і нудне. Мета — не успішне створення резервної копії, а успішне відновлення.
• Інженерні RPO/RTO: скільки ви готові втратити (RPO) і як швидко повернутися в роботу (RTO). Якщо ви ніколи не відпрацьовували відновлення — ваш RTO мрія, а не факт.

3) Сегментація мережі: зробіть латеральний рух дорогим

Плоскі мережі прискорюють ransomware. Сегментація — це те, як ви перетворюєте «один скомпрометований ноутбук» на «один скомпрометований ноутбук», а не «вся компанія».

• Ізолюйте резервні копії від загальної серверної мережі. Обмежте порти управління до jump hosts.
• Відокремте підмережі користувачів від серверних; розділіть серверні підмережі за функцією.
• Обмежте east-west трафік. Зробіть доступ до SMB і WinRM надто складним для зловмисника.
• Контролюйте egress. Більшість середовищ моніторить inbound; нападники люблять outbound.

4) Логування і моніторинг, які переживуть атаку

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

• Централізуйте логи в системі з жорстким доступом.
• Налаштуйте оповіщення по подіях ідентичності: нові адмін-акаунти, нові service principals, зміни членства в групах.
• Оповіщуйте про маніпуляції з резервами: видалення завдань бекапу, зміни політик зберігання, видалення знімків.
• Оповіщуйте про масові перейменування/записи файлів і високі SMB write rates.

5) Управління патчами: не ідеально, але необхідно

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

6) EDR і AV: корисні, але не шеф-плану

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

7) Інженерія сховищ: знімки, незмінність і контроль зони ураження

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

Контрзаходи для сховищ, що мають значення:

• Незмінні знімки (де підтримується) або політики знімків, захищені від рутинних адмін-облікових даних.
• Відокремлене сховище резервів від первинного. Інші облікові дані, інша мережа, інша зона відмови.
• Моніторинг кількості видалень і хвиль перейменувань у файлових системах.
• Знайте ваші шляхи відновлення: відновлення на рівні VM, на рівні файлу, bare metal. Вимірюйте час.

Практичні завдання: 12+ конкретних перевірок з командами й рішеннями

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

Завдання 1: Перевірка підозрілої активності SMB-шерів (Linux Samba server)

cr0x@server:~$ sudo smbstatus -b
Samba version 4.15.13-Ubuntu
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
-----------------------------------------------------------------------------------------------------------------------------
2314    jdoe         domain users  10.20.5.44 (ipv4:10.20.5.44:49832)       SMB3_11           -                    partial
2488    svc_backup   domain users  10.20.9.12 (ipv4:10.20.9.12:52110)       SMB3_11           -                    partial

Service      pid     Machine       Connected at                     Encryption   Signing
------------------------------------------------------------------------------------------
finance      2314    10.20.5.44    Tue Feb  5 10:12:44 2026 UTC     -            partial
profiles     2488    10.20.9.12    Tue Feb  5 09:55:03 2026 UTC     -            partial

Що це означає: Активні SMB-сеанси і які шари вони торкаються. Один робочий станцій, який інтенсивно звертається до чутливого шару поза робочими годинами, — підозріло.

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

Завдання 2: Виявлення хвилі перейменувань/записів на файловій системі (Linux)

cr0x@server:~$ sudo iostat -xz 1 3
Linux 6.5.0-15-generic (fs01)  02/05/2026  _x86_64_ (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.12    0.00    6.44   31.88    0.00   52.56

Device            r/s     rkB/s   rrqm/s  %rrqm   r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm   w_await wareq-sz  aqu-sz  %util
nvme0n1          4.12    211.4     0.00   0.00    2.41    51.30   812.3  18244.0   120.1  12.88   38.22    22.45   31.2   99.1

Що це означає: Висока кількість операцій запису, велике iowait, високе завантаження. Ransomware часто проявляється як тривале навантаження на запис з великою кількістю малих записів.

Рішення: Якщо це ненормально для цього хоста — вважайте це інцидентом. Корелюйте з процесним IO і нещодавніми подіями автентифікації.

Завдання 3: Визначити процеси з найбільшим IO (Linux)

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ:         0.00 B/s | Total DISK WRITE:      65.12 M/s
TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
8123 be/4  root        0.00 B/s   18.22 M/s  0.00 % 98.00 %  python3 /opt/agent/tmp/enc.py
3911 be/4  nobody      0.00 B/s   12.05 M/s  0.00 % 87.00 %  smbd: notifyd

Що це означає: Один процес робить великі постійні записи — це тривожний сигнал, особливо якщо шлях дивний, наприклад /opt/agent/tmp.

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

Завдання 4: Перевірити нещодавно змінені виконувані файли в підозрілих директоріях (Linux)

cr0x@server:~$ sudo find /tmp /var/tmp /dev/shm -type f -mtime -1 -maxdepth 2 -ls | head
131099  120 -rwxr-xr-x   1 root root   122880 Feb  5 09:58 /tmp/.cache/agent
131104   44 -rwxr-xr-x   1 root root    45056 Feb  5 10:01 /dev/shm/.x

Що це означає: Свіжі виконувані файли в тимчасових локаціях часто з’являються в ланцюжках вторгнення.

Рішення: Якщо бачите нові виконувані артефакти — карантинуйте систему і обчисліть їхні хеші/зіберіть для аналізу.

Завдання 5: Перевірити контролі незмінності для репозиторію резервних копій (приклад: ZFS snapshots)

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation tank/backups | tail -5
tank/backups@auto-2026-02-05_0100  Tue Feb  5 01:00 2026
tank/backups@auto-2026-02-05_0200  Tue Feb  5 02:00 2026
tank/backups@auto-2026-02-05_0300  Tue Feb  5 03:00 2026
tank/backups@auto-2026-02-05_0400  Tue Feb  5 04:00 2026
tank/backups@auto-2026-02-05_0500  Tue Feb  5 05:00 2026

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

Рішення: Підтвердіть, хто може знищувати ці знімки. Якщо «domain admins можуть SSH і виконати zfs destroy», у вас немає незмінності; у вас є список завдань.

Завдання 6: Перевірити, чи захищені знімки делегуванням (приклад ZFS)

cr0x@server:~$ sudo zfs allow tank/backups
---- Permissions on tank/backups --------------------------------------------
Local+Descendent permissions:
user backupsvc create,mount,receive,rollback,snapshot
user root create,destroy,mount,receive,rename,rollback,snapshot

Що це означає: Лише root може знищувати знімки/дата-сети; сервісний акаунт backupsvc може створювати/отримувати/знімати, але не знищувати.

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

Завдання 7: Підтвердити, що ви можете відновити (не лише бекапити) файл швидко (приклад ZFS clone)

cr0x@server:~$ sudo zfs clone tank/backups@auto-2026-02-05_0500 tank/restore-test
cr0x@server:~$ ls -lah /tank/restore-test/finance/ | head
total 64K
drwxr-xr-x  2 root root 4.0K Feb  5 05:00 .
drwxr-xr-x  8 root root 4.0K Feb  5 05:00 ..
-rw-r--r--  1 root root  18K Feb  5 04:59 invoice-2026-02.csv

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

Рішення: Виміряйте час цієї операції й занотуйте. Якщо це займає надто довго — ваші припущення про RTO хибні.

Завдання 8: Перевірити масові зміни файлів за допомогою аудиту (приклад Linux auditd)

cr0x@server:~$ sudo ausearch -ts today -k finance-share | tail -5
time->Tue Feb  5 10:03:41 2026
type=SYSCALL msg=audit(1738759421.211:1293): arch=c000003e syscall=82 success=yes exit=0 a0=ffffff9c a1=7f2a2c001b40 a2=241 a3=1b6 items=2 ppid=8123 pid=8123 auid=1002 uid=0 gid=0 exe="/usr/bin/python3" comm="python3"
type=PATH msg=audit(1738759421.211:1293): item=1 name="/srv/samba/finance/Q1/budget.xlsx.locked" inode=901232 dev=fd:00 mode=0100644 ouid=1002 ogid=1002 rdev=00:00 nametype=CREATE

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

Рішення: Миттєво ізолюйте: відділіть хост/користувача, деактивуйте облікові дані, заблокуйте SMB з того джерела, збережіть знімок.

Завдання 9: Перевірка вихідних з’єднань на великі несподівані передачі (Linux)

cr0x@server:~$ sudo ss -tpn | head -8
State Recv-Q Send-Q Local Address:Port  Peer Address:Port  Process
ESTAB 0      131072 10.20.9.22:443      185.199.110.153:52344 users:(("rclone",pid=9011,fd=7))
ESTAB 0      0      10.20.9.22:22       10.20.1.10:49822   users:(("sshd",pid=1881,fd=3))

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

Рішення: Якщо ви не запускаєте rclone у продакшні — вважайте це інцидентом. Завершіть процес, зафіксуйте командний рядок/історію та перевірте логи egress, що саме було відправлено.

Завдання 10: Перевірити здоров’я реплікації контролерів домену (Windows з управління з хоста через WinRM — поширений сценарій; тут Linux-перевірка через samba-tool)

cr0x@server:~$ samba-tool drs showrepl dc01.corp.example
DSA Options: 0x00000001
DSA object GUID: 2b6b0f4b-3a2b-4d2a-a9f2a-3b5a9c9aa2ad
==== INBOUND NEIGHBORS ====
DC=corp,DC=example
    dc02.corp.example via RPC
        DSA object GUID: 9d7b1c2a-1c11-4a72-ae9e-2d0b2a6a0c17
        Last attempt @ Tue Feb  5 09:55:12 2026 UTC was successful

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

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

Завдання 11: Перевірити додавання нових локальних адміністраторів (приклад Linux через sudoers і файли груп)

cr0x@server:~$ sudo grep -R "ALL=(ALL)" -n /etc/sudoers /etc/sudoers.d | head
/etc/sudoers:27:%sudo   ALL=(ALL:ALL) ALL
/etc/sudoers.d/90-cloud-init-users:1:deploy ALL=(ALL) NOPASSWD:ALL

Що це означає: Passwordless sudo для загального акаунта — подарунок для нападників, які опинилися на цьому хості.

Рішення: Видаліть NOPASSWD там, де це не критично, і обмежте дозволені команди. Якщо це необхідно, перенесіть доступ за сильну автентифікацію та логування на jump host.

Завдання 12: Підтвердити, що резерви завершуються й не падають мовчки (універсально: перевірка systemd timers + логів)

cr0x@server:~$ systemctl list-timers --all | grep -E "backup|restic|borg"
Tue 2026-02-05 01:00:00 UTC  4h 59min left Tue 2026-02-04 01:00:03 UTC 19h ago  restic-backup.timer  restic-backup.service
cr0x@server:~$ sudo journalctl -u restic-backup.service -n 8 --no-pager
Feb 04 01:00:03 backup01 restic[2201]: repository 1a2b3c4d opened successfully
Feb 04 01:12:44 backup01 restic[2201]: processed 412563 files, 1.8 TiB in 12m41s
Feb 04 01:12:44 backup01 restic[2201]: snapshot 9f8e7d6c saved
Feb 04 01:12:44 backup01 systemd[1]: restic-backup.service: Succeeded.

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

Рішення: Якщо резерви падають — виправте це перш ніж робити щось «просунуте». Якщо вони повільні — плануйте підвищення відновлювальної потужності.

Завдання 13: Перевірити цілісність відновлення за контрольними сумами (приклад)

cr0x@server:~$ sha256sum /srv/data/finance/invoice-2026-02.csv
c8b1d7a2b2a5ef3fdddbf0d66a52f3f3d8b2d1e2f30d7c2f2e0b7b2b3a1f0a9e  /srv/data/finance/invoice-2026-02.csv
cr0x@server:~$ sha256sum /tank/restore-test/finance/invoice-2026-02.csv
c8b1d7a2b2a5ef3fdddbf0d66a52f3f3d8b2d1e2f30d7c2f2e0b7b2b3a1f0a9e  /tank/restore-test/finance/invoice-2026-02.csv

Що це означає: Ваша відновлена копія співпадає з продакшн. Це доводить, що резервні копії не лише присутні, а й коректні.

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

Завдання 14: Швидко знайти процеси з підозрілою персистенцією (Linux)

cr0x@server:~$ systemctl list-unit-files --type=service | grep -E "agent|update|backup" | head
agent-updater.service                      enabled
backup-sync.service                        enabled
system-update.service                      enabled
cr0x@server:~$ systemctl status agent-updater.service --no-pager | sed -n '1,12p'
● agent-updater.service - Agent Updater
     Loaded: loaded (/etc/systemd/system/agent-updater.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-02-05 09:58:11 UTC; 7min ago
   Main PID: 8123 (python3)
     CGroup: /system.slice/agent-updater.service
             └─8123 /usr/bin/python3 /opt/agent/tmp/enc.py

Що це означає: Персистенція через systemd — поширена. Сервіс, що запускає скрипт з тимчасового шляху, — надзвичайно підозріло.

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

План швидкої діагностики

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

По-перше: підтвердити обсяг і зупинити кровотечу

1. Визначте пацієнта нуль: який хост/користувач першим повідомив про зашифровані файли? Корелюйте часові мітки з логами автентифікації.
2. Ізолюйте ймовірні джерела: карантинуйте кінцеві точки на мережевому рівні, якщо можливо; не покладайтеся на співпрацю кінцевої точки.
3. Заморозьте резерви/знімки: негайно збережіть точки відновлення. Якщо у вас є незмінні знімки, перевірте, чи вони ще існують і доступні.

По-друге: з’ясуйте, чи скомпрометована ідентичність

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

По-третє: визначте, чи це шифрування, ексфільтрація чи обидва

1. Телеметрія сховища: стрибки iowait, SMB write bursts, підвищені операції з метаданими. Шифрування голосно говорить на рівні сховища.
2. Телеметрія egress: незвичні вихідні з’єднання, інструменти на кшталт rclone, великі передачі на невідомі IP.
3. Індикатори файлів: нові розширення, примітки з вимогою викупу, послідовні схеми перейменування.

По-четверте: оберіть шлях відновлення

• Якщо резерви цілі: пріоритет — контейнмент і планування відновлення. Не поспішайте відновлювати в домен, що ще скомпрометований.
• Якщо резерви під загрозою: заблокуйте їх негайно (зміна облікових даних, мережева ізоляція, відкликання доступу). Час важливіший за елегантність.
• Якщо ексфільтрація підтверджена: залучіть юристів/комплаєнс раніше; відновлення не скасовує зобов’язань щодо розкриття.

Три короткі корпоративні історії з поля бою

Міні-історія 1: Інцидент через неправильне припущення

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

Неправильне припущення було простим: «Якщо у нас EDR, ransomware не може поширюватись». Насправді EDR був розгорнутий на більшості кінцевих точок, з виключеннями для продуктивності на наборі файлових серверів, які «не могли дозволити собі навантаження». Саме там співробітники зберігали все важливе. Сервери також дозволяли старі SMB-настройки для застарілого додатку, який ніхто не хотів чіпати.

Нападник зайшов через VPN-акаунт підрядника без MFA. Акаунт був «тимчасовим» вже шість місяців. Вони пересунулися латерально, знайшли незахищені файлові сервери й запустили шифрування прямо на них. Немає агента — немає ізоляції. Коли служба підтримки побачила перший тикет, сховище вже було насичено записами й шар перетворився на кладовище перейменованих файлів.

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

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

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

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

Зміна виглядала ефективною. Менше знімків. Менше місця. Менше тертя. Метрики покращилися. Ризик не з’явився на дашборді, бо ризик рідко показується на графіках.

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

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

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

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

Ця історія не кінематографічна. Ось чому вона спрацювала.

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

Вони також підтримували окремий адмін-акаунт для бекапу, збережений офлайн з MFA. Резервне сховище жило в іншій мережевій сегментації. Видалення знімків вимагало окремого шляху затвердження й облікових даних, що не були домен-адмінськими.

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

У них все одно були важкі дні, бо інциденти так і виглядають. Але вони пережили не катастрофічний квартал. Нудна практика — постійне доведення відновлюваності — перетворила паніку на послідовність кроків.

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

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

1) «Наші резерви були в порядку» (поки не сталося навпаки)

• Симптоми: Завдання резервного копіювання показують «успішно», але відновлення не вдаються або займають дні; відсутня консистентність додатків; архіви пошкоджені; ніхто не знає ключів/паролів.
• Корінна причина: Успіх бекапу вимірюють завершенням завдання, а не валідацією відновлення; немає відпрацювань; облікові дані зберігаються на скомпрометованих системах.
• Виправлення: Заплануйте відновлення з вимірюваним RTO; зберігайте адмін-креденшали резервів офлайн; впровадьте незмінність; документуйте порядок відновлення за залежностями.

2) Шифрування «поширюється миттєво» по організації

• Симптоми: Багато шарів і серверів уражені за хвилини; латентність сховища стрибає; SMB write rates йдуть вертикально вгору.
• Корінна причина: Плоска мережа + широкі дозволи на шари + повторне використання адмін-облікових записів + відсутність east-west контролів.
• Виправлення: Сегментуйте; обмежте SMB/WinRM; приберіть повторне використання локальних адміністраторів; впровадьте модель рівнів адміністрування; обмежте права на запис у шарах.

3) Команда безпеки нічого не бачить під час інциденту

• Симптоми: SIEM мовчить; агенти офлайн; сервери логів зашифровані; немає хронології подій.
• Корінна причина: Моніторинг залежить від тієї ж плоскості ідентичності/сховища, що й скомпрометовані; немає захищеного каналу логування.
• Виправлення: Централізуйте логи на захищеній інфраструктурі; відокреміть автентифікацію; використовуйте write-once або обмежені політики зберігання; тестуйте логування під час відключення.

4) Відновлення повторно інфікує середовище

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

5) «У нас був MFA», але нападники все одно зайшли

• Симптоми: Компроміс через SSO; підозрілі OAuth-додатки; сесійні токени зловживані; обман служби підтримки.
• Корінна причина: MFA не застосовано всюди; методи схильні до фішингу; крадіжка токенів; слабкі процедури в службі підтримки.
• Виправлення: Впровадьте MFA всюди; для адміністраторів використовуйте стійкий до фішингу MFA; оповіщайте про нові дозволи додатків; зміцніть процедури служби підтримки.

6) Резерви є, але їх все одно видаляють

• Симптоми: Знімки відсутні; змінено політики зберігання; завдання бекапу видалені; бакети об’єктного сховища порожні.
• Корінна причина: Адміністратори резервів ділять ту ж плоскость ідентичності з нападниками; немає незмінності; відсутній розподіл обов’язків; немає оповіщень про руйнівні дії.
• Виправлення: Впровадьте незмінне зберігання; відокремте облікові дані; вимагайте break-glass акаунтів для видалень; оповіщайте про зміни політик зберігання та видалення негайно.

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

Контрольний пункт 0: Визначте, що означає «добре» для вашого бізнесу

• Визначте RPO для кожної системи (скільки даних ви можете втратити).
• Визначте RTO для кожної системи (скільки часу ви можете бути недоступними).
• Класифікуйте дані: регульовані, конфіденційні, внутрішні, публічні.
• Визначте топ-5 сервісів, які повинні повернутися першими (ідентичність, DNS, основні додатки, файлові шари, ERP тощо).

Тиждень 1: Заберіть легкі перемоги від нападників

1. Впровадьте MFA на VPN, пошті та для привілейованого доступу.
2. Інвентаризуйте привілейовані облікові записи і розділіть адмінські та повсякденні акаунти.
3. Приберіть очевидні «бомби привілеїв»: NOPASSWD sudo, спільні адмін-облікові дані, застарілі акаунти підрядників.
4. Визначте еталон egress: знайте, який вихідний трафік «нормальний» від серверів.

Тиждень 2: Зробіть резерви стійкими до компрометації адміністраторів

1. Впровадьте незмінність хоча б для однієї копії резерву (знімки/object lock/WORM-подібне зберігання).
2. Сегментуйте мережі резервів: обмежте доступ до інфраструктури резервів тільки через jump host.
3. Розділіть облікові дані: акаунти адміністраторів резервів не повинні бути domain admin; зберігайте break-glass облікові дані офлайн.
4. Налаштуйте оповіщення про руйнівні дії: видалення знімків, зміни політик зберігання, видалення завдань бекапу.

Тиждень 3: Зменшіть зону ураження сегментацією і правами

1. Сегментуйте доступ від користувача до серверів: лише потрібні порти, лише потрібні підмережі.
2. Посилюйте дозволи на шари: приберіть «Everyone write»; впровадьте найменші привілеї по групах.
3. Блокуйте протоколи латерального руху, де можливо: SMB між робочими станціями, WinRM, WMI між підмережами.
4. Зміцніть адмінські робочі процеси: PAW або jump host, ніякого прямого адміністрування з робочих станцій.

Тиждень 4: Доведіть, що можете відновитися

1. Проведіть тест відновлення в ізольованій мережі; перевірте функціонування додатку, а не лише запуск системи.
2. Заміряйте час і порівняйте з RTO; оновіть плани або придбайте ресурси.
3. Опишіть runbooks для порядку відновлення і контрольних точок прийняття рішень.
4. Відпрацюйте першу годину: контейнмент, ротація облікових даних, збереження знімків, план комунікацій.

Жарт №2 (короткий, по темі): Якщо ваш план аварійного відновлення — PDF, який ніхто не може знайти, вітаю — ви винайшли сховище документації, сумісне з ransomware.

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

Чи має антивірус взагалі значення?

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

Який один найважливіший контроль проти програм-вимагачів?

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

Чи достатньо незмінних резервних копій?

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

Як часто тестувати відновлення?

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

Що слід моніторити для раннього виявлення ransomware?

Зміни ідентичності (нові адміністратори, нові токени, зміни MFA), незвичні SMB write-патерни, сплески перейменувань файлів, зміни зберігання/завдань бекапу, а також аномальні зовнішні передачі.

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

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

Ми в основному SaaS. Чи ми в безпеці?

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

У чому різниця між EDR і AV у цьому контексті?

AV зазвичай — це підхід, заснований на сигнатурах/поведінці для запобігання на кінцевих точках. EDR додає телеметрію, полювання і дії реагування (наприклад, ізоляцію хоста). Обидва допомагають, але ні один не замінює стійкість резервів і контролі ідентичності.

Як уникнути відновлення шкідливого ПЗ разом із даними?

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

Чи рахуються знімки на первинному сховищі як резервні копії?

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

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

Якщо ви хочете запобігти ransomware — припиніть шопінг «найкращого антивірусу» і почніть запуск програми надійності для безпекових результатів.

1. Виберіть один критичний сервіс і виміряйте час відновлення кінця-до-кінця. Зафіксуйте число письмово.
2. Захистіть одну копію резерву незмінністю і доведіть, що рутинні адміністратори не можуть її швидко видалити.
3. Впровадьте MFA для всього віддаленого доступу, потім проведіть аудит винятків, поки не залишиться жодного виправданого.
4. Сегментуйте мережі резервів і управління, щоб скомпрометована робоча станція навіть не бачила їх.
5. Налаштуйте три оповіщення, на які ви реально реагуватимете: зміни привілейованих груп, зміни зберігання резервів і аномальні вихідні передачі.
6. Напишіть односторінковий runbook першої години і програйте його раз. Мета — прибрати дебати, а не вразити когось.

Ransomware — це системна проблема. Ставтеся до неї як до production-інженерії: зменште зону ураження, впровадьте найменші привілеї, проектуйте під відновлення і репетируйте. Антивірус може їхати на цьому ж «рейсі».