What’s Your Analysis Process Pt. 2
How Do The Professionals Do It?
My findings here were mixed and I wasn’t able to find one workflow consistently referenced by seasoned analysts that encompassed everything. As I’ve mentioned this likely varies from analyst to analyst. I did, however, manage to find a couple of resources that discussed components that should be included in one's workflow. I’ve added those references to my Resources Keep List. I intend on maintaining this list as time progresses and I learn more.
Some of the components consistently mentioned have been included below. They provide a good foundation and I referenced a few when developing my own workflow.
Establishing a Malware Analysis Lab
Indicator Collection
Reporting
I’ve been making a conscious effort to also incorporate intake into my process (see the workflow diagram below).
Method Of Cataloging Samples
I think there is so much benefit in cataloging the samples you analyze. For starters, why reinvent the wheel when you’ve potentially seen the same sample before? Cataloging also allows you to search historically by hash, similar code snippets, or indicators of compromise (IOCs). I’ve gone through several waves trying to determine the best method but settled on an automated folder structure creation. Let me explain…
Her name is triage.py 😬 — She's a command-line (CLI) tool written in Python that takes a switch and title. When submitted, the below file structure is created. Here I’m able to organize all the artifacts that result from my analysis. It isn’t perfect but for now it is working.
If you’re interested in incorporating automation into your process via CLI, get started with How to Build Command Line Interfaces in Python With argparse.
What Do You Want to Achieve?
This is an area where it's really easy to get lost in the abyss. When you start analyzing a sample, whether it's limited to triage or requires in-depth analysis, you should have a grasp on what questions you’re trying to answer and what you want to achieve. This may vary depending on your audience or the time you have to spend on analysis.
I like to cover questions that would inform two groups…non-technical readers and technical readers.
Non-Technical
Overview (e.g. What happened? What was the impact? What can we do to detect and/or stop it?..etc.)
Technical
Infection Vector (e.g. How does the malware get delivered?)
Observed Behaviors (e.g. Observed C2, Notable obfuscation/deobfuscation routines, Anti-debugging features...etc.)
Indicators of Compromise (IOCs) (e.g. IOCs that result from static or dynamic analysis)
Detections (e.g. This includes developed signatures or referenced publicly available signatures)
What’s Your Flavor Of Reporting?
I recently read an explanation differentiating the categories of reporting provided by the OA Labs co-founder on their Patreon feed that made me have an entire “duh” moment. It also made clear that I’d been doing some Frankenstein-type reporting that included “how-to” and “intelligence-ish” reporting. In other words, I found that I need to clean up my reporting focus and the first step is having a better idea of the flavors recognized professionally.
I’ve quoted his key points and explanation below..
Several of their tutorials have been a significant help in breaking down some of the RE 101 concepts, so you’ll see other references to their work on this site.
Thank you for making it this far; I’m trying to keep the read times digestible! Below is my workflow (also shared via GitHub below), as of this publishing anyway.
You’ll notice that ‘Static Analysis’ is shown in two places. Once the file has been run through a sandbox, I prefer to look at some of the static file properties for any blaring information that may guide analysis. A few of the most common things I look at include 1. checking the file strings, 2. checking the entropy to determine if the file is packed, and 3. confirming the file type matches the displayed extension.
What did you think?!
Curious about something you read or have questions, contact us!