Аварийная ситуация: как противостоять атакующему системы ПАЗ вредоносу Trisis

Автор: Андрей Прошин, руководитель направления по развитию бизнеса услуг и сервисов SOC компании «Ростелеком-Солар».

Летом 2017 года на нефтеперерабатывающем заводе Petro Rabigh в Саудовской Аравии произошли несколько сбоев в системе противоаварийной защиты (ПАЗ). Все началось с того, что в июне отключился один из контроллеров ПАЗ. Так как системы АСУ/SCADA показывали штатный режим работы технологического процесса, служба эксплуатации решила, что сбой связан с неисправностью самого контроллера. Его отключили и передали на проверку производителю. Тот, проведя тестирование, не обнаружил ничего подозрительного, рекомендовал установить контроллер на место.

Но в августе сбой повторился. В этот раз уже были задействованы несколько контроллеров ПАЗ, которые работали в разных сегментах промышленной сети на разных производственных установках. Производитель оборудования и ИТ-специалисты Petro Rabigh решили провести более детальный анализ. Они проверили в том числе сетевое окружение, автоматизированные рабочие места (АРМ) и серверы, которые принимают участие в работе системы. В итоге были обнаружены неавторизованные RDP-соединения с инженерной станцией. Стало очевидно, что к расследованию надо подключать экспертов по кибербезопасности.

Нефтеперерабатывающий завод Petro Rabigh, Саудовская Аравия

Это была первая публично описанная атака вредоноса Trisis (он же Triton), нацеленная именно на системы противоаварийной защиты. Стало очевидно, что такое воздействие на систему в принципе возможно и что это может привести к серьезной аварии.

Потенциально, если бы киберпреступникам удалось изменить параметры блокировок контроллера ПАЗ, они могли бы спровоцировать выброс ядовитых газов или даже их детонацию. К счастью, ничего подобного не произошло и в результате инцидента контроллеры просто отключились, что вызвало безопасную остановку технологического процесса.

Также комбинация атак на ПАЗ и саму распределенную АСУ ТП может лишить автоматику и персонал возможности оперативно реагировать на нештатную ситуацию на производстве. Давайте разберемся подробнее, как же происходит подобная атака.

Как работает противоаварийная защита

Системы ПАЗ являются основным элементом защиты от аварий и устанавливаются на опасных производствах (часто объектах КИИ и ЗОКИИ), где нештатная ситуация может привести к человеческим жертвам и огромным материальным потерям. Существует три основных способа интеграции ПАЗ в АСУ ТП.

Первый – это прямая интеграция. Способ заключается в том, что локальная сеть системы ПАЗ напрямую интегрируется в сеть системы управления по Ethernet:

В этом случае на границе зон всегда используется межсетевой экран (МСЭ). Он должен предотвратить несанкционированные изменения уставок ПАЗ через систему управления, если последняя будет скомпрометирована злоумышленниками. Если межсетевой экран не предусмотрен, то от такого сценария лучше отказаться.

При этом администрированию МСЭ должно уделяться особенное внимание. В частности, надо следить за обновлением прошивки и корректной настройкой правил, отслеживать все попытки изменения конфигурации. Плюсом будет наличие у межсетевого экрана способности «понимать» протокол общения между системой ПАЗ и системой управления. Для этого должен быть настроен функционал глубокого анализа пакетов (deep packet inspection, DPI), который будет блокировать запрещенные команды, например, на запись уставок в контроллер ПАЗ. Без DPI межсетевой экран будет просто видеть взаимодействие между хостом А и хостом Б по конкретному порту, что малоинформативно.

Второй способ предполагает интеграцию через промежуточное оборудование. В этом случае системы ПАЗ подключаются по Ethernet через АСУ с помощью коммуникационных модулей, выделенных портов или специальных шлюзов:

