Analysis of a suspicious file

Last week I was asked to quote for some work on a new client’s website. As always if the work is quite in-depth I’ll take a copy of the site so that I can review the codebase. Quite often I’ll see other non-application files in the root of the site, mostly just stuff that clients like to store there, but this time I also noticed another file which looked suspicious.

I opened the file tabs.php and it contained lots of encoded text. This is a red flag for me as it can sometimes mean this is a malicious file because most developers don’t encode files that are meant to be there unless they have good reason to so (eg copyright protection) I thought it was definitely worth a deeper look.

After taking a full backup I span up my SIFT Workstation virtual machine and copied the file over so that I could inspect it in a more secure environment with a reduced risk of infecting my main machine.

The file started off with a PHP eval function, passed to this was a gzinflate function and passed to that was a base64_decode function which was being passed a very long string.

I began by removing the eval function, saving the response of the gzinflate and base64_decode functions to a variable and finally added a var_dump function to the end of the file. I then executed the file with PHP on the command line and outputted the result to a new file, tabs2.php.

The result was a bunch of new code which included a preg_replace function. I repeated the above steps on the new file and outputted to tabs3.php. I got an error this time due to a parameter that was being passed to preg_replace being deprecated in PHP7. I removed the preg_replace function and ran it again. This time I got new code which again consisted of gzinflate and base64_decode functions so I repeated the above steps and outputted the variable contents to tabs4.php.

Now I was getting somewhere. This new file contained what looked like a web shell. A bunch of functions which allowed a user to get access to sensitive information about the server environment and the website including usernames and passwords, database credentials, file permissions, file locations etc. I did a quick DuckAndGo search and found other versions of this file which were very similar and the descriptions alongside those files confirmed my suspicions.

The production site was also using PHP7 so it’s likely that this file wasn’t able to execute due to the preg_replace fatal error that I experienced however I removed the file and we changed all usernames and passwords across the website and server environment.

I contacted the hosting company to explain what I had found incase they wanted to run scans on their accounts to ensure this file hadn’t caused any further damage but I never heard anything back from them. This hosting company isn’t one that I normally use but I won’t name them here.

What can we take from this?

Well the first thing is that it’s a good idea to keep an eye on your website’s files, or even better to have software monitor your file integrity. The thing that drew me to this file in the first place was knowing that it isn’t a part of the application’s core fileset.

Having strong FTP usernames and passwords is crucial.

The fact that the server was running up-to-date PHP possibly saved the website in this instance. If the preg_replace function was able to execute then things would have been worse.

If you notice anything suspicious on your website or even if you want an audit then contact me on 01782 954282 or by email.