Adrian Hada
ATI Security Researcher

Deobfuscating Malicious Actor Intentions for Your Web Server

April 10, 2017 by Adrian Hada

Mihai Vasilescu and I, both security researcher engineers for Ixia’s Application and Threat Intelligence (ATI) team, set out to discover why hackers target our honeypots. One very common misconception regarding security is that you’re secure because nobody wants to target you. In the age of Mirai and other major scanning bots, this is simply not true. On average, each of our web honeypots is hit by more than 25,000 suspicious requests per day – clearly more than the number of people either of us has ever upset. But what could one of these malicious actors want from your web server? While investigating honeypot events, we identified an interesting request:


This is an older exploit for the AdsManager extension for the Joomla CMS, discovered and fixed in 2015. You can find a PoC for this here: The vulnerability allows the attacker to upload an arbitrary file to the web server. The uploaded file looks like this:


This is a piece of PHP code that has been compressed using gzip and base64 encoded. The author definitely didn’t want his intentions to be known. Using PHP, decoding this is easy. Unfortunately, what we got was just more obfuscated code:


This is a decoding function in which the parameters have been replaced by random strings. The decoding function is used to decode another large blob of base64 to executable PHP code. The first line in the function decodes to the complete set of lowercase alphanumerics plus underscore. Using that, we can decode the function as follows (note that some parts have been modified for readability):


In short, the author has replaced the names of several PHP functions with obfuscated strings. The last of these is “eval” which would have executed the PHP code inside – replacing it with “print” allows us to easily get from the obfuscated blob below (again, improved for readability) to the deobfuscated content:



In the end, what we found was a PHP backdoor script that would be executed on the server. Its capabilities include:

  • Downloading and executing a Perl bot
  • Reading out Joomla and Wordpress configuration files
  • E-mailing the malware author with the exact coordinates of the infected website
  • Self-cleanup
  • Executing shell commands
  • Downloading files from the server
  • Modifying file permissions
  • Uploading new files

To improve its security, the script checks the user agent string of the accessing entity for the string “google” so that this page doesn’t get indexed. Upon GoogleBot access, it will respond with a 404 error.

Most of these functions are standard for backdoor web shells – at this point, the attacker has gained complete control of your website. He might try to deface it, steal information, or do whatever he pleases with it (hosting malware files is always an option). There’s also the option of the Perl bot that seems interesting. Unfortunately, there’s more obfuscation here:


Luckily, the code has to deobfuscate this to execute the commands, so we were quickly able to get to the following code:


This code effectively tries to download a Perl script from a URL (either given in the backdoor UI or from a default website). It tries all types of shell execution functions that PHP offers (in case some of them were blocked for security purposes). Unfortunately, at this point we reached a dead end. The URL was no longer active. It was time to change strategy.

The backdoor script e-mails three different addresses by default. Searching for the e-mail name, we found the actor in some hacking-related forums, asking for different types of assistance, as well as a Pastebin account:


The two pastes lead to two Perl scripts for two Perl bots with IRC communication. Capabilities seem to include scanning and DDoS for one of the scripts:


The other script is an older Perl bot, also with IRC communication capabilities, which is able to exploit an old RealVNC authentication bypass vulnerability (circa 2006) using this PoC:, as well as installing Hydra ( and brute-forcing certain services:


Whichever of the above the payload is, this is a good example of what a malicious web actor might want to use a web server for – it’s not necessarily you that they’re after, it’s the resources that you pay for that leverage their actions further down the road.

Anybody who connects to the Internet is liable to become a target – not necessarily an intended target, but the result of mass-infection strategies such as automated scanners, brute-forcing bots, malvertising campaigns, and other threats aiming a large audience. This is just a small example belonging to what seems to be a relatively new threat actor – hence the old exploits, reduced capabilities, and reuse of older malware. Regardless of their size, these actors can be dangerous to an ill-prepared organization. Tracking them and understanding their actions and strategies can help all of us better prepare for the security challenges ahead.