Advanced·500 points·2 solves

Advanced Threat Hunting

Learn to hunt with no starting indicator, using frequency analysis over a whole estate — and learn the failure mode that makes the technique produce confident false negatives. You will stack an inventory several different ways, work out which column actually establishes identity, and recognise adversary tooling that is common rather than rare because it was distributed by the organisation itself.

The vulnerability

Hunting begins with a hypothesis and a body of data rather than an alert. The standard opening move is stacking, also called least-frequency analysis: enumerate everything of one kind across the estate, count occurrences, sort ascending, and examine what is rare. In a managed estate almost everything should be everywhere, so the things that are not are worth a look. That reasoning is sound and this data rewards it — there is a substantial long tail of binaries present on exactly one machine each, and you are asked how many. Every one of them is legitimate: developer tooling, a contractor's laptop, one-off utilities. That is what the tail of a real estate looks like, and a hunter who works only the tail goes home with nothing. The failure is not the technique, it is the COLUMN. A file name is a claim anybody can make. Nothing stops a file from carrying the name of a trusted operating-system component while being something else entirely, sitting somewhere that component has never lived. Stack by name and an impostor collapses into the same row as the thing it imitates, inheriting its ubiquity and reading as obviously fine. A hash is an identity rather than a claim: stack on it and the row splits. The same goes for the path, the signer, and the moment each machine first saw the file. That last column carries the second idea. Software spreads through an organisation gradually. When many machines acquire the same file within one afternoon, something distributed it — and the thing that distributes software to many machines at once is the organisation's own deployment system, which is exactly why an adversary would want it. Being common is not evidence of being safe; the question is whether a file's ubiquity is EXPLAINED. Evidence is in /var/log/soc — start with hunt-brief.md and read hunting-reference.md before you begin.

Your tasks

Reproduce the hunt that found nothing

Stack process-inventory.json by file name, count the distinct hosts each name appears on, and sort ascending. Count how many binaries appear on exactly one host — that figure is asked for. Then spend a moment on the tail itself and satisfy yourself that it really is all legitimate. Understanding why this pass comes back clean is the point of the exercise, not a formality.

Stack the same data on a different column

Now count by hash instead of by name, and compare the two results. Every name in a healthy estate should correspond to exactly one hash; where a single name maps to more than one identity, something is wearing something else's label. Exactly one name here does that. Record the name, and how many distinct hashes it resolves to.

Characterise the impostor

Take the identity that is not the legitimate one and describe it fully: its hash, the full path it occupies, its signer, and how many hosts carry it. Cross-check the path against the build policy recorded at the foot of asset-inventory.csv, which states plainly where executables are and are not supposed to be installed. Note that both an empty signer and an executable in that location occur elsewhere in this estate for ordinary reasons, so neither property is a finding on its own — it is the combination, on a file claiming to be an OS component, that is.

Explain how it got everywhere

Look at when each affected host first saw the file. Organic installation is spread out over weeks; these are not. A tight cluster means something pushed it. Find the corresponding entry in software-deployment.log and record the package name and the account that ran the deployment, then check asset-inventory.csv for what that account is and what a package reaching the all-workstations collection actually does.

Confirm behaviour and map it

A suspicious file is a hypothesis until it does something. Check edr-network.log for outbound connections from the affected hosts and identify the external destination they contact, and confirm the set of hosts talking to it matches the set holding the file. Then map two distinct techniques: one for a file adopting the name of a legitimate component to avoid scrutiny, and one for abusing an enterprise deployment system to distribute tooling. A report citing only the first misses how this achieved scale.

Answer the questions

Start the lab, investigate the evidence in the terminal, and answer the questions here.

Hints

Loading…

Official write-up

Loading…

Frequently Asked Questions

What is threat hunting?

Threat hunting is the proactive search for attackers who have evaded automated detection. Hunters form hypotheses, query endpoint and network data, and investigate anomalies instead of waiting for alerts.

What is a hypothesis-driven hunt?

It starts with a testable idea about attacker behaviour, such as a persistence method, then uses data to prove or disprove it. This keeps the hunt focused and produces clear findings or new detections.

Is the advanced threat hunting lab free?

Yes. You hunt across a workstation inventory in your browser, which suits learners who already know basic analysis techniques.

NEW350+ rooms now have a live terminal, so you can learn by typing the commands, right in your browser.Learn in a live terminal. 350+ rooms.Try a labCodelivly is 100% free, no paywall. If it helped you, chip in to keep it running.100% free. Help keep it so.Support us