Lion Cipher Lab
Find the last clean backup before ransomware, with entropy and magic bytes
- Digital Forensics & IR (DFIR)
- Intermediate
- ~50 min
- Free · no account required
Why it matters
When ransomware hits, the question that decides how bad the week gets is not 'do we have backups?' -- it is 'WHICH backup is clean?' The instinct is to restore the newest snapshot from before the ransom note appeared. That instinct is wrong more often than people expect, because the note marks the loud night, not the first night: attackers frequently sit inside a network for days, and modern ransomware often encrypts only part of each file to move faster, so damage can quietly accumulate in several nightly backups before anyone notices. Restore the wrong one and you bring the damage back,…
What you'll learn
- explaining why 'restore the newest backup from before the ransom note' is the wrong default: encryption often starts quietly days before the loud night, so that snapshot already contains damaged files (6 of 16 in this lab)
- computing Shannon entropy (bits per byte, 0 to 8) in pure Python and knowing what it can and cannot tell you: random-looking data scores near 8, but so do PNGs, ZIPs, and legitimately encrypted files
- checking file signatures (magic bytes) -- the fixed first bytes that identify a format -- and using a mismatch between the extension and the signature as a far sharper corruption signal than entropy for formats that are compressed by design
- sampling entropy per 4096-byte block instead of per file, so a text file whose first block was overwritten (whole-file entropy 5.2-5.8, under any sane threshold) still stands out at 7.95+
- measuring per-snapshot change rate against a baseline median, and seeing that it screams on the loud night (100%) but stays under its spike threshold during the slow phase (31.2% vs 18.8% baseline)
- building a per-file restore plan (each file's newest version that passes every check) and quantifying how much newer, good work a whole-snapshot rollback throws away (6 files, 31 file-days here)
- naming the honest limits: header-preserving corruption of an already-compressed or encrypted file passes entropy and magic checks, backups themselves can be tampered with, and none of this proves root cause or that the attacker is gone
Steps in this lab
- The recovery question, and every term you need
- Why 'the newest backup before the ransom note' is a trap
- Generate 14 nights of synthetic backups
- Write the scanner: entropy, block sampling, magic bytes, change rate
- Measure the BEFORE: change rate and the naive restore point
- Entropy alone: false positives every night, and it still misses
- The full scanner: find the last clean restore point
- Per-file restore vs rolling the whole share back
- The honest negatives, measured
- When to use this, why it works, and how to do it better
- What you built, and the reflex to keep