Incident-Response-Powershell: sweeping a Windows host for forensic artifacts

One script, more than 25 artifacts

The centre of this repository is a single file, DFIR-Script.ps1, that collects forensic artifacts from Windows devices. The documentation describes it as gathering over 25 potential indicators of compromise, exporting to CSV files for SIEM integration, and integrating with Defender for Endpoint Live Response.

Run as a normal user, the script collects a wide slice of the live state of the machine. The documented list covers local IP information, open connections, autorun information from the startup folder and the registry Run keys, active users, local users, connections made from Office applications, active SMB shares, RDP sessions, active processes, active USB connections, PowerShell history, the DNS cache, installed drivers, installed software, running services, scheduled tasks, and browser history and profile files.

That list is a triage sweep rather than a targeted collection. Everything on it is a category an analyst would otherwise visit by hand during the first hour of an incident, when the question is not yet which artefact matters but what is running on the box at all.

The output is written into the current directory in a folder named DFIR-_hostname_-_year_-_month_-_date_, and that folder is zipped at the end so it can be collected remotely. The naming convention matters more than it looks: it means a collection from a machine with a known hostname lands in a predictable place, and it means two collections from two hosts do not overwrite each other when you gather them into the same evidence share.

Elevation adds the artefacts you actually need in a case

The documentation is explicit that the best experience comes from running the script as administrator, and lists what that adds on top of the standard collection.

The elevated items are the heavyweight ones: Windows Security Events, remotely opened files, shadow copies, MPLogs, Defender exclusions, and the PowerShell history of all users rather than the current user's.

Each of those unlocks a different question. Windows Security Events are the logon and access history that a timeline is built from. Remotely opened files show which paths an attacker touched on other machines. Shadow copies tell you what the system looked like before the change. Defender exclusions are the list of things the antivirus was told to ignore, which is one of the first things to check when a machine is clean but behaving oddly. The all-users PowerShell history catches the activity of accounts other than the one responding.

That creates a practical constraint worth naming. Without elevation you get a good overview but not the logon history, and an investigation that stops at the overview will miss lateral movement. In practice, responder tooling on a live system is a negotiation between what you need to collect and what the target's current user session allows.

It also raises the question of evidence integrity. The documentation does not describe any hashing of the collected output, and it does not describe a write protection scheme, so anything you rely on from this collection has to be handled with your own chain of custody process.

CSV exports shaped for a SIEM

The design choice that makes this script usable beyond a single analyst is the CSV export. The artefacts are written as CSV files, which the documentation says allows responders to ingest them into tools like Sentinel, Splunk, Elastic or Azure Data Explorer for filtering, aggregation and visualisation.

All of the CSV files live in a folder named CSV Results (SIEM Import Data), and the documented set covers the collection one artefact at a time:

ActiveUsers.csv
AutoRun.csv
ConnectedDevices.csv
DefenderExclusions.csv
DNSCache.csv
Drivers.csv
InstalledSoftware.csv
IPConfiguration.csv
LocalUsers.csv
NetworkShares.csv
OfficeConnections.csv
OpenTCPConnections.csv

The list continues with files for the PowerShell history, running processes, RDP sessions, remotely opened files, running services, scheduled tasks and their run info, security events, shadow copies and SMB shares.

One artefact per file is the point. A single flattened log would need a schema and a parser before anything could be queried; one file per artefact means each can be mapped to a field set in the SIEM and queried on its own terms. The cost is a folder with two dozen files in it, which is manageable but not zero, and the naming has to be consistent between runs to be useful in a dashboard.

For a team that already has a working ingestion pipeline, this format is also the easiest thing to replace. The collection and the SIEM side are cleanly separated by the file format.

Acquisition, Analysis and Containment as separate scripts

The main script is not the only thing in the repository. Alongside it are granular response scripts that perform specific tasks, such as collecting Windows Security Events, resetting active user sessions, or uploading a folder to Azure Storage Blob. Some of them use APIs to retrieve or export data, and the documentation notes that the required permissions are described in each script.

Those scripts are organised by the incident response cycle, in three directories. Acquisition holds scripts and tools for acquiring data and evidence during an incident. Analysis holds scripts for analysing acquired data to identify indicators of compromise and understand the scope. Containment holds scripts and methods for containing the incident to prevent further damage and spread.

That structure is the main difference between this repository and a single collection script, and it changes how you would use it. The DFIR script answers what is on this machine. The Analysis and Containment directories are for the parts of an incident where the machine is not the only subject, since an analysis script may look at the acquired data and a containment script may act on users, sessions or storage.

