MemProcFS-Analyzer and the case for a memory triage that runs itself

One script that installs, mounts and triages

MemProcFS-Analyzer.ps1 is a PowerShell script for simplifying the use of MemProcFS and for optimising a memory analysis workflow. The repository description calls it automated forensic analysis of Windows memory dumps for DFIR, and the topics list covers digital forensics, incident response, live response and memory forensics.

The dependency on MemProcFS is the centre of the design. MemProcFS is the memory process file system by Ulf Frisk, and the analyzer's main trick is that you can mount a memory snapshot, whether a raw physical memory dump or a Microsoft crash dump, like a disk image, and handle the memory compression feature on Windows. Once mounted, the dump is browsable as a drive letter, and the rest of the tooling operates on files that look like ordinary files.

That is a large ergonomic win for an analyst under time pressure. The alternative is assembling MemProcFS, a parser for every artefact type, an event log processing tool, a scanner and an IP mapping client by hand, which is where most of the evening goes.

The script also does the unglamorous work of pulling in the rest of the toolchain. The auto-install list covers MemProcFS itself, AmcacheParser, AppCompatCacheParser, Elasticsearch, entropy, EvtxECmd, ImportExcel, IPinfo CLI, jq, Kibana, lnk_parser, RECmd, SBECmd, xsv, YARA and Zircolite, and there is a matching auto-update list, plus a notice when a new ClamAV version or a new Dokany File System Library Bundle is available.

The repository layout is small, which tells you the bulk of the logic lives in one file: `MemProcFS-Analyzer.ps1` at the root, with `Scripts/`, `Tools/`, `Updater.ps1`, `Screenshots/`, a `CHANGELOG.md` and a `LICENSE`.

The first pass is broad: processes, injection, network and files

The analysis features fall into a few recognisable groups, and reading them is the fastest way to understand what the script does for you.

On process behaviour, it builds a process tree in a tree view including the complete process call chain, checks processes for unusual parent-child relationships and unusual numbers of instances, and checks for unusual user context. It also looks for process path masquerading and process name masquerading, using Damerau Levenshtein distance for the name comparison. That last check is the kind of thing that catches a renamed binary sitting in a temp directory, and it is not something you would write from scratch during an incident.

On artefacts, it analyses the extracted Amcache.hve with AmcacheParser, the Application Compatibility Cache with AppCompatCacheParser, and Syscache, UserAssist, ShellBags, auto-start extensibility points, RecentDocs and Office trusted documents with RECmd, including a DFIR batch file for registry analysis by Andrew Rathbun. It provides a simple prefetch view based on Forensic Timeline, extracts Windows shortcut files and hunts malicious ones, and offers metadata analysis of recovered process modules, which the README marks as experimental.

On network and host context, it extracts IPv4 and IPv6 addresses, does IP2ASN mapping and GeoIP with the IPinfo CLI, checks for suspicious port numbers, and provides web browser history for Chrome, Edge and Firefox.

Two features stand out because they involve other engines. The multi-threaded scan with ClamAV for Windows collects infected files for further analysis, and MemProcFS PE_INJECT detection collects injected modules the same way. Both are explicitly framed as collection for further analysis rather than as verdicts.

Event logs get a timeline, and the outputs are CSVs

The event log handling is where the script leans on the wider Eric Zimmerman toolset, and it is the part that most affects the shape of the output.

Windows event log files are extracted and processed with EvtxECmd into a Timeline Explorer, and the script provides an event log overview. Beyond that, event logs are processed with Zircolite, a standalone SIGMA-based detection tool for EVTX, which means the script and it runs detection rules over them as well as converting logs into a timeline.

The output format is worth noting because it affects what you can do afterwards. The script produces CSV output data for analysis with Timeline Explorer, and the README names three of them: timeline-reverse.csv, findevil.csv and web.csv. CSV is a good choice for a first pass, because it drops into other tooling without ceremony, and a poor one for an evidence package where the native format and the exact tool version matter.

The script also collects evidence files into a Secure Archive Container, which is how the README describes gathering what you intend to keep.

For a custom detection workflow, the script can scan with custom YARA rules, and the README notes that this includes 447 rules contributed by projects such as Chronicle and Elastic Security. That is a substantial starting rule set, and it is also a starting point rather than your own coverage.

Running it means Administrator PowerShell and a few first-run dialogs

The usage section is short. Launch Windows PowerShell, or Windows PowerShell ISE, or Visual Studio Code with PowerShell version 5.1, as Administrator, and open or run `MemProcFS-Analyzer.ps1`.

The screenshots in the README walk through the first run in order. You select your memory snapshot and, optionally, your pagefile.sys. The script then auto-installs its dependencies, which the README marks as the first run. You accept the terms of use of the Microsoft symbol store, which is a separate first-run step, and after that the dump is mounted and you investigate it by exploring the drive letter. On a second run the script checks for updates.

