SCADA-сервер в бот-сети: инсайдер на стороне подрядчика атакует объект электроэнергетики

Общая информация

В ходе проведения аудита информационной безопасности АСУ ТП на газопоршневой электростанции (ГПС) промышленного предприятия, на одном из серверов были обнаружены неизвестные скрипты. Впоследствии эти скрипты были идентифицированы как вредоносное ПО.

Расследование инцидента показало, что скрипты были размещены на сервере в марте 2022 года инженером украинской подрядной организации с использованием инструмента удаленного администрирования (RAT) AnyDesk. Этот инструмент был установлен сотрудниками подрядной организации за несколько лет до инцидента, на этапе пусконаладки и ввода электростанции в эксплуатацию.

Обнаруженное на сервере вредоносное ПО представляет собой bash-скрипт, который использовался для проведения DDoS-атак на сайты средств массовой информации, промышленных предприятий, банков, объектов транспортной инфраструктуры, а также государственных органов Российской Федерации и Республики Беларусь.

После того как злоумышленник понял, что на скомпрометированном сервере начаты мероприятия по реагированию на инцидент, он подключился к нему и попытался удалить файлы логов AnyDesk, а затем открыл специализированное программное обеспечение для управления SCADA-сервером.

Служба безопасности предприятия приняла решение немедленно физически отключить скомпрометированный сервер от сети. В результате осталось неизвестным, что именно хотел сделать злоумышленник со SCADA-сервером.

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

Для получения более подробной информации обращайтесь по адресу: ics-cert@kaspersky.com.

Обнаружение инцидента

В ходе аудита информационной безопасности систем управления технологическими процессами на газопоршневой электростанции (ГПС) на одном из SCADA-серверов были обнаружены неизвестные bash-скрипты. Поскольку изменения программного обеспечения, установленного на SCADA-сервере, происходят крайне редко, неизвестные скрипты привлекли внимание специалистов.

Анализ скриптов показал, что они являются компонентами примитивного вредоносного ПО, предназначенного для проведения DDoS-атак. Первая версия вредоносного ПО использует утилиту wget для отправки запросов на веб-сайты в цикле:

Также используется отдельный «стартовый» скрипт для основного скрипта, описанного выше:

Список веб-сайтов для атаки содержится в отдельном файле с именем list. Как показало исследование, злоумышленник неоднократно подключался к серверу, чтобы обновлять список веб-ресурсов для атак. В последней версии текстового файла содержались адреса сайтов средств массовой информации, промышленных предприятий, банков, объектов транспортной инфраструктуры, а также государственных органов Российской Федерации и Республики Беларусь:

Вторая версия вредоносного ПО, которую злоумышленник использовал на том же сервере, работает несколько иначе: для открытия страниц, содержащих JS-скрипты, применяется браузер Mozilla Firefox, при этом скрипт в цикле отправляет запросы на атакуемые веб-сайты:

Вредоносное ПО подключается к веб-страницам, используемым организацией, известной как IT ARMY of Ukraine.

Развитие инцидента

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

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

Примерно через 10 минут после передачи запроса подрядной организации инженеры атакованного предприятия зафиксировали входящее подключение по AnyDesk. Злоумышленник удалил один из файлов журналов этой утилиты, а затем запустил программное обеспечение для управления SCADA-сервером.

Расследование инцидента

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

Прежде всего было подтверждено, что подключение, использованное для размещения первой версии вредоносного ПО в системе, было установлено 3 марта 2022 года в 20:52 UTC с использованием учетной записи инженера подрядной организации, которая применялась с 2020 года, когда производилась пусконаладка системы.

Во время следующего подключения, установленного 6 марта 2022 года в 20:09 UTC, также с использованием учетной записи подрядчика, злоумышленник внес изменения в текстовый файл, содержащий список веб-сайтов для атаки.

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

