Исследователи обнаружили новое вредоносное ПО, нацеленное на кластеры Kubernetes для майнинга Monero

Кампания по вредоносному ПО не велась с момента его первого обнаружения в январе 2021 года, что заставляет исследователей полагать, что оно «все еще может находиться на стадии разведки и размещения оружия».

Исследователи кибербезопасности из подразделения 42, группы разведки Paolo Alto Networks, опубликовали профиль новой вредоносной кампании, нацеленной на кластеры Kubernetes и которая может использоваться для целей криптоджекинга.

Криптоджекинг — это отраслевой термин для скрытых атак криптоджекинга, которые работают путем установки вредоносного ПО, которое использует вычислительную мощность компьютера для майнинга криптовалют — часто Monero (XMR) — без согласия или ведома пользователя.

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

Unit 42 дал новому вредоносному ПО прозвище «Hildegard» и полагает что за ним стоит TeamTNT, группа, которая ранее провела кампанию по краже учетных данных Amazon Web Services и распространению скрытого приложения для майнинга Monero на миллионы IP-адресов с помощью вредоносного ботнета.

Исследователи отмечают, что в новой кампании используются инструменты и домены, аналогичные тем, которые использовались в предыдущих операциях TeamTNT, но что новое вредоносное ПО обладает инновационными возможностями, которые делают его «более скрытным и устойчивым». Хильдегард, в их техническом резюме:

«Использует два способа установления соединений управления и контроля (C2): обратная оболочка tmate и канал Internet Relay Chat (IRC); использует известное имя процесса Linux (биосет) для маскировки вредоносный процесс; использует технику внедрения библиотеки на основе LD_PRELOAD, чтобы скрыть вредоносные процессы; шифрует вредоносную полезную нагрузку внутри двоичного файла, чтобы затруднить автоматический статический анализ «.

С точки зрения хронологии, Unit 42 указывает, что домен C2 borg [.] wtf был зарегистрирован 24 декабря прошлого года, а IRC-сервер впоследствии подключился к сети 9 января. Несколько вредоносных скриптов часто обновлялись, а мощность хэширования кампании составила ~ 25,05 KH / s. По состоянию на 3 февраля подразделение 42 обнаружило, что в соответствующем кошельке хранилось 11 XMR (примерно 1500 долларов США).

Однако с момента первоначального обнаружения командой кампания была неактивной, в результате чего подразделение 42 решило, что «Кампания по угрозам может все еще находиться в стадии разведки и размещения оружия». Однако, основываясь на анализе возможностей вредоносного ПО и целевых сред, команда ожидает, что готовится крупномасштабная атака с потенциально более далеко идущими последствиями:

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

Из-за того, что кластер Kubernetes обычно содержит более одного хоста, и что каждый хост, в свою очередь, может запускать несколько контейнеров , Unit 42 подчеркивают, что взломанный кластер Kubernetes может привести к особенно прибыльной кампании криптоджекинга вредоносных программ. Для жертв захват ресурсов их системы с помощью такой кампании может вызвать серьезные нарушения.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *