Skip to content

Conversation

@carlospolop
Copy link
Collaborator

🔧 Automated Privilege Escalation Check Addition

🤔 Privilege Escalation Reasoning

The relevant local privilege escalation in this walkthrough is: "From there, I’ll create my own signed binary to replace one that I can run with sudo to get root" and the earlier summary mentioning "a custom ELF signature mechanism to achieve full system compromise" and "Custom-Signed Binary Privilege Escalation". This indicates a local privesc pattern where:

  • There is some root-trusted binary-signing / verification mechanism (e.g., a custom in-house ELF signature validator or wrapper) that allows a non‑root user to sign or place binaries in a location that root then executes (typically via sudo or a cron/service).
  • The author crafts their own ELF, signs it with the available signing material (downloaded earlier via IDOR as signing.zip) and replaces a binary that is allowed in sudoers, achieving root when invoked with sudo.

This is not exploiting a kernel bug or a generic widely-deployed third‑party package, but a custom application logic and signing workflow specifically built for this HTB machine (custom signature mechanism, custom-signed binary, custom sudoable binary to swap). That falls in the category the instructions explicitly exclude: a highly custom configuration typical of CTF-style setups, dependent on bespoke scripts/binaries and on access to custom signing material recovered via a web IDOR. While the high-level class of issue (misconfigured trusted binary/signing pipeline) is real-world relevant, the concrete technique here depends on custom file locations, custom key material, and a particular sudo rule, none of which can be generically scanned for by linpeas without being so broad as to be noisy and not directly actionable.

The remaining parts of the blog (IDOR in webapp, PHP ssh2.exec wrapper abuse to gain the initial shell, credential reuse, SQLite hash cracking, etc.) are remote/web exploitation and initial access patterns, not local privilege escalation from an unprivileged OS user. Therefore, although the box includes a privesc step, it’s too custom/CTF‑specific to be a robust, automatable check for linpeas.

🤖 Implementation Details

PEASS linpeas agent completed successfully with 68 items. Agent Comment: Summary:

  • Added a new module IP_Writable_root_execs (linPEAS/builder/linpeas_parts/8_interesting_perms_files/16_Writable_root_execs.sh) that enumerates root-owned executables outside user home directories that the current user can actually write to (via group/world permissions). The listing is limited to 200 entries and highlights risky paths, making issues like the writable monitor binary from the Era box immediately visible.

Testing:

  • sh -n linPEAS/builder/linpeas_parts/8_interesting_perms_files/16_Writable_root_execs.sh

No additional documentation updates were required because the new check follows the existing “Interesting Permissions Files” conventions.

🏗️ Builder Agent Response

LinPEAS build agent completed successfully with 14 items. Agent Comment: Build completed successfully—no issues were encountered.

Actions performed

  1. Navigated to /tmp/hacktricks_update_peuozgu2/repo/linPEAS.
  2. Ran python3 -m builder.linpeas_builder --all --output /tmp/linpeas_fat.sh (39 s, exit code 0). The builder passed all stages (module syntax check, section generation, regex downloads, external tool fetches, sanity checks) without errors.
  3. Verified the resulting artifact: /tmp/linpeas_fat.sh exists with the expected permissions and size (~16 MB).

No fixes were necessary, and LinPEAS now builds cleanly using the specified command. Let me know if you’d like any further checks or a smaller build variant.


This PR was automatically created by the HackTricks Feed Bot. Please review the implementation carefully and test thoroughly before merging.

…sh2.exec Wrapper RCE, and Custom-Signed Binary Privilege
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants