Find Hacked Joomla Files

Find Hacked Joomla Files

What Does a Hacked Joomla File Look Like?

Obfuscated code is the most prevalent symptom of a compromised file. Basically, anything that appears to be a long string of gibberish is almost certainly an inserted assault. Especially if it’s right next to an obfuscator like base64 decode. To the uninitiated, real code may appear to be Greek, but it does not appear to have been written by a machine.

Hacked files are also known for having badly written code with a haphazard organisation, with large functions and variables jammed together.

Hacked files frequently include references to other websites or utilise specific functions. A list of common functions in hacked files can be found further down the page. Please keep in mind that the presence of such a feature does not imply that a file has been hacked; rather, it adds to the evidence that it has.

Another sign is any reference to an off-site URL or an oddly named file. E.g. include(‘../../templates/beez_20/b996.php’). Similarly, a reference to a normal sounding file in an odd location is another indicator of an attack. E.g. include(‘../../templates/beez_20/settings.php’).

Likely Targets for an Attack

Because to the way Joomla operates, attacks frequently target files that are always loaded when the programme runs. The following are the three files that are most likely to be affected:

  • Joomla’s index.php
  • The template’s index.php
  • The site’s .htaccess

Attacks on these files are clear, while more sophisticated hacker scripts delve deeper into the system when making changes. Files in system and content plug-ins, language files, and core templates are examples of targets.

Verifying a File is Hacked

To be sure it’s not hacked code, download an unaltered file from the extension or core that matches the version you’re looking at, make an MD5 checksum on it, and compare it to the MD5 checksum on the one you think is hacked. This functions as a fingerprint and will tell you absolutely whether the file has changed from its original version.

Here are some examples of how to make an MD5 checksum:

  • Using MD5SUM to Validate the Integrity of (Downloaded) Files (Linux/Windows)
  • Generate & Compare MD5, SHA1 Hashes For Files In Terminal (Mac)

Locating Hacked Joomla Files

There are two things to bear in mind when looking for hacked files:

  • Files and database entries that have been hacked have been changed in some way.
  • Hackers insert files into the system to cause weaknesses or give another type of attack.
  • By doing so, hackers hope to achieve some sort of aim.

These may seem self-evident, but they will aid us in determining what has been hacked rather than simply throwing tools at the problem and hoping for a solution.

How can we tell what has been modified if we know that compromised files and database entries have been updated in some way? There are two options:

  • We can compare it to a previous backup.
  • We can make a clone of our site using the same versions of the software as the original and compare the two.

Comparing Files

You can compare files with the following tools:

  • Diff (Linux/Mac)
  • Diff Tools on Mac
  • Meld (Linux/Windows)

Finding Hacked Joomla Files with a Backup

The first method is the most straightforward. However, you must have a backup that you can restore elsewhere, and you must be able to trust that the backup was not tampered with. Because you don’t know when you were hacked, you have to travel back far enough in time to be relatively certain you weren’t hacked at that time. I would go back two months if possible if your site doesn’t change much and you have backups that are many months old.

Some users entrust their website’s backups to their web host. In this instance, the host will frequently delete backups after a specified amount of time has passed. If you’re lucky, they’ll keep photos for specific time periods, and you’ll be able to receive one at 45 days or three months. They should restore the backup to a subdirectory where you can access it. However, each host is different, so if you’ve been relying completely on them for backups, you’ll need to contact them.

Download both file structures into side-by-side directories to compare the backup to the current version. Then compare the two file directories using a difference scanning programme. After that, save both databases as SQL dumps and scan them for abnormalities with the same difference scanning tool.

This method takes a few hours, but it will show you exactly what has changed and what needs to be removed and repaired. There will be multiple false positives if your Joomla site was upgraded between the backup and the current version.

The drawback with this strategy is that because you don’t know when your site was hacked, the backup you restore could be affected as well. You’ll also need backups to even do this.

Finding Hacked Joomla Files with a Clean Comparison

This method does not require a backup, but it functions similarly to the first.

  • You just generate a list of all your Joomla extensions and their versions installed on your hacked site in your Joomla extension management, under the “manage” menu option.
  • You do the same thing in your template manager.
  • Download and instal a copy of Joomla that is the same version as your hacked version, as well as all extensions and templates (you don’t need to modify anything).
  • Place your Joomla site in the same directory as your hacked site and compare the files.

Comparing against a previous backup is comparable, but you can be assured that you’re comparing against clean files. However, the disadvantage of this method is that it does not detect any database assaults and takes 4 to 5 times longer than comparing against a backup. It can take up to a day of effort to produce a clean version of your site if you have a lot of extensions installed. Finally, keep in mind that any custom work you’ve had done will show up in your file compare tool.

Finding Hacked Files with Pattern Matching

If we know that hackers are attempting to accomplish a purpose via modifying database records or Joomla files, we can look for alterations that will affect those objectives.

Consider the indications listed in the “Is my Joomla Website Hacked?” section. Any file, function, or other piece of code that could cause the symptoms should be investigated further. These are unintended consequences of hackers fulfilling their objectives, and they all revolve on a certain set of requirements that hackers must meet in order to use your site efficiently. It’s similar like planning a journey to a faraway city: there are only so many roads that lead there.

This is significant because we may use tools to detect trends in the code that may signal a hacked file or database entry. Here are a few examples of “ways” that a hacker altering a file might take 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

We can search for matching patterns for these strings using tools. grep or egrep are the most basic to use. This is provided by default if you work with Linux, like I do. It’s also available for Mac. If you’re using Windows, you’ll need to get a similar programme like PowerGREP.

You should use case insensitivity when searching your file system. To scan your database, create a text SQL dump with PHPmyAdmin or another MySQL client. You can then perform the same searches on it.

