Websites compromised due to injection of JavaScript code

In recent days, a system admin reported us that his website had been blocked and that his browser detected his site as malicious despite being legitimate. For this reason, UNAM’s Computer Emergency Response Team proceeded to analyze it.

Many antivirus engines identified that the website hosted an unwanted program that could be a virus.

The site was fully downloaded so that we could examine the HTML files to find a possible reference about the allegedly download of a malicious file or about a redirection to an external website.

We came across the code that can be seen on the image below, which turned out to be suspicious because it used another process to obfuscate itself.

On the image above, marked with green, are the labels that contained the injected JavaScript code. Additionally, displayed in red, is the set of hexadecimal characters that contained the obfuscated code, which executed each time the user accessed the site.

The writers of this code changed the name of some functions to difficult the analysis of the sample. Since we were dealing with JavaScript code, we could insert the function document.write(), which allowed us to print the code on the browser. The insertion was done by replacing the function eval(), which had been substituted by the variable “e”. The section of code replaced is given by “e(zas)” and can be observed before the label </script>.

After this procedure it was possible to print the code on the screen. The results obtained are shown below.

The site jsbeautifier was used to present the code in a more legible way:

The declaration of the functions zzzfff(), SetCookie() and GetCookie() can be easily observed.

The function zzzfff() injected an iframe on the website, which contained a link to an external site, identified by the declaration of the variable csp.src on line number 3; the rest of the lines defined the size of it.

The function SetCookie() created a cookie that stored in the user’s computer. This function received as parameters the name of the cookie (cookieName), its value (cookieValue), the number of days before expiration (nDays) and the path on the website on which it was going to be active.

The function GetCookie() searches among the set of stored cookies to determine if the cookie has been establish on the user’s computer.

Starting from line 36 we could see the next code block:


At first, the code tries to validate that the browser employed by the user supports cookie persistence, if this is the case, it proceeds to make use of the function GetCookie(), to check whether the cookie called “visited_uq” had the value 55. If it did, the execution of the code got terminated; this meant that the user had previously visited a malicious site that set this value. If the cookie had a different value, the function SetCookie was called to create the cookie with the following parameters: name=”visited_uq”, value=55, duration= 1 (day) and path=”/”; this last parameter indicated that the cookie was going to be valid for the whole domain and not just for one site of it.

After determiningthenature of the code, we proceeded to search for the entire domain to discover out whether the code had been injected on a different site to index.html. On the analysis, we found out that the intruders put the malicious code on every HTML file, by doing this they made sure that the users who did not visit the site directly through the main page were also affected by the execution of the code. The results obtained are shown below.

When a user visited a website of this nature, he wasn’t affected by the exploitation of vulnerability on the browser o the download of malicious software. Interestingly, exploited websites served as intermediaries to redirect the users to sites where some kind of malicious software is finally downloaded or that contained advertisements for the sale or purchase of different items.

Due to the user being redirected to a site written in PHP, it is not possible to know the type of validations that it made but, in general, the following case was identified: When the site is accessed directly, without being previously redirected by an exploited website. In this case, we could determine that the site tried to avoid analysis by not redirecting the user to the download of malware (or advertisements), instead it redirected to the user’s localhost.

On the image below, part of the captured network traffic, obtained after visiting the malicious site directly, is shown.

Marked in red is the redirection to the user’s local domain, which is a very uncommon pattern.

On the other hand, if the site confirmed that the user had the cookie “visited_uq” with a value of 55, the user was redirected to a page that was probably infected. On the image below is shown one of the sites to which the malware redirected:

If, for example, it is necessary to confirm the presence of the cookie, it is possible to use the cookie handler of the browser. As seen on the next image, the cookie was created after an infected website was visited.

Subsequently, the domain was analyzed using the Sucuri SiteCheck. On the results, it can be seen that the website had been added to the black list.

However, because there was no malicious file found inside it, antivirus engines classified it as clean.


Using the website we confirmed the server was located in Japan.


The use of this kind of techniques to compromise users has increased. If the pattern of the injected code is searched, reallysignificant numbersare obtained: google displayed 34,900 results.

In many cases the code injection is not carried out successfully, so it ends up being displayed on the website.

If our computers have been compromised, it is necessary to delete the code injected on the web files and to check the server’s configuration.

On the next link there is an excellent guide about how to identify and keep our servers secure against this kind of threats.

It is important to be constantly verifying the server’s logs to detect anomalies.