In this section

0.2 How This Course Is Structured

Module 0

Seven modules, six sections each, in the order the work actually happens rather than the order the topics group tidily.

The order is doing work

Most malware courses are organized by technique family: static here, dynamic there, intelligence somewhere else. That arrangement is easy to write and it teaches the sequence backwards, because it presents the expensive methods as equals of the cheap ones.

This course follows cost and dependency instead.

Module 1, What Triage Is. The question you are answering, the time you have, and the environment and handling position. Nothing here is optional and none of it is technique, which is why it comes before any tool.

Module 2, Static Examination. Identification, structure, packing, signing, strings. Cheapest sources first, and the ones that shape every decision after. Everything here runs in seconds and none of it requires the sample to execute, which is why it is also the only part of the method that is safe to do badly.

Module 3, Capability. What the code can do, named and mapped to ATT&CK, from a file that has never run. It sits after static examination because it depends on knowing whether the file is packed, and before detonation because it tells you what to watch for when you do run it.

Module 4, Reputation and Intelligence. What other people already know. It comes after your own examination deliberately: forming a view first and then checking it is a different exercise from reading somebody's verdict and reasoning back to it.

Module 5, Detonation. The expensive step, and the one with the most ways of producing a misleading clean result. By this point you know what the sample can do, so you know what its absence means.

It is also the module with a prerequisite the others do not have: an environment that is genuinely isolated. Reading it without one is possible and running it without one is a mistake somebody else in your organization ends up dealing with.

Module 6, Indicators and Detection. Turning the verdict into something deployable, and knowing which values survive the next build.

Module 7, The Verdict and the Queue. Writing it, handing it off, and running triage as a function rather than as a one-off.

The seventh module is the one that makes this a course about a job rather than a technique. A person who can triage one sample well and cannot run a queue, hand off cleanly, or explain why an item was closed is not yet doing the work somebody is paying for.

Two dependencies in there are worth naming, because reordering them is a common and expensive mistake. Capability before detonation, because a sandbox report is a list of what happened and you need to know what could have happened to read the gaps. Your own examination before reputation, because a detection name anchors your thinking hard and it is frequently wrong about the family.

The second of those costs people more than they realize. Engine detection names are assigned by automated classification at scale, they disagree with each other routinely on the same file, and a name like a well-known family attached to something unrelated will send an analyst looking for behavior that was never there. Reading the name after forming your own view means you can weigh it. Reading it first means you are checking your work against it rather than the other way round.

What every section does

Each section is built to a single test: does it make you do something you could not do before it. A section that restates a concept in different words does not survive the edit.

In practice that means each one opens with a specific failure or a non-obvious result, teaches the technique that addresses it, shows the technique working on real output, and then shows the case where the same technique produces an answer you would be wrong to act on.

That last part is not a caveat section bolted on the end. On this subject the failure cases are where the teaching is, because your adversary knows which tools you use.

The rhythm is consistent enough to rely on. If a section has shown you a technique working and you have not yet reached the part where it misleads you, you are not finished with it.

What the sections show you

Every section that teaches a tool shows its actual output, not a description of it.

Command      the exact invocation, copyable, with the flags that matter
Output       real output, trimmed to what carries the decision
Annotation   which fields decide, and which look decisive and are not
Limit        what this result does NOT establish

The fourth line is the one that makes the course different from a tool tour. A section that shows you capa output without telling you what a partial result on a packed sample means has taught you a command rather than a method.

Where output is shown it is representative rather than harvested from a specific live sample, and the course says so at the point it matters. What is never approximate is a tool name, a flag, a field name or a published rule namespace: those are checked against the projects' own documentation, because a course that invents a switch teaches you to type something that fails.

The knowledge checks

Every module ends with eight scenario questions. They are written to a specific standard and it is worth knowing what it is before you meet them.

The wrong answers are not filler. Each one is the reasoning a competent analyst would actually offer: a real technique applied to the wrong problem, a correct fact leading to a wrong conclusion, or a verdict stated one level stronger than its evidence. Picking one of those and being told why it fails is where most of the teaching in the check happens, so every option carries its own explanation rather than only the correct one.

The questions test decisions rather than recall. You will not be asked which flag prints imports. You will be asked what you do next when the sandbox report is empty and the static examination said the sample was packed.

The answer letters are distributed rather than clustered, and the correct option is never the longest one on its question. That second point sounds like formatting and is not: an assessment where the right answer is visibly the most detailed can be passed by pattern rather than by knowledge, which measures nothing and tells you nothing about your own gaps.

The reference layer

Behind the teaching modules sits a reference layer you will use long after finishing the course.

Cheatsheets organized by the question you arrived with rather than by tool, so the sheet you open matches the problem in front of you. The sheet you need at two in the morning is the one indexed by your problem, not by the vendor's product name.

Cookbooks, runbooks for the procedures this work repeats: clearing a queue item end to end, handling a sample that arrives from outside the organization, escalating to reverse engineering.

Worked cases, complete triage jobs reasoned from the file arriving to the verdict being written, including the ones that end in a weaker finding than the evidence first suggested. The proportion is deliberate: a set of cases that all resolve cleanly is a teaching artifact rather than a record of the work.

A playground, an operational reference and a references module.

The reference layer is deliberately separate from the teaching. A cheatsheet tells you how; the module tells you when and why, and every reference entry links back to the section carrying the judgment behind it.

That separation is deliberate for a reason worth stating. Reference material ages faster than teaching does, because tool syntax changes and services move, while the reasoning about what a clean reputation result establishes does not. Keeping them apart means the part that rots is contained and visible.

How long it takes

Ten to twelve hours at your own pace, and the modules are not equal. Module 2 is the longest because static examination carries the most distinct techniques. Module 5 is the one that needs a working environment before you start it. Module 3 is the shortest and the one most likely to change how you work, because capability analysis is a capable tool that most triage workflows simply do not include.

You can work them in order or start where your gap is. If you already triage daily and want the part you are missing, Module 3 on capability analysis is the section most practitioners have never used, and Module 6 on indicator durability is the one most often done badly.

If you have never done this work, start at Module 1 and do not skip Module 0.3, because the environment is the one thing that has to exist before Module 5 and building it under time pressure is how people end up detonating something on a machine that can reach their own network.

Module 0 continues by covering the environment you will build, where this capability shows up in real work, what it cannot do, and how to follow along without putting a live sample somewhere it should not be.