At this new site (actually, close to a year old now), you will find a detailed wiki with installation and configuration instructions, a Subversion-based source code repository, and a trouble ticketing system. Oh yeah, and there's a mini-blog section on the front page as well. Enjoy and let us know if there's something else you'd like to see.

The email honeyclient package can be downloaded here.

So, how did this happen? Well, there's a site called Allakhazam, which WoW players can reference to see neat statistics such as the average price auction items sell for. Apparently, some bad guy bought an ad on Allakhazam, which when viewed with a vulnerable Internet Explorer browser, installs a keylogger on the IE host. The next time the player logs onto WoW, his/her account login and password are logged, and sent to the attacker. Now, the attacker can log into WoW as that player, and transfer game currency to other accounts, and do stuff like sell that game currency on Ebay for real money. Ouch!

Why am I interested in this? Because 1) I play WoW, and 2) honeyclient technology can help to detect sites like Allakhazam, where in this case, the user didn't even have to click on the ad to get infected. I'm not saying that this is Allakhazam's fault - they just sold an ad to a bad guy. But, if honeyclients were widely deployed, there's a good chance someone would have found this malicious ad before the infection rate become so high. Especially since the ad had already been up and running for several days, according to this Allakhazam post. By the way, Allakhazam has since then removed the malicious ad.

I think the important question is: what's to stop this from happening again? This is clearly a viable business model. These attackers will probably not get caught - how will they even be traced? I could sit here and tell you to download and install Firefox browser instead, but we all know that Firefox has its vulnerabilities too. So, those of us who are using Firefox are hoping that being part of a minority user group will protect us from being the low-hanging fruit that attackers look for first. But, the sad reality is that if those attackers should choose to, they can certainly target vulnerabilities in other browsers besides IE.

I'm starting to feel like a broken record player saying this, but we need to spend more time thinking about proactive detection technologies. The honeyclient is one of those technologies, and I'm glad to see other people have also thought about that besides me - I'm not the only one, or the first. However, we need to hit a critical mass of people who run honeyclients so that we have a chance of finding malicious sites and spreading the word about them before an infection epidemic like this happens.

Dan's slides can be downloaded here.

I had a great time at ToorCon, and will talk more in detail about that on my personal weblog soon.

If you are planning on attending ToorCon, or if you're in San Diego, please stop by and say 'hi'.

There will be new information presented at ToorCon, and I will put the slides up on the honeyclient site afterwards.

I read the paper and thought it was very interesting. 'HoneyMonkeys' is Microsoft's term for what I call 'Honeyclients'. Anyhow, the term doesn't matter much - it's essentially the same concept. Reading Microsoft's paper, it was good to see that the more patched versions of Windows XP were less susceptible to malicious sites.

I suspect that very few attackers are even aware of honeyclient technology at this point. It will be interesting to see what type of 'arms race' is coming down the pipeline as attackers become more aware of honeyclient technology. I'm envisioning more verification by the malicious sites of whether the client is driven in an automated fashion. How about active content malicious sites? It will be challenging to integrate automated mouse clicks within the honeyclient architecture, but is there any other way to detect these types of links?

Namely, the MSIE browser caching mechanism was giving me some problems. Even though I specified in the browser options that I never wanted to cache pages, and gave it the minimum memory space (1MB) for storing caches, it was still storing pages. This was indirectly causing error messages like 'Cannot open intfile: no such file or directory.' It also means that things were not going to proxy.pl, which was really the cause of the underlying intfile problem.

Thanks to JD Durick for pointing out the bug while testing, and thanks also to Jeff Nathan for taking the time to show me MSIE caching mechanics.

I am still in Montreal today, and will be returning home tomorrow. Today, I enjoyed sightseeing around the wonderful city of Montreal. The food here is pretty phenomenal.

Talking to the people at RECON was really cool. Everyone seemed to have something to say about honeyclients, and many people had good suggestions as to improving the current prototype. I also got a lot of people interested enough to do additional testing - this is the best reason of all to present at conferences.

Please join the mailing list and contribute! The slides I used at the RECON talk will be available for download within the next few days.

Basically, the first trojan (Win32.Glieder.AK) downloads malware from a hard-coded list of URLs, and disables various security measures such as the host firewall. The second trojan (Win32.Fantibag.A) ensures that anti-virus and Windows Update is disabled. The third trojan (Win32.Mitglieder.CT) actually puts the host under control of the attacker, who will presumably build large botnets with these hosts.

Although this is a complicated attack, it is clever. For one thing, it will make identification of the source of attacks more difficult. Also, according to Symantec's information on the first trojan in the three-staged attack, this trojan may be emailed out as part of a Beagle worm variant, so is this really a four-staged attack?

Whether honeyclients will be useful for studying this attack will depend on whether the first trojan is exploiting a vulnerability in the Windows server, or if it's exploiting a vulnerability in a client, such as IE. For the first case, honeypots would probably be more useful, for the latter, honeyclients.

This Russian company (which I will not link directly to) supplies one-line exploit code to other sites, who then get paid $0.06 per machine that is infected with that exploit code, which installs at least spyware and adware.

Interesting insight: I was testing my honeyclient implementation, and decided to access this Russian site to see if I could somehow download that exploit code to research. It turns out that the information they wanted from me is quite extensive. I mean, there's no way I'm giving them my address, phone number, etc., just so they can contact me to 'talk business'. So, in case you were wondering, they don't make it easy to obtain that exploit code.

It would be interesting to see with honeyclients if all the sites that work with this Russian company can be found via the way they would uniquely try and exploit IE and Windows 2K/XP. At least, that's what I'm assuming the exploit code targets.

More importantly, though, this goes to show that it's becoming increasingly important to actively seek out the bad HTTP servers proactively. This will help to develop a better sense of situational awareness, which is where I think the future of information security is headed. I think folks are finally getting sick of constant reactive problem-solving, and this includes Microsoft.

I say the attackers/typosquatters are extremely enterprising, and evil to do this. I wonder what their motives are? Surely, there's money being made on their end. It used to be that if you mistyped certain domains, you'd just get porn, but this is definitely another step up. And, IMHO, another reason why we need honeyclients to help with finding sites like this, and warning the public, before they get a chance to do much damage.

This server to client attack cannot be detected using traditional honeypots. Traditional honeypots are passive devices which do not actively hit sites for data. Honeyclients, however, can be deployed to detect and warn of such malicious servers, because honeyclients are designed to actively access those servers. If we hope to better detect new server to client 0-day attacks, we need to actively look for those servers.