Advanced·500 points·3 solves

APT Intrusion Investigation

Learn why file system timestamps cannot be used to date an intrusion, and what to corroborate them against. You will find an artefact that a creation-time sort actively hides, prove its metadata is false using three sources the attacker never controlled, and identify a second command-and-control channel that survives blocking the first.

The vulnerability

A file's creation and modification times are attributes stored next to the file. They are writable. Setting them backwards is a routine defence-evasion step, and the purpose is not to hide the file — it is to make it BORING. Something that appears to have been on the disk for years reads as part of the original build: it predates everyone who might question it, and it belongs to whichever vendor directory it sits in. That defeats the most natural triage move there is. Sorting by creation time to find what is new puts a backdated artefact at the far end of the list, among the operating system files, which is exactly where nobody looks. The first responder in this scenario did precisely that and reported the machine clean. You cannot detect a forged timestamp by studying the timestamp. You detect it by finding sources the attacker did not control and checking whether they agree. An endpoint agent records when it first OBSERVED each file, and it cannot observe something that is not there — so an agent reporting continuously since well before a file supposedly existed is making a claim the file contradicts. A backup catalogue records what each set actually contained, so absence from every older set is positive evidence of absence. And metadata can contradict itself: nothing can be older than the directory that contains it. The second habit this lab teaches is not stopping at the first channel. Sustained operations keep a fallback, contacted rarely — sometimes only a handful of times a year — purely to confirm it still answers. Rank destinations by connection count and it sits at the very bottom, indistinguishable from a typo. Blocking the loud one and closing the case contains nothing. Evidence is in /var/log/soc; read forensics-reference.md before you start.

Your tasks

Reproduce the first responder's pass, then distrust it

Sort filesystem-metadata.json by creation time and look at both ends. Nothing recent is out of place, which is what was already reported. Note also that several files are genuinely years old and entirely legitimate, so "old" is not suspicious by itself — you cannot simply invert the sort and accuse the oldest thing on the disk.

Compare what the disk claims against what was observed

endpoint-agent-inventory.json records, for each file, the moment the agent first observed it. Join the two sources on path and compare the claimed creation time with the first-observed time. For legitimate files these are consistent. For exactly one file they are years apart, and in the direction that matters: the agent has been reporting since long before the file claims to have been created, yet only saw it recently. Record its full path, the date it claims, and the date it was actually observed.

Corroborate twice more before you accuse anything

One contradicting source is a discrepancy; three is a finding. Check backup-catalogue.json and establish which sets contain the file and which do not — a file that genuinely existed years ago is in the older sets. Then look at the metadata for the directory that contains it and compare the two creation times. Record the directory's creation date, because the relationship between the two is impossible and is the cleanest single piece of proof in the case.

Establish the persistence and the evasion

Search windows-security.json around the true arrival time. Something was installed to survive reboots — record the registry key it was written under, exactly as the event gives it. Shortly afterwards an event records that the audit log itself was cleared; record that event's numeric identifier, and the account responsible for both actions. Check asset-inventory.csv for what that account is supposed to be able to do.

Find BOTH channels, and compute dwell honestly

Group network-connections.log by destination for the affected host. One destination dominates and is the obvious answer. Then look at the bottom of that same ranking, not the top: there is a second external destination contacted only a handful of times across the whole period, on a different port, by this host and no other. Record both. Finally compute the dwell time in whole days from the true arrival to the date of this report — and note that the retention policy in asset-inventory.csv limits what the network log can show, but not the agent's first-observed value. Then map two techniques: one for falsifying timestamps, one for keeping a spare channel.

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 an APT intrusion?

An advanced persistent threat intrusion is a long-running, targeted compromise, often by a state-linked group, that aims to stay hidden while collecting intelligence. It uses stealthy persistence and carefully chosen tools.

How do you investigate when you have no indicators?

Build hypotheses from behaviour and context: review persistence locations, unusual network connections, timestamps that may be manipulated and rare binaries, then pivot from each finding to widen the picture.

Is the APT intrusion lab free?

Yes. You investigate a maritime operator's compromise in your browser, which suits learners with some forensics and incident response grounding.

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