Skip to content
Sedat Özdemir
Writing

blueteaming

Before You Double-Click That File: Becoming a 'Plague' Hunter in the Lab

A deep dive into the fundamentals of malware analysis, featuring personal stories from the field and practical tips on static and dynamic analysis without compromising your host machine.

Sedat Özdemir
· 4 dk read

It was around 2010, and I was just trying to warm up to the world of cybersecurity. I was examining an 'indispensable' tool I found on a forum. Of course, back then, sandboxes were a luxury I didn't even know existed. I had one VMware setup and thought I was the king of the world. Thinking the analysis was over, in a mix of excitement and carelessness, I left the 'Shared Folders' feature active between my host and the virtual machine. That 'harmless' looking tool turned out to be ransomware, and through that shared folder, it encrypted all my university projects and childhood photos in seconds. The first lesson I learned while crying and reformatting my drive that night was this: In malware analysis, your biggest enemy isn't the malicious code—it's your own carelessness.

Today, I’m talking to the rookie Sedat of that day and to all my friends curious about this field. We’re going to discuss how to professionally answer the question 'What is this thing?' when we encounter malware. Grab your tea or coffee; we’re stepping into our testCompany lab.

First Rule: Looking Through the Glass (Static Analysis)

People who grab a file and immediately smash the 'execute' button usually don't end up on our team; they end up on the 'victims' list. We look at the exterior of the file first. We call this static analysis. Without ever running the file, we examine the external structure of that cell, just like a biologist.

The first place we always look is the 'strings' command. The readable text inside a file tells us a lot. If you see library calls like CreateRemoteThread or URLs like http://malicious-site.example.com/payload.exe inside a calc.exe file, it’s a safe bet that file isn't going to behave like a calculator.

Take a look at this example (defanged):

# Simple logic to extract suspicious strings from a file
# In real-world scenarios, strings.exe or FLOSS is used.

def simple_strings_check(file_path):
    suspicious_patterns = ["http://", "https://", "powershell", "WScript", "cmd.exe"]
    with open(file_path, "rb") as f:
        content = f.read().decode('utf-8', errors='ignore')
        for pattern in suspicious_patterns:
            if pattern in content:
                print(f"[!] Suspicious string found: {pattern}")

simple_strings_check("suspect_file.bin")

Examining PE (Portable Executable) headers is also critical in static analysis. When was the file compiled? Which libraries (DLLs) is it calling? If WriteProcessMemory is being called from kernel32.dll, this friend might be trying to inject code into another process.

Step Two: Detonating the Mine, Controlled (Dynamic Analysis)

Static analysis only goes so far. Modern malware authors aren't stupid anymore. They 'obfuscate' their code—meaning they scramble it. When you look at it with static analysis, you just see a pile of meaningless characters. This is where we move into the fun and adrenaline-filled part: Dynamic Analysis.

You run the file in an environment that is totally isolated—internet cut off, completely detached from the host machine (and I mean actually detached). This is where we watch the malware's behavior in real-time. We monitor which registry keys it changes, which files it creates, and which 'command and control' centers it tries to reach out to. Just remember: if you haven't properly isolated your lab, you're not a hunter; you're just another target.

Related posts