NYMJCSC Notes and Other Things

I attended the third annual New York Metro Joint Cyber Security Conference on Wednesday, October 5th and I got to see Lenny Zeltser’s presentation in the morning. I had been up until about 2 AM that morning working on a project to submit to someone, so I got a bit of a late start but managed to make it into the room just as he was beginning his talk.

Lenny’s talk was his usual great content, this time focusing on sort of a “Malware 101” for the attendees. Lenny has a framework for malware analysis which starts at the simplest (automated analysis) and escalates in difficulty up to manual code reversing at the top. He covered his first three areas which encompassed automated analysis (sandboxes), static and dynamic analysis.

Some of the tools he mentioned were new to me, and I plan on checking them out. The most interesting ones to me were:

PE Studio
Nice tool for looking at PE headers. You can see full feature list on their site. Notice that there’s a standard and professional license and the feature list reflects what you can and can’t do with each. The interface looks really nice, and there are some features in the standard (free) edition that could be really helpful like entropy detection and anti-debugging import detection. There are a few things missing in the standard edition, though, like listing exports and resources that I’d miss if I switched to PE Studio completely, so I think I’m going to add this to my toolbox and switch back and forth between this and PEview. If budget were no option, I’d definitely start using the professional version of PE Studio going forward, though.

CaptureBAT is a tool that, as Lenny put it, makes a good compliment for something like Process Monitor. This software records state changes and is good for capturing information on file creation, deletion, and other things that you’d be interested in knowing about during dynamic analysis. The only issue with CaptureBAT is that it’s only for 32-bit Windows systems. Lenny said that NoVirusThanks has some tools that can approximate the same functionality for 64-bit machines, though.

This is a really cool tool for visualizing the output of Process Monitor logs. I wish I had this when I was working on this copy of Adwind and I was manually doing the visualizations. Basically, you let Process Monitor collect data and then you export the data as a .csv and then import this into ProcDOT. ProcDOT will then graph this data and visually show you process and thread creation, function calls, etc. You can see some examples of this output on the ProcDOT blog. I’m definitely going to start using this. I remember having a sample that created 16 child processes and I went through all of that manually, which was no fun…

This is a Linux distribution maintained by Lenny Zeltser that comes preloaded with tools for malware analysis. You can browse the full tool list yourself, but this comes with a ridiculous amount of tools both for doing malware analysis directly and for activity in support of malware analysis (such as simulating an Internet connection). I almost think of this as like a Kali for malware.

As far as the other things, I’m going to write up a couple of little topics that came up during some of my analyses that might be of interest to people doing malware analysis.

An easy way to capture dropped files before they are deleted

In one of my Adwind analyses, I noted that there were two .vbs files dropped that were deleted by the malware after execution. I didn’t have any tool that I could use to intercept these files, but I could see where they were being dropped by reviewing Process Monitor results. What I did was I created a .bat file in that directory that contained the following lines:

copy *.vbs *.vbs.bac
goto loop

Nothing groundbreaking here, but it worked. I put this file into the directory where the malware dropped the .vbs files, and then started the .bat file before I started the malware. When the malware executed, this batch file was able to catch both of the dropped files and made a copy for me to review later. Obviously you could change this to work with different types of files or whatever else you wanted, but this was just a really quick and easy workaround to this issue.

Not very obvious file deletion in Process Monitor

DeleteFile is a fairly common imported function in malware I’ve analyzed, so you’d think that you’d see calls to it in Process Monitor. Another thing I’ve observed is some malware will delete files from a command prompt, and this is fairly easy to pick up in Process Monitor as well. This copy of Adwind, however, deleted files in such a way that it wasn’t immediately obvious to me. What it did was make a call to SetDispositionInformationFile to set Delete:True. If you have files that “disappear” during your analysis, take a look in Process Monitor and set a filter on Operation for SetDispositionInformationFile — you should see the disappearing files show up here. Basically, when this is set to True, then the file is deleted when it is closed, as explained by this MSDN article. This blog post from Malcolm McCaffery goes into more detail here and explains why you shouldn’t expect to see a call to DeleteFile in your Process Monitor results.

That’s all for now.


This weekend I attended Hackers on Planet Earth (HOPE) XI in NYC. Saturday night there was a presentation from Robert Simmons of ThreatConnect on open source malware labs. All the talks are going to be placed online at some point, but I thought I’d highlight some of the material Robert presented in the meantime.

Robert spoke about the use of either open source or otherwise free tools for analyzing malware. By “otherwise free” I mean tools that might require registration or some other action to be performed in order to obtain access. He attributed his overall analysis framework to some of Lenny Zeltser’s work, highlighting four main areas where the lab (open source or otherwise) can impact the organization:

1. Malware Research
2. Enhanced Threat Intelligence
3. Network Defense
4. Fun [IMO, it’s more fun once you figure the sample out]

