В современной облачной инфраструктуре система оркестрации контейнеров Kubernetes играет роль критически важного фундамента для множества крупных приложений. Однако именно этот статус делает её привлекательной целью для злоумышленников, которые научились превращать единичный скомпрометированный контейнер (pod) в точку входа для получения полного контроля над облачными аккаунтами. Тенденция к злоупотреблению уязвимостями и ошибками конфигурации в Kubernetes набирает обороты, что подтверждается резким ростом операций по краже токенов и несанкционированному использованию цифровых идентификаторов в корпоративных средах.
Детали
Основной вектор атаки часто начинается с публично доступных сервисов, которые выходят в интернет через контроллеры входящего трафика (ingress controllers) или балансировщики нагрузки. Эти сервисы предоставляют злоумышленникам первоначальную возможность для эксплуатации ошибок на уровне приложений с целью получения удалённого выполнения кода внутри контейнеров. Попав внутрь рабочей нагрузки, атакующие используют слабые правила управления доступом на основе ролей (RBAC), избыточные привилегии сервисных учётных записей и отсутствие сетевых политик для разведки внутри кластера и выхода на подключённые облачные сервисы.
Яркой иллюстрацией этой угрозы стал инцидент 2025 года на одной из платформ для торговли криптовалютой. Злоумышленники скомпрометировали рабочую станцию разработчика и, используя его активную облачную сессию, развернули вредоносный контейнер в производственном кластере Kubernetes. Этот контейнер был специально сконфигурирован для доступа к смонтированному в нём токену сервисной учётной записи, которая, как выяснилось, обладала широкими правами для управления процессами непрерывной интеграции и доставки (CI/CD). Используя этот токен, атакующий прошёл аутентификацию непосредственно в API Kubernetes, получил список секретов (secrets) во всех пространствах имён (namespaces) и внедрил бэкдор в рабочие нагрузки для сохранения долгосрочного доступа. Впоследствии произошла эскалация атаки на размещённые в облаке внутренние системы, сбор дополнительных учётных данных и, в конечном итоге, доступ к финансовой инфраструктуре биржи, что привело к хищению цифровых активов.
Другим тревожным примером стала активная эксплуатация критической уязвимости React2Shell, получившей идентификатор CVE-2025-55182. Эта ошибка в протоколе Flight компонентов React Server Components позволяет осуществлять неавторизованное удалённое выполнение кода через специально сформированные HTTP-запросы. Уже через несколько дней после публикации информации об этой уязвимости в декабре 2025 года, угрозовые акторы использовали её для выполнения команд внутри контейнеров с приложениями, размещёнными в Kubernetes и расположенными за контроллерами входящего трафика и облачными балансировщиками нагрузки. Получив возможность выполнять код, злоумышленники исследовали окружение контейнера, читали смонтированные токены сервисных учётных записей и обращались к API Kubernetes для проверки их возможностей. В ряде сред им также удавалось извлечь облачные учётные данные из переменных окружения или служб метаданных, после чего они перемещались в базовые облачные аккаунты для развёртывания майнеров криптовалюты, установки бэкдоров и кражи паролей от баз данных.
Оба кейса демонстрируют повторяющийся паттерн атаки, который можно соотнести с тактиками матрицы MITRE ATT&CK. Сначала злоумышленники эксплуатируют уязвимость или ошибку конфигурации (T1190 - эксплуатация публично доступного приложения) для получения удалённого выполнения кода в контейнере. Далее они похищают идентификаторы Kubernetes, обычно это токены сервисных учётных записей, смонтированные по предсказуемым путям, что соответствует технике T1528 (кража токена доступа приложения). Наконец, используя эти украденные идентификаторы и обнаруженные облачные учётные данные, они повышают привилегии в кластерах и облачных сервисах, осуществляя горизонтальное перемещение и доступ к данным далеко за пределами исходного контейнера.
Защита от этих угроз требует комплексного подхода, выходящего за рамки простого исправления уязвимостей в контейнерах. Ключевым элементом является внедрение контроля, учитывающего идентификацию, и обеспечение глубокой наблюдаемости. Командам безопасности следует применять строгие правила RBAC и стандарты безопасности для контейнеров (Pod Security Standards), чтобы рабочие нагрузки выполнялись с минимально необходимыми привилегиями. Кроме того, долгоживущие токены целесообразно заменить на краткосрочные проектируемые токены сервисных учётных записей, что ограничивает последствия их кражи. Включение журналов аудита Kubernetes и их интеграция с облачной телеметрией помогает обнаруживать необычные вызовы API, изменения привилегий и подозрительные операции с контейнерами на ранних этапах вторжения. Непрерывный мониторинг активности во время выполнения (runtime monitoring) также критически важен, поскольку он позволяет выявлять неожиданные запуски командных оболочек, команды на вывод данных из системы и признаки майнинга криптовалюты внутри контейнеров. Это даёт защитникам шанс остановить скомпрометированные рабочие нагрузки до того, как атакующие получат контроль над плоскостью управления облаком.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2025-55182
- https://unit42.paloaltonetworks.com/modern-kubernetes-threats/
- https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
