CWP Security Audit - Unknown file

[anandmys]

Getting this alert

Code Select Expand

CWP Security Audit - Unknown file

Unknown file: /opt/php-build-deps/lib64/libzip.so.5.5

Should I be concerned?

Also getting

Code Select Expand

CWP Security Audit - Ghost files

Ghost files found for apache

[overseer]

No concern on the first, a false positive. Does it show any additional information on the "ghost files"? Did you get your casino SEO problem taken care of? Did you find that malicious Apache module that was producing the output for the bots?

[jeffshead]

I was watching this vid (https://www.youtube.com/watch?v=ksmWCWw5Vd4), logged into CWP admin and have the same two errors and others.

[overseer]

I would double check to make sure you don't have any fake kernel threads running or deleted processes running out of memory. tuned is legitimate, as long as it's not another process trying to disguise itself as tuned.

[Starburst]

I asked Sandeep about:



He said that error was a false positive from php-manager.

--

The rest looks like you have another or several other problems with the server, and some things that aren't configured correctly.

[jeffshead]

Thanks for the responses!

Currently 229 processes running. How do you know if any/which ones are illegitimate?

Since recent server updates were installed, the Server health and performance counters no longer auto-refresh, either.

I also noticed that I now get a 403 when accessing any info.php, for any user. If I exclude INFO_MODULES, the other php data displays.

[overseer]

You can try this short one-liner, or I have a longer script if you're interested.

Code Select Expand

find /proc/[0-9]*/exe -lname '*deleted*' -ls 2>/dev/null

[jeffshead]

Thank you!

I ran the one-liner:

Code Select Expand


[root@cwp8 ~]# find /proc/[0-9]*/exe -lname '*deleted*' -ls 2>/dev/null
   993687      0 lrwxrwxrwx   1  root     root            0 Oct 27 10:30 /proc/229839/exe -> /usr/local/cwp/php71/sbin/php-fpm\ (deleted)
   997452      0 lrwxrwxrwx   1  root     root            0 Oct 27 10:35 /proc/230497/exe -> /usr/local/cwp/php71/sbin/php-fpm\ (deleted)
  1007333      0 lrwxrwxrwx   1  root     root            0 Oct 27 10:48 /proc/232923/exe -> /usr/local/cwp/php71/sbin/php-fpm\ (deleted)
    24299      0 lrwxrwxrwx   1  root     root            0 Oct 26 22:33 /proc/910/exe -> /usr/local/cwp/php71/sbin/php-fpm\ (deleted)
    24339      0 lrwxrwxrwx   1  root     root            0 Oct 26 22:33 /proc/931/exe -> /usr/local/cwp/php71/sbin/php-fpm\ (deleted)


So what does that one-liner tell us?

I used the stand alone PHP updater (https://www.alphagnu.com/topic/633-standalone-cwp-php-cli-build-manager-build-php-7485-php-fpm-selector-switcher-and-pie-extensions)

I also noticed that the bin directory does not exist:

Code Select Expand


[root@cwp8 ~]# ls /usr/local/cwp/php71
etc  lib  php.d  tmp  var


[jeffshead]

I ended up restoring a 5 day old backup of the VM. That seems to have solved some of the issues including the missing directories. Looks like I did get hit by the PHP2Shell vulnerability.

Since updates were applied after restoring the VM, I had to run the Quick fix listed here to regain access to the admin.

Now, the counters on the dashboard do not update every 5 seconds like they are supposed to. I asked how to fix in the thread I linked to in the previous sentence.

[Freespirits_GR_Host]

Hi,

Restoring the VM was a reasonable recovery step, but since you suspect PHP2Shell exploitation, I would verify the server's security state before considering the incident resolved.

One important detail: PHP-FPM processes showing (deleted) after an upgrade are not necessarily malicious. Linux processes can continue running an older executable after its binary has been replaced.

First, check which PHP-FPM services are currently running:

Code Select Expand

systemctl list-units --all --type=service | grep -Ei 'cwpsrv|php.fpm'

ps -eo pid,ppid,user,etimes,args | grep -E '[p]hp-fpm|[c]wpsrv'

Next, verify the missing directories and socket:

Code Select Expand

ls -ld /usr/local/cwp/php71/bin
ls -ld /usr/local/cwp/php71/sbin
ls -ld /usr/local/cwp/php71/var/sockets

ss -xlpn | grep -F cwpsrv.sock

A missing PHP-FPM socket would help explain the dashboard errors, but that is a separate issue from determining whether exploitation occurred.

For the security investigation, I would preserve the available logs and examine unexpected processes, cron jobs, systemd services, SSH authorized keys and recently modified executables.

I would also verify that the restored PHP installation contains the relevant security patches. A five-day-old backup may predate those updates.

If you have evidence of successful exploitation or root-level compromise, I would recommend rebuilding from a trusted installation rather than relying on the restored snapshot alone.

Full disclosure: I'm the developer of the CWP7 Security Audit Module, which is separate from CWP's built-in security audit. I developed it to help administrators investigate suspicious files and persistence indicators.

It could assist with the security-verification stage, but it cannot guarantee that a compromised operating system is clean.

One question: did you find actual malicious files or suspicious commands before restoring the VM, or was the suspected compromise based primarily on the errors following the PHP update?

That distinction would help determine whether this was an exploitation incident or a failed CWP/PHP upgrade.

[jeffshead]

@Freespirits_GR_Host - Thank you for taking the time.

Code Select Expand


[root@cwp8 ~]# systemctl list-units --all --type=service | grep -Ei 'cwpsrv|php.fpm'
  cwpsrv-phpfpm.service                                 loaded    active   running The PHP FastCGI Process Manager
  cwpsrv.service                                        loaded    active   running CentOS Web Panel service (daemon)
● php-fpm73.service                                     not-found inactive dead    php-fpm73.service
● php-fpm74.service                                     not-found inactive dead    php-fpm74.service
● php-fpm81.service                                     not-found inactive dead    php-fpm81.service
● php-fpm82.service                                     not-found inactive dead    php-fpm82.service
● php-fpm83.service                                     not-found inactive dead    php-fpm83.service
● php-fpm84.service                                     not-found inactive dead    php-fpm84.service
  php-fpm85.service                                     loaded    active   running The PHP FastCGI Process Manager
[root@cwp8 ~]#
[root@cwp8 ~]# ps -eo pid,ppid,user,etimes,args | grep -E '[p]hp-fpm|[c]wpsrv'
    906       1 root         382 php-fpm: master process (/usr/local/cwp/php71/etc/php-fpm.conf)
    907       1 root         382 php-fpm: master process (/usr/local/cwp/php71/etc/cwpsrv.conf)
    915       1 root         382 php-fpm: master process (/opt/alt/php-fpm85/usr/etc/php-fpm.conf)
    971       1 root         381 cwpsrv: master process /usr/local/cwpsrv/bin/cwpsrv
    979     971 root         381 cwpsrv: worker process
    980     971 root         381 cwpsrv: worker process
   2136     907 root         244 php-fpm: pool cwpsrv
   2270     907 root         238 php-fpm: pool cwpsrv
   2271     907 root         238 php-fpm: pool cwpsrv
   2275     907 root         238 php-fpm: pool cwpsrv


Code Select Expand


[root@cwp8 ~]# ls -ld /usr/local/cwp/php71/bin
drwxr-xr-x. 2 root root 107 Oct 27 18:07 /usr/local/cwp/php71/bin
[root@cwp8 ~]# ls -ld /usr/local/cwp/php71/sbin
drwxr-xr-x. 2 root root 21 Oct 27 18:07 /usr/local/cwp/php71/sbin
[root@cwp8 ~]# ls -ld /usr/local/cwp/php71/var/sockets
drwxr-xr-x. 2 root root 4096 Oct 28 09:30 /usr/local/cwp/php71/var/sockets
[root@cwp8 ~]#
[root@cwp8 ~]# ss -xlpn | grep -F cwpsrv.sock
u_str LISTEN 0      128        /usr/local/cwp/php71/var/sockets/cwpsrv.sock 24802            * 0     users:(("php-fpm",pid=2275,fd=14),("php-fpm",pid=2271,fd=12),("php-fpm",pid=2270,fd=10),("php-fpm",pid=2136,fd=9),("php-fpm",pid=907,fd=7))


I have removed the old web app that relied on PHP 7.3 and also deleted all versions of PHP except for 8.5.12.

I suspected compromise based primarily on the errors and missing files. However, I have seen a couple more errors since my last post and restoring the backup. One error was 'Suspicious process running from RAM/memfd!' Unfortunately, I closed the screen capture software before saving the pic. I do remember it listed php-fpm, not tuned.

My meters on the dashboard still do not auto update like they did prior to CWPpro version: 1.26.

I'm not sure what else to do at this point.

[Freespirits_GR_Host]

Hi jeffshead,



Thanks for providing the results.

The good news is that your internal CWP PHP-FPM services are running, and the [tt]cwpsrv.sock[/tt] socket exists. This suggests the earlier missing-socket problem is no longer present.

The [tt]php-fpm73[/tt], [tt]php-fpm74[/tt] and similar "not-found" entries do not necessarily indicate compromise. They may be references to services removed during your PHP cleanup.

However, the warning about a suspicious process running from RAM/memfd deserves closer investigation.

Important: PHP-FPM can legitimately use memory-backed file descriptors, so this warning alone does not prove malware. We need to identify the actual executable and its behavior before taking action.

1. Identify the running PHP-FPM processes

Code Select Expand

ps -eo pid,ppid,user,stat,lstart,args | grep '[p]hp-fpm'

2. Check their actual executable paths

Code Select Expand

for PID in $(pgrep -f 'php-fpm'); do
    echo "=== PID $PID ==="
    readlink "/proc/$PID/exe" 2>/dev/null
done

If the suspicious-process warning appears again, please record its exact PID before restarting anything.

3. Investigate the suspicious PID

Replace [tt]12345[/tt] with the actual PID reported by the security warning.

Code Select Expand

PID=12345

ps -p "$PID" -o pid,ppid,user,lstart,stat,args

readlink "/proc/$PID/exe"

ls -l "/proc/$PID/fd" 2>/dev/null |
    grep -E 'memfd|deleted' || true

grep -F 'memfd:' "/proc/$PID/maps" | head

These checks should help us distinguish a legitimate PHP-FPM process using memory-backed resources from an executable launched from an unexpected anonymous-memory location.

4. Investigate the CWP dashboard counters

Regarding the dashboard counters, your PHP-FPM socket is currently available.

I would now check whether the dashboard's AJAX requests are failing and whether fresh errors appear in the CWP web-server logs:

Code Select Expand

tail -n 100 /usr/local/cwpsrv/logs/error_log

This may help identify whether the problem is related to the recent CWP upgrade, PHP-FPM configuration or a separate dashboard issue.

5. Check for possible persistence

If the suspicious process is confirmed to be executing from an unexpected memory-backed location, I would also investigate:

• Its parent process and execution history.
• Unexpected outbound network connections.
• Suspicious systemd services and timers.
• Root and user cron jobs.
• Recently modified executables and PHP files.
• Unfamiliar SSH authorized keys.

Preserve any suspicious evidence before removing files or restarting services. If root-level compromise is confirmed, recovery from a trusted installation is safer than assuming that deleting the visible malware restores system integrity.

About the CWP7 Security Audit Module

Full disclosure: I'm the developer of the CWP7 Security Audit Module, which I mentioned previously.

I developed it to help CWP administrators investigate suspicious files, malware indicators and persistence mechanisms.

For this particular warning, however, I would prioritize identifying the exact process before recommending automated cleanup. The module can support a broader investigation, but I would not claim it detects this specific memory-based technique without verifying that capability.

Could you share the diagnostic results if the warning appears again?

In particular, the process PID, executable path and any memfd-related findings would help us determine whether this is legitimate PHP-FPM activity or something requiring a deeper security investigation.

Best regards,
Freespirits Web Services