Наконец, межсетевой экран организации зафиксировал IP-адрес источника подключения. Согласно данным сервиса Whois, он принадлежит подсети региона, в котором расположен офис подрядной организации.

Таким образом, для осуществления атаки злоумышленнику необходимо было знать как пароль от учетной записи AnyDesk инженера подрядной организации, так и пароль от учетной записи привилегированного пользователя на атакуемом сервере. Даже если предположить, что все учетные данные были украдены у подрядной организации и использованы третьими лицами, это не объясняет тот факт, что злоумышленник подключился к серверу через 10 минут после отправки запроса на предоставление пароля в адрес подрядной организации. IP-адрес также косвенно подтверждает версию о том, что атака была осуществлена инженером подрядной организации, ранее выполнявшим пусконаладочные работы на объекте.

Наконец, анализ истории bash-команд на скомпрометированной системе позволил установить, что злоумышленник пытался устанавливать SSH-подключения к другим системам в сети АСУ ТП, отыскивая такие системы с помощью утилиты nmap. Нельзя однозначно утверждать, была ли его целью попытка продвижения по сети (lateral movement) или саботаж, однако опрос инженеров атакованной организации показал, что подобные действия инженера подрядной организации в любом случае не были легитимными. К счастью, попытки подключиться к другим системам в OT сети оказались безуспешными.

Жертвы атаки

Нам известно об одном инциденте, который привел к компрометации SCADA‑сервера на газопоршневой электростанции.

Владельцев веб‑сайтов, пострадавших от DDoS‑атаки, включая средства массовой информации, промышленные предприятия (металлургической и горнодобывающей отраслей, легкой промышленности, нефтегазовой отрасли, производства удобрений, электроэнергетики), банки, объекты транспортной инфраструктуры, а также государственные органы Российской Федерации и Республики Беларусь, можно считать вторичными жертвами атаки.

Информация о злоумышленниках

На основании всех выявленных фактов можно предположить, что инженер подрядной организации принял решение присоединиться к деятельности структуры, известной как IT ARMY of Ukraine. После этого он злоупотребил своим служебным положением в компании‑подрядчике, а именно — возможностью использовать инструменты удаленного доступа к промышленной инфраструктуре заказчиков, чтобы разместить и выполнить вредоносный код.

Согласно данным Википедии, IT ARMY of Ukraine — это волонтерская киберорганизация, созданная в конце февраля 2022 года. Группа осуществляет наступательные кибероперации.

С конца февраля 2022 года эта группа использует свои веб‑сайты, а также аккаунты в социальных сетях и мессенджерах для распространения инструкций по участию в DDoS‑атаках на веб‑ресурсы компаний и организаций в России и Беларуси.

Заключение

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

К сожалению, во время пусконаладочных работ нередко подрядчику предоставляется удаленный доступ к ОТ-инфраструктуре, который потом попросту забывают отозвать. В результате подрядчик может пользоваться таким доступом, когда захочет, даже без ведома заказчика и после ввода объекта в эксплуатацию.

Описанный выше инцидент демонстрирует, что изоляция сети АСУ ТП от интернета, строгий контроль использования средств удаленного администрирования, а также периодический пересмотр всех ранее выданных прав доступа должны входить в число приоритетных задач для ИТ‑подразделений и служб информационной безопасности предприятия.

Если после ознакомления с этим отчетом у вас возникли вопросы или комментарии, или если у вас есть дополнительная информация, относящаяся к описанной в нем вредоносной кампании, пожалуйста, свяжитесь с нами, отправив письмо на адрес ics-cert@kaspersky.com.

Рекомендации

Чтобы вы не оказались жертвой атаки, описанной в этом отчете, мы рекомендуем принять следующие меры:

1. Провести аудит использования средств удаленного администрирования и удалить такие утилиты в тех случаях, когда они применяются без согласования. В случаях, когда использование подобных средств обосновано и утверждено, им следует запретить прямое подключение к интернету (с помощью межсетевых экранов), а доступ к ним должен осуществляться только через VPN. Для VPN‑подключений рекомендуется использовать двухфакторную аутентификацию.
2. Задать следующие требования к сложности паролей в политиках операционных систем:
   • Длина пароля: не менее 12 символов для непривилегированных учетных записей и 16 символов для привилегированных учетных записей.
   • Пароль должен содержать буквы в верхнем и нижнем регистрах, цифры и специальные символы.
   • Пароль не должен содержать слова из словаря или персональные данные пользователя, которые могут быть использованы для взлома пароля, в частности:
     • имена пользователя, телефонные номера, памятные даты (дни рождения и т. п.);
     • блоки символов, последовательно расположенных на клавиатуре (12345678, QWERTY и т. п.);
     • распространенные аббревиатуры и термины (USER, TEST, ADMIN и т. п.).
3. Обеспечить наличие у технического персонала предприятия учетных данных для привилегированных учетных записей. Если эти учетные записи ранее использовались подрядными организациями, выполнить внеплановую смену паролей.
4. В случае выявления каких-либо индикаторов компрометации следует выполнить смену паролей для всех учетных записей.
5. Включить двухфакторную аутентификацию при входе в консоль управления и веб-интерфейсы защитных решений. К примеру, в Kaspersky Security Center это делается всего в несколько шагов, описанных в статье.
6. Установить актуальные версии средств защиты на все системы (как серверы, так и рабочие станции под управлением Windows и Linux) и регулярно обновлять антивирусные базы и программные модули. Использовать специализированные решения для защиты промышленных систем. Kaspersky Industrial CyberSecurity защищает промышленные узлы и обеспечивает мониторинг сети АСУ ТП для выявления вредоносной активности.
7. Убедиться, что все компоненты средств защиты включены на всех системах и что действующие политики запрещают отключение защиты, завершение работы или удаление защитных решений без ввода пароля администратора.
8. Убедиться, что защитные решения получают актуальную информацию об угрозах из Kaspersky Security Network на тех группах систем, для которых использование облачных сервисов не запрещено законом или иными нормативными требованиями.
9. Убедиться, что лицензионные ключи защитных решений распространены на все устройства и что для всех групп устройств созданы задачи периодического сканирования системы.
10. Развернуть SIEM-систему, например, Kaspersky Unified Monitoring and Analysis Platform.
11. Реализовать в SIEM системе следующие корреляционные правила:
    • Использование средств удаленного администрирования (RAT).
    • Появление новых приложений в автозапуске.
    • Появление новых скриптов cmd / bash.
    • Отключение средств защиты.
    • Сканирование портов систем внутри сети АСУ ТП.
    • Большое количество запросов к внешним ресурсам из сети АСУ ТП.
