Saturday, July 16, 2011

6 - Malware Lab Setup

I'd started off learning Reversing last year and touched on the basics of reversing in a Unix environment; we also analyzed a few basic C programs in gdb to understand patterns in Assembly language and how common patterns of code looked inside a debugger. If you've read all of those tutorials you would understand a little of what I was trying to communicate. If you need a little more brushing up of your Assembly syntax, I strongly advise you spend a day or so looking at Vivek Ramachandran's fantastic Assembly language videos on securitytube.net. There are 11 parts to it; very lucidly explained - do take your time and study all of them.

I've been spending a lot of time trying to understand how malware works over the last 2 months or so. I have stuck to Windows this time because a large majority of malware runs only on Windows systems. I started off learning Dynamic Malware Analysis and have over the last month or so dived into Static Analysis. I hope to explain all my learnings to you in this series of blogs over the next few days. Lets start :)

In my first post on Reverse Engineering last year I briefly touched on the types of Analysis. There is a great presentation by Lenny Zeltser there; if you've seen it you will know that its extremely important to set up a lab if you're serious about Malware Analysis. This "lab" can be as small as 2 physical machines or 1 physical machine with a VM running on it. Since a vast majority of the people reading this will be people with a single laptop or desktop in their possession, I will stick to a simple setup with a single physical machine and multiple Virtual Machines (as needed) on it, so you can hit the ground running :)

My lab configuration is as follows:

Ubuntu 10.04 Host [500G HDD, 4GB RAM, Intel i3 processor]
Virtual Machine 1 -WinXP with Malware tools [Not updated]
Virtual Machine 2 - Ubunutu 10.04 Malware controller [Not updated]

Effectively as long as you have a reasonably powerful host machine which can run multiple VMs at the same time, you should be okay.

The WinXP machine is the one on which I will load and run all my malware samples to understand their behavior. The controller is the machine that all the analysis data is transferred to, after the malware has run. You don't need the controller VM at times; you can just store reports on the host. I just chose to keep it as a VM because the entire setup is more easily transferrable if so needed, at a later date to another machine.

Once this high level setup was decided; these were the guidelines I followed while setting up the host as well as the VMs.

1)Latest version of VirtualBox downloaded and installed
2)Configure the firewall [iptables] on your host to drop incoming packets from the Malware infected machines
--- Drop all from victim
--- Accept all INPUT stateful connections [This is for the OUTPUT chain]
--- Allow Outbound SSH to Malware controller
--- Allow HTTP,HTTPS and outbound DNS access
--- Drop everything else on all chains
3)Use a host-only networking configuration. [NOTE: Vboxnet0 is used for communication between the host and the VM; not eth0]
4)Disable shared folders between the host and target or make them read-only
5)Prevent the target from accessing any shared devices or removable media, such as USB drives that may be physically connected to your host
6)Do not customize your target system with any sensitive information
7)Default route added on victim machine to route all traffic to the controller; sniffing working
8)Configure Iptables on the controller.
--- Allow inbound SSH from Host
--- Allow all INPUT traffic from Malware Client 1
--- Allow all stateful OUTPUT traffic
--- Drop all other traffic across all chains

At the end of this you should effectively have a Host machine with 2 Vms set up and all 3 talking between each other as expected. A tip I will give is to leave the Firewall configurations for the very end, after you are sure the machines can talk properly to each other.

The aim in the end is to ensure that traffic from your malware machine doesn't leak out on to the Internet unless you know exactly what you're doing. Do whatever you need to do to secure it as much as you can. In the next blog we will take a look at what tools need to be installed at minimum; on the various machines.

No comments: