CRTP REPORT - 1

PHASE 1 : Initial Foothold & Local Privilege Escalation

To begin our engagement, we first established a stealthy execution environment. We launched

an Invisi-Shell session to prevent our commands from being subjected to enhanced PowerShell
logging. Within this session, we executed a memory-based AMSI bypass. This is a critical
preliminary step to ensure our enumeration scripts, such as PowerUp, can be loaded and
executed without being detected and blocked by Windows Defender's in-memory scanning
capabilities. Once the environment was prepared, we ran Invoke-AllChecks to enumerate the
local system for potential privilege escalation vectors.

1. I have initialized an RDP session on the student VM and transferred the PowerUP.ps1 file
along with the “invi-shell” tool folder in a folder that I have created “AD” under “C:\”
drive

2. I launched the PS shell using the “RunwithPathAsAdmin.bat” post which I applied the
AMSI bypass.
3. Now I have loaded the PowerUp.ps1 script using the dot sourcing to execute it’s main
functions (Invoke-AllChecks)

Analysis of the findings from the output :

Invoke-AllChecks has identified several potential issues, but one stands out as our best
option:
  Vulnerable Service: vds (Virtual Disk Service)
 Privilege Level: It runs as LocalSystem, the highest privilege level on a Windows
machine.
 Vulnerability: Your user has permissions to modify the service's configuration.
 Key Factor: Crucially, the CanRestart property is True.

This combination is perfect for privilege escalation. We can temporarily change the
service's executable path to a command of our choice, start the service to run our
command as LocalSystem, and then change it back.

4. I need to use the Invoke-SeviceAbuse command to gain administrative rights exploiting

the VDS service. The function was used to temporarily reconfigure the service's binary
path to a command that adds our user account to the local 'Administrators' group. Upon
starting the service, this command was executed with SYSTEM privileges. Verification
with net localgroup administrators confirmed that we had successfully escalated our
privileges to local administrator on the machine.

5. The studentuser machine needs to be restarted to ensure the administrative privilege is

applied correctly. Additionally, we can also disable the windows defender capabilities to
ensure it does not cause in hurdles. I have applied the disabled command from the shell
and also disabled from the GUI to be sure.
PHASE 2 : Credential Harvesting with Mimikatz

1. With local administrator privileges secured, the next objective was to harvest
credentials. After logging into a new session with our elevated privileges, we first
disabled Windows Defender's real-time monitoring. Subsequently, we uploaded and dot
sourced the Invoke-Mimi.ps1 script. Then executed it by passing the
sekurlsa::logonpasswords argument to the script's -Command parameter, we
successfully dumped credentials from the LSASS process memory. This action allowed us
to recover credentials for other users and service accounts, providing us with the
material to begin lateral movement into the domain

Analysis of Findings:
We have successfully dumped the credentials from the LSASS process. Here's what we've
found:
User: studentuser in the TECH domain.
NTLM Hash: 8668f7cf1b4b5ed5a2d164d82d7c16d5
Domain: TECH.FINANCE.CORP
We haven't found any other high-value user credentials on this machine, which is
common. However, we have confirmed our user's NTLM hash, which is valuable for
future use.

PHASE 3 : DOMAIN ENUMERATION WITH BLOOD HOUND

1. Having established a privileged foothold on the initial VM, the next phase was to
conduct comprehensive domain enumeration. The SharpHound collector was
uploaded and executed on the machine to gather data about the
TECH.FINANCE.CORP Active Directory environment. The resulting data was then
exfiltrated and loaded into the BloodHound analysis GUI. This process provides a
complete map of the domain's objects and relationships, forming the basis for
identifying lateral movement and privilege escalation paths.

2. The data has been fed to bloodhound. The logical step is to mark the studentuser
machine as “owned” and find the shortest path to Domain admin. That yielded no
 result. Then I queried for kerbroastable accounts :

I queried for shortest path to domain admin

Analysis of Findings
By combining the data from both queries, we have identified a critical vulnerability.
 Analysis of the BloodHound data revealed a critical attack path. The service account
sqlserversync@tech.finance.corp was identified as being both Kerberoastable (due to
a configured Service Principal Name) and having DCSync privileges over the domain. This
combination represents a critical misconfiguration, allowing an attacker to request a service
ticket for the user, crack the password offline, and then leverage the compromised account
to replicate all credential hashes from the domain controllers.

Phase 4: Kerberoasting

1. The initial attempt to perform a Kerberoasting attack using Rubeus was unsuccessful. As
part of our methodology, we pivoted to an alternative tool, PowerView. Using the Request-
SPNTicket function, we successfully requested a service ticket for the vulnerable
sqlserversync account and exported its hash into a crackable format, saving it for offline
password cracking.

