0.5 What It Cannot Do

The limits come before the techniques in this course, because every one of them produces a result that looks like an answer. Meeting them for the first time in a queue means meeting them as a wrong verdict rather than as a boundary.

A file cannot tell you what happened

This is the largest one and the most often crossed.

A sample tells you what a program is capable of. It does not tell you whether it ran, when, under which account, what it reached, or whether it succeeded. Those are questions about a machine, answered from endpoint evidence, and no amount of examining the binary produces them.

This cuts both ways, which is the part people miss. A sample that is clearly capable of stealing credentials may have been quarantined before it executed, and a benign-looking file may have been the second stage of something that already ran.

The crossing is rarely deliberate. It happens in the wording, when "capable of encrypting files" becomes "encrypted files" somewhere between the analysis and the summary, and it survives because the second sentence is shorter and reads more decisively.

It is also the crossing most likely to be made by somebody other than you. A verdict passes through a ticket, a stand-up and a status email, and each retelling trims a qualifier. Writing the qualifier into the sentence rather than into a caveat below it is what makes it survive the third retelling.

FROM THE SAMPLE              FROM THE ENDPOINT
what it is capable of        whether it executed
what it would write          what it actually wrote
where it would connect       what it actually connected to
what account it would need   which account ran it
#
The left column is triage. The right column is an investigation,
and a verdict that answers the left is frequently quoted as
though it answered the right.

The habit that prevents it is writing capability and observation as separate sentences, every time, even when it feels laboured.

It feels laboured for about a week and then stops, because the alternative surfaces quickly. The first time a verdict of yours is quoted back in a status update with the capability turned into an event, the extra clause stops looking like pedantry.

The sources that fail quietly

Each of the four main sources has a failure that produces a clean-looking result rather than an error. They are covered properly in their own modules; they are listed here because knowing they exist changes how you read every result before you get there.

Reputation reports what has been seen. On a file nobody has submitted, a clean result is a statement about the file's obscurity, and the sample most likely to matter to you is the one with the least reputation data. Submission count and first-seen date carry more information than the detection ratio.

Detonation reports what happened in one environment during one window. A sample that checks whether it is being watched exits quietly, and the resulting report is identical to the report from a benign file. Nothing distinguishes them in the output.

Strings report what is present in the file, not what is used. Decoy values are ordinary, and a real address is often assembled at runtime and never exists as a string at all.

Capability analysis reports what it can recognize in the code it can read. On a packed sample it reads the packer rather than the payload, so a thin result may describe the wrapper and say nothing about what is inside.

That one has a tell, at least. A capability list dominated by decompression, memory allocation and process manipulation, with nothing about files or network, is usually describing a loader rather than the thing it loads.

None of those four is a defect in the tool. Each is the tool working correctly against a file built by somebody who knew the tool would be used.

They also share a shape worth naming once. In every case the failure produces less output rather than wrong output, and less output reads as reassurance. A sandbox with nothing in the report, a scanner with no detections, a strings dump with nothing interesting and a capability list with three entries all feel like the file is unremarkable, and all four are consistent with the file being the one that matters.

What a hash actually covers

Worth separating from the rest because it is the most trusted value in triage and the most narrowly scoped.

A file hash identifies one exact sequence of bytes. Change one, and it matches nothing. That property is what makes it useful for confirming you are looking at the same file somebody else looked at, and it is what makes it nearly worthless as an estate-wide hunt for anything an actor is actively building.

So "we hunted the hash and found nothing" establishes that this exact build is not present, in the places you looked, in the window your telemetry covers. That is three qualifications, and reports routinely carry none of them. Any one of the three failing is enough to make the sentence wrong.

Module 6 covers the durability ordering properly. The short version is that behaviors outlive infrastructure, infrastructure outlives file contents, and file contents outlive a hash.

None of that makes a hash useless. It is the right value for confirming two people are examining the same file, for deduplicating a queue, and for checking whether a sample is already known. Those are the jobs it does well, and they are all about identity rather than about detection.

Where triage stops and reverse engineering starts

Triage does not recover an algorithm. It will not tell you the encryption scheme, extract a configuration reliably from a custom format, or explain how a protection works.

Three situations reach that boundary, and recognizing them early is worth more than pushing through.

Custom packing that does not yield. Known packers unpack. A bespoke one is a research problem, and the hour you spend on it is an hour the queue does not get. The distinction is usually visible early: a recognized packer name in the identification step means a tool exists, and an unrecognized high-entropy section means one does not.

A configuration you need rather than want. If the incident turns on which servers a sample would contact and the configuration is encrypted with a routine inside the binary, that is reverse engineering by definition.

A verdict that has to be certain. Legal proceedings, an insurance claim, an attribution that will be published. Triage produces a graded confidence, and when a stated confidence is not acceptable the answer needs a different discipline. That is a decision about the matter rather than about the sample, and it usually belongs to somebody other than the analyst.

Reaching one of those and saying so is a finished piece of work. Module 7 covers writing the handoff so that whoever picks it up starts from your hour rather than from nothing.

The failure at this boundary is rarely stopping too early. It is an analyst who does not want to write "I could not determine this" spending a day getting to the same sentence, while everything behind them waits.

What this course does not cover

Being explicit, so you can find it elsewhere rather than expecting it here.

Assembly and debugging. No disassembly, no debugger, no unpacking by hand. That is the discipline this course stops at, deliberately. It is worth learning and it is not a prerequisite for anything here, which is the point: a great deal of useful triage happens without it.

Deep format-specific analysis. Office document internals, PDF object streams and script deobfuscation get enough treatment to triage them and not enough to specialize.

Non-Windows platforms in depth. The method is platform-independent and most of the tooling handles ELF and Mach-O, but the worked examples are Windows-heavy because most triage queues are. Where a technique differs materially on another platform the course says so rather than leaving you to discover it.

Detection engineering as a discipline. Module 6 covers writing a rule from a sample. Building and operating a rule library is a different course.

Each of those four has somewhere sensible to go next, and the references module names them rather than leaving you to search. Knowing where a course stops is more useful than a course that gestures at everything.

Why the limits come first

Because they change what a capability means when you meet it.

A technique introduced without its limit reads as a source of answers, and the analyst who learned it that way will keep using it after the point where it stops working. The same technique introduced with its limit attached reads as what it is: a source that answers one question well and neighboring questions not at all.

That framing is also what makes a verdict defensible. A finding whose limits are visible survives being questioned, and one whose limits are implied does not, because the questions arrive later and from somebody who was not in the room.

There is a practical benefit too, and it is not about defensibility. A stated limit tells the next person where to spend their time. "Capability is partial because the sample is packed" is an instruction as much as a caveat, and it is worth more to whoever picks the sample up than another paragraph of what you did establish.