main
4 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 leviathan
|
ee3e7dd9a7 |
skeletonkey: --explain MODULE — single-page operator briefing
One command that answers 'should we worry about this CVE here,
what would patch it, and what would the SOC see if someone tried
it'. Renders, for the specified module:
- Header: name + CVE + summary
- WEAKNESS: CWE id and MITRE ATT&CK technique (from CVE metadata)
- THREAT INTEL: CISA KEV status (with date_added if listed) and
the upstream-curated kernel_range
- HOST FINGERPRINT: kernel + arch + distro from ctx->host plus
every relevant capability gate (userns / apparmor / selinux /
lockdown)
- DETECT() TRACE (live): runs the module's detect() with verbose
stderr enabled so the operator sees the gates fire in real
time — 'kernel X is patched', 'userns blocked by AppArmor',
'no readable setuid binary', etc.
- VERDICT: the result_t with a one-line operator interpretation
that varies by outcome (OK / VULNERABLE / PRECOND_FAIL /
TEST_ERROR each get their own framing)
- OPSEC FOOTPRINT: word-wrapped .opsec_notes paragraph (from
last commit) showing what an exploit would leave behind on
this host
- DETECTION COVERAGE: which of auditd/sigma/yara/falco have
embedded rules for this module, with pointers to the
--module-info / --detect-rules commands that dump the bodies
Targeted at every audience the project is meant to serve:
- Red team: opsec footprint + 'would this even reach' verdict
in one screen
- Blue team: paste-ready triage ticket with CVE / CWE / ATT&CK /
KEV header and detection-coverage matrix
- Researchers: the live trace shows the reasoning chain
(predates check, kernel_range_is_patched lookup, userns gate)
that drove the verdict — auditable without reading source
- SOC analysts / students: a single self-contained briefing per
CVE, no cross-referencing needed
Implementation:
- New mode MODE_EXPLAIN, new flag --explain MODULE
- cmd_explain() composes the page from the existing module
struct, cve_metadata_lookup() (federal-source triage data),
ctx->host (cached fingerprint), and a live detect() call
- print_wrapped() helper word-wraps the long .opsec_notes
paragraph at 76 cols / 2-space indent
- Help text + README quickstart + DETECTION_PLAYBOOK single-host
recipe all updated to mention --explain
Smoke tests:
- macOS: --explain nf_tables shows full briefing; trace says
'Linux-only module — not applicable here'; verdict
PRECOND_FAIL with the generic-precondition interpretation
- Linux (docker gcc:latest): --explain nf_tables on a 6.12 host
fires '[+] nf_tables: kernel 6.12.76-linuxkit is patched';
verdict OK with the 'this host is patched' interpretation
- Both: --explain nope (unknown module) returns 1 with a clear
'no module ... Try --list' error
- Both: 87 tests still pass (33 kernel_range + 54 detect on Linux,
33 + 0 stubbed on macOS)
Closes the metadata + opsec + explain trio. The three together
answer the 'best tool for red team, blue team, researchers, and
more' framing.
|
||
|
leviathan
|
8938a74d04 |
detection rules: YARA + Falco for the 6 highest-rank modules + playbook
Closes the 'rules in the box' gap — the README has claimed YARA + Falco coverage but detect_yara and detect_falco were NULL on every module. This commit lights up both formats for the 6 highest-value modules (covering 10 of 31 registered modules via family-shared rules), and the existing operational playbook gains the format-specific deployment recipes + the cross-format correlation table. YARA rules (8 rules, 9 module-headers, 152 lines): - copy_fail_family — etc_passwd_uid_flip + etc_passwd_root_no_password (shared across copy_fail / copy_fail_gcm / dirty_frag_esp / dirty_frag_esp6 / dirty_frag_rxrpc) - dirty_pipe — passwd UID flip pattern, dirty-pipe-specific tag - dirtydecrypt — 28-byte ELF prefix match on tiny_elf[] + setuid+execve shellcode tail, detects the page-cache overlay landing - fragnesia — 28-byte ELF prefix on shell_elf[] + setuid+setgid+seteuid cascade, detects the 192-byte page-cache overlay - pwnkit — gconv-modules cache file format (small text file with module UTF-8// X// /tmp/...) - pack2theroot — malicious .deb (ar archive + SUID-bash postinst) + /tmp/.suid_bash artifact scan Falco rules (13 rules, 9 module-headers, 219 lines): - pwnkit — pkexec with empty argv + GCONV_PATH/CHARSET env from non-root - copy_fail_family — AF_ALG socket from non-root + NETLINK_XFRM from unprivileged userns + /etc/passwd modified by non-root - dirty_pipe — splice() of setuid/credential file by non-root - dirtydecrypt — AF_RXRPC socket + add_key(rxrpc) by non-root - fragnesia — TCP_ULP=espintcp from non-root + splice of setuid binary - pack2theroot — SUID bit set on /tmp/.suid_bash + dpkg invoked by packagekitd with /tmp/.pk-*.deb + 2x InstallFiles on same transaction Wiring: each module's .detect_yara and .detect_falco struct fields now point at the embedded string. The dispatcher dedups by pointer, so family-shared rules emit once across the 5 sub-modules. docs/DETECTION_PLAYBOOK.md augmented (302 -> 456 lines): - New 'YARA artifact scanning' subsection under SIEM integration with scheduled-scan cron pattern + per-rule trigger table - New 'Falco runtime detection' subsection with deploy + per-rule trigger table - New 'Per-module detection coverage' table — 4-format matrix - New 'Correlation across formats' section — multi-format incident signature per exploit (the 3-of-4 signal pattern) - New 'Worked example: catching DirtyDecrypt end-to-end' walkthrough from Falco page through yara confirmation, recovery, hunt + patch The existing operational lifecycle / SIEM patterns / FP tuning content is preserved unchanged — this commit only adds. Final stats: - auditd: 109 rule statements across 27 modules - sigma: 16 sigma rules across 19 modules - yara: 8 yara rules across 9 module headers (5 family + 4 distinct) - falco: 13 falco rules across 9 module headers The remaining 21 modules can gain YARA / Falco coverage incrementally by populating their detect_yara / detect_falco struct fields. |
||
|
leviathan
|
9593d90385 |
rename: IAMROOT → SKELETONKEY across the entire project
Breaking change. Tool name, binary name, function/type names,
constant names, env vars, header guards, file paths, and GitHub
repo URL all rebrand IAMROOT → SKELETONKEY.
Changes:
- All "IAMROOT" → "SKELETONKEY" (constants, env vars, enum
values, docs, comments)
- All "iamroot" → "skeletonkey" (functions, types, paths, CLI)
- iamroot.c → skeletonkey.c
- modules/*/iamroot_modules.{c,h} → modules/*/skeletonkey_modules.{c,h}
- tools/iamroot-fleet-scan.sh → tools/skeletonkey-fleet-scan.sh
- Binary "iamroot" → "skeletonkey"
- GitHub URL KaraZajac/IAMROOT → KaraZajac/SKELETONKEY
- .gitignore now expects build output named "skeletonkey"
- /tmp/iamroot-* tmpfiles → /tmp/skeletonkey-*
- Env vars IAMROOT_MODPROBE_PATH etc. → SKELETONKEY_*
New ASCII skeleton-key banner (horizontal key icon + ANSI Shadow
SKELETONKEY block letters) replaces the IAMROOT banner in
skeletonkey.c and README.md.
VERSION: 0.3.1 → 0.4.0 (breaking).
Build clean on Debian 6.12.86. `skeletonkey --version` → 0.4.0.
All 24 modules still register; no functional code changes — pure
rename + banner refresh.
|
||
|
leviathan
|
ea5d021f0c |
tools/iamroot-fleet-scan.sh + docs/DETECTION_PLAYBOOK.md
iamroot-fleet-scan.sh — bash wrapper that scp's the iamroot binary to a host list, ssh-runs --scan --json on each, aggregates results into a single JSON document. Supports: - hosts list from file or stdin - user@host:port syntax - parallel xargs execution (default -P 4) - ssh key / extra ssh opts pass-through - --no-sudo for hosts where root isn't required - --summary-only to suppress per-host detail - --no-cleanup to leave the binary on disk Critical fix during smoke-test: iamroot's exit codes are SEMANTIC (0=OK, 2=VULNERABLE, 4=PRECOND_FAIL, 5=EXPLOIT_OK). The wrapper must NOT treat nonzero exit as a transport failure; success is defined by 'stdout contains valid JSON', failure by 'stdout empty'. Verified end-to-end on kctf-mgr → kctf-fuzz: fleet-scan reports ok=1, failed=0, summary.vulnerable groups by CVE: copy_fail_gcm, dirty_frag_esp×2, entrybleed. Per-host detail included. docs/DETECTION_PLAYBOOK.md — operational integration guide: - Lifecycle diagram (inventory → scan → fleet scan → deploy/mitigate/upgrade → monitor) - Recipes by team size: single host, small fleet, large fleet - SIEM integration patterns: Splunk, Elastic, Sigma - Auditd-event lookup commands per module key - VULNERABLE decision tree (patch vs mitigate vs compensate) - Mitigation revert procedures + side-effect table - False-positive tuning table per rule key - Pre-patch quarantine pattern - Maintenance contract / module-shipping SLA |