How to search for malware in a Magento installation

The other day I was asked to look at a Magento website as the client was reporting suspicious activity around the site.

The website was pretty new to me so I didn’t know anything about its background other than what the client had told me so I was working a little bit blind.

After taking full backups of the website and the database I made an exact copy to work with locally. Having taken a look at the version number (1.9.2.4) I downloaded a fresh version of Magento to match this from the Magento release archive so that I could begin comparing the two codebases. Here’s a quick run through of what I did to quickly check for malicious files in the core.

My first step was to see which files are different from the original codebase, taking in to account any installed patches in our local site. So we have two lots of files here, we have files that exist in our local site’s core folders that are not in the fresh Magento download (red flags) and we have files that exist in the fresh version but have been modified in our version (we’ll call those orange flags).

The way Magento works, if you don’t know, is that any modifications that are required should always be carried out by extending from the core codebase through modules or templates rather than modifying the core directly. So if we have any red or orange flags then we should be suspicious of them and take a look.

$ diff -qrw --exclude=.DS_Store {PROJECT}/app/code/core magento/app/code/core | sort diff.txt

What this does is run a brief (-q) and recursive (-r) diff on the main core directory which ignores any whitespace changes in the files (-w) as we aren’t really interested in that. I added the –exclude flag to ignore some .DS_Store files that I’m not interested in at the moment.

This gave me quite a long file so I then wanted to separate these as follows:

$ grep Files diff.txt > files-not-matching.txt
$ grep Only diff.txt > only.txt

This just copies all lines from our diff.txt file into new files where lines starting with Files (eg Files … differ) go into one and Only (eg Only in {PROJECT}/) go into another one. It just makes it easier to work through.

I had one file in the new-files.txt so I had a look. It was an encoded one-liner which is always a red flag so I opened up an online base64 decoder (just guessing it was base64) and ran the tool on the pasted text from the file. The contents were indeed malicious code which is all I needed to know at this stage.

I then looked through all of the modified files in my other file to make sure there was nothing else in there and repeated the above steps on the other Magento core directories.

This gave me enough information to feedback to the client and contact Foregenix for further analysis. Obviously you could use this approach on any codebase as long as you have something to refer back to such as a fresh WordPress download or plugin files.

I hope this helps if you want to run a quick manual scan.