In this post, we will discuss some basics of malware analysis and how to apply the results in your organization.
Why do malware analysis?
General research – sometimes it may be worth looking at the trends and techniques malware authors use.
Signatures – Malware analysis can be applied to create antivirus signatures and signatures for IDS/IPS.
Vulnerability and exploit search – Malware can utilize vulnerabilities and exploits to get itself on a system. Analyzing samples to figure out how it infects the system can be very useful.
Incident response or forensics – You may want to analyze samples during an IR or forensics scenario to figure out capabilities or persistence mechanism. This aids in getting rid of the malware and provides your client (or boss) with more information regarding what access and capabilities malware had.
You may also have some goals in mind when conducting an analysis. Some of these goals can be to collect IOC’s, command and control protocol, persistence, spreading and lateral movement, encryption method, and possible killswitch/prevention methods.
How do you get malware samples?
Lenny Zeltser has a blog post regarding this here: https://zeltser.com/malware-sample-sources/
There are plenty of other ways, such as setting up your own honeypot, checking spam emails for attachments, and Googling hacks for popular video games (seriously).
There are plenty of guides on building a malware analysis lab. There is also the Flare VM from Fireeye that can be used. Do consider operational security (opsec). I recommend reading “OPSec for security researchers” (https://securelist.com/opsec-for-security-researchers/66911/) and Chapter 1 of Malware Analyst’s Cookbook (https://www.amazon.com/Malware-Analysts-Cookbook-DVD-Techniques/dp/0470613033).
Static analysis is analyzing the sample without executing the code. This can include analyzing the properties of the malware sample or disassembling code and analyzing that. Some of the common things to look at for Windows malware is file hash, import/export table, function calls, strings, and PDB string.
Hashes can be looked up to see if anyone else has seen the sample before. Sometimes it’s just easier to find data online and use the analysis results if they’re provided.
Import/export table and function usage can give you a decent idea of what capabilities the malware sample has or what it may do. Microsoft has plenty of documentation on some of the functions you may come across when doing analysis.
CFF Explorer and PEStudio are great for doing static analysis. PEStudio will even highlight malicious indicators for you.
Analyzing the strings included in the malware sample can give you more information about what the sample may be doing or what it interacts with. Sometimes strings can help you get URL’s or IP addresses that you can conduct more research on.
PDB string is related to debugging. The string may not always be useful. Sometimes, it may provide context around the sample. You can also use it for OSINT or writing signature depending on what the string is. Reading “Definitive Dossier of Devilish Debug Details” (https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html) is recommended.
Dynamic analysis is analyzing by executing the sample or sample code. Dynamic analysis can be done to observe behavior. It’s especially useful when the sample is encrypted or encoded somehow.
One of the things to analyze during dynamic analysis is the interaction with the system. Malware may read/write files, it may also modify the registry, or even use built-in system feature such as scheduling for persistence.
Regshot and Procmon are two great tools for monitoring registry changes. Regshot allows you to take a snapshot of the registry pre-infection and post-infection then compare. Procmon monitors registry amongst other things such as file operations, network connections, and processes and threads. If you’re a visual person, the output from Procmon can be visualized using Procdot.
During dynamic analysis, you may also want to simulate the internet, to allow the sample to make web requests or connect to an IRC server. Inetsim, Fakenet, and Fakenet-ng provide some of these capabilities. Inetsim allows you to enable and simulate many different services and it runs on a separate virtual machine. Fakenet and Fakenet-ng run on the same system as the malware and are also able to capture some of the network requests that malware may make.
You can always run the sample and let it connect to the real C2 while also intercepting network data and collecting system data.
Sysinternals Suite comes with a ton of tools that can help with dynamic analysis.
Speeding up analysis:
If you’re collecting and looking at analyzing tons of samples, there are some options. You can automate both static and dynamic analysis.
For static analysis, tools such as Laikaboss and Strelka can be used. For dynamic analysis, Cuckoo sandbox can be used. Results from these tools can be used to trigger alerts or writing detection signatures. Estonia CERT has a public Cuckoo instance that you can use as well: https://cuckoo.cert.ee (Be careful about uploading private or sensitive files to sandboxes or multi-AV sites)
Utilizing OSINT can help save time as well. Malware samples the author distributed may all have different hashes but may have some properties that are the same. Using OSINT to looking for IOCs or data obtained from static analysis can help find other samples, C2’s, analysis reports, etc.
Many times, we notice a malware sample using a specific file name (or format), file drop location, service name, etc. Searching for those things on Google or sandbox sites can lead to similar samples.
Virustotal is also a great resource as well. Relationships feature on Virustotal can help find samples that are related to your sample. Virustotal also has a behavior analysis tab that has results from multiple dynamic analysis sandboxes.
Strings and PDB string were mentioned in static analysis. Searching for a unique string or PDB string can be very helpful too. In the past, we’ve seen PDB string that relates to an opensource project. In this case, the author had modified an opensource project by adding malicious code to it and recompiling it.
Applying your analysis results:
The post title says “Actionable” (because it sounds cool) so in this section, we can discuss applying your analysis results. Applications presented in this post won’t apply to everyone.
Some of the things you can do are:
Block malicious IPs and domains – this is an obvious thing to do. If malware ends up being executed somehow, you’ll at least prevent communication with C2.
Create signatures – Depending on the products you use, you may be able to create signatures. IDS/IPS signatures can also be created if C2 protocol can be detected.
Do historical IOC lookups – If you collect network data or logs, you should be able to lookup IOCs to ensure that your environment has not had those IOCs.
Share IOCs – CIRCLU MISP is a great place for organizations and researchers to share IOCs. AlientVault OTX is another place IOCs can be shared.
ClamAV and Yara signatures are very easy to create. If you’re doing incident response or post-incident cleanup, using ClamAV and Yara can make life easier. Yara rules also work with ClamAV. ClamAV provides an option to move or remove the files it finds as well.
Using file hashes is probably the easiest way to create ClamAV signature file. You can have samples in one directory, run Sigtool and create hash-based database. This is very useful in a scenario where an attacker has deployed the same malware on multiple systems.
Yara signatures are pattern-based. You can look for a certain pattern that’s common for malicious files. In the past, we’ve created Yara rules using a string that turned out to be common throughout multiple samples with different hashes.
Earlier in the post, I had mentioned killswitch and prevention. I did not discuss mutex earlier but mutex (https://en.wikipedia.org/wiki/Lock_(computer_science)) is sometimes used by malware to ensure that only one copy of the malware is running. Creating a mutex that malware sample uses before malware starts can potentially prevent the malware from running. Mutex isn’t the only thing that can be used for malware prevention. Malware may detect the presence of a sandbox or virtual machine and quit running. See “Contemplating Malware Vaccination via Infection Markers” (https://zeltser.com/malware-vaccination-infection-markers/) to learn more about how killswitch/prevention would work.
The following books are great for getting started: Practical Malware Analysis, Malware Analyst’s Cookbook, Learning Malware Analysis, Reversing: Secrets of Reverse Engineering, and Mastering Malware Analysis.
Pluralsight has great courses on malware analysis as well. To see a course that discusses analysis and applies the results, I recommend viewing “Malware Analysis and Detection: Trickbot” by Tyler Hudak and Aaron Rosenmund (https://www.pluralsight.com/courses/malware-analysis-detection-trickbot)
SentinelOne has a free malware analysis course that may be worth viewing: https://www.sentinelone.com/lp/zero2hero/
About the Author:
R is an experienced cybersecurity analyst from the Pondurance SOC team.