Live Forensicator: collecting artefacts from a host that is still running

A collector that runs on the live host, not an image parser

The positioning is the first thing to understand. Live Forensicator is a cross-platform forensic artefact collector, designed to help forensic investigators and incident responders rapidly collect system and user activity artefacts from a live host or device, with the collected artefacts uploaded to Forensicator Core for analysis. The collector also bundles a built-in HTML report for quick triage along the way.

So the division of labour is: Live Forensicator gathers and does a first pass, Forensicator Core does the deeper analysis. That split matters because it determines what you can expect from the collector itself.

The three capabilities are listed plainly. It collects system and user activity artefacts, ready for Forensicator Core upload. It generates structured, investigation-ready HTML reports. And it performs built-in triage, detecting anomalous behaviour and suspicious indicators and highlighting potential compromise or misconfiguration on the spot.

Running against a live system is the reason this class of tool exists. A disk image gives you a snapshot of files; a live collector can read artefacts that exist only in memory or in locked structures, which on Windows means registry hives, $MFT, $UsnJrnl, SRUDB.dat, Windows.edb and the ActivitiesCache database. On the Windows collector those are reached through a Volume Shadow Copy snapshot, which is a live-system technique by definition.

The primary language of the repository is PowerShell, and the tree shows four separate implementations, Windows/, MacOS/, Linux/ and Network/, which is the central structural fact of this project and the reason its coverage differs by platform.

Windows gets the deepest artifact set, and it says so

The Windows collector is the most detailed of the four, and the artefact list is long enough to be worth reading as a checklist of what an investigation needs.

The Windows Artifact Analysis collection is opt-in, and it covers Shimcache, Amcache, Prefetch, UserAssist, BAM, Autoruns, LNK files, Jump Lists, Shellbag, $MFT, $UsnJrnl, SRUM, Defender quarantine, WER, the Windows Search database, the Recycle Bin, Notifications, BITS and the Windows Timeline artefacts. It also collects each registry hive's own .LOG1 and .LOG2 transaction logs, which exist so Forensicator Core can replay them into a more complete hive. All of that goes through a Volume Shadow Copy snapshot so the collector can reach locked registry hives, $MFT, $UsnJrnl:$J, SRUDB.dat, Windows.edb, wpndatabase.db and ActivitiesCache.db.

The event log side is described as advanced collection: System, Security and Application as raw .evtx, plus a configurable richer channel list covering Sysmon, Defender Operational, PowerShell, TaskScheduler, WMI-Activity, BITS-Client and RDP, exported as Core-ready single-line Event XML for the Log Analysis feature.

Three smaller Windows capabilities are easy to overlook and useful in practice. Windows Defender tamper-protection state and the current exclusion configuration are captured as standalone findings, which tells you whether an attacker disabled the protections before running. Browser history extraction comes with IOC matching built in. And the investigation archive is produced alongside structured JSON output, with optional AES encryption of the artefacts.

The reason the Windows list is longer than the others is visible in the artefact names themselves. Most of them are Windows-specific structures, and the ones that are not, such as the Timeline and the Windows Search database, exist in the same form only on Windows.

Sigma, hashes and what the built-in triage actually checks

The detection layer is the part that turns a collector into something an analyst can use without a second tool.

On Windows the triage consists of a Sigma rule engine with 1,400 or more community rules, known-Event-ID detection, and malware hash matching against feeds such as abuse.ch. The Sigma engine is opt-in through config.json with the key sigma.enabled, and it is off by default, with the reason given: it is a real-time scan with meaningful runtime and log-query cost.

That default is worth respecting. A collector that silently spends several minutes evaluating a thousand rules on a production server during an incident is a collector that gets run in a hurry, so making it an explicit choice is the right call for the people who have to make it under pressure.

Every finding comes with a Detection Insight, described as a summary of the detection, why it matters, the detection logic, what to look for, and its MITRE mapping. The network collector has the same pattern, with a plain-language explanation, MITRE ATT&CK mapping and recommendations on every finding, using the same knowledge-base approach as the Windows collector.

Then there is Forensicator AI, optional, giving per-finding AI verdicts from a local Ollama model or a commercial LLM, shown in the report's tooltip. The local option is the interesting one for an investigation, because a finding verdict generated by a model running on the analyst's own machine does not send evidence to a third party, and the tool works with either a local model or a hosted one.

The macOS and Linux engines are described in more behavioural terms. The macOS detection engine covers reverse shells, SIP, Gatekeeper and kext tampering, PATH hijacking, deleted-binary execution and credential timestomping, plus a best-effort Sigma engine sourced from real SigmaHQ community rules evaluated against the unified log, malware hash matching and browser history IOC matching with auto-updating abuse.ch and URLhaus feeds, and application code-signature verification. The Linux engine covers reverse shells, timestomping, PATH hijacking, deleted-binary execution and package integrity, with a Sigma engine evaluated against auditd and journald where available, and malware hash and malicious URL matching with the same auto-updating feeds.

