ajmartel/irtriage

1. Repository purpose

- This is an incident-response triage toolkit for Windows endpoints.

- The main job of the project is to collect forensic artifacts quickly from a live machine without imaging the full disk.

2. Primary runtime entry point

- The top-level IRTriage.au3 / IRTriage.exe is the core application.

- It is an AutoIt-based GUI that orchestrates data collection, likely with per-category tabs and options.

- The UI is the control plane; the collected data is the output plane.

3. Evidence collection workflow

- The application creates a new output folder named with hostname + date/time.

- It gathers artifacts such as:

- system information

- network information

- registry hives

- disk metadata

- memory dumps

- It also records activity into IncidentLog.csv and command-execution logs.

4. Local toolchain boundary

- Almost all functionality depends on bundled binaries under Compile/Tools rather than external installations.

- This makes the repo effectively a portable triage workstation packaged inside the project.

- The application invokes these helpers as subprocesses and captures their outputs into the case folder.

5. Forensic subsystems

- The toolkit is composed of several forensic subdomains:

- memory acquisition: Moonsols Win32/64dd or FDpro

- registry analysis: RegRipper

- filesystem / disk analysis: The Sleuth Kit

- prefetch / artifact viewing: NirSoft utilities

- process and system enumeration: Sysinternals utilities and Windows built-ins

- These are not separate services; they are integrated command-line dependencies.

6. Volume Shadow Copy support

- A notable capability is collecting from Volume Shadow Copy.

- Architecturally, this means the tool is not limited to the live filesystem state; it can pull artifacts from historical snapshots to help defeat simple anti-forensic deletion.

7. Built-in command layer

- The repo includes a custom ReactOS-derived cmd.exe in Compile/Tools/cmd.exe.

- The README indicates it adds Linux-like aliases and forensic-oriented commands such as privilege and info.

- This shell acts as an auxiliary command interpreter for analysts during triage, not as the main application UI.

8. Update and maintenance subsystem

- The Compile/Tools/Updater folder suggests an update-check / downloader utility.

- The project appears to support checking GitHub-hosted updates and downloading newer tool/app versions.

- Update.nfo and the README’s version notes reinforce that the project has a lightweight update distribution path.

9. Packaged tool families

- The Compile/Tools tree is organized by vendor/tool family:

- SysinternalsSuite

- SleuthKit

- RegRipper2.8

- NirSoft

- UnixUtils

- Moonsols

- Malware-Hunters

- Each folder is a deployment boundary for a specific class of triage capability, which is useful when drawing the architecture as pluggable external helpers.

10. Output artifacts and analyst handoff

- The outputs are designed for offline analyst review, not immediate remediation.

- Key outputs include CSV logs, parsed artifact exports, copied registry hives, disk listings, and memory capture files.

- The Docs folder supports this handoff with comparison material and triage help documents.

11. Operational constraint

- The tool is intended to run locally on the evidence machine, ideally from a USB drive.

- Because memory dumping may require space larger than installed RAM, storage capacity is a practical architectural constraint.

- The app tries to elevate to Administrator automatically on supported Windows versions, which is necessary for many collection actions.

12. How to think about the architecture

- The cleanest diagram is: Analyst launches IRTriage GUI → GUI selects modules → AutoIt script orchestrates local CLI tools → artifacts are written into a case folder + CSV logs → analyst reviews outputs or updates tooling.

- The external boundaries are the Windows endpoint being triaged, the bundled helper binaries, and optionally GitHub/update resources for maintenance.