Think Twice Before Opening That File: A Peek into the Kitchen of Malware Analysis

Back when I first started in the industry, I suspected something fishy about a 'cracked' network analysis tool I downloaded from a forum. I told myself, 'Sedat, you're in the biz now, why don't you take a look and see what’s really going on?' But back then, I had no idea what a sandbox was, let alone an isolated environment... I just turned off my antivirus and ran the file on my main machine. The result? My computer turned into a zombie overnight, CPU usage pegged at 100%, and every single file ended with some gibberish extension. The embarrassment I felt while reformatting that day taught me the hard way why malware analysis is both an 'art' and a 'discipline.'

Today, I want to talk about how we dissect those 'suspicious' files we encounter in our testCompany labs or during our Red Team operations—how we get straight to the heart of the code. Grab your coffee, because we're diving deep.

First Stop: Static Analysis (Don't Be Fooled by Appearances)

The first rule of analyzing a file is this: Never run it. First, look at it from the outside, give it a sniff, and weigh it. Static analysis is the examination of a file without actually executing its code. Usually, the first thing we do is take the file's hash value (SHA-256 or MD5) and check platforms like VirusTotal to see if 'anyone has seen this before.'

But the real fun starts with the strings command. Pulling readable text out of a binary file can sometimes hand you a gold mine of clues. For example, if you see an address like hxxp://example[.]com/api/v1/collect, you’ve already figured out where that file is planning to report back to (the C2 server).

Then there's the 'Packer' issue. Developers compress files to protect their code, but attackers do it to avoid detection (using tools like UPX). If a file has very few strings and the entry point looks weird, you know there’s some obfuscation going on.

# Example: Simple string analysis and hash check (Defanged)
$ sha256sum suspicious_sample.exe
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

$ strings suspicious_sample.exe | grep "http"
hxxp://update-service-test[.]com/download/payload.bin

Second Stop: Dynamic Analysis (Cage It and Watch)

Sometimes static analysis isn't enough. An attacker might have encrypted their code so thoroughly that it would take days to decrypt. This is where 'Dynamic Analysis' comes in. At this stage, we run the file in a 'lab environment' (Sandbox). We unleash the file in a virtual machine that is disconnected from the internet (or simulated) and where every single move is logged.

Here’s what we’re looking for:

• File System Activity: Is it copying itself under C:\Windows\System32? Is it adding itself to startup?
• Registry Changes: Is it writing anything to Run keys?
• Network Traffic: Is it making DNS queries? Is it 'beaconing' (sending signals at specific intervals)?

For instance, when we find a suspicious file on the testCompany network, we look for network traffic patterns like this:

// Simulated C2 communication log
{
  "timestamp": "2023-10-27T10:00:01Z",
  "source_ip": "127.0.0.1",
  "destination_domain": "api-check-update[.]xyz",
  "request_type": "POST",
  "payload_size": "256kb"
}