“This site may harm your computer”. How to recognize and defeat website infections

Mass website infections are one of the biggest problems in contemporary IT security. The size of the problem is reflected, for example, in the amount of queries to our Technical Support concerning warnings about malicious websites. Website owners usually complain that our product incorrectly blocks access to their portal and it must be a false alarm as they do not host any malicious content. Unfortunately, in most cases they are wrong and malicious scripts can indeed be found within their websites – injected into the original PHP, JS or HTML code by attackers. These scripts usually redirect visitors to the website to malicious URLs from where malware is downloaded and executed on the victim’s computer. In most cases, the execution of malware is completely invisible to the user, who sees the website appearing to operate as usual. Malicious code exploits vulnerabilities in software running on the user’s computer (like Java, Flash, PDF viewers, browser plugins, etc.) to silently install itself on an attacked machine. This method is called a “drive-by download” and has already been extensively described on Securelist.

In the following article we would like to focus on information that may help website administrators identify and remove malware from their websites.

• What is happening? Infection symptoms.
• What to look for. Examples of malicious code.
• How did it happen? Attack vectors and techniques.
• What is the purpose of it? The cybercriminals’ goals.
• How to defeat website infection. Removal methods.
• How to prevent website infection. Website security basics.

Infection symptoms

How do you know if your website has been infected? The best symptoms are the most obvious ones:

• users complain that the website is blocked by the browser and/or security software;
• the website is denylisted by Google or added to some other database of malicious URLs;
• there is a significant change in traffic and/or drop in search engine rankings;
• the website doesn’t work properly, displays errors and warnings;
• after visiting the website, computers exhibit strange behavior.

It often happens that the infection remains unnoticed for a long period of time, especially in the case of more sophisticated malware. Such malware is usually heavily obfuscated – in order to mislead both website administrators and security software – and it constantly changes the domain names to which it redirects, bypassing the denylisting approach. If you do not notice any of the above mentioned symptoms it’s a good indication that your server is clean, but please remain alert to any suspicious activities.

The most reliable sign of every single infection will be the presence of malicious/suspicious code in one or more files on the server – mainly HTML, PHP or JS files, but recently also ASP/ASPX. It’s not easy to find this code and it requires at least a basic knowledge of programming and website development. In order to familiarize the reader with what the malicious code may look like, below are some examples of most common web injections.

Example 1: Simple redirection

The oldest and least complicated method used by cybercriminals is attaching a simple HTML IFRAME to the code of HTML files on the server. The address used to load the malicious website in the frame is specified as the SRC attribute and the VISIBILITY attribute set to “hidden” is responsible for making the frame invisible to the user who is browsing the website.

Figure 1: Malicious IFRAME inside the HTML code of the website

Another technique for executing malicious script in the user’s browser is injecting a link to this script into an HTML file as the src attribute in the script or img tag:

Figure 2: Examples of malicious links

Recently, there have been more cases where malicious code is dynamically generated and injected into the HTML files by a malicious JS or PHP script. In such cases, this code is visible only in the source view from inside the browser, but not in physical files on the server. Cybercriminals may additionally define conditions where the code has to be generated: for example, only when the user has come to the website from certain search engines or opened the website using a particular browser.

In order to deceive both the website owner and security software, and to impede the analysis of malicious code, cybercriminals use a variety of different techniques of code obfuscation.

Example 2: “404 Not Found”

In this example, malicious code is injected into the template of the message that is displayed when the specified object has not been found on the server (the famous HTTP 404 response). Additionally a link to some non-existent element is injected into the index.html / index.php files in order to silently trigger this error every time a user visits the infected web page. This method may cause some confusion: the person responsible for the website receives the information that some AV software has flagged this website as infected; after superficial investigation, it turns out that the malicious code was found in an object that apparently doesn’t exist; now, it’s tempting to (wrongly) assume that it is just a false alarm.

Figure 3: Trojan.JS.Iframe.zs – malicious script in the template of a 404 error message

