Push the Red Button

System calls are of great interest to researchers studying malware, because they are the only way that malware can have any effect on the world – writing files to the hard drive, manipulating the registry, sending network packets, and so on all must be done by making a call into the kernel. In Windows, the system call interface is not publicly documented, but there have been lots of good reverse engineering efforts, and we now have full tables of the names of each system call ; in addition, by using the Windows debug symbols, we can figure out how many arguments each system call takes (though not yet their actual types). I recently ran 24,389 malware replays under PANDA and recorded all the system calls made, along with their arguments (just the top-level argument, without trying to descend into pointer types or dereference handle types). So for each replay, we now have a log file that looks like: 3f9b2340 NtGdiFlush 3f9b2340 NtUserGetMessage 0175feac 00000000 00000000 000000...

It's now been a little over 100 days since I started running malware samples in PANDA  and making the executions publicly available. In that time, we've analyzed 10,794 pieces of malware, which generated: 10,794 record/replay logs , representing 226,163,195,948,195 instructions executed 10,794 packet captures , totaling 26GB of data and 33,968,944 packets 10,794 movies , which are interesting enough that I'll give them their own section 10,794 VirusTotal reports , indicating what level of detection they had when they were run by malrec 107  torrents , containing downloads of the above I've been pleased by the interest malrec has generated. We've had visitors from over 6000 unique IPs, in 89 different countries: The Movies There's a lot of great stuff in these ~10K movies. An easy way to get an idea of what's in there is to sort by filesize; because of the way MP4 encoding works, larger files in general mean that there's more going on o...

Summary : With help from GTISC , I have begun running 100 malware samples per day and posting the PANDA record & replay logs online at http://panda.gtisc.gatech.edu/malrec/ . The goal is to lower the barriers to entry for doing dynamic malware research, and to make such research reproducible . Today, I spoke at the ACSAC Malware Memory Forensics workshop in New Orleans about a problem that I think has been largely ignored in existing dynamic malware analysis research: reproducibility . To make results reproducible, a computer science researcher typically needs to do three things: Carefully and precisely describe their methods. Release the code they wrote for their system or analysis. Release the data the analysis was performed on. Of course, even research published at top conferences may fail at some of these criteria; a recent study by Collberg et al. attempted to obtain the code associated with 613 recent papers from ACM conferences, and were able to obtain, build and...

Regin, a piece of state-sponsored malware that may have been used to attack telecoms and cryptographers, has recently come to light. There are several good writeups out there, and I encourage you to check them out. Getting access to samples in cases like this is often a challenge. Luckily, both The Intercept and VXShare  ( warning : both links contain live malware) have released samples thought to be associated with Regin, so that others can perform independent analysis. So far, it appears that the samples are all of the "stage1" component of the malware, rather than the initial "stage0" infector or the later stages. In order to allow others to do dynamic analysis of this malware, I built a very small malware sandbox setup using PANDA. The sandbox essentially just executes a sample for five minutes, recording it using PANDA's record and replay facility. The process is slightly complicated by the fact that most of the stage1 samples are kernel-mode compo...

For the last couple days I've been playing with a sample of " Big Yellow ", worm that exploits a vulnerability in Symantec Antivirus to spread (yes, SAV actually listens on a network port--2967--to receive commands from some sort of central server. I was horrified too). I got interested in it after a warning was posted on the Internet Storm Center . Since the warning helpfully included the MD5 of the executable (f538d2c73c7bc7ad084deb8429bd41ef), I just went over to Offensive Computing and grabbed a copy for myself. Feel free to do the same in the discussion that follows, but be safe--don't do analysis on a machine connected to a network, and take some steps like renaming the executable to something that won't run when you double-click it. To start with, a lot of basic tools barf when run against the file. Dumpbin and pedump both crash, and OllyDBG complains that the file is not a valid 32-bit executable (though it goes ahead and runs it). On the UNIX side, objd...