The following is an example of a basic grep search:

egrep -Ri ‘location.href’ mysitedirectory/

Here’s a tutorial that goes over how to use grep to discover patterns in greater detail: The grep command in Linux and Unix

The advantage of employing patterns to find compromised files is that it is very rapid and does not necessitate the creation of a backup or similar site. Pattern matching’s flaw is that it can lead to mistakes. Hackers are always looking for new ways to get around these types of file scanning, and they’re becoming better at it.

Finding Hacked Files Using JAMSS

Bernard Toplak created and maintains JAMMS, an outstanding script. Joomla! Anti-Malware Scan Script is what it stands for.

Another programme that employs pattern matching to identify potentially compromised files. It will produce a lot of false positives, just like other file scanning tools, so be careful and double-check that any changes or removals you do based on its results are truly because the file has been hacked. You can compare the contents of a file to a clean version or use MD5 checksums as described above.

It’s simple to use; simply upload it to your web root and go to http://yoursite.com/jamss.php.

More information and a link to download is available on the Joomla security forum here: http://forum.joomla.org/viewtopic.php?f=714&t=778692

Make careful to remove it from your site directory once you’ve finished using it!

Finding Hacked Files Using Joomla Extensions

Several Joomla extensions will do pattern matching in their file scanner for you. These can be installed on a compromised site and used to search for suspicious files.

A handful of these tools are listed below:

  • Admin Tools
  • RSFirewall
  • AntiVirus
  • Website Protection
  • Securitycheck Pro

The advantage of using one of these is that they are simple to set up and scan. The disadvantage is that you have no idea what they’re looking for or what they’re missing out on. The difficulty is that even if you don’t notice any hacked files on your site, they can reinfect it with even more hijacked files after you believe you’re safe. Even so, it’s still worthwhile to use one just to have a different method to evaluating your files.

Finding Hacked Files Using a Debugger

Going through your site line by line with a debugger is the most thorough technique to figure out what’s going on. When it comes to debugging, we use PHP Storm and Xdebug. I’m not getting into the specifics of how to achieve this because it’s beyond the scope of this guide’s intended audience. If you’re a developer who can’t figure out where the attack is coming from in your site’s code, this method will show you exactly where it’s coming from and what it’s doing. The disadvantage of this method is that it can only detect hacked code that is currently being loaded. This will not identify a successful attack on your site that does not enter through your main index.php file if you are unaware of it. It’s quick and effective with that limitation.

What Do You Do If You Can’t Find What’s Hacked?

Hackers are cunning, and once they’ve gained access to your site, they’re already ahead of you. This is due to the fact that the average Joomla site has thousands of files in which an attacker can disguise their attack. It’s like looking for a single tree in a forest full of them. So, what should you do if you’re stumped?

There are a few options available to you:

  • You have the option of hiring someone else.
  • You can make a completely new version of your website.
  • With a new Joomla installation and an old database, you may produce a 90 percent clean version.

Hire Someone to Clean it

Sucuri is a cost-effective paid cleanup service for many Joomla users. They also provide continuing security and have a stellar reputation. If you utilise Sucuri, though, you’ll still need to perform some work to patch the vulnerabilities and improve Joomla’s security. This is when the section on How to Secure Joomla comes in handy.

We are a Sucuri referral partner, full disclosure. We’re a referrer because we’ve used their service and tools to monitor sites and have been impressed.

Create a 100% Clean Version of Your Site

The objective of all this labour isn’t to figure out how you were hacked or which files were affected. It’s all about getting back on your feet. So, if you can’t find out what’s wrong, you can still get back to a safe place by simply recreating your site with fresh data. Because you have to recreate everything piece by piece, this is quite time consuming, but you can rest assured that everything you don’t transfer over directly is clean.

You must still use caution since items from the previous site must be transferred to the new site. You’ll probably want to copy over images, articles, and your template, for example. Before copying any of this into your brand-new site, look over it with a fine toothed comb. When you’ve finished setting up your new site, double-check that everything is up to date (see “Secure Your Joomla Site To Keep from Being Hacked Again”.)

Create a 90% Clean Version

Remember to test this in a staging environment first, with a backup, before doing it on your live site!

  • Make a clone of your hacked site in a development environment.
    Download and instal Joomla at the same version as your hacked site in a separate directory.
  • Clean versions of your extensions should be installed in the new Joomla version.
    If you purchased the template, instal it from the supplier. If the template was custom created, you’ll have to inspect it by hand before copying it over to ensure that none of the files have been hacked.
  • Change the configuration.php file on your new site to point to the hacked site’s database (see below for more information.)
  • Your new site should now look just like your old one, with the exception of a clean file system.
  • Update the Joomla! core as well as all of your extensions to the most recent versions.
  • To prevent your Joomla site from being hacked, follow the steps below. Again
  • Delete all of the files from your live compromised website and replace them with the clean version. Important!!! Because most hacker scripts litter your file system with additional files and backdoors, you can’t just overwrite your previous site. Before you update your server with your new, clean site, you must erase everything.

What variables to change in the configuration.php file to point to your old site’s database:

In the new site you have built, at the root level, is a file named configuration.php

You want to change your database credentials to the old hacked site database. There are three variables that you change to do this:

public $db = ‘change_to_your_old_db;
public $user = ‘change_to_your_old_db_user’;
public $password = ‘change_to_your_old_db_password’;

You change the values encapsulated in the single quotes to connect to the old database where all your data resides (old username, password, and database)

Once you’ve done that, you have essentially a clean new body (the files) and an old brain (the database).

This will eliminate most problems on most hacked sites. However, if your database has been compromised, this will do nothing to address it because only the file system is changing.