Beginner·200 points·13 solves

File Hash Reputation

You learn that a multi-engine detection count is not a threat score: it mostly reflects how long the industry has had a sample and what kind of tool it is. You practise separating a family conviction from a dual-use label from a generic heuristic, and telling "0 detections" apart from "no record at all".

The vulnerability

A reputation service reports how many engines currently hold a matching signature, out of the number consulted. The fraction looks like a score and is not one: it tracks how long the industry has had the sample and what category of software it is, not how much harm the file will do here. The evidence is reputation-reports.json (one cached multi-engine report per line), edr-file-inventory.csv (which host holds which binary and at what path), hash-reputation-reference.md (how to read a verdict) and software-policy.md (approved tools, internal builds and which paths matter). The work is to read the verdict strings, the first_submission_date and times_submitted fields, and the policy, and to keep the ranking out of it: for these six files the count runs close to the inverse of what matters. A rule that alerted on a high detection count would fire on files the policy already accounts for and stay quiet on the one that does matter.

Your tasks

Build the table before forming an opinion

Parse reputation-reports.json, one JSON object per line, into a row per file: name, detection count out of engines consulted, first_submission_date, times_submitted and signed status. Six reports, six rows. Sorting by detection count is a fair way to read the table, but treat that order as a property of the report and write no conclusions in this step.

Read the verdict names, not the counts

For every report, read the vendor_verdicts strings and classify the shape of each name: a specific malware family, a dual-use classification (HackTool, RiskWare, not-a-virus, PUA), or a generic heuristic (Gen:Variant, ML.Attribute, Heur., Suspicious.Packed). hash-reputation-reference.md carries the table. Then ask a separate question of each report: do the detecting vendors converge on one family name, or has every vendor emitted a different label? Convergence is the signal; a pile of disagreeing labels is not, however tall it is.

Settle the high-count files against policy

For the files carrying the largest detection counts, set the verdict shapes beside the metadata - signer, sample age, submission volume - and then read software-policy.md. Decide for each whether it is an approved tool covered by a change record, something the platform team builds and compresses itself, prohibited software that is an IT hygiene matter, or none of those, and record the policy reference that settles it. Packer and machine-learning labels describe how a binary was built rather than what it does, so establish provenance before treating one as a finding.

Find the real malware and pin the host

Take the report where several vendors name the same family and treat that agreement, rather than the size of the count, as the conviction. Read its first_submission_date and times_submitted and compare the submission date with the date in the shift brief, so you can say why a small count on that sample is expected rather than reassuring. Then carry its sha256 into edr-file-inventory.csv to establish which hosts hold the file and where on disk each copy sits.

Separate the two zeros and finish with MITRE

Two files come back with no detections for opposite reasons. One has a complete record, a submission history in the millions and a zero count after years of continuous analysis; the other has no record at all, because nobody has ever submitted the hash. Use the found, times_submitted and first_submission_date fields to tell them apart and say which is the less reassuring result. Finish by naming the MITRE ATT&CK technique under Defense Evasion that covers packing or obfuscating a file to hinder detection.

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 file hash reputation?

It is the known verdict for a file's cryptographic hash, drawn from antivirus engines and threat intelligence, used to quickly judge if a binary is malicious.

Why can detection counts mislead?

Low counts may reflect new malware, while some benign tools trigger detections. Analysts weigh engine names, context and file behavior, not the number alone.

Is this lab free?

Yes. It is a beginner investigation lab on Codelivly with no cost, built around cached reputation reports for six binaries.

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