What does Joomla’s hacked file look like?
Obfuscated coding is the most prevalent indicator of a compromised file. In essence, something that sounds like a long line of gibberish is actually an inserted attack. Especially if it is alongside an obfuscating feature such as base64 decode. The actual code for the layperson might be Greek, but it still doesn’t look like it was written by a computer.
There is also a trend for stolen files to contain very poorly written code with loose organisation where the functions are big and the variables are jammed together.
Referencing other pages, or using particular features, is popular for hacked files. For a list of popular functions in compromised files, see further down the article. Please note that the inclusion of such a feature does not suggest that a file has been compromised, only that it adds to the proof that it might have been.
Another indication is some reference to an off-site URL or a file with a weird name. Include( ‘../../templates/beez_20/b996.php’, for example). Similarly, another indication of an intrusion is a reference to a regular sounding file in an unusual spot. Include( ‘../../templates/beez_20/settings.php’).). For example:
Seeking for an Offensive
It’s common for attacks to concentrate on files that are still loaded while the programme runs, regardless of how Joomla operates. The three files which are most definitely affected are:
- Joomla’s index.php
- The index.php template
- .htaccess Website
Attacks on these files are very clear and, as they make their modifications, more devious programmer scripts dig further into the framework. Targets, for instance, include framework and material plug-in files, language files, and key models.
Verification of a file has been hacked
To know for certain whether or not it is hacked code, import an unaltered file matching the version you are checking from the extension or core and build an MD5 checksum on that file and check it on the one you assume is altered with the MD5 checksum. This works like a fingerprint that shows you unambiguously whether the file has improved according to the version it is intended to be.
Tutorials on how to generate an MD5 checksum are given here:
- Validating the fairness of (downloaded) files (Linux / Windows) using MD5SUM
- Generate & Compare MD5, Terminal (Mac) SHA1 Hashes For Files
Locating Files Hacked Joomla
There are two things to bear in mind in the hunt for stolen files:
- Hacked archives and folder entries somehow are distorted.
- Hackers instal vulnerability-generating files or have some form of attack.
- Through doing this, hackers aim to accomplish whatever purpose.
These can sound glaringly evident, but instead of just tossing instruments at the problem and trying to land on a solution, they will help us focus in on what has been stolen.
How can we say what has been changed if we know the compromised files and database entries have been altered in some way? Two paths:
- We might equate this to an old backup.
- From the same versions of the programme built on the web, we will create a clone of our platform and compare it for modifications.
Comparing Files
Here are a couple tools you can use to compare files:
- Diff (Linux/Mac)
- Diff Tools on Mac
- Meld (Linux/Windows)
Getting a Backup of Modified Joomla Archives
The simplest is the first way. You need to provide a copy that you can recover elsewhere, though, and you need to be able to assume that no copy has been changed. And when you’re compromised you don’t know exactly, you have to go back in time far enough to ensure you can be fairly confident you weren’t compromised back then. If your website doesn’t change much, because you have multiple months of copies, I’d go back two months, if I could.
Some people rely on their web host for the site to perform backups. In this scenario, sometimes, after a certain amount of time, the host can erase backups. If you’re fortunate, they’ll hold screenshots of any time frame and you’ll be able to get a 45-day or three-month glimpse. They would hopefully restore the backup into a subdirectory for you to run. However, each host is different and if you rely entirely on them for backups you will need to contact your web host.
Download all file systems into side by side folders to match the backup versus the new one. Using a differential scanning tool to compare the two folders of the paper. If this is done, save all databases as SQL dumps and run the same testing method for discrepancies and check for anomalies.
It takes a few hours to pursue this strategy, so it will show you just what has been modified and what to delete and repair. Notice that if the latest version of your Joomla site is modified with the archive, you’ll get some false positives.
The downside in this strategy is that the copy you rebuild has now possibly been corrupted and you don’t know exactly when your website was hacked. Additionally, for even attempting this you need backups.
Find Joomla Compromised Files with a Clean Contrast
This technique does not require a backup, but operates pretty much like the first plan.
- In your Joomla extension manager, you literally compile a list of all your Joomla extensions and their versions installed on your hacked site under the “manage” menu page.
- You’re doing the same with your Template Boss.
- Download a copy of Joomla which is the same as your compromised build, update it and update all the plugins and templates with the same versions (you don’t have to modify anything).
- Place the Joomla site next to your hacked site in a directory and run your file comparison app.
Compared to an old copy, this is really close, but you should be sure you’re competing towards new data. The downside of this strategy, though, is that it does not detect any threats on your servers and it takes 4 to 5 times longer than testing them against a backup. It will take you up to a day of work just to build a similar clean version of the site if you have loads of extensions installed. Finally, you may remember that it would show up in your file comparison application if you have any custom work completed.
Find Hacked Files with Corresponding Pattern
If we realise that by changing database records or Joomla files, hackers aim to accomplish any objective, we can search for modifications that will impact those aims.
“Any file, feature, or other code that may produce the symptoms means that we can look more closely at these places. Think back to the symptoms list from the section,” Is my Joomla website hacked? There are side effects of hackers completing their targets and they all revolve around a basic set of needs that hackers have to be able to access the platform successfully. It’s like planning a trip to a faraway city — there are just so many ways to get to it.
This is important because we can use tools to identify trends in the code that could signify a compromise file or database entry. For starters, here are a few typical “ways” that an updated hacker file can need to use to get where they want to go:
- base64_decode
- eval
- exec
- strrev
- wget
- file_get_contents
- stream
- create_function
- assert
- system
- preg_replace
- gzuncompress
- gzinflate
- str_rot13
- curl_exec
- header
- location.href
- encodeuri
- encodeuricomponent
- any link or domain
Using methods, we can search such strings for similar patterns. The grep or egrep are the most common to use. If you’re running on Linux, like I do, it’s available by chance. It’s on the Mac as well. If you run Windows, though, you can need to download a comparable application, such as PowerGREP.
You’ll want to be case-insensitive on any search on your filesystem. Export it to a text SQL dump to search the servers, using PHPmyAdmin or another MySQL app. Then you can run the same searches on it.
A simple quest for grep seems as follows:
egrep -Ri ‘location.href’ mysitedirectory/
Here is a guide with more comprehensive examples about how to find trends in a grep: grep command for Linux and Unix:
The power of using patterns to find hacked files is that it is very easy and doesn’t need a backup or a comparable site to be set up. The downside in pattern matching is that items can be overlooked by you. Hackers are actively searching for ways to escape all kinds of file scans aiming for more tricky and trickier ways to meet their targets.
Searching for hacked files with JAMSS
JAMMS is an outstanding script that Bernard Toplak produced and preserved. It represents Joomla! Script for Anti-Malware Search.
Another tool which uses matching patterns to recognise files that may be hacked. It can return several false positives, similar to other file scanning methods, so you need to be vigilant and check to be sure that all modifications or removals you make based on its findings are because the file was actually hacked. As mentioned above, you can use MD5 Checksums or compare the contents of the files to a clean version.
Only add it to your domain root and visit the http:/yoursite.com/jamss.php URL.
On the Joomla security website, more information and a link to download is available here: http:/forum.joomla.org/viewtopic.php? F=714&t=778692 Update:
Be sure to delete it from your website directory until you are done using it!
Hacked Files with Joomla Extensions
Several Joomla extensions accessible in their file scanner can do the pattern that suits with you. On a compromised site, you can instal these and continue to use them to locate malicious files.
A list of a few of these resources can be found here:
- Admin Tools
- RSFirewall
- AntiVirus Website Protection
- Securitycheck Pro
The advantage of having one of them is they’re easy to set up and search. The downside is you don’t know what they want and what they’re wanting. The concern is that if you have even one hacked file that you can’t find on your site, it may theoretically reinfect it after you think you’re covered with even more hacked files. And with that, though, it’s always worth having one just to have an easy way to evaluate the data.
Use a Debugger to locate hacked files
Using a debugger, the most detailed way to assess what is going on the website is to go through it line by line. When we’re doing our debugging, we use PHP Storm and Xdebug. I’m not going to look at the specifics of how to do this, so this tutorial goes beyond the intended reader. If you are a developer and you are unable to determine where the attack is being dragged into the code of your site, this technique will tell you precisely where it is taking place and what it is doing. The downside to this method is that it can only detect loaded hacked data. If you don’t know about a good attack on your web that doesn’t enter from your key index.php code, you won’t detect it. It’s fast and productive with the disclaimer.
What do you do if what is hacked can’t be found?
Hackers are tricky, because they’re always in a better spot than you if they’ve hacked your site. This is because there are thousands of files on the typical Joomla server to cover their attack in. It is like trying to locate a single tree in a whole woodland. So, what can you do if you can’t work it out right now?
You have a few choices in there:
- Everyone else you should recruit.
- You will build a clean version of your site for 100 per cent.
- With a new Joomla installation and an old database, you can build a 90% clean version.