ShellForSell

Upon unzipping the file, the hierarchy of files are:

As mentioned, live_response file would not seems helpful for us, so for the exploited server, lets get the enumeration details based directly from the logs present within /var/logs from given [root] folder.

The logs from Apache/access.log.1 contains very important details regarding the enumeration phase using tool like wpscan by an attacker 192.168.72.131

And the enumeration was started from 31 July 2026, 09:09:22

Altogether $45$ attempts has been made for this credential-stuffing attack.

The attacker found the w2pshell vulnerability which is the vulnerability of WordPress core, allowing attacker for unauthenticated RCE on default installations. This vulnerability chain combines ==CVE-2026-63030 and CVE-2026-60137==

The overview of the vulnerabilities is (🔎Google):

• CVE-2026-63030 (Route Confusion)
  • Type: CWE-436 (Interpretation Conflict)
  • CVSS Score: 9.8 Critical (WPScan) / 7.5 Hight (CISA ADP)
  • Details: Located in WordPress REST API batch endpoint (wp-json/batch/v1). By nesting batch request structures, an attacker can confuse the route dispatcher and access handlers that normally require authentication.
• CVE-2026-63030
  • Type: CWE-60137(SQL Injection)
  • CVSS Score: 5.9 Medium (WPScan) /9.1 Critical (CISA ADP)
  • Details: Caused by insufficient sanitization of the author__not_in argument in WP_Query (mapped from the public author_exclude parameter in the REST API posts endpoint)

For more info: wp2shell

Within this log, the suspected exploitation time is 31th July 2026, 09:15:14

Despite we saw the timestamp, the attacker has tried to spoofed the timestamp during its exploitation. Within the debug.log file in folder /var/www/html/wordpress/wp-content, I found a log with SQL command where the attacker tries to spoof the timestamp.

Just after the exploitation timestamp, attacker has used the sql command with date in hex 0x323032302d30312d30312030303a30303a3030 which actually is:

After attacker gets accessed to the system, I can find the executed commands within access.log.1 file.

The timestamp for these execution was: 2026-07-31 09:16:08

And within this same file, we can see the commands and the full filesystem path of the web shell that has been primarily used by an attacker.

On combining all the relevant logs and decoding those URL, I found the primary path to be: /var/www/html/wordpress/wp-content/plugins/wp2shell_767ea7d9/wp2shell_767ea7d9.php

Then the user has also been able to get the SSH login. The auth.log file provide us the information on successful login into the machine with a privileged account. It means, after attacker exploited the WordPress and obtained a blog account password, he/she uses that same password to get SSH login.

On searching for the persistence mechanism, there is an authorized ssh key, within /root/.ssh/authorized_keys with root@kali. To verify, I found that the attacker has successfully logged in as root using the password. It means the attacker is using root as username and kali as hostname.

Using this key, an attacker is maintaining its persistence. To access the database credentials, attacker uses /var/www/html/wordpress/wp-config.php because wordpress stores its database connection credentials in wp-config.php file similarly as:

define('DB_NAME', 'wordpress');
define('DB_USER', 'wordpress_user');
define('DB_PASSWORD', 'database_password');
define('DB_HOST', 'localhost');

The attacker gained the command execution through the vulnerability and read this file to obtain the credentials. Within the log file, /var/log/apache2/error.log.1 file I found the evidence of accessing that location.

To extract all the information from the database, attacker uses the command:

There are two commands but the actual executed command is:

mysqldump -u root -p --all-databases > config.sql

This is further validated when we search for the timestamp for these commands to be executed.

Remember, we also have bodyfile.txt which contains filesystem metadata which generated by UAC. I am using this file to find the time for dumping the sql.

The last column value represented the dump file creation time.

On decoding the Unix timestamp, we can find the the accessed timestamp as:

Further looking at the access.log.1 I found two users that has been deleted by an attacker. It means, using w2pshell attacker was able to create two accounts. And the account where attacker has longer web-shell access is , user: wp2_758d54eed8a9

And this is it. I found all the artifacts of compromised server exploited by an attacker on wp2shell vulnerability.