privilege-escalation-audit

What this is for

This is the defender's version of the attacker's first hour on a box: enumerate every way a local user could become root, so they can be closed. It is discovery, and discovery is read-only — nothing here escalates anything. When it finds a path, the fix is stated and confirmed before it runs, because tightening sudo or a permission is exactly where you lock the legitimate user out too.

Scope is the machine you are on or hosts a person named (ssh_exec). The trail is what makes this an audit: every find is on the action log, which is what distinguishes enumerating your own host from probing someone else's.

The enumeration — all read-only

• SUID / SGID: run_command "find / -perm -4000 -o -perm -2000 -type f 2>/dev/null". Run as a job if it drags. Compare against a known-good baseline — a SUID binary that should not be one (a shell, an interpreter, a text editor) is the finding.
• sudo rules: run_command "sudo -l" for the current user; read_file /etc/sudoers and list_directory /etc/sudoers.d. NOPASSWD on anything that can spawn a shell or write a file, and any wildcard, is a path.
• Capabilities: run_command "getcap -r / 2>/dev/null". cap_setuid, cap_dac_override and friends on an unexpected binary are SUID by another name.
• Writable units and timers: service files, cron, and systemd timers a non-root user can edit run as whoever the unit runs as. run_command "find /etc/systemd /etc/cron* -writable -type f 2>/dev/null".
• PATH and wrappers: a writable directory early on root's PATH, or a writable script a root job calls, is game over. Check the crontabs and the service ExecStarts for scripts, then the permissions on those scripts.
• World-writable in sensitive trees, unowned files, weak ~/.ssh perms, and /etc/passwd//etc/shadow writability.
• Versions with known local exploits: run_command "uname -a", the libc and sudo versions. A version number is a finding to report, not a thing to exploit — name it and let a person decide.

Remediating — the same lock-out warning as any hardening

Each finding gets: what it is, how it would be used, the fix, and what the fix might break. Removing a SUID bit, tightening a sudo rule, or fixing a service file permission can stop something legitimate that quietly depended on it — say so, and use ask_human when the trade-off is the person's to make. Re-run the matching enumeration after each fix and show it is closed.

The line this skill does not cross

Enumerate and report; do not run an exploit to "prove" a path, on this or any host. A version number, a writable file, a loose sudo rule — those are the evidence, and they are enough. Actually escalating leaves a different kind of trace and answers a question nobody asked. If a person wants a proof-of-concept, that is their explicit call to make, on a host they own, said out loud — not an assumption this skill makes for them.