All attempts to crack the Kerberoasted service ticket for sqlserversync failed, indicating a strong
password. This attack vector was abandoned. The strategy was pivoted to re-analyze the
privileges of the sqlserversync account in BloodHound. This analysis revealed that the account
held DCSync rights over the domain. The new attack path became clear: compromise the host
where the sqlserversync service runs (dbserver31) in order to impersonate the user and execute
the DCSync attack. The first step in this new plan was to enumerate dbserver31 for active user
sessions.

PHASE 5 : Chaining Privileges

INPUT DATA!!!!!!!!!

PHASE 6 : Manual Domain Enumeration

After exhausting automated pathfinding and GPO enumeration techniques, the investigation
returned to foundational domain enumeration to build a more detailed understanding of the
environment. Using PowerView, we collected basic information about the domain itself, a
complete list of computer objects, and a list of all domain users along with their descriptions.
This data was then manually reviewed for any anomalies, interesting hostnames, or descriptive
text that could indicate a potential attack vector or a misconfiguration to exploit.

A deep-dive analysis of the techservice user object revealed that it was a service account with a
non-expiring password. The account's description indicated it was used for an "inventory
management agent". This led to the hypothesis that the account's credentials might be stored
in a plaintext configuration file on a network share. To test this, PowerView's Invoke-FileFinder
was used to scan all domain shares for relevant files, specifically searching for the keyword
"inventory".:

A deep-dive analysis of the techservice user object...led to the hypothesis that the account's
credentials might be stored in a plaintext configuration file on a network share. To test this,
PowerView's Invoke-FileFinder was used to scan all domain shares for relevant files,
specifically searching for the keyword "inventory" in file names.

That output indicates the command completed its search across all 5 computers in the domain but
found no files with "inventory" in the name that you have permission to access.

We have reached a critical point. We have tried & failed:

 Automated pathfinding (BloodHound) – Did not reveal the attack paths from studentuser
 Kerberoasting and offline cracking – strong password
 GPO enumeration – did not yield any GPO
 Targeted file searches – Did not yield any result
Phase 7: Logical Password Guessing

Attempt to Use a Deduced Password for techservice

After multiple enumeration techniques failed to provide a path forward, we revisited the
techservice account. This account was configured with a non-expiring password, a common
indicator of a weak or static credential. A logical guess was made based on common
administrative password schemes. The password Password123! was tested using the runas
command and was not found to be valid, granting us execution context as the techservice
user.

Phase 8: Hunting for Delegation Vulnerabilities

After failing to identify any user-based Kerberos vulnerabilities (Kerberoasting, AS-REP

Roasting), the investigation pivoted to identifying host-based misconfigurations. PowerView was
used to enumerate all computer objects in the domain, specifically searching for the dangerous
"Unconstrained Delegation" flag. Identifying a server with this property would provide a clear
path to capturing privileged credentials if a high-value user could be enticed to authenticate to
it.

Phase 9: Final Credential Guess

After a comprehensive but unsuccessful search for technical vulnerabilities, the investigation
returned to the techservice account. Based on the fact that it was a service account with a
non-expiring password, a final attempt was made to test for a common misconfiguration: the
use of the username as the password. The credential techservice:techservice was tested
and found to be valid, granting us execution context as the service account.

Phase 10: Inbound Control Analysis

The output Explicit Object Controllers: 6 is critical. It means that while techservice
itself might not have a direct path forward, there are six other users or groups that have direct
administrative permissions over the techservice account.

If we can compromise any one of these six controllers, we can use their privileges to reset the
password for techservice and take control of it.

I have analyzed the Techservice-6accounts.json file. Here is the critical piece of

information:

 Controlling Group: ACCOUNT OPERATORS@TECH.FINANCE.CORP

  Permission: GenericAll
 Target: TECHSERVICE@TECH.FINANCE.CORP

This means that any member of the "Account Operators" group can do anything to the
techservice account, including resetting its password.

We have come full circle. We know the path is: Our User -> ACCOUNT OPERATORS group ->
techservice user -> DCSync

The problem remains the same: we still don't have a path into the ACCOUNT OPERATORS group.

Phase 11: Investigating the Final Lead

The inbound control analysis for techservice confirmed that the ACCOUNT OPERATORS group
held GenericAll permissions over it, making control of this group our primary objective. As no
direct path to this group was found, the investigation pivoted one last time to analyze the final
remaining service account identified during initial enumeration: databaseagent. A full dump of
the user object's properties was performed to search for the final piece of the puzzle required to
complete the attack chain.

Critically, for both techservice and databaseagent, the Get-NetUser command is not
showing us which groups they are members of. This is our key blind spot.
Phase 12: Final Analysis and The Missing Link

Previous enumeration attempts to identify the members of the high-value ACCOUNT OPERATORS
group using live PowerShell commands were unsuccessful. The investigation pivoted to re-
analyzing the comprehensive dataset collected earlier by SharpHound. By directly querying the
properties of the ACCOUNT OPERATORS group object in the BloodHound GUI, its members were
successfully identified, revealing the final link in the attack chain.
This is a highly unusual situation and a major turning point. The ACCOUNT OPERATORS group
having no members means that our previously identified attack path is a dead end.

Phase 13: Exhaustive Local Enumeration

Initial attempts to run winPEASx64.exe from an Invisi-Shell session were unsuccessful. To

troubleshoot potential shell compatibility issues, the tool was re-run from a standard, elevated
command prompt. This allowed the tool to execute correctly and generate a comprehensive
report of the system's configuration, which was then analyzed for new attack vectors.

Analysis of peas_output.txt

I have analyzed the lengthy output. Most of it confirms what we already know (we are admin,
LSA is unprotected, etc.). However, under the "Interesting files and registry" section, there is one
critical line:

 Looking for possible password files in users homes

o C:\Users\All
Users\Microsoft\UEV\InboxTemplates\RoamingCredentialSettings.xml

This is our key. A file named RoamingCredentialSettings.xml is almost certainly a

configuration file left behind by an application, and it is a prime location for finding insecurely
stored credentials. The name itself is a massive red flag.

Phase 14: Exploiting Leaked Credentials

Examine the Leaked Credential File

After multiple attack paths were exhausted, a comprehensive local enumeration scan was
performed on the initial host using winPEASx64.exe. This scan uncovered a misconfigured XML
file, RoamingCredentialSettings.xml, located in a user-accessible directory. The contents of
this file were examined to determine if it contained credentials that could be used for privilege
escalation or lateral movement. It did not contain anything valuable.
Phase 15: Exhaustive Local File System Search

dir /s /b c:\*inventory*

dir /s /b c:\*agent*

After all network-based attack vectors and AD enumeration paths were exhausted, the
investigation returned to the most unique clue: the description of the techservice account. A
hypothesis was formed that the credentials for the "inventory management agent" might be
stored in a file on the local machine. A comprehensive search of the local file system was
initiated to find any files related to this agent. It did not yield anything of use.

Phase 16: Final Enumeration - Credential Manager

After all other avenues of investigation, including file system and registry searches, proved
unsuccessful, the investigation returned to the output of the winPEAS script. The script had
indicated an error while trying to automatically parse the Windows Credential Manager but
suggested the manual command cmdkey /list. This command was executed as a final
enumeration step to check for any stored network or application credentials that could be used
for lateral movement. It did not.

Phase 17: Abusing Delegation

After exhausting multiple dead-end paths, a re-evaluation of the BloodHound data from the
perspective of the compromised studentuser revealed a new attack vector. A delegation
relationship was discovered where the initial host, STUDVM, was "allowed to delegate" to the
high-value target mgmtsrv.tech.finance.corp. This host-based privilege became the primary
focus for lateral movement. The next step was to identify the specific type of delegation to
formulate an exploitation plan.

The BloodHound analysis revealed that the STUDVM computer object was configured for
Constrained Delegation to the MGMTSRV server. This was verified from the command line using
PowerView to query the msds-AllowedToDelegateTo attribute of the STUDVM computer
account. This configuration is abusable, as an attacker with administrative rights on STUDVM can
impersonate any user to access the specified services on MGMTSRV. This became the primary
vector for lateral movement.

[ NOTE : This is where the RDP session showcased erratic behavior – leading to time consumtion
due to which the exam was re-launched ]

After re-establishing an administrative session on the STUDVM host, the next step was to abuse
its Constrained Delegation privilege. To begin, Invoke-Mimi was executed to dump credentials
from LSASS. This successfully recovered the NTLM hash of the STUDVM$ machine account, which
is the first component required to forge a service ticket.
Analysis of Findings

From the Mimikatz output, we have the credentials for the STUDVM$ machine account:

 Account: STUDVM$
 Domain: TECH
  NTLM Hash: 9d1ae6a056d1366d8a905ae41504d351

The NTLM hash for the STUDVM$ machine account was successfully extracted from LSASS. This
credential was then used with Rubeus to execute a constrained delegation attack. A service
ticket for the CIFS service on mgmtsrv.tech.finance.corp was forged, impersonating the
context of a Domain Administrator. The resulting ticket was injected into the current session,
granting full administrative access to the target server's file system and achieving a successful
lateral movement to a high-value target.