Skip to content

Module 05 — Dynamic Analysis — Behavioural

Type 5 · Detonate & Detect — trace a suspicious Linux binary with strace/ltrace, map the observed syscall behaviour to MITRE ATT&CK, then author a host detection (Sigma/auditd) from the high-signal sequence, deliverable a behavioural timeline plus a rule proven to fire on the malicious trace and stay quiet on a benign one. (Secondary: Reconstruct — rebuild the behaviour from the trace.) Go to the hands-on lab →

Last reviewed: 2026-06

Malware Analysis — static analysis shows you the blueprint; dynamic analysis shows you the building going up.

Difficulty: Intermediate  ·  Estimated time: ~5–7 hrs (study + lab)  ·  Prerequisites: Foundations

In 60 seconds

Static analysis shows the blueprint; dynamic analysis shows the building going up. Anything decided at runtime — resolved imports, decrypted payloads, self-modification — is invisible on disk but surfaces in a trace. strace is the Linux microscope for syscalls, ltrace for library calls; the skill is not running them but reading the thousands of lines for the high-signal handful (openat /etc/passwd, connect, mprotect to RWX). You then author a Sigma/auditd rule from that sequence and prove it fires on the malicious trace, not a benign one.

Why this matters

No static analysis tool can reason about behaviour that is determined at runtime: dynamically resolved imports, decrypted payloads, environment-conditional code paths, anti-analysis tricks that redirect execution based on timing or the presence of specific DLLs. For any sample that static analysis cannot fully explain — and that includes most packed or obfuscated malware — dynamic analysis is not optional. QakBot is a good reason this layer exists: statically it is a packed, self-modifying DLL that changes its own checksum and hides in hidden directories, so static tools see little. At runtime, though, it gives itself away — it injects into a legitimate process (T1055), writes a Run key for persistence (T1547.001), and reaches out for C2. None of that is visible in the on-disk file; all of it shows up in a behavioural trace. (QakBot — MITRE ATT&CK S0650 documents the process injection, the self-modification, and the autostart persistence.)

Objective

Use strace and ltrace to trace the syscalls and library calls of a suspicious Linux binary, interpret the trace output, and map the observed behaviour to MITRE ATT&CK techniques — then author a host detection (a Sigma rule for the auditd/process_creation log source, or an auditd rule) from the high-signal syscall sequence and prove it: it fires on the malicious trace and stays quiet on a benign one. Practice reading Process Monitor (Procmon) CSV output to understand the equivalent Windows analysis workflow. Reading the behavioural timeline and building a verified detection from it are equal halves.

The core idea

The mental model

Dynamic analysis is structured observation: you run the sample under a microscope and record everything it touches. strace is the Linux microscope for syscalls — every kernel interaction (file opens, process spawns, network connections, memory maps) appears in order with arguments and return values. ltrace is the library-level complement (libc: fopen, malloc, execve wrappers). Between them you get a behavioural timeline of what the binary actually did, not what the import table said it might.

The key skill is not running the tools — it is reading the output. A raw strace of a medium-complexity program generates thousands of lines. The analyst's job is to find the signal: openat("/etc/passwd", ...) suggests credential file access (T1003.008); connect(...) to a non-loopback address suggests network communication (T1071); clone(...) or execve(...) indicates process spawning (T1059); mprotect(..., PROT_EXEC) on a region that was previously writable is a shellcode-writing indicator. The technique IDs are not decoration — they connect the observed syscall to the threat model the rest of the team uses.

Go deeper: the Windows equivalent (Procmon)

Procmon (Sysinternals) captures every file-system, registry, and network event with the calling process, operation, path, result, and detail. This module ships a pre-captured Procmon CSV from a real benign Windows process so you can practise the format without a Windows sandbox. Filter and column discipline is the skill: unfiltered Procmon is a firehose; a well-filtered view isolates malicious behaviour from OS noise in minutes. A QakBot detonation is exactly this — a RegSetValue on ...\CurrentVersion\Run (T1547.001) and a write into another process's address space (T1055) are a handful of rows buried in tens of thousands of benign events.

The gotcha

Dynamic analysis means you are running live code, so containment is stricter than for static: the Module 01 network isolation must hold, and the environment must reset to known-clean after every run (here, make reset rebuilds from the image — your snapshot equivalent). And remember the trace only captures the path the sample took this run — environment-conditional or time-delayed code may simply not fire, so a quiet trace is not proof of innocence.

Learn (~4 hrs)

strace and ltrace - Julia Evans — strace Zine (free PDF) — the clearest introduction to strace, what each syscall means, and how to read the output. Essential; read it cover to cover. (~30 min.) - Linux man page — strace(1) — the reference; read the -e trace= filter syntax and the -f (follow forks) option. - Linux man page — ltrace(1) — the library-call companion; understand when ltrace adds information that strace doesn't.

Windows: Procmon - Sysinternals Procmon Docs — the reference for column names and filter syntax.

A real family that only reveals itself at runtime (~15 min) - QakBot — MITRE ATT&CK S0650 — read the technique list to see what a behavioural trace must catch that static analysis can't: process injection (T1055), Run-key persistence (T1547.001), and self-modification that defeats hashing/static tools. This is the runtime profile your trace-reading skill targets.

Dynamic analysis methodology - SANS — "Building a Malware Analysis Lab and Basic Dynamic Analysis" (Lenny Zeltser) — the practitioner workflow for a safe detonation: snapshot, isolate the network, instrument before you run, then diff the system state. Read it for the disciplined order of operations that keeps a behavioural run reproducible and contained.

Key concepts

  • Syscall vs. library call: strace vs. ltrace
  • Key syscalls for malware analysis: openat, connect, execve, clone, mmap, mprotect
  • Reading trace output: filtering signal from noise
  • Procmon event types: File System, Registry, Network, Process/Thread
  • Procmon filter discipline: include/exclude by process, path, result
  • Behavioural indicators → ATT&CK: T1003.008, T1059, T1071.001
  • Why packed malware behaves differently than static analysis predicts
  • Reset discipline: never analyse two samples in the same environment state
  • Author then verify: write the Sigma/auditd rule from the syscall timeline and prove it fires on the malicious trace, not the benign corpus — the build half
  • Real worked family: QakBot (self-modifying modular trojan) — packed and quiet on disk, but at runtime it injects (T1055) and writes a Run-key (T1547.001); the behaviour only shows in the trace, which is the whole point of dynamic analysis

AI acceleration

AI can parse a strace output and summarise it in natural language, but it tends to miss rare or subtle indicators (a single mprotect on a small RWX region, a connect with an odd port number). Use AI to give you the first-pass summary, then manually grep the raw trace for connect, execve, mprotect, and clone yourself. The things AI glosses over are often the most interesting.

AI caveat

A model gives a decent first-pass trace summary, but it glosses the rare, high-value events — the lone RWX mprotect, the odd-port connect. Grep the raw trace for those yourself; what AI skips is often the whole finding.

Check yourself

  • What class of malicious behaviour is invisible to static analysis but shows in a behavioural trace?
  • Name three syscalls in a trace that are worth stopping on, and the ATT&CK behaviour each suggests.
  • Why does "the sample did nothing in the trace" not establish that the sample is benign?

Comments

Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).