Криптоджекинг в Kubernetes — выводы с БЕКОН 2026

С конференции вернулся в час ночи) Cпикерпати меня не отпускало 😂

Обещал, что расскажу про доклад (к предыдущему посту я прикрепил в комментариях свою презентацию, если кто-то хотел ее посмотреть). Пока официальное видео с моим выступлением не вышло, распишу все текстом, к чему мы все уже привыкли

На БЕКОН 2026 я ездил с докладом про криптоджекинг в Kubernetes. И изначально может показаться, что тема довольно простая. Ну что такое криптоджекинг? Кто-то залез на сервер, запустил майнер, CPU улетел в космос, админ открыл top, увидел подозрительный процесс, убил его и все. Или не все?

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

А Kubernetes только добавляет веселья, потому что в кубере у злоумышленника перед глазами появляются Pod, Deployment, DaemonSet, ServiceAccount, RBAC, Kubernetes API и много всего интересного

В 2025 году исследователи описывали кампании, где били по Docker API, использовали Tor, тянули полезную нагрузку из скрытых источников и разворачивали криптомайнеры через контейнерную инфру. Unit 42 в 2026 году отдельно показывали, что в Kubernetes-атаках злоумышленники после первичного доступа смотрят смонтированные ServiceAccount token, проверяют права через Kubernetes API и уже потом доставляют вторичную нагрузку, включая майнеры и бэкдоры

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

И если защита построена только вокруг графика нагрузки на CPU, то мы увидим только симптом, но не сможем понять причину. И вот как раз это я показывал в практическом стенде на докладе

В процессе приготовления доклада я собрал лабораторный стенд с разными пространствами имен и инструментами, которые в совокупности ловили свои "симптомы" (в докладе я их называл уликами), а их корреляция позволяла полностью проанализировать инцидент. Смысл был в том, чтобы показать, что криптоджекинг в кубере закрывается не одним продуктом, а архитектурой из нескольких слоев защиты

На уровне ресурсов нам нужны метрики. Prometheus, Grafana, metrics-server и тд, потому что нам важно видеть, что какой-то workload внезапно начал есть CPU

На уровне сети нужны NetworkPolicy, Calico или Cilium. По умолчанию лишний egress запрещаем, а разрешаем только то, что реально нужно сервису. Если приложению нужен только внутренний API, оно не должно свободно ходить в интернет просто потому что

На уровне допуска нужны Kyverno, OPA Gatekeeper или аналогичные Policy Engine. Они помогают не пускать в кластер странные спецификации, latest, образы из недоверенных источников, privileged Pod, hostPath и прочие подарки судьбы для злоумышленника

На уровне цепочки поставок нужны Trivy, Grype, Syft, Cosign и нормальная работа с образами

На уровне прав нужен нормальный RBAC. Если workload скомпрометировали, он не должен получить возможность читать секреты, создавать Pod или смотреть весь кластер. А если приложению вообще не нужен Kubernetes API, то ему часто не нужен и автоматически смонтированный ServiceAccount token (поэтому отключаем его там, где он не нужен)

На уровне рантайма нужны Falco, Tetragon или что-то подобное. Потому что часть событий можно увидеть только после запуска контейнера (запуск оболочки, например)

И тогда у нас каждый слой по отдельности видит только кусочек картины, тогда как вместе они фиксируют инцидент

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

Вот об этом и был мой доклад на БЕКОН 2026) Как выйдет видео с выступлением, тоже опубликую

🫡 Сайт | 🤔 Хабр

#информационная_безопасность