Loot CLI — Filesystem Recon for CTFs and Post-Exploitation

Walk a target once. Catch everything worth catching.

The Goal

After landing a shell — on a CTF box, a pentest engagement, or an internal audit — the next step is always the same: figure out what's on the filesystem that shouldn't be readable. .env files, private keys, SUID binaries, shell history, KeePass databases, hardcoded tokens buried in source. Doing that manually is slow and inconsistent.

I wanted a single command that could sweep an arbitrary root path, classify every interesting file with a severity level, map each finding to the appropriate MITRE ATT&CK technique, and output either a human-readable report or clean JSON for piping into other tools.

The constraint I kept front of mind: read-only. The tool never writes, never modifies, never executes anything it finds.

How It Works

The core design choice was a single-pass walk. scan_tree() calls walk() once to build the full path list, then dispatches that same list to every enabled scanner. No scanner re-traverses the tree independently.

loot-cli /home/user --severity high
loot-cli /mnt/usb --json
loot-cli /var/www --scanners filenames,strings

Each scanner yields Finding objects — a dataclass carrying category, severity, path, detail string, optional line number and snippet, and a tuple of MITRE technique IDs. The orchestrator collects, deduplicates, and sorts them by severity before rendering output.

Exit codes are CI-friendly: 0 for clean, 1 for LOW/MEDIUM, 2 for at least one HIGH, 3 for at least one CRITICAL. That makes it trivial to fail a build or alert pipeline on a real finding.

Capabilities

Eight scanners, each targeting a different class of finding:

Severity runs from INFO through LOW, MEDIUM, HIGH, and CRITICAL. An id_rsa is CRITICAL; a .db file is LOW; a SUID binary is HIGH.

The string scanner reads up to 1 MiB per file and skips anything that looks binary in the first 4 KB, keeping it fast enough for real engagement use without choking on large media directories.

Default-pruned directories (proc, sys, dev, node_modules, .venv, __pycache__, etc.) avoid the noise of virtual filesystems and build artifacts without requiring any configuration.

MITRE ATT&CK mapping is baked in at the pattern level, not applied after the fact:

Tech & Tools

• Python 3.10–3.12 — type-annotated throughout, dataclasses for Finding and Severity
• pathlib.Path for all filesystem operations
• os.stat / stat module for permission and ownership checks
• re for string pattern matching against token and credential patterns
• fnmatch for glob-based filename matching across the pattern table
• Structured JSON output suitable for ingestion by Splunk, Elastic, or any log pipeline
• pytest test suite covering each scanner independently with synthetic fixture trees

What I Learned

Single-pass architecture matters more than I expected. When I initially prototyped separate walkers per scanner, scanning a deep home directory was visibly slow — repeated os.walk calls against spinning disk added up fast. Collecting paths once and dispatching to functions changed the feel entirely.

The severity-as-exit-code pattern is underused. Most security tools exit 0 on completion and leave severity parsing to whoever reads the output. Mapping severity tiers directly to exit codes made the tool immediately composable in shell scripts and CI pipelines without any extra glue.

Pattern tables are easier to maintain than scattered if-chains. The filename scanner is driven by a single list of (glob, severity, description, mitre_ids) tuples. Adding a new dangerous filename means adding one line to that list, not finding the right place in a conditional tree. Same pattern in the string scanner for token regexes.

Deciding what to prune is as important as deciding what to scan. Early runs against a developer's home directory returned hundreds of false positives from .venv and node_modules. Defining a sensible default prune list — and making it overridable — was necessary before the tool was usable in practice.

The project pairs with vault-scan, which does the same kind of sweep through git commit history. loot-cli finds repos on disk; vault-scan rakes what got committed to them.