Практическое расследование инцидентов в облачных средах: самые наглядные кейсы в 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: мисконфиг и сервисный аккаунт с правами
Однажды мы разбирали историю, где всё, на первый взгляд, было сделано по учебнику:
Развернули Hadoop.
Навесили Security Groups (SG).
Добавили публичный IP.
Прибиндили сервисный аккаунт.
Но кое‑что пошло не так. В Hadoop есть YARN Resource Manager, который по умолчанию без аутентификации позволяет выполнять код через HTTP‑запрос. Вдобавок к этому security‑группу сделали c CIDR SG: 0.0.0.0/0, а сервисный аккаунт — с правами admin/editor на папку и Yandex Cloud. Получилась опасная комбинация.
Как заметить. Угрозу обнаружили по эпическому всплеску исходящего трафика и обращениям к ботнету.
Что интересно, злоумышленники на самом деле не поняли, куда они попали, так как не воспользовались преимуществами сервисного аккаунта с правами администратора. Теоретически они могли создать кучу других ВМ и увеличить эффект примерно в 20 раз.
Кейс обхода мониторинга: бакеты и диски
У злоумышленников часто есть цель: понять, что крутится в облаке, но при этом постараться не шуметь. Ещё в одном кейсе хакерам удалось дотянуться до учётной записи с ролью compute.editor. Как именно: они создавали ВМ в своём тестовом каталоге и монтировали к ним доступные диски из продакшн‑окружения. А в облаках ещё нередко бывает и публичный S3 с расслабленными правами на запись — администраторы обычно помнят об ограничении прав на чтение, а вот про запись можно забыть, и этим хакеры тоже могут воспользоваться. Таким образом, у злоумышленников есть и точка для вывода информации, и возможность уносить данные по‑тихому.
Как обнаружить. В логах эту ситуацию тоже видно: когда тестовая среда начинает подтягивать диски из продакшн‑среды, это точно повод насторожиться.
Лог Audit Trails, в котором видно, к какому ресурсу и какой диск подключается.
Кейс с серийной консолью в 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‑правил.
Когда мы снимаем импакт, у нас есть список из нескольких наиболее популярных шагов.
Аккаунты:
Убедиться, что не появились новые аккаунты.
Убедиться, что нет внешних аккаунтов и паспортных аккаунтов с высокими правами.
Убедиться, что нет прибинденных сервисных аккаунтов.
Токены и роли:
Заморозить токен.
Навесить скоуп.
Забрать все роли.
Cеть:
Навесить Security Group.
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‑чате.
