HTB | Cerberus

Machine - https://app.hackthebox.com/machines/Cerberus

IP - 10.10.11.205

NMAP

└─$ nmap -sC -sV -p 8080 10.10.11.205 -Pn -oA nmap_port_details                                                                 
Starting Nmap 7.95 ( <https://nmap.org> ) at 2025-08-13 12:31 IST
Nmap scan report for 10.10.11.205
Host is up (0.30s latency).

PORT     STATE SERVICE VERSION
8080/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))
|_http-title: Did not follow redirect to <http://icinga.cerberus.local:8080/icingaweb2>
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: Apache/2.4.52 (Ubuntu)

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

Port 8080

Nothing was found on dirsearch

But we found alot of 302 when fuzzing /icingaweb2

Foothold/shell

Shell as www-data on icinga

Arbitrary File Disclosure (CVE-2022-24716)

Also, when looking for known vulnerabilities, we found RCE

But that RCE required a valid username and password

But Arbitrary File Disclosure worked

we cannot upload files, so i started looking around

Here we can see 172.16.22.1 pointing to DC and this IP is probably some internal IP (maybe containerization/virtualization, or we need to do some pivoting?)

Getting cred of matthew via Doc

Since we cannot do anything, let’s look for configuration files (reference - Icinga Web Doc )

The user preferences are stored in the database resource db

From resources.ini we got the credentail for matthew

from this we can login

CVE-2022-24715

Public POCs did not work for me

Refer - https://www.sonarsource.com/blog/path-traversal-vulnerabilities-in-icinga-web/#remote-code-execution-cve202224715

Since we did not find any Public POC to work, we can go for the manual method

But first, we need to create a PEM file

Now we will go to Application - > Resources and create a new resource

Let’s put SSH key there and save

and we can validate the file upload via LFI

Now let’s try to get shell

But for that we need to find a way to run php or bash but since it only takes SSH keys that will not be easy

But from the sonar article, we can put a null byte and trick it into running PHP

Now let’s try to run a PHP cmd

(I was not able to make it work, shoutout to 0xdf and ippsec because of there writeup i was able to make it work)

For that, we will use configuration.php

nd then we will change the module path to

then when we visit the module and click on test module which we have created we can see the response

Now it’s time to get revshell

and when we click on module test2 we will get the shell

Shell as root on Icinga

When looking for SUID, we found something interseting firejail

Firejail escape

On looking for the vulnerability for firejail We found this

Now we have to get another shell and run this, and we are root

Shell as Matthew on Cerberus

We have seen the internal IP for DC We can confirm this by simple ping sweep

Let’s copy nmap and run it

Sweet WinRM is open

sssd

SSSD (System Security Services Daemon) provides a set of daemons to manage access to remote directory services and authentication mechanisms.

There are a few files in the db directory. Running strings on cache_cerberus.local.ldb returns a bunch of data, including references to the matthew user and some hashes:

Let’s crack the hash

Let’s set up ligolo-ng for pivoting (refer to this)

And we can ping DC

Now we can WinRM and get the user.txt

Privilege Escalation

Shell as ?

Backup file on ADSelf

We found a backup file in ADSelfService Plus

Let’s download and analyse

Both files are password protected zip

On this show the default password should be Default password: This is the reverse string of the filename. For the filename mentioned above, the password would be: 7451-422180.

Let’s try it out

Since we can list the files on OfflineBackup_20230214064809

found a hash.txt

Let’s crack 'em

Now I need to find the user for it. Unfortunately, no user matched the password

After that, I thought to look for open ports

but strangely, we found all the ports in an ignored state, but we know winrm port is open (maybe the firewall or some filtering is there?)

After doing some digging I found out Why WinRM Works Only via Linux Jump Host (172.16.22.2)

Finding

  • Windows Firewall inbound rules for WinRM (TCP 5985) explicitly allow connections only from 172.16.22.2/32.

  • The generic Allow Ports rule does allow 172.16.22.1 and 172.16.22.2, but it does not include port 5985 in its LocalPort list.

  • Result:

    • From attacker host directly → source IP not allowed for WinRM → packet silently dropped (filtered in Nmap).

    • From Linux jump host (172.16.22.2) via Ligolo-ng → source IP matches allowed rule → WinRM connection succeeds.

Scripts Used

1. firewall_rule.ps1 – Display all rules with key fields:

Output excerpt:

2. Remote_IP_restriction.ps1 – List only rules with RemoteIP restrictions:

Output excerpt:

3. Detailed check of Allow Ports rule:

Output excerpt:

No 5985 in the LocalPort list → rule does not apply to WinRM.

Conclusion

  • WinRM access is hard restricted to the Linux jump host’s IP (172.16.22.2).

  • Generic allow rule for 172.16.22.1 doesn’t help because 5985 is excluded.

  • Pivoting through 172.16.22.2 is the only way to reach WinRM.

Double Pivot to access all ports

We need to put Ligoglo-ng agent on Windows server as well, because right now:

  • My Kali → Linux pivot (172.16.22.2) → Windows server

  • Windows firewall limits WinRM to only 172.16.22.2, so it works, but other ports may be restricted to other IPs or LocalSubnet.

  • From Kali, our Nmap scans are limited to what 172.16.22.2 is allowed to see.

So if I double Pivot

Double Pivot

Since Kali already knows 172.16.22.0/28 via first tunnel, but the /32 route to 172.16.22.1 will override it in the routing table.

This forces all DC traffic to go via the second tunnel → direct access from DC’s perspective → bypasses the firewall that blocks your Kali IP.

cve_2022_47966

we can see internal port 9251

but my nmap result says it’s filtered but nc says otherwise

We can see adself sign in page

we can see there is unauthenticated RCE for Build prior to 6003

and in our case, build is 6210

we found the exploit exploit/multi/http/manageengine_adselfservice_plus_saml_rce_cve_2022_47966

We need a GUID, and for that

there are two ways

  1. The URL above does have useful information. The two parameters passed are SAMLRequest and RelayState. Both appear to be URL encoded base64.

    If I URL decode the SAMLRequest (online tools like urldecoder.org or Burp Decoder will work), and then pass them to a SAML decoder such as this one on samltool.com, it generates XML:

  2. login as Matthew, and it will redirect you to https://dc:9251/samlLogin/67a8d101690402dc6a6744b8fc8a7ca1acf88b2f

Now We need to get the ISSUER_URL from the offline backup

and we get the shell on msf

Redo pivot with Chisel

I’ll redo the pivot with chisel

on ichinga linux

on kali

we get windoows shell

for double pivoit I will upload the chisel to windows and

on kali

Now i can visit https://127.0.0.1:9251 with FoxyProxy to tunnel Firefox over 1080

Now let’s try again with msfconsole

I think the issue was with the payload

and we found root.txt

PreviousFlight | HTBNextHTB | BoardLight

Last updated