Такая архитектура является более безопасной по сравнению с прямой интеграцией, ведь злоумышленнику нужно сначала получить полный доступ к контроллерам системы управления, и только после этого он сможет добраться до ПАЗ.

Если коммуникационные модули работают в прозрачном режиме и предоставляют прямой доступ из сети управления к нижестоящим устройствам, то необходимы дополнительные меры защиты в виде межсетевого экрана. Но без него можно обойтись, если модули контроллеров сети управления или контроллеры системы ПАЗ имеют встроенный файрвол.

Наиболее безопасный способ интеграции ПАЗ – подключение по последовательным интерфейсам (чаще всего по RS-485):

Последовательный интерфейс обеспечивает передачу данных по единственной линии (то есть это COM-порты и выделенный кабель). При таком подключении большую часть сетевых атак, которые могут произойти в Ethernet, реализовать невозможно. В этом случае нет необходимости в дополнительных средствах защиты, так как само по себе использование последовательных интерфейсов значительно снижает риск успешной атаки на ПАЗ (даже при взломанной системе управления).

Также для максимальной защиты контроллеры ПАЗ должны иметь функцию отключения записи уставок системы через последовательный интерфейс. В противном случае у атакующих остается легитимная возможность изменения этих уставок через систему управления. Если все сделано корректно, и данная функция на контроллере активирована, то остаются только теоретические шансы на взлом системы ПАЗ по сети. Но пока неизвестно ни об одной успешной атаке, проведенной по такому сценарию.

Судя по доступной информации, на НПЗ Petro Rabigh использовалась первая схема интеграции. При этом базовые меры защиты – сегментация, разграничение прав, политика безопасности на межсетевых экрана – были выполнены не корректно. Все это позволило хакерам реализовать успешную атаку.

Как проходила атака

Trisis (как и Industroyer, о котором мы уже рассказывали ) – это специализированное вредоносное ПО, созданное для взаимодействия с контроллерами определенного типа (Triconex компании Schneider Electric) в системах ПАЗ. Отличительной особенностью является то, что Trisis, используя 0-day уязвимость в программируемом логическом контроллере (ПЛК), может напрямую взаимодействовать с его памятью, включая запись и исполнение своего кода.

Прежде чем запустить само ВПО, злоумышленники проделали сложную подготовительную работу. Они проникли в корпоративную ИТ-инфраструктуру, закрепились в ней, повысили свои привилегии и получили доступ к промышленной сети. Основные этапы атаки на АСУ ТП подробно описывает модель ICS Kill Chain, которая разобрана в работе “The Industrial Control System Cyber Kill Chain”. Фактически атака состоит из двух этапов.

Этап 1. Компрометация ИТ-инфраструктуры, проникновение в изолированную OT-инфраструктуру и закрепление в ней. В большинстве известных атак на промышленные сети проникновение происходит через корпоративную сеть, в которой злоумышленники находят узлы с доступом к OT. В случае с Trisis это были АРМ инженера АСУ и инженера ПАЗ.

Этап 2. Исследование промышленной сети, разработка и тестирование специализированного ВПО, попытка взаимодействия с промышленным оборудованием. В кейсе с Petro Rabigh именно на этом этапе удалось обнаружить вторжение хакеров, исследовать ВПО и остановить атаку.

Действия злоумышленников выглядят так:

При этом само ВПО Trisis использовалось только для взаимодействия с ПАЗ контроллерами, то есть на финальной стадии атаки.

А это основные этапы атаки:

Ее результатом стало нарушения состояния защищенности системы (T0880 - Loss of Safety), что, к счастью, не привело к аварии.

Злоумышленники использовали различные техники и инструменты, которые можно разделить на три группы:

