Friday, 16 January 2009

More PCs being used where they shouldn't

This sort of thing is now far too common. The above shot (click on it to enlarge) was taken at a railway station, and the display is supposed to show details of the next train. Instead it hung at the BIOS info screen, and I'm guessing the operating system (Windows?) failed to boot up.

Why, apart from laziness, would you plump for a PC to run this display?

Sunday, 4 January 2009

Virtumonde - Getting rid of a persistent trojan

In one of my worst Sundays for a long time, I spent most of today trying to prise the persistent trojan 'Virtumonde' a.k.a. 'Vundo' out of my Windows laptop.

The trojan has tens of thousands of variants, and only the more common ones are caught by virus scanners. I was unfortunate to get one of the rarer ones, which managed to elude even Kaspersky Anti-Virus 2009 (one of the best). Although Kaspersky recognised and blocked attempts to download dodgy files from the net, it didn't recognise the trojan that was behind the attempts. When I discovered the trojan's location using Spybot Search & Destroy, I tried pointing Kaspersky straight at the dodgy file, and it still passed it clean. And yes, this was with today's virus definition updates.

That said, if Kaspersky wasn't pro-active in scanning
the contents of internet traffic, I wouldn't have even realised I had the trojan, and probably would have continued thinking the slowness was just because my laptop was old. Other scanners would have missed this completely.

To make my Sunday as bad as possible, the trojan had hooked itself deep into Windows. In addition to the usual load-at-startup stuff, it had made itself a Windows service (which didn't appear in the Services list) and become memory-resident. When I deleted the hooks it had placed in the Windows Registry, identified by the tools Spybot and HijackThis, they would appear back within seconds.

The files I deleted kept re-appearing with new (randomly generated) names. I ran the Spybot and HijackThis tools a few times to try and weed it out, but it persisted. It was no use making Spybot start before the rest of Windows, because the trojan would load even before that. Therefore I couldn't delete it's main DLL file (also randomly named) because it was always in use, even when I booted in safe mode.

I tried using KillBox, which can move/delete in-use files, but the DLL file stubbornly stayed put. KillBox queued the file for deletion at Windows boot-up, but this instruction was immediately removed by the trojan process! In desperation I downloaded OTMoveIt3 by OldTimer, which also attempts to move in-use files, but without the nice interface (see image below with example syntax). Somehow it managed what Killbox couldn't, and move the file to safe location where I could delete it.


The trojan was still resident in memory though, and was still replacing it's registry hooks soon after I deleted them - but this time the hooks were pointing to the now non-existent DLL file. A restart took the trojan out of the memory, which enabled me to delete it's hooks in the Registry once and for all - a good half-day after identifying the problem.

At least it didn't attempt to spread to other PCs or delete files - which is some consolation, as re-installing everything would have taken days.

It's experiences like these that make me think of switching to a *nix platform, like Linux or Mac OS X.

Mac users have been relatively lucky - vulnerabilities clearly exist but it's nowhere near the same numbers or nastiness as it is with Windows. That said, there's a lot of unprotected Macs out there, and malware writers will look to target this population as Mac usage increases.

Most Mac users seem to only use a single user account - the one they created when they first switched on their Mac. The problem with this user account is that it's an administrator account - which makes things much easier for malware writers, as it enables them to do more damage without user intervention. If this applies to you, create a standard user profile and switch to it. As with all *nix platforms, an administrator account should only be used when strictly necessary (such as when installing new programmes, or fiddling with hardware or with system settings).