3x-ui Server Infected by Trojan, Used as a Mining Server

3x-ui project repository: https://github.com/MHSanaei/3x-ui
It is a forked and further modified version based on x-ui. Like other x-ui fork projects, it updates the core and supports new protocols and multi-user functionality. However, a practical feature added later in 3x-ui is the ability to modify the xray core, which will be discussed later. In terms of UI aesthetics and animation smoothness, 3x-ui is on another level compared to other proxy panel setups.

Some time ago, a critical vulnerability in 3x-ui was disclosed, resulting in many servers being compromised. My server was infected and had mining software installed. Initially, using a terminal tool, finalshell, when logging into 3x-ui, I noticed the CPU usage was constantly at 100%.

Then I used the command-line top to check running processes and found one process consuming 96.4% CPU, named system. On Debian servers, system processes are usually named systemd, so this raised my suspicion.

So I took the issue to ChatGPT for advice.

VPS Provider	Lowest Price	Features	Payment Methods
BWG Bandwagon	$49.99/year	Fastest, Most Stable	WeChat, Alipay, PayPal, Credit Card
DMIT	$36.9/year	CN2 GIA, Hong Kong CMI lines	Alipay, PayPal, Credit Card
hostdare	$16/year	High bandwidth, fast CMI lines	Alipay, PayPal, Credit Card
BuyVM	¥18	Large disk, unlimited bandwidth, streaming unlock	Alipay, PayPal, Credit Card, Crypto
RackNerd	$8.89/year	Cheap, high bandwidth, high specs	Alipay, PayPal, Credit Card, Crypto
CloudCone	$13.99/month	Cheap, large bandwidth, big disk	Alipay, PayPal, Credit Card
Vultr	$5/month	Multiple global data centers, $100 free credit	Alipay, PayPal, Crypto

This is a rough handling procedure provided by ChatGPT:

Your process info:

PID: 511620
USER: root
CPU: 96.7%
TIME+: 7d+9h
COMMAND: system

Notes:

Process name system is not a normal Linux system daemon name
- The core Linux system daemon is systemd (not system), so this is suspicious.
- Many mining trojans or malicious scripts disguise themselves with names like system, kworker, or bash.
Running for 7 days 9 hours with high CPU usage
- Long-lasting high usage often means a malicious mining process or a runaway loop.
User is root
- Indicates the malware might have gained root privileges, increasing damage potential.

Identify it first

Run:

ps -fp 511620

Check the full path and startup command.

Then:

ls -l /proc/511620/exe

See where the executable is located.

To check network connections:

netstat -pantu | grep 511620

ss -pantu | grep 511620

If confirmed malicious

Kill the process immediately

kill -9 511620

Delete its file If the file pointed by /proc/511620/exe still exists, delete it:

rm -f /path/to/file

Clean startup entries Check scheduled tasks and autostart:

crontab -l
ls /etc/cron* -R
cat /etc/rc.local
systemctl list-unit-files | grep enabled

Check suspicious users

cat /etc/passwd | grep -v '/nologin'

Prevent reinfection

Update system:

apt update && apt upgrade -y

Change root password:

passwd

Disable root remote SSH login (edit /etc/ssh/sshd_config, set PermitRootLogin no, then systemctl restart ssh).
Install fail2ban or similar anti-brute-force tools.

I suspect your system process is a mining trojan. If you want, I can write a one-click detection and cleanup script for Debian 11 to scan and kill malicious mining processes.

Do you want me to write that? It will solve the CPU usage issue immediately.

Based on ChatGPT’s advice, I found the mining trojan: a Monero miner disguised as a system process.

Below are ChatGPT’s instructions to kill the trojan process, delete files, and clean startup items.

I confirmed from your full startup command this is a Monero (XMR) mining trojan.

Evidence

./Download/system The program is located in your server’s Download directory and disguised as system.
-o pool.hashvault.pro:443 hashvault.pro is a Monero mining pool domain.
-u 8AMoGmzK... This is the attacker’s wallet address; your server is mining for them.
-k --tls These are typical xmrig miner parameters (TLS encrypted transmission).

What to do now

1. Kill the process immediately

kill -9 511620

2. Delete the mining program

rm -f /root/Download/system

If unsure of the directory:

ls -l /root/Download

3. Find similar files (prevent backups)

find / -type f -name "system" -o -name "xmrig" 2>/dev/null

4. Check startup items (prevent auto-relaunch)

crontab -l
ls -l /etc/cron* /var/spool/cron* 2>/dev/null
grep -r "Download/system" /etc/ 2>/dev/null

5. Check suspicious services

systemctl list-units --type=service | grep system

6. Change passwords to prevent reinfection

passwd

Also recommended to disable root SSH login by editing:

nano /etc/ssh/sshd_config

Modify:

PermitRootLogin no

Save and restart SSH:

systemctl restart ssh

The trojan hides deeply.

From your /etc/cron.* content, no direct mining cron job was found, so it might be in the user crontab or systemd startup, not in /etc/cron.d folders.

I suggest continuing with:

1. Check root user’s crontab

crontab -l -u root

If there is a command running Download/system or xmrig, delete all lines.

Edit with:

crontab -e -u root

2. Search all cron files for mining commands

grep -r "Download/system" /etc/cron* /var/spool/cron* 2>/dev/null

3. Check systemd autostart services

Mining trojans often disguise as services like system-update.service or network.service:

systemctl list-unit-files --type=service | grep enabled
systemctl status system
systemctl status system-update

If any points to Download/system or unknown paths, disable and delete:

systemctl disable --now service_name
rm -f /etc/systemd/system/service_name
systemctl daemon-reload

4. Check `rc.local` and boot scripts

cat /etc/rc.local
ls -l /etc/init.d/
grep -r "Download/system" /etc/init.d/

5. Prevent reinfection

Change password: passwd
Disable root SSH login (edit /etc/ssh/sshd_config, set PermitRootLogin no)
Enable key-based login only (PasswordAuthentication no)
Install fail2ban for SSH brute-force protection:

apt install fail2ban -y

If you want, I can write a Debian 11 mining trojan auto-cleanup script to:

Kill mining processes
Delete mining files
Clean crontab, systemd, rc.local entries
Harden SSH config

This way you won’t need to manually check and can prevent trojan restarting after reboot.

Do you want me to prepare that one-click cleanup script? Your CPU usage will normalize right after running it.

Finally, delete the daemon process, manage scheduled tasks, change admin password, and reboot the server.

Your crontab first line is the mining trojan’s scheduled task:

* * * * * pgrep -x ibus || exec /root/.cache/ibus/ibus &

Meaning:

Every minute check if process named ibus exists
If not, run /root/.cache/ibus/ibus (actually the mining trojan disguised as input method ibus)
Even if you kill it, it will restart in one minute

The second line ~/.acme.sh/acme.sh --cron is a normal certificate renewal task, not malware.

Cleanup steps

Remove trojan crontab task

crontab -e -u root

Delete the line:

* * * * * pgrep -x ibus || exec /root/.cache/ibus/ibus &

Save and exit.

Kill running trojan process

pkill -f "/root/.cache/ibus/ibus"

Delete trojan files

rm -rf /root/.cache/ibus

Check if systemd has Trojan auto-start

systemctl list-unit-files --type=service | grep ibus
systemctl status ibus

If you find any suspicious ibus service:

systemctl disable --now ibus
rm -f /etc/systemd/system/ibus.service
systemctl daemon-reload