In this particular case, the malicious code has been obfuscated. After de-obfuscation, we can see that the purpose of this script is to inject an IFRAME tag, which will be used to redirect users to a malicious URL.

Figure 4: Trojan.JS.Iframe.zs – malicious code after de-obfuscation

Example 3: Profiling infections

Similar code can be generated and attached dynamically (i.e. depending on specific circumstances) to all HTML files located on a server by using a malicious PHP script uploaded to the same server. The script shown in the following example checks the UserAgent tag – which is sent by the user’s browser and by search bots as well – and doesn’t append the malicious code if the website is visited by bots and by Opera, Chrome or Safari users. Hereby, users of browsers that are not vulnerable to the particular exploit used in this attack will not be redirected to that exploit at all. It’s also worth noting the deceptive comments that may suggest this script is somehow related to bot statistics.

Figure 5: Trojan.PHP.Iframer.e – PHP infector

This method can also be used in the opposite direction – cybercriminals may inject links to some illegal, shady or malicious content (like spam, spyware, pirated software and phishing) only if a search bot is visiting the website. The purpose of such an attack is so-called Black Hat SEO: a mechanism of optimizing search results for the cybercriminal’s resources. Such malware usually targets high-profiled portals with a well-elevated Page Rank; and it’s rather difficult to discover, as a regular user will never be presented with the malicious code. As a result, malicious websites are highly rated by search engines and therefore they start to appear at the top of search results.

Example 4: Tricky obfuscation

PHP infectors can take other forms as well. Below are two examples that were discovered and described on our blog several months ago (here and here).

Figure 6: Trojan-Downloader.PHP.JScript.a – PHP infector

Figure 7: Trojan.PHP.Injecter.c – PHP infector

The first of these examples (Trojan-Downloader.PHP.JScript.a) injects malicious JavaScript into the code of HTML files just after one of the defined closing tags (i.e. script, div, table, form, p, body). The content of the injected script is not plainly written – it’s delivered in the form of numbers and stored in two arrays: $tr and $tc. The de-obfuscation is performed “on-the-fly”. The code generated in this manner is also obfuscated, but in a different way:

Figure 8: Trojan.JS.Redirector.px – malicious JavaScript injected into HTML file

At first glance, one might think that this script has something to do with the colors displayed on the web page. Alas, this impression is completely wrong – the script converts the values it stores in the div_colors array into the ASCII characters and then builds the malicious URL, which is further appended to the HTML file with the use of document.write() or document.createElement() functions.

The second PHP script (Trojan.PHP.Injecter.c) is even trickier: the malicious URL is written with the use of “invisible” characters: space and tabulator. If we assume that space == “0” and tab == “1”, we will get binary code; every 8-bit chunk of this code is a decimal representation of one ASCII character.

Example 5: Infected JavaScripts

The infectors described above were placed in PHP files uploaded to the server by cybercriminals using vulnerabilities in the CMS software or stolen FTP credentials. A different method is to infect legitimate JS files that already exist on the server. Out of a wide range of examples of this, it’s worth mentioning at least three different cases that have been widespread over the last few months.

In the first one, the following code is dynamically injected into HTML files:

Figure 9: Trojan.JS.Iframe.zs – malicious IFRAME dynamically injected into HTML

The script responsible for appending this code is placed in one or more JS files on the server:

Figure 10: Trojan.JS.Iframe.zs – script that injects an IFRAME – after de-obfuscation

In the next case, the hexadecimal form of ASCII characters was used for the obfuscation. All JS files on the server are infected with similar code:

Figure 11: Trojan-Downloader.JS.Agent.gnm – malicious code injected into JS files

In another popular scenario, besides the standard obfuscation methods there are also comments in Latin – probably inserted there to make the script look legitimate and gain the administrator’s trust – although they are just a random sequences from the famous “Lorem ipsum” formula 🙂

Figure 12: Trojan-Downloader.JS.Twetti.t – malicious code injected into JS files

Finally, we have a mass web malware outbreak in which random domain names are used. The code you can find on your website, if infected with this malware, looks like this:

Figure 13: Obfuscated version of code that redirects to a randomly-created domain

Example 6: “gootkit” and obfuscation of the whole file

Obfuscated malicious code is easy to spot inside the clean file, so the cybercriminals recently came up with the idea of obfuscating the entire content of the file, making both the injected script and the legitimate code unreadable. It’s not possible to distinguish the good code from the harmful code, so there is no way to disinfect the file without decrypting it.

Figure 14: File obfuscated by the “gootkit” malware

Getting rid of the first layer of obfuscation is not very difficult, as all you need to do is to change the eval() function to the alert() function – or print() function in case of console – and execute it. The second layer is a bit trickier: it uses the domain name as the key to encrypt the code.

Figure 15: “gootkit” – second layer of obfuscation

After the decryption, we can see the malicious code, followed by the original content of the file:

Figure 16: “gootkit” – de-obfuscated code

It happens that the malicious part is the second version of the malware mentioned in the previous example and is used to generate the pseudo-random domain name for the redirection.

Example 7: .htaccess

Instead of infecting scripts and HTML code, attackers can also use the possibilities provided by some configuration files, such as .htaccess files. In these files the administrator can define permissions to access particular folders on the server as well as redirect users to other URLs in specific circumstances (e.g. if the user-agent comes from a mobile browser, the user will be redirected to the mobile version of the website). It’s not hard to guess how cybercriminals use this functionality…

Figure 17: .htaccess malware

In the above example, all the users who visited this website by clicking a link from most of the major search engines (HTTP_REFERER parameter) are redirected to the malicious URL. In addition, there is quite a big list of browsers and bots which will not trigger the redirection (HTTP_USER_AGENT parameter). The redirection will not occur if the web page is read from the cache (referer == cache), nor if the web page is loaded again from the same computer (the cookie parameter).

Such malware can be used for even more profiled infections – for example, the exact IP addresses can be excluded, so that browsing to the website from within a specific IP range – for example, one belonging to a security company – will return no malicious results.

Attack vectors and techniques

Regardless of which technique they use, cybercriminals need to find a way to drop malicious files, or modify files already on the server. The most primitive method to gain access to the server is to crack the access password. In order to do so, cybercriminals can use a so-called brute-force attack or its limited version – a dictionary attack. Such tactics are usually time consuming and require a lot of resources, so this method is rarely used for mass web infections. More popular scenarios include exploiting vulnerabilities and password-stealing malware.

Use of vulnerabilities in content management / e-commerce systems

Most contemporary web management platforms (like CMS, e-Commerce, control panels, etc.) are not perfect and contain vulnerabilities that let someone upload files to the server without any authentication. Such vulnerabilities are discovered on a regular basis, while patches are released too slowly; moreover a lot of users still use older, much more bug-infested versions of software. As the most targeted platforms we may consider the most popular ones – like WordPress, Joomla and osCommerce. An infamous example of such a vulnerability is the TimThumb vulnerability, which was widely used by cybercriminals in various drive-by download scenarios. TimThumb is the PHP module for resizing images and creating so-called thumbnails and is included in most of the public CMS templates. The vulnerability allowed files from a remote location to be written into the cache directory on the server. Another example is the SQL injection vulnerability in Plesk Panel (versions 10 and older), discovered in February 2012, that makes it possible to read databases and steal passwords, which were – until recently – stored in plain text. Credentials obtained in such manner were probably used in a recent mass web malware outbreak: https://securelist.com/who-is-attacking-me-23/33307/, https://securelist.com/runforestrun-gootkit-and-random-domain-name-generation/57865/.

Use of spyware designed to steal FTP credentials