Robert also spoke about some of the benefits of an automated malware analysis system. He described “hunt teams” which would use an automated analysis system and other tools to enhance threat intelligence. His vision of a hunt team is sort of a “proactive IR”, meaning that rather than reacting to an incident, this team would go searching for malware or other issues and then use the automated system as a force multiplier for analysis. For instance, say the hunt team locates what they believe to be an undetected piece of malware. The team would then use the automated system to begin to build out host and network based signatures, begin to gather pieces necessary for threat intelligence (resolved domains, IP addresses, etc.), etc. This information would then be used to improve defensive measures with updated or new signatures.

His top four entry points for malware are:
1. Files
2. URLs
3. PCAPs
4. Memory Images

My interpretation of this is not that malware literally comes from a memory image, but rather these are the inputs into an automated lab that would then be used to isolate and analyze samples. I think this makes sense because most users aren’t going to be looking through captured packets or memory dumps.

The tools that he highlighted for the talk were:
Cuckoo Sandbox (also the sandbox used by malwr.com)
Thug (low interaction URL honeyclient)
Bro (network monitoring tool)
Volatility (memory forensics)

One really interesting thing that he mentioned is that Bing can be used for doing passive DNS type searches. He demonstrated that by searching Bing for an IP address, it will return all domains that have resolved to that IP address. This could be really useful in the event that you have a sample that doesn’t resolve a domain name but rather handles C2 via a hard coded IP address. For example, BEAR resolved her.d0kbilo.com ( this IP is actually associated with a few other malicious domains (e.g., l.kokoke.net). If you lookup an IP address that you feel is suspicious (say from captured packets during dynamic analysis) and notice that it is associated with numerous domains related to malware, you could safely assume that the traffic you found is suspect and should be looked at in more detail. I tried using Bing for this with the BEAR IP address, and didn’t have much luck with it, however trying other IP addresses associated with botnets did reveal other domains that currently or previously resolved to that address. That said, I got some similar results searching on Google also, so perhaps it’s best to just try various search engines for this type of research and then see if you get results from one search engine that you might not get from another.

Anyway, going through the tools, Cuckoo Sandbox is a great tool that I actually use all the time via malwr.com. You can think of a sandbox as sort of an automated container for malware that creates a virtual environment each time a sample is analyzed. In the case of the malwr.com instance, it drops the sample into a Windows XP (or other) environment and then lets the malware run while observing behavior. It’s nice to use a sandbox because it can help get a lot of basic info sorted out for you quickly, such as generating hashes, searching for strings, and so on. These are typically actions that you take with every malware sample that you work on. You can also observe dynamic information such as network activity and dropped files in the sandbox. One thing to keep in mind is that you need to have an understanding of the “baseline behavior” of what sample you are analyzing and the environment so that you can recognize normal behavior that the sandbox might flag. For instance, if you are analyzing a malicious PDF, you should be aware of what files might be dropped or what actions Acrobat Reader will take that are part of normal operation (such as dropping a SQLite database) vs. what can be traced back specifically to the sample you are working on.

Thug is a tool that I haven’t heard of before this talk, and from what I hear isn’t that well known just yet. Thug complements tools like Dionaea. Dionaea and other honeypots will sit out there and collect attacks that are directed towards machines, while Thug is a honeyclient that will go and simulate a connection to suspect sites, in this case websites. It works by crawling sites and simulating various client-side software (e..g, Flash) and trying to see what is triggered by the possibly malicious website, then saving these results for later analysis.

Bro Network Security Monitor could be described simply as an IDS, but it appears that this description doesn’t really do it justice. It’s more of a framework than a system, and it’s actually been around since the 1990s so it has quiet a bit of experience backing it up at this point. Though Bro’s focus is on networking monitoring, you can also use Bro to do traffic analysis, which is how Robert presented this tool during the talk. I remember one interesting point he made was that Bro is very good at recognizing types of traffic – so, if you see captured traffic that Bro didn’t identify, chances are it’s something very shady since at this point Bro will successfully identify pretty much anything that is legitimate. I think sometime I’m going to try using Bro instead of other tools (like Wireshark) and see what results I get.

The last tool that he mentioned was Volatility, which probably doesn’t need an introduction but I’ll talk about it a bit anyway. Volatility is a framework for volatile memory analysis/forensics. There are a few reasons why you might want to look into this type of memory. One is that you might be able to get a better look into things that would otherwise have been obfuscated during static or dynamic analysis. For example, when I analyzed BEAR, you didn’t see the domain or IP address for the C2 server in the static analysis, but you did observe it in the memory dump that I did just with one of the sysinternals tools. Another thing that you can do, which Robert highlighted in the talk, is compare two views of internal memory to see what has changed because of the malware. He took a sample of “normal” memory and then a sample of memory after running the suspicious file and then compared the two in order to help determine what new processes (and other indicators) were associated with the malware sample.

This was a great talk. A couple of other things – one was that Robert had a really clean format for displaying analytical results in swimlanes. He basically set up a swimlane for each of the four tools and then inserted the signatures obtained by each tool in the respective swimlane. I thought it was a great visualization, and I think I’d like to try it at some point with one of my future analyses. The other thing that was nice was that it looks like Robert’s thought process around malware analysis (at a high level) lines up with what I learned, so it was a good validation of how I’ve taught myself and the materials that I used.

Robert has some interesting repositories up on his GitHub site and he’s also on Twitter if you’re interested in following his work.