CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's

The main thread regarding the gsocket hacking should have most of the details you need. Also the CWP-provided script should do a lot for you automatically. Do you need help cleaning up your server?

I have removed 3 entries from /etc/hosts
127.0.0.1 mya.cloudsyndication.org
127.0.0.1 gsocket.io
127.0.0.1 www.gsocket.io

and I have upgraded apache to version 2.4.66.
I have also checked numerous files on server, but I didn't find something suspicious.
Everything seems to work fine by now, but I am not sure if server is 100% clean.
Can you suggest something else that I should check?
Thank you

Hacker used CWP to get into server, not centos.
Not to mention that centos 8 is one of the OS that CWP recommends.

Anyhow, CWP was patched but hacker was already in.
Any suggestions on how to clean server?

https://forum.centos-webpanel.com/centos-webpanel-bugs/i-think-there-is-a-very-serious-security-vulnerability-in-cwp-right-now/msg53492/#msg53492

I have removed 3 entries from /etc/hosts
127.0.0.1 mya.cloudsyndication.org
127.0.0.1 gsocket.io
127.0.0.1 www.gsocket.io

Those entries are intentional, created by the CWP cleanup script -- they blackhole the known C&C infrastructure of the hackers. Best to leave them in place.

I have removed 3 entries from /etc/hosts
127.0.0.1 mya.cloudsyndication.org
127.0.0.1 gsocket.io
127.0.0.1 www.gsocket.io

and I have upgraded apache to version 2.4.66.
I have also checked numerous files on server, but I didn't find something suspicious.
Everything seems to work fine by now, but I am not sure if server is 100% clean.
Can you suggest something else that I should check?
Thank you

Sorry you got hit too. This is the same compromise being tracked in the big "I think there is a very serious security vulnerability in CWP right now" thread - same gsocket C2, same IOCs. We cleaned it across our own fleet. Removing the /etc/hosts lines and restarting Apache does nothing: those entries are cosmetic, and the infected files get re-infected within 2-3 minutes as long as the persistence is alive. So order matters - kill persistence FIRST, then clean.

The hard truth first: once an attacker had a root C2 on the box, you can't fully trust that OS again - modified binaries, a hidden rootkit or backdoored packages are all possible. The only way to be 100% sure is a fresh rebuild on a supported OS (you are on CentOS Linux 8.5.2111, EOL, no security updates - move to AlmaLinux 8 or Rocky 9/10 anyway), migrating data only after scanning, rotating every credential, then repointing DNS. That is what we did for our worst-hit box.

If you clean in place, here is the checklist that worked, in this order:

0. Apply the official fix + close the entry points
Run the CWP updater TWICE (some users still got reinfected on 0.9.8.1231; you want 0.9.8.1235+):

Code: [Select]

sh /scripts/update_cwp && sh /scripts/update_cwpThe likely entry vector is Roundcube (CVE-2025-49113) - and CWP re-bundles a vulnerable Roundcube on install, so update it and close webmail (2095/2096) to the public. Close the panel ports too (2030/2031, 2082-2087) - restrict to your IP, or reach them only through an SSH tunnel. The gsocket C2 is outbound, so the firewall never stopped it.

1. Kill the gsocket persistence (do this BEFORE cleaning files)
The C2 ships as a service named defunct.service, running gsocket from /usr/bin/defunct with config /lib/systemd/system/defunct.dat, and hides its process as a fake kernel thread (a bracketed name such as mm_percpu_wq in ps auxf).

Code: [Select]

systemctl stop defunct.service; systemctl disable defunct.service
rm -f /usr/bin/defunct /lib/systemd/system/defunct.dat
rm -f /usr/lib/systemd/system/defunct.service /etc/systemd/system/multi-user.target.wants/defunct.service
systemctl daemon-reload
ps auxf | grep -Ei 'mm_percpu_wq|defunct|gs-netcat'   # must be empty now
ss -tnp                                               # no outbound to the C2 IPs belowThen check for variants and re-install vectors:

Code: [Select]

