Index

Scanning and Enumeration
Exploitation
Lateral Movement
Privilege Escalation

Scanning and Enumeration

nmap -p- -T4 --open -n -Pn 10.10.10.224 -oN nmap/scan

First of all the domain “REALCORP.HTB” was added to /etc/hosts.

When visiting the web site, an error related to SSL appears.

In the error message you we see the email address “j.nakazawa@realcorp.htb” and the subdomain “srv01.realcorp.htb”. I added that subdomain to the /etc/hosts file.

The DNS is searched for interesting records, where an IP different from that of the target host is observed.

ns.realcorp.htb 10.197.243.77

A subdomain brute force was also performed, where the domains “proxy” and “wpad” were found.

dnsenum --dnsserver 10.10.10.224 --threads 50 -f /usr/share/SecLists/Discovery/DNS/subdomains-top1million-5000.txt realcorp.htb

The following subdomains where added to the /etc/hosts file:

10.197.243.77 ns.realcorp.htb proxy.realcorp.htb
10.197.243.31 wpad.realcorp.htb

Since there is a Squid Proxy serving on port 3128, it would be interesting to see if it is possible to connect to this discovered IP through the proxy using proxychains. For this, the /etc/proxychains.conf file is configured to add the proxy.

Now we can try to use Nmap to find open ports on the discovered IP.

proxychains nmap -sT -Pn -n -v 127.0.0.1

SquidProxy has internal interfaces, so we can take advantage of them to potentially reach other internal hosts. For this, the internal HTTP proxy is also added to the list of proxies in the proxychains.conf file.

Now when scanning with Nmap to the IP, it is observed that it jumps directly to the discovered IP.

proxychains nmap -sT -Pn -n -v 10.197.243.77

A scan to IP 10.197.243.31 was attempted, without success.

Seeing that host 10.197.243.77 has port 3128 open, you could try to include it in the proxy list to try to reach host 10.197.243.31. For this, the following configuration was made in the proxychains.conf file

Now scanning again the host 10.197.243.31, we found some interesting ports open.

Seeing that port 80 is open, I do a curl to see its content.

Researching WPAD, HackTricks tells us the following:

WPAD
Many browsers use Web Proxy Auto-Discovery (WPAD) to load proxy settings from the network. A WPAD server provides client proxy settings via a particular URL (e.g., http://wpad.example.org/wpad.dat) upon being identified through any of the following:
DHCP, using a code 252 entry

DNS, searching for the wpad hostname in the local domain

    Microsoft LLMNR and NBT-NS (in the event of DNS lookup failure)

Responder automates the WPAD attack—running a proxy and directing clients to a malicious WPAD server via DHCP, DNS, LLMNR, and NBT-NS.

With this in mind, I search for the wpad.dat file, and find it.

The output shows a new network segment, corresponding to 10.241.251.0/24. With this in mind, I use the following script to discover hosts based on common open ports.

#!/bin/bash
 
for port in 21 22 25 80 88 443 445 8080 8081 3128; do
    for i in $(seq 1 254); do
        proxychains -q timeout 2 bash -c "echo '' > /dev/tcp/10.241.251.$i/$port" 2>/dev/null && echo "[+] 10.241.251.$i:$port OPEN" &
    done; wait
done

We found the following hosts and ports opened:

10.241.251.1
- 22 SSH
- 88 Kerberos-sec
- 3128 Squid Proxy

10.241.251.113
- 25 SMTP

At first sight, the most interesting thing would be to go for the SMTP service of the host 10.241.251.113. For this, I scan it with Nmap with its basic recognition scripts.

Here the domain smtp.realcorp.htb is discovered and the service running is OpenSMTPD 2.0.0, for which the following vulnerabilities were found:

Exploitation

Unfortunately, when trying to run the script it does not work as expected. This may be due to the user configured in the script not working. Recalling the start of the exercise, an email had been found. It would be interesting to test if this user is valid.

proxychains python3 47984.py 10.241.251.113 25 ls

We were able to execute commands correctly from the main target. At this point, I will set up a reverse shell.

Lateral Movement

The shell is stabilized and the environment is enumerated.

A non-conventional directory “.msmtprc” is observed, where plain text credentials were found.

j.nakazawa
sJB}RM>6Z~64_

An attempt was made to use these credentials to connect via SSH, without success. Seeing the error message, it is suspected that additional information is needed.

With the “-v” parameter we can see verbose information.

The debug mode indicates that Kerberos credentials are required to authenticate. This could be done in the following way:

Once KRB5 is configured, we modify the /etc/krb5.conf file as follows:

Now the authentication must be initialized and we will obtain the desired temporary cache file.

After obtaining the ticket cache file, in our SSH configuration file (/etc/ssh/sshd_config) we set the following settings:

An important detail for this to work is to leave only the subdomain srv01.realcorp.htb in the /etc/hosts file, as follows:

Once this is done, we will be able to connect via SSH without any problems.

Privilege Escalation

Enumerating the system, I find the folder /home/admin and also a cronjob that runs a script periodically.

Analyzing the content of the script, I see that rsync is used to copy all the content of /var/log/squid to /home/admin.

To abuse this script, taking advantage of the availability of Kerberos authentication, a text file will be created with the user name “j.nakazawa@REALCORP.HTB” and saved in a file named “.k5login”, to finally copy it to /var/log/squid.

If everything works correctly, the .k5login file will be copied to /home/admin, which will allow us to connect via SSH as the admin user to the target.