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

7/28/2019 “This site may harm your computer”. How to recognize and defeat website infections - Securelist

http://slidepdf.com/reader/full/this-site-may-harm-your-computer-how-to-recognize-and-defeat-website 1/8

English Calendar Dis cus sions Polls RSS feeds Subscriptions Contacts Log in Search

Internet threat level: 1 Watch us on

Threats Analysis Blog Statistics Descriptions Glossary

This site may harm your computer”. How to recognize and defeatwebsite infections

Contents

Infection symptoms

Attack vectors and techniques

The cybercriminals’ goals

Removal methods

Website security basics

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 moscases 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 blacklisted 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 blacklisting 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 cybercr iminals 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 isspecified 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.

PrintShare

Author

Marta Janus

All analysis articles

All blog postings

Anal ysi s

Kaspersky Security Bulletin 2009.Malware Evolution 2009

Browsing malicious websites

The Cash Factory

Drive-by Downloads. The Web

Under Siege

Malicious website evolution:

January – June 2007

Bl og

“RunForestRun”, “gootkit” and

random domain name generation

The end of DNS-Changer

Who is attacking me?

DNSChanger - Cleaning Up 4

Million Inf ected Hosts

Two-pronged attack: Argentine

site hit by malware and data leak

Source

Kaspersky Lab

Home → Analysis → 18 Sep 2012 → “This site may harm your computer”. How to recognize and defeat website infections



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

Another technique f or 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 dif ferent techniques of code obf uscation.

Example 2: "404 Not Found"

In this example, malicious code is injected into the template of the message that is d isplayed when thespecified 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 inf ected web page. This method may cause some confusion: the person

responsible f or the website receives the information that some AV software has f lagged this website as

infected; af ter 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 obf uscated. Af ter 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 f or the cybercriminal's resources. Such malware usually targets high-prof iled



portals with a well-elevated Page Rank; and it's rather dif ficult 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: Troja n-Downloader.PHP.JScript.a – PHP inf ector

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 af ter one of the def ined closing tags (i.e. script, div, table, f orm, 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-obf uscation is performed “on-the-f ly”. 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 f irst 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 dif ferent cases that have been widespread over the last few months.

In the f irst 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.If rame.zs – script that injects an IFRAME – after de-obfuscation

In the next case, the hexadecimal f orm of ASCII characters was used for the obfuscation. All JS f iles on

the server are inf ected with similar code:

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

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 – a lthough

they are just a random sequences from the famous “Lorem ipsum” formula :)

Figure 12: Trojan-Downloader.JS.Twetti.t – ma licious 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: Obf uscated version of code that re directs 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 obf uscating 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 f rom the harmful code, so there

is no way to disinfect the f ile without decrypting it.



Figure 14: File obfuscated by the “gootkit” malware

Getting rid of the first layer of obfuscation is not very diff icult, 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, f ollowed by the original content of the f ile:

Figure 16: "gootkit" – de-obf uscated 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 inf ecting scripts and HTML code, attackers can also use the possibilities provided by some

conf iguration files, such as .htaccess files. In these files the administrator can def ine 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 f rom 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 f unctionality...

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 f or 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 f iles 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 platf orms

we may consider the most popular ones – like WordPress, Joomla and osCommerce. An infamousexample of such a vulnerability is the T imThumb 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 i

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:

http://www.securelist.com/en/blog/208193624/Who_is_attacking_me,

https://www.securelist.com/en/blog/208193713/RunForestRun_gootkit_and_random_domain_name_gene

Use of spyware designed to steal FTP credentials

In most widespread web infections (such as Gumblar and Pegel) a dif ferent 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 traff ic. Once the malware finds these credentials, it connects to the FTP server and uploads

malicious scripts, or overwrites original f iles with infected versions. It goes without saying that until the

account holder’s computer is disinfected, f iles 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 recen ,

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 o f 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 inf ection 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 conf iguration 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 helpf ul 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 f or any other website-

related software. If you haven't obf uscated the code yourself , you have every reason to be suspiciousabout it. Do be caref ul, though – not all obf uscated 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 f iles. Some of them may be related to

advertisements and statistics, but don't be fooled by the URLs – they may conf usingly resemble the

addresses of known and trusted portals. Don't f orget to check the templates of error code messages and

all the .htaccess files as well.

Useful tools f or 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 -i Rs “i f rame” *

grep -i Rs “ev al ” *

grep -i Rs “unescape” * grep -i Rs “base64_decode” *

grep -i Rs “var di v _col or s” *

grep -i Rs “var _0x ” *

grep -i Rs “CoreLi brar i esH andl er” *

grep -i Rs “pi ngnow” *

grep -i Rs “ser chbot” *

grep -i Rs “km0ae9gr 6m” *

grep -i Rs “c3284d” *

f i nd . -i name “ upd.php”

f i nd . -i name “ *ti mthumb*”

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 knownwebsite infections.

As for find, the Linux manual states: search for files in a directory hierarchy; the dot indicates the curren

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 inf ection. 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 f ind 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

Unf ortunately, 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 connec

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/;



Oldest first Newest first Threaded viewTable view

Donna J.Marn2012 Sep 19, 01:33

0

Sumit Katule2012 Sep 24, 15:37

0

If you w oul d l i ke to comment on thi s arti cl e you must f i rst l ogi n

Creating frequent backups – having a clean copy of server content will certainly save you a grea

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 importan

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.

2 comments

I Love,Kaspersky Anti-Virus

You are the Greatest,Thank You all!

Reply

Network ATTACK........

After the 2 network attack my coputer will be slow down,i lost my whole data and due to which i

had to format it... what a rubbish anti-virus it is......

Reply

© 1997-2012 Kaspersky Lab ZAO. A ll Rights Reserved.

Industry-leading Antivirus Software.

Registered trademarks and serv ice marks are the property of their respective ow ners.

kaspersky.com

Products

eStore

Threats

Downloads

Support

Partners

About Us

Search

securelist.com

Threats

Analysis

Blog

Descriptions

Glossary

RSS feeds

Contacts

Search

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

Documents

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