systemctl list-unit-files --state=enabled
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done
grep -Rn '' /etc/cron* /var/spool/cron/ /etc/rc.local /etc/profile.d/ 2>/dev/null | grep -iE 'curl|wget|base64|/tmp|/dev/shm'
2. Remove SSH backdoors (they are set immutable - deletion fails silently)
The attacker sets chattr +i on the planted authorized_keys, so a plain rm does nothing. Clear the flag first:

Code: [Select]

find / -name authorized_keys 2>/dev/null -exec lsattr {} \;   # look for the 'i' flag
chattr -R -i /root/.ssh /home/*/.ssh 2>/dev/null
rm -rf /var/lib/mysql/.ssh                                    # service accounts must NOT have .sshThen audit every remaining authorized_keys for keys you did not add. Known-bad key seen in these attacks: SHA256:w79EbEKrlqugvMc8n/i9dQ5QuvhFBdJZDA/UKdSek2o

3. Remove rogue accounts + sudo backdoors

Code: [Select]

awk -F: '($3==0 && $1!="root"){print "UID0:"$1} /^(__user|user__|login|imunify):/{print "ROGUE:"$1}' /etc/passwd
grep -REn 'NOPASSWD' /etc/sudoers /etc/sudoers.d/ 2>/dev/null
awk -F: '$3<1000 && $7 ~ /(ba)?sh$/ {print $1":"$7}' /etc/passwd   # service accts with a login shell = tamperedService accounts (bin, daemon, sshd, named ...) should be /sbin/nologin or /bin/false. If they have /bin/bash, the attacker edited /etc/passwd - reset them to nologin.

4. Clean the web injection (the cloaking that serves spam to visitors, clean pages to you)

Code: [Select]

grep -RIl --include='*.php' 'aW5pX3NldCgiZGlzcGxheV9lcnJvcnMi' /home /usr/local/apache/htdocs 2>/dev/null
find / -type f \( -name '.x.php' -o -name '.r.php' -o -name 'cmd.php' -o -name 'shell.php' -o -name 'c99.php' -o -name 'r57.php' -o -name 'wso.php' \) 2>/dev/nullThat base64 string is the eval(base64_decode(...)) payload (it decodes to ini_set("display_errors",0) ...); it lands in index.php, wp-config.php, and a "defauit.php" typo file. Also check every .htaccess for RewriteCond on HTTP_USER_AGENT / HTTP_REFERER, and auto_prepend_file / auto_append_file in php.ini + any .user.ini. List files changed in your intrusion window (adjust the dates):

Code: [Select]

find /home /var/www /etc -type f -newermt "2026-06-01" ! -newermt "2026-07-15" 2>/dev/null
5. Check for trojaned system binaries

Code: [Select]

rpm -Va | grep -E '^..5'                 # '5' = checksum changed; scrutinise /usr/bin, /usr/sbin, /bin
find / -perm -4000 -type f 2>/dev/null   # unexpected SUID backdoorsThen run rkhunter, chkrootkit and a ClamAV / maldet scan.

6. Rotate EVERYTHING (assume total credential theft)
root + all CWP user passwords, MySQL root + every DB user, WordPress admins + regenerate the wp-config salts, all mail passwords, any API tokens. Regenerate the SSH host keys too.

Network IOCs to block / hunt: IPs 89.248.172.183, 89.248.172.118, 152.53.173.29 ; domain mars.imasync.com.

CWP gotcha - vanishing SSH keys: if your keys keep disappearing, that is NOT the attacker, it is CWP's own temp_hacker_check (ships from 0.9.8.1239) deleting keys for users whose home is /root (e.g. operator). Fix:

Code: [Select]

usermod -d /root/operator operator(credit Netino.)

Bottom line: with a root C2 AND an EOL OS I would rebuild on AlmaLinux/Rocky and migrate only scanned data. But if you clean in place: update_cwp x2, kill defunct FIRST, clear the chattr +i keys, purge the base64 injections, rotate everything - and put the panel + webmail behind an SSH tunnel so it can't recur. The full IOC list is in the "very serious security vulnerability in CWP right now" thread.

Good luck.