Cascade- Medium
Last updated
Last updated
The "Cascade" machine on is categorized as an Medium-level target. It's ideal to
Our initial step involved verifying connectivity with a ping test. This helps determine if we can reach the target machine and provides information such as the Time to Live (TTL) value, which can help us identify the operating system. Typically, a TTL of 64 suggests a Linux system, and a TTL of 128 or less indicates a Windows machine.
Following this initial check, we proceeded with a SYN TCP port scan against all ports. We used flags such as -Pn
and -n
, along with setting a minimum rate of 5000 packets per second, to expedite the scan.
Once we identified all the open ports on the target, we conducted a second scan using the -sVC
flags. This scan was aimed at retrieving detailed information such as service versions and other relevant data that would be crucial for our enumeration phase.
As you can see, several ports indicative of a domain controller are open, including port 88 for Kerberos, 445 for SMB, 389 for LDAP, and 135 for RPC. This is crucial information because it allows us to leverage various tools tailored to these protocols. Tools such as kerbrute
for testing Kerberos authentication, ldapsearch
for querying LDAP services, smbmap
for SMB server enumeration, and crackmapexec
for assessing the security of network services can be used to gather comprehensive information about the domain.
The first port we chose to enumerate was SMB, as our goal was to identify any accessible shares on the network and the domain name, which we planned to add to the /etc/hosts
file. To achieve this, we utilized crackmapexec
to gather the necessary information. However, for reasons unknown, crackmapexec
did not yield any results. Consequently, we decided to proceed with the enumeration of the remaining ports.
As we mentioned the crackmapexec appears not to work without credentials. So, we started enumerate RCP port using rpcclient using a null in order to enumerate potentials users on the domain. Usually we use the following one-liner to extract the users list.
After obtaining the list of users, one effective strategy is to check for valid credentials using kerbrute
. We recommend this approach because, while kerbrute
validates the users, it also checks to see if any user is vulnerable to ASREPRoast. This dual-functionality makes kerbrute
particularly useful in both verifying user accounts and enhancing security assessments by identifying specific vulnerabilities.
Continuing with our enumeration, we used ldapsearch
to gather additional information which could aid in gaining initial access to the system or identifying potential attack vectors for further enumeration. By filtering results by userPrincipalName
, we discovered an uncommon field for the user r.thompson
, which appears to contain a Base64 encoded password. This finding is particularly significant as decoding this encoded string may provide direct credentials for accessing other system resources or escalating privileges within the network. Here's how to proceed:
Using the decoded credentials, we progressed further in our enumeration efforts. With these credentials, we gained access to SMB shares which housed several files. Among these, the most noteworthy discovery was in the IT/Temp/s.smith/VNC
directory, where we found a VNC log containing an encrypted password.
To decode the encrypted password found in the VNC log, we followed a systematic approach. We initially leveraged the VNCpwd tool, which is specifically designed to decode passwords encrypted by TightVNC using a known static key. Here are the steps involved:
Clone and Build VNCpwd: We started by cloning the VNCpwd repository and compiling the tool:
Prepare the Encrypted Password: Next, we extracted the encrypted password from the VNC log and prepared it for decryption:
Decrypt the Password: Using the compiled VNCpwd tool, we decrypted the password:
Validate the Decrypted Password: With the decrypted password in hand, we validated it against the SMB service using Crackmapexec to ensure it provided access:
This step confirmed that the decrypted credentials were valid and provided access to additional network resources.
Access SMB Shares: Armed with valid credentials, we accessed the relevant SMB shares to retrieve critical files:
After successfully downloading files from the SMB share, we proceeded to inspect the source code of various executables and libraries found within these shares. To accomplish this, we used tools like dotPeek
to examine the compiled .NET assemblies for any hardcoded keys or additional credentials that might be exploited for deeper access.
During our inspection, we focused on the MailModule
of an application where the code revealed intriguing elements:
.