Мащабна операция за добив на криптовалута е компрометирала 3562 Redis сървъра и е превърнала тяхната изчислителна мощност в източник на приходи в Monero.

Кампанията не разчита на новооткрита софтуерна уязвимост. Вместо това тя е насочена към достъпни през интернет Redis инстанции, които приемат команди без автентификация.

Атакуващите са сканирали 12 966 потенциални цели, след което са използвали функциите за репликация на Redis, за да внедрят насрочена задача (scheduled task), която изтегля и стартира зловреден код за добив (miner).

Резултатът може да бъде по-бавно работещи приложения, необичайно високо използване на процесора, по-високи сметки за облачни услуги и риск от нарушаване на нормалните данни в Redis.

Изследователи от Hunters.io са идентифицирали кампанията, след като са открили открита директория, съдържаща 147 файла, включително експлойт код и логове от кампанията.

От Hunters.io заявяват в доклад, споделен с Cyber Security News (CSN), че записите предоставят необичайно ясна представа за това как е била изградена, тествана и измервана операцията.

Логовете показват, че две големи серии от атаки са компрометирали съответно 3388 и 2862 хоста, с припокриване между тях. Това оставя 3562 уникални жертви.

Пълната верига на атаката (Източник - Hunters.io)
Пълната верига на атаката (Източник – Hunters.io)

Засегнатите системи обхващат версии на Redis от 2.8.17 до 7.2.0, което показва, че конфигурацията, а не конкретна уязвима версия, е била основният проблем.

Redis сървъри, превърнати в копачи на криптовалута

Основната атака е злоупотребила с репликацията master-replica в Redis. След като потвърдили, че даден сървър не изисква парола, атакуващите променили мястото, където Redis записва своите данни, и го насочили да копира съдържание от фалшив (rogue) сървър.

Получените данни са създали cron задача – малък запис в планирача на Linux, който многократно изпълнява команди. На всеки пет минути задачата е изтегляла XMRig, преименувала го е, за да го скрие сред временните файлове, и го е свързвала с пул за добив през криптиран порт 443.

Този подход може да направи трафика да изглежда по-малко необичаен в сравнение с добива през специализиран порт. Той повтаря модела, описан в по-ранна кампания за криптоджакинг срещу Redis, където откритите и лошо защитени инстанции също са били началната точка.

Атакуващите са използвали няколко резервни места за насрочената задача. Те също така са тествали начини за добавяне на SSH ключове и използване на скриптове в Redis, но тези опити не са довели до потвърдени компрометирания в голям мащаб.

Успешният метод за репликация е от значение, тъй като използва легитимна функция, която остава налична във множество версии.

Откриване на Redis хостове и проверка на автентификацията при цели, достъпни през интернет (Източник - Hunters.io)
Откриване на Redis хостове и проверка на автентификацията при цели, достъпни през интернет (Източник – Hunters.io)

Въздействието надхвърля откраднатите изчислителни ресурси. По време на атаката променените настройки за запис на Redis могат да попречат на нормалните снимки (snapshot файлове) на данните.

Поради това организациите, разчитащи на персистентност в Redis, могат да се сблъскат с риск от загуба на данни наред със спада в производителността. Подобно злоупотребяване с репликацията наскоро бе наблюдавано и при атаките срещу публично достъпен Redis от P2PInfect, което подчертава защо излагането на Redis в интернет е опасно.

Приоритети за защита и откриване на заплахи

Защитниците трябва първо да премахнат директния достъп до Redis от интернет, да го ограничат до доверени мрежи и да изискват автентификация.

Когато репликацията не е необходима, администраторите трябва да ограничат или преименуват командата SLAVEOF или REPLICAOF и да държат защитения режим (protected mode) включен. Самото обновяване няма да реши този конкретен проблем с излагането на рискове, въпреки че инсталирането на корекции за сигурност остава важно за други рискове.

Екипите трябва да проверят cron директориите и потребителските crontab файлове за неочаквани препратки към инструменти за изтегляне, извличане на архиви или софтуер за добив на криптовалута.

Те трябва също така да прегледат настройките на Redis за необичайни директории с данни или имена на файлове, след което да потърсят неоторизирани APT куки (hooks) и скриптове за вход в обвивката (login-shell).

По-широкият извод се появява и в доклада за активността по добив на RedisRaider, който документира как атакуващите превръщат слабите контроли за достъп до Redis в изпълнение на код.

Мрежовият мониторинг може да помогне за идентифициране на системи, които вече са били засегнати. Екипите по сигурност трябва да разследват неочаквани HTTP връзки към инфраструктурата на кампанията, криптиран трафик от добив на криптовалута и продължителна консумация на процесорен ресурс от процеси, изпълнявани от временни директории.

Софтуерът за добив е легитимен софтуер, с който се злоупотребява – тенденция, видима и в кампанията за добив с XMRig за Linux, така че откриването трябва да се фокусира върху поведението, а не само върху името на файла.

Пълната реакция трябва да включва изолиране на сървъра, спиране на зловредните процеси, премахване на всеки механизъм за персистентност, ротация на идентификационните данни за Redis и свързаните с него системи, както и преглед на целостта на данните преди връщането на хоста в експлоатация.

Администраторите трябва също да проверят местата за SSH ключове на сервизните акаунти, тъй като намерените инструменти на атакуващите са опитали да поставят ключове извън обичайните пътища на root акаунта за осигуряване на последващ достъп.

Индикатори за компрометиране (IoCs):-

ТипИндикаторОписание
IP адрес188.245.99.156Хост на оператора, използван за дублиране на компрометиран Redis, командване и контрол (C2) и стейджинг на злонамерен код
IP адрес и порт188.245.99.156:10000Точка за обратна връзка (callback endpoint) за командване и контрол
IP адрес и порт диапазон188.245.99.156:16379-16385Слушащи портове за дублиране на компрометиран Redis
URL шаблонhttp://188.245.99.156:10000/ping?h=<hostname>Шаблон на заявката за регистрация (check-in) на жертвата
IP адрес и порт45.155.102.89:10128Локално прокси за пул за копаене, използвано на хоста на оператора
Домейн и портpool.moneroocean.stream:443Точка на пула за копаене, използвана от внедрения чрез ботнет XMRig
Домейн и портsocket.ayakliborsa.net:8081Активно хост име под контрола на оператора, насочващо към 188.245.99.156
IP адрес47.250.92.230Често преизползвана QA или тестова цел, собствеността не е потвърдена
IP адреси34.166.99.116, 20.198.10.42, 213.6.207.123, 173.212.244.25Допълнително наблюдавани цели за разработка и QA
IP адрес23.235.223.49Периодично атакувана цел с експлоатация на WordPress
IP адрес и порт194.48.248.105:8081По-ранна отворена директория, свързана чрез повторно използване на портфейл за криптовалута
Хост имеWIN-F13ECU568VFИдентификатор на Windows хост, наблюдаван в RDP сертификата
TLS отпечатък420c7850e09b7c2b9e39e2a93e204e3c56bcf08a685ff1daa986e3c348da5d2aФиксиран (pinned) отпечатък на сертификата на пула за копаене в най-новия злонамерен код
URLhttps://github.com/xmrig/xmrig/releases/download/v6.22.2/xmrig-6.22.2-linux-static-x64.tar.gzЛокация за изтегляне на XMRig, реферирана от злонамерения код
Файлов път/etc/cron.d/redis-minerОсновен път за персистентност (постоянно присъствие) базиран на cron
Файлов път/etc/cron.hourly/redis-minerРезервен (fallback) cron път за персистентност
Файлови пътища/etc/cron.d/redis-update, /var/spool/cron/root, /var/spool/cron/crontabs/rootДопълнителни локации за персистентност чрез cron
Файлови пътища/root/.ssh/authorized_keys, /home/redis/.ssh/authorized_keys, /var/lib/redis/.ssh/authorized_keysЦели за инжектиране на SSH ключове
Файлов път/etc/apt/apt.conf.d/99sys-updateПът за персистентност чрез APT hook
Файлов път/etc/profile.d/sys-init.shПът за персистентност чрез login-shell
Файлови именаtmp.xmrig, tmp.xrИмена на скрити бинарни файлове на XMRig
Файлови именаc2persist.py, rogue.py, boot.py, redisminer.py, s.phpВъзстановени инструменти от кампанията и файлове, свързани със злонамерения код

Забележка: IP адресите и домейните са нарочно неутрализирани (defanged, напр. [.]), за да се предотврати случайно разрешаване или създаване на хипервръзки. Възстановете ги в активен вид (re-fang) само в рамките на контролирани платформи за разузнаване на заплахи като MISP, VirusTotal или вашия SIEM.