Malware Data Science

Saxe was a research director at a security vendor and Sanders a data scientist there, and the book is aimed at the problem they had: a million new samples a week and no possibility of a human looking at any of them. It moves from static analysis through similarity and campaign analysis into detector construction with machine learning and eventually neural networks.

Two modules cite it, and they cite the first half. The machine-learning chapters are a competent introduction that has aged the way applied machine learning does; the analysis chapters underneath have not aged at all.

Why it is on this shelf

Because it treats the question "what is this file" as a measurement problem rather than a reading problem, and that reframing is exactly what a triage or file-forensics challenge needs. Numbers you can extract in a second, compared against numbers from files you already understand, beat opening the file and staring at it.

Chapter 1, Basic Static Malware Analysis

What a binary tells you before you run it, and the chapter is disciplined about limiting itself to that. The PE header and what its fields claim, the section table and what the section names and sizes imply, the imports as a statement of what the program intends to do, the strings as leftovers of what it was built from, and the resources as a place where whole files hide.

The import table is the highest-value item and the reason this is cited from the file-forensics module. A program's imports are a summary of its capabilities written by the compiler: networking, cryptography, process manipulation, filesystem access. A binary importing almost nothing is either tiny or packed, and both are informative. Work it with the ELF and PE analyzer and the strings extractor, and reading a binary covers what each field means.

Chapter 5, Shared Code Analysis

The chapter the malware module cites, and the one with the most transferable idea in the book: how to say that two files are related without either of them being identical.

The construction is straightforward. Reduce each sample to a set of features - n-grams of its bytes, its strings, its imports - and compare two sets with the Jaccard index, which is the size of their intersection divided by the size of their union. One means the same features, zero means nothing in common, and everything interesting is in between. Because comparing every pair is quadratic, he then introduces minhash, which reduces each set to a small fixed-size signature whose collisions estimate the same ratio, so that similarity search becomes tractable across a large corpus.

For challenge work the value is the concept rather than the pipeline. When you have several artefacts and suspect they came from the same source, a similarity measure over strings or imports answers that in seconds, and it also answers the reverse question - which of these twenty files is the odd one out. The visualisation half, drawing samples as a graph with edges for similarity above a threshold, makes families visible at a glance. Malware triage at scale applies the same idea to a CTF-sized sample set, and the perceptual image hash is the same trick for pictures.

Where it stops

The back half of the book is machine learning, and it is a general introduction rather than a security-specific one: feature extraction, training, evaluation, then Keras. It is fine, and it is not why you are here. Everything after chapter five is optional for CTF purposes.

It is also Windows and PE throughout, and it does not teach reverse engineering at all - it is explicit that its subject begins where reading the disassembly ends. For the sample that resists all of this, Evasive Malware is the next book.

What to take into a challenge

Compare rather than read. When you have more than one artefact - several binaries, several captures, several images - the cheapest useful operation is measuring how they differ, and the difference is usually the challenge. This is the same instinct as diffing a protocol, applied to files.