Pluto Security розкрила подробиці кампанії з криптомайнінгу Load/Mine на Hugging Face

29 жовтня 2026 року дослідницька команда Pluto Security опублікувала свій звіт Load/Mine, у якому розкрила подробиці кампанії з криптомайнінгу та встановлення бекдора, що поширювалася через шкідливі репозиторії моделей на Hugging Face. У звіті йдеться про 31 шкідливий репозиторій у семи облікових записах Hugging Face, а також дзеркало на ModelScope; зафіксовано 29 818 завантажень у межах кампанії, або 32 376, якщо врахувати 13 пов’язаних репозиторіїв. Pluto зазначає, що ця цифра відображає кількість завантажень, а не підтверджених заражень чи унікальних жертв.

У звіті, авторами якого є Шакед Чен, Ейтан Хассід і Йотам Перкал, сказано, що кампанія відновилася за кілька днів після першого видалення: у 19 репозиторіях другої хвилі зафіксували понад 29 000 завантажень, і вони залишалися доступними через вісім днів після того, як Pluto повідомила про них. За даними звіту, на криптогаманець для виплат першої хвилі надійшло близько 2 276 PRL — приблизно 5 000 доларів США — у вигляді доходу від майнінгу в блокчейні.

Як виконується шкідливий код

Кампанія використовує задокументовану особливість завантаження в Transformers, а не отруєні ваги. Завантаження репозиторію за допомогою trust_remote_code=True імпортує код Python із репозиторію з правами викликувача ще до завантаження будь-яких ваг. Репозиторій config.json використовує auto_map для зазначення модуля та класу Python, які потрібно завантажити; Transformers завантажує вказаний файл у кеш модулів, а виклик exec_module() виконує код верхнього рівня у файлі, перш ніж повернути запитаний клас моделі. У звіті зазначено, що така поведінка задокументована, але не є типовою, а політика безпеки Transformers радить користувачам перевіряти вміст файлів моделі, коли використовується цей аргумент. У звіті також згадується CVE-2026-22807: у версіях vLLM від 0.10.1 до виправлення у версії 0.14.0 завантажувалися auto_map модулі без перевірки параметра trust_remote_code , що давало змогу шкідливому репозиторію виконувати код під час запуску сервера.

Виявлення та встановлення зв’язків між обліковими записами

Pluto створила сканер, який перевіряє кожен файл .py файл, на який посилається auto_map у config.json, а також файли Python, розміщені поруч із вагами моделі, і виявляє такі шаблони, як subprocess, socket, ctypes, memfd_create і декодування base64. Першою знахідкою став dsxk4mr8tq/qwen2-tiny-gpt2, що містив файл із 305 рядків під назвою modeling_evil.py; в обліковому записі було шість репозиторіїв, створених протягом 2,5 години 12 жовтня 2026 року.

Порушення в атрибуції виявили завдяки резервним файлам. У qwen2-tiny-lite репозиторії містилися modeling_evil.py.bak-src і modeling_evil.py.bak-sync, старіші версії тієї самої шкідливої програми, URL-адреси завантаження в яких вели не до одноразового облікового запису, а до hhzz667 на Hugging Face і wssb123e на ModelScope. У звіті сказано, що оператор скопіював робочий код у тестовий обліковий запис, оновив URL-адреси в основному файлі й забув про резервні копії. Перша хвиля охопила 12 репозиторіїв у трьох облікових записах і на двох платформах; до видалення зафіксували понад 700 завантажень і жодного попередження системи безпеки.

Будова шкідливого навантаження

Як репрезентативну збірку взявши MENXIANGYU/qwen2-tiny , у звіті описано шкідливе навантаження, яке спершу створює /tmp/.cch/svc.py, сторожовий процес, що перезапускає відсутній майнер кожні 120 секунд, із командами запуску, доданими до /root/.bashrc, /root/.profile і файлу .bashrc. У трьох збірках є зворотна оболонка, яка під’єднується до 212.32.253.3 через порти 443 або 9443 і повторює спробу після кожного розриву з’єднання.

Бінарний файл майнера, syscore.bin, запускається через memfd_create і fexecve маскується під робочий потік ядра kworker/u20:1, тож під час першого запуску на диску не залишається виконуваного файлу; резервна копія зберігається в /tmp/.cch/sync. Бінарний файл розміром 40,6 МБ стиснуто за допомогою UPX; у ньому два маркери UPX! змінено на PEK! , через що стандартна утиліта розпакування його відхиляє; Pluto відновила маркери й розпакувала майнер під назвою peakminer, запущений із кінцевими точками пулу та логіном krxXJ2PKQW.worker. Звіти про виконання записуються до локального реєстру моделей Xinference як qwen2-tiny- із подальшими кодами стану в base32; шкідливе навантаження також видаляє реєстрації конкуруючих майнерів і завершує відповідні процеси.

Дві хвилі та адаптація після видалення

У звіті першу хвилю пов’язують з обліковим записом hhzz667, створеним 29 квітня 2026 року й неактивним протягом п’яти місяців. 21 вересня 2026 року в ньому опублікували qwen2-shell, бекдор SSH із 37 рядків, який додавав ключ ed25519 до authorized_keys і надсилав сигнальний запит на сервер Alibaba Cloud; файл README скопіювали з офіційної картки моделі Qwen2.5-0.5B. До 22 вересня оператор уже розмістив qwen2-final, безфайловий майнер із 305 рядків, замаскований під потік ядра, зі знищувачем конкуруючих майнерів і звітуванням про стан Xinference під нейтральними назвами, зокрема Qwen2Config. Коментарі в коді були написані спрощеною китайською мовою.

Pluto повідомила про першу хвилю Hugging Face і ModelScope, після чого облікові записи видалили. Друга хвиля розпочалася за кілька днів: 19 репозиторіїв у п’яти облікових записах, зокрема MENXIANGYU із 13 репозиторіями, а також wjsbg, soumikmahato, r1r13 і htt0118; останній створили 25 жовтня 2026 року. Один із репозиторіїв, MENXIANGYU/qa-whl-1021, опублікований через 8,5 години після листа Pluto з повідомленням про виявлення, містить скрипт для виходу з контейнера на хост, який монтує диски хоста, націлюється на каталог GPUStack і /var/lib/gpustack надає змогу входити на хост із правами root. Пізніший дропер обмежує доступ до другого етапу за IP-адресою джерела: для інших запитувачів він повертає відповідь 403 із текстом «static ip.». Кількість завантажень головного репозиторію MENXIANGYU/qwen2-tiny зросла з 7 354 20 жовтня до 28 412 28 жовтня; на нього припало 97,7% завантажень другої хвилі.

Доходи від майнінгу та виявлені жертви

Гаманець першої хвилі отримав близько 2 276 PRL у межах 716 транзакцій і переказав далі приблизно 2 241 PRL. Він залишався активним на публічних панелях пулів 21 жовтня, уже після видалення репозиторіїв. На Kryptex гаманець показував двох онлайн-воркерів, які звітували peakminer/2.16.5 про приблизно 1 008 PRL — орієнтовно $2 237 у вигляді винагород за 30 днів на момент збору даних. Під час аналізу дев’ять воркерів із назвами, схожими на назви ноутбуків, приєдналися з різницею не більш як 90 секунд і припинили надсилати частки приблизно через шість хвилин. Як зазначається у звіті, така картина відповідає спільному кластеру GPU. Окремо відстежуване hl сімейство, що використовує подібне виконання під час імпорту, мало гаманець MoneroOcean із 13 воркерами; за приблизно місяць йому виплатили близько $26.

Пробіл у покритті сканерами

Жоден із 12 репозиторіїв першої хвилі не отримав позначки, а корисне навантаження головного репозиторію другої хвилі modeling_evil2.py за перевірками Pluto мало статус «safe» у кожному сканері, який його перевірив; JFrog повідомив, що це не модель машинного навчання. У документації Hugging Face зі сканування на шкідливе програмне забезпечення зазначено, що під час кожного коміту всі файли репозиторію розміром менш як 2 GB перевіряються сканером на шкідливе програмне забезпечення. У документації зі сканування pickle-файлів сказано, що сканер запускає антивірусну перевірку ClamAV і перевірку імпорту pickle-файлів, що ClamAV не захищає від експлойтів у pickle-файлах, а сканування «не є цілком безпомилковим», тож відповідальність за перевірку безпечності лежить на користувачеві. Pluto зазначає, що перевірка .py файлів, на які auto_map вказує система до встановлення позначки, виявила б усі шкідливі компоненти цієї кампанії; статична перевірка під час завантаження на наявність subprocess, socket, ctypes або звернень безпосередньо за IP-адресою у auto_mapфайлах, на які є посилання, виявила б їх раніше.

Оцінка причетності та рекомендовані кроки

Pluto вважає, що за кампанією стоїть фінансово мотивований оператор або невелика група, яка спілкується китайською мовою. На це вказують коментарі спрощеною китайською, сервер керування на Alibaba Cloud, дзеркала на ModelScope і hf-mirror.com, націленість на користувачів Xinference і Tencent Cloud, а також кластеризація активності в період із 18:38 до 21:19 UTC. Збірка «parasit» від soumikmahato містить коментарі індонезійською мовою. У звіті зазначено, що це може свідчити як про другого оператора в тій самій ніші, так і про одного оператора, який навмисно використовує лінію з іншим виглядом.

У звіті радять усім, хто завантажував одну з перелічених моделей із увімкненим користувацьким кодом, перевірити хости на наявність /tmp/.cch/, неочікуваних svc.py процесів, процесу з kworker/u20:1 аргументами для майнінгу, закодованих qwen2-tiny- або ezv- реєстрацій Xinference, а також з’єднань із зазначеними серверами й пулами. Pluto рекомендує ізолювати уражені комп’ютери, зберегти докази, видалити всі механізми закріплення в системі, змінити скомпрометовані облікові дані з чистого комп’ютера, перевстановити систему з довіреного образу, якщо цілісність хоста неможливо підтвердити, вимагати автентифікацію для API Xinference і фіксувати перевірені версії моделей. Pluto очікує нових кампаній такого типу й продовжує стежити за ними.