Let's first turn our attention to building a malware analysis laboratory of niyour very own. People frequently ask me about the equipment they need to do malware analysis at home or in the office. As you download and test various defensive and offensive programs , you'll need a solid environment to conduct these freakish experiments on your own. Beyond mere freelance experimentation, you might encounter various malware specimens in use against your own production systems in the wild. Using the laboratory structure we'll describe in this section, you'll be able to poke and prod the malicious software you discover so that you can get a deeper understanding of how the malware specimens work and the damage they might have caused. With a good malware analysis lab, you'll be ready when nasty software comes calling.

Caveats: Using Nonproduction Systems and Staying off of the Internet

First, make sure you construct your lab using extra computers that you don't rely on for production purposes. If you are like me, you'll be installing some pretty noxious malware on these boxes, so you'll need to air gap them off of your production network. These machines shouldn't ever be connected to your real network or the Internet until all software on them is completely destroyed with a thorough reformatting of the hard drive. Also, don't even think about storing any sensitive data on these systems, as some malware types could steal this data or corrupt it thoroughly. These boxes should be a malware analysis lab and playground only. Any use of these boxes in a production environment could only cause vast amounts of trouble. Never, ever connect these machines to the Internet. You've been warned!

Additionally, you'll want to have your lab ready to roll at a moment's notice, in the event of an emergency such as a fast-spreading worm that requires quick analysis. You don't want to have to scrounge around in real time during such a crisis for current production boxes to use in your lab. Instead, allocate the appropriate systems and build the lab in advance so you can conduct analysis on the fly.

Overall Lab Architecture

With those caveats out of the way, the good news is that you can build a malware analysis laboratory at quite a low cost. You don't need the latest gee-whiz hardware for your lab. A speedy processor and gobs of RAM are nice to have, but aren't required. Instead, old surplus equipment from your company or a handy Internet auction will suffice. The goal here is merely to obtain machines that will hold the operating systems, a select few applications, and the malware to be analyzed. Such limited requirements can be easily filled without plush computer systems.

For my malware analysis laboratory architecture, I use four systems connected together. I recommend that you build your lab from machines with at least a 350 MHz processor, 64 MB of RAM, and a 5 GB hard drive. Each system will need a network card, of course, but a simple 10-Mbps Ethernet will suffice. By today's standards, these vintage-1997 boxes should be plentiful and cheap. Again, if you can do better than this baseline, you'll have a spiffier lab, but don't devastate your budget in getting these systems. I just zoomed over to my favorite on-line auction site, and saw that desktop systems with this hardware profile are available for less than U.S. $250.00 each. Laptops of this nature can be snagged for around U.S. $400.00 each.

Now, let's move on to the operating system hardware and service mix. As you can see, my lab contains a Windows 2000 system running Microsoft's IIS Web server. Many corporations rely on Windows 2000, and IIS servers are a favorite malware target. Therefore, I can use this system to evaluate the numerous worms and RootKits designed for Windows machines. Of course, Windows 2000 is a commercial operating system, so you'll need a legitimate license, which just might have been included in your purchase of the hardware itself.

My next system is a Linux machine, running an FTP server and the Apache Web server. Just as with Windows and IIS, many malware specimens specifically target vulnerable FTP and Apache installations, so I want to be ready to analyze them. My third system is a Windows XP box, configured to share files using the built-in Windows file sharing mechanisms. Because Windows XP is a common desktop environment for both home and corporate users, I can test malware that targets these popular user environments. Finally, for variety, I've included a machine with the OpenBSD operating system. OpenBSD is getting increased attention due to its significant built-in security features. I test these features by running a Network File System (NFS) server on this box.

On each of the systems in my lab, I've installed a variety of antivirus tools that can help identify various well-known malware examples as they are loaded onto the system. Furthermore, I install file integrity checking software on each machine to monitor critical files and system settings in the event that malware under analysis tries to make changes. While I analyze the evil critters, I might disable the antivirus and file integrity checking tools temporarily to get more insight, letting my foot off of the software brakes. However, my default stance is to leave these defensive tools in operation, to control any contamination within my lab until I decide to let the malware run loose.

I connect all of these boxes together using a cheap hub or switch. I actually prefer using a hub for my lab, because hubs replicate packets to all systems connected to the LAN. That way, I can run a sniffer on any of my lab-connected machines, and see the packets sent by any other system on the laboratory LAN. If I use a switch, I'll need to configure a span port, which is a single connection on the switch that receives all data from the LAN. Some of the cheaper switches don't even have an option for span ports. Therefore, your best bet for networking your malware analysis laboratory is the lowly hub. I've configured the networking of each of my lab boxes so that they are all on the same LAN, using an unregistered swath of IP addresses in the 10.x.y.z network range. I use 10.10.10.z in particular, simply because it's easy to type. I also use a netmask of 255.255.255.0, which would allow me up to 254 different machines on this network. Now, I have a lot of computers in my lab, but I haven't yet run out of addresses.