• Общие техники и инструменты, применяемые для проникновения и распространения внутри корпоративных сетей (это Mimikatz, PsExec, Webshell, Nmap и т.д.);
• Общие техники и специализированные инструменты. Они были разработаны для того, чтобы уменьшить вероятность детектирования и блокировки стандартными средствами защиты, например, антивирусом (это SecHack, NetExec и целый набор бэкдоров, собранных на основе OpenSSH, CryptCat и других библиотек);
• Специализированное ВПО для использования в системах ПАЗ, установленных на данном заводе (это Trisis).

Общие техники и инструменты

На основе опубликованных данных и подробного отчета, выпущенного командой FireEye Mandiant, непосредственно принимавшей участие в расследовании инцидента, можно выделить следующие общие техники и инструменты, применяемые хакерами:

1) Изменение легитимных задач в планировщике

Установленные backdoor были добавлены в планировщик задач для сохранения, перезапуска себя в системе и сокрытия своих действий за счет маскировки под легитимные процессы операционной системы. Например, backdoor на основе cryptcat маскировался под легитимный процесс OC ProgramDataUpdater. А backdoor на основе PLINK – под NetworkAccessProtectionUpdateDB.

2) Использование Domain Name Generator Algorithm (DGA) для взаимодействия с C&C-сервером

Для сохранения постоянной связи с установленными backdoor в ИТ- и OT-инфраструктуре хакеры использовали частую генерацию и смену доменных имен C&C-серверов (DGA).

В частности, Cryptcat backdoor при запуске инициировал DNS-запрос вида upd-%d.mooo.com и %d-srv.net, где %d - текущая дата. Затем backdoor устанавливал зашифрованное соединение с полученным IP-адресом.

3) Использование нестандартных DNS-серверов

Для корректной работы DGA вредонос использовал DNS-сервер 8.8.8.8, который отличался от стандартного DNS-сервера, используемого в корпоративной и изолированной OT-сети.

4) Кража учетных записей: Mimikatz

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

5) Кража учетных данных: извлечение NTDS.dit

Для получения учетных записей злоумышленники копировали файл NTDS.dit с контроллера домена (база данных Active Directory, в которой содержатся все объекты домена).

6) Сетевое сканирование NMAP и тестирование iPerf3

Для исследования корпоративной и промышленной сети использовались стандартные утилиты NMAP и IPERF3. Это сканеры для определения запущенных сервисов, протоколов, доступных хостов, пропускной способности и прочих сетевых характеристик.

7) Использование утилит Windows: adexplorer, shareenum, psGetSid и т.д.

Для исследования доменной инфраструктуры использовались стандартные утилиты Windows, запускаемые на контроллерах домена.

8) Использование команд Windows: whoami, netstat, net, ping, quser и т.д.

Для исследования на хосте использовались стандартные команды Windows, которые обычно запускаются администратором.

9) Использование RDP для интерактивных удаленных сессий

Злоумышленники активно использовали RDP-сессии для удаленного доступа на скомпрометированные Windows хосты и выполняли стандартные команды, доступные администраторам. При этом доступ через RDP был как прямым (между хостами внутри сети), так и туннелировался в сторону C&C-серверов.

10) Использование webshell для OWA-серверов с целью кражи учетных данных

Во время установки webshell на сервер Outlook Exchange, злоумышленники также изменяли стандартные flogon.js и logoff.aspx файлы. Это позволяло получать актуальные учетные записи сотрудников завода.

11) Действия в промышленной сети выполнялись в нерабочее время

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

12) Маскировка ВПО под легитимные процессы и приложения

Чтобы сделать исполняемые файлы и библиотеки похожими на легитимные, хакеры их переименовывали. К примеру, сам вредонос trisis был назван trilog.exe (так называется одно из легитимных приложений Schneider Electric).

13) Удаление следов работы после выполнения части задач

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

Общие техники и специализированные инструменты

Хакеры использовали ряд инструментов собственной разработки, которые были созданы на основе публикуемых библиотек и модулей. Это помогало им избегать детектирования и блокировки классическими сигнатурными способами, сохраняя при этом полную функциональность ВПО. Использовались следующие инструменты:

