As we move into the Malware Analysis process, it’s time to set up a testbed because you need somewhere to play. Here is our description from the process map:
Build Testbed: It’s rarely a good idea to analyze malware on production devices connected to production networks. So your first step is to build a testbed to analyze what you found. This tends to be a one-time act, but you’ll always be adding to the testbed based on the evolution of your attack surface.
This is mainly done once, but keeping your environment and tools current require some ongoing effort. We’ll discuss that when we model out the metrics in the second phase of this Quant research. But for now let’s just say a bit about the environment you should strive to build.
Of course we need to mention caveats for our shopping list. Some of you will not need all of this stuff, while others will need more. There is no one size fits all test environment, but there are some guidelines and general tool categories you’ll need.
- Isolated test network: Don’t want to test live malware on production networks, so you’ll need to build a separate network to host your testbed.
- Victim devices: You’ll want to provide victim machines in a variety of configuration states (patched, not patched, etc.) and a variety of operating systems from your environment. You’ll want to rely heavily on virtualization snapshots and re-imaging tools to wipe and rebuild the victims quickly. Given that many malware writers check whether their malware is running in a virtual machine, you will need some physical machines (how 2005!) as well to test on.
- Network services: Given our preference for total isolation, you probably want to provide a totally separate Internet connection (it doesn’t have to be fast). At minimum you need DNS and outbound Internet connectivity. You could simulate these services on a closed network, but based on our research, providing direct Internet connectivity is preferred – and of course be sure there is no way a compromised machine in the testbed can jump to the production network.
- Testing tools: There are many things you can buy and a lot of open source and shareware. Lab tools come down to personal preference so you will likely need to try a bunch of stuff before you find a set of tools that work for you.
- Imaging tools: Before you start investigating you need a clean image for forensics and possibly prosecution purposes.
- File/data analysis: You’ll want some tools for static analysis of potential malware files – including things like disassemblers, decompilers, and source code analyzers. Be sure the tools can provide a timeline of which files are moved, added, and changed, as that’s key to understanding what the malware does.
- Registry/configuration analysis: Since most malware targets Windows (which means pretty much all malware) messes with the registry and other configuration variables, having a tool to do quick diffs against last-known good or gold master settings can save a lot of time.
- Sandbox: You can do dynamic analysis manually but it’s not for the feint of heart, and it may not make sense when there are both self-contained sandbox appliances and services that can help analyze executables. I’m using this generic term to also include memory analyzers and the like, which allow you to build your own sandbox.
- Log analyzers: Devices under attack generate log files recording the activities of the malware, so you need some kind of log aggregator and parser to wade through what could be thousands of log records.
- Network capture: You’ll also need to understand how the malware leverages the network, so you need to capture the traffic to isolate command and control traffic, possible exfiltration paths, and encryption mechanisms.
Of course not everyone needs all these tools, but this should be a reasonably comprehensive list of things you might need to get your testbed up and running. Now that we have the testbed in place we can start to analyze bad stuff. In the next post we’ll start looking at the steps in static and dynamic analysis of malware files.
- Mike Rothman (0) Comments