Код, пароли, уязвимости: «Газинформсервис» в лабиринтах Standoff

Коллеги, привет. С вами Михаил, инженер компании «Газинформсервис», и если вам так же, как и мне, интересно, как устроена кибербитва Standoff, — предлагаю прочитать эту статью.

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

Команда «Газинформсервис» регулярно участвует в разных кибербитвах. В этом материале речь пойдет об опыте участия в Standoff 13, проходивший в рамках мероприятия PHDays и в кибербитве на ПМЭФ в 2024 году. Битвы проходили на виртуальном полигоне Standoff, он моделирует реальные ИТ-инфраструктуры компаний из различных секторов экономики. В виртуальной среде разворачиваются настоящие кибербаталии.

Red team – команды «красных» стремятся проникнуть в информационные системы и реализовать инциденты различного уровня критичности, зарабатывая баллы за успешные взломы. Blue team – команды «синих» применяют весь арсенал средств защиты и мониторинга для отслеживания угроз и взломов, расследования киберинцидентов.

Red side

Я пообщался с представителями команды GISCyberteam, коллеги играли за «красных» на кибербитве Standoff 13. В рамках этого материала раскрывать имена участников не буду.

— Расскажите, как проходит противостояние на кибербитве, как все было организовано?

— Однозначный плюс кибербитвы, которая проводилась в рамках PHDays, — возможность поиска уязвимостей не только в Windows, но и в других операционных системах, программах, ресурсах: GitLab, CMS, Axelor. Можно было искать уязвимости и в самописном ПО с заранее вшитым бэкдором.

На киберполигоне были воссозданы восемь отраслевых сегментов, в том числе атомный и энергетический. Именно на этих инфраструктурах работали респонсы активной блокировки.

Рисунок 1. Визуализация сегмента киберполигона

— Как строилась инфраструктура? Какие кейсы попадались чаще?

— Первой преградой на пути к желаемому был гейт. Под гейтом понимается обычный веб-интерфейс. «красному» необходимо было отыскать какую-то impact-RCE-уязвимость. Всего гейтов было 70, по 8 в каждом офисе, на каждый гейт по три красных команды. Помимо уязвимостей там же были и почтовые серверы, а также лежали возможные креды почтовых ящиков. Методом брутфорса пытались получить доступ к учетной записи, после чего можно было начинать сканирование сети на наличие узлов, а именно путей доступа к ним. В зависимости от гейта и результатов сканирования можно было выйти на разные сегменты (топов, операторов, SCADA user, SCADA, HR). Например, мы получили доступ к информации HR-подразделения. У каждого сегмента были чекеры на устройствах, можно было попробовать их взломать, отправить скомпрометированное письмо, после чего получить бэк.

Еще можно было сдампить одну из учетных записей администратора: компьютера (WS) или сервера (SRV).

Помимо сегментов были серверы, на которых имитировалось, что администратор допустил ошибку и неверно настроил конфигурацию, — такой сервер можно было сразу сдампить. Получив учётку WS-админа, можно было проводить пивотинг – это давало возможность горизонтального перемещения по сегментам.

В целом кейсов было очень много, например забрать файл с шары, порыться в сегменте топов — поискать финансовый документ. Другой вариант — получить доступ к учетной записи WS-администратора, затем постараться пропивотиться до узла SRV-администратора, с помощью этой учетной записи зайти в сегмент. Если там сдампить хеш-дампом локальные учетные записи, то можно просмотреть местные базы данных, так как локальные УЗ имеют возможность просматривать базы.

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

— Можешь описать конкретный киллчейн?

— Конечно! Разберем по шагам.

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

Второй: выяснили, что обнаруженное на первом шаге веб-приложение уязвимо к RCE-атаке. Атаковали, реализовали реверс-шелл-соединение в контексте пользователя innocentbead.

Третий: на скомпрометированный узел мы загрузили вредоносную программу Chisel, с ее помощью просканировали периметр, расположенный за гейтом, затем нашли Roundcube Webmail.

Четвертый: провели брутфорс-атаку с использованием найденных почтовых адресов по выданным паролям.

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

Шестой: получили привилегии суперпользователя (root) на узле, проэксплуатировав sudo find.

Седьмой: получили сведения о структуре домена FreeIPA.

Восьмой: получили доступ к ресурсу в корпоративном сегменте. Для этого на узле получили сессию учетной записи, которая принадлежит локальному администратору.

Девятый: скачали информацию с помощью команд sudo ls и sudo cat и получили данные браузера из профиля, затем просмотрели историю и получили ссылку на ВКС (видеоконференцсвязь).

Десятый: реализовали критическое событие. Подключились к ВКС, просмотрели презентации.

Рисунок 2. Схема киллчейна

Blue side

Я также опросил команду Octopus, игравшую за «синих», — поговорил с капитаном команды, тремя аналитиками второй линии, техническим писателем и ментором. Ребята представляли «Газинформсервис» на стороне защитников на ПМЭФ.

— Какие правила участия были реализованы хорошо, какие были неудачными или непонятными? Как вы их оцениваете? Что бы вы изменили в них?

