Skills Assessment - Password Attacks

The Credential Theft Shuffle

The Credential Theft Shuffle, as coined by Sean Metcalf, is a systematic approach attackers use to compromise Active Directory environments by exploiting stolen credentials. The process begins with gaining initial access, often through phishing, followed by obtaining local administrator privileges on a machine. Attackers then extract credentials from memory using tools like Mimikatz and leverage these credentials to move laterally across the network. Techniques such as pass-the-hash (PtH) and tools like NetExec facilitate this lateral movement and further credential harvesting. The ultimate goal is to escalate privileges and gain control over the domain, often by compromising Domain Admin accounts or performing DCSync attacks. Sean emphasizes the importance of implementing security measures such as the Local Administrator Password Solution (LAPS), enforcing multi-factor authentication, and restricting administrative privileges to mitigate such attacks.

Skills Assessment

Betty Jayde works at Nexura LLC. We know she uses the password Texas123!@# on multiple websites, and we believe she may reuse it at work. Infiltrate Nexura's network and gain command execution on the domain controller. The following hosts are in-scope for this assessment:

Pivoting Primer

The internal hosts (JUMP01, FILE01, DC01) reside on a private subnet that is not directly accessible from our attack host. The only externally reachable system is DMZ01, which has a second interface connected to the internal network. This segmentation reflects a classic DMZ setup, where public-facing services are isolated from internal infrastructure.

To access these internal systems, we must first gain a foothold on DMZ01. From there, we can pivot — that is, route our traffic through the compromised host into the private network. This enables our tools to communicate with internal hosts as if they were directly accessible. After compromising the DMZ, refer to the module cheatsheet for the necessary commands to set up the pivot and continue your assessment.

Questions:

What is the NTLM hash of NEXURA\Administrator?

The Scenario: A Segmented Network and a Reused Password

The environment was set up with a classic DMZ (Demilitarized Zone) configuration. Our attack host had external access only to DMZ01 (10.129.X.X), which acted as a gateway to the internal network (172.16.119.0/24). The internal hosts included JUMP01, FILE01, and the prized DC01 (Domain Controller).

We had a crucial piece of initial intelligence: a user named Betty Jayde was known to reuse the password Texas123!@# across multiple websites, and we suspected she might use it at work. This would be our initial entry point.

Phase 1: Gaining a Foothold on the DMZ and Pivoting In

Our first objective was DMZ01 (10.129.234.116). We suspected Betty Jayde's password Texas123!@# might be reused. However, we first needed to confirm her username on the system.

  1. Username Enumeration with Username Anarchy: To confirm Betty Jayde’s username on the system, I utilized a tool called Username Anarchy. This allowed me to generate potential usernames based on common naming conventions (e.g., first initial + last name, first name + last initial).
  1. Brute-Forcing SSH with Hydra: With a list of potential usernames (which quickly identified jbetty as a valid user) and the suspected password, I turned to Hydra for a targeted SSH brute-force attack.
hydra -L user.txt -p 'Texas123!@#' ssh://10.129.234.116
  • What it does:
  • hydra: A powerful and fast network logon cracker that supports numerous protocols.
  • L user.txt: Specifies a list of usernames to try (in this case, the output from Username Anarchy which would have included jbetty).
  • p 'Texas123!@#': Provides the specific password to attempt for each username.
  • ssh://10.129.234.116: The target service and IP address (SSH on DMZ01).

Result: Hydra successfully authenticated, confirming jbetty and Texas123!@# as valid credentials for SSH access on DMZ01. This was our initial breach point.

Get Sau Rav’s stories in your inbox

Join Medium for free to get updates from this writer.

Subscribe

3. Establishing a SOCKS Proxy via SSH:

ssh -D 9050 jbetty@10.129.234.116
  • What it does: This command then established the SSH connection using the newly confirmed credentials. The D 9050 flag sets up a SOCKS proxy on our local machine (listening on port 9050). This proxy is absolutely crucial as it allows us to route all subsequent network traffic destined for the internal network through the compromised DMZ01 host. Without this pivot, our attack host wouldn't be able to "see" or interact with the internal systems.

4. Credential Discovery on DMZ01: Once logged into DMZ01, I immediately checked for sensitive information. A great starting point is a user's bash history, which often contains commands with credentials.

cat .bash_history
  • What it does: Displays the command history of the currently logged-in user. This quickly revealed another set of credentials: hwilliam with the password dealer-screwed-gym1. This was a jackpot for further lateral movement!

Phase 2: Internal Network Enumeration and Lateral Movement to FILE01

With our SOCKS proxy now active, we could finally map out the internal network. Identifying active hosts and open ports is a fundamental step in any red team assessment.

  1. Nmap Scanning through the Proxy: I used Nmap to perform a targeted port scan on the identified internal hosts, DC01 (172.16.119.11) and FILE01 (172.16.119.10), routing the traffic through our proxy.

Command (DC01 Scan):

proxychains nmap -sT -Pn --open --min-rate 10 -p 53,88,135,139,389,445,464,593,636,3268,3269,3389,5985 -oA dc01_scan_slow 172.16.119.11 proxychains nmap -sT -Pn --open --min-rate 10 -p 135,445,3389,5985 172.16.119.11

Command (FILE01 Scan):

