Now that you have a working Malware Lab setup, the next step is for you to install a few tools which will enable you to monitor the behavior of malware that you run inside the WinXP unpatched machine. You effectively need to monitor does on the local machine [Files, registry, memory] and what it does on the network..i.e How does it try and communicate with the outside world?
This blog post will just illustrate the tools that I personally think are a good starting point. It is not by any means a list which includes every available tool. I will cover what needs to be on the victim system and what needs to be on the host and how to use these tools. The procedure can obviously be tweaked to include or remove anything you feel is not needed. Here we go :)
WinXP [Victim machine] - Autoruns, Regshot, Wireshark, Process Explorer, Process Monitor, CaptureBAT, Psftp
Ubuntu [Malware controller] - Tcpdump, Burp, Inetsim, Ssh[server]
Autoruns - Programs that run automatically on startup
Regshot - Tells you exactly what files and registry keys have changed
Wireshark - Saves network traffic to a file
Process Explorer - Details of what processes were started and stopped
Process Monitor - Details of each and every operation [very low level] done by every process
CaptureBat - Similar to ProcessMonitor but more high level. Also saves files that the malware deletes from the hard disk
Psftp - Sftp client to transfer all results to controller for archiving purposes
Tcpdump - Wireshark equivalent on Linux
Burp - HTTP/HTTPS proxy [You will need it if the malware communicates with other machines using these protocols]
Inetsim - Simulates a lot of services like Ftp, Dns, HTTP, IRC and many others. You may be able to analyze malware without allowing it to go out on to the Internet.
SSHd - SSH server to allow victim machine to connect to; to transfer data.
Yes, that is all you need to perform dynamic or behavioral analysis of malware. Its of course a work in progress. As and when there is a better tool available or something that needs to be added we can add the same at a later date. Now I divided the analysis into 2 parts - Malware which does not need to communicate with the Internet and malware which will not work unless it "calls home". I wrote 2 small procedures for handling both these cases; which I will share with you in the next article. Do get your lab setup and take a snapshot of your VM once all the tools are properly installed. Doing this is very important; as you'll have to reinstall all your tools again..each time you analyze a single piece of malware. That is not fun.. trust me :)
Until next time...goodbye.
Showing posts with label lab. Show all posts
Showing posts with label lab. Show all posts
Sunday, July 17, 2011
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.
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.
Subscribe to:
Posts (Atom)