Cyber Polygon 2024:
как это было

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

Также мы наблюдаем тренды на размещение инфраструктуры в облаках и применение средств контейнеризации. В сценарии тренинга мы обратили особое внимание на последствия, которые ожидают IT-инфраструктуру при некорректной настройке таких инструментов.

В этот раз мы решили объединить в одном сценарии актуальные инциденты из практики BI.ZONE, с которыми встречались команды SOC, DFIR, CSIRT. В итоге получилась сложная, но вполне реальная таргетированная атака.

Один из ключевых моментов сценария — атака на систему оркестрации контейнеров Kubernetes, которая заняла оба сегмента R&D (research and development): R&D Dev и R&D Prod. Для расследования атаки участники:

• использовали логи Kubernetes audit и Tetragon;
• анализировали дамп памяти диска с атакованного хоста;
• работали с телеметрией в ELK для поиска действий атакующих;
• исследовали файлы;
• анализировали тактики и техники атакующих;
• изучили много журналов и логов;
• искали подробности в интернете.

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

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

Тренировки на киберполигоне — это не только эффективный способ подготовить специалистов к реальным атакам, но и возможность для руководства компании оценить степень готовности и слабые места команды реагирования.

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

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

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

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

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

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

Так выглядели сегменты, из которых состояла инфраструктура компании.

В инфраструктуре мы реализовали плотную интеграцию между отдельными сервисами и приложениями, запущенными внутри Kubernetes. Например, между собой взаимодействовали:

• GitLab, Vault и Harbor;
• GitLab и Apache Airflow;
• Kubernetes, Apache Airflow и объектное хранилище S3 (Simple Storage Service).

Также мы применили работоспособный пайплайн обучения ML-модели. Сегменты DMZ, Admin и Internet в сценарии не использовались, но мы ввели их, чтобы максимально приблизить виртуальную инфраструктуру к реальной.

Тренинг начался в 12:00 10 сентября. В это время мы опубликовали пароль от архива с артефактами, который участники могли скачать заранее.

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

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

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

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