Trojan Zoo @EHugin

• VMWare pictures

Zoo Tech

So, how am I doing this research? What is this VMWare thingy? How did I figure out which registry entries were added by a particular trojan? Here I'll attempt to explain how I'm getting my information.

The VMWare virtual machine

VMWare is a software package for running one or more virtual machines, using the underlying hardware of a physical machine. VMWare fools a program into thinking that it's running on a real machine, to such a fine degree that even entire operating systems can run under VMWare.

That probably doesn't quite clear things up though, does it. This is almost certainly a case of "a picture is worth a thousand words", and rather than writing all that text, I've made some screen captures of a VMWare machine booting up and running Windows 98. Take a look at the VMWare pictures page. Keep in mind that each of the screens you see is from the VMWare program running on a Linux machine. Even the BIOS setting screens, and Windows itself, are all taking place within a VMWare virtual system running on a Linux machine.

Since the virtual machine is just another program running on the Linux system, I can continue to do other work while the virtual machine boots and runs. In effect, I have a complete Win98 machine sitting in its own window on my desktop, running in parallel with Linux.

Finding trojan modifications

As you may recall from the main Trojan Zoo page, one of the virtual machines is named BALDR. BALDR has the unenviable job of being infected with the server portion of the trojan. Think of BALDR as a laboratory rat.

Now, prior to doing anything nasty to BALDR, I went through and saved copies of all the likely files that a trojan might modify to ensure that the server is run each time the machine boots. These include CONFIG.SYS, AUTOEXEC.BAT, and all the various .INI files in the WINDOWS directory. In addition, I ran the RegEdit program and exported the registry settings. These files form a baseline of what a clean, uninfected Win98 machine should look like.

Next, I bring a copy of the trojan server over to BALDR and run it. This lets the trojan server make its modifications.

Now, I save fresh copies of all the same files, storing them in a separate location from the baseline copies. It's then a relatively easy task to compare the copies from the infected BALDR with those from the original, clean BALDR. (For most of the files, a simple "diff" command is sufficient. Since the registry is such a large and complex file, I use emacs' buffer diff function to search for modifications.)

Verifying alterations in the CONFIG.SYS, AUTOEXEC.BAT, and .INI files is very straightforward. Since nothing has been added to BALDR except for the trojan server, any differences in these files are changes made by the trojan server.

In the case of the registry, however, Windows itself makes several modifications with each boot. Here I frankly have to make a judgement call as to whether a modification is due to Windows making legitimate changes, and the trojan server making its own little modifications. Generally this is pretty straightforward though. Seeing keys like "last program run" changing is obviously a Windows change. But seeing a whole new key hierarchy being added, or seeing new keys inserted in the RunServices folder are pretty darned good indications that something other than Windows is mucking around with things. These keys are where I concentrate my attention.

Determining scan signatures

In addition to poor little BALDR, there's a second virtual machine named LOKI. LOKI is luckier, and gets to run the trojan's client program, just like the script kiddies do.

To determine scan signatures, I boot up BALDR after having infected it with the trojan server. I then boot up LOKI, and start the trojan client. On the actual, physical machine running both of these virtual machines I run tcpdump, a handy Unix utility for watching network traffic.

Now I go to LOKI and tell the client to start scanning the virtual network. By watching the network traffic on the tcpdump output, I can see which connections the client is trying to make, particularly which source ports are being used by LOKI's client, and which destination ports this client is trying to reach.

From this information, I can determine if the client always uses a fixed source port, and whether it tries a single destination port or a series of ports. And from that, I can write up the scan signature. Pretty easy!