Lion Cipher Lab
Catch shadow IT before an attacker does: track attack-surface drift with Amass
- Cyber / Security Engineer
- Advanced
- ~90 min of hands-on work, deliberately split across two sessions at least a few days apart (you cannot diff two runs taken ten minutes apart and learn anything)
- Free · no account required
Why it matters
Almost every breach post-mortem that starts with 'the internet-facing host nobody knew about' is a drift failure, not a patching failure. Somebody stood something up, it never reached the asset register, no scanner had it in scope, no owner watched it, and it sat there rotting until an attacker — who enumerates your namespace far more often than you do — found it first. Part 1 taught you to take a photograph of your attack surface. That photograph is out of date the moment you take it, and a 900-line report gets skimmed once and never read again. What actually changes outcomes is a short,…
What you'll learn
- persisting Amass results in the Asset Database instead of throwaway text files
- running a baseline enumeration and a later re-run against the same scope
- producing a defensible delta: assets that appeared, assets that disappeared
- using `amass track -since` to ask the database directly what is new
- normalising enumeration output so DNS ordering and casing cannot fake a change
- suppressing known-good churn (autoscaling hostnames, CDN edges) without hiding real findings
- a repeatable triage question set for every newly discovered asset
- chaining drift output into httpx and nuclei so a delta becomes prioritised work
- scheduling the whole thing as a cron/Task Scheduler routine with a stored baseline
- framing continuous discovery as CIS Control 1 / NIST CSF ID.AM rather than a hacking trick
Steps in this lab
- The idea in one sentence: a scan is a photograph, an attack surface is a river
- Ethics and scope: this only works on something you actually own
- Check your version FIRST — half the Amass advice online is for a CLI that no longer exists
- Where your results actually live: the Asset Database
- Session one: take the baseline
- Normalise before you store — or DNS will invent changes that never happened
- Session two, days later: run again and ask the database what is new
- The delta is the deliverable: a two-way diff you can hand to a human
- Do it better: suppress known-good churn so the signal survives contact with reality
- Triage: five questions you ask about every single new asset
- Turn the delta into work: hand new assets to httpx, then nuclei
- Make it a routine: schedule it, store the baseline, alert on the delta
- WHEN this pays for itself — and when it is premature
- The governance framing: this is an asset-inventory control, not a hacking trick
- What you actually learned