Зомби-эпидемия криптоджекинга: майнер Dero массово заражает контейнеры через открытые API Docker

Введение

Представьте себе зомби-эпидемию среди контейнеров: один зараженный контейнер сканирует интернет в поисках открытых API Docker, кусает их эксплуатирует их, создавая новые вредоносные контейнеры и заражая существующие. Те, в свою очередь, превращаются в новых «зомби», которые добывают криптовалюту Dero и распространяют инфекцию дальше. Доставка происходит без участия командного сервера — зараженные системы автоматически инфицируют новые, что приводит к экспоненциальному росту числа «зомби». Именно так устроена новая кампания по майнингу криптовалюты Dero.

В ходе недавнего проекта по оценке компрометации (compromise assessment — поиск незамеченных инцидентов в ИТ-инфраструктуре) мы обнаружили ряд активных контейнеров с признаками вредоносной активности. Некоторые контейнеры уже были известны аналитикам, другие — ранее не фиксировались. Как показал анализ, злоумышленники получили начальный доступ к активной контейнеризованной инфраструктуре через открытый API Docker, не защищенный должным образом. В результате были скомпрометированы существующие контейнеры и развернуты новые — не только для майнинга криптовалюты на ресурсах жертвы, но и для проведения внешних атак с целью распространения в других сетях.

На схеме ниже изображен вектор атаки:

Цепочка заражения

Атака полностью автоматизирована и полагается на два вредоносных компонента: ранее неизвестный зловред-распространитель под названием nginx и криптомайнер Dero. Оба образца написаны на языке Go и упакованы с помощью UPX. Решения «Лаборатории Касперского» детектируют эти вредоносные компоненты со следующими вердиктами:

• nginx — Trojan.Linux.Agent.gen;
• криптомайнер Dero — RiskTool.Linux.Miner.gen.

Зловред-распространитель nginx

Этот зловред отвечает за закрепление майнера в системе и его дальнейшее распространение на внешние системы. Таким образом, для доставки импланта не требуется командный сервер. Задача nginx — распространять полезную нагрузку среди всех пользователей с открытым доступом к API Docker через интернет без надлежащей защиты.

Злоумышленники назвали этот компонент «nginx», чтобы замаскировать его под широко известный легитимный веб-сервер nginx и таким образом избежать обнаружения пользователями и средствами защиты. В нашей статье все последующие упоминания «nginx» относятся именно к этому зловреду.

После распаковки nginx мы проанализировали метаданные бинарного файла Go и смогли определить путь к исходному файлу на момент компиляции — /root/shuju/docker2375/nginx.go.

Файл с исходным кодом nginx

Заражение контейнера

Зловред начинает свою работу с создания лог-файла по пути /var/log/nginx.log.

Создание лог-файла

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

Лог работы вредоносного ПО

Затем в отдельном процессе запускается функция main.checkVersion, которая бесконечно проверяет, чтобы содержимое файла /usr/bin/version.dat в скомпрометированном контейнере всегда оставалось равным 1.4. При любом изменении функция немедленно перезаписывает файл.

Проверка наличия файла version.dat и соответствия его содержимого значению «1.4»

Если файл version.dat отсутствует, функция создает его с содержимым 1.4, а затем бездействует 24 часа до следующей проверки.

Создание version.dat в случае его отсутствия

Файл version.dat позволяет зловреду определять уже зараженные контейнеры — этот механизм мы рассмотрим далее.
Затем nginx запускает функцию main.monitorCloudProcess, которая в отдельном процессе бесконечно проверяет, запущен ли процесс с именем cloud, — это и есть криптомайнер Dero. Сначала образец проверяет, активен ли процесс cloud. Если он не запущен, nginx вызывает функцию main.startCloudProcess, чтобы активировать майнер.

Мониторинг и запуск процесса cloud

Чтобы запустить майнер, функция main.startCloudProcess пытается найти его по пути /usr/bin/cloud.

Запуск майнера

Распространение заражения

Поиск хостов

Затем nginx входит в бесконечный цикл генерации случайных подсетей IPv4 с маской /16 — зловред сканирует их и пытается скомпрометировать с помощью функции main.generateRandomSubnet.

Бесконечный цикл генерации и сканирования подсетей

Подсети с соответствующими диапазонами IP-адресов передаются в функцию main.scanSubnet, которая сканирует их с помощью портового сканера masscan, установленного в контейнере зловредом, — подробнее об этой утилите мы расскажем позже. Сканер ищет небезопасно опубликованные API Docker для заражения подсетей, используя следующую команду: masscan -p 2375 -oL — —max-rate 360.

Сканирование сгенерированной подсети с помощью masscan

Выходные данные masscan анализируются с помощью регулярных выражений для извлечения IPv4-адресов с открытым стандартным портом API Docker (2375). Затем извлеченные IPv4-адреса передаются в функцию main.checkDockerDaemon. Она проверяет, работает ли удаленный демон dockerd на хосте с соответствующим IPv4-адресом и доступен ли он. Для этого зловред пытается получить список всех работающих контейнеров на удаленном хосте с помощью команды docker -H PS. Если попытка завершается сбоем, nginx переходит к следующему IPv4-адресу.

Удаленное перечисление работающих контейнеров

Создание контейнера

После подтверждения работоспособности и доступности удаленного демона dockerd зловред nginx генерирует имя из 12 случайных символов и под этим именем создает вредоносный контейнер на удаленной машине.

Генерация имени контейнера

Вредоносный контейнер создается с помощью следующей команды: docker -H run -dt —name —restart always ubuntu:18.04 /bin/bash. В команде есть флаг --restart always для автоматического запуска созданных контейнеров при их завершении.

Создание вредоносного контейнера на новом хосте

Затем nginx подготавливает контейнер для последующей установки зависимостей, обновляя пакеты с помощью команды docker -H exec apt-get -yq update.

Обновление пакетов контейнера

После этого зловред выполняет команду docker -H exec apt-get install -yq masscan docker.io, чтобы установить в контейнер зависимости masscan и docker.io. Эти пакеты нужны вредоносному ПО для взаимодействия с демоном Docker и внешнего сканирования с целью заражения других сетей.

Удаленная установка зависимостей вредоносного ПО в созданный контейнер

Далее образец переносит в контейнер два вредоносных компонента, nginx и cloud, с помощью команды docker -H cp -L /usr/bin/ :/usr/bin.

Перенос nginx и cloud в созданный контейнер

Для закрепления в системе зловред вносит перенесенный бинарный файл nginx в список алиасов /root/.bash_aliases, чтобы он автоматически запускался при входе в оболочку. Это делается с помощью команды docker -H exec bash –norc -c \'echo \"/usr/bin/nginx &\" > /root/.bash_aliases\'.

Добавление nginx в .bash_aliases для закрепления в системе

Компрометация работающих контейнеров

До этого момента зловред лишь создавал новые зараженные контейнеры. Далее он будет пытаться скомпрометировать существующие контейнеры на базе ubuntu:18.04. Сначала образец выполняет функцию main.checkAndOperateContainers, чтобы проверить все работающие контейнеры на удаленном хосте на соответствие следующим условиям: контейнер должен быть основан на образе ubuntu:18.04 и не содержать файл version.dat, являющийся индикатором предыдущего заражения.

Перечисление и компрометация существующих контейнеров на удаленном хосте

Если условия выполнены, вредоносное ПО запускает функцию main.operateOnContainer, чтобы по описанному ранее принципу заразить работающий контейнер. Цепочка заражения повторяется: ресурсы контейнера используются для сканирования и компрометации других контейнеров, а также для майнинга криптовалюты Dero.

Это позволяет зловреду обходиться без связи с командным сервером и оставаться активным, пока в интернете существуют открытые API Docker без защиты, через которые можно скомпрометировать работающие контейнеры и разворачивать новые.

cloud — майнер Dero

Основной целью nginx является запуск и обеспечение работы криптомайнера cloud. Майнер также написан на языке Go и упакован с помощью UPX. После распаковки бинарного файла мы установили, что он относится к проекту DeroHE CLI с открытым исходным кодом, доступному на GitHub. Злоумышленник обернул майнер DeroHE CLI в компонент cloud, добавив в его код конфигурацию для добычи криптовалюты, которая включает адреса кошелька и узла DeroHE (derod).

