Неприятная история случилась с Kong Ingress Controller (довольно популярный Ingress Controller для Kubernetes, поставляется в виде docker образа) в конце прошлого года – в прод попал образ, содержащий в себе майнер XMRig. Эта история сильно напоминает инцидент с SolarWinds, который случился в 2020 году. Тогда злоумышленники снабдили платформу Orion для Windows, предназначенную для централизованного мониторинга и управления, вредоносным обновлением. В результате множество клиентов SolarWinds установили зараженную версию платформы и, сами того не зная, впустили хакеров в свои сети.

Мы решили подсветить кейс с Kong Ingress Controller через призму Luntry и показать наши возможности, как мы это уже делали с инцидентом в xz-utils, прогремевшем в прошлом году. Но для начала восстановим таймлайн.

1. 28 августа 2024 года разработчики из Kong исправляют свои пайплайны, меняя pull_request на pull_request_target.
2. 25 ноября 2024 года они получают анонимный отчет от исследователя безопасности о том, что их репозиторий подвержен атаке Pwn request. После этого мейнтейнеры провели ротацию всех секретов в репозитории и вернули триггерное событие обратно на pull_request. Но только для главной ветки. Так что старые неиспользуемые ветки продолжили использовать pull_request_target, а значит были уязвимы.
3. Спустя почти два месяца, а именно 23 декабря 2024 года, атакующие начали разведку – они получили доступ к секретам, в том числе к персональному токену доступа GitHub, проэксплуатировав уязвимость в одном из репозиториев.
4. Примерно через 22 часа – 24 декабря злоумышленники перешли на основной репозиторий с полученным на предыдущем шаге access token. Они запушили образ io/kong/kubernetes-ingress-controller на Dockerhub с тегом 3.4.
5. 29 декабря 2024 года 4 пользователя отметили в issue на GitHub, что запуск Kong Ingress Controller приводит к аномально высокой нагрузке на CPU.
6. 2 января 2025 мейнтейнеры подтвердили, что образ был скомпрометирован, а вунтри него содержался XMRig.

Более подробно обо всей ситуации можно почитать в блоге KIC. Также было опубликовано YARA правило для обнаружения таких нагрузок.

Мы хотели воспроизвести это у себя, но столкнулись с некоторыми сложностями. В ходе расследования образ был удален, и в публичном доступе найти его не представлялось возможным. Однако, авторы поделились YARA правилом для обнаружения вредоносной версии. В самом правиле они оставили хэш:

По этому хэшу файл достаточно легко ищется на Virus Total:

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

Из интересного, атакующие оставили пасхалку для всех, кто посмотрит логи контейнера, запущенного на базе вредоносного образа:

Скачав бинарь с VT, нам осталось воспроизвести оригинальный образ. Для этого обратимся к Dockerfile из репозитория kubernetes-ingress-controlller. Этапы сборки самого бинаря нам не интересны, так что можем их пропустить. Останавливаемся на последнем этапе и подменяем в Dockerfile инструкцию COPY, так чтобы там оказался вредоносная нагрузка с VT. Итоговый Dockerfile будет выглядеть так:

В Luntry, помимо создания SBOM, сканирования на известные уязвимости, мисконфигурации, чувствительную информацию в образах, есть также функциональность для поиска вредоносных файлов и файлов двойного назначения, которая сделана специально с учетом Linux и контейнерной специфики. Это сделано для того, чтобы негативно не влиять на рабочее окружение и пользовательские приложения. Эта возможность базируется на YARA правилах, где можно использовать как наш собственный feed, так и добавлять собственные проверки.

После запуска сканирования по расписанию результаты сканирования можно посмотреть на вкладке Images -> Registry Images

Ранее мы уже упоминали о том, что злоумышленники используют memfd для запуска майнера. memfd (memory file descriptor) — это механизм в Linux, позволяющий создавать анонимные временные файлы в оперативной памяти, которые не отображаются в файловой системе. Эти файлы создаются с помощью системного вызова memfd_create, поддерживаемого начиная с ядра Linux 3.17, и предоставляют удобный способ работы с данными как с файловыми объектами без записи их на диск. Файлы, созданные с помощью memfd, автоматически удаляются при закрытии дескриптора. Использование такого способа запуска процесса (прямиком из памяти) позволяет обойти большинство традиционных антивирусных решений, поэтому пользуется популярностью у злоумышленников, например при Fileless Attack. Важно понимать, что легитимное ПО вряд ли будет использовать этот механизм.

В Luntry, использование memfd можно обнаружить как на базе поведенческого движка, так и на базе сигнатурных правил. Так это выглядит в нашей модели поведения, обученной на вредоносном образе: