Dexter's Lab (Part 1)
Network Architecture & Setup — Red Team Simulation

Overview

This project involved the design and deployment of a multi-machine, cross-hardware virtualized environment simulating a corporate Active Directory infrastructure. The lab is split between a high-performance Host PC (The Enterprise Network) and a Laptop (The Attack Surface), interconnected via a physical LAN bridge to simulate real-world network pivoting and lateral movement.

Project Context & Ethical Disclaimer

This lab was conducted within a strictly isolated VMware architecture with no external internet connectivity to ensure a controlled and safe execution environment. This project was developed for educational purposes as part of a self-driven curriculum following TryHackMe's advanced penetration testing pathways. All techniques demonstrated were performed on owned hardware within a private, sandboxed domain to simulate modern threat actor TTPs (Tactics, Techniques, and Procedures) for defensive research and skill validation.

Architecture Visualization

The Enterprise Network (Desktop PC)

A secure Windows Domain environment monitored by a centralized SIEM.

• Domain Controller (Dexter-Server): Windows Server 2022 hosting Active Directory, DNS, and DHCP. It serves as the "Brain" of the lab, managing the dexters-lab.local domain.
• SIEM Instance (Splunk Enterprise): Installed on the Domain Controller to provide centralized logging, alerting, and data visualization.
• Workstations (Dee-Dee-PC1 & MrDad-PC2): Windows 10 endpoints joined to the domain, equipped with Splunk Universal Forwarders for real-time telemetry.

The Attack & Vulnerable Segment (Laptop)

A legacy and offensive environment designed to test security controls.

• Vulnerable Gateway: Windows Server 2008 joined to the domain. This machine acts as a "Legacy Bridge," intentionally left vulnerable to MS17-010 (EternalBlue) to simulate an initial entry point into the domain.
• Attacker Node (Kali Linux): Isolated on a Host-Only network (VMnet19), communicating with the enterprise network solely through the compromised Server 2008 gateway.
• Resources (Kali Linux/Docker): Hosts "Riddle Manager" (a custom password manager app) via 6 Docker containers, having the capacity to generate passwords and respective hash values that help with guessing and decrypting NTLM hashes.

Technical Implementations

• Hardware Bridging: Successfully configured VMware Bridged Adapters across two separate physical machines, allowing seamless L2 communication over a physical LAN cable.
• Segmentation: Utilized VMnet19 (Host-Only) to isolate the attacker's backend tools while maintaining a bridged connection for target access.
• Security Monitoring (Blue Team): Using Splunk installed on the main DC server.
• Scalable Deployment: Configured a Splunk Deployment Server using Server Classes and Wildcards (*) to automate the distribution of inputs.conf configurations across all endpoints.

Attacker's Machine: Kali + Riddle Manager

Reconnaissance

1. Setting up the target included making sure the service "Server" is running, the firewall to allow incoming connections via port 445, and changing network profile to "Private" so it will allow Administrative pipe connection.

2. Initial reconnaissance was hindered by the default Windows Firewall policy, which silences ICMP echo requests. To achieve visibility without relying on ICMP, I executed an ARP sweep and an ACK scan. Operating at the Data Link layer (ARP) allows for reliable host discovery on the same LAN, even when higher-level protocols are filtered.

So I ran a custom nmap command and found the live host (Windows Server 2008) on the current network (VMnet19), with port 445 open. Next we should find what version it is and if it's vulnerable.

3. After running msfconsole, search for "eternal blue" — I found an auxiliary scanner for that exploit, set RHOST to match the target IP and got a "likely Vulnerable" result.

Initial Attack

After setting RHOST to target IP and the LHOST to my current Kali IP, I successfully got a reverse shell with SYSTEM privileges.

Post-Exploitation & Hash Extraction

While achieving SYSTEM privileges provides total control over the local host, it is limited to the local scope. To facilitate lateral movement, I extracted NTLM hashes from the SAM database, including legacy accounts (e.g., 'shadow') which are often overlooked. My next objective is to establish persistent remote access by modifying the Windows Firewall to permit RDP (TCP 3389). In the event that the extracted hashes cannot be cracked, I will proceed by creating a new local account and elevating its privileges to the 'Administrators' and 'Remote Desktop Users' groups to ensure continued access — but I would like to avoid creating a new user because it's very noisy. In a real-world scenario, creating a user triggers an Event ID 4720 which can be easily detected by Splunk.

Targeted Credential Cracking

Upon auditing the local user accounts, I performed a strategic prioritization of my targets. While the 'Admin' account was identified as a known baseline setup user and 'Administrator' was flagged as a standard local-only profile, they were de-prioritized. Instead, I focused on 'DeeDee' and 'Dexter-Backup', as these accounts are more likely to possess domain-level permissions or shared credentials. I proceeded to perform an offline brute-force attack on their extracted NTLM hashes to recover the plaintext passwords.

Based on initial reconnaissance and the cartoon (animated series), I identified a potential password pattern for the user 'DeeDee' centered around the keyword 'cookies'. Rather than using a generic wordlist, I performed a targeted dictionary attack by generating custom variations (mutations) of this keyword. I then calculated the NTLM hashes for these variations to perform a manual comparison against the hashes extracted from the SAM database. This phase demonstrates how a password manager — in this case, the locally hosted 'Riddle Manager' — can be repurposed as an offensive tool for credential validation and hash comparison.

After having a wordlist based on that "cookies" word, I generated NTLM hashes to compare them against the extracted hashes.

Establishing RDP Access

Now that I have the plain text password for that account, I will first try to connect from Kali via an RDP connection.

Encountered TLS handshake errors (0x00020008) due to protocol mismatch between modern Kali tools and legacy Windows Server 2008. Resolved by forcing the /sec:rdp security layer. This highlights the challenges of accessing legacy infrastructure during an engagement.

After this I encountered another error — the solution was to go back in msfconsole and add the "DeeDee" user to the "Remote Desktop Users" group.

Network Pivoting via SOCKS Proxy

To bypass network segmentation, I implemented a Pivot using a SOCKS4a proxy via the compromised Windows 2008 gateway. By configuring Proxychains on my Kali instance and establishing an autoroute in Metasploit, I was able to perform internal reconnaissance on the restricted dexters-lab.local subnet without transferring offensive tools to the victim's file system. This minimized my forensic footprint while granting full visibility into the internal Domain Controller and workstations.

Configured Kali proxychains by commenting out proxy_dns (often breaks proxychains in lab environments) and adding socks4 127.0.0.1 1080 in the configuration.

Pivot Recap

• Step 1 — autoroute: Used post(multi/manage/autoroute) to transform the target (Windows Server 2008) into a proxy server giving access inside the dexters-lab.local (192.168.10.0/24) network. This directs all traffic destined for the 192.168.10.0/24 subnet through the active Meterpreter session on the Windows Server 2008 gateway.
• Step 2 — socks_proxy: Used auxiliary(server/socks_proxy) to bring the proxy from Metasploit to the Kali machine on port 1080. This bridges the Metasploit routing table to the Kali OS user-space.
• Step 3 — proxychains: Configured proxychains to use 127.0.0.1:1080 as the system proxy. Now typing proxychains before any tool forces that tool to use the proxy server (the Windows Server 2008).

During the pivoting phase, initial Nmap scans through Proxychains returned 'False Positives,' indicating all 254 hosts were active. This occurred because Proxychains intercepted the connection attempts locally before the Metasploit routing table could resolve the path.

A blind scan returned "net-unreach" — Nmap was trying to send packets, but the Kali Linux OS was telling Nmap "I have no idea how to get to the 192.168.10.x network," killing the connection before it even reached the Proxychains tunnel. The core issue: "Raw Sockets" vs. "TCP Connect" — Nmap often fails through proxies because it tries to use Raw Sockets (which requires a direct network path), whereas Proxychains can only hook standard TCP system calls.

Internal Reconnaissance (Second Attempt)

I tried using the built-in Metasploit tools such as "run post/windows/gather/arp_scanner RHOSTS=192.168.10.0/24".

Now I have an idea of the network. From a simple "ipconfig" run on Windows 2008 I know its IP is 192.168.10.56. 192.168.10.53 and 192.168.10.54 are VMware network adapters (UNKNOWN status). 192.168.10.255 is the Broadcast Address. So the only addresses of interest remain: 192.168.10.10, 192.168.10.52, and 192.168.10.55. Next I backgrounded the current session, added a route to session 1, and performed a port scan.

Lateral Movement — Credential Spraying

Naturally the next step was to check if the credentials I already got (Username: DeeDee and Password: C00kies1234) have access somewhere else on the network.

Since I'm already using Windows 2008 as a proxy, I can use proxychains to connect RDP to that workstation.

Privilege Escalation Setup

With a simple command "net users deedee" I can see that this user doesn't have administrative rights, but there are other logged-in users that have the right kind of privileges.

