Не каждая кибератака начинается с вредоносного файла. Иногда достаточно легитимной учётной записи, штатных инструментов и пары привычных команд, чтобы вмешаться в работу производства. Именно поэтому в АСУ ТП сигнатурной защиты уже недостаточно.
- 1. Введение
- 2. Как атака попадает в промышленную сеть
- 3. Почему сигнатуры перестают видеть угрозу
- 4. Что использует атакующий вместо вредоноса
- 5. Как вернуть видимость и управляемость
- 6. Выводы
Введение
Три часа ночи. В промышленную сеть входит учётная запись инженера. Логин и пароль верные, права доступа есть, сессия похожа на штатную работу. Антивирус молчит: нового файла нет, знакомого вредоносного хеша нет, подозрительной нагрузки тоже. Но сам инженер в это время спит дома, а подключение идёт из сегмента, из которого он обычно не работает.
В этом и опасность living-off-the-land в промышленных сетях. Атакующий не обязательно приносит в инфраструктуру новый исполняемый файл, который можно распознать по сигнатуре. Он использует то, что уже разрешено: легитимные учётные записи, штатные протоколы, удалённое администрирование, инженерные станции и стандартные команды. Для средств защиты такая активность может выглядеть как нормальная работа, а риск возникает из контекста: кто выполняет действие, откуда, когда и к какому оборудованию.
Одним из основных способов первичной компрометации остаётся фишинг, но главная сложность начинается после входа в сеть: атака может выглядеть как обычная инженерная операция. Разбираемся, почему в АСУ ТП одних сигнатур недостаточно и как отличить штатное действие от опасного.
Как атака попадает в промышленную сеть
Легитимную учётную запись редко получают непосредственно в АСУ ТП. Чаще точка входа находится в корпоративной ИТ-среде: фишинговое письмо, кража паролей через стилер, открытый сервис удалённого доступа, скомпрометированная учётная запись подрядчика или поставщика. Затем атакующий смещается в технологический сегмент: через слабую сегментацию, общие учётные данные, постоянные удалённые доступы или инженерные станции, которые связаны сразу с несколькими зонами.
Именно на стыке ИТ и ОТ living-off-the-land становится особенно опасным. В офисном контуре атакующий получает первичный доступ, закрепляется, изучает инфраструктуру и ищет путь к технологической среде. Когда он доходит до АСУ ТП, ему уже не обязательно использовать вредоносные программы. Достаточно учётных данных, доступа к инженерной станции или разрешённого канала удалённого администрирования.
После перехода в технологический сегмент меняется и цена ошибки. В корпоративной инфраструктуре последствия атаки чаще всего измеряются утечкой данных, простоем сервиса, штрафами или восстановлением из резервной копии. В АСУ ТП команда в системе может изменить физический процесс. Иногда достаточно легитимной операции: закрыть заслонку, остановить двигатель, изменить дозировку, перезагрузить контроллер. Дальше работает уже не ИТ-логика, а физика производства: растёт давление, останавливается линия, срывается цикл, на опасном объекте появляется риск аварии.
Поэтому в промышленной сети недостаточно искать вредоносный файл. Нужно понимать, когда формально разрешённая команда становится опасной: в конкретный момент, на конкретном участке и от конкретного пользователя.
Российский регуляторный подход тоже смотрит на такие сценарии не через наличие или отсутствие вредоносного файла, а через действия нарушителя: работу с легитимной учётной записью, разведку узлов, воздействие на процесс, подавление защитных функций. Пока специалист видит только «странное, но законное» действие, риск остаётся на уровне ощущения. Когда действие связывается с конкретным способом атаки и возможным воздействием на производство, появляется картина, с которой уже можно работать: ограничивать доступы, менять сегментацию, настраивать мониторинг и сценарии реагирования.
Почему сигнатуры перестают видеть угрозу
Именно здесь появляется предел сигнатурной защиты. Представим типовой сценарий: подрядчик присылает сотруднику промышленного предприятия письмо с документами по проекту. Внутри нет файла, который выглядит как классический вредонос. Это может быть архив с «безобидным» PDF, но внутри него скрыт макрос или ссылка на легитимный облачный сервис, где лежит скомпрометированный файл конфигурации для SCADA.
Атакующему не нужно тащить вирус-шифровальщик. Его цель — украсть пароль инженера или найти открытый RDP-порт. После того как сотрудник открывает документ, срабатывает мини-скрипт (тоже штатный — PowerShell или WMI), который «прощупывает» сеть, находит незакрытый сервис и подменяет легитимный процесс инженерного ПО.
С этого момента злоумышленник работает уже под авторизованной учётной записью. Дальше используются разрешённые инструменты: программа удалённого доступа, штатная утилита командной строки, скрипт для передачи данных или администрирования. Формально это знакомые компоненты инфраструктуры. Риск возникает не в самом инструменте, а в том, кто его запустил, зачем и что он начал делать после запуска.
Такая атака не обязана быть быстрой и шумной. Атакующий может изучать сеть, проверять доступы, смотреть, какие станции связаны с контроллерами, кто работает с удалёнными объектами, какие учётные записи имеют повышенные права. Пока он действует через привычные для инфраструктуры инструменты, отдельные события выглядят как рабочая активность.
Сигнатурный анализ хорошо распознаёт известное: вредоносное поведение, эксплойты, подозрительные файлы, совпадения с базой индикаторов. Отказываться от него нельзя. Но если пользователь с законными правами отправил команду «стоп» и двигатель остановился, сигнатура видит разрешённый пакет. Она не оценивает, уместна ли команда, должен ли этот пользователь выполнять её ночью и работал ли этот узел раньше с этим контроллером.
В промышленной сети эффективнее обратная логика: описывать норму и реагировать на отклонения. Технологический процесс обычно предсказуемее офисной среды, а набор штатных команд, маршрутов и узлов ограничен. Для living-off-the-land это принципиально: злоумышленник делает не «запрещённое» в терминах сигнатур, а нетипичное в терминах процесса.
Что использует атакующий вместо вредоноса
Если разобрать такую цепочку по шагам, её арсенал почти полностью состоит из легальных инструментов. Промышленные протоколы Modbus, S7 и другие содержат штатные команды чтения, записи, запуска и остановки. RDP, SSH и VPN привычны для распределённых объектов, но тот же канал может стать входной точкой. Забытые технические аккаунты и доступы подрядчиков, оставленные «для отладки», дают атакующему возможность действовать почти без шума.
Даже диагностика может работать на атакующего. Ping, трассировка и широковещательное сканирование выглядят как обычная проверка доступности, но позволяют построить карту сети и найти путь к критичному участку.
На практике это выглядит буднично. Подрядчик подключается к своему сегменту, что само по себе разрешено, но затем с его точки доступа начинается сканирование за пределами зоны ответственности. Или через командную строку создаётся локальная учётная запись с правами администратора. Или уходит команда на перезагрузку удалённого контроллера, и производственный цикл прерывается.
Закрыть эту проблему антивирусом или EDR на всех узлах АСУ ТП часто невозможно. Старым ОС на слабом железе, включая Windows XP на специализированном оборудовании, может не хватать памяти, процессора и совместимости для современных агентов. На ПЛК обычно нельзя установить внешнее ПО: это устройство с прошивкой, вмешательство в которую может нарушить гарантию и сделать поведение непредсказуемым.
Технические ограничения усиливаются организационными. Даже сильное средство защиты мало поможет, если подрядчик подключается по постоянному доступу, старые технические учётные записи не отозваны, многофакторная аутентификация не включена, а технологический сегмент связан с ИТ-средой без жёстких границ.
Есть и отдельное ограничение, которого почти нет в офисной ИТ-среде: непрерывность производства. Многие предприятия запрещают останавливать процесс ради установки защиты или перезагрузки критичных узлов. Поэтому у классической защиты конечных точек в промышленной среде неизбежно остаются слепые зоны.
Как вернуть видимость и управляемость
Раз атака может идти через разрешённые инструменты, защитная логика должна смещаться от поиска файла к анализу поведения. В таких условиях ключевую роль играет промышленный анализ трафика — решения класса NTA (Network Traffic Analysis) для OT-сред. Их задача не ограничивается адресами и соединениями. Они должны видеть содержание технологического взаимодействия: какая команда прошла, было ли это чтение, запись, запуск, остановка или изменение параметра. Такой мониторинг работает пассивно, на зеркалированном трафике, не ставит агенты на контроллеры и не нагружает критичные узлы.
Ценность появляется в конкретной логике детектирования. Инженерная станция впервые обратилась к незнакомому контроллеру. В сегменте появились команды записи или остановки, которых обычно не бывает. Узел, который раньше работал с одной системой, начал обращаться ко всем соседним устройствам. Каждое действие формально законно, но в контексте конкретной сети становится отклонением. Профиль нормы не появляется сам по себе: первые недели требуют настройки и дают шум. Но без него невозможно отличить штатную операцию от атаки, выполненной чужими руками.
NTA нужно дополнять контролем конфигураций и сканированием уязвимостей. Эталонные параметры рабочих станций, установленное ПО, версии, учётные записи и права сверяются с текущим состоянием по расписанию. Новая учётная запись или изменение прав становятся поводом для проверки. Это закрывает часть того, чего нет в трафике: например, изменение, внесённое вручную на станции.
Сканирование уязвимостей и сопоставление установленного ПО с базами уязвимостей показывают, где риск можно реально эксплуатировать, и помогают расставить приоритеты: что нужно изолировать, что обновлять, где компенсировать риск ограничением доступа или дополнительным мониторингом.
Отдельно стоит продумать реагирование. В промышленной сети нельзя просто изолировать узел или выдернуть кабель: само это действие может остановить процесс и стать причиной аварии. Здесь NTA полезен не только как источник сигнала, но и как инструмент для принятия решения. Он показывает, какой узел стал источником активности, к какому контроллеру или инженерной станции шло обращение, по какому протоколу, какая команда передавалась, была ли это операция чтения, записи, остановки, перезагрузки или изменения параметра.
Важен и контекст: работал ли этот узел с таким оборудованием раньше, происходило ли подключение в штатное окно, не вышел ли пользователь или подрядчик за пределы своей зоны ответственности.
За счёт ретроспективы можно восстановить цепочку событий: когда появилась новая связь, с какого сегмента началось движение, какие учётные записи использовались, какие команды уходили в технологический контур и затронуло ли это только один узел или уже несколько участков сети. Это помогает не действовать вслепую.
Вместо автоматической блокировки, опасной для производства, команда ИБ и инженеры АСУ ТП могут понять масштаб события, согласовать безопасное действие с технологами и выбрать точечную реакцию: ограничить конкретную сессию, проверить учётную запись, остановить удалённый доступ подрядчика, сверить конфигурацию станции или подготовить безопасное переключение.
По сути, NTA даёт картину, без которой реагирование в OT превращается в угадывание. Но сама по себе система анализа трафика не заменяет базовую управляемость промышленной сети. Чтобы сигнал был полезен, его нужно с чем-то сравнить: с картой активов, перечнем разрешённых подключений, зонами ответственности пользователей, данными о конфигурациях, известными уязвимостями и нормальным профилем технологического обмена. Иначе даже точное событие останется вопросом без ответа: это штатная работа инженера, ошибка подрядчика, эксплуатация известной уязвимости или уже часть атаки.
Поэтому начинать стоит с карты промышленной сети хотя бы на верхних уровнях: какие устройства есть, за что они отвечают, какие IP-адреса им соответствуют, кто владелец сегмента. Затем нужна видимость удалённых подключений: кто, откуда и к чему подключился. Базовая гигиена доступа закрывает значительную часть риска: инвентаризация и отзыв лишних технических учётных записей, MFA для удалённого доступа, доступ подрядчиков только по времени и заявке.
Следующий шаг — фиксация изменений в ПЛК: кто и когда отправлял команды, соответствует ли эталонная версия проекта рабочей. И наконец, описание нормального профиля трафика.
Тогда вывод про сигнатуры становится практическим, а не декларативным. Проблема не в том, что сигнатуры «больше не нужны»: против известного вредоноса они работают. Проблема в том, что living-off-the-land проходит без файла, без хеша и без явной вредоносной нагрузки. В таком сценарии работает не совпадение с базой, а понимание нормы и отклонений от неё.
Главный вопрос для предприятия простой: известно ли, что на самом деле происходит внутри промышленной сети в обычный рабочий день. Кто подключается, какие команды отправляет, какие изменения вносит и соответствует ли это норме.
Выводы
Сигнатурная защита остаётся важным элементом кибербезопасности, но в промышленных сетях она уже не способна закрыть весь спектр угроз. Когда злоумышленник использует легитимные учётные записи, штатные протоколы и встроенные инструменты администрирования, ключевым становится не поиск вредоносного файла, а анализ контекста действий и отклонений от нормального поведения.
Чем меньше атака отличается от повседневной работы, тем выше требования к наблюдаемости промышленной сети. Когда каждое действие выглядит легитимным, решающее значение приобретают контекст, история взаимодействий и понимание технологического процесса — именно они позволяют отличить инженера от злоумышленника.
