[LINPEAS] Add privilege escalation check: HTB Watcher — From Zabbix CVE‑2024‑22120...

[carlospolop]

🔧 Automated Privilege Escalation Check Addition

🤔 Privilege Escalation Reasoning

The post’s ultimate local privilege escalation comes from abusing a locally bound TeamCity instance where both the server and build agents run as root. With admin access to TeamCity, an attacker can create a build configuration with a command-line step to execute arbitrary commands as root on the agent, yielding full system compromise. This is a realistic and commonly observed misconfiguration (CI/CD services running as root) rather than a CTF-only artifact. While the initial Zabbix CVE‑2024‑22120 is remote/web exploitation and not suitable for linpeas, the detection of a locally listening TeamCity service and agents running as root is a solid privesc indicator linpeas can flag. The additional steps in the blog (credential capture by patching PHP) are CTF-specific and should be ignored for automation, but the generic check "TeamCity detected and running as root" is broadly useful.

🤖 Implementation Details

PEASS linpeas agent completed successfully with 116 items. Agent Comment: Work summary
I analyzed the technique in the HTB Watcher write‑up and extracted the part that is relevant for local privilege escalation in Linux hosts: a locally bound TeamCity server/agent running as root. With TeamCity admin access (which can be obtained through many paths, including the blog’s Zabbix chain), an attacker can create a “Command Line” build step and execute arbitrary commands as root on the local agent. This is a realistic, common misconfiguration in CI/CD and worth adding to linpeas. The Zabbix CVE chain itself is remote/web exploitation and out of scope for linpeas.

What I checked first (and why a change was needed)

• Searched the repo for any existing TeamCity checks: none present.
• Verified there are no generic CI/CD checks that already flag TeamCity specifically or highlight “agent running as root” risk. Only GitLab, Splunk and other software have bespoke modules.
  Conclusion: It’s not covered, and the TeamCity misconfiguration is common enough to add.

What I implemented

1. New linpeas module to detect TeamCity and privilege context

• File added: linPEAS/builder/linpeas_parts/7_software_information/TeamCity.sh
• Module metadata:
  • Title: Software Information - TeamCity (JetBrains)
  • ID: SI_TeamCity
  • Author: HT Bot
  • Last Update: 09-10-2025
  • Description: Detect TeamCity server/agents, listeners and risky privilege context
  • License: GNU GPL
  • Version: 1.0
  • Functions Used: print_2title, print_3title, print_info
  • Fat linpeas: 0, Small linpeas: 1
• Detection logic:
  • Only runs if any of the following hints exist:
    • Found TeamCity‑related paths via storage list ($PSTORAGE_TEAMCITY)
    • TeamCity processes seen (ps | grep -Ei 'teamcity|buildAgent|jetbrains.buildServer.agent|TeamCityMavenServer')
    • Listener on default TeamCity HTTP port 8111 (ss/netstat)
    • DEBUG is set
  • Shows:
    • Processes for server/agents with “root” highlighted in red.
    • Listeners on :8111 using ss (or falls back to netstat). Local bind (127.0.0.1) in blue; 0.0.0.0/:: in green.
    • A small HTTP fingerprint (curl -I 127.0.0.1:8111) highlighting TeamCity/JetBrains in green if available.
    • If $PSTORAGE_TEAMCITY contains paths:
      • Tries to read, when readable, the common config files and prints a few safe, useful lines:
        • conf/teamcity-startup.properties → ownPort, contextPath
        • config/database.properties → user/password/url (keywords colored and minimized)
        • buildAgent/conf/buildAgent.properties → serverUrl/authorizationToken/name
    • If any TeamCity server/agent process is owned by root, prints a high‑severity warning:
      • “TeamCity server/agent running as root detected. With TeamCity admin access, you can create a ‘Command Line’ build step to execute arbitrary commands as root on the agent (high risk).”
      • Also prints a short tip about SSH port‑forwarding when bound to 127.0.0.1.