I will try to get Meterpreter inside this workstation but this implies a few obstacles. First, Windows Defender is active and would kill any msfvenom payload. Second, Dee-Dee-PC1 (Win10 — 192.168.10.x) has no idea how to find my Kali (192.168.181.x). I will have to create the payload with LHOST set to the Server 2008 and port-forward port 8889 to my Kali (192.168.181.x). Meaning: "Any traffic hitting the Server 2008 on port 8889, throw it back to Kali on port 9999."

I would also need to open port 8889 and port 9999 in the firewall — incoming connection from Dee-Dee-PC1 (192.168.10.52) and outgoing connection to Kali (192.168.181.129) on port 9999.

Custom PowerShell Port Relay

I had to create a small PowerShell script, upload it to Win2008 via RDP and then run it. This script acts as a forwarder — any incoming connection on 8889 is redirected to port 9999 on Kali Linux. Because this is an old (ancient) operating system, I used Google AI Gemini to help create it faster.

To facilitate the multi-hop relay, the Windows 2008 Gateway firewall was modified to permit bidirectional traffic between the isolated segments. An inbound rule was created on TCP/8889 to accept the initial callback from the target (Windows 10), and an outbound rule was defined for TCP/9999 to permit the relayed traffic to egress towards the C2 server on the 192.168.181.0/24 network.

