Three PowerShell scripts to identify persistence on Windows

Welcome back, dear defenders. 

We continue our series on the defensive side of PowerShell. Today we focus on persistence. We already covered Windows persistence mechanisms in a previous article, and those techniques resonated with many of you. Those articles were useful for the red team, but defenders benefit even more when they learn the same tricks from the other side. When an attacker has footholds across an estate they rarely rely on a single mechanism, but they try to build multiple fallbacks. We have seen cases where incident responders removed scheduled tasks and services, but forgotten credentials and remote-access tools like AnyDesk allowed attackers to re-enter days later. We have also seen attackers plant helper processes (watchdogs) that resurrect payloads after removals. For this reason treat the environment as if it were “radioactive.” Assume there are survivors and look for them everywhere.

To make the demo concrete we used a simple BootExecute persistence entry. BootExecute is a legacy Windows mechanism that runs specified commands very early during boot, before most services and user sessions. An adversary who replaces or extends that value can schedule executables to run before the system fully initializes. We tested our BootExecute example and confirmed the executable ran on boot. With that in place, let us look at three PowerShell tools that will help you find similar persistence across your estate.

Persistence Sniper

Repository: https://github.com/last-byte/PersistenceSniper

PersistenceSniper is a modern PowerShell module designed to enumerate known persistence locations and present them in analyst-friendly form. It walks standard places such as services, scheduled tasks, Run keys, Winlogon, Startup folders, WMI persistent subscriptions, AppInit DLLs, service image paths and more. It returns structured results with context, notes when items look suspicious, and maps findings to ATT&CK techniques where appropriate.

Installation in 2026 may differ slightly from older docs. Below is a reliable installation approach:

PS > powershell -ep bypass
PS > Install-Module -Name PersistenceSniper -Scope CurrentUser -Force -SkipPublisherCheck
PS > Import-Module PersistenceSniper

Once imported, a single command scans the host:

PS > Find-AllPersistence -Verbose

The output is verbose and intentionally descriptive. You will see entries for native system binaries in legitimate locations, but not everything is hostile. 

You will also see the new BootExecute entry. PersistenceSniper classifies findings and will map the BootExecute change to ATT&CK technique T1547.001, which helps when you tag incidents and generate reports.

Use PersistenceSniper as a first pass during triage on a live endpoint. It is fast, produces human-readable commentary, and is good for analysts who need to quickly determine whether a host still contains surviving persistence after an initial cleanup.

Trawler

Repository: https://github.com/joeavanzato/Trawler

Trawler approaches the same problem with a different emphasis. Where PersistenceSniper aims to be comprehensive and explanatory, Trawler attempts to reduce noise and present only items that look like adversary persistence. That approach is useful when you are hunting at scale and do not want dozens of benign services getting in the way of triage. The trade-off is that Trawler can produce false negatives when an attacker deliberately mimics an allow-listed item. Any finding needs human validation, so never treat a “no findings” result as absolute proof of cleanliness. Trawler also supports scanning offline images and mounted drives, which is important during forensic acquisition. You can point Trawler at that drive and it will scan it.

To run the basic interactive scan on a machine:

PS > .\trawler.ps1

Allow several minutes for the full checks to complete. If you tested the same persistence method, expect it to appear toward the end of the run where registry-backed persistence entries are analyzed.

Use Trawler when you want a compact set of high-confidence leads that are quick to validate at scale.

Kansa

Repository: https://github.com/davehull/Kansa

Kansa is different in purpose and scope. It is a modular incident-response framework implemented in PowerShell that excels at collecting forensic artifacts across many hosts using WinRM. Whereas PersistenceSniper and Trawler focus on local host persistence enumeration, Kansa is the tool you use when you want to pull the same artifacts from hundreds of computers and aggregate the results for analysis.

Kansa uses a simple module configuration. If a modules.conf file exists in the .\Modules directory it controls which modules run and in what order. Otherwise Kansa executes all modules. Its modules include things like Get-PrefetchListing, Get-WinRMRecentApps, Get-Netstat, Get-DNSCache and specific persistence-oriented modules. Kansa is safe by design, as it issues read-only queries and collects outputs that you can ingest into a central store.

Before running Kansa ensure WinRM is configured and reachable, and that the host firewall permits the traffic:

PS > winrm quickconfig -q

Then execute Kansa against a target set:

PS > .\kansa.ps1 -Target DELIVERY -ModulePath .\Modules -Authentication Negotiate -Verbose

You will see modules execute one after another, and each module will produce CSVs or structured JSON files. In a large environment you typically push Kansa results to a central analyst workstation or an Elastic stack for querying. Kansa is excellent for hunting, as you can roll a new modules.conf that focuses specifically on what you need.

Practical Validation and Triage

Here is a short workflow you can use when one of the above tools returns a candidate persistence artifact.

First, note the evidence: file path, service name or registry key and timestamps. 

Second, get file hashes and compare them with known-good baselines or vendor signatures. 

Third, determine whether the binary is signed and by whom. Unsigned or mismatched signatures are suspicious. 

Fourth, examine process ancestry and network connections: what launched it, and when did it first appear. 

Fifth, search your SIEM and EDR telemetry for related events, such as creation of a service, scheduled task registration, WMI filter creation, or a change to the BootExecute value. If the item is confirmed malicious, isolate the host, preserve volatile evidence, and proceed with credential rotation and domain-wide mitigations where appropriate.

Hardening & Remediation

Persisting attackers often rely on weak operational hygiene. You need to restrict who can create services and scheduled tasks through Group Policy, enable LAPS for local admin credentials and rotate them after any suspected compromise, monitor and alert on changes to critical system registry keys like BootExecute and Winlogon. Also, block execution from temporary directories with AppLocker or Windows Defender Application Control where feasible, and remove unnecessary remote management tools that are not used by your organization.  

Treat incident response as a long process. Removing a service is not an end state. You must rotate credentials, check for lateral spread, hunt for secondary re-entry mechanisms (both Windows and Linux), and review logging and detection gaps so next time the intrusion is noticed earlier.

Summary

Persistence is fundamental to attacker resilience. The three tools discussed here occupy complementary roles. Use them to scan and triage, validate the output, and then sweep the environment to find siblings of the same implant. Remember that persistence is cross-platform. Linux watchdogs and systemd units can resurrect removed binaries, so broaden your playbooks beyond Windows. Finally, integrate findings into your detection engineering. Persistence discovery and removal is painstaking work, but a methodical approach will make your environment a much harder target.

Source: HackersArise
Source Link: https://hackers-arise.com/powershell-for-dfir-part-2-finding-persistence/