A few weeks ago we wrote about compromised websites being used to attack your web routers at home by changing DNS settings. In that scenario the attackers embedded iFrames to do the heavy lifting, the short fall with this method is they require a website to inject the iFrame. As is often the case, tactics change, and while home routers still seem to be of interest, the latest tactic seems to take the conquer one, conquer all idiom very seriously by targeting ad networks in a concept known as malvertising.
Malvertisements or malvertising are a malicious variety of online advertisements generally used to spread malware. – Kaspersky
This definition is a bit dated, but you get the point. It’s the act of an attacker making use of of what could be a good or bad advertisement on a website, they key these days is the exploitation of what are known as ad servers. Where website integrate a third party ad service to show appropriate ads based on the users visiting and the information the ad network has on the user. It’s a much more complex scenario, but hopefully you get the point.
In this scenario, the attacker is leveraging an ad, part of a large ad network, and embedding their router focused payload within the body of the ad. The ad was being hosted on googlesyndication.com network.
What to Look For
We were notified of suspicious activity by a attentive client that noticed several log in boxes opening while browsing his own website. If you recall, this was the same behavior that led us to the original discovery. He identified malicious ad, hattip for that kind sir, and sent us the link. This naturally gave us what we needed to start analyzing what it was doing.
I was able to capture the URLs it accessed:
The malicious code was heavily encoded and injected in the ad body. This is what the raw payload looked like:
After sanitizing the code I was able to catch the decoding function that will translate all the noise.
Decoding the malicious content, I went through 2,716 blank characters before I found something malicious. It’s hard to tell if this was intentional to evade detection, but the code is there, and it is trying to change your home routers DNS settings and force a reboot.
This time they issue a command to remotely reboot it to make sure the DNS cache is flushed and the malicious site is loaded.
The second improvement is a counter. Unfortunately, during testing http://www.artevegan.com.br/tpl/conteudo/contador/contador.php was disabled.
It appears to be configuring a server in LA as an DNS server, which seems to be working fine; during our tests it didn’t return any malicious addresses. All resolved IP addresses were correct, which means it’s probably waiting for the go-live.
The second DNS server set is Google’s, which means they probably had only one compromised server this time. We’ll continue to update as more information becomes available.