Since my last entry, I’ve settled into a group, we’ve made a somewhat detailed plan of what our tasking will be and we’ve started work. I did indeed end up joining the Malware Analysis team with intrepid classmates Michael Banks, Mark Kaiser and Jennifer Bowers. As has often been my experience in this program, they’re top-notch and I could hardly pay to have better teammates. Last week, we finished up our plan; just to clarify what this project exactly is, let me first explain that.
Malware Analysis? So is that like an antivirus program you’re writing?
Well, no. As discussed in my previous post, computer science is a far larger field than just programming, despite it being a common overlap in subfields. What this project actually is, is a demonstration of how a computerized attack would be safely analyzed and understood in a controlled and professional environment. Writing antivirus software without this step being accomplished first is putting the proverbial cart before the horse, because antivirus software depends on signatures and patterns first cataloged in this kind of analysis.
OK, so how is this done? What technologies are used?
The general concept is that any suspicious data should be isolated from other systems as a measure of control. This can be accomplished in a few more obvious ways like in an “air-gapped” or otherwise segregated network, but the cheaper and more pedagogical alternative is to use software virtualization. In our case, OSU has a deal with the proprietors of VMWare to provide extended keys for this type of situation.
VMWare is what’s known as a “hypervisor,” a concept that you’ve probably run into for years at this point, whether you’re a student or TA or professional. What it does is manage simulated (“virtualized”) computers known as virtual machines that can be configured in any number of ways as a subset of the host machine’s hardware. On a 64-bit host with a 320 GB disk and 16 spare gigs of RAM, one virtual machine might be running a Debian Linux distribution with 40 GB of disk space afforded 8 GB of RAM, and two others may be Windows XP machines, further segregated into x86 and x64 machines with their own disk and memory. These machines can be arranged in a totally abstracted, virtual network or they could be bridged to the host’s router or either at different times. In fact, this is exactly the sort of environment that the Malware Analysis team is using to analyze samples of software harmful to Windows XP installations.
The general plan
Malware samples are acquired from the internet – in our case, we’re using relatively controlled open-source samples authored for the purpose of analysis, but there are various repositories and websites that exist for this purpose such as VirusShare or “theZoo.” The virtual machines are then opened up to the host network one way or another and the samples are loaded onto the machines. The virtual machines are then isolated on their own virtual network. At this point the team is able to create a “snapshot” of the virtual machine – a kind of differential restore point that will be used for scientific control purposes.
In static analysis, the malware is not (intentionally) run, and various tools and utilities loaded onto the virtual machines can disassemble or otherwise read features of the malware outside of runtime. Utilities that will be used for this purpose include Ghidra, Ida, and an assortment of tools that read properties of Windows’ “portable executables” – the very executables that contain the malware. By seeing which Windows functions are used and which assembly instructions are given, one can begin to glean what the malware might do.
In dynamic analysis, the malware is actually run, along with utilities that will attempt to capture what is happening as it happens. These include things like procmon, as many attacks are inextricably linked to the management of processes in the operating system, as they attempt to hide their activity and exploit resources for ulterior reasons. Other utilities include apateDNS and Wireshark, which respectively simulate a DNS server for the virtual network and capture what network packets each process is trying to send and receive. It’s this mode of analysis that I will be performing on the first malware sample this week, before compiling my results and meeting with my group about them before our first progress report.
Whew
It’s been a fast couple of weeks, inside and outside of school, but order is returning and that means I can be as productive as possible. I even managed to restore the headlights on my car today so I can actually see at night! I’ll see you at my next blog post, which I’m guessing is going to be an analysis of the analysis.
Leave a Reply