Если майнер cloud не получает адреса в качестве аргументов, он будет использовать заданную зашифрованную конфигурацию по умолчанию, что мы и наблюдали в этой кампании. Конфигурация хранится в виде строки в кодировке Base64, дополнительно зашифрованной алгоритмом AES-CTR. Она содержит адрес кошелька, еще раз закодированный при помощи Base64. Для расшифровки строки используется функция main.decrypt. Шифрование конфигурации указывает на попытки злоумышленников усложнить зловред, поскольку мы не наблюдали подобных способов в предыдущих кампаниях.

Расшифровка адреса криптовалютного кошелька

После расшифровки и декодирования строки мы обнаружили адрес кошелька: dero1qyy8xjrdjcn2dvr6pwe40jrl3evv9vam6tpx537vux60xxkx6hs7zqgde993y.

Поведенческий анализ функции расшифровки

Затем вредоносное ПО расшифровывает две другие зашифрованные AES-CTR строки с помощью функции main.sockz, чтобы получить адреса узлов Dero.

Вызовы функций для расшифровки адресов

Адреса узлов зашифрованы так же, как и адрес кошелька, но с другими ключами. После расшифровки нам удалось получить следующие адреса:
d.windowsupdatesupport[.]link и h.wiNdowsupdatesupport[.]link.

Расшифрованные адреса в памяти

Тот же адрес кошелька и адреса узлов derod ранее встречались в кампании, нацеленной на кластеры Kubernetes с включенной анонимной аутентификацией в API Kubernetes. Вместо внедрения зловреда в скомпрометированный контейнер злоумышленники запрашивали вредоносный образ со встроенным майнером под названием pauseyyf/pause:latest, размещенный на Docker Hub. На основе этого образа создавался вредоносный контейнер. В отличие от текущей кампании, злоумышленники не пытались распространяться внутри сети или сканировать интернет с целью компрометации других сетей. Эти атаки имели место в 2023 и 2024 годах с незначительными различиями в техниках.

Выводы

Хотя атаки на контейнеры случаются не так часто, как на другие системы, это не делает их менее опасными. В рассматриваемой кампании контейнеризованные среды были скомпрометированы комбинацией ранее известного майнера и нового вредоносного ПО, которое как создает новые зараженные контейнеры, так и инфицирует уже существующие. Оба вредоносных компонента распространяются без использования командного сервера, что ставит под удар любую сеть с контейнеризованной инфраструктурой и небезопасно открытым для интернета API Docker.
Согласно анализу Shodan, в апреле 2025 года по всему миру было открыто для доступа из интернета 520 API Docker, опубликованных на порте 2375. Это дает представление о разрушительном потенциале описанной угрозы и подчеркивает необходимость тщательного мониторинга контейнеров и их надежной защиты.

API Docker, опубликованные на порте 2375, по всему миру, январь–апрель 2025 г. (скачать)

Создание контейнеризованной инфраструктуры исключительно на основе известных легитимных образов не гарантирует ее безопасность. Как и любая другая система, контейнеризованные приложения могут быть скомпрометированы во время работы. Поэтому для отслеживания состояния контейнеризованной инфраструктуры крайне важно использовать эффективные инструменты, например Kaspersky Container Security. Наше решение обнаруживает неправильные настройки и проверяет образы в реестре, обеспечивая безопасность контейнерных сред. Мы также рекомендуем применять проактивный поиск угроз для выявления скрытых вредоносных действий и инцидентов, которые могли остаться незамеченными в сети. Сервис Kaspersky Compromise Assessment помогает не только выявлять подобные инциденты, но и оперативно реагировать на них, устраняя последствия и минимизируя ущерб.

Индикаторы компрометации

Хэш-суммы файлов
094085675570A18A9225399438471CC9  nginx
14E7FB298049A57222254EF0F47464A7   cloud

Пути к файлам
Примечание. Некоторые пути файлов в индикаторах компрометации могут привести к ложным срабатываниям из-за используемой техники маскировки.
/usr/bin/nginx
/usr/bin/cloud
/var/log/nginx.log
/usr/bin/version.dat

Адреса узлов derod
d.windowsupdatesupport[.]link
h.wiNdowsupdatesupport[.]link
Адрес кошелька Dero
dero1qyy8xjrdjcn2dvr6pwe40jrl3evv9vam6tpx537vux60xxkx6hs7zqgde993y