— Правила участия были понятны для большинства. Логика работы синей команды была ясной. Предлагаю ввести общий рейтинг для «синих» команд с более четкой системой очков.

— Как общались с организаторами?

— У нас было два основных канала связи — чат в Telegram и Discord-сервер. В Telegram мы задавали в основном уточняющие вопросы по ходу соревнований, а также просили помощи в некоторых ситуациях. В Discord можно было делать тикеты на платформе.

— Какие СЗИ использовали? Все ли из них устроили?

— Использовали целый набор продуктов по обеспечению безопасности: SIEM, NTA, Sandbox, WAF. Но не все хосты были занесены в WAF, что препятствовало анализу событий. С SIEM и NTA проблем не было, показалось, что в PT Container Security не всегда было удобно просматривать оповещения и не видны были результаты выполнения команд.

— Что детектировалось используемыми СЗИ?

В целом, детектировалось все необходимое, особенно когда дело касалось известного вредоносного ПО и подозрительных команд. А также:

• события с хостов, входящий трафик, события в контейнерах/кубере, события на L7 (Application Firewall);
• все входы и горизонтальные перемещения внутри сети. В SIEM детектировались все действия, происходящие на хостах, в NTA их соединения, в Application Firewall соединения заведенные за фаерволл хостов, в PT Container Security действия внутри контейнеров;
• в PT Sandbox анализировались вредоносные файлы, а также почтовые вложения;
• иногда детектировалось не то, что нужно, так называемые «фолзы», были ложные срабатывания;
• детектировались утилиты, используемые «красными», большое количество других событий, как легитимных, так и не легитимных;
• сетевые атаки, фишинг через электронную почту, действия атакующих на конечных точках (в т.ч. в контейнерах), различные веб атаки.

— Что не детектировалось и почему?

А1: Исходя из функционала, должно было детектироваться все, но так как инфраструтура копировала реальную жизнь, и не всегда в ней картина работы ИТ и ИБ идеальна – то и в этом случае много чего не было.

А2: Были иногда «пробелы» в детектировании СЗИ, был даже показательный случай, когда SIEM пропустил важное событие, которое играло роль в расследовании, но в атаке от другой команды оно было задетектированно.

А3:Плохо детектировалась работа в контейнере и трафик с некоторых хостов, так как они не были заведены под СЗИ.

А4: Не весь траффик детектировался в PT NTA (зашифрованный tls трафик).

А5: Не детектировалась часть логов, которая нам была нужна для расследований, пофиксить можно более тщательной проверкой перед ивентом.

А6: Не детектировались сетевые атаки в зашифрованном трафике т.к. NTA не умеет его расшифровывать. Было бы удобно, если бы у NTA была интеграция с прокси по ICAP. Также было бы гораздо легче расследовать атаки при наличии EDR-агентов на конечных точках (пусть и только с функцией мониторинга) т.к. они дают гораздо больше информации, чем стандартный SIEM.

— Понравилось ли в целом участие? Как оцениваете полученный опыт?

А1: Конечно, очень много потратили времени чтобы разобраться с PT Container Security. Также, к концу мероприятия мы пришли к выводу, что на критические инциденты нужно выделять минимум 2 человека, так как один может не заметить очевидных вещей и потратить много времени на распутывание цепочки, так и не добравшись до истины. Легкость была в работе с СЗИ в целом, так как с продуктами очень хорошо все знакомы в нашей команде.

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

А3: Мне бы хотелось сделать больше расследований, но легкие НС быстро разобрали, а в более сложных векторах были проблемы из-за отсутствия логов.

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

А5: Работать с SIEM, NTA, Sandbox и Application Firewall, было легко, т.к. с ними был опыт на курсах PT PROFF. В целом, выступить мог бы и лучше. Не был готов к большому количеству атак на контейнеры и к тому, что атакующие будут знать инфраструктуру заранее.

— Что можете сказать о соперниках?

А1: Если считать соперниками «красных», то там были очень опытные специалисты, у которых можно многому научиться. С соперниками из «синих» практически не общались (почти все были онлайн).

А2: Соперники проявили себя достойными и умелыми, дали большую почву для расследований. Я был изначально о них наслышан, и мои ожидания оправдались.

А3: Отмечу синюю команду, которая была вместе с нами в офлайне, — N@mele$$. Ребята молодцы, разобрали все недопустимые события, которые у них были.

А4: «Красные» довольно активно и успешно сдавали отчеты с описанием векторов атак, поэтому всегда было что расследовать, а среди «синих» было несколько команд, с которыми мы шли рядом по количеству расследований все время, — это было дополнительным стимулом.

А5: Атакующие молодцы. Было действительно довольно сложно: «красные» использовали средства для сокрытия своей работы в системе — это тоже усложняло расследование.

Если вы раздумываете, нужно ли практикующим специалистам участвовать в подобных проектах, надеюсь, это интервью поможет вам определиться с выбором. Увидимся на киберсоревнованиях. Ближайший киберполигон будет организован уже этой осенью в рамках форума GIS DAYS 2024. Подробнее — на сайте мероприятия.