12. Обновить Microsoft Windows, а также Unix-подобные операционные системы до версий, которые в настоящее время поддерживаются производителями. Установить последние обновления безопасности (патчи) для операционных систем и приложений.
13. Убедиться, что политики операционных систем включают ограничения на количество попыток пользователей выполнить вход в систему. Пользователям должно быть разрешено входить только на те системы, доступ к которым необходим им для выполнения их должностных обязанностей.
14. Ограничить сетевые подключения, включая VPN, к системам в сети АСУ ТП; заблокировать подключения по всем портам, использование которых не требуется для технологического процесса.
15. Обучать сотрудников предприятия безопасной работе с интернетом, электронной почтой и другими каналами связи. В частности, разъяснять возможные последствия загрузки и запуска файлов из непроверенных источников. Сделать акцент на контроле фишинговых писем, а также на безопасных практиках работы с документами Microsoft Office.
16. Обязать администраторов не использовать привилегированные учетные записи, за исключением случаев, когда их задачи могут быть выполнены только с использованием таких учетных записей. Также рекомендуется использовать отдельные специализированные учетные записи для администрирования различных групп систем, например баз данных.
17. Для систем на базе Windows, где это возможно, ограничить получение программами прав SeDebugPrivilege.
18. Внедрить решения классов EDR/XDR/MDR для получения наиболее часто встречающихся паттернов связей между процессами для используемых систем АСУ ТП.
19. Применять запуск приложений по белым спискам, чтобы в сети АСУ ТП запускались только одобренные приложения, имеющие действительную цифровую подпись.
20. Запретить хранение и отправку паролей в открытом виде; использовать для хранения и передачи паролей специализированное программное обеспечение (менеджеры паролей).
21. Внедрить двухфакторную аутентификацию для авторизации (с использованием RDP, SSH или других протоколов) на системах, содержащих конфиденциальные данные, а также на системах, критически важных для ИТ‑ и OT‑инфраструктуры организации, таких как контроллеры домена и SCADA‑серверы.
22. Усилить сегментацию сети. Настроить сети разных подразделений (а также разных предприятий) как отдельные сегменты. Ограничить передачу данных между сегментами сети минимально необходимым набором портов и протоколов, требуемых для функционирования рабочих процессов организации.
23. Перенести системы, связанные с обеспечением информационной безопасности организации, в выделенный сегмент и, по возможности, в отдельный домен. Ограничить передачу данных между этим сегментом и остальной сетью минимально необходимым набором портов и протоколов, требуемых для работы средств защиты и проведения мониторинга с целью выявления инцидентов информационной безопасности.
24. Если требуется удаленный доступ к системам в других сегментах сети, настроить демилитаризованные зоны (DMZ) для обмена данными между сегментами и осуществлять удаленный доступ через терминальные серверы.
25. Настроить систему хранения резервных копий таким образом, чтобы копии сохранялись на отдельном сервере, не входящем в домен, и права на удаление и изменение резервных копий были только у выделенной учетной записи, также не входящей в домен. Эта мера поможет защитить резервные копии в случае компрометации домена.
26. Увеличить частоту создания резервных копий, чтобы отказ любого сервера не приводил к потере критически важного объема информации.
27. Хранить не менее трех резервных копий для каждого сервера и других систем, важных для нормального функционирования организации. Кроме того, как минимум одна резервная копия должна храниться на отдельном, автономном устройстве хранения данных.
28. Использовать RAID‑массивы на серверах, на которых хранятся резервные копии. Это поможет повысить отказоустойчивость системы резервного копирования.
29. Внедрить процедуру регулярной проверки целостности и работоспособности резервных копий. Кроме того, внедрить процедуру регулярного антивирусного сканирования резервных копий.
30. Провести внеплановое сканирование всех используемых в организации съемных носителей информации с помощью антивирусного ПО, а также с использованием предоставленных индикаторов компрометации.
31. Также мы рекомендуем, независимо от наличия или отсутствия признаков инцидента информационной безопасности, привести настройки Kaspersky Security Center в соответствие с лучшими практиками, описанными в Руководстве по усилению защиты.

Индикаторы компрометации

Контрольные суммы файлов (MD5)
1ECAFBCC7187740E037462B312181319 – Вредоносный скрипт
FD30EF38227A52E5C96D00257912C247 – Список ресурсов, атакуемых вредоносным ПО
E88DAC291E0442AFAAF474B352D9028C – Вредоносный скрипт
DFD9BBC24F46EE0E1F69623308126CAD – Вредоносный скрипт

Пути к файлам

\home\<username>\dosilka\dosilka.sh
\home\<username>\dosilka\list
\home\<username>\dosilka\start.sh
\home\<username>\dosilka\start2.sh

Вердикты защитных решений

Trojan-DDoS.Shell.Agent.f
Trojan.Shell.Starter.d
Trojan-DDoS.Shell.Agent.g

Доменные имена

www.notwar.ho[.]ua
playforukraine[.]live
tours.testforstudio[.]com
russianwarshipgofuckyourself[.]club