Two practical points come out of that sequence. First, the first run needs network access, because the toolchain is downloaded rather than bundled. Second, the updater keeps running afterwards, and the README explicitly recommends uncommenting or disabling the Updater function after installation, pointing at the Main section at the bottom of the script.

That recommendation is worth taking seriously in a lab environment. A tool that rewrites its own dependencies between runs makes the output of the second analysis different from the first, which is a problem when you are comparing runs or defending a finding later.

The dependency auto-update is a feature and a liability

The auto-install and auto-update lists are the reason this script is worth using, and they are also the reason to think before you use it in a case.

The upside is concrete. A responder does not have to know that `RECmd` parses Syscache, that `SBECmd` handles ShimCache, that `AmcacheParser` handles the Amcache hive, or that `EvtxECmd` is what turns event logs into a timeline. The script knows, and it installs the right version of each.

The downside follows directly. The analysis depends on third-party binaries whose versions change, and the script updates them on its own schedule. Two runs of the same dump a week apart may use different parsers and different detection rules, and the README does not document a mechanism for pinning versions. The bundled YARA rule set, the SIGMA-based event log checks and the ClamAV signature database are all moving targets.

That is why the README's own advice to disable the updater after installation matters. For a triage workstation, an auto-updating sweep is a reasonable convenience. For evidence that will be examined by someone else, you want to know exactly which version of each tool produced the output, and the script does not offer that guarantee out of the box.

Where the tool stops, and what to do instead

Two limits are visible in the README and the usage instructions. The first is the platform. The usage instructions name Windows PowerShell, Windows PowerShell ISE or Visual Studio Code with PowerShell 5.1, and the workflow is built around mounting a Windows memory image and parsing Windows artefacts such as Amcache, ShimCache, Syscache, UserAssist, ShellBags, LNK files and Windows event logs. There is no Linux or macOS path described.

The second is that this is a first pass. The features that matter most for a real case, injected modules and infected files, are described as collections for further analysis, and the recovered process module metadata is marked experimental. A finding from this tool is a lead, not a conclusion.

The alternative is to use the same components yourself, which the README's own feature list describes in detail. Mounting the image with MemProcFS and then driving RECmd, SBECmd, AmcacheParser, EvtxECmd and your own YARA rules gives you control over versions, over which artefacts are parsed, and over how findings are recorded. The cost is the setup time the script was built to remove, and the risk of missing an artefact type you did not know to look for.

A middle path exists. Use the script to mount the image and to gather the artefacts, then do the parsing with pinned, recorded versions of the same tools the script would have used. The output format the script already expects, CSV for Timeline Explorer, fits that workflow well.

Releases, licence and the shape of the project

The releases are MemProcFS-Analyzer v1.2.1 from 2026-04-20, v1.2.0 from 2025-06-24 and v1.1.0 from 2024-09-03. The repository is not archived, and the last push was on 2026-08-31. The README carries a badge describing the maintenance level as actively developed, and a further one for a valid digital signature on the release artefact.

That signature badge is a meaningful detail for a forensic tool. It tells you the published binary is signed, so the analysis environment can be verified before it runs against evidence, rather than trusted on the basis of a download URL.

The licence is GPL-3.0, with the text in the LICENSE file at the root. For a tool you run internally during an investigation, the copyleft obligations are not usually the interesting part, but anyone planning to modify the script and distribute it, or to build a service on top of it, needs to read what that licence requires.

The project sits in the LETHAL-FORENSICS organisation alongside other DFIR tooling, with a wiki linked from the README badges for the detailed documentation, including a dedicated Process Tree page, and a `CHANGELOG.md` in the repository for the release history. The upstream project it builds on, MemProcFS by Ulf Frisk, is the piece to sponsor if you find this useful, as the README asks.

Editorial conclusion

MemProcFS-Analyzer is the right starting point for a responder who has a raw memory image or a Microsoft crash dump, needs it mounted and triaged quickly, and wants the common artefacts parsed without assembling the toolchain by hand. It is the wrong choice for an evidence workflow that requires a documented, reproducible acquisition and parsing chain, since the script installs and updates its own dependencies, and for an analyst who needs to run a single tool rather than a sweep. Verify first that your environment matches the one the script expects, Windows PowerShell or Windows PowerShell ISE or Visual Studio Code with PowerShell version 5.1, run as Administrator, and decide on the updater before the first run, because the README recommends disabling it once installation is done.

Frequently asked questions

Official sources

1. Issues
2. LETHAL-FORENSICS/MemProcFS-Analyzer on GitHub
3. License: GPL-3.0
4. README
5. Releases