proxychains nmap -sT -Pn --open --min-rate 10 -p 135,445,3389,5985 172.16.119.10
  • What it does:
  • proxychains: Routes the Nmap traffic through our SOCKS proxy.
  • nmap: The network mapper, used for host discovery and port scanning.
  • sT: Performs a TCP connect scan, which completes the full TCP three-way handshake. This is often necessary when scanning through a SOCKS proxy.
  • Pn: Treats all hosts as online, skipping host discovery (pinging). Useful when a firewall might block ICMP.
  • -open: Only shows ports that are in the "open" state.
  • -min-rate 10: Sets a minimum send rate to avoid being too noisy or getting blocked, especially when going through a proxy.
  • p ...: Specifies the list of ports to scan. These include common Active Directory services (LDAP, Kerberos, SMB), MSRPC, and RDP.
  • 172.16.119.11 and 172.16.119.10: The target internal IP addresses.

Scan Results Interpretation:

  • DC01 (172.16.119.11): Showed numerous open ports typical of a Domain Controller: 53 (DNS), 88 (Kerberos), 135 (MSRPC), 139 (NetBIOS), 389 (LDAP), 445 (SMB), 464 (Kerberos Password Change), 593 (DCOM), 636 (LDAPS), 3268/3269 (Global Catalog LDAP), 3389 (RDP), 5985 (WinRM/WSMan). This confirmed it was indeed the DC and offered many avenues for attack.
  • FILE01 (172.16.119.10): Showed 135 (MSRPC), 445 (SMB), 3389 (RDP), and 5985 (WinRM/WSMan) open. The open SMB (445) port was particularly interesting, pointing towards a file share.

2. Accessing FILE01 via SMB with Stolen Credentials: With hwilliam's credentials and the knowledge that SMB was open on FILE01, our next step was to explore its shares.

proxychains python3 /home/user/.local/pipx/venvs/impacket/bin/smbclient.py nexura.htb/hwilliam:'dealer-screwed-gym1'@172.16.119.10
  • What it does:
  • proxychains: Routes traffic through the SOCKS proxy.
  • smbclient.py: Impacket's SMB client to interact with shares.
  • nexura.htb/hwilliam:'dealer-screwed-gym1'@172.16.119.10: Specifies the domain, user, password, and target.
  • Result: We successfully connected to FILE01. A quick enumeration of shares (ls) revealed an HR share. Diving into HR and then Archive, we found a file named Employee-Passwords_OLD.psafe3. This looked incredibly promising – a password safe!

3. Extracting Hash from Password Safe:

python3 ./pwsafe2john.py /path/to/Employee-Passwords_OLD.psafe3 > psafe_hash.txt

Explanation:

  • pwsafe2john.py: A utility that extracts the password hash from a Password Safe (.psafe3) file and formats it for use with John the Ripper.
  • > psafe_hash.txt: Redirects the output (the extracted hash) to a file named psafe_hash.txt.
  • Result: A hash string from the password safe was saved to psafe_hash.txt.

4. Cracking the Password Safe Master Password:

john --wordlist=/usr/share/wordlists/rockyou.txt psafe_hash.txt

Explanation:

  • john: John the Ripper, a popular open-source password cracking tool.
  • -wordlist=/usr/share/wordlists/rockyou.txt: Specifies the rockyou.txt wordlist, which is commonly used due to its large collection of leaked and common passwords.
  • psafe_hash.txt: The file containing the extracted password safe hash.
  • Result: The master password for the password safe was cracked: michaeljackson.

5. Accessing and Extracting Credentials from Password Safe:

  • Action: Used a pwsafe application (or similar software) and the cracked master password (michaeljackson) to open Employee-Passwords_OLD.psafe3.
  • Result: Obtained several valuable domain user credentials:
  • DMZ01 :-> jbetty xiao-nicer-wheels5
  • Domain Users:-> bdavid caramel-cigars-reply1 (Confirmed valid)
  • Domain Users:-> hwilliam warned-wobble-occur8
  • Domain Users:-> stom calves-warp-learning1 (This specific password for stom was actually obtained later during the LSASS dump from JUMP01, but it's listed here for completeness of discovered domain users).

Phase 3: Lateral Movement to JUMP01 and Initial Credential Dumping Attempt

  1. RDP to JUMP01 with Stolen Credentials:
proxychains xfreerdp /u:bdavid /p:'caramel-cigars-reply1' /d:nexura.htb /v:172.16.119.7 /cert:ignore /dynamic-resolution "/drive:parrotshare,/home/user/parrotshare"

Explanation:

  • proxychains: Routes the RDP connection through the SOCKS proxy.
  • xfreerdp: An open-source RDP client for Linux.
  • /u:bdavid /p:'caramel-cigars-reply1': Specifies the username and password for bdavid.
  • /d:nexura.htb: Specifies the domain.
  • /v:172.16.119.7: The target IP address of JUMP01.
  • /cert:ignore: Ignores RDP certificate warnings.
  • /dynamic-resolution: Allows the RDP session to adjust its resolution dynamically.
  • "/drive:parrotshare,/home/user/parrotshare": This crucial option mounts a local directory (~/parrotshare on the attacker's Linux machine) as a shared drive within the RDP session. This facilitates easy file transfer between the compromised Windows host and the attacking machine.
  • Result: Successfully gained an interactive RDP session on JUMP01 as bdavid.

2. Dumping LSASS from JUMP01 and Extracting Credentials:

  • Action (on JUMP01): Once on JUMP01, I needed to extract credentials from memory. I opened Task Manager, navigated to the Details tab (or Processes in older Windows versions), located the lsass.exeprocess (Local Security Authority Process), right-clicked it, and selected "Create dump file". This generated a lsass.dmp file containing a snapshot of the process's memory.
  • Transfer: This lsass.dmp file was then transferred to my attacking Linux machine using the shared RDP drive (parrotshare).

3. Analysis (on Linux):

pypykatz lsa minidump lsass.dmp

Explanation: