Let’s take a deeper look into the much talked-about malicious sites discussed here.

As an overview, the whole process starts with a user searching for a certain string in the Google search engine (e. g., “Christmas”). After the search engine returns several search results, the user visits one of the sites. The catch is on the result set where there are several malicious sites hosting a malicious script, which in turn can lead to the compromise of the user’s system.

In this case, the malicious script redirects to another web page using the “window.location={url}” function.

It’s somewhat simple. However, there is a little catch for us security researchers. We now look at the “if” statement where it relies on the “document.referrer” function. The code tells that in order for the “eval” function to be executed, the page where the user visited before arriving on the malicious Web page should be a page containing Google search results. Also, the search string used by the user must not have the “inurl:” and “site:” Google search functions. Thus, direct visit or access of the malicious site will not trigger the evil script and not redirect us to the site hosting the malicious binary file.

For security reseachers developing tools to automate the capture of the malicious files found on Web threats, this is something to consider. It is clear that this is a limitation for tools designed to directly access the malicious site aiming to capture the malicious files. The affected tools include honeyclients, Web crawlers, and downloaders.

Several modifications and enhancement to our tools should be applied in order to catch these kinds of Web threats.

If you're new here, you may want to subscribe to our RSS feed. Thanks for visiting!