В 2026 году водоочистные сооружения в нескольких городах Польши предположительно были скомпрометированы на OT-уровне - с нарушением водоснабжения (независимая верификация инцидента отсутствует). Чуть раньше - координированная атака на распределённую энергетическую инфраструктуру Польши, предположительно с повреждением оборудования. Два инцидента - один паттерн: злоумышленники больше не останавливаются на IT-периметре. Они целенаправленно спускаются по Purdue-модели до контроллеров и исполнительных устройств. Разбираю конкретные техники - от начального доступа до манипуляции function codes Modbus - с которыми сталкиваюсь при аудитах OT-сегментов.
Бизнес-логика атаки на OT: зачем атакуют промышленные системы управления
Атака на IT-инфраструктуру обычно заканчивается шифрованием данных или их кражей - ущерб в деньгах и репутации. Атака на OT-сегмент - принципиально другой импакт:Физический ущерб. Повреждение турбин, насосов, трансформаторов. Инциденты в энергетическом секторе показывают: атакующие способны повредить оборудование через манипуляцию уставками. По данным Shieldworkz (требует независимой верификации), после инцидента были выпущены рекомендации пересмотреть безопасность edge-подключений и сегментацию.
Прерывание сервиса для населения. Водоснабжение, электричество, отопление. Тут не данные утекли - тут кран не течёт.
Предпозиционирование. Государственные группировки закрепляются в OT-сетях на месяцы или годы до активации. Группировки, связываемые с Volt Typhoon, предположительно закреплялись в сетях электроэнергетических и телекоммуникационных компаний (конкретные TTPs описаны в совместных advisory CISA/NSA/FBI, независимая верификация отдельных деталей затруднена).
Эта мотивационная разница - не данные, а физические процессы - определяет и выбор техник, и необходимость принципиально иного подхода к детектированию.
Угрозы безопасности ICS/SCADA в 2026 году: три вендора, три методологии
При анализе угроз не стоит смешивать метрики разных вендоров в единую картину - у каждого своя методология, клиентская база и период наблюдения.IBM X-Force Threat Intelligence Index (данные за 2024 год): 70% инцидентов, на которые реагировала команда X-Force, затронули критическую инфраструктуру. Методология - incident response engagements клиентской базы IBM, преимущественно крупные предприятия, глобальная выборка.
CrowdStrike Global Threat Report (данные за 2024 год): +150% рост активности China-nexus adversaries год к году. Эта цифра характеризует рост активности китайских группировок по всем секторам, не только OT/ICS. Метрика получена из телеметрии сенсоров Falcon на endpoint-ах корпоративных клиентов. Делать из неё прямой вывод о целенаправленном росте атак на промышленные системы управления - натяжка, но вектор коррелирует с тем, что наблюдаю в OT-сегменте.
RED Security SOC (Q1 2026, Россия): по данным RED Security SOC (требует независимой верификации), 77% кибератак в стране направлены на объекты критической информационной инфраструктуры, общее число превысило 9000 за квартал. Методология - мониторинг клиентов RED Security SOC, российские организации. Доля высококритичных атак в КИИ - 27% против 20% в остальных отраслях.
Три квартала подряд растёт доля шпионского ПО. Рост шифровальщиков в производственной отрасли - в 2,3 раза.
Что эти метрики показывают вместе: количество и интенсивность атак на OT/ICS устойчиво растут. Но каждая цифра отражает конкретный срез - конкретного вендора, конкретного региона, конкретного типа клиентов. Не складывайте 70% IBM с 77% RED Security - это разные популяции и разные определения «критической инфраструктуры».
Векторы компрометации АСУ ТП: Purdue-модель как карта атаки
Purdue-модель делит промышленную сеть на уровни от 0 (физические процессы) до 5 (внешние сети). Начальный доступ в OT почти всегда идёт с верхних уровней (3–5) вниз. Каждый вектор - своя точка входа.Exploit Public-Facing Application (T1190, Initial Access) - граница уровней 4-5
[Применимо: внешний пентест, инфраструктура с публичными OT-компонентами]Эксплуатация уязвимостей в веб-интерфейсах SCADA, HMI-панелях с внешним доступом, публичных API industrial gateways. По данным Claroty (через NexusConnect), около 40% организаций имели устройства с известными, активно эксплуатируемыми уязвимостями, небезопасно подключённые к интернету.
Работает если: HMI/SCADA-серверы доступны из внешней сети (прямой IP, проброс портов), патчи не установлены, аутентификация отсутствует или дефолтные учётные данные. Не работает если: OT-компоненты изолированы от внешних сетей, используются промышленные файрволы с deep packet inspection для ICS-протоколов.
Shodan и Censys по-прежнему находят тысячи устройств с открытыми портами Modbus/TCP (502), EtherNet/IP (44818) и HMI-панели без аутентификации. Каждый раз, когда смотрю на эти результаты - удивляюсь. Но перестал удивляться.
External Remote Services (T1133, Initial Access / Persistence) - уровни 3-4
[Применимо: любая инфраструктура с удалённым доступом вендоров или инженеров]VPN- и RDP-подключения к инженерным станциям - самый массовый вектор. Подрядчики подключаются для обслуживания ПЛК, но VPN-туннель часто не ограничен конкретными хостами и портами внутри OT-сегмента. Получил VPN - получил всё.
RED Security SOC отмечает (Q1 2026): организации КИИ выстраивают защиту собственного периметра, но их партнёры - IT-подрядчики - часто имеют слабую защиту. Низкий уровень безопасности контрагентов превращается в лазейку.
Работает если: VPN-доступ вендора не ограничен по IP/порту/времени, нет MFA, сессии не записываются. Не работает если: brokered access с MFA, time-boxed сессии с записью, сегментация вендорского доступа до конкретных хостов.
Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation / Defense Evasion) - все уровни
[Применимо: внутренний пентест, post-compromise]Украденные или общие учётные данные - бич OT-сегментов. В промышленных средах shared credentials встречаются повсеместно: один пароль на весь отдел, один логин на HMI для всех операторов. Если атакующий получил учётные данные из IT-сегмента (фишинг, keylogger, утечка), он часто может использовать те же credentials в OT - доменная аутентификация нередко распространяется и на уровень 3 (historian, SCADA-серверы).
Работает если: общие учётные записи, нет MFA на инженерных станциях, единый домен для IT и OT. Не работает если: OT-сегмент использует отдельный домен или локальные учётные записи с индивидуальными паролями.
Hardware Additions (T1200, Initial Access) - уровни 1-2
[Применимо: физический доступ к объекту, insider threat]USB-накопители и ноутбуки подрядчиков - по данным отраслевых публикаций (IIoT World, точная методология не верифицирована), значительная доля OT-инцидентов связана с transient devices. Физический пронос заражённой флешки обходит все сетевые средства защиты. Старый добрый sneakernet.
Для объектов с высокой критичностью на входе устанавливаются physical sanitization kiosks, сканирующие все съёмные носители до подключения к OT-сети. Для наиболее критичных сред - hardware-enforced data diodes, физически однонаправленная передача данных.
Атаки на энергетическую инфраструктуру: латеральное движение из IT в OT
Типичная цепочка от компрометации IT-хоста до воздействия на физический процесс проходит несколько ступеней:Уровень 5 → 4 (IT → IT-DMZ): фишинг или эксплуатация уязвимости на endpoint в корпоративной сети. Стандартные IT-техники, ничем не отличающиеся от типового пентеста.
Уровень 4 → 3 (IT-DMZ → OT-DMZ): pivoting через historian server, data integration server или SCADA-сервер с двойным подключением (dual-homed). На практике это самая уязвимая точка. Historian-серверы часто имеют интерфейсы в обеих сетях для передачи производственных данных в ERP. Один сетевой интерфейс смотрит в IT, второй - в OT. Мечта атакующего.
Уровень 3 → 2 (OT-DMZ → Supervisory): доступ к SCADA/HMI-серверам. На этом уровне атакующий видит технологический процесс - мнемосхемы, параметры, уставки.
Уровень 2 → 1 (Supervisory → Control): прямое взаимодействие с ПЛК. Здесь начинаются протокольные атаки - отправка Modbus-команд, загрузка модифицированной логики, изменение уставок.
Ключевая разница IT и OT на уровне защиты: на уровнях 1–2 стандартные средства детектирования часто отсутствуют. Нет EDR на контроллерах, нет SIEM-агентов. Старые ПЛК (Siemens S7-300, Allen-Bradley MicroLogix) не поддерживают установку стороннего ПО. Детектирование возможно исключительно через анализ сетевого трафика (passive monitoring). Контроллер слепой - видит только сеть, которая его слушает.
OT пентест: атаки на промышленный протокол Modbus и другие SCADA уязвимости
Modbus TCP - какие function codes опасны и почему
Modbus - протокол без встроенной аутентификации и шифрования. Любой хост с сетевым доступом к порту 502 может отправить команду на ПЛК. Протокол проектировали в 1979 году - тогда никто не думал, что промышленная сеть будет доступна из интернета. Разберём конкретные function codes с позиции атакующего.FC 6 (Write Single Register) и FC 16 (Write Multiple Registers) - основной вектор атаки на производственный процесс. Эти коды записывают произвольные значения в holding-регистры ПЛК, где хранятся уставки: температурные пороги, давление, скорость вращения, положение задвижек. Запись некорректных уставок - именно тот механизм, через который атакующий останавливает процесс, вызывает аварию или повреждает оборудование.
Пример: установка температурного порога аварийного отключения ниже текущей рабочей температуры через FC 6 - ПЛК штатно выполнит аварийную остановку, потому что «температура превышена». С точки зрения контроллера - легитимное срабатывание защиты. Красиво, если не знать контекст.
FC 5 (Write Single Coil) и FC 15 (Write Multiple Coils) - переключение дискретных выходов (реле, клапаны, двигатели). Прямой путь к физическому воздействию.
FC 8 (Diagnostics), sub-function 0x0001 (Restart Communications Option) - распространённое заблуждение, что этот код «останавливает ПЛК». Нет. Sub-function 0x0001 сбрасывает состояние communication event log и перезапускает коммуникационный порт. Выполнение управляющей логики на ПЛК не прекращается. Этот код полезен атакующему для другого - очистки логов коммуникационных событий, что соответствует тактике сокрытия следов (Indicator Removal, T1070).
OPC UA и DNP3 - дополнительные поверхности атаки
OPC UA поддерживает шифрование и аутентификацию, но на практике часто развёрнут с самоподписанными сертификатами и политикой безопасностиNone. На аудитах OT-сегментов регулярно встречаю серверы OPC UA с включённым Anonymous access. По документам - безопасный протокол. На практике - дверь нараспашку.DNP3 (энергетика, водоснабжение) поддерживает unsolicited responses - устройство отправляет данные мастер-станции без запроса. Атакующий, получивший доступ к сегменту с DNP3-устройствами, может инжектировать ложные unsolicited responses, создавая искажённую картину технологического процесса - подмену показаний датчиков. Оператор видит на экране «всё нормально», а в реальности давление уже за пределами.
Ограничение: атаки на уровне протоколов требуют сетевого доступа к OT-сегменту (уровни 1–2 Purdue). Без предварительного lateral movement или физического доступа протокольные атаки невозможны.
Детектирование атак на промышленные системы управления: Suricata и ограничения
Suricata-правило для Modbus: практика настройки
Требования к окружению: Suricata 7.x с включённым парсером Modbus (app-layer.protocols.modbus.enabled: yes в suricata.yaml). Переменные $ENGINEERING_HOSTS (IP-адреса легитимных инженерных станций) и $PLC_NET (подсеть контроллеров) определяются в конфигурации. Зеркалирование трафика через SPAN-порт или TAP на уровне 2 Purdue. Проверка конфигурации: suricata -T -c /etc/suricata/suricata.yaml.
Код:
alert modbus !$ENGINEERING_HOSTS any -> $PLC_NET 502 \
(msg:"SCADA: Modbus FC6 write from non-eng host"; \
modbus.function: 6; sid:1000001; rev:1;)
alert modbus !$ENGINEERING_HOSTS any -> $PLC_NET 502 \
(msg:"SCADA: Modbus FC16 write-multi from non-eng host"; \
modbus.function: 16; sid:1000002; rev:1;)
alert modbus !$ENGINEERING_HOSTS any -> $PLC_NET 502 \
(msg:"SCADA: Modbus FC5 coil write from non-eng host"; \
modbus.function: 5; sid:1000003; rev:1;)Что пропускает сетевое детектирование в OT
Правила выше - рабочий старт. Но слепых зон хватает.Suricata-правила - рабочий старт для организаций без бюджета на коммерческие ICS-мониторинговые решения, при условии корректного зеркалирования и инвентаризации.
APT группы, атакующие ICS: разбор инцидентов 2025-2026
Водоочистные сооружения Польши (май 2026)
По неподтверждённым данным, атакующие предположительно получили доступ к промышленным системам управления в нескольких городах. Полная техническая детализация не раскрыта, но из контекста и аналогичных инцидентов сектора водоснабжения можно восстановить вероятный kill chain:- Initial Access: Exploit Public-Facing Application (T1190) или External Remote Services (T1133) - эксплуатация веб-интерфейса или VPN с украденными учётными данными
- Lateral Movement: переход IT → OT через dual-homed historian или SCADA-сервер
- Impact: Firmware Corruption (T1495) или манипуляция параметрами процесса (дозирование реагентов, давление)
Атака через ViPNet (Россия, июль 2026)
В 2026 году была выявлена целевая атака через отечественное ПО ViPNet, предназначенное для построения защищённых сетей (точная дата и источник первичного отчёта требуют верификации). Атакующие использовали легитимное средство защиты как вектор - supply chain compromise через программный канал. Классификация по MITRE неоднозначна: T1195.002 (Compromise Software Supply Chain) описывает внедрение на этапе разработки/сборки, T1195.003 (Compromise Hardware Supply Chain) ближе к аппаратно-программным каналам связи, но ни одна подтехника не описывает точно сценарий компрометации через доверенный VPN-канал. Классификация - моё предположение.Инцидент показателен: доверие к «безопасному» ПО само по себе становится уязвимостью. Промышленные предприятия и государственные организации, использующие ViPNet для VPN-подключений между площадками (включая OT-сегменты), оказались под ударом через канал, который считался защищённым. Ирония: VPN - средство защиты, через которое зашли.
Тренд на secure by design - встраивание безопасности на этапе разработки - по данным IIoT World, становится ключевым в 2026 году. Но для legacy OT-оборудования с циклами жизни 15–25 лет этот подход применим только к новым закупкам. А старый Siemens S7-300 стоит себе в цеху и никуда не собирается.
Защита критической инфраструктуры: практические выводы
Сегментация - не checkbox, а процесс. Purdue-модель остаётся базовым инструментом проектирования OT-сетей, но модель на бумаге и модель в production - разные вещи. Cameron Lee (через NexusConnect) рекомендует: машины на производственных площадках - в собственные сегменты, VPN только с brokered time-boxed доступом и MFA.Инвентаризация - условие работы детектирования. Без точного списка
$ENGINEERING_HOSTS правила Suricata бесполезны. На практике большинство OT-сегментов не имеют даже статического списка всех подключённых устройств.Мониторинг процессных значений, а не только трафика. Suricata покажет, КТО отправил FC 16. Но не покажет, что записанное значение - аварийное. Для этого нужна интеграция с SCADA historian и алерты на выход параметров за допустимые диапазоны.
ФЗ-187 задаёт рамку, но не решает проблему. Федеральный закон обязывает субъектов КИИ категорировать объекты и выполнять требования ФСТЭК (ст. 14 - государственный надзор через плановые и внеплановые проверки по Постановлению Правительства №162). Категорирование и бумажная отчётность не гарантируют, что FC 16 write-запросы на ПЛК фильтруются по источнику.
После нескольких десятков аудитов OT-сегментов вижу одну и ту же картину: формально у предприятия есть категорирование по ФЗ-187, документы по сегментации, политики - а engineer workstation на уровне 3 Purdue имеет RDP-сессию во внешний интернет «для скачивания обновлений прошивок».
Проблема промышленной кибербезопасности в 2026 году - не отсутствие инструментов и не нехватка фреймворков. IEC 62443, NIST 800-82, NIS2, Purdue - всего хватает. Проблема - разрыв между документированной архитектурой и реальной сетевой топологией. Пока этот разрыв существует, атакующему достаточно одного dual-homed historian-сервера, чтобы из корпоративной почты добраться до Modbus-порта ПЛК.
Инструменты мониторинга работают - но только при условии, что сеть соответствует заявленной топологии. Если нет - мониторинг покрывает «как должно быть», а атака идёт через «как есть».
Те, кто проводит OT-аудиты, знают: первый шаг - не настройка SIEM и не развёртывание Dragos, а верификация реальной сетевой карты. Возьмите
$ENGINEERING_HOSTS из ваших правил Suricata и сравните с тем, что реально подключено к OT-сегменту. В большинстве случаев эта карта существенно отличается от документов по категорированию. И именно в этом зазоре живёт атакующий.