Beginner·200 points·5 solves

Indicators of Compromise

Learn to judge a feed hit by its last_seen, confidence and source rather than escalating it blind, and to pivot from a confirmed compromise onto a non-infrastructure artefact to find hosts no indicator could ever surface.

The vulnerability

You are a SOC analyst at ABC Financial working a vendor advisory against your estate on Monday 14 September 2026. The evidence lives in /var/log/soc: threat-advisory.md is the vendor report and the place to start, ioc-feed.csv is the aggregated indicator feed carrying first_seen, last_seen, confidence and source columns for fourteen indicators plus an export date in the header comment, proxy.log is a working week of web-proxy requests across 36 workstations, asset-inventory.csv lists the estate alongside company-operated internet infrastructure and approved third-party software, and ioc-reference.md covers indicator types and the Pyramid of Pain. Matching a feed against a log is the cheapest detection there is, and it is where most analysts stop. It fails in both directions. A hit can be worthless, because an indicator is a claim with a date on it: addresses get reassigned, domains get sold, and bulk-scraped feeds routinely list their own subscribers' infrastructure. And no hit is not no compromise, because a feed contains only what somebody has already found and published. Both failures are in this estate. Characterise every hit before you escalate it, and do not treat the last dismissal as the end of the shift.

Your tasks

Match the feed and count host breadth

Take each indicator from ioc-feed.csv and grep proxy.log for it. For every indicator that produces hits, record two numbers: the request count, and the count of distinct hosts in field 3 - grep '<indicator>' /var/log/soc/proxy.log | awk '{print $3}' | sort -u | wc -l. Do that for all of them before you escalate anything. Breadth is the cheapest triage signal you have: an indicator matched by most of a 36-host estate is far more likely to be a wrong indicator than evidence that the estate is owned, while a narrow hit is the shape an intrusion actually makes. That table decides the rest of the lab.

Dismiss the weak hits with grounds

A hit is a question, not an answer, so read the paperwork on each one before acting. How old is last_seen against the export date in the feed header comment, what confidence did the source report, and which source supplied it - hand-curated analyst tracking, or an unreviewed bulk passive-DNS import? Then check the destination against asset-inventory.csv, which lists ABC Financial's own internet infrastructure and its approved third-party software; a feed hit is not a judgement about whether the destination is yours. Every dismissal you write must name the age, the confidence, the source or the inventory entry that settles it. Escalating your own infrastructure is an embarrassment, and blocking it is an outage.

Confirm the true positive

One hit should survive that pass. Pull every request from whatever host or hosts touched it and work the traffic itself: sort by timestamp and look at the gaps between requests, check whether the URI path repeats, note the method and the size of the request bodies, and compare all of it against what the same host's ordinary browsing looks like elsewhere in the log. Automated beaconing and a person using a browser do not look alike. Write down the destination, the host, and the evidence that makes you call it command and control rather than an application polling an API.

Pivot on the behavioural artefact

You are not finished. Re-read the advisory's behavioural-indicator section: it argues that an infrastructure list is stale the moment it is written, reports that subscribers who matched only that list found on average fewer than half the affected hosts in their estate, and names one durable artefact to hunt instead - something the operators cannot change without rebuilding and redeploying every implant. Take that artefact from the advisory and search the whole proxy log for it, not only the traffic you have already looked at. Anything it surfaces beyond the compromise you confirmed is a host no indicator in the feed could ever have found, because a feed holds only what somebody has already published. Then map the command-and-control behaviour to the MITRE ATT&CK technique covering C2 over ordinary web protocols, and read the Pyramid of Pain table in ioc-reference.md for why that artefact was worth more than an address.

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 are indicators of compromise?

IOCs are observable artifacts such as IP addresses, domains, file hashes or URLs that suggest a system may be compromised.

Why do some IOC matches prove worthless?

Indicators can be stale, shared infrastructure or common benign services. Analysts check context and timing before declaring a host compromised.

Is the IOC analysis lab free?

Yes. It is a beginner investigation lab on Codelivly, free to use, using a threat feed and a week of proxy logs.

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