Relay Script (PowerShell + C#)

Payload Delivery & Meterpreter Access

Let me get this out of the way first: I disabled Windows Defender on this first workstation (Dee-Dee-PC1). Since I don't have a user with administrative permissions, I have to escalate privileges — and doing so while managing a double-pivot, a proxy server, and a reverse connection is absolute madness. Evading AV is beyond the scope of this first exercise, but it will definitely come later on!

Next I generated the payload (stageless) and uploaded it via RDP to Dee-Dee-PC1.

I opened a new terminal with a new instance of msfconsole, configured the new listener on local IP and port 9999.

Privilege Escalation (CVE-2023-36874)

Before manually trying all possible CVEs, I ran a scanner from Meterpreter in hopes it would find the most likely to work options.

Of course it's not as simple as it sounds. I had to try all 8 of them. Some time later, after some BSOD (Blue Screen of Death) and crashes, I found one that worked on this OS (Windows 10 22H2). Being unlucky, the last one in the list did the trick: exploit/windows/local/win_error_cve_2023_36873.

This exploit creates a new connection to Meterpreter with "SYSTEM" privileges and so it needs another port for communication. I copy-pasted the PowerShell relay script that runs on Windows Server 2008, edited a new incoming port (8890) to forward to my Kali (port 9998) and ran the new instance.

Multi-Session Management

In the setup:

• MSF1: The session that controls Windows Server 2008.
• MSF2: The session that controls Windows 10 (192.168.10.52 Dee-Dee-PC1), but that user (DeeDee) is not an Administrator.
• MSF3: The session where I will try to get "SYSTEM" privileges using "DeeDee" account from "MSF2" session.

Configured the exploit and ran it using the unprivileged "DeeDee" account from MSF2 session. The user "DeeDee" just created a new folder (C:\XkgZAiZtW) — the exploit is working!

Now, let's check MSF3 session!

Lab Recap (Phase 1)

• 1. Initial Foothold: Scanned the 192.168.181.0/24 segment from Kali and compromised the Windows Server 2008 gateway (192.168.181.132) via EternalBlue.
• 2. Pivoting: Established a Meterpreter session, dumped hashes to identify the user "DeeDee," and deployed a SOCKS proxy to route traffic into the internal 192.168.10.0/24 network.
• 3. Lateral Discovery: Decrypted the "DeeDee" hash and performed credential spraying against the internal segment, identifying Dee-Dee-PC1 as a valid target.
• 4. Traffic Relaying: Leveraged RDP access to the target; however, to gain a stable C2 channel back to Kali, I deployed a custom asynchronous PowerShell relay on the Win2008 server to bridge communication.
• 5. Privilege Escalation: Established a secondary relay on Win2008 to facilitate the CVE-2023-36874 (Windows Error Reporting) exploit. Using a stageless payload and process migration, I successfully escalated from "DeeDee" to NT AUTHORITY\SYSTEM.
• 6. Persistence & Looting: With SYSTEM integrity, I added "DeeDee" to the local Administrators group and performed a final hashdump to collect high-value credentials, including the user "MrDad."

Next Target: MrDad-PC2

Having successfully acquired the 'MrDad' NTLM hash and bypassed Dee-Dee-PC1, only two targets remain on the internal subnet. I performed a fresh network scan to account for potential IP reassignment by the DHCP service, as any system reboots could have altered target addresses. Once active hosts were confirmed, I proceeded with service discovery to identify open ports on the remaining systems.

Cracking the clear-text password from the 'MrDad' NTLM hash should be straightforward given the user profile; however, for this exercise I prioritized a Pass-the-Hash (PtH) attack to demonstrate credential relay techniques. I determined that 'MrDad' is a local account rather than a domain user, as the profile path is C:\Users\MrDad instead of the domain-prefixed C:\Users\Dexters-Lab.MrDad. Consequently, I targeted 192.168.10.55, as it is highly probable this workstation is a standard endpoint rather than the Domain Controller.

Pass-the-Hash via Evil-WinRM

Because I have made a proxy-server from Windows 2008, I can use "proxychains evil-winrm" to connect to MrDad-PC2 (192.168.10.55) using the pass-the-hash method.

As we can see this user (MrDad) is an Administrator. Next I will disable the AV and open outgoing port 8889 in the firewall because I will also want to get a Meterpreter inside this workstation.

In order to allow a local Admin to have administrative control over WinRM, I had to manually add a register using the console from VMware Workstation:

UAC Bypass & Tamper Protection Battle

Even after multiple attempts, I succeeded in configuring the firewall, but disabling the AV was not successful. At this stage, I am using a Local Account (MrDad). Windows is designed to be extremely suspicious of local accounts connecting over the network.

In a real company, admins use Group Policy (GPO). A Domain Admin creates a policy on the Domain Controller. That policy tells all workstations: "Trust the 'Domain Admins' group and give them full 'High Integrity' tokens over WinRM." Because the instruction comes from the Domain Controller (the "Boss"), the workstations allow the administrative moves without the UAC block.

To bypass this I had to add 3 additional registers via Evil-WinRM:

Of course those commands didn't work from the first attempt. Almost for each command I had to reconnect with Evil-WinRM, because those commands have a big chance of killing the session — but after a few tries they worked.

Once all registers were added, I restarted the workstation for them to take effect. Restarting is not very stealthy but let's assume this is done in the middle of the night when nobody is using the PC.

Even after all of this, Tamper Protection is doing its job. It protects the Defender settings in a way that registry keys alone cannot bypass because the kernel itself is guarding those specific values.

Scheduled Task Bypass Attempt

Next try: create a kill.bat file and use schtasks to run the commands as SYSTEM.

I attempted to use a Scheduled Task as SYSTEM because, in many legacy Windows environments, the SYSTEM account can bypass the 'Access Denied' errors encountered by local administrators. I targeted the boot process to try and disable the security service before it could protect itself. The failure of this attempt proves the effectiveness of Tamper Protection in this specific Windows 10 build.

I tried Registry, PowerShell, CMD, and Scheduled Tasks (as SYSTEM) — I have officially exhausted the standard "Administrative" bypasses.

RDP via Pass-the-Hash

Next idea: enable RDP and open port 3389 since my user (MrDad) can do this. The problem is that at this moment I only have the NTLM hash. I configured the registry so I can pass-the-hash to a remote desktop connection.

Hunting the Domain Admin

Observations in Task Manager reveal an active session for the user 'Dexter-Admin'. Since this account does not appear in the output of "net users" command, it is confirmed to be a Domain Account rather than a local one.

Once the environment is clear from Windows Defender, I deployed a Meterpreter payload. From there, I attempted to leverage Kerberos tickets or session tokens to impersonate the Domain User, providing a path for lateral movement toward the Domain Controller.

Using "Dexter-Admin" I started a shell (cmd) and opened a PowerShell instance, also added DC to TrustedHosts.

Domain Controller Access Attempts

Not getting the PowerShell connection, I tried something else — proving I can write to the DC's administrative shares.

Now that I know this user is able to list contents of C$, it's clear that "Dexter-Admin" has privileges on the DC. I tried to dump the account NTLM hashes. Even after getting SYSTEM, a normal hashdump didn't work.

SAM vs. NTDS.dit

• hashdump (and smart_hashdump) targets the SAM (Security Account Manager) database.
• The SAM is Local: It only stores hashes for accounts local to that specific machine (like MrDad, Administrator, or Guest).
• Domain Accounts are Central: Because Dexter-Admin is a Domain Account, their hash is not in the SAM of MrDad-PC2. It is stored in the NTDS.dit database located on the Domain Controller.

Since load kiwi failed (preventing a memory dump of the hash) and Enter-PSSession failed (due to WinRM's IP security), we need a way to execute a command on the DC using the current Dexter-Admin token.

I utilized WMIC (Windows Management Instrumentation Command-line) to execute processes remotely.

SUCCESS — Remote Code Execution on DC!

Attack Chain Recap

• 1. Initial Access & Elevation: Established a Meterpreter session as MrDad. MrDad is a local administrator providing the high-integrity context required to interact with system tokens and memory.
• 2. Token Impersonation: Hijacked the session of Dexter-Admin. Since Dexter-Admin (a Domain Admin) was actively logged into the workstation, a delegation token existed in memory. Using the Incognito module, I impersonated this token to inherit domain-level privileges without needing their password.
• 3. Credential Harvesting Limitations: Hashdump failed (domain account not in local SAM). Kiwi/Mimikatz failed — blocked by Protected Process Light (PPL) or kernel-level behavioral protections preventing unauthorized memory reading.
• 4. Remote Management Obstacles: WinRM (Enter-PSSession) failed due to IP-based authentication restrictions. PsExec failed because it requires a cleartext password or NTLM hash, but only the token was available.
• 5. Final Pivot via WMIC: WMIC utilizes DCOM/RPC for communication. Unlike WinRM or PsExec, WMIC can leverage the existing Kerberos token of the current process. The WMIC command inherited the Dexter-Admin identity and successfully authenticated to the Domain Controller as a Domain Administrator.

Domain Controller — Registry Hive Extraction

I ran these 3 commands to dump the registry hives:

Download those files from DC to MrDad-PC2 (locally):

Used RDP to get those 3 files on my Kali and ran "impacket-secretsdump":

I now have the hash for the Administrator account. But where is the hash for "Dexter-Admin"?

Extracting NTDS.dit via Volume Shadow Copy

The Active Directory database (ntds.dit) is protected by a persistent process lock maintained by lsass.exe. To bypass this without crashing the Domain Controller or stopping essential services, I utilized the Volume Shadow Copy Service (VSS) via the ntdsutil utility. By generating an Install From Media (IFM) set, the system created a point-in-time snapshot of the volume. This allowed for the successful extraction of the database and the corresponding SYSTEM hive from the shadow volume, bypassing the active file lock and enabling offline credential extraction.

Good thing to notice here: this method of dumping hashes doesn't require disabling the AV (Windows Defender 2022)!

Final Pivot — RDP to Domain Controller

Now I have the NTLM hash from "Administrator" and "Dexter-Admin" — both being Domain Admins. I configured the DC to open RDP (not stealthy but looks good for demonstration), configured the firewall, and added a register to login using just the NTLM hash.

Disabled Network Level Authentication (NLA) and created additional firewall rules:

Service restart & port check:

VOILA — Domain Controller Compromised!

Pentest has now ended — I reached the Domain Controller with Kali and got Domain Admin!

Lab Conclusion: The Evolution of the Kill Chain

This laboratory exercise served as a chronological journey through the evolution of Windows security and exploitation, demonstrating the shift from legacy vulnerabilities to modern administrative compromise.

The Path of Progression

• Legacy Exploitation (Windows Server 2008): The entry point utilized the EternalBlue (MS17-010) exploit, highlighting the catastrophic risk of unpatched legacy systems and the power of remote kernel-level exploitation.
• Modern Privilege Escalation (Windows 10): Demonstrated advanced post-exploitation by leveraging CVE-2023-36874 (Windows Error Reporting). This phase proved that even on modern builds, specific functional vulnerabilities can bypass traditional security boundaries to achieve local administrative rights.
• Environmental Manipulation: Successfully performed host hardening bypasses by programmatically disabling Windows Defender and reconfiguring the Windows Firewall to establish persistent C2 (Command & Control) channels via RDP.
• Domain Dominance (Windows Server 2022): The final pivot involved evading the enhanced protections of Server 2022. By utilizing Token Impersonation and Volume Shadow Copy (VSS) extraction, I bypassed modern process locks to retrieve the Domain Admin NTLM hashes from the NTDS database. Windows Defender remained totally silent.
• Infrastructure & Engineering: Throughout the lab, success relied on architectural mastery — crafting custom networking relays and cross-platform tools to bridge communication between disparate OS generations.

Mitigation & Defense

Attack Vector	Defense / Mitigation Strategy
EternalBlue	Decommissioning SMBv1 and aggressive patching of MS17-010.
CVE-2023-36874	Restricting local admin rights and monitoring WER process calls.
VSS Extraction	Monitoring ntdsutil.exe and vssadmin execution via EDR.
Token Hijacking	Enabling Credential Guard to protect lsass.exe.

The attack phase is now complete. The domain is fully compromised. Next: “Blue Team” assessment.