Week 1: Malware Basics
Greetings, weary traveller/blog reader. This post marks the beginning of my Defense against the Dark Art series. I’m writing this series as part of the homework for a class, so I know I have a captive audience of at least one (hi, McGrath!), but my hope is that these posts will be accessible/interesting to others as well. I’ll be writing for a general audience with some technical background.
This post will mostly be an overview/introduction to malware stuff: definitions, general information, and tools for static and dynamic analysis.
Let’s jump in!
Types of malware
What is malware? Malware is an umbrella term for any sort of malicious software.
There are three main classes of malware:
- Viruses
- Trojans
- Potentially Unwanted Programs
Viruses and trojans are differentiated by their delivery mechanisms. Viruses exploit vulnerabilities in software in order to infect computers, whereas trojans simply entice you to run them of your own accord.
We can also break viruses and trojans into different subtypes based on what they do. Some of the better known ones are ransomware, spyware, worms, bots. I’m not going to explain what these are; if you want to know you can go look them up on your own.
“Potentially Unwanted Programs” are a gray area. These can be things like keyloggers, password crackers, and the like — tools that can have a legitimate use by a sysadmin, but which can also be useful to malicious actors. Adware and some kinds of spyware can also fall under this category, since they aren’t directly damaging.
Motivation
Why do people write malware? Well, it shouldn’t surprise you that the number one motivator is money! However, there are some other possible motivations.
- Military - There’s a large potential use malware for cyberwarfare; we saw one of the first examples with Stuxnet.
- Research - Security researchers might write malware as a proof-of-concept or to be able to study it. Hopefully they do so ethically.
- DRM - The techniques used to implement digital rights management are suspiciously similar to the techniques used by malware authors. See the Sony rootkit for an example.
- Corporate espionage - Get a leg up on your competitors by stealing their ideas.
- Revenge - Picture a disgruntled employee who wants payback for being fired, or a stalker who plants spyware on their ex’s computer.
- Fun :)
Analysis
Let’s assume you have a sample of some malware that you want to analyze. How we go about that? There are two main approaches: static and dynamic analysis. Any real analysis will probably use a mixture of both.
Dynamic analysis
This is where you let the malware actually run, and try to observe what it’s doing. Needless to say, you want to have a safe environment to do this in or you’ll end up infecting yourself and others, which would be bad. For the class, we were provided with VMs to play in which were already locked down. I wish I knew exactly how they were made so I could tell you, but I don’t. Sorry! At a minimum, you’ll want to disable all network and disk access.
Counterintuitively, although you want to lock down the VM itself and the computer it’s running on, you don’t want lock down the guest OS on the VM. That is, the guest OS shouldn’t have any antivirus or firewall or other security software installed, and it shouldn’t have security updates applied. This is because we’re trying to observe what the malware would do in its ideal situation, on an unsecured system — security measures would only get in the way.
Warning! Some malware is able to detect when it’s running in a VM and disable itself (so you can’t observe it), and some malware can escape VMs. There are ways to deal with this (anti-anti-VM techniques) but sometimes there’s nothing you can do and you just have to run the malware on a real system. This sacrificial system is known as a “goat” in the industry.
Alright, let’s talk tools.
- Process Explorer - Task manager on steroids. Super useful for seeing what’s happening on your system. I keep a copy running on all my windows machines.
- Process Monitor - Logs system calls that processes make. Similar to strace on linux.
- Autoruns - Lists programs that run at startup / scheduled tasks.
- fakenet - Intercepts DNS, HTTP, FTP, SMTP traffic.
- flypaper - Stops programs from exiting and blocks TCP/IP.
Process Explorer, Process Monitor, and Autoruns are all free tools from Microsoft (formerly Sysinternals, before MS bought them). They have a whole bunch of other useful tools. Check them out!
Flypaper used to be a free tool from HBGary, but doesn’t seem to be available any more. Sorry :(
We also used a tool called antispy in class, which listed programs that run at startup. I can’t find it online, but it’s basically the same thing as Autoruns.
The basic process for dynamic analysis goes like this:
- Make a snapshot of the VM
- Start your tools
- Run the malware
- Observe
- Make another snapshot
- Compare
It is very important to take a snapshot before running the malware. This gives you a clean state to fall back to if you need to. When we practiced analysing malware in class, I had to revert to my snapshot several times.
What should you look for after the malware has done its business? Here are a few ideas.
- Suspicious processes
- Newly-created files (hint: search explorer for files modified today)
- Network activity / Downloads from suspicious websites
- New scheduled tasks
- Programs setting registry keys
- ???
If your malware doesn’t seem to be doing anything, try giving it some bait — for example, if you think it might be stealing credit card, try pasting some fake credit card numbers into a file. Be creative! Think outside the box!
Static analysis
Static analysis is where you try to glean things about the code without running it. This can be harder that dynamic analysis, since lots of malware is obfuscated, compressed, or encrypted to try and foil researchers, but it is also less dangerous because you aren’t giving the malware and chance to run, and it enables you to more thoroughly understand the program you are analyzing than you can with dynamic analysis.
That said, there’s one static analysis technique that shines above all others:
Strings
If you don’t know, strings is a standard unix tool which simply prints out all human-readable strings found in a file.
It might not seem like much, but it is surprisingly useful.
Some things you can find with strings:
- file paths
- URLs
- system calls
All of these can give you important clues into what the malware does, what files it targets, what websites it connects to. The types of system calls it makes can tell you what it does – a program which access the keyboard is probably a keylogger, for example. And if you’re really lucky, you might find information like a username which helps to identify the malware author.
Most of the static analysis we practiced in class was just using strings.
That said, sometimes strings isn’t enough. Eventually you’ll need to roll up your sleeve and start disassembling the actual code.
Disassembly
The industry standard disassembly tool is IDA Pro. I’ve never used it, so i can’t really speak to its effectiveness, but I thought it was worth mentioning. It’s pretty expensive, but you can grab an outdated version for free.
Personally, for all my disassembly needs up to this point, I’ve gotten along fine just using objdump from the standard binutils package.
Compression
Often, malware is compressed. This has the dual purpose of making the code smaller, and thus easier to distribute, as well as confounding analysis.
If the malware author used an off-the-shelf tool like UPX to compress, you can usually just decompress it with the tool as well. If not, good luck have fun!
The Achilles heel of compressed/encrypted executables is the same as for DRM: at some point the code has to be decompressed or decrypted in order to run. The key is always somewhere in the malware itself, and can always be found with enough effort. McAfee has apparently developed a generic tool to safely decrypt and/or decompress any malware, but sadly it isn’t available for public use.
Acknowledgements
This post was based on lectures given by Christiaan Beek, Lead Scientist & Principal Engineer at McAfee.