На аудите энергетического предприятия мы получили domain admin за четыре часа - Kerberoasting плюс слабый пароль сервисной учётки AD. Стандартная история, ничего интересного. Но между корпоративной сетью и сегментом SCADA стоял файрвол, пропускавший только Modbus TCP на порт 502 и HTTPS на 443 для data historian. Pass-the-Hash бесполезен, RDP заблокирован, SSH отсутствует. Весь классический набор lateral movement техник, которые отлично работают внутри IT-домена, на границе с OT-сегментом превратились в мёртвый груз.
И вот тут начинается настоящий пентест промышленных сетей - на стыке корпоративного домена и промышленных контроллеров, где правила совершенно другие.
Бизнес-логика атаки: зачем атакующему переходить в OT
Атакующий, получивший контроль над IT-доменом, уходит в OT-сегмент не из любопытства. Причины конкретные: шифрование SCADA-серверов для максимального давления при ransomware (остановка производства - сотни тысяч долларов в час), саботаж физических процессов (кейс TRITON/TRISIS 2017: группа XENOTIME атаковала системы противоаварийной защиты Schneider Electric Triconex на нефтехимическом заводе), или создание долгосрочного плацдарма в критической инфраструктуре (группа Volt Typhoon, по данным CISA, сидела в инфраструктуре месяцами без единого активного действия).По данным IBM X-Force Threat Intelligence Index 2025, 70% атак, обработанных X-Force, затронули организации критической инфраструктуры. CrowdStrike в Global Threat Report 2025 фиксирует среднее время lateral movement после initial access - 62 минуты, рекорд - 51 секунда. Для OT-среды вывод прямой: если IT-сеть скомпрометирована, у защитников критически мало времени до того, как атакующий окажется на границе с промышленным сегментом.
Kill chain для IT->OT pivot:
- Initial access - фишинг, эксплуатация VPN, скомпрометированный подрядчик
- AD compromise - Kerberoasting, NTLM relay, AS-REP Roasting
- Lateral movement к инженерным станциям - jump hosts, shared credentials
- Пересечение IT/OT-границы - через DMZ, dual-homed хосты, VPN-концентраторы
- Взаимодействие с ПЛК/SCADA - чтение и запись регистров, модификация логики
Чем OT-сеть отличается от IT на уровне защитных мер
Если вы работали только с корпоративными сетями, OT-сегмент преподнесёт несколько неприятных сюрпризов, которые напрямую влияют на выбор инструментов и техник при пентесте промышленных сетей.Протоколы без аутентификации. Modbus TCP - рабочая лошадка промышленных коммуникаций - вообще не имеет встроенной аутентификации. Любой хост, способный отправить TCP-пакет на порт 502, может читать и записывать регистры ПЛК. Function codes делятся на чтение: FC1 (Read Coils), FC2 (Read Discrete Inputs), FC3 (Read Holding Registers), FC4 (Read Input Registers) - и запись: FC5 (Write Single Coil), FC6 (Write Single Register), FC15 (Write Multiple Coils), FC16 (Write Multiple Registers). DNP3 имеет опциональный Secure Authentication, но на практике он развёрнут на единичных процентах инсталляций. OPC UA поддерживает шифрование и сертификаты, но часто настроен в режиме None/None для совместимости с legacy-клиентами. По документам - безопасный протокол. На практике - голый как сокет.
Legacy-системы. Инженерные станции под Windows 7 или XP - не аномалия, а будни предприятий с жизненным циклом оборудования 20-30 лет (Siemens S7-300, Allen-Bradley PLC-5). Установка EDR-агента на станцию, управляющую технологическим процессом, - вопрос не технический, а организационный: вендор может аннулировать гарантию. CrowdStrike Falcon или SentinelOne на HMI-панели под Windows XP Embedded - забудьте.
Модель Purdue. Архитектура строится по Purdue Reference Model: Level 0 (физические процессы, датчики, актуаторы) -> Level 1 (ПЛК, RTU) -> Level 2 (SCADA-серверы, HMI) -> Level 3 (MES, historian) -> Level 3.5 (DMZ) -> Level 4-5 (корпоративная IT). Ваша задача при пентесте SCADA - пройти от Level 4-5 до Level 2 или даже Level 1. Каждый переход - отдельная задача с отдельными ограничениями.
Мониторинг. Корпоративные SIEM (Splunk, Elastic, MaxPatrol SIEM) в OT слепы: они не разбирают Modbus или DNP3 на уровне function codes. Специализированные OT-IDS - Claroty, Dragos Platform, Nozomi Guardian - работают иначе: строят baseline нормального промышленного трафика и детектируют аномалии. Новый IP, обращающийся к ПЛК, нетипичный function code, изменение частоты опроса - всё это алерт. Именно поэтому привычная тактика «закинул Cobalt Strike и пошёл гулять» здесь не прокатит.
Recon на границе IT/OT: fingerprinting промышленного сегмента
[Применимо: внутренний пентест, grey box - доступ к IT-сегменту получен]Требования к окружению
- Kali Linux 2024.x или Parrot OS
- Nmap 7.94+ (скрипты modbus-discover, s7-info входят в стандартную поставку)
- Wireshark или tcpdump для пассивного захвата
- RAM: от 4 ГБ, рекомендуется 8 ГБ
- Подключение к IT-сегменту с маршрутизацией к OT DMZ
tcpdump -i eth0 -w capture.pcap 'port 502 or port 102 or port 44818 or port 20000'. Даже без span-порта ARP-таблица на скомпрометированном хосте покажет, какие IP из OT-подсети общаются с IT-серверами: data historians, антивирусные серверы, WSUS. Тихо, без единого отправленного пакета.Шаг 2: аккуратное активное сканирование. Network Service Discovery (T1046, Discovery) - только после согласования с заказчиком. ПЛК с процессорами 1990-х могут уйти в fault от агрессивного SYN-скана. Был случай на одном аудите: коллеги из другой компании положили ПЛК Allen-Bradley SLC 500 обычным
nmap -T4. Контроллер ушёл в hard fault, процесс встал на два часа.
Bash:
nmap -sT -Pn -p 502,102,20000,44818 \
--script modbus-discover,s7-info \
--scan-delay 500ms -oA ot_recon 10.10.20.0/24--scan-delay 500ms - не рекомендация, а требование: без него рискуете вызвать отказ оборудования. Скрипт s7-info возвращает модель ПЛК, версию firmware, имя проекта - достаточно для подбора эксплойтов и понимания назначения контроллера.Шаг 3: поиск dual-homed хостов. Машины с двумя интерфейсами - один в IT, другой в OT - ваш главный приоритет. Это инженерные станции, data historians, jump-серверы. В AD они видны через DNS-записи с двумя A-записями или через
netstat -rn на скомпрометированных хостах. Каждый dual-homed хост - готовый мост для lateral movement OT. Нашли такой - считайте, полдела сделано.Lateral movement через IT/OT-границу: выбор вектора
Decision tree
| Что обнаружено | Техника | MITRE ATT&CK | Ожидаемая сложность |
|---|---|---|---|
| Инженерная станция в AD-домене | SMB/WMI через domain credentials | T1021.002, Lateral Movement | Низкая |
| Общие учётки для IT и OT | Valid Accounts | T1078, Initial Access | Низкая |
| NTLM на доменных хостах в OT | Pass the Hash | T1550.002, Lateral Movement | Средняя |
| VPN или jump host с доступом в OT | Protocol Tunneling | T1572, Command and Control | Средняя |
| Уязвимый сервис в DMZ | Exploitation of Remote Services | T1210, Lateral Movement | Высокая |
Shared credentials - самый частый вектор
Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation) срабатывает в подавляющем большинстве аудитов OT. Причина банальная: сервисные учётки SCADA-софта (WinCC, FactoryTalk, Citect) создаются в AD с паролями, которые не менялись годами. Локальные учётки administrator на инженерных станциях - часто с одинаковым паролем на всех машинах; LAPS в OT-сегменте я не встречал ни разу.Grey box: если заказчик выдал учётные данные оператора SCADA, первым делом проверяйте их на всех обнаруженных хостах OT-сегмента. Один пароль нередко работает для HMI, инженерной станции и VPN подрядчика. Классика жанра.
Ограничение: если OT-сегмент изолирован от AD (отдельный workgroup), доменные учётки бесполезны. Тогда ищите локальные credentials через LSASS dump на dual-homed хостах или в конфигурационных файлах SCADA-софта - многие хранят пароли в plaintext или с обратимым шифрованием. WinCC, например, исторически этим грешит.
Pass the Hash на границе
Pass the Hash (T1550.002, Lateral Movement) применим, если инженерные станции включены в общий AD-домен с NTLM-аутентификацией.Работает если: инженерная станция - member of AD domain, NTLM enabled, SMB/RPC доступен через файрвол между зонами.
Не работает если: OT-сегмент в отдельном workgroup без доменного доверия, на файрволе разрешён только Modbus TCP (порт 502), или на engineering workstation активирован Windows Defender Credential Guard (что в OT редко, но встречается на свежих инсталляциях Siemens TIA Portal под Windows 10/11).
Protocol Tunneling через разрешённые порты
Когда файрвол на границе IT/OT пропускает только специфические порты (502, 443), Protocol Tunneling (T1572, Command and Control) - основной способ получить полноценный доступ в OT. Компрометируете dual-homed хост (historian, jump server) через IT-интерфейс, разворачиваете туннель и получаете доступ к OT-подсети.Chisel (GitHub - jpillora/chisel: A fast TCP/UDP tunnel over HTTP, активно поддерживается) прокидывает SOCKS-прокси через HTTPS - сливается с легитимным трафиком historian. Ligolo-ng - альтернатива с TUN-интерфейсом для более прозрачного pivoting. На практике я предпочитаю Chisel: бинарь маленький, настраивается за минуту, в трафике выглядит как обычный HTTPS.
Ограничение: если на границе стоит DPI, заточенный на промышленные протоколы, туннелирование произвольного трафика через порт 502 будет замечено. Modbus-пакет имеет жёсткую структуру MBAP-заголовка (7 байт: Transaction ID, Protocol ID, Length, Unit ID), и DPI отличит его от инкапсулированного HTTP/SOCKS. Через 443 шансы выше - HTTPS есть HTTPS.
Exploitation of Remote Services в DMZ
Exploitation of Remote Services (T1210, Lateral Movement) нацелен на сервисы в DMZ: data historians (OSIsoft PI, Aveva Historian), WSUS-серверы, антивирусные серверы. Эти системы часто работают под Windows Server с известными уязвимостями и имеют сетевой доступ в обе стороны.Применимо: внутренний пентест, grey box, обнаружен непропатченный historian в DMZ. Historian - идеальная цель: он подключён к IT-сети для передачи данных в BI и одновременно собирает теги из OT через OPC или Modbus. Два интерфейса, один непропатченный Windows Server - что может пойти не так?
Работа с промышленными протоколами: от чтения регистров до понимания процесса
После получения сетевого доступа в OT-сегмент - через pivot или скомпрометированную инженерную станцию - начинается специфика пентеста SCADA. Metasploit содержит модули для промышленных протоколов. Чтение Modbus-регистров:
Код:
use auxiliary/scanner/scada/modbusclient
set RHOST 10.10.20.100
set DATA_ADDRESS 0
set ACTION READ_HOLDING_REGISTERS
set NUMBER 10
runЗапись в регистры (FC6, FC16) - действие с физическими последствиями. На реальном пентесте запись в ПЛК выполняется строго при явном согласовании с заказчиком и в присутствии оператора, способного перевести процесс в ручной режим. Разница между «прочитал регистр» и «записал регистр» - это разница между демонстрацией доступа и потенциальной остановкой турбины.
Дополнительные инструменты: PLCScan (Python, обнаружение и fingerprinting ПЛК - проект не обновлялся активно с 2018-2019, используйте с пониманием ограничений) и Redpoint NSE-скрипты для Nmap. Для Siemens S7 скрипт
s7-info возвращает модель CPU, серийный номер и название проекта - информация, достаточная для оценки критичности контроллера.Evasion и OPSEC при пентесте OT-сети
Специализированные платформы OT-мониторинга работают не так, как корпоративный SOC. Dragos Platform и Claroty используют DPI для промышленных протоколов и разбирают Modbus до уровня function code плюс register address. Nozomi Guardian строит граф сетевых взаимодействий и профилирует каждое устройство. Обмануть их сложнее, чем корпоративный SIEM.
Что гарантированно вызовет алерт:
- Появление нового IP, общающегося с ПЛК (ваш Kali или pivot-хост, отсутствующий в baseline)
- Modbus-команды записи (FC5, FC6, FC15, FC16) от хоста, который раньше только читал
- Сканирование портов - даже медленное, с
--scan-delay - S7comm-функции Stop CPU или Download Block
- Любое изменение конфигурации контроллера
- Пассивный захват трафика невидим для OT-IDS - начинайте с него
- Для активной разведки используйте IP скомпрометированной инженерной станции, а не собственный
- Ограничивайтесь read-only операциями (FC1, FC3) - они не выделяются на фоне штатного SCADA-опроса
- Выполняйте сканирование в период технологических окон, когда трафик выше обычного
- Туннель пускайте через легитимный historian, чей трафик уже есть в baseline
Минилаб для отработки IT->OT pivot
Цепочка для отработки: Kerberoast сервисную учётку AD -> Pass the Hash на historian -> pivot через historian в OT-подсеть -> чтение регистров OpenPLC через Modbus. Весь путь от initial access до взаимодействия с ПЛК - на изолированном стенде без риска для реального оборудования.
Заключение
Большинство предприятий, которые я аудировал, верят, что файрвол между IT и OT закрывает вопрос. По документам - два VLAN, ACL на Cisco ASA, может быть DMZ с data historian. На практике - сервисная учётка SCADA-софта в корпоративном AD с паролем трёхлетней давности, dual-homed инженерная станция, на которой оператор читает почту и программирует ПЛК с одного рабочего стола, VPN подрядчика Siemens без MFA. Каждый из этих элементов - готовый мост для lateral movement, и никакой ACL его не закроет, потому что трафик через эти мосты легитимен.Проблема глубже: пентест OT-сегмента заказывают на порядок реже, чем пентест IT. Страх остановки производства, сложность согласования, дефицит специалистов, одновременно понимающих AD и Modbus. Результат - промышленная сеть живёт с конфигурацией пятилетней давности, пока IT-периметр проверяют ежеквартально. По моему опыту, в восьми из десяти аудитов путь от domain admin до чтения регистров ПЛК занимает меньше рабочего дня при формально «сегментированной» архитектуре. Группы уровня Sandworm или XENOTIME этот путь пройдут быстрее - и не остановятся на чтении регистров.
Если хотите отработать эту цепочку целиком - на WAPT разбирают lateral movement в корпоративных сетях, а связку IT→OT можно прогнать на стенде из раздела выше.
Последнее редактирование модератором:
