На кибербитве Standoff 11 в виртуальном государстве F впервые представили атомную промышленность. Задачей атакующих (red team) было реализовать недопустимые события на виртуальной АЭС, а защитников (blue team) — расследовать атаку с помощью продуктов Positive Technologies. Как все прошло? Заглядываем в ретроспективу событий, сохранившихся в SOC, за который на Standoff отвечал наш соорганизатор Innostage. Атаку шаг за шагом распутывает Данил Лобачев, специалист группы обнаружения атак на конечных устройствах экспертного центра безопасности Positive Technologies (PT Expert Security Center).
В атомной промышленности мы выделили основные отраслевые элементы и этапы — от добычи урановой руды до захоронения отходов. По сценарию кибербитвы для атак доступны АЭС (включая электроподстанцию) и завод по обогащению урана.
Во второй день противостояния на виртуальном заводе перестали работать несколько центрифуг. Атакующим удалось проникнуть во внутреннюю сеть предприятия и отправить контроллеру соответствующую команду. В реальной жизни изменение скорости вращения центрифуг может привести к остановке обогащения урана и откатить буквально все до ноля. Это просто недопустимо для бизнеса. К тому же при неправильном изменении частоты вращения центрифуга может разрушиться. На восстановление обогащения ушло бы несколько месяцев.
Кстати, в реальном мире такое уже случалось: вирус Stuxnet отбросил ядерную программу Ирана на два года назад.
Реализация недопустимого события
Центрифуга для обогащения урана управляется программируемым логическим контроллером (ПЛК) SIMATIC S7. Семнадцатого мая «синие» зафиксировали остановку контроллера с помощью системы глубокого анализа технологического трафика — PT Industrial Security Incident Manager (PT ISIM). Команда остановки была отправлена с узла, имеющего IP-адрес 10.156.64.197; запомним его для расследования.
Так как взаимодействие с ПЛК происходит по 102-му порту, можно обратиться к системе поведенческого анализа сетевого трафика — PT Network Attack Discovery (PT NAD) — и посмотреть, зафиксировала ли она такую активность. Для этого необходимо отфильтровать трафик по времени и известным параметрам: по IP-адресу источника и назначения, а также по порту источника.
Видим несколько сессий, подходящих под временной отрезок: вероятно, команда красных несколько раз пыталась совершить сие злодеяние. Также в колонке «Домен отправителя» отображается имя узла, с которого проведена атака; эту информацию запоминаем.
PT NAD позволяет скачать дамп сессии для более глубокого анализа. Сделаем это.
В скачанном дампе видно, что атакующий посылает пакет с кодом 0x29: это означает остановку контроллера.
Итак, нам известны доменное имя узла, с которого совершалась атака, порт и время инцидента. Негусто. Обратимся к MaxPatrol SIEM с имеющимися вводными. Отсортируем события фильтром event_src.host = "bpreston.nuclear.stf" and src.port = "65492" and dst.port = "102" and dst.ip = "10.156.62.3". Теперь мы узнаем, что команда остановки отправлена пользователем ladmin с помощью процесса rec.exe. Но что это за процесс и как он попал на узел? Разберемся.
Можно посмотреть, как был запущен процесс, — отфильтруем события запросом event_src.host = "bpreston.nuclear.stf" and object.process.name = "rec.exe" and msgid in [1, 4688]. Оказывается, что использовался агент Zabbix (довольно подозрительно o_O).
Пробуем поискать запуск zabbix_agentd.exe и находим интересное описание в поле, предназначенном для хранения метаинформации. Делаем вывод, что этот процесс не является легитимным агентом Zabbix, а был подложен в папку вместо настоящего.
К примеру, метаинформация легитимного агента Zabbix представлена ниже.
Посмотрим, какой вердикт вынесет сетевая песочница PT Sandbox после проверки zabbix_agentd.exe.
Но что еще интересного делал подмененный агент Zabbix? Применим запрос event_src.host = "bpreston.nuclear.stf" AND object.process.chain contains "zabbix_agentd.exe" для того, чтобы увидеть, в каких цепочках запуска процессов находится название подставного агента. И тут же натыкаемся на события с созданием пользователя ladmin с помощью исполняемого файла net.exe.
Кстати, смотреть цепочку запущенных процессов удобно с помощью плагина SiemMonkey. Наш коллега Константин Грищенко в рамках участия в открытом сообществе Security Experts Community выложил в открытый доступ свои наработки по автоматизации рутинных задач специалистов SOC и оформил их в виде плагина для браузера Google Chrome.
Эта активность также попала в цепочку нескольких корреляционных правил.
Незадолго до этих событий с процессом zabbix_agentd.exe взаимодействовал пользователь r_humphrey. Предположим, что до создания учетной записи ladmin атакующие использовали r_humphrey.
Как пользователь попал на узел bpreston.nuclear.stf? Отсортируем события по этой сессии и зададим в запросе только события входа в систему: event_src.host = "bpreston.nuclear.stf" and (subject.account.session_id = "11812950" or object.account.session_id = "11812950") and msgid = "4624".
Как оказалось, пользователь пришел с сервера RDG. Посмотрим логи. Так как мы знаем время подключения, можно поискать на сервере события установки соединения по порту RDP с адресом назначения bpreston.nuclear.stf. Это необходимо для того, чтобы узнать номер сессии, в которую совершались действия.
Получаем номер сессии, а также замечаем срабатывание правила корреляции на активность файла rec.exe, который мы видели ранее на узле bpreston. Запуск бинаря rec.exe осуществлялся с помощью файла telemetry.exe.
Изучаем данные о запуске telemetry.exe и видим уже знакомую ситуацию: у файла говорящая метаинформация.
Проверяем хеш файла в базе VirusTotal, чтобы убедиться наверняка.
Осталось узнать, как атакующие получили доступ к RDG-серверу. Изучаем события входа в рамках этой сессии. Под учеткой r_humphrey «красные» пришли с устройства fhays.
Посмотрев события с fhays.nuclear.stf, в который раз замечаем соединение через файл rec.exe. Но здесь мы видим, что запустил его пользователь f_hays, а не r_humphrey.
Смотрим сработавшие правила корреляции, которые укладываются в наши временные рамки. Находим использование mimikatz.exe с параметрами sekurlsa::logonpasswords full (видимо, отсюда «красные» и получили креды r_humphrey).
Сгруппируем события по названиям сработавших корреляционных правил, чтобы увидеть, чего можно ждать от этой сессии.
Тут целый букет правил. Самыми интересными, на первый взгляд, кажутся срабатывания на Sliver, Cobalt Strike, SharpHound. И куда же без документов с макросами! Попробуем узнать, откуда на устройстве появился Sliver (aka telemetry.exe).
Применим запрос для поиска события о создании файла telemetry.exe: (event_src.host = "fhays.nuclear.stf") and body contains "telemetry.exe" and msgid = "11". Цепочка продолжается, так как мы узнали, что файл создан с помощью a01.exe.
Узнаем, как был создан a01.exe. Видим легитимный netsh.exe, который по умолчанию не может создавать файлы: значит, он не тот, каким кажется.
Посмотрим сработавшие корреляционные правила, в которых subject.process.name = "netsh.exe". В процесс с помощью pp3.exe были загружены библиотеки PowerShell.
О такой активности говорят события с msgid = "8".
Откуда взялся pp3.exe? Для этого вновь воспользуемся SiemMonkey. Замечаем, что процесс создан с помощью закодированной PowerShell (pid 2924) команды, которая запущена документом FBI_Request.doc.
На активность процесса PowerShell сработали сразу несколько правил.
В одном из срабатываний видим, что атакующие пытались подделать URL, с которого была загружена полезная нагрузка. Хорошая попытка, но название компании Innostage пишется с двумя n.
Обратимся к PT NAD для поиска информации об этой сессии: файл загрузили с помощью PoshRat, который был внутри макроса письма.
Проверяем документ в PT Sandbox. Видим, что письмо рассылалось на множество адресов, в этот список попал пользователь f_hays.
Цепочка событий, произошедших на кибербитве Standoff, наглядно демонстрирует, что даже самые защищенные системы и критическая инфраструктура подвержены уязвимостям. Атака началась с обычного фишингового письма. После того как пользователь открыл зараженный документ, «красным» удалось переместиться через несколько устройств. В итоге они получили доступ к узлу оператора ПЛК, с которого остановили центрифугу для обогащения урана.
Как защититься? Выстроить регулярное обучение сотрудников как минимум азам кибербезопасности, а также проводить регулярные киберучения. Все это делает атаку невыгодной для злоумышленников и существенно повышает шансы компании на успешное противостояние киберугрозам.
