leviathan
9593d90385
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.
2.9 KiB
Ethics, scope, and acceptable use
Acceptable use
SKELETONKEY is intended for:
- Authorized red-team / pentest engagements. You have a written scope, signed by someone who can authorize testing on the target systems.
- Defensive teams testing detection coverage. You're using SKELETONKEY in a lab to verify your auditd/sigma/falco rules fire as expected.
- Security researchers studying historical LPEs. You're reading the code, running it in your own VMs, learning how the primitives actually work end-to-end.
- Build engineers verifying patch coverage. You're running
skeletonkey --scanagainst your fleet's golden images to confirm each known CVE shows up as patched.
Not-acceptable use
SKELETONKEY should not be used:
- On systems you do not own and have not been authorized to test
- As part of unauthorized access to any system
- To exfiltrate data or maintain persistence on a system after a testing engagement is complete
- To build a worm, scanner, or any tool that automatically targets systems at scale without per-target authorization
By using SKELETONKEY you assert that your use falls into the acceptable-use cases above.
Why this is publishable
Every CVE bundled in SKELETONKEY is:
- Already patched in upstream mainline kernel
- Already published in NVD or distro security trackers
- Already covered by existing public PoCs
SKELETONKEY does not introduce new offensive capability. It bundles, documents, and CI-tests what is already public — and ships the detection signatures defenders need to spot it.
The bundling itself raises the baseline competence required to benefit from this code: a script kiddie can already find and run single-CVE PoCs on GitHub. Bundling improves quality and CI coverage without meaningfully changing offensive capability, while providing real defensive value through the detection-rule exports.
Disclosure
If you find a bug in SKELETONKEY itself (incorrect detection, broken exploit on a kernel where it should work, missing a backport in the range metadata): file a public GitHub issue.
If you find a new 0-day kernel LPE while inspired by reading
SKELETONKEY code: please disclose it responsibly to the kernel
security team (security@kernel.org) and the affected distros
before writing a public PoC. Once upstream patch ships and a CVE
is assigned, SKELETONKEY will gladly accept the module.
Persistence and stealth are out of scope
--exploit-backdoor in the copy_fail module overwrites a
/etc/passwd line with a uid=0 shell account. This is overt:
- The username is
skeletonkey(wasdirtyfail) — instantly identifiable - It's covered by the auditd rules SKELETONKEY ships
--cleanup-backdoorrestores the original line
If you're looking for evasion, persistence, or stealth: not here. Use a real C2 framework if you have authorization to do so. SKELETONKEY stops at "demonstrate that the bug works."