I discovered another file.
And the method used.
The file `
/usr/local/cwpsrv/var/services/users/login/conf/Iang.php` was created on the same date as `ico.php`.
* Anatomy of the attack
The method used was this one, detected by ModSecurity (I protect my `cwpsrv` with ModSecurity), whose logs modsec_audit.log the attacker forgot to delete:
---vsWUH37C---A--
[15/Nov/2025:08:06:12 -0300] 176320477298.529591 127.0.0.1 42932 127.0.0.1 2083
---vsWUH37C---B--
[very long string, unfortunately forum is not allowing to post]
---vRkASqMp---H--
---vRkASqMp---I--
---vRkASqMp---J--
---vRkASqMp---Z--
He deleted all the other logs.
File data:
# stat ico.php
Arquivo: ico.php
Tamanho: 1477 Blocos: 8 bloco de E/S: 4096 arquivo comum
Dispositivo: fd01h/64769d Inode: 2892154 Links: 1
Acesso: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Acesso: 2026-08-27 10:18:13.727189654 -0300
Modificação: 2025-11-28 06:17:52.883868313 -0300
Alteração: 2026-08-24 21:59:57.435060346 -0300
Criação: 2025-11-15 08:06:12.856741480 -0300
# stat Iang.php
Arquivo: Iang.php
Tamanho: 1891 Blocos: 8 bloco de E/S: 4096 arquivo comum
Dispositivo: fd01h/64769d Inode: 3019261 Links: 1
Acesso: (0644/-rw-r--r--) Uid: ( 971/ cwpsvc) Gid: ( 970/ cwpsvc)
Acesso: 2026-08-27 20:53:36.488199001 -0300
Modificação: 2025-11-15 08:06:14.962752159 -0300
Alteração: 2026-08-27 20:51:53.481791997 -0300
Criação: 2025-11-15 08:06:12.432739330 -0300
If you are familiar with ModSecurity, you can use the HTTP data above to create a rule and protect your server.
ModSecurity was active, but the DELETE method was used; the attacker appended a ";" to the command and added further commands for execution.
* Why is the use of the DELETE method a crucial detail?
Firewall (WAF) Rule Bypass: Most administrators and default WAF/ModSecurity rules strictly monitor POST and GET requests, as these are the most common methods for sending data and commands. DELETE requests targeting public files often slip through without deep content inspection.
Exploiting Application Logic: The CWP script targeted in the attack (`/contsist/index.php?module=filemanager&acc=emptyTrash`) was originally designed to delete files (empty the trash). Consequently, the panel's API likely required or natively accepted the HTTP DELETE method for this specific function. The attacker exploited this legitimate permission to inject the `;` character into the URL and append the Linux commands that created the malicious file.
* Steps you can take:
Although the `filemanager` module appears to have been used, you should immediately restrict the methods allowed by Nginx and `cwpsrv`:
Add the following to your `/usr/local/cwpsrv/conf/cwpsrv.conf` file, inside the `server {` directive and before the `location / {` block:
# Natively block unauthorized methods in NGINX
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444; # Code 444 closes the connection immediately without sending headers, saving bandwidth and dropping the bot
}
If you discover the presence of any of the files mentioned above, you should run a scan using the following command:
# maldet -a /usr/local/cwpsrv/htdocs/admin/
Critic:
To use the filemanager module, it was necessary to know the username.
But he managed to use the username because it's extremely simple to find the username in CWP: Just use
http://IP.AD.DR.ESS/~usernameJust associate it with the user's domain name, and the damage is done.
This feature needs to be disabled immediately in CWP.
There are other possible ways to test a website before it's published, and this is the worst method.
Once you have the username, all that's missing is the password to break the login of any active service on your server.
In my opinion, you should remove or comment out this section of the file /etc/nginx/conf.d/IP.AD.DR.ESS.conf
location ~ ^/~(.+?)(/.*)?$ {
internal;
proxy_pass http://IP.AD.DR.ESS:8181;
include proxy.inc;
}
If you don't use the proxy, you should remove it anyway.
I discovered today that in nginx, using alias in a prefixed location that doesn't end with directory separator could lead to path traversal vulnerability.
Additional info:
https://gixy.getpagespeed.com/checks/alias-traversal/The alias directive is used to replace path of the specified location. For example, with the following configuration:
location /i/ {
alias /data/w3/images/;
}
On request of /i/top.gif, the file /data/w3/images/top.gif will be sent.
But if the location doesn't end with directory separator (i.e. /):
location /i {
alias /data/w3/images/;
}
On request of /i../app/config.py, the file /data/w3/app/config.py will be sent.
In other words, the incorrect alias configuration could allow an attacker to read files stored outside the target folder.
There are more things that can be done, but for now I need to focus on fixing my server and exploring other possibilities.
Topic: Possible CWP Security Issue – Malicious JavaScript Injection (Read 489 times)
