Return of the EXIF PHP Joomla Backdoor

Our Remediation and Research teams are in constant communication and collaboration. It’s how we stay ahead of the latest threats, but it also presents an opportunity to identify interesting threats that aren’t new but may be reoccuring.

Such as today’s post, in which we explore a case we shared close to two years ago where we found malicious payloads were being injected into images.

My colleague Rodrigo Escobar passed us a very interesting payload, in which the backdoor was being embedded right into the JPG EXIF header data. It was specific to a hacked Joomla! install, and coincidently used the same markers as what we reported on in our last post on the subject. This time however, the image was working correctly, so it seems they’ve managed to get it right.

This time our team noticed the image was still working on the website and it loaded without any problems. The interesting part is that the code is stored within a seemingly innocent image file – the Joomla! logo – which can be loaded and viewed:

Breaking Down the Backdoor

This initiating (and quite discreet) piece of code was added to the application.php core file in Joomla in order to read EXIF data from the logo image. Note as well that the @preg_replace includes some EXIF data about the image, such as the Description, Aritist, Model, etc.

The application.php file simply loads as a core part of Joomla. When it loads the logo using this malicious snippet, it executes information stored in the EXIF header. Here is one part of the malicious JPG header, the image itself is valid, but the attackers added base64_decode in the header:

When the data is loaded using the PHP exif_read_data function, it returns an array filled with the data itself. The EXIF data is all listed as filled in by the attacker:

You can also clearly see the obfuscated base64 part of the code, which is the encoded Joomla backdoor itself. There’s nothing more – it’s just a very common backdoor.

In summary, the attackers broke up the string of malicious code and inserted it into each of the sections of the EXIF data on the JPG image. The EXIF data is like a puzzle waiting to be base64 executed, and when the application.php file loads, the @preg_replace pieces together EXIF data, which successfully executed the backdoor.

Malware Everywhere

The malware authors are always trying to find new ways to hide malware, and some cases going back to old techniques, anything to make it as invisible as possible.
You can read a related blog post where I described similar situation involving malicious code hidden in PNG file.

We have recently discussed infected Word document macros and even fake Google Drive phishing, so be wary of your sources even with commonly trusted forms of media.

Who knows, maybe in another two years, I’ll share with you a blog post about malware hiding in a JPG EXIF header again… Repetitio mater studiorum est – Repetition is the mother of all learning. Keep your eyes open and stay safe!