Welcome back to the blog. Last time I discussed how my team would be setting up their malware testing environment and how the project was starting to come along. This last week, though we encountered a bit of a problem!
Oh no, who could have seen this coming? (“What do you plan to do to get back on track?”)
While the first malware sample went off without a hitch for our plan of separating static and dynamic analysis duties, the second sample was not quite so well-adapted for our project format. The sample was chosen due to results that were expected using one tool (IDA, Interactive Disassembler). IDA mostly falls under the category of static analysis since disassembly doesn’t constitute running the malware necessarily.
Anyway, the problem is that the sample that was chosen was simply a dynamic-link library with very few actually moving parts. You might see how this would be a problem when it comes to observing it in action. Several methods were tried to get it to budge a little:
- rundll32.exe – this is an executable Windows normally used to load up DLLs innocuously. It was theorized that this might trigger the DLL somehow, but practically speaking all it resulted in was a few suspicious looks.
- Python script – the DLL actually came with a Python script that could be run with it, but its purpose was mostly to modify a few memory addresses to alter what was seen in IDA.
- DumpIt and Redline – the idea here is to get another picture of what exactly it did to memory by analyzing a memory dump. This process is currently ongoing as the team grapples with configuring these utilities for the older operating systems.
This was not exactly ideal! Ultimately, the vetting process for malware samples will have to change in order to better support our outline. The team considered simply changing the format of the project, but decided that it should still be possible to find malware samples that can be both statically and dynamically analyzed in a substantial way.
So is the project on track? (“Do you feel your project is on-track to succeed?”)
Yes. Although there was a hitch, we are still on-schedule and don’t see any obstacles. We will certainly complete a thorough analysis of at least 3 malware samples, if not 4, although this week we are mainly working on assignments. If something goes seriously awry, I’ll write about it in the fourth blog post, but I feel pretty confident that the rest of the story will be told in the reports.
That’s it for now! I’ll see you next time and we’ll find out if my confidence was well-founded or not.
P.S.: This week I’ve been applying to jobs right and left, hoping to find a position somewhere in the Pacific Northwest where I grew up. I’ll be continuing that process also and report back if anything interesting has come up by next time.
Leave a Reply