• Performance and compatibility:
  • Uses light commands only (ps, ss/netstat, curl if available).
  • Avoids heavy filesystem scans in the code; leverages the standard storage list for file locations.
  • Works without curl (HTTP fingerprint is optional).
  • Uses standard coloring and helper functions already present in linpeas.

2. Added TeamCity file patterns to the storage list (for quick, safe file discovery)

• File modified: build_lists/sensitive_files.yaml
• New section appended:
  • name: TeamCity
  • config: auto_check: False (so the YAML won’t auto‑print content; the custom module handles the output)
  • files searched (in common locations such as /opt, /var, /srv, etc. per existing logic):
    • Directories: TeamCity, buildAgent
    • Files: teamcity-startup.properties, buildAgent.properties, database.properties
• This provides $PSTORAGE_TEAMCITY for the module to reference without introducing slow “find /” searches.

How the detection works (step by step)

• Processes: ps axo user,pid,comm,args | grep -Ei 'teamcity|buildAgent|jetbrains.buildServer.agent|TeamCityMavenServer'
  • Highlights root; if root detected → prints a high‑risk escalation note.
• Listeners: ss -lntp | grep -E ':8111 .*LISTEN' (or netstat fallback)
  • Colors 127.0.0.1 (local bind) blue, 0.0.0.0/:: green.
  • Optional curl -I 127.0.0.1:8111 header fingerprint to spot “TeamCity/JetBrains”.
• Configs: From $PSTORAGE_TEAMCITY, tries to read standard TeamCity files and prints only a few relevant keys to guide manual escalation (no noisy dumps).

Why this addresses the blog’s privesc path

• On Watcher, TeamCity server and agents run as root and are bound to loopback.
• The new module flags exactly that: TeamCity presence, local listening 8111, and processes running as root, and advises the standard “Command Line” build step → root execution path.
• It also suggests local port‑forwarding, which is the practical way to reach the TeamCity UI when it’s loopback‑only.

Documentation update

• The module header includes complete metadata per PEASS standards (so it is properly built).
• No separate README updates were necessary.

Validation and quality checks

• Bash syntax validation: bash -n on TeamCity.sh returned 0 (no syntax errors).
• Functions used are declared and available in linpeas (print_2title, print_3title, print_info).
• Storage variable ($PSTORAGE_TEAMCITY) is generated by the updated sensitive_files.yaml section; auto_check is False to avoid duplicate auto-sections.
• The check is lightweight and compatible (uses ps/ss/curl/netstat only, with fallbacks).
• It won’t run unnecessarily: it requires one of the quick indicators (storage hit, process hit, or listener hit) or DEBUG.

Files changed/added

• Added: linPEAS/builder/linpeas_parts/7_software_information/TeamCity.sh
• Modified: build_lists/sensitive_files.yaml (appended “TeamCity” search section)

Final note
I explicitly did not add Zabbix CVE checks, credential‑stealing patch logic, or other CTF‑specific elements. The module focuses on the generally applicable, realistic misconfiguration highlighted by the post: TeamCity server/agents running as root and reachable locally, which is a strong privesc indicator for linpeas to flag.

🏗️ Builder Agent Response

LinPEAS build agent completed successfully with 20 items. Agent Comment: Done.

What I did:

• Navigated to /tmp/hacktricks_update_ol2ovq4v/repo/linPEAS/builder.
• Ran the build as requested: python3 -m builder.linpeas_builder --all --output /tmp/linpeas_fat.sh
• The build completed successfully with no errors. External tools and regex lists were fetched, sanity checks passed, and the final script was written.
• Verified artifact: /tmp/linpeas_fat.sh exists and is executable (size ~16.5 MB). The header shows the expected linPEAS script content.

No fixes were necessary because the build worked on the first attempt. If you want me to also produce a non-fat or small build, say the word and I’ll run those too.

---

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