Trojans. Not Stupid.
I got held up recently by a particularly nasty Trojan infection that seemed to come from a flash vulnerability – or at least it installed itself in a Macromedia directory at a time when embedded flash would have been running on one of the web pages I had open.
No ordinary decent virus this one though. It cleverly disabled my default browser – Chrome – coercing me into a specific set of steps that would ultimately place a rootkit on my OS. As my browser seemingly inexplicably was rendered useless, even after multiple uninstall/reinstalls, something else was up. Internet Explorer was attempting to connect to a “tolule.net” which on lookup resolved to a Chinese IP. So a quick entry into my Sygate advanced rules and I had a large swathe of Chinese IPs blocked. So I was safe for the time being giving me a chance to think about what was going on. (The Trojan was quite busy – attempting to connect every 10 mins or so and to multiple domains – initially always tolule.net but also gusmon.net and somemon.net – each time resolving to an address in China).
I ran a full AVG scan and two files were suspect – both resident in System Volume Information – the area where System Restore settings reside. Delete wouldn’t work (looking into it further if system restore is turned on these files cannot be manipulated) so I went for seemingly the next best option – system restore to a point before Chrome stopped working. Looking back this was a stupid thing to do but at the time seemed logical enough. A thought process that no doubt the hackers had already wargamed out in their heads prior to deployment. User sees app not working, reinstall doesn’t work, anti-virus identifies but can’t clear the Trojan, proceeds to system restore hence running the virus the hackers managed to plant somehow in Sys Vol Info.
Needless to say, the system restore failed, but now a plethora of hacked files had now successfully and relatively silently installed themselves on my OS. The rig included their own embedded db instance of Sql Anywhere, the a.exe worm that amongst other things engages in Process Hijacking described above, a bunch of reg keys that pointed device drivers and startup configs to the original hacked Macromedia directory, a hidden rootkit type process that ensured these keys and the directory were not tampered with and the actual downloader Trojan itself, W32/Agent.GBS!tr.dldr.
The process hijacking was something else. It would wait until I’d start an application and use the app’s virtual memory for it’s own devices. Hence why I was getting the Sygate reports of IE getting a life of it’s own. Wasn’t just browsers that were vulnerable, even MalwareBytes Anti-Malware software’s memory was hijacked. Each time the stolen app tried unsuccessfully to phone home to China.
By now it was obvious to me I had been infected with a particularly nasty virus and ran AVG a 2nd time. But now the Trojan was so well embedded AVG didn’t pick up anything more than a few measly HTTP cookies. I did wonder about Sygate at this stage but it still seemed to be successfully blocking all malicious packets so I was still just interested in removal. Spybot Search and Destroy was my next bet but it returned nothing. What’s more that TeaTimer process monitor it installs is a real resource hog – 128meg of virtual memory. That’s a bit more than a mere heartbeat in my book. Especially on my netbook! Got rid of that then was pointed to the MalwareBytes app by Matt @ BleepingComputer.com. The hackers obviously see it as a threat – after I installed it I tried to update it’s malware db but was prevented from doing so, presumably by the a.exe worm. It instead forced MBAM to attempt another connection to tolule.net. Proceeded with the scan anyway. Result? Every malicious file was identified.
Although still not out of the woods – MBAM would freeze when attempting to quarantine the audio driver reg keys whose values had been changed from wdmaud.drv to a dll file in the fake Macromedia directory. After I deleted a.exe and ran MBAM again, this time it succeeded in changing the reg keys after a restart. I had tried manual deletion of the reg keys and fake Macromedia directory prior to this but as soon as I closed regedit the keys and files would reappear. MBAM must have required the restart to remove whatever in-memory process had been running to protect the hacked data.
So that’s pretty much it. Quite an organised payload that, and a very well thought out attack vector relying on unwitting end user participation as much as the original web vulnerability.