Как обнаружить S7Flip в сети АСУ ТП и защитить ПЛК Siemens

2026.10.08

📋 Кратко

S7Flip — образец для Windows, который обнаруживают на компьютере в промышленной среде с оборудованием Siemens. Он ищет устройства в локальной сети и пытается работать с ПЛК через S7Comm и Modbus TCP. Фактический вред контроллерам пока не подтверждён. Поэтому защита строится на пассивном мониторинге, контроле инженерных станций и проверке целостности проектов.

⏱ 7 минут чтения│сложность

В промышленной сети даже один неизвестный файл на инженерной станции требует проверки. Такой файл может получить доступ к узлам АСУ ТП через доверенный компьютер. Риск растёт, если станция видит ПЛК без строгих сетевых ограничений.

S7Flip привлекает внимание именно по этой причине. Образец обнаруживают на компьютере с Windows в промышленной среде с оборудованием Siemens. Он сканирует локальные адреса и пытается взаимодействовать с промышленными устройствами.

Главное ограничение выводов: доступные сведения описывают поведение образца. Фактический вред контроллерам пока не подтверждён. Сетевые признаки сами по себе также не доказывают заражение.

Подозрительный образец требует проверки, а не ярлыка

🔍 Что известно о S7Flip сейчас

S7Flip — условное имя подозрительного Windows-образца. Его обнаруживают в коллекции вредоносных файлов MalwareBazaar. Для образца указывают SHA-256: e014dadf6d93b312b93e2fc857791c241692da4015da7a24a4d42a946551add2.

Сетевой сигнал требует согласования технологического риска

Описание образца связывает его с промышленной средой и оборудованием Siemens. Программа предположительно нацелена на системы управления. При этом автор наблюдения отдельно подчёркивает отсутствие подтверждённого вреда для контроллеров.

По имеющимся данным, S7Flip пытается работать с данными ПЛК через S7Comm и Modbus TCP. Также образец маскируется и закрепляется в Windows. Это делает инженерную станцию важной точкой проверки.

Что сделать сейчас: занесите хеш образца в внутренний список проверки. Не называйте любой похожий файл S7Flip без анализа хеша и поведения.

⚠️ Чем опасна ошибка в оценке угрозы

Нельзя автоматически считать S7Flip аналогом известных атак на промышленность. Доступные сведения не подтверждают такой вывод. Они также не доказывают воздействие на любой ПЛК Siemens.

Сканирование сети важно сопоставить с картой сегмента

Есть и другая ошибка. Команда может увидеть сканирование портов и сразу остановить контроллер. В АСУ ТП такое действие создаёт отдельный технологический риск. Сначала нужно оценить последствия остановки.

Сетевой сигнал может иметь несколько объяснений. Его создаёт вредоносная программа, инженерный инструмент или плановая проверка. Поэтому аналитик сопоставляет событие с заявкой, сменным заданием и технологическим окном.

Правило для операторов: подозрительный трафик фиксируют и проверяют. ПЛК не отключают автоматически. Решение принимают вместе с ответственными за технологический процесс и функциональную безопасность.

Что сделать сейчас: закрепите порядок эскалации. В нём укажите владельца процесса, администратора АСУ ТП и ответственного за безопасность.

📡 Как S7Flip ищет устройства в сети

После закрепления в автозапуске под именем aphp.exe образец собирает адреса устройств. Он проверяет диапазоны 192.168.*.*, 10.*.*.* и 172.*.*.*.

Операции записи требуют точной проверки источника

Затем программа ищет открытые порты, которые часто встречаются у промышленных устройств. Порт 102 связан с контроллерами Siemens и протоколами S7Comm или S7Comm+. Порт 502 используют устройства с Modbus TCP.

Образец также проверяет порт 44818. Этот порт часто связан с контроллерами Allen-Bradley и протоколом EtherNet/IP. Однако описанная реализация клиента для EtherNet/IP отсутствует.

Поэтому подключение к настоящему Allen-Bradley через порт 44818 не устанавливается. Сам факт такого сканирования не означает воздействие на эти контроллеры.

Что сделать сейчас: проверьте, какие узлы в ваших сегментах отвечают на порты 102 и 502. Сравните результат с утверждённой картой промышленной сети.

🛠️ Какие сетевые признаки искать

Первый признак — неизвестная Windows-станция, которая обращается к ПЛК. Особенно важны новые соединения с портом 102. Для сети Modbus отдельно отмечают обращения к порту 502.

Защита начинается с разделения сетей и прав доступа

Второй признак — массовая проверка адресов из локальных диапазонов. Инженерная станция может обращаться к множеству узлов за короткое время. Такое поведение сопоставляют с её обычной ролью.

Третий признак — активность вне технологического окна. Ночной доступ к контроллерам не всегда вредоносен. Но он требует проверки, если для станции нет планового задания.

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

неизвестный источник соединений с портом 102;
новые обращения к порту 502;
проверка большого числа адресов локальной сети;
работа вне согласованного технологического окна;
неожиданные операции чтения и записи в ПЛК;
появление новой инженерной станции в промышленном сегменте.

Что сделать сейчас: настройте пассивное наблюдение за трафиком. Сначала собирайте метаданные, не отправляя тестовые команды в ПЛК.

📊 Какие действия с данными описаны

Для S7Comm описан механизм с названием «randomize». Образец по очереди обходит блоки DB 1–10. Для каждого блока он выбирает случайное смещение от 0 до 99.

Безопасное реагирование сохраняет управление и доказательства

Затем программа читает по этому смещению четырёхбайтовое целое число. Она прибавляет случайное значение от −10 до +10. После этого образец записывает результат обратно.

Для Modbus TCP описано похожее поведение. Программа выбирает holding-регистр по случайному адресу от 0 до 99. Она читает значение, меняет его на случайную величину от −10 до +10 и записывает результат.

Такие действия особенно важно сопоставлять с журналом контроллера и проектом. Само наличие записи не объясняет, была ли команда легитимной. Нужно установить источник, время и пользователя.

Важно: эти сведения описывают заявленную логику образца. Они не подтверждают успешное изменение конкретного ПЛК. Проверку проводят по журналам, резервной копии проекта и данным сетевого мониторинга.

Что сделать сейчас: выделите операции записи в отдельные события высокого приоритета. Сохраняйте их вместе с адресом источника и точным временем.

🔐 Как разделить обнаружение и проверку ПЛК

Сетевое обнаружение отвечает на вопрос о связях. Оно показывает, кто обращается к ПЛК, когда это происходит и какой протокол используется. Такой анализ не заменяет проверку программы контроллера.

Проверка целостности отвечает на другой вопрос. Она показывает, изменились ли блоки программы, настройки и режим работы. Сравнение проводят с доверенной резервной копией проекта.

Нужно отдельно проверить изменения режима работы ПЛК. Также ищут загрузку или изменение блоков программы. Важны дата, время, инженерная станция и учётная запись.

Если подробного журнала нет, выводы остаются ограниченными. Шифрование и неполное журналирование могут скрыть часть активности. Поэтому отсутствие записи не означает отсутствие события.

Что сделать сейчас: составьте две независимые процедуры. Первая описывает анализ трафика. Вторая описывает проверку проекта и состояния ПЛК.

🛡️ Как защитить ПЛК и инженерные станции

ПЛК не должны быть доступны из корпоративной сети без необходимости. Промышленный сегмент отделяют межсетевым экраном. В правилах оставляют только нужные соединения между известными узлами.

Доступ к протоколам S7 и Modbus TCP ограничивают по адресам и ролям. Неизвестной станции не нужен прямой доступ к контроллерам. Правила пересматривают после каждого изменения схемы.

Инженерные станции защищают отдельно. На них контролируют автозапуск, учётные записи, журналы и появление новых программ. Имя aphp.exe проверяют по хешу и контексту, а не удаляют вслепую.

Удалённый доступ защищают многофакторной проверкой. Съёмные носители проходят контроль до подключения к инженерной станции. Проекты и резервные копии хранят с ограничением прав на изменение.

разделите корпоративную сеть и сеть АСУ ТП;
разрешите только необходимые соединения к ПЛК;
запретите прямой доступ неизвестных станций;
включите многофакторную защиту удалённого доступа;
контролируйте съёмные носители;
защитите резервные копии от случайного изменения.

Что сделать сейчас: выгрузите правила межсетевого экрана для промышленного сегмента. Найдите разрешения без владельца и понятной производственной причины.

🧰 Как безопасно реагировать на подозрение

Реагирование начинают с фиксации состояния. Сохраняют сетевые события, журналы станции, имя файла и его хеш. Также записывают время обнаружения и текущий режим ПЛК.

Подозрительную инженерную станцию изолируют по согласованной процедуре. Изоляция не должна разрывать критическое управление без оценки последствий. ПЛК не отключают только ради удобства расследования.

Дальше сравнивают проект с доверенной резервной копией. Проверяют блоки программы, режим работы и историю действий. При подтверждённом изменении восстановление проводят по утверждённому плану.

В процесс включают ответственных за функциональную безопасность. Они оценивают влияние каждого шага на технологию. После восстановления сеть и станции проверяют повторно.

зафиксируйте состояние сети и ПЛК;
сохраните журналы и хеш подозрительного файла;
оцените риск изоляции станции и остановки процесса;
изолируйте станцию безопасным способом;
сравните проект ПЛК с доверенной копией;
восстановите систему по утверждённому плану;
проверьте отсутствие повторных обращений.

Что сделать сейчас: проведите настольную тренировку по этому сценарию. Отдельно проверьте, кто принимает решение об изоляции и восстановлении.

✅ Чек-лист для операторов и администраторов

Оператору важно замечать изменения процесса и режима ПЛК. Он также фиксирует необычное время работ и неизвестные сообщения инженерной станции. Самостоятельно менять программу контроллера нельзя.

Администратор проверяет сетевые связи и журналы Windows. Он ищет автозапуск с именем aphp.exe, новые обращения к портам 102 и 502, а также массовый перебор локальных адресов.

Ответственный за АСУ ТП проверяет проект и резервные копии. Он сопоставляет изменения с заявками и технологическим окном. При расхождении запускается утверждённая процедура инцидента.

Есть ли неизвестная станция в промышленном сегменте?
Обращается ли она к ПЛК Siemens через порт 102?
Есть ли соединения с устройствами Modbus TCP через порт 502?
Происходит ли сканирование локальных диапазонов?
Есть ли операции записи вне технологического окна?
Изменился ли режим работы ПЛК?
Совпадает ли проект с доверенной резервной копией?
Сохранены ли журналы и сведения о подозрительном файле?

Итог: S7Flip нельзя подтверждать только по имени файла или одному сетевому событию. Надёжный вывод требует связать хеш, поведение Windows, сетевые обращения и состояние проекта ПЛК.

Что сделать сейчас: добавьте этот чек-лист в сменную документацию. Обновляйте его после каждого изменения архитектуры АСУ ТП.

📚 Читайте также

📖 Термины

Ics Security · Plc · Scada · Сетевой трафик