What Is Malware Analysis?

A malicious binary lands on your desk. Maybe an EDR quarantined it, maybe it arrived as an email attachment, maybe incident responders pulled it off a compromised server. Someone needs to know, quickly and with confidence: what does this thing do, how do we find it everywhere else, and how do we stop it?

Malware analysis is the discipline of answering those questions. Reverse engineering — reading and understanding a program without its source code — is its core skill. This path teaches that skill for defensive ends: detection, incident response and threat intelligence.

What analysis produces

Nobody reverses malware for its own sake. Every hour of analysis should turn into something another team can use:

Output	Consumed by	Example
Indicators of compromise (IOCs)	SOC, threat hunters	File hashes, C2 domains, mutex names, registry keys
Detection content	Detection engineers	YARA rules, Sigma rules, EDR queries
Capability assessment	Incident responders, management	"It steals browser credentials and can download further payloads"
Remediation guidance	IT operations	Persistence locations to clean, services to disable
Intelligence	CTI analysts	Links to a known family, shared code, infrastructure reuse

Keep that table in mind. It is the difference between an analyst who spends three days fully reversing an unremarkable loader and one who extracts its C2 config in an hour and hands the SOC a working detection before lunch.

Why binaries are hard

When a developer compiles a program, most of what made the source readable is thrown away:

Names disappear. Variable names, most function names and all comments are gone. A stripped binary may not even name its own functions.
Types disappear. The CPU only sees bytes and registers. Whether 8 bytes at an address are a pointer, a double or two ints is something you must infer.
Structure disappears. for loops, switch statements and objects become jumps, comparisons and offset arithmetic. The compiler may inline, reorder and merge code aggressively.
Code and data mix. On x86, the bytes of an instruction and the bytes of a string or jump table can sit side by side, and nothing in the file reliably says which is which.

Malware adds a deliberate layer on top: packing, encryption, obfuscation and anti-analysis tricks designed to waste your time. Much of this site's techniques catalog documents those tricks — and the gambits catalog documents how analysts defeat them.

The three ways to look at a sample

Static analysis

Examining the file without running it. This ranges from seconds-long triage (hashes, file type, strings, imports) to hours inside a disassembler. Static analysis is safe and complete in principle — every instruction is in front of you — but it is defeated by packing and encryption, because the interesting code is not in the file in readable form.

Dynamic analysis

Running the sample in a controlled environment and observing what it does: processes spawned, files written, registry keys touched, network traffic sent. Behavioural monitoring is fast and cuts through packing — the sample unpacks itself for you. Its weakness is coverage: you only see the paths that actually executed, and malware that detects the sandbox may simply refuse to act.

Code reversing

Reading disassembly or decompiled code, often while stepping through it in a debugger, to understand the exact logic: how the config is decrypted, how the C2 protocol is framed, what triggers a destructive payload. This is the most powerful and most expensive level, and it combines static and dynamic work.

Tip: Static and dynamic are not rivals. Real analysis alternates between them: a debugger session reveals a decrypted string, which you then search for statically; a static look at imports tells you where to set breakpoints.

The analysis funnel

Effort should grow only as far as the questions require. A practical workflow looks like a funnel:

text

  ┌──────────────────────────────────────────────────────────┐
  │ 1. Triage (minutes)                                        │
  │    hashes · file type · packer? · strings · imports        │
  │    known family? → reputation lookup, stop if answered     │
  └───────────────────────────┬──────────────────────────────┘
                              ▼
      ┌──────────────────────────────────────────────┐
      │ 2. Behavioural analysis (tens of minutes)     │
      │    sandbox / monitored VM · IOCs · persistence │
      └───────────────────────┬──────────────────────┘
                              ▼
          ┌──────────────────────────────────────┐
          │ 3. Targeted reversing (hours)         │
          │    unpack · config · crypto · C2      │
          └───────────────────┬──────────────────┘
                              ▼
              ┌──────────────────────────────┐
              │ 4. Full reversing (days)      │
              │    new family, full report    │
              └──────────────────────────────┘

Most samples exit at stage 1 or 2. Knowing when to stop is as important as knowing how to go deeper.

What you need to know to go deeper

Everything later in this path builds on a handful of foundations:

How programs become binaries — compilation, linking, symbols. Covered next in From Source Code to Binary.
How the OS loads them — the loader, virtual memory, imports. See How a Binary Is Loaded and Run.
The file format — for Windows malware, the PE format, which gets a whole module starting with PE Headers.
Assembly — you do not need to write it fluently, but you must read it. The assembly reference covers the instructions you will meet most.

Defensive first

This path is about understanding malicious software so you can detect it, contain it and clean it up. Two rules apply throughout:

Never run a real sample on a machine you care about. The next lesson, Building a Safe Analysis Lab, sets up the isolated environment every later lab assumes.
Labs on this site use benign programs you compile yourself. They mimic the structures and behaviours of malware — packed code, suspicious imports, encoded strings — without being harmful. When you are ready for real samples, public repositories such as MalwareBazaar exist, but handle them only inside your lab.

Lab: your first triage, on a harmless file

This lab needs no VM yet — you are only reading a file you trust. Use a Linux, macOS or WSL shell.

Write a tiny C program and compile it:

// hello.c
#include <stdio.h>
int main(void) {
    puts("connecting to update.example.com ...");
    return 0;
}

bash

gcc -O0 -o hello hello.c

Ask the file what it is:
bash
```
file hello
sha256sum hello
```
Note the format (ELF or Mach-O), architecture, and whether it is stripped.
Look for human-readable text:
bash
```
strings -n 6 hello | head -40
```
Find your "update.example.com" string among the compiler and library noise. In a real sample, this is exactly how a hard-coded C2 domain first shows up.
Strip the binary and compare:
bash
```
cp hello hello-stripped && strip hello-stripped
ls -l hello hello-stripped
nm hello | head; nm hello-stripped
```
The stripped copy is smaller and nm finds no symbols — the situation you will face with almost every real sample.

Questions to answer: Which of your four observations would make a useful IOC? Which would change if the author recompiled with a different compiler?

Key takeaways

Malware analysis exists to produce IOCs, detections, capability assessments and remediation steps for other teams.
Compilation throws away names, types and structure; malware authors add deliberate obfuscation on top.
Static analysis reads the file, dynamic analysis watches it run, and code reversing combines both to recover exact logic.
Work as a funnel: triage everything, go deep only when the questions demand it.

Objectifs