Мащабна операция за добив на криптовалута е компрометирала 3562 Redis сървъра и е превърнала тяхната изчислителна мощност в източник на приходи в Monero.
Кампанията не разчита на новооткрита софтуерна уязвимост. Вместо това тя е насочена към достъпни през интернет Redis инстанции, които приемат команди без автентификация.
Атакуващите са сканирали 12 966 потенциални цели, след което са използвали функциите за репликация на Redis, за да внедрят насрочена задача (scheduled task), която изтегля и стартира зловреден код за добив (miner).
Резултатът може да бъде по-бавно работещи приложения, необичайно високо използване на процесора, по-високи сметки за облачни услуги и риск от нарушаване на нормалните данни в Redis.
Изследователи от Hunters.io са идентифицирали кампанията, след като са открили открита директория, съдържаща 147 файла, включително експлойт код и логове от кампанията.
От Hunters.io заявяват в доклад, споделен с Cyber Security News (CSN), че записите предоставят необичайно ясна представа за това как е била изградена, тествана и измервана операцията.
Логовете показват, че две големи серии от атаки са компрометирали съответно 3388 и 2862 хоста, с припокриване между тях. Това оставя 3562 уникални жертви.

Засегнатите системи обхващат версии на Redis от 2.8.17 до 7.2.0, което показва, че конфигурацията, а не конкретна уязвима версия, е била основният проблем.
Redis сървъри, превърнати в копачи на криптовалута
Основната атака е злоупотребила с репликацията master-replica в Redis. След като потвърдили, че даден сървър не изисква парола, атакуващите променили мястото, където Redis записва своите данни, и го насочили да копира съдържание от фалшив (rogue) сървър.
Получените данни са създали cron задача – малък запис в планирача на Linux, който многократно изпълнява команди. На всеки пет минути задачата е изтегляла XMRig, преименувала го е, за да го скрие сред временните файлове, и го е свързвала с пул за добив през криптиран порт 443.
Този подход може да направи трафика да изглежда по-малко необичаен в сравнение с добива през специализиран порт. Той повтаря модела, описан в по-ранна кампания за криптоджакинг срещу Redis, където откритите и лошо защитени инстанции също са били началната точка.
Атакуващите са използвали няколко резервни места за насрочената задача. Те също така са тествали начини за добавяне на SSH ключове и използване на скриптове в Redis, но тези опити не са довели до потвърдени компрометирания в голям мащаб.
Успешният метод за репликация е от значение, тъй като използва легитимна функция, която остава налична във множество версии.

Въздействието надхвърля откраднатите изчислителни ресурси. По време на атаката променените настройки за запис на 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) отпечатък на сертификата на пула за копаене в най-новия злонамерен код |
| URL | https://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.