1)SecHack (утилита для получения учетных данных из памяти процесса lsass.exe для 32- и 64-битных ОС Windows)

Утилита работает аналогично Mimikatz и должна быть запущена в привилегированном режиме. Исполняемый файл был переименован в KB77846376.exe (как обновление для ОС Windows).

Утилита запрашивает следующие пакеты аутентификации:

• msv1_0
• kerberos
• wdigest
• tspkg

SecHack может собирать и дополнительную информацию. Так, команда «cert» собирает данные об установленных сертификатах (контейнер, криптопровайдер, размер ключа, pfx-файл и т.д.). А команда «info» – информацию о самом хосте (версия ОС, архитектура процессора, UAC флаги и т.д.)

2) NetExec (утилита для удаленного выполнения команд на хостах Windows)

Утилита запускается как процесс netexec.exe и умеет:

• осуществлять удаленный запуск исполняемых файлов;
• загружать файлы с локальной машины на удаленный хост;
• открывать удаленную командную строку;
• открывать удаленную сессию powershell;
• создавать свою копию на удаленной машине для дальнейшего распространения.

3) Бэкдор, основанный на CryptCat

Он позволяет создавать зашифрованный туннель для передачи команд на управление. Исполняемый файл - compattelprerunner.exe. При запуске он использовал генератор доменных имен для определения актуального IP-адреса управляющего C&C-сервера. В качестве основного параметра использовалась текущая дата, а в качестве DNS-сервера – 8.8.8.8. Туннель создается на 443 порт C&C-сервера.

4) Бэкдор, основанный на PLINK

Измененный PLINK (Putty), позволяет создавать reverse-туннель между RDP-сервером и C&C-сервером атакующего. Бэкдор запускается как napupdatedb.exe, который создает обратный туннель на порт 3389 (RDP) локального хоста и передает трафик через TCP 8531.

5) Бэкдор, основанный на OpenSSH

Позволяет получать удаленный доступ к скомпрометированному узлу и обмениваться файлами. Запускается как spl32.exe и является модифицированной версией sshd.exe дистрибутива OpenSSH. Когда запускается из командной строки, может «слушать» TCP-порт 50501. Отличается от стандартного sshd.exe наличием фиксированной конфигурации и трех установленных крипто-ключей. Бэкдор также содержит в себе winsat.exe, неизмененную версию sftp-server.exe (также часть OpenSSH). WinSAT запускается в случае, когда spl32.exe принимает входящий SFTP-запрос.

6) Бэкдор, основанный на Bitvise

Клиент Bitvise часто используется для передачи файлов и может достигать хороших скоростей при передаче данных по протоколу SFTP. Также он содержит возможность обфускации, что затрудняет детектирование использования SSH.

Специализированное ВПО для атаки на контроллеры ПАЗ

Сам вредонос Trisis является завершающим этапом атаки. Все аналитики подчеркивают, что после того, как злоумышленники попали на АРМ инженера ПАЗ и остались незамеченными, у них было достаточно времени для разработки, тестирования и отладки специализированного ВПО.

В итоге им удалось:

• разобрать проприетарный протокол TriStation, используемый между приложением Trilog (на АРМ инженера ПАЗ) и контроллером Triconex;
• реализовать работу TriStation с помощью Python;
• найти и проэксплуатировать 0-day-уязвимость на ПЛК Triconex, и в результате загрузить собственный код непосредственно в память контроллера.

Схематично работа Trisis выглядит так:

Вредонос Trisis — это приложение, написанное на Python, и скомпилированное с помощью Py2EXE. Помимо самого ВПО, дистрибутив содержит набор стандартных и описывающих работу протокола TriStation библиотек. На момент атаки TriStation не поддерживал механизм аутентификации, поэтому Trisis мог самостоятельно подключиться к уязвимому устройству и загрузить вредоносный код непосредственно в память ПЛК.

Также Trisis может самостоятельного искать уязвимые контроллеры (через сканирование сети по порту UDP 1502). Однако во время атаки эта функция не использовалась, ведь ранее злоумышленники уже получили список интересующих их IP-адресов.

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

Важное дополнение: на контроллерах SE Triconex был включен режим “PROGRAM MODE” с помощью аппаратного переключателя, что позволяло удаленно использовать TriStation протокол для взаимодействия с контроллером. Режим “RUN MODE” не позволил бы провести атаку описанным образом. К сожалению, “PROGRAM MODE” часто оставляют включенным для возможности быстрого и удобного подключения к контроллеру инженерным персоналом, но атака Trisis показала насколько эта практика небезопасна.

Как защитить АСУ ТП

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

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

На межсетевом экране нужно:

• контролировать все сетевые соединения на предмет отклонения от обычного профиля трафика (по времени и source/destination адресам);
• контролировать версию прошивки и попытки обновления программного обеспечения;
• определять попытки несанкционированного доступа к МСЭ (например, подбор логинов и паролей);
• определять изменения конфигурации МСЭ и особенно политики безопасности.

На всех АРМ и серверах нужно:

• составить типовой профиль работы системы, то есть разрешенные процессы и сетевые соединения;
• использовать расширенные возможности мониторинга событий на уровне операционной системы. Это поможет обнаружить запуск удаленных команд и хакерских утилит на хосте, взаимодействия с реестром ОС Windows, запуск и загрузку неподписанных библиотек (DLL). Помимо Sysmon применимы и все существующие варианты контроля операционной системы и приложений, включая антивирусы, промышленные EDR и т.д.

На уровне сети рекомендуется использовать специализированные системы обнаружения вторжений (СОВ), которые умеют разбирать трафик промышленных протоколов. Также необходимо реализовать как минимум следующие сценарии детектирования в SIEM:

• обнаружение событий сканирования сети;
• отправка нелегитимных команд на промышленные контроллеры;
• использование нелегитимных или нетипичных DNS-серверов;
• анализ DNS-трафика на предмет резолва DGA-доменов;
• использование нетипичных сетевых протоколов в сети (отклонение от типового профиля трафика), включая RDP, ssh, scp и т.д.

И, наконец, на уровне ПЛК нужно:

• контролировать версии ПО и попытки обновления;
• фиксировать ошибки аутентификации или успешные попытки в нетипичное время;
• контролировать запуск и остановку дополнительных сервисов на ПЛК (например, FTP-протокола);
• контролировать отправку нелегитимных команд на управление (включая запуск или остановку самого контроллера).

Считается, что обнаружение атаки на уровне ПЛК говорит о том, что киберпреступники уже находятся на финальном шаге и ИТ- и ИБ-специалисты просто не успеют среагировать и предотвратить последствия. Однако пример Trisis говорит о том, что взаимодействие с контроллерами также происходит в момент исследования сети и попытки загрузки и отладки ВПО перед “боевым” запуском. На этот процесс у злоумышленников уходит больше 6 месяцев. За это время ИБ-специалисты могут обнаружить аномальную активность и нейтрализовать инцидент.

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

Так согласно приказу ФСБ России №282, значимые объекты КИИ должны передавать данные о своих компьютерных инцидентах в НКЦКИ в течение 3х часов с момента обнаружения. Это позволяет оперативно актуализировать базу возможных угроз. А с технологической точки зрения большую роль играют центры мониторинга и реагирования на кибератаки (SOC), которые позволяют видеть и контролировать все возможные инциденты. Необходимо подключить к SIEM-системе все источники событий в промышленной сети: ПЛК, сетевое оборудование, средства защиты информации, АРМ и серверы. Помимо этого, к мониторингу важно подключить и корпоративную сеть, так как многие атаки могут быть обнаружены еще до момента проникновения хакера в промышленный сегмент.