Intro to Malware Dynamic Analysis: Part 1
By John Hubbard
This is the first post in a wonderfully enlightening series of five. A new post will be posted every Thursday until they’re all posted.
So, you want to jump into the world of malware analysis, that’s great! Reversing malware can be a scary challenge to take on at first due to the complexity. I believe it’s a rewarding and extremely valuable skill to have as an analyst. It is one that can provide tremendous value to your team. When it comes to malware reversing, there are two methods of analyses you will hear about – static and dynamic. These aren’t competing methodologies, but a complimentary set of techniques that help analysts break down and understand the capabilities of a given sample.
Static analysis investigates the strings, metadata, and disassembling the file to try to understand what the malware will do. The key distinction is that you don’t run it. Dynamic analysis, on the other hand, is running malware in a controlled environment. Once “detonated,” we observe closely how it acts, the network connections it makes, and the changes it makes to the victim computer. Both types of analysis have strengths and weaknesses. When analyzing a sample, it’s important to optimize which pieces of each analysis method you will perform. This choice is often driven not just by the technical aspects of malware, but the goals, importance, and time requirements of a given situation.
Static and Dynamic Analyses
Static analysis can be complicated and time consuming. I have found that it will also give you the clearest picture of exactly what a piece of malware can do. Dynamic analysis is often much faster, gets you all the information you need to protect your environment, and can be automated with tools like the excellent Cuckoo Sandbox. The downfall of dynamic analysis is that you can’t be sure that it will always work, or that it will reveal all the potential features of a piece of malware.
Some samples attempt to evade dynamic analysis by embedding checks for virtual machines and will either kill the malware, so it doesn’t run, or modify its behavior to throw an analyst off the trail. Consider the scenario of government written malware where there is a huge incentive to protect the nature of the mission.
It’s easy to imagine a sample from one of these groups could be written to act like general malware in most scenarios. Despite this, under a given set of conditions, it can wildly change the nature of what it does. Stuxnet was famous for this. It “knew” exactly what environment it should be running in and the malware would not activate unless the perfect conditions were met. This situation is a good example of one of the downfalls of dynamic analysis. This illustrates why both static and dynamic analysis should be used, time permitting, or if the situation dictates.
As an analyst, I typically use dynamic analysis for most of jobs with some of the quick and easy static analysis tasks mixed in. Only when I see particularly unique and dangerous seeming sample do I go all the way. This includes disassembly and debugging, it’s a much more time-consuming task and usually not needed. When I receive a sample that I’m going to perform manual analysis, the goal is still to figure out what it will do to a host as fast as possible. We then block those actions from occurring in the environment at large.
In most cases, I find the easiest way to do this is just to run it in a virtual machine. Then I watch the ensuing network traffic, files dropped, and registry changes made. I then use that information to apply firewall/proxy blocks, AV and host IPS signatures, or other mitigations across the organization.
Working with Samples
If your sample is an executable, script, or type like flash or java, some information can be easily found with certain methods. Whereas scripts, pdfs, and other text-based files are generally easier to understand with static analysis since the file is in plain text. You may analyze compiled file types such as executables and swf files faster using dynamic analysis due to the complexity and time-consuming nature of disassembly.
John is a dedicated blue-teamer and is driven to help develop defensive talent around the world. Through his years of experience as the SOC Lead for GlaxoSmithKline, he has real-world, first-hand knowledge of what it takes to defend an organization against advanced cyber-attacks and is eager to share these lessons with his students. As a SANS Cyber Defense curriculum instructor and course author of SEC455, John specializes in threat hunting, network security monitoring, SIEM design and optimization, and constructing defensive postures that allow organizations to protect their most sensitive data. Throughout class, he works with students to explain difficult concepts in relatable and clear language. He illustrates important ideas with stories and demonstrations. John encourages students to push themselves beyond the limit of what they thought possible.
John holds degrees in Electrical and Computer Engineering. His past research spans from malware reverse-engineering to car hacking, mobile app security, and IoT devices. In his free time, John enjoys catching every InfoSec conference he can attend, FPV drone racing, and coffee roasting. John is slowly turning his home into a data center.