It should be noted that flexibility and pragmatism are helpful characteristics of your lab. If a brand new malware specimen is released that runs against a target environment I don't have already built, I'll rapidly modify my laboratory to support the new type of target. For example, if someone releases an attack against an Apache Web server running on Windows, instead of my default IIS server, I'll simply install Apache on one of my Windows machines to test the new pathogen. By creating a default baseline lab infrastructure that can be easily adapted to other environments, I'm ready to start analyzing nearly anything the bad guys unleash.

Also, please don't feel that you have to emulate this sample lab in exact detail. Feel free to vary it to suit your own environment and analysis techniques. If your employer uses a large number of Solaris machines, throw an old Sparc system into the mix, such as a cheap Sparc 5 system (less than U.S. $100.00 at an Internet auction house near you). If you want to check out HP-UX, get an old HP box and include it in the lab. Don't use my lab specifications as a leash to limit your lab; use my specs as a starting point for your own exploration and customization.

Finally, keep in mind that you don't have to implement this lab in all its glory. Don't worry if you can't afford several computers; you'll still be able to analyze malware. If you don't have the funds, you could create a junior version of this lab with just a single computer. Build a dual-boot Windows and Linux machine, installing both operating systems on a single box so you can switch between the two with a simple reboot. That way, you'll be able to analyze malware on at least one system. You could even strip your lab down further. If you want to just focus on Windows malware analysis, you could also configure just a single Windows machine, having it ready to do your analysis.

Virtualizing Everything

The lab architecture we've discussed so far focuses on buying four separate machines and a hub, but an even niftier implementation involves using a virtual environment to run different operating systems simultaneously on a single hardware box. Implementing virtual systems allows me to install a host operating system on a single desktop or laptop computer, and then run several guest operating systems on top of it. The host is just a normal operating system, running on my hardware. The guest operating systems, however, are simply programs that run on top of my host operating system. These guests are true operating systems running simultaneously on the host, in that they can run programs themselves and communicate across a virtual network connecting all of these virtual systems together. Each guest operating system is implemented through an emulation program running on the host, and consists of a few files within the host. The guest systems don't even realize that they're not real! They think they are separate systems running on their own hardware, but they are really just sharing one processor. Using this approach, I build three or more different virtual systems and run them at the same time on a single computer.

Using a virtual environment for malware analysis isn't a new idea. Indeed, researchers at IBM performed some very forward-looking work on malware analysis using a virtual machine environment back in 2000. I use similar concepts in my own lab.

A variety of programs are available that let you turn a single machine into a host holding several different operating systems. Commercial tools like VMWare (available at www.vmware.com), Virtual PC (available at www.connectix.com), and others emulate an x86 processor in software so you can install and run virtual computers on top of a single set of hardware. There are even freeware tools that do this, such as the Plex86 Virtual Machine Project, at http://plex86.sourceforge.net, and the Bochs project at http://bochs.sourceforge.net. Furthermore, if you want Linux only, the UML project can run multiple, independent Linux kernels inside of Linux processes on a single Linux machine. UML is available for free at http://user-mode-linux.sourceforge.net.

The beauty of this virtual implementation is that I can carry my entire malware analysis lab with me on a single laptop, and test malicious software on the road. Furthermore, most of these virtual system tools allow you to roll back any changes to a virtual machine without rebuilding a system, immediately restoring a guest operating system to its original configuration. If some malware royally messes up one of my virtual machines, I'll just instantly set it back to the original state. Therefore, I can safely watch the malware's impact on my (purely virtual) network, keeping my sanity while working with some very nasty and buggy attacker code. This revert feature is immensely useful. I can even freeze guest operating systems in their tracks, suspending all action while I analyze what the nasty software is doing.

Of course, to run all of these virtual machines at the same time, the host computer hardware must be beefier than the relatively scrawny systems described in the last section. Indeed, with enough RAM and CPU horsepower, you can virtualize nearly anything. If you intend on running a virtual malware analysis laboratory, I recommend at least a 2 GHz processor, with at least 64 MB of RAM for each guest operating system you intend on running. Therefore, if you want to run a single host operating system and three guests, you should have 256 MB or more of RAM. For comfort's sake, you might want to go ahead and double that RAM figure to 512 MB so your systems can run at a more reasonable pace. With virtual operating systems, memory is the oxygen that keeps the machine breathing.

For my own portable virtual lab, I use the VMWare product. It's a commercial tool, but I've found it to be more stable and flexible than some of the free virtual system offerings. 've set up VMware on my Windows 2000 host operating system to hold a bunch of different guest operating systems, including Windows XP, various incarnations of Red Hat Linux, FreeBSD, and Windows 2000 Server. I can run any or all of these guest operating systems at the same time, or suspend them for future analysis. A virtual environment isn't required for implementing a malware analysis laboratory, but it can certainly make the analysis process a lot easier and more portable!