If you have access to the site via SSH, you can find files with injected code by running the following commands:
#grep -lr --include=*.php "eval(base64_decode" /pathWebroot #grep -lr --include=*.php "strrev(" /pathWebroot
If there is no access, you can ask the hosting support team to do this for you and send you a report.
Here is an example listing: ./components/com_wrapper/wrapper.php ./components/com_wrapper/controller.php ./components/com_wrapper/router.php ./components/com_wrapper/views/wrapper/view.html.php ./components/ com_banners/models/banner.php ./components/com_banners/models/banners.php ./components/com_banners/controller.php ./components/com_banners/router.php ./components/com_finder/views/search/view.html. php ./components/com_finder/helpers/route.php ./components/com_finder/helpers/html/filter.php ./components/com_finder/helpers/html/query.php ./components/com_finder/controllers/suggestions.json. php ./components/com_jshopping/tables/productfiles.php ./components/com_jshopping/tables/statictext.php ./components/com_jshopping/tables/country.php ./components/com_jshopping/tables/productlabel.php ./components/com_jshopping /tables/shippingext.php .... ./administrator/components/com_jshopping/controllers/orderstatus.php ./administrator/components/com_jshopping/controllers/shippingsprices.php ./administrator/components/com_jshopping/controllers/vendors.php . /administrator/components/com_jshopping/controllers/productlabels.php ./administrator/components/com_jshopping/controllers/categories.php ./administrator/components/com_cache/cache.php ./administrator/components/com_cache/models/cache.php . /administrator/components/com_cache/controller.php ./administrator/components/com_cache/views/purge/view.html.php ./administrator/components/com_cache/views/cache/view.html.php ./administrator/components/ com_cache/helpers/cache.php ./administrator/components/com_content/tables/featured.php
Total 1606 occurrences. These are almost all PHP files. Removing injected code manually is useless. This will take too much time. Discovered and new file images/post.php to execute any code.
Removing malicious code from infected filesYou should first make a full backup of your site in case something goes wrong.
If the immediate functionality of your site is very important to you, you can remove the injected code by running simple commands.
#grep -lr --include=*.php "eval(base64_decode" /pathWebroot | xargs sed -i.bak "s/eval(base64_decode[^;]*;//" #grep -lr --include=*. php "strrev(" /pathWebroot | xargs sed -i._bak "s/$_ = strrev([^;]*; @$_([^;]*;//"
The commands will remove all occurrences of such malicious code from the files and make backup copies of them with the .bak extension. This will only allow you to gain time to fully restore the site, but will not save you from subsequent attacks. It should be understood that there is a high probability of having files such as images/post.php described above for the execution of any code and old holes in installed extensions.
Third Party ExtensionsIf you have not been deprived of the site’s administrative panel, you can look installed components, modules, plugins and templates. If there is no access, you need to view the contents of the site by connecting via FTP or SSH.
Look at the list of modules #ls ./modules index.html mod_banners mod_login mod_users_latest mod_articles_archive mod_breadcrumbs mod_menu mod_weblinks mod_articles_categories mod_custom mod_random_image mod_whosonline mod_articles_category mod_feed mod_related_items mod_wrapper mod_articles_latest mod_finder mod_search mod_articles_news mod _footer mod_stats mod_articles_popular mod_languages mod_syndicate #ls ./administrator/modules index.html mod_latest mod_menu mod_quickicon mod_title mod_custom mod_logged mod_multilangstatus mod_status mod_toolbar mod_feed mod_login mod_popular mod_submenu mod_versionOnly standard Joomla modules are used
Look at the list of components #ls ./components com_banners com_finder com_media com_search com_wrapper com_contact com_jshopping com_newsfeeds com_users index.html com_content com_mailto com_phocapdf com_weblinks #ls ./administrator/components com_admin com_config com_installer com_media com_phocapdf com_users com_banners com_contact com_joomlaupdate com_menus com_plugins com_weblinks com_cache com_content com_jshopping com_messages com_redirect index. html com_categories com_cpanel com_languages com_modules com_search com_checkin com_finder com_login com_newsfeeds com_templatesIn addition to standard components, com_jshopping and com_phocapdf are used.
Look at the list of plugins #ls ./plugins authentication content editors-xtd finder phocapdf search user captcha editors extension index.html quickicon systemIn addition, you need to view the contents of all these folders. They are groups of plugins.
#ls ./plugins/authentication gmail index.html joomla ldap #ls ./plugins/captcha index.html recaptcha #ls ./plugins/content emailcloak geshi joomla pagebreak rokbox finder index.html loadmodule pagenavigation vote #ls ./plugins/editors codemirror index.html none tinymce #ls ./plugins/editors-xtd article image index.html pagebreak readmore #ls ./plugins/extension index.html joomla #ls ./plugins/finder categories contacts content index.html newsfeeds weblinks #ls ./plugins/quickicon extensionupdate index.html joomlaupdate #ls ./plugins/search categories contacts content index.html newsfeeds weblinks #ls ./plugins/system cache highlight languagecode log p3p remember sef debug index.html languagefilter logout redirect rokbox #ls . /plugins/user contactcreator index.html joomla profile
In addition to standard plugins, the phocapdf plugin is used.
Look at the list of templates #ls ./templates atomic beez_20 beez5 index.html system templ1In addition to standard templates, templ1 is used.
Restoring an infected site- Download the distribution kit of the latest release, unpack the archive into the directory of the future site and delete the installation directory from it.
- Rename the htaccess.txt file to .htaccess. If it used directives that you wrote down, transfer them from the infected copy.
- We copy the configuration.php file from the infected copy, having previously checked for the absence of injected code in it.
Third Party Extensions
- We find the used third-party components Phoca PDF, JoomShopping, the plugin "Phoca PDF Content Plugin", download.
- We unpack and copy the files, having previously created a directory structure similar to that of the infected copy. Don't forget about localization files.
The situation with the template is a little more complicated. The template was generated by special software and is not possible to find. We'll have to "pick out everything unnecessary" from it.
Fortunately, there are 21 PHP files in the template and all the injected code was removed with the command #grep -lr --include=*.php "strrev(" /pathWebroot | xargs sed -i._bak "s/$_ = strrev([^ ;]*; @$_([^;]*;//"
Own files
- Create directories where you kept pictures, documents and other files and copy them.
The site should start working as soon as you replace the old content with the new one.
Go to the administrative panel of the site, change the username and password for accessing the CMS and see if the SuperUsers e-mail has been replaced (an attacker can use the function to recover a forgotten password). Never use the standard username admin. Carefully review the rights of all users. The possibility of an attacker installing another administrator cannot be ruled out.
Replace the username and database password MySQL data, if the standard database table prefix jos_ is used, it must be replaced with another one, this will prevent the possibility of an SQL injection attack.
Upon completion of the restoration work, install the BotsGo404 plugin.
If you found this article helpful, please vote for it. This will help others find this article more quickly from many others that are less useful.(17 Votes)
At first he had 4 Torjan-infected js files and some malicious code. I have cleared these files. But now I can't find this javascript include.
You can see by viewing the page source.
It turns on at the end of each one. It stores the page as it loads, and the scanner detects it as malicious code.
What I've tried so far.
1) Changed template 2) Try disabling all components. 3) try to disable all components. 4) tried to disable all plugins. 5) downloaded the full site and searched for this code on the full site. But I couldn't find it.
But he was still there. Can you give me some suggestions?
4 answers
The malicious code is present on the page even if javascript is disabled - this tells us that it is not written there document.write in other js files.
When we visit a site with the settings tmpl=component&no_html=1, which suppresses template output and only sends component output, the code is still there: http://ziggymonster.com/?tmpl=component&no_html=1
This will pretty much indicate that the code is being added to the end of the main Joomla index.php file at the root of your site. Alternatively, a component.php file in your own template folder or in the /templates/system/ folder could be a viable candidate.
Cleaning up a site on site is risky - but it can be done with the right knowledge, experience and the right tools. I would suggest finding an experienced Joomla security expert to do this, or rebuilding the site files: install a new Joomla in a completely clean folder (it would be better to use local server), install all your extensions, and then delete your live site and upload files to your webspace, linking the files to the original database.
Of course, back to backup copy since a few days ago it would have been the best option- you have backups right?
You must examine the log files to understand how the attack was carried out. You should also change all passwords, update Joomla and all add-ons - and consider changing web hosts if this seems different account on the server, made available for hackers to access.
If you like ssh you can use this command:
Find. -type f -iname "*.php" -exec grep -l "mail(\|eval(\|sockopen\|socket_client" () \;
who is looking for php files(recursively from the current directory) containing dangerous code. PHP functions mailboxes are of interest to hackers, but there are eval and api functions for this. I run this command on my server once a day and it has detected malicious scripts in the past.
most quick way remove all types of malicious code - connect via ssh, open the yous site directory and run a request like:
find. "*.*" -exec replace "HERE_IS_BAD_CODE" "" -- () \;
you can also filter the file types to search by changing. to *.php or *.html
disclamer: you have to be VERY VERY careful with ssh
To be sure, you need to rebuild your site. Backup the database and files, then delete ALL files from docroot and re-download them from fresh copies (Joomla from http://www.joomla.org/, extensions from their sites, etc.). You will then re-upload your media folder and any custom code (template, etc.).
If you are not very technical you will need to install Joomla and extensions and then delete the database and configuration.php and re-upload old file configuration.php and database. Otherwise, you will have to unpack the extensions yourself.
At the very least, I would recommend downloading a fresh copy of Joomla core (you will need to delete the "installation" directory immediately after this). This is quite safe as the distribution does not overwrite your .php config. Of course, if you hacked Joomla core (Bad Idea), you will need to reapply your custom hacks.
It would also be a good idea to consider your security measures - do you need to change your passwords? Should all your files be writable on the web server?
Joomla is not only one of the most popular CMS on the Internet. Unfortunately, this content management system is most susceptible to hacker attacks. Today we will talk about what to do if your Joomla site is hacked, and we will also look at preventive measures and combating intruders.
Communication with readers forced me to add a paragraph. We do not provide free or paid consultations related to the hacking of your site, but we are ready to provide a paid service for treating and restoring the site after a hacker attack.
Why do hackers hack a website?I will not consider exotic cases when an attack on a site occurs purposefully in order to obtain information. Because when placing confidential data on the Internet, anything but Joomla is used. The motivation of modern hackers is quite clear and can be divided into three main sections.
Scripts are introduced that fill your pages with links to the attacker’s website. A redirect option is possible, when the visitor is immediately sent in the direction the hacker wants.
There are often cases when an attacker gains access to the database and the administrative panel, and you find other people's articles and news in the list of materials.
Joomla files can be either completely deleted or replaced with attacker scripts. There is a high probability that the visitor will see something in red and dark colors, where it will be written that the hack was carried out by a wonderful guy from Turkey.
In 2015, most hacks occurred for this reason.
What is the algorithm for the operation of malicious scripts and attackers?
An attack on a site is carried out through a vulnerability in the Joomla CMS or component. There are cases when malicious code is initially present in an installed extension.
This applies to those components, plugins, modules that were downloaded illegally.
The result of penetration into the site is the appearance of numerous script files in different Joomla directories.
The names of the files and their placement in directories are such that at first glance it is not easy to distinguish malicious scripts from “native” Joomla files. For this reason, the “treatment” of the site is often incomplete, and after a few days or weeks another batch of spam leaves on behalf of your domain.
Almost immediately, hosting technical support sends you a threatening letter, offering to solve the security problem. Inaction threatens to block your account and shut down the site.
What to do if a Joomla site is hacked?The beginning of your war against malicious scripts will begin with your hosting provider. Most likely, it is his letter that will give the go-ahead for military action
Their success largely depends on what tools the hosting company puts at your disposal. I will list the main ones:
Antivirus panel built into the hosting. As a rule, it does not perform disinfection, but it will help to find a significant part of malicious scripts
Access via SSH. Without it, it is impossible to talk about a full fight against viruses.
Prompt and qualified technical support
Daily backup. The ideal option is the ability to restore or download a copy from a month ago
If your hosting provider does not provide antivirus software(it can be built into the hosting panel, or launched independently by the hosting provider at your request) - grab your infected site and change the company providing the hosting service. The market is simply replete with such offers.
Most sites are hosted on virtual hosting, and I would give a solid five on all four points listed to the company, the link to which is below:
It's a completely different story if you rent the entire server. The first, third and fourth points will be entirely on your conscience. And point two will go without saying.
Procedure for hackingStep 1. Clean the site from malicious files
As a rule, it doesn’t take much time from a hack to a letter from hosting technical support. In rare cases, the site owner himself discovers a hack.
The easiest way is to restore the site from an uninfected backup. However, it is only suitable if no changes have been made to the site for a long time.
On a regularly updated site, the search will have to be done manually. And do this via SSH. The task will be extremely simple. You need to find out which files have changed recently. For example, in a week. For operating system Debian command would look like this:
find /directory where the search is performed/ -type f -mtime -7
According to this command, the system will display those files that have changed over the last 7 days. We pay attention to files with the PHP extension.
They are the ones who pose the threat. At the same time, you should understand that some of the displayed files may not be infected and belong to Joomla itself. Therefore, you should have at hand the original distribution of the version that works in this moment.
In the screenshot we see two files. The first is most likely a virus. The second one is system file Joomla.
Where are such conclusions from?
The fact is that in principle, no start.php file should be present in the /components/com_weblinks/views/category/ directory.
And the error.php file in the /logs/ directory is part of the CMS. However, if it is specifically deleted, nothing critical will happen, since it serves as a storage for Joomla logs.
Step 2. Protect the site from hacking
Let's assume you have successfully removed all malicious scripts. Hosting technical support and antivirus reported: “yes, everything is clean.” What needs to be done to prevent this from happening?
Updating Joomla and extensions to the latest version
If your site runs on Joomla version up to 3.X, there is another reason to think about upgrading. Lately, many hosting providers have been insisting on this.
This will not solve the security problem 100 percent, but in the future you will have the opportunity to quickly update the system and install security patches with the click of one button, which have recently been released almost every week.
I want to pay special attention installed extensions on your website. Each component, plugin, module must also be updated to the latest version. Conduct an audit in the administrative panel of your site.
Are all extensions used?
Due to low qualifications, modern web masters solve any issue by installing a plugin or module, although it is enough to add a couple of lines to the website template code. Or tweak the CSS.
The less on your site additional extensions, the less likely it is to be hacked!
RSFirewall componentRegardless of the content, a website running the Joomla CMS is susceptible to attacks every day. Hackers guessing the password to the administrative panel and trying to introduce malicious code occur with alarming regularity. It is impossible to resist attacks and intrusions alone.
I would like to draw your attention to a component that solves a huge number of problems related to website security. Its name is “RSFirewall”.
Let's briefly consider the main capabilities, functions and tasks solved by RSFirewall:
Checking your system for vulnerabilities. The database, files, and the environment in which the site operates are analyzed
Comparison of files on your system with the original Joomla distribution. This greatly simplifies the search for infected files.
Analysis of rights to directories and files.
Search for files with malicious code. After the list is displayed, you will have to manually analyze each file, since some of them may turn out to be quite normal working code for Joomla extensions
Logging login attempts to the Joomla administration panel and the ability to block users who entered the wrong login and password a certain amount of once
Logging of any site visits and the ability to block IP addresses from which a hacking attempt was made
Prohibition of access to the site from specified countries.
The component is paid. Current version available exclusively for Joomla versions 3.X
At the time of writing this article is distributed in three versions. Below is a table showing the cost, terms of subscription and a link to the page where this subscription is purchased.
We will explore RSFirewall using “default” localization. That is, the interface language will remain English.
Installation of the component is standard, carried out through the extension manager. After the component is installed, go to “Components - RSFirewall - System Check”
A page will open where we will be asked to check the Joomla and server configuration for resistance to hacking. The following will also be searched:
Joomla files that have been modified and differ from their counterparts from the original distribution
malicious files
rights to directories and files will be checked
In order for the check to begin, just click the “Perform the System Check” button.
Let's consider the result of the analysis.
At the top you can see the number of points or percentages that the component assigns after checking the site. A value of “100” is the highest score. At the moment, the tested site is rated only 84 points. Let's figure out why.
Let's look at the list in detail, not excluding the text highlighted in green.
Joomla Configuration SectionChecking if you have the latest Joomla! Version — Check: is it installed version Joomla is the latest. As you can see, everything is fine with this. At the time of writing this article, the version of Joomla was 3.4.8
Checking if you have the latest RSFirewall! Version - Check: the installed version of the RSFirewall component is the latest. This is an important security characteristic of your system, since from version to version the component not only acquires a database of malicious scripts, but constantly changes functionality according to vulnerabilities discovered in Joomla.
Checking if you have a weak database password - In this case, the component checks the hacking resistance of the database password.
Checking if the default "admin" user is active . - For security reasons, the login of the super site administrator should be different from the widely used “admin”. If the component finds a user with this login in the database, a warning will appear.
Checking if you have set your FTP password - At the stage of installing Joomla or editing its settings, a fatal error is made. FTP access is specified in the Joomla configuration file. There is also an equally tragic option. When saving general Joomla settings, the login and password for the administrative panel are recorded in the FTP access field. Therefore, we make sure that the corresponding parameters in the configuration.php file are empty.
Checking if you have Search Engine Friendly URLs enabled - Checking: whether it is enabled in general Joomla settings SEF URL support.
Checking the integrity of configuration.php — Checking the configuration.php file for correctness and integrity.
Checking if any admin users have weak passwords - Checking all passwords of super administrators of your site for crack resistance
Checking your session lifetime — Checking the session lifetime, which is set in general settings Joomla. If it exceeds 15 minutes, a warning will appear.
Checking if there are any files left in the Joomla! temporary folder - In this case, it is checked whether the files are located in the Joomla temporary directory. By default, this directory is the “tmp” folder. You need to keep this directory clean, because after installing extensions or updating Joomla, there may be unnecessary archives and scripts there.
Checking for .htaccess - Checking for the existence of the .htaccess file. After installing Joomla, the htaccess.txt file is created in the root of the site by default. Your task is to rename it to .htaccess. Exactly as written, with a period at the beginning and without .txt at the end
Checking if the Joomla! temporary folder is publicly accessible - Checks whether the directory for temporary Joomla files is accessible to open access. What is meant by this? Simply put, is it possible to dial in address bar browser link like www.yoursite.com/tmp.
Not everyone knows that it is possible to place a temporary directory so that only Joomla scripts can access it. It is enough to create a folder with an arbitrary name at a level higher than the directory where the site is located and write the path to this folder in the configuration.php file
Checking your Session Handler - Checking the type of session handler. We are recommended to set the value to “No”. This can be done in the general settings of Joomla
Server Configuration SectionLet's move on to the next section, where the server configuration was analyzed.
We can see that the PHP configuration directives from the component's point of view are not configured properly.
There is no need to understand which directive is responsible for what. However, you first need to resolve the issue with the Joomla temporary directory, which I wrote about above.
Copy it to HDD your computer, and delete it from the root of the site, because it is for informational purposes only and tells you the meaning of PHP directives that you should insert into your php.ini
How to find it on the server and whether access is allowed there should be checked with your hosting provider. Often PHP directives are changed by changing the hosting panel settings. Therefore, there is no universal recipe here.
Scan Result SectionHere are the results of the scan of your system. I suggest studying their results.
Scanning the integrity of your Joomla! (CMS) files - in this section the result of scanning CMS Joomla files will be shown and compared with the original distribution for integrity and possible changes to the files. Not only scripts will be compared, but also image and CSS files. Well, that's all.
Scanning your folders - scan via FTP to visit each one and make sure that it is clean from malicious scripts
Scanning your files - in this case we are talking about file rights. The actions should be the same as in the case of directories
Scanning your files for common malware - scanning for the presence of malicious code. As you can see, RSFirewall found one file and when analyzing it in text editor, it was found to be truly malicious and was removed from the server by me.
Let's sum it upUnfortunately, it is not possible to cover all the capabilities and settings of the RSFirewall component in one material. In the next article we will study the component configuration.
If you are not ready to resolve the issue of website hacking on your own, write through the “Contacts” section, or in the chat in the lower right corner of the screen.
Site treatment is carried out for a fee.
The current cost of work is indicated on the page: “Treatment of websites (CMS Joomla) from viruses"
Best regards, Vladimir Egorov
Must be done together. If you eliminate the original cause of the hack (for example, a vulnerability in the CMS extension), but do not remove all the malicious files, the attacker will be able to gain access to the site again using one of his scripts. If you remove all downloaded malicious scripts, but do not eliminate the cause of the hack, the attacker will be able to hack the site again and download scripts onto it again.
A specialist with the appropriate knowledge and experience should carry out work to remove malicious scripts and analyze the causes of hacking:
- To remove malicious scripts, you need to know the language PHP programming, as well as knowledge “from the inside” of popular CMS (Joomla, WordPress, etc.) and extensions for them. This knowledge is required to distinguish scripts directly from the CMS and its extensions from extraneous files, and also to be able to unambiguously determine what actions they perform when encountering dubious scripts.
- To analyze the causes of hacking, server administration experience is required. This is necessary to analyze the state of the files on the account, the time they were changed, and also to compare this data with server logs to determine which actions of the attacker led to the hacking of sites.
Therefore, if your site has been hacked, it is recommended, in order to avoid repeated hacks, not to do the work yourself, but to contact a specialist who will perform the necessary diagnostics and recommend or take the necessary actions to solve the problem, and who can guarantee the quality of the result obtained.
However, there are a number of measures that in some cases help to restore the safe operation of the site without special knowledge. The limitation of the method below is that in order to resume operation of the site, it requires a backup copy of it created before the hack. If the date of the breach is unknown, you can try this method using the oldest backup available. The second limitation, as a consequence of the first, is that after restoring the site, data added to the site after the restore backup was created (for example, new articles, images or documents). If you need to restore the site while retaining new data, you need to contact a specialist.
These measures do not allow us to determine the cause of the site hack, but each of them is aimed at eliminating one of the potential causes of penetration. Since the exact reason for the hack is unknown, it is necessary to perform all of them. The actions are arranged in such an order as to first completely eliminate the possibility of the attacker continuing his activities on the site or hosting account in currently, and then prevent an attacker from entering the site in the future.
The steps below assume that you only have one website on your hosting account. If there are several sites on the account, then they could also be hacked, and the site could be hacked through them. It is necessary to either transfer the site with which restoration work is being carried out to a separate account, or carry out restoration for all sites hosted on the account at the same time.
The order of actions is important, so it is necessary to perform them in the exact order in which they are located below.
All the above actions must be performed in accordance with the specified order, without omissions or any changes. If the actions are performed inaccurately, malicious scripts or vulnerabilities may remain on the site, as a result of which it can be hacked again by an attacker after a short time. If for some reason it is not possible to perform the above steps in the form in which they are indicated, contact a specialist to carry out work to restore the site after a hack.
To protect your site from repeated hacks in the future, you must adhere to the following recommendations:This post was prompted by questions from several site owners about how to remove malicious code from their website. Below I will try to describe the sequence of simple steps, which does not require any special knowledge and will primarily be useful to beginners in the administration of Internet resources.
How do you know if a website has become the victim of an attack during which it was hit with malicious code? The first and simplest thing is that the site has stopped working or does not look the way a “healthy” resource should look. This may manifest itself in the appearance of unwanted content or the disappearance of your content, pages do not load or load with errors. In addition, if your site is added to Yandex or Google webmaster, you high probability Receive notification from these systems about malicious code. In some cases, you can learn about the vulnerability from your browser (screenshot from Google Chrome).
In such cases, it is highly undesirable to try to open the page further.
We are looking for malicious code on the siteWe will not understand the motives of the person who installed malicious code on your site, much less search for it. Our main goal is to find "bad" code and remove it. First, you need to scan the resource to detect all “infected” pages. This allows you to narrow your search. For example, malicious code could be placed in the form Javascript script to some separate page, say, to the contents of a post or a comment to it. In this case, the problem can be solved through the site admin by removing such code from the content/comment. Otherwise, you have to look for it in the source code of your resource.
To scan a site for vulnerabilities, you can use https://sitecheck.sucuri.net As a result, you can see the following:
As you can see from the screenshot, the “bad” script was found on several pages of the site, so you’ll have to look for it in the source code.
Get access to source code site in several ways:
Do not try to find malicious code in the source files of your site, substituting it completely in the search. Select its unique part, such as googleleadservices.cn in our case, and repeat the search several times.
Removing malicious codeOnce malicious code is detected, it simply needs to be removed. In our case, the site was running Joomla, and the “bad” script was inserted into index.php in the root directory. That is why the vulnerability was discovered on several pages at once, since this index.php is used when building all pages of the resource.
Immediately after removing the malicious code, I recommend changing the passwords of all users in the site control panel, and also trying to find the experiences of other administrators who have encountered this problem. It may be necessary to take some additional measures.
PreventionPrevention is always better than cure, so I recommend:
Please leave any questions or comments in the comments.
Loading...
