0.6 Following Along

Module 1 sets up the discipline properly. This is the short version, so you have something to run while you read it.

The fastest working machine

REMnux is a Linux distribution with the analysis tooling already installed and configured. It is the shortest route from nothing to a machine that can do most of this course, and it removes an afternoon of installing tools that each want a different Python version.

# Confirm the machine has what the course uses
file --version
capa --version
floss --version
yara --version
#
# Detect It Easy, console build
diec --version

If those five answer, you can work Modules 2, 3 and 4 today. Module 5 needs the isolation from 0.3, and a Windows analysis machine if you want to run Windows samples in their own environment rather than in an online sandbox.

Worth knowing what REMnux is and is not. It is a working analysis environment, not an isolated one: it ships configured to reach the internet because most of its tools want to. Turning that off is your job and it is the difference between a machine for examining files and a machine for running them.

Samples that are safe to practice on

This is the question that stops people, and it has a good answer that does not involve downloading live malware.

Start with files that are not malware at all. Ordinary Windows binaries make excellent practice for static examination: run capa against a legitimate installer and read what it reports, because knowing what normal looks like is what makes abnormal visible. Most analysts skip this and then cannot tell whether a capability list is unusual.

That baseline is worth building deliberately rather than absorbing by accident. A legitimate installer will report file writes, registry access, service creation and network activity, which is the same list a great deal of malware produces. What separates them is rarely a single capability and usually the combination, and you cannot see a combination as unusual without having seen the ordinary ones.

Then use deliberately safe test files. The EICAR test file is not malware and every scanner detects it, which makes it perfect for testing that your workflow, your submission process and your alerting all behave. It teaches nothing about analysis and everything about whether your setup works. It is also the right thing to use when you want to check that a control fires, without introducing anything real into an environment to find out.

Then use samples built for teaching. Practical Malware Analysis ships lab binaries designed for exactly this, and there are open collections of intentionally-crafted samples with published answers, which is the useful part: you can check whether your verdict was right.

That feedback loop is the thing a real queue never gives you. In production you close an item and almost never learn whether the verdict held, so a source of samples with known answers is the only place your calibration actually improves.

Live samples last, and only if the handling position in 0.3 is settled. Public repositories exist and they are appropriate for a practitioner working within their role. They are not appropriate as a private collection, and the course does not need them.

The ordering here is not caution for its own sake. Each tier teaches something the next one cannot: normal binaries teach you the baseline, test files teach you your workflow, and teaching samples teach you whether your reasoning was correct, because they come with an answer. A live sample teaches you none of those, because nobody can tell you whether you got it right.

The failures worth causing deliberately

Every source in this course fails quietly, so the only way to recognize a quiet failure quickly is to have produced one on purpose while nothing was at stake.

Run capa against a packed file and then against the same file unpacked. The difference between the two results is the single most useful thing you can see early, because it shows you what a thin capability list actually means.

Submit a file nobody has seen to a multi-scanner and read the result. Zero detections, and now you have felt what that looks like when it means nothing.

Detonate something benign and read the sandbox report. Then compare it to a report from a sample that declined to run. Getting the second one is the hard part, and the point is that they are hard to tell apart.

If you cannot get the second, the next best exercise is reading a published sandbox report for a sample known to check its environment, alongside its static analysis. The gap between what the file could do and what the report recorded is the whole lesson.

Take a string that looks like an address and check whether the binary ever uses it. Doing this once cures the habit of quoting strings as behavior. Once is genuinely enough.

Write a YARA rule against a sample, then recompile or repack the sample and run the rule again. Watching a rule you wrote stop matching is the fastest possible lesson in indicator durability.

Do these before you need them. All five take minutes, none requires a real sample, and the point of each is to make a failure familiar while it costs nothing. A quiet failure you have seen once is recognizable in seconds; one you have only read about takes an afternoon.

Habits from the first item, not the hundredth

Four things that cost nothing now and are painful to retrofit.

Write the verdict and the confidence in the same sentence. Not the verdict now and the confidence later if somebody asks. The two travel together or the second one gets lost.

Record what you checked, including what came back empty. An empty result is evidence and it is the part nobody writes down, which means the next person repeats it. Three lines is enough.

The version that costs you most is the check you ran and did not record, because in six weeks you cannot tell whether you ran it or considered running it. Nobody remembers, and the ticket is the only thing that does.

Say capability and observation separately, every time. The habit from 0.5. It reads as laboured for a week and then becomes the reason your findings survive being quoted.

It is also the one habit here that other people will notice, because it changes what they can safely do with your work.

Timebox the item before you start it. Decide what it is worth, then notice when you have passed it. The failure in triage is almost never spending too little time on a sample; it is spending three hours on one while a queue builds.

Passing the box is allowed. What is not allowed is passing it without noticing, which is the ordinary way three hours disappears. The decision at the boundary is a real one: is this now worth more than the rest of the queue, and if it is, say so and continue deliberately.

Working against a real queue

If you have access to one, three things from this course are safe to apply immediately and will surface something.

Re-read your last ten closed items and check whether the verdict matches the evidence recorded. Not whether it was right, which you cannot know: whether the sentence written is supported by what is in the ticket. This is uncomfortable and it is the fastest way to find your own pattern.

Most people find one of two patterns. Either the verdicts are stronger than the evidence, which is the failure this course is built around, or the evidence is not recorded at all and the verdict is unreviewable regardless of whether it was correct.

Run capability analysis on something you already closed. If it tells you something the original triage did not have, that is a gap in the method rather than in that item. Pick one you closed quickly and confidently rather than one that was difficult.

Check what your closed-as-benign items had in common. If they are mostly "no detections", the queue is being cleared on the weakest source available.

That one usually produces the strongest finding, and it is not about any individual item. A queue cleared predominantly on reputation is a queue with a systematic blind spot exactly where it matters most, and no single ticket in it looks wrong.

What is not safe against a real queue is anything from the previous section. Do the deliberate failures on your own machine. A production queue is not the place to find out what happens when you detonate something.

Then begin

Work the module summary, which pulls Module 0 together, then start Module 1.

If you have not built anything yet, get REMnux running first. Module 1 opens on what triage is answering and what it costs, and it reads differently when there is a terminal open in another window with the tools already installed.

That holds for the whole course. Every module has something to run, and reading them with nowhere to run it turns a method into a description of a method.