Практическое расследование инцидентов в облачных средах: самые наглядные кейсы в 2024 году

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

Меня зовут Юрий Наместников, я руковожу Cloud Security Operations в Yandex Cloud и в этой статье поделюсь нашей внутренней облачной кухней. Расскажу, с какими интересными задачами сталкиваются команды безопасности облачных платформ сегодня, и разберу кейсы с наиболее запоминающимися решениями.

Немного статистики

Наши клиенты часто обращаются за помощью в расследовании инцидентов к специалистам команды Cloud Detection & Response. Нередко запрос может начинаться фразой «Мы видим, что происходит что‑то странное» (а потом, например, выясняется, что это пентест). Чаще всего после анализа инцидент попадает в одну из этих категорий:

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

Если обобщить наш опыт с доступными исследованиями, то в 2024 году в облаке злоумышленники преследуют такие цели атак:

• Остановка бизнес‑процессов.

• Дотянуться до баз данных и S3.

• Supply Chain, если вы разработчик или сервис‑провайдер.

• Переход в on‑premise‑инфраструктуру (об этом в случае гибридных систем часто забывают).

• Использование инфраструктуры злоумышленниками: майнинг, DDoS, C2.

В целом, мы видим в 2024 году переход от урона репутации к деструктивным действиям в облаке.

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

Атаки с облачным вкусом и не только 

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

• Аккаунт Яндекс Паспорта. Мы рекомендуем использовать его только для первичной настройки и для биллинга, а больше никаких прав ему не давать. Какие тут могут быть секреты: OAuth‑токен на IAM и Cookie для доступа в консоль.

• Сервисный аккаунт (SA). Здесь набор ключей поинтереснее: есть API‑ключ (по умолчанию без срока и скоупа), есть авторизованный ключ для обмена на IAM‑токен, а также статический ключ доступа для AWS‑совместимых API.

• Федеративный аккаунт. Способы аутентификации: SSO и IdP.

• Федерация сервисных аккаунтов (Workload Identity Federation). Это way‑to‑go для сервисных аккаунтов, поскольку так можно избавиться от долгоживущих ключей. Что тут можно настроить: OpenID‑провайдер выпускает JWT для внешней сущности и меняет на IAM‑токен SA.

Вторая особенность облака — всё, что делается с облачными ресурсами, проходит через сервис Identity and Access Management (IAM). В логах IAM оседает всё, что делает хакер. Если взглянуть более прицельно на этот сервис в Yandex Cloud:

• Есть централизованная система описания ролей и доступов.

• Есть групповые роли, наследование, имперсонация.

• Все ресурсы Yandex Cloud завязаны на IAM.

• Логи попадают в Audit Trails.

Эти особенности пригодятся нам в расследовании.

Кейс «Добро пожаловать»: пользователи и ключи

Начнём с обобщённого и довольно частого кейса. Мы периодически видим, что злоумышленники просто заходят в облако клиента: они ничего не перебирают, не проводят сложных атак, а сразу используют для входа готовые креды. Как им это удаётся: секреты угоняют у владельцев, подрядчиков, DevOps с помощью вредоносного ПО или же проводят майнинг в открытых данных, по env, image, исходникам.

Не менее интересно, что позволяет им закрепиться в инфраструктуре:

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

• Создание своих виртуальных машин с ключами и добавление внешнего IP.

• Создание сервисных аккаунтов.

Хорошая новость в том, что всё это можно увидеть в логах.

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

Кейс со «вкусным» SA: мисконфиг и сервисный аккаунт с правами

Однажды мы разбирали историю, где всё, на первый взгляд, было сделано по учебнику:

1. Развернули Hadoop.

2. Навесили Security Groups (SG).

3. Добавили публичный IP.

4. Прибиндили сервисный аккаунт.

Но кое‑что пошло не так. В Hadoop есть YARN Resource Manager, который по умолчанию без аутентификации позволяет выполнять код через HTTP‑запрос. Вдобавок к этому security‑группу сделали c CIDR SG: 0.0.0.0/0, а сервисный аккаунт — с правами admin/editor на папку и Yandex Cloud. Получилась опасная комбинация.

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

Что интересно, злоумышленники на самом деле не поняли, куда они попали, так как не воспользовались преимуществами сервисного аккаунта с правами администратора. Теоретически они могли создать кучу других ВМ и увеличить эффект примерно в 20 раз.

Кейс обхода мониторинга: бакеты и диски

