If you want to evaluate Windows malware effectively you will need a system that is properly configured to do so. This article discusses building a system to detonate Windows malware in order to evaluate the behavior and artifacts that are created. This article will not cover the more advanced analysis or reverse engineering. If you want to take a deeper dive into advanced malware analysis, you can build a system first to learn malware discovery, then build on this configuration by adding additional tools for advanced analysis and reverse engineering.
Bare metal/ bare bones or virtual machine?
In classes I teach on ‘Malware Discovery and Basic Malware Analysis’ I use a particular malware sample in the labs that detects virtual machines and does not detonate on them. Symantec reported in their 2015 Information Security Threat Report (ISTR) that 28% of malware in 2014 was VM aware. In 2016 the Symantec ISTR stated 22% in Q4 of 2015. Knowing that, and experiencing this in my own analysis, detonating malware on a bare metal system just like a production system in your environment, is the best way to go; by far for basic malware analysis. Whether you agree or not, the same configuration covered in this article could or should be used for a VM that you want to evaluate malware on as well. If you want to tweak your VM to improve Anti-VM detection by the malware, it will just take more configuration not covered by this article.
Step One – The hardware and operating system
The first order of business is to build a system. Most hardware you have will work, an older PC with 16GB RAM or more and most importantly a Solid State Drive (SSD). Since malware analysis includes full filesystem hashing when evaluating malware, the faster the hard drive the better. A spindle drive can take up to an hour to hash 150,000 files (normal for Windows 10) whereas an SSD can do it in 15 minutes or less. Use a small SSD (256GB) and create two partitions so you have a C: and D: drive. You will install your operating system on the C: drive and place all your scripts and tools on the D: drive. You might choose to use a USB drive with a write-protect switch to store and launch your tools from to avoid getting them encrypted when you are doing a ransomware evaluation, for example. In the case of hard drives, bigger is not better for analysis. The smaller the disk drive the faster it is to duplicate or clone the drive.
Disk Duplicating or snapshots
In order to evaluate malware quickly, you will want to have multiple drives so you can re-image an infected drive from a master that you maintain. Use three drives so two analysts can evaluate malware and one you maintain a master image, etc. If you decide to use VMs then one drive will work since you will create a snapshot or a copy to infect and perform your analysis. Aleratec makes nice disk duplicators that will duplicate a 256GB drive in roughly 15 minutes.
Which operating system?
Malware will be crafted for both Windows 7 and Windows 10 32bit and 64bit systems. I would recommend using whatever OS is primarily being used in your environment. Building both a Windows 7 and Windows 10 master image provides more options as Windows 10 has many new audit log improvements as well as a new feature called SRUM that we will discuss in another article that can help identify malware behavior.
Additional basic software
You will need to install various applications that are normal for a system such as; Microsoft Office, an archive tool like 7Zip or WinZip, a file editor like NotePad++, and a PDF reader like Adobe or FoxIt so the system looks like a normal corporate system. You can also install whatever base apps your company includes in your base image, or use a copy of your base image to really reflect a real corporate system. Avoid installing any security tools like Wireshark as malware looks for these and will terminate if found. You can always install additional tools after you do your initial basic malware analysis. Place random misc. documents and open them to populate the ‘Recent Documents’ folder as malware is known not to detonate if the system does not appear to be used. Consider a few fake documents saved to the desktop, say a bunch of fake passwords, social security numbers or credit card numbers with enough data to make it tempting to take, noting the size of the file, so that you can use the SRUM feature of +LOG-MD to measure data being transferred off the system.
Step Two – The network
Do not use your production network to analyze malware! You will need to provision a DSL/Cable line to do the evaluation so that you are not on the same network with all your other corporate infrastructure. Unless you have an elite network team that knows how to VLAN you a perfectly isolated network, which I still would not trust, use an isolated network. And yes, let the system talk to the Internet. Many malware samples check to see if it can communicate to the Internet and if not, fails to execute and shuts down.
The next part is whether or not the system should be attached to a Domain. I have frequently seen ransomware and other malware that looks to see if it is in a workgroup or part of a domain. Either add it to your domain, then move the system to the isolated network, or create a fake domain controller and add it to the fake domain, again to make the system look like a real domain attached corporate system.
Step Three – Configure your audit logging
All Windows systems used for malware analysis need to have properly configured local logs to provide you tons of information on the behavior of the malware. It is important to “log the right things”, not “all the things”. If you log everything possible, you are setting yourself up for failure. In order to properly configure the audit logging, you must first know what to configure. Fortunately for us there are some cheat sheets that will tell you exactly what to set in order to optimize the audit logging. There are four steps to properly configure Windows audit logging, they are;
1. Configuring the base Windows audit logging
a. The Windows Logging Cheat Sheet
2. Configure PowerShell logging
a. The Windows PowerShell Logging Cheat Sheet
3. Configure File auditing
a. The Windows File Auditing Logging Cheat Sheet
4. Configure Registry auditing
a. The Windows Registry Auditing Logging Cheat Sheet
These four cheat sheets available to guide you in setting all of these that can be found at;
Follow the guidance in each of the following cheat sheets and you will have the properly configured logs needed to help understand the behavior of the malware detonated and what was created and changed.
Why File and Registry auditing?
Enabling file auditing and registry auditing on certain directories and registry keys will provide log events on those locations of things malware does as a part of the infection and how it persists. For example, as malware drops files to disk in the typical user directory locations, the action would trigger file creation events in the logs. This would include logging any data files the malware created when doing things like keylogging. By monitoring well known autorun locations when malware creates or updates autorun locations, this persistence can be captured in the logs. Some malware that lives only in memory on infection will write to disk and update one or more autorun locations on shutdown. This would bypass traditional autorun tools, but would all be captured in the logs if proper file and registry auditing is configured.
Step Four – Capturing malware artifacts
Now that the audit logging is optimally configured, there are a few more things that can help with your malware analysis. One thing I like to do is capture binaries and artifacts that occur as a part of a malware infection. For example; a malicious Word document will contain one or more VB/CMD/PowerShell scripts that will reach out to a website, pull down a binary and detonate it. Then there are other data files, scripts, tools and keystroke logging files the malware uses or creates that can possibly be captured aiding your analysis. Some of these artifacts can be deleted after use. However there are a couple tools you can utilize to capture them;
1. PECaptureService – Service that captures a copy of binaries (EXE & DLLs, NOT scripts)
a. http://www.novirusthanks.org/products
2. A script to loop RoboCopy to copy all files in the following directories and their sub-directories;
a. C:\Users\<username>\AppData
b. C:\Users\<username>\AppData\Local
c. C:\Users\<username>\AppData\Local\Temp (to be sure to catch items dropped to %temp%)
d. C:\Users\<username>\AppData\LocalLow
e. C:\Users\<username>\AppData\Roaming
f. C:\Users\<username>\Downloads
g. C:\Windows\Tasks
Step Five – Add more log data
There are some additional log tools you can install that can provide additional data. Microsoft Sysinternals Sysmon service can capture some additional details that is useful for malware analysis. You can get Sysmon here;
Some of the items Sysmon can capture are;
- Process Create with hash of file
- Network Connections
- Modules loaded (includes DLLs)
- Drivers loaded
- File and Registry modifications (new to ver 5)
There is overlap between what the ‘Windows Logging Cheat Sheet’ will collect when fully implemented and what Sysmon will collect. I am of the belief that you should use what is built-in first and what is optional second. You can enable all the options of Sysmon, but there will be duplicate data such as the following;
- Network connection overlaps with the Windows Firewall data (use the Windows Firewall)
- Process create overlaps with Windows process create (use both, Sysmon gives you the hash)
- File and Registry changes overlaps with Windows File and Registry auditing (use Windows File and Registry auditing as Sysmon by default logs everything and very noisy unless you create a lot of sysmon_config rules, versus just what you want with Windows file and registry auditing per the cheat sheets)
If you follow these ‘How to build a malware lab’ steps, you will have a great lab to begin doing malware analysis and you will be ready to start using +LOG-MD for your malware discovery lab.