In most widespread web infections (such as Gumblar and Pegel) a different method has proven successful. In the first stage, cybercriminals propagate malware that is specially designed to look for and steal usernames and passwords to FTP accounts either by checking the FTP client settings or by sniffing the network traffic. Once the malware finds these credentials, it connects to the FTP server and uploads malicious scripts, or overwrites original files with infected versions. It goes without saying that until the account holder’s computer is disinfected, files on the server will be re-infected all over again, even after changing the login details and restoring all content from a clean backup.

The cybercriminals’ goals

What’s the purpose of spreading web malware?

• to redirect users to exploits in order to silently install malware on their computer;
• to redirect users to spam, phishing and other malicious, illegal or unwanted content;
• to hijack the site traffic / search traffic;
• to promote malicious / illegal / spam websites (Black Hat SEO);
• to use server resources for illegal activity.

Generally speaking, there’s nothing new here: it’s indirect financial gain that drives cybercriminals to infect websites.

Removal methods

What to do if your site gets hacked? First of all, if you see any symptoms of possible infection, you should immediately deactivate your website until the problem has been resolved. This is really essential, as every moment of delay acts in favor of the cybercriminals, exposing more potential victims to the problem and spreading the infection over the Internet. You should also check the server logs to see if there is any suspicious activity, like strange requests from IP addresses located in unusual countries, and so on. It could be helpful in locating the infected files and determining how the cybercriminals accessed the server. How to fight the malicious code, then?

Backup copy

The fastest and most reliable solution is to restore all the content of the server from a clean backup copy. To make this solution effective, you must also perform a full reinstall of the software that runs on the server (like CMS / CMF, e-commerce system, etc.) – and, of course, you should use the most recent, fully updated versions for that. After such action, there no infected files should remain on the server – as long as you erase all the content before the recovery and your backup copy was created before the attack.

Automated scan

If you don’t have a clean backup copy, there’s not much of a choice but to fight the malware on your own. Fortunately, there are several automated solutions which can help you in locating the malicious code – including antivirus products and online website scanners such as http://sucuri.net/. None of them is perfect, but in the case of known / common malware all of them may prove extremely helpful. To start with, you can check your website with a few online scanners. Some of them will not only confirm whether your site is indeed infected, but also point out the malicious code within your files. Then you can perform a full antivirus scan on all of your server files. If you own the server, or if there is a security solution running on the server which you have permission to use, you can perform the scan on the server side. Make sure you’ve made a copy of your files, as some AV scanners will delete infected files rather than disinfect them! You can also download the contents of your server to your local computer, and scan it using your desktop Internet Security solution. The second option is better, as most contemporary desktop AVs have a well-developed heuristic module. Website malware is highly polymorphic: while static signatures are almost useless against it, it can be easily detected with heuristics.

Manual removal

If an automated scan proves unsuccessful and your site is still reported as infected, the only way to get rid of the infection is to manually search for, and delete, all instances of the harmful code. It’s not an easy task and it may be quite time-consuming, as you need to check every single file – be it HTML, JS, PHP or configuration file – for the presence of malicious scripts. The examples above are just a small fraction of all the possible forms website malware comes in, so there is a high probability that the code on your site will be either slightly or completely different. However, most contemporary website infections have some things in common, and these features may be helpful in diagnosing the problem.

Most of all, you should pay attention to every piece of code that looks obscure and unreadable. Code obfuscation is a common technique for malware writers and it’s relatively unusual for any other website-related software. If you haven’t obfuscated the code yourself, you have every reason to be suspicious about it. Do be careful, though – not all obfuscated code will prove malicious!

Similarly, not every malicious script will be obfuscated, so you need to look for plain text IFRAMES, as well as for other links to external resources in all of your files. Some of them may be related to advertisements and statistics, but don’t be fooled by the URLs – they may confusingly resemble the addresses of known and trusted portals. Don’t forget to check the templates of error code messages and all the .htaccess files as well.

Useful tools for hunting malicious code on the server are certainly grep and find – command line utilities, included by default in pretty much all Unix-based systems. Below are some examples of how to use them to diagnose the most popular infections:

grep -iRs “iframe” *
grep -iRs “eval” *
grep -iRs “unescape” *
grep -iRs “base64_decode” *

grep -iRs “var div_colors” *
grep -iRs “var _0x” *
grep -iRs “CoreLibrariesHandler” *
grep -iRs “pingnow” *
grep -iRs “serchbot” *
grep -iRs “km0ae9gr6m” *
grep -iRs “c3284d” *
find . -iname “upd.php”
find . -iname “*timthumb*”

The description of grep (taken from the Linux manual) states: print lines matching a pattern; -i option stands for ignore case; -R means recursive and -s will prevent writing error messages to the output. The first of the listed commands will look for all IFRAME tags in the files; the next three will look for the most obvious signs of obfuscation; the last ones will look for specific strings that are related to major known website infections.

As for find, the Linux manual states: search for files in a directory hierarchy; the dot indicates the current directory (so you should run these commands from within the root directory or your home directory on the server) and the -iname parameter specifies the filename to look for. You may use regular expressions to find all files that meet the given criteria.

Of course, you must always know what to look for – not all of the results will indicate an infection. You may want to scan suspicious pieces of code with an AV scanner or try to google it – it’s highly likely that you will find some answers, in case of both malicious and clean code. If you’re still not sure whether the file is infected or not, it’s best to deactivate the website (just in case) and consult a specialist before taking any other action.

Very important notice!
Apart from cleaning the files on the server, you must remember to perform a full antivirus scan of all the computers that are being used to upload and manage the content on the server and to change all login credentials to all the server accounts (FTP, SSH, administration panels, etc.) that you maintain.

Website security basics

Unfortunately, in most cases cleaning out the malicious code is not enough to get rid of the infection once and for all. Once your website gets compromised, it probably means that there are some vulnerabilities that allowed cybercriminals to drop or inject malicious scripts on the server; and if you pay no attention to them, you can expect new infections in the near future. To prevent this from happening, you need to take appropriate action in order to secure your server and the computer(s) used to connect to the server account.

• Using strong passwords – however trivial it may sound, this really is the foundation of server security. Passwords should not only be changed after any malware incident and/or attack on the server – you should change them on a regular basis – say, once a month. A good password should meet specific criteria, which you can read about on our web site;
• Being up-to-date – the next thing to remember is to perform regular updates. Cybercriminals tend to exploit vulnerabilities in software, no matter whether the malware is aimed at PC users or at websites and web servers. All the software that you manage from your server account should be the newest possible versions and every single security patch should be applied as soon as they are released. Keeping all software fully patched and up-to-date will decrease the risk of an exploit-based attack. A regularly updated list of known vulnerabilities can be found on http://cve.mitre.org/;
• Creating frequent backups – having a clean copy of server content will certainly save you a great deal of time and effort – not to mention that a fairly recent backup may prove very useful when dealing with other problems, as well as infection;
• Regular file scanning – even if there are no visible infection symptoms, it’s good practice to scan all server files once in a while;
• Taking care of PC security – as a great deal of website malware is spread with the use of infected PCs, the security of the desktop computer used to manage your website is one of the most important aspects of website security. Keeping your computer clean and safe at all times will significantly improve the chances of your website staying safe and clean as well.
• Server hardening – if you own the server, you should pay attention to configuring it as securely as possible. Such activity may include, but is not limited to:
  • removing all unused software;
  • disabling all unnecessary services and modules;
  • setting appropriate policies for users and groups;
  • setting secure permissions / restricting access to certain files and directories;
  • disabling directory browsing;
  • collecting log files, which are checked for suspicious activity on a regular basis;
  • using encryption and secure protocols.

Website malware is a real nightmare for both web administrators and Internet users. Cybercriminals are constantly improving their techniques and uncovering new exploits. Infections spread very quickly across the Internet, affecting servers and workstations as well. It’s true to say there is no reliable way of eliminating this threat completely. However, every single website owner and every single Internet user can make the Internet a bit safer by following basic security rules and keeping their websites and their computers safe and clean at all times.