A malware analysis sandset is an environment created to allow relatively safe analysis of malicious software samples, which are generally obtained either via a honeynet, or perhaps by reading all the spam one gets and following all the links 😉
I’ve been running one for over a year, and figured it was about time to document how I have it set up.
Hosts
Currently there are 2 hosts in the sandnet:
- viktim: A Windows XP SP2 host which is deliberately infected for the purposes of analysis
- snservices: A Debian Linux host which serves wildcard DNS, as well as running Apache, and providing various other services used to analyze the malware.
viktim
viktim is running XP SP2 (no patches other than the SP) and has 2 hard drives in it.
After installing Windows, I disabled the second hard drive so that the OS doesn’t see it. Then I booted up a live Linux distro and used dd to copy the OS drive to the backup one.
The advantage to this is that I can install whatever malware is desired and then simply dd from the backup drive over the infected one to get things back to a clean state.
Note: It takes about 15 minutes to do the dd (they’re 9gb drives).
snservices
snservices is running Debian Linux for an OS, and has been configured with a number of tools, including:
- BIND
- Apache
- NMAP
- Paketto
- ettercap
- SpiderMonkey
Architecture
The regular network is protected from the sandnet via a firewall device. I’ve configured the firewall to log all traffic (logfiles are sent to a remote host via syslog for analysis).
BIND Configuration
BIND has been configured such that it is the SOA for every domain request that it receives, and replies to any requests with the IP address of the snservices host.
viktim has been configured to use snservices as its only DNS server. This allows any DNS calls being made by the viktim host to be observed, and any software that tries to communicate with the internet ends up talking to the snservices box instead.
/etc/bind/named.conf
the default zones for localhost and such have been snipped from the text below
include "/etc/bind/named.conf.options";
key "dnskey" {
algorithm hmac-md5;
secret "hash";
};
controls {
inet * allow { 127.0.0.1; } keys { "dnskey"; };
};
zone "." IN {
type master;
file "/etc/bind/db.wildcard";
};
/etc/bind/db.wildcard
$TTL 60M
@ IN SOA localhost. root.localhost (
2008022002 ; serial
604800 ; refresh
86400 ; retry
2419200 ; expire
604800) ; negative cache ttl
;
IN NS localhost.
* IN A 192.168.1.3
/etc/bind/named.conf.options
options {
directory "/var/cache/bind";
allow-transfer { none; };
// logging {
// channel query_log {
// severity info;
// print-time yes;
// file "query.log" versions 5 size 50M;
// };
// category queries {
// query_log;
// }
// }
listen-on-v6 { any; };
};
Analysis
JavaScript De-Obfuscation
For de-obfuscating javascript downloader code there are a couple different methods which can be used. Info on this can be found at this SANS diary entry.
The SpiderMonkey method described there is fairly simple and generally works well. For this reason, SpiderMonkey has been installed and9 configured on the snservices host.
Monitoring and Logging
On snservices
For analyzing network communication from the viktim host, iptables logging can be used. Apache logs can be used to view HTTP requests. Additionally, a netcat listener can be established on whatever port the malware on viktim is attempting to connect to so the conversation can be monitored and/or logged.
On viktim
For analyzing the binaries and behaviors that occur upon infecting the Windows host, a combination of the following is typically used:
- strings
- wget
- Wireshark
- PEBrowse Pro
- Immunity Debugger
- SysAnalyzer
- iDefense MAP
- netstat
- ipconfig
Virtual Machine Environment
For a quick analysis of things that don’t appear to require such a complicated setup, a virtual environment can be used.
VM Software
For the purposes of evading detection, the Innotek VirtualBox software was chosen. Most malware at the time of this writing does not check for this particular VM software when determining whether it is being run inside a virtual host (whereas a number of them do check for VMWare). VirtualBox also consumes less resources on the Host OS than VMWare. Both VMWare and Virtualbox are freely downloadable.
Guest OS
A Windows XP SP2 ( again, unpatched except for the SP ) image is run inside the VirtualBox Host.
Tools
The tools used in this environment are largely the same as those on the viktim host described above. Due to the fact that the snservices host is not available to the virtual machine however, some functionality is lost.
This is made up for somewhat by the functions provided by the SysAnalyzer tool and the iDefense MAP suite, however, these are not as robust as the tools available via the snservices host.
—-
And there you have it. Maybe not the best sandnet ever made, but I find it fairly sufficient, and flexible enough to do what I need it to do and be easily maintained.
[update 2010-03-02]
I turned this into a talk and presented it at BlackHat DC 2010!
