Хакеры всё активнее используют ошибки в настройке Kubernetes, чтобы пройти путь от взломанного контейнера до облачной инфраструктуры компании. Речь идёт уже не о единичных экспериментах, а о смене тактики: злоумышленники крадут токены сервисных учётных записей, проверяют права доступа через Kubernetes API и затем двигаются дальше — к секретам, облачным сервисам и критичным внутренним системам.
По данным Unit 42, число операций, связанных с угрозами для Kubernetes, включая кражу токенов сервисных учётных записей, за последний год выросло на 282%. Исследователи также отмечают, что 78% наблюдаемой активности пришлись на ИТ-сектор. Ещё один важный показатель: в 22% облачных сред, которые анализировались в 2025 году, была замечена подозрительная активность, связанная с кражей токенов сервисных учётных записей. Это означает, что проблема — уже не редкий инцидент, а массовый риск для облачных сред на базе Kubernetes.
Схема атаки такая: сначала злоумышленник получает выполнение кода внутри контейнера, например, через уязвимость в приложении или уже скомпрометированную учётную запись разработчика. Затем он извлекает из пода токен сервисной учётной записи. Такой токен Kubernetes автоматически выдаёт рабочим нагрузкам, чтобы они могли обращаться к API кластера. Если права этой учётной записи слишком широкие, атакующий может просматривать секреты, работать с подами в разных пространствах имён и постепенно расширять контроль над кластером. Об этом отдельно напоминает и CISA: украденные токены сервисных учётных записей позволяют аутентифицироваться в Kubernetes API и дальше использовать кластер для повышения привилегий, кражи данных, закрепления и запуска вредоносных контейнеров.
Unit 42 приводит реальный пример, связанный с группой Slow Pisces, которую также отслеживают под названиями Lazarus и TraderTraitor. По данным исследователей, в середине 2025 года эта группа атаковала криптовалютную биржу, закрепившись на рабочей станции разработчика через фишинг. После этого злоумышленники использовали активную привилегированную облачную сессию разработчика, развернули вредоносный под в промышленном Kubernetes-кластере и вытащили токен высокопривилегированной сервисной учётной записи. С его помощью они получили доступ к API, перечислили секреты, взаимодействовали с рабочими нагрузками в разных пространствах имён и внедрили бэкдор в производственный под для сохранения доступа.
На этом атака не остановилась. Исследователи Unit 42 подчёркивают, что украденный токен позволил перейти от уровня кластера к более широкой облачной инфраструктуре: злоумышленники получили доступ к внутренним системам, извлекли чувствительные учётные данные и добрались до финансового контура организации. Атакующие больше не пытаются просто «сбежать» из одного контейнера — они используют слабые настройки идентификации и избыточные права доступа, чтобы добраться до ядра облачной среды.
Во втором кейсе, который разбирает Unit 42, атакующие использовали уязвимость CVE-2025-55182, известную как React2Shell. Она позволяла добиться выполнения кода внутри контейнеров через небезопасную десериализацию в протоколе React Server Components. После проникновения злоумышленники снова последовали по уже знакомому пути: собирали токены сервисных учётных записей, обращались к Kubernetes API, вытаскивали облачные учётные данные из переменных окружения, а затем устанавливали бэкдоры и разворачивали криптомайнеры. По данным Unit 42, активная эксплуатация началась уже через два дня после публичного раскрытия этой уязвимости.
Проблема не ограничивается только токенами. Внешние исследования подтверждают, что в Kubernetes злоумышленники часто используют и другие типовые ошибки: слишком широкие права через RBAC, запуск контейнеров с повышенными привилегиями, отсутствие сетевых политик и плохо защищённые точки управления. Microsoft указывает, что неверные настройки среды и слабый контроль доступа к Kubernetes API могут позволить атакующему развернуть вредоносные контейнеры, нарушить работу кластера или полностью его захватить. Dynatrace добавляет, что многие реальные цепочки атак строятся не на сложных эксплойтах нулевого дня, а на распахнутых дверях — штатных возможностях Kubernetes, которые не ограничили.
Unit 42 рекомендует жёстко ограничивать права сервисных учётных записей по принципу минимально необходимого доступа, не использовать шаблонные или избыточные разрешения, а долгоживущие статические токены менять на короткоживущие проектируемые, которые автоматически истекают. Кроме того, исследователи советуют включать и регулярно анализировать журналы аудита Kubernetes, а также использовать средства мониторинга исполнения, которые замечают необычные процессы, нетипичные исходящие соединения и попытки доступа к чувствительным путям внутри контейнеров. CISA со своей стороны также рекомендует отзывать и менять украденные токены и перезапускать поды после ротации сервисных учётных записей.
Академические исследования последних месяцев показывают, что ошибки конфигурации в Kubernetes встречаются системно. Например, в одной из работ исследователи проанализировали 287 открытых приложений и нашли 634 сетевые ошибки конфигурации, влияющие на безопасность и боковое перемещение внутри кластера. Это не новостной инцидент, а важное подтверждение: слабые настройки в Kubernetes — не исключение, а массовая проблема экосистемы.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