The caveat is that the documentation describes the granular scripts only in one sentence, and the permission requirements are documented per script rather than collected in one place. If you plan to rely on the containment scripts, the practical work is reading each one before you need it under pressure.

The same script inside a Live Response session

The second deployment path is Microsoft Defender for Endpoint Live Response, and it is the reason the script is written the way it is.

The documentation describes using the scripts in combination with Live Response, and being explicit that because the script is unsigned a setting change is needed to allow it. The steps are given in order: go to Security.microsoft.com, open Settings, then Endpoints, then Advanced Features, ensure Live Response is enabled, enable Live Response for servers if needed, and enable Live Response unsigned script execution.

From there the workflow is upload, run, retrieve. You go to the device page, initiate a Live Response session, and upload the script to the library. After uploading it, you run the script with the command run DFIR-script.ps1, and the documentation shows the parameter form as run DFIR-Script.ps1 -parameters "-sw 10" if you want to pass options. The collected artefacts come back with the command getfile DFIR-DeviceName-yyyy-mm-dd, which downloads them to your local machine for analysis.

This is the part of the project that most affects its design. The output is a zipped folder whose name contains the hostname and the date precisely because the retrieval step is a file download over the session rather than a person walking up to the machine. The same reasoning explains the CSV export: the responder is somewhere else, looking at files later.

The requirement to enable unsigned script execution is also the sharpest edge. It is a tenant-wide setting in the Defender portal, and turning it on is a decision that belongs to the team running the tenant rather than to the responder in the middle of an incident.

Unsigned scripts and the execution policy bypass

The script is unsigned, and the documentation says plainly that this could result in having to use the execution policy bypass to run it.

The normal invocation is short:

.\DFIR-Script.ps1

and when the policy blocks it, the documented workaround is:

Powershell.exe -ExecutionPolicy Bypass .\DFIR-Script.ps1

This is worth being explicit about rather than glossing over, because it is the kind of detail that decides whether a tool can be used in a regulated environment. A bypass of the execution policy is exactly the switch an organisation forbids by default, and a responder running it on a production host will be asked to explain it. Some organisations will simply not allow it, in which case the Live Response path with unsigned script execution enabled may be the only route, and that setting is a tenant change.

The counterpoint is that unsigned status is normal for this kind of tool. Signing a collection script means shipping a certificate and keeping it valid, and the maintainer has not done that. What matters for your decision is whether you can accept an unsigned script on endpoints in an incident.

Two related blogs are linked from the repository, one on incident response with Live Response and one on version 2 of the scripts, both on kqlquery.com, and they are the best place to look for the reasoning behind the current design.

BSD-3-Clause, version 3, and a last push in May

The licence is BSD-3-Clause, with the licence file at the root of the repository next to the script and the three phase directories. That is a permissive grant with a short notice requirement, which is why this kind of tool tends to be easy to adopt internally compared with copyleft licences. As always, your counsel should confirm how it fits your distribution.

The release history has three tags: V2.0.1 in February 2024, V2.1.0 in March 2024 and V3.0.0 in February 2025, the last one named DFIR PowerShell V3.0.0. A major version bump in a script collection usually means the output format or the scope of collection changed, so a team upgrading from the 2.x line should expect their SIEM mappings to need work.

The last push to the repository was on 2026-05-26, which is a little under five months before this article. That is inside the window where a project can be described as receiving work, but the release cadence tells a more cautious story than the push date does: a version 3 release in February 2025 and no tag since. The repository is not archived and the scripts continue to be referenced, so the honest description is a maintained-in-place collection whose last tagged release is more than a year old.

For a tool that runs against evidence during a live incident, that is an acceptable trade, and it is also the reason to read the script before running it rather than after.

Editorial conclusion

Incident-Response-Powershell suits a responder who needs a defensible first-pass collection from a suspect Windows machine and wants the output in a shape a SIEM can ingest, or who needs to run collection inside a Defender for Endpoint Live Response session on an endpoint they cannot touch. It is the wrong choice if your organisation already has a hardened, tested collection pipeline, because a script that is unsigned and needs an execution policy bypass will not pass many change control processes, and it is the wrong choice if you need collection that does not alter the system at all, since the project does not describe the script as being read only. Verify three things before you use it in a case: that the collection run on the target host does not disturb the state you are trying to prove, that your tenant allows unsigned script execution in Live Response, and that the CSV output, which the documentation says lands in a folder named after the hostname and date and is then zipped, is stored somewhere your evidence handling rules accept.

Frequently asked questions

Official sources

1. Bert-JanP/Incident-Response-Powershell on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases