Every once in a while we get a case that makes us dig deep to find answers. We have spoken before about the trouble with forensics and reasons why websites get hacked. Sometimes though, the answer is not clear and we can only gather clues to make an educated guess. Our main business is preventing hacks and cleaning them up, but we always try to go above and beyond when we get questions about the methods and reasons behind hacks.
One of the websites we protect was experiencing an abnormal increase in traffic. In just one month, they saw 4 times as much traffic as the previous months. It was a mystery to them where it was all coming from.
The requests themselves were not doing anything nefarious, but upon investigation, our Website Firewall was adding rules to block the traffic from returning by temporarily blocking the offending IP addresses. Though the requests were benign in nature, their behavior was definitely suspect and triggered our automatic protection. We were curious about the source of this strange traffic, and looked to provide our customer with any insight on where this surge in traffic might be coming from.
This is what makes our jobs interesting. Even though I’m technically in marketing, there are so many ways that crooks can exploit code and internet protocols. Many of these nefarious online acts unfortunately intersect with marketing, advertising, and analytics. Everyone on our team works together to solve these cyber crimes, helping out when we have a little bit more knowledge in Google Analytics, or previous experience with a specific operating system. Before I lay this out, I have to thank Jarret Cade, Marc Kranat, and Rafael Capovilla for helping me find and analyze this case. Though our team never got a clear and confirmed answer to this mystery, the process of analyzing these cases interests all of us.
The client noticed that in Google Analytics, a lot of traffic was coming from a source that was not set. She also noticed right away that there was also a lot of referral spam from free-social-buttons.com and other top offenders involved in this kind of analytics spam.
Finding the Clues
Throughout the logs were chunks of requests that looked similar to this:
72.229.103.104 – – [31/Jul/2015:19:00:28 -0400] “GET / HTTP/1.1″ 200 1055 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19″ “PROXYBLOCKID:” “CACHEP:-” 72.229.103.104 – – [31/Jul/2015:19:00:28 -0400] “GET / HTTP/1.1″ 200 1062 “http://clientwebsite.com/"; “Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20100101 Firefox/12.0″ “PROXYBLOCKID:” “CACHEP:-” 72.229.103.104 – – [31/Jul/2015:19:00:28 -0400] “GET / HTTP/1.1″ 200 1016 “http://clientwebsite.com/"; “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)” “PROXYBLOCKID:” “CACHEP:-” 72.229.103.104 – – [31/Jul/2015:19:00:28 -0400] “GET / HTTP/1.1″ 200 1058 “http://clientwebsite.com/"; “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729; .NET4.0E)” “PROXYBLOCKID:” “CACHEP:-” 72.229.103.104 – – [31/Jul/2015:19:00:28 -0400] “GET / HTTP/1.1″ 200 998 “http://clientwebsite.com/"; “Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3″ “PROXYBLOCKID:” “CACHEP:-” 72.229.103.104 – – [31/Jul/2015:19:00:28 -0400] “GET / HTTP/1.1″ 200 1010 “http://clientwebsite.com/"; “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB7.3; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)” “PROXYBLOCKID:” “CACHEP:-” 72.229.103.104 – – [31/Jul/2015:19:00:28 -0400] “GET / HTTP/1.1″ 403 2354 “http://clientwebsite.com/"; “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0; FunWebProducts)” “PROXYBLOCKID:CUST01″ “CACHEP:-”
Lets break down these logs a bit.
This chunk of requests (one of many) is coming from the same IP address at the exact same second. Each chunk of requests like this had a different IP address though. This pattern repeated itself throughout the logs during the length of the traffic spike.
We can see the first request in the group has a blank referrer “-“, but the following six requests show the referrer is actually the client’s website. This helps the attacker avoid spam filters that prevent bad referrers or bot traffic by mimicking normal surfing behavior. While you could block blank referrers in theory, it is not generally an acceptable practice because you can block Google from scanning your website, and that’s not good.
The next thing we see is a list of different user agent strings. This is where things get interesting. Fake user agent strings can be generated easily by attackers, but there are some interesting patterns to note here that suggest this might not be the case.
FunWebProducts: Not That Fun
In the chunk of the requests above, FunWebProducts is listed in one of the user agents. This user agent was frequently used throughout the other chunks of requests from other IP addresses, and it was one pattern that we noted. For me, this was a pretty strong indication that we may be dealing with a zombie army of infected computers.
FunWebProducts is a set of browser add-ons that often get bundled with installers on websites like CNET. Users download executable software from these sources and forget to uncheck optional offers from third-parties, like FunWebProducts.
Many people would remove SmileyCentral or MyWebSearch toolbars if they accidentally installed them along with other software, but even among savvy users, the malicious web looks more and more legitimate every day. It’s hard for the average user to know if they are being attacked in a world of malvertising, rogueware, and fake update notifications.
People who do not remove FunWebProducts from their computer have some security concerns:
- They don’t uncheck the optional boxes on installers
- They don’t regularly audit their applications and add-ons.
- They don’t run an AntiVirus program, because most would pick up FunWebProducts as a Potentially Unwanted Program (PUP) and recommend the user remove it.
A visitor who has FunWebProducts in their user agent probably doesn’t take security seriously enough.
Flood By FunWebProducts?
At first, our team wondered if FunWebProducts was connected to the traffic flood somehow. Their EULA allows them to collect usage statistics, which could include scraping pages visited by their users. This allows adware to send data back to a log server, analyze it, and deliver better ads to toolbar users.
In looking around their website, I noticed the footer contains links to websites you wouldn’t expect: CollegeHumor, Hotels.com, and Expedia. My first thought was that FunWebProducts might also have their hands in blackhat Search Engine Optimization (SEO).
After a quick search, it appears that all of these websites, including FunWebProducts, are owned by InterActiveCorpo (IAC) – just a small part of their more than 150 brands across 100 countries. Some notable inclusions are popular dating sites like Tinder, OkCupid, and PlentyofFish, and reference websites like About.com, Ask.com, and Dictionary.com.
As much as FunWebProducts is annoying, there doesn’t seem to be much for a huge media conglomerate like IAC to gain by flooding the traffic of an innocent and comparatively small website that has nothing to do with their niches.
Other Risky User Agents
Only one of the requests had FunWebProducts for the user agent. What about the other ones?
Maybe you already noticed that one of the other user agents is running Internet Explorer 7 on Windows XP? Defunct browsers on defunct operating systems. Not a good sign.
These new ‘visitors’ not only have FunWebProducts, but they also use decade-old operating systems and outdated browsers. It’s highly likely that they are infected with more sinister malware. This suggestion comes from personal experience. I used to clean and fix Windows computers remotely, so I have seen all kinds of infections. FunWebProducts was almost always there alongside spyware, rootkits, and trojan horses.
Before you point out the iPad user agent… yes, I see it too. If you think that Apple is 100% safe, I have to point to personal experience again. Years ago, my Macbook was infected and part of a botnet. I found it using Little Snitch and though it was easier to remove than Windows infections, nonetheless an illegitimate DivX folder was sending malicious traffic requests from my machine. Furthermore, iPads and iPods can be infected with botnets simply by being connected to an infected PC running iTunes.
Infected Computers Attacking Websites
All of the requests from these infected computers (and server farms) are also rotating through their set of IP addresses. By using the IP address of the infected machines visiting the website, the botnet is unlikely to be compromised and requests can still be fulfilled. You can temporarily block the IP, but it is going to be different in the next chunk of requests.
It’s not uncommon for botnets consisting of infected home computers to attack smaller websites. In this case, it isn’t at the level of a bandwidth-overloading Distributed Denial of Service (DDoS), the traffic is relatively small. The infected computer users wouldn’t notice a thing, and really, neither would the website owner. In some cases, the bandwidth could become expensive, but so far it seems that this “attack” just messes up your traffic data.
Why?
Why would someone flood this website with fake traffic?
… why would someone flood any website with fake traffic?
It’s possible that someone bought this dodgy traffic to damage the website’s reputation, or to cause pain for their marketing team. There are numerous ways to use hackers-for-hire in order to attack competitors. If you look on Fiverr, there are tons of people selling “real visitor traffic” – maybe the real visitors are infected users who don’t know what they’re doing?
It could also be a bored script kiddie with a small botnet and a thirst for trolling. All it takes is a pre-made script and a few commands to launch a network of infected machines against a target website. We see automated attacks participating in click fraud on pay-per-click advertisements, and more disruptive bandwidth usage in the form of a DDoS attacks.
There’s always money in botnets. This is why it’s so important that we all take the time to understand cybersecurity – our websites and computers are merely file storage and bandwidth for hackers to use if we let them.
I open up the floor to the readers, because this is as far as our investigation goes for now. Have you seen anything like this in your logs?
Luke Leal
Caleb Lane
Denis Sinegubko
Ben Martin
Pilar Garcia
Juliana Lewis
Alycia Mitchell
7 comments
I appreciate the information and understand the downsides of allowing this to continue. What’s the fix? How do I block these kinds of hits on my websites?
Great question!
The temporary IP ban after the chunk of requests is the only thing suspect. The requests look innocent. There are all kinds of fake traffic generators, this one just happens to likely be real, infected computer users.
I found one experience in my research with a similar fix suggested: https://isc.sans.edu/forums/Botnet+quotattackingquot+our+site+but+I+cant+figure+out+why/709/
I can’t think of a way (in Google Analytics) to segment out the IP addresses, and it’s no using a View with a filter after the data is already collected.
I’m frustrated by this too. There are a lot of complaints surfacing about the lack of security in analytics when it comes to malicious referrers and fake traffic. I can only guess that this is either hackers who are angry at big data or script kiddies testing out their hacking powers.
I’m hoping this post will stimulate some discussion around this issue.
I’ve seen a similar issue on some of our sites. Several of our sites went from little to no traffic daily to a consistent ~500 visits per day all from the same IP address. I haven’t taken any action up to this point but I’m looking at just straight up blocking traffic from those IP addresses via htaccess.
If it’s all the same IP address/range, you can definitely do that. Best of luck 🙂
I see floods of traffic come with funwebproducts user agent at irregular intervals. They are all blocked as there is never a header accept. They come for a day or two at most then disappear/dissipate for a couple weeks to a month.
As for the why – never been able to figure out why the flood of traffic happens. There doesn’t seem to be anything malicious attached to the traffic.
We are facing this issue as well.
The BIG question is, what is the solution for that?
We’ve been seeing this type of traffic since about September, to 24 of our sites (we’re an agency, so we manage lots). All relatively small local business sites, from all over the country, so I can’t figure out why they’d be targeted. All traffic is to the home page, and comes from 15 user agents–11 of which only hit these 24 sites, for tens of thousands of hits a month per site. FunWebProducts accounts for 5 of them (as well as lots of other more generic traffic to our sites that look like legitimate, if infected, users). They’re all old browsers & operating systems, including the iPad one. They present quite the conundrum, because for 3 or 4 of the user agents, there is still enough legitimate looking traffic to make it risky to block them globally (one is the most common user agent for IE9, I think) but it’s worth it to filter a small amount legit traffic for those 24 sites, to get rid of the flood of bad. We can filter them from individual traffic reports fairly easily, but do a lot of reporting at the global level, as well.
Comments are closed.