0.1 What Triage Actually Is

A file arrives. Somebody wants to know whether it is a problem, and they want to know today.

That request sounds like a request for analysis and it is not. Analysis answers what the program does. Triage answers whether you need to act, how urgently, and what to look for everywhere else, and it answers on evidence the file gives up without being taken apart.

The four questions

Everything in this course serves four questions, in this order.

Is this malicious? Not what family, not what it does in detail. A verdict with a confidence attached: malicious, suspicious, or benign, and how sure you are. Suspicious is a real answer rather than a failure to decide, and it is the correct one more often than most queues admit.

How bad, and how urgent? A credential stealer that already ran and a phishing document that was never opened are both malicious and produce completely different afternoons.

What did it touch, or what would it touch? Where it writes, what it starts, where it reaches out to. This is what turns a file verdict into an incident scope.

What do we look for on everything else? The indicators, the detection rule, the hunt. A verdict about one file that produces nothing to check the estate with has answered a quarter of the question.

The order is not arbitrary. Each question is cheaper to answer than the one after it and each constrains the next: a benign verdict ends the sequence, an urgent one changes who you wake, and the scope determines which indicators are worth extracting. Working them out of order is how an analyst spends forty minutes building a YARA rule for something that turns out to be a legitimate installer.

Notice that none of those require knowing how the code works. That is the point, and it is why triage is a different discipline rather than a shallower version of reverse engineering.

What triage is not

It does not tell you how the program achieves what it achieves. It does not recover an encryption routine, unpack a custom protection, or produce a configuration extractor. Those are reverse engineering, they are worth doing, and they take days.

The distinction matters operationally rather than academically. Somebody who treats every sample as the start of an analysis clears one item a day while a queue builds behind them. Somebody who triages properly clears the queue and knows which two samples out of forty deserve the deeper work.

Module 7 covers making that call explicitly, because "this needs reverse engineering" is a legitimate triage outcome and stating it early is the whole value.

There is a second boundary worth naming now. Triage examines a file. It does not establish what happened on the machine the file came from, which is an investigation question needing endpoint evidence rather than sample evidence. The two get conflated constantly, usually in the direction of a triage verdict being read as an incident scope, and Module 7 covers keeping them apart in writing.

The first ten minutes, shown

Here is the shape of it, before any of the reasoning that makes it defensible.

# What is this file, regardless of what its name claims
file invoice_2026.pdf.exe
#
# What built it, and is it packed
die -e invoice_2026.pdf.exe
#
# What can it do, before it has run once
capa invoice_2026.pdf.exe

Three commands, under a minute, and you already know more than the extension told you.

invoice_2026.pdf.exe: PE32 executable (GUI) Intel 80386, for MS Windows
#
PE32
  Compiler: Microsoft Visual C/C++
  Packer: UPX(4.24)[NRV,brute]
#
+------------------------+------------------------------------------+
| CAPABILITY             | NAMESPACE                                |
+------------------------+------------------------------------------+
| check for time delay   | anti-analysis/anti-debugging             |
| query environment var  | host-interaction/environment-variable    |
| write file on Windows  | host-interaction/file-system/write       |
| create HTTP request    | communication/http/client                |
+------------------------+------------------------------------------+

An executable wearing a document's name, packed, that checks for time delays and makes HTTP requests. No verdict yet, and already enough to decide this is worth the next twenty minutes rather than the next two.

Read what each line contributes. The first establishes what the file is, independently of a name chosen to mislead. The second says it was compressed by a known packer, which is a fact about how it was prepared rather than about what it does. The third is the one most triage workflows never run: capability analysis naming behaviors found in the code, in a binary that has not executed.

None of that is a verdict. All of it is orientation, and orientation is what tells you which of the expensive steps is worth taking.

Time is a design constraint, not an excuse

The reason triage exists as a discipline is that the number of files needing a decision exceeds the hours available to decide, permanently and by a wide margin.

That constraint shapes the method. Cheap sources run first. Expensive sources run only when the cheap ones justify them. Every step either changes the verdict or is skipped, and a step that produces interesting information which changes nothing is a step you can afford to drop.

It also means the deliverable is a verdict with a stated confidence rather than certainty. An analyst who will not write a finding until they are sure produces no findings, and the queue does not care.

The constraint has a second effect that is easy to miss. Because the cheap sources run first, they are the ones that shape the hypothesis, and a hypothesis formed in the first two minutes tends to survive contact with everything after it. Knowing that the ordering is efficient and also biasing is why several sections in this course are about deliberately testing the reading you already formed.

The failure this course is built around

A triage verdict is a claim made quickly on partial evidence. The recurring failure is not that analysts get the verdict wrong. It is that they state it more strongly than the evidence supports, and nothing in any tool warns them.

Consider the four sentences below. Each is one somebody could reasonably write after an hour, and each claims more than what produced it.

"The file is clean." Produced by a clean reputation result. What the evidence supports is that no engine that has seen this file flags it, which on an unsubmitted sample is close to no information at all.

"The sample is inert." Produced by a sandbox run with no activity. What the evidence supports is that nothing was observed in that environment, in that window, which is also what a sample that recognized the sandbox produces.

"It communicates with this address for command and control." Produced by a string. What the evidence supports is that the value is present in the file.

"We are not affected." Produced by hunting the file's hash across the estate. What the evidence supports is that this exact build is not present, which one recompile changes while nothing else about the threat does.

What the four have in common is worth stating once. In each case the tool did its job correctly and reported accurately. The gap opened when a human turned an accurate narrow result into a broader sentence, and no monitoring, no error and no gate exists anywhere in that path. The only thing standing between a correct tool and an incorrect conclusion is whether the analyst wrote the limit down alongside the finding.

None of those four is a careless mistake. Each is a reasonable reading of a real result, and each is the version that fails when somebody acts on it. Learning to write the other version is most of what separates a triage function from a tool sequence.

What a good verdict looks like

It names the disposition and the confidence. It says what the disposition rests on. It says what is inferred rather than observed. And it says what would change the answer.

That last part is the one people leave out, and it is the most useful line in the document. "This would change if the packed section unpacks to something with different capabilities" tells the next person exactly where to spend their hour, and it tells the person acting on your verdict how much weight it carries.

It also protects you. A verdict with its limits stated survives being wrong: if the sample turns out to be worse than you said, the document shows you named the gap and somebody chose not to close it. A verdict written as certainty has no such defense, and the review after an incident is exactly where that difference gets noticed.

Module 6 builds the form. Every module before it feeds one of its fields.

Why this is a course rather than a checklist

The tool sequence is not hard and you could learn it from a blog post in an afternoon. What takes a course is the judgment underneath: which source to reach for, what its answer establishes, when a result means the opposite of what it looks like, and where the boundary of your own verdict sits.

That judgment is what the next seven modules build, and every one of them is organized the same way: here is a capability, here is what it gives you, and here is the specific case where it will confidently mislead you.

One consequence of that structure is worth expecting. Several sections will teach you a technique and then spend as long on its failure case as on the technique itself. That is deliberate: on this subject the failure cases are not edge conditions, they are the ordinary result of an adversary who knows the tools you use and builds against them.