Where coverage actually breaks down, platform by platform

The README is unusually honest about the gaps, and these notes are the most useful part of the page for anyone planning an investigation.

On macOS, real process-creation telemetry is restricted to the Endpoint Security Framework, which a plain script cannot access, so the Sigma coverage is narrower there than on Windows or Linux. The macOS README is the place to look for the specifics. This is not a defect in the collector so much as a property of the operating system: a script cannot see what only an authorised endpoint security client can see.

On Linux, the scripts are written to avoid non-native utilities, for example net-tools, for maximum compatibility, and the Sigma coverage depends on whether auditd is already configured on the target box. That second point is a real operational trap. If auditd is not running, the kernel audit stream that Sigma rules for Linux expect is simply not there, and the rules that depend on it will not fire. A collector that reports no findings may be reporting accurately.

The network collector has a different shape of limitation. It talks to network infrastructure over SSH rather than running on the host being investigated, so it needs a reachable device. Its detection coverage is listed as 21 rules covering unauthorized local accounts, an insecure management plane with Telnet, weak SNMP and missing AAA, logic-implant persistence through EEM applets and task schedulers, boot-image and config-section tampering, NTP and syslog tampering, brute-force login patterns, unexpected SPAN sessions and tunnel interfaces, loosened ACLs, and device-to-C2 and transit-traffic-to-known-malicious-IP detection.

The network collector is also the most conservative in the ways that matter during an incident. It is read-only by design, every collected command is non-mutating, and no configuration changes are ever made to a device. It uses SSH-based collection via Netmiko against Cisco IOS and IOS-XE, Cisco NX-OS, Arista EOS, Juniper Junos and VyOS, and it isolates errors per device so one unreachable device never aborts the rest of the run, with concurrent multi-device collection and a self-contained HTML report per device.

Configuration lives in config.json, and baselines are declared not inferred

The network collector describes a config-driven baseline model that is worth understanding because it is a good pattern for the other collectors too. The device inventory, the per-rule toggles and every rule's expected-value baseline are all set in config.json, with no code changes needed to tune a deployment.

The expected-value baseline is the interesting part. A detection rule on a network device has to decide what normal looks like before it can call something abnormal, and for things like a local account list, a management plane configuration or a NTP setup, the normal state differs per organisation. Declaring the baseline in configuration means the rule fires on deviation from what you said the device should look like, rather than on a generic heuristic.

The same applies to the Windows collector, where the Sigma engine is toggled through the config.json key sigma.enabled. The distinction between detection code and detection policy is one of the healthier things in this project, and it is why the configuration story is worth reading before you deploy it.

For the Windows artefact collection itself, the collection is opt-in as a whole, which is a second layer of the same idea. A tool that grabs everything by default is a tool that will be run with the default settings, and the default settings should be the ones that are safe to run against a production machine during an incident.

The three host platforms also share the optional AES artefact encryption and the structured JSON output, which is what makes the Forensicator Core upload path work the same way everywhere.

What to check before you run it on someone else's machine

This is a collector that executes on systems under investigation, often while they are still in production, so the operational questions come before the analytical ones.

The first is what it touches and when. The Windows artefact analysis collection is opt-in precisely because it is invasive, taking a Volume Shadow Copy snapshot to reach locked files, and running the Sigma engine adds real-time log queries. Both are decisions you make per collection, and both are worth making explicitly rather than accepting whatever the default is.

The second is the platform gap, which is the note in the README about macOS Endpoint Security Framework access and about Linux auditd being required for full Sigma coverage. If you are collecting from a Mac, plan for narrower detection coverage. If you are collecting from a Linux host, check whether auditd is running before you interpret a quiet result.

The third is transport and evidence handling. The artefacts can be encrypted with AES, the output is a structured JSON archive for Forensicator Core plus an HTML report, and the network collector is read-only by design with no configuration changes ever made. Those are good properties, and the read-only guarantee on network gear is the one most worth holding the tool to, because an incident response tool that changes a firewall during collection is a tool that can destroy evidence.

The release history shows active work: v4.2.0 from 2026-08-09, which introduced Forensicator AI on Windows, v4.1.4 from 2026-05-16 and the Nightingale release, 4.1.1, from 2026-03-23. The last push was on 2026-10-19 and the project is not archived, and the licence is Apache-2.0 with the homepage at forensicator.io.

Editorial conclusion

Adopt Live Forensicator if you need evidence from a machine you cannot take offline, and you want the collection step and the first triage pass in one tool, because the collectors reach into live sources such as Volume Shadow Copy on Windows and the unified log on macOS that a disk image cannot give you. Do not adopt it expecting identical detection coverage everywhere, because the README is explicit that macOS Sigma coverage is narrower and that Linux coverage depends on whether auditd is already configured on the target. Before you run it, read the platform README for the operating system you are collecting from, and check whether the Sigma engine is enabled, since it is off by default on Windows for runtime and log-query cost.

Frequently asked questions

Official sources

1. Johnng007/Live-Forensicator on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases