Статья VNC без аутентификации в промышленных системах: от разведки Shodan до контроля HMI

На оценке защищённости водоочистных сооружений в прошлом году нашли три VNC-сервера на портах 5900–5902. Ко всем трём - подключение без пароля. На экране HMI-панель Wonderware InTouch с управлением насосными станциями. Между обнаружением и полным доступом к физическому процессу прошло 40 секунд: 20 на nmap -p 5900-5910 --script vnc-info и 20 на vncviewer. Сорок секунд - и ты управляешь насосами.

По данным исследований, в интернете обнаруживаются сотни VNC-серверов с отключённой аутентификацией, дающих прямой доступ к ICS/OT-панелям. Общее число VNC без аутентификации может составлять десятки тысяч. Это не теория - хактивистские группировки публиковали видео компрометации промышленных объектов и продавали доступ к SCADA именно через открытые VNC.

Бизнес-логика атаки: зачем открытый VNC-сервер в OT-сети​

Открытый VNC в промышленном сегменте - не просто удалённый рабочий стол. За ним стоит HMI (Human-Machine Interface), через который оператор управляет физическим процессом: давление в трубопроводе, скорость конвейера, состояние реле на подстанции. Для атакующего это три вещи.

Первое - initial access без эксплойтов. Не нужен 0-day, не нужен фишинг, не нужна цепочка уязвимостей. Одного vncviewer хватает для получения пульта управления. По MITRE ATT&CK это External Remote Services (T1133, Initial Access) в чистом виде.

Второе - операционный импакт за минуты. Изменение уставки давления, отключение насоса, перевод привода в аварийный режим - всё через GUI, мышкой. В отличие от ransomware, который требует lateral movement и закрепления, здесь путь от initial access до физического воздействия - один шаг.

Третье - низкий порог входа. HMI проектируется для операторов без инженерного образования. Атакующему достаточно кликать по кнопкам. Знание промышленных протоколов, программирования ПЛК или ladder logic не нужно.

По данным IBM X-Force Threat Intelligence Index 2025, 70% всех реагирований X-Force в 2024 году затрагивали критическую инфраструктуру. Среднее время между публикацией CVE и устранением - 29 месяцев. Но для VNC без аутентификации CVE нет - это ошибка конфигурации, которая живёт годами.

Место VNC в kill chain ICS-атаки​

[Применимо: внешний пентест, legacy OT-инфраструктура без сетевой сегментации]

Цепочка атаки через открытый VNC в промышленных системах:

1. Reconnaissance - поиск VNC-серверов через Shodan/Censys (T1596.005, Scan Databases) или активное сканирование целевой сети (T1595.002, Vulnerability Scanning)
2. Initial Access - подключение к VNC без аутентификации (T1133, External Remote Services) или с дефолтными учётными данными (T1078.001, Default Accounts)
3. Collection - снятие скриншотов HMI-панелей (T1113, Screen Capture), изучение мнемосхемы процесса, считывание параметров
4. Lateral Movement - переход на другие системы через VNC (T1021.005, VNC), обнаружение инженерных станций с проектами ПЛК
5. Impact - остановка сервисов (T1489, Service Stop), модификация уставок, вывод оборудования из штатного режима

Ключевая особенность: шаги 2–5 выполняются через один протокол RFB. Нет смены инструментов, нет доставки payload, нет C2-канала. Для сетевых IDS/IPS это выглядит как легитимный VNC-трафик. Если VNC разрешён в сети - детектировать атаку стандартными средствами почти невозможно.

Когда цепочка НЕ работает:

• VNC-сервер за VPN/jump host с MFA - прямое подключение из интернета невозможно
• Аутентификация включена, пароль нетривиальный - потребуется brute force (T1110.001, Password Guessing), который медленен и генерирует алерты
• Сеть сегментирована, VNC доступен только из DMZ - lateral movement в OT-сегмент потребует дополнительного pivoting через скомпрометированную инженерную станцию

Разведка: SCADA уязвимости VNC и методы обнаружения открытых серверов​

Shodan ICS: поиск уязвимостей пассивным методом​

[Применимо: внешний пентест, фаза reconnaissance]

По данным Kaspersky ICS CERT (2019), в Shodan обнаружено более 600 000 VNC-серверов. Точное текущее число зависит от методологии и момента сканирования, но значительная часть работает без аутентификации.

Запросы Shodan для поиска открытого VNC-сервера в ICS-среде:

• port:5900 "RFB" "Authentication: (1) None" - VNC без аутентификации с явным указанием auth type
• port:5900 "RFB" org:"target_org" - таргетированный поиск по конкретной организации
• port:5900 screenshot.label:ics - серверы с автоскриншотами, классифицированными как ICS

В Censys аналогичный запрос: services.port=5900 AND services.vnc.result.auth_enabled=false.

Shodan автоматически снимает скриншоты VNC-серверов без аутентификации. Если на снимке видна мнемосхема технологического процесса (трубопроводы, насосы, уровни в ёмкостях) - с высокой вероятностью это реальная SCADA: Siemens WinCC, Wonderware InTouch, Ignition by Inductive Automation или AVEVA Edge.

Ограничение: пассивная разведка показывает только серверы, проиндексированные сканерами Shodan/Censys. VNC на нестандартных портах (выше 5910) или за NAT не попадёт в результаты. Большинство обнаруженных серверов расположены в Китае и США, и значительная часть может оказаться honeypots или провайдерскими хостами. Верификация каждого результата обязательна.

OT пентест методология: активное сканирование Nmap​

[Применимо: внутренний пентест OT-сегмента, санкционированная оценка защищённости]

Требования к окружению:

• ОС: Kali Linux 2024+, Parrot OS, или любой дистрибутив с Nmap 7.90+ (последний стабильный релиз 7.95, апрель 2024, проект активно поддерживается)
• RAM: от 2 ГБ для сканирования /24, от 8 ГБ для /16
• Сеть: доступ к целевому OT-сегменту через VPN, jump host или SPAN-порт
• Критично для OT: скорость сканирования согласуется с инженерами АСУ ТП. Агрессивные шаблоны -T4/-T5 роняют legacy-оборудование. Использовать -T2 с ограничением --max-rate 50

# Обнаружение VNC в подсети OT с безопасной скоростью
nmap -sV -p 5900-5910 --script vnc-info -T2 --max-rate 50 192.168.10.0/24

NSE-скрипт vnc-info извлекает версию протокола RFB, тип аутентификации и desktop name. Если в выводе Authentication: (1) None - сервер принимает подключения без пароля. Поле desktop name часто содержит имя хоста или название SCADA-проекта - можно понять назначение сервера ещё до подключения.

Для проверки стойкости VNC-пароля (только при явном разрешении заказчика, задокументированном в scope):

# Brute force VNC - T1110.001, Password Guessing
nmap -p 5900 --script vnc-brute --script-args brute.delay=2 192.168.10.50

Параметр brute.delay=2 критичен для промышленной среды. Без задержки серверы на базе TightVNC 1.3.x и UltraVNC на Windows XP Embedded стабильно уходят в отказ. Из практики: после 50 параллельных попыток пришлось ждать 15 минут перезагрузки контроллера. В промышленной сети это не "ой, упало" - это остановка процесса.

Эксплуатация: подключение к VNC и удалённый доступ SCADA без пароля​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Сервер SCADA (Windows Server с WinCC или AVEVA) - полный доступ к ОС, lateral movement через RDP/SMB, доступ к SQL-базе с технологическими данными и историей процесса.

Интересная деталь: по данным исследований, подавляющее большинство таких инсталляций устанавливается персоналом предприятий или подрядчиками. Именно "подрядные" инсталляции чаще всего оказываются без аутентификации - настроили для быстрого доступа во время пусконаладки и забыли.

В 2019 году Kaspersky ICS CERT обнаружил множество уязвимостей порчи памяти в реализациях VNC (LibVNC, UltraVNC, TightVNC, TurboVNC), часть из которых приводила к удалённому исполнению кода. При этом серверная часть VNC на Windows в режиме сервиса получает привилегии SYSTEM. Для сравнения: BlueKeep (CVE-2019-0708, CVSS 9.8, CWE-416 Use After Free) - принципиально иная по природе угроза (memory-corruption RCE в RDP, а не ошибка конфигурации), но аналогичная по импакту: удалённое исполнение кода без аутентификации с привилегиями SYSTEM. Публичный Metasploit-модуль для BlueKeep вышел в сентябре 2019, первые in-the-wild кампании (криптомайнеры) зафиксированы в ноябре 2019; уязвимость внесена в CISA KEV 2021-11-03.

Ограничения при эксплуатации:

• Если VNC-сервер в режиме view-only - управление невозможно, но разведка (скриншоты HMI, чтение параметров) остаётся доступной
• На некоторых HMI-панелях включена блокировка клавиатуры/мыши при подключении второго VNC-клиента - оператор на месте заметит попытку
• Запись VNC-сессий (session logging) на стороне сервера поддерживается UltraVNC и RealVNC Enterprise, но в OT-средах эту функцию, как правило, не включают даже при наличии технической возможности

ICS security: чем OT-угрозы VNC отличаются от IT​

В IT-сети открытый VNC - инцидент уровня "скомпрометирован один хост". В OT-сети - "скомпрометирован физический процесс". Разница принципиальная:

Критерий	IT	OT
Последствия	Кража данных, malware	Остановка производства, физическое повреждение, угроза жизни
Патчинг VNC	Patch Tuesday, минуты	Остановка процесса, согласование с вендором, ревалидация. Средний срок - 29 месяцев (IBM X-Force)
Сегментация	VLAN, микросегментация, Zero Trust	Flat-сеть, общий broadcast-домен для HMI, ПЛК и инженерных станций
Аутентификация	AD + MFA + SSO	Общий пароль на смену или полное отсутствие
Endpoint protection	EDR на каждом хосте	CrowdStrike Falcon, SentinelOne, Elastic 8.x+ не поддерживают legacy-ОС (Windows XP Embedded, Win7 Embedded) на HMI-панелях

Промышленные протоколы усугубляют картину. Modbus TCP не имеет аутентификации - любой хост в сети отправляет команду FC5 (Write Single Coil) или FC6 (Write Single Register) на ПЛК, минуя HMI. Функции FC1 (Read Coils), FC3 (Read Holding Registers), FC16 (Write Multiple Registers) тоже доступны без ограничений. DNP3 в большинстве развёрнутых систем работает без Secure Authentication (SA). Если атакующий через VNC попадает на инженерную станцию в одном сегменте с контроллерами - он взаимодействует с ПЛК напрямую через эти протоколы, минуя даже минимальные ограничения SCADA-сервера.

Реальные инциденты подтверждают вектор. Атака TRITON (2017) на Schneider Electric Triconex использовала инженерную станцию для модификации Safety Instrumented System. Industroyer/CrashOverride (2016) отключил часть энергосети Украины через промышленные протоколы. В обоих случаях удалённый доступ к инженерным станциям был одним из этапов kill chain. В последние годы хактивистские группировки демонстрируют компрометацию SCADA через VNC, публикуя видео и продавая доступ. Появляются ботнеты, нацеленные на открытые VNC-серверы, часть которых, предположительно, находится в промышленных сетях.

Обнаружение открытого VNC в OT-сети: ICS/OT точки входа и детекция​

Детектировать VNC-трафик в OT-сети можно на нескольких уровнях.

Сетевой уровень. Мониторинг трафика на портах 5900–5910. Если VNC не является легитимным средством для конкретного сегмента - любое соединение на эти порты генерирует алерт. Правило для Suricata/Snort:

alert tcp $OT_NET 5900:5910 -> any any (msg:"VNC RFB banner from OT segment"; flow:established,from_server; content:"RFB 0"; offset:0; depth:5; sid:1000001; rev:3;)

Сигнатура ловит начало RFB-хендшейка - строку RFB 0 в первых пяти байтах ответа сервера (по RFC 6143 сервер первым отправляет ProtocolVersion). Для SIEM (MaxPatrol SIEM, KUMA, Splunk) - правило корреляции по NetFlow/IPFIX: source из IT-сегмента, destination в OT-сегменте, dst_port 5900–5910 - алерт при любом совпадении.

Уровень хоста. Если на HMI или инженерной станции стоит агент мониторинга (что редкость - и это сама по себе проблема), фиксировать запуск процессов winvnc.exe, tvnserver.exe, vncserver с параметрами, указывающими на отключённую аутентификацию (-SecurityTypes None, конфигурация AllowLoopback=1). Для Windows - правило аудита на создание процесса (Event ID 4688) с фильтром по имени образа.

Ограничения детекции в OT:

• Зеркалирование трафика на промышленных коммутаторах (Hirschmann, Moxa, Cisco IE) - не все модели поддерживают полноценный port mirror без деградации production-трафика
• Passive-мониторинг (Nozomi Networks, Claroty, Dragos) обнаруживает VNC-сессии, но не всегда определяет тип аутентификации - для этого нужен deep packet inspection первых пакетов RFB-хендшейка
• Легитимный VNC от вендоров и подрядчиков через VPN визуально неотличим от атаки - без baseline нормального поведения false positive гарантированы
• CrowdStrike Falcon, SentinelOne не устанавливаются на legacy-ОС HMI-панелей - Windows XP Embedded и Windows 7 Embedded вне поддержки

Чеклист: защита промышленной кибербезопасности от VNC-угроз​

Формат готов к передаче инженерам АСУ ТП:

1. Инвентаризация. Просканировать OT-сегмент на порты 5900–5910: nmap -sV -p 5900-5910 <subnet>. Составить реестр VNC-серверов с указанием типа аутентификации и назначения хоста
2. Отключить VNC без производственной необходимости. Если удалённый доступ к HMI не нужен для эксплуатации - деактивировать службу. UltraVNC: net stop uvnc_service; TightVNC: sc stop tvnserver
3. Включить аутентификацию. Если VNC необходим: UltraVNC - раздел Security, предпочтительно MS-Logon II или интеграция с AD; при использовании классической VNC-аутентификации (Type 2) учитывать, что DES challenge-response использует только первые 8 байт пароля как ключ; TightVNC - через реестр HKLM\SOFTWARE\TightVNC\Server
4. Закрыть порты на firewall. Запретить входящий трафик на 5900–5910 из всех сегментов кроме jump host. Windows: netsh advfirewall firewall add rule name="Block VNC" dir=in action=block protocol=tcp localport=5900-5910
5. Организовать доступ через jump host. Единая точка входа с MFA, журналированием и записью сессий. VNC-сервер принимает подключения только с IP jump host
6. Настроить мониторинг. Правило в SIEM/IDS на любое VNC-соединение в OT-сегменте не с whitelisted-адресов
7. Согласовать с вендором. Получить письменное подтверждение, что включение аутентификации VNC не нарушает гарантийные обязательства и не снимает поддержку ПО АСУ ТП
8. Регулярный аудит. Повторять сканирование ежеквартально. После каждых пусконаладочных работ подрядчиков - внеплановое сканирование: подрядчики открывают VNC обратно для "удобства" с завидной регулярностью

За три года работы с OT-сетями вижу одну и ту же картину: инженеры АСУ ТП знают про открытый VNC на своих HMI, но осознанно не закрывают. Аргумент один - "вендор сказал не трогать". У Schneider Electric, Siemens, AVEVA есть legacy-инсталляции, где VNC без пароля прописан в документации как "рекомендуемая конфигурация для удалённой поддержки". Пока вендор не отзовёт рекомендацию, ни один главный инженер не возьмёт на себя ответственность за изменение настройки, которая может нарушить гарантию.

Проблема не техническая. Включить аутентификацию на VNC - пять минут работы. Проблема организационная: разрыв между IT security и инженерами эксплуатации, которые живут в параллельных мирах. Одни считают severity по CVSS, другие - по времени простоя конвейера. Пока разрыв существует, сотни открытых VNC-серверов с прямым доступом к ICS-панелям - не аномалия, а стабильное состояние отрасли.

Я убеждён: в ближайшие два года мы увидим резонансный инцидент с физическими последствиями, где вектором входа будет именно open VNC. Все предпосылки на месте - хактивистские группировки уже продают такой доступ, появляются ботнеты, нацеленные на открытые VNC, а средний срок устранения уязвимости в OT остаётся на уровне 29 месяцев. Единственное, что пока сдерживает массовые атаки - отсутствие у большинства группировок понимания конкретных технологических процессов за экраном HMI. Но порог входа снижается с каждой утёкшей инструкцией, а ICS-специфичных навыков для нажатия кнопки "Стоп" не требуется.