У злоумышленников часто есть цель: понять, что крутится в облаке, но при этом постараться не шуметь. Ещё в одном кейсе хакерам удалось дотянуться до учётной записи с ролью compute.editor. Как именно: они создавали ВМ в своём тестовом каталоге и монтировали к ним доступные диски из продакшн‑окружения. А в облаках ещё нередко бывает и публичный S3 с расслабленными правами на запись — администраторы обычно помнят об ограничении прав на чтение, а вот про запись можно забыть, и этим хакеры тоже могут воспользоваться. Таким образом, у злоумышленников есть и точка для вывода информации, и возможность уносить данные по‑тихому.

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

Кейс с серийной консолью в Yandex Cloud

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

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

Как обнаружить. Все такие события попадают в логи, где есть поле Remote_Address. По нему можно определить тип IP, репутацию и геолокацию. В первую очередь стоит смотреть на нетипичные для вас вещи, например заходы с хостинг‑провайдеров, известных VPN.

Кейс с антиоблачным паттерном: «Майнер — это не страшно»

Иногда пользователь приходит в облако, разворачивает какое‑то решение из Marketplace, навешивает публичный IP, привязывает домен, и вроде бы всё хорошо. Но нужно ещё, как минимум, подумать о патч‑менеджменте, потому что он не случится сам собой. При этом часто Dev‑ и продакшн‑окружения разделены только на бумаге. Или вообще находятся на одной машине под одним пользователем.

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

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

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

Как можно было не разбирать такие инциденты?. Если коротко, то ответ заключается в использовании Managed‑сервисов, прежде всего баз данных, которые решают сразу кучу проблем:

• Патчи из коробки.

• Более безопасная конфигурация.

• Понятная сеть и Seсurity‑группа.

• Аудитные логи в Audit Trails.

• Возможность все описать в Terraform, в том числе и правила логирования.

• Всё сразу видно в ресурсной модели со всеми ключевыми настройками, а значит можно проверять на мисконфигурации через инструменты класса Cloud Security Posture Management.

Обнаружение, анализ и форензика

Audit Trails и IAM помогают обнаруживать львиную долю подозрительных событий в облаке. Вот TOP-5 вещей, которые должны привлекать внимание безопасника:

• Походы из внешних сетей. Особенно SA.

• Добавление пользователей.

• Выдача прав (bindings).

• Подключение дисков или публичный S3.

• БД: включение DataLens, SQL‑консоль.

Помимо этого мы очень рекомендуем настроить и автоматизировать сбор артефактов и протестировать его до того, как произойдёт первый инцидент. Что автоматизировано у нас:

Снапшоты дисков и памяти:

• Достаточно просто по сравнению с физическими серверами.

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

• Можно создать образ и запустить в контролируемой среде.

У себя мы используем Cloud Functions для автоматизации поиска индикаторов и техник с прошлых инцидентов с помощью YARA‑правил.

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

Аккаунты:

1. Убедиться, что не появились новые аккаунты.

2. Убедиться, что нет внешних аккаунтов и паспортных аккаунтов с высокими правами.

3. Убедиться, что нет прибинденных сервисных аккаунтов.

Токены и роли:

1. Заморозить токен.

2. Навесить скоуп.

3. Забрать все роли.

Cеть:

1. Навесить Security Group.

2. N. B.: не дефолтную!

Постинцидентные активности и подготовка

Давайте подведём итог и начнём с частых ошибок. Итак, что НЕ надо делать:

• Запускать IR/Forensic‑инструменты и накатывать патчи до того, как собрали базовые артефакты.

• Отрывать роли и менять конфигурацию Control Plane, а потом включать Audit Trails.

• Оставлять повышенные привилегии учётным записям, которые участвовали в IR (не обязательно security!). Особенно примитивные роли — admin, editor, viewer на облако или папку.

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

• Держать маленькое окно хранения бэкапов.

• Настраивать облако руками.

Что вместо этого мы рекомендуем делать:

• Включить Audit Trails.

• Сетевые логи настроить заранее.

• Использовать Стандарт по защите облачной инфраструктуры Yandex Cloud 1.2.

• Провести инвентаризацию ресурсов и роли!

• Настроить CSPM — Cloud Security Posture Management.

• Создать облако для security: для хранения артефактов, инструментов для анализа.

• Автоматизировать базовые вещи: дампы, скан.

• Описать облако security и Audit Trails в формате Infrastructure as Code.

• Выбрать нужные данные уровня конфигурации и сервиса.

• Сделать бэкап логов — например, в том же S3. Потом всегда можно подключиться и искать через Yandex Query.

Спасибо за внимание! Если вам интересна тема безопасности в облаках и не только, будем рады видеть вас в нашем Security‑чате.