DFIRArtifactMuseum: sample forensic artifacts catalogued by operating system

A museum of samples, organised by operating system

The stated purpose of DFIRArtifactMuseum is to increase accessibility to sample artifacts without individual researchers duplicating the effort to generate data that, in the project's phrasing, should be done once and shared so that more time goes into analysis rather than artifact generation. It is described as a community-driven archive of DFIR-related artifacts created to provide a centralised location for examples from various operating systems.

The organisation is visible in the top level of the repository, and it is as simple as it gets: one directory per platform, Android/, Cloud/, iOS/, Linux/, macOS/, Windows/ and WindowsPhone/, plus a CONTRIBUTING.md, a LICENSE and a logo. The repository topics list android, artifacts-repository, dfir, ios, linux, macos and windows, which matches the directory set exactly. The primary language is listed as HTML, which is consistent with a repository whose content is largely browsable files rather than code.

There is no software here to install. The deliverable is the data. A forensic artifact is an application-generated trace of activity, such as a browser history file, a prefetch entry, a registry hive or a mobile container, and each of these has a different internal structure per platform and per version. Collecting them by hand is the expensive part, and that is the part this archive takes over.

Why a shared corpus changes tool development

The second stated benefit is about exposure across platforms. Someone who never uses Linux can get familiar with what Linux artifacts look like, and the same applies in the other direction for a Linux-only user meeting Windows artifacts. That is a training benefit, but the more concrete one is the third benefit listed: people who build tools get sample data to write a parser against, and having an artifact readily available removes a major obstacle between having an idea for a parsing tool and actually creating and sharing it.

That is the workflow this repository exists for. A parser author needs a file whose structure they know, ideally a pristine one, so that a failing parse is a bug in the parser rather than an artefact of the data. Without a shared corpus, every author generates their own sample, and two tools written by different people end up tested against different bytes.

The related projects section reinforces the pattern. EVTX-ETW-Resources is described as holding XML and CSV files with every Event ID and Event Message for every Event Provider for nearly every major version of Windows 8, 10 and 11 and Windows Server 2016, 2019 and 2022, with one CSV per version enumerating providers and event IDs. VanillaWindowsRegistryHives is described as raw registry hives from a post-clean install plus JSON dumps from the topmost ROOT key, which is explicitly framed as a way to see what is normal in the registry before user activity kicks in. VanillaWindowsReference is a directory listing of every file in a clean install with filenames, parent folders, hash values and file sizes. The ArtifactParsers list is offered as a place to find parsers for the artifacts in this repository, separated by whether they are CLI or GUI.

Those three sibling repositories are also the honest alternative to building your own sample set, and they cover the Windows case more thoroughly than this one does.

Attribution is not optional in this repository

The Licensing and Source Attribution section is the longest part of the visible documentation and the part an engineer should read first. Each artifact family names its origin and the permission under which it was included. Android 7 to 10 images come from Digital Corpora, with explicit permission from Josh Hickman and under public domain. Android 11 and 12 come from Josh Hickman's blog, again with explicit permission. Belkasoft CTF artifacts are included with explicit permission from the CTF page. Eric Zimmerman's artifacts are included with explicit permission, and the list names specific upstream test file sets, including AppCompatCacheParser, JumpList, Lnk and MFT.

Two things follow from that structure. First, permission was granted to this repository for specific artifact families, and a downstream user redistributing those files inherits questions that the archive itself answered. The MIT licence in the LICENSE file covers the repository's own contribution, not the third-party artifacts folded into it, which is why this section has to be read rather than skimmed.

Second, the mechanics of a contribution are more involved than adding a folder. CONTRIBUTING.md is pointed to for guidance, and the roadmap is tracked on the project boards rather than in a text file. A repository that accepts third-party forensic data has to police the boundary between an artifact someone generated themselves and an artifact copied from someone else's case, and the fact that this project documents permissions per family shows the author treats that as a live concern.

What you get, and what you do not get

There is no index, no manifest and no query layer. The repository holds directories of artifacts and lets you browse them. For a project of this size, that is both the appeal and the problem: cloning gives you everything, and there is no way to fetch just the one folder you need without a shallow clone or a sparse checkout, and the documentation does not describe either.

There are no GitHub releases, so there is no versioned artifact set to pin. The repository is not archived, and the last push was on 2026-07-14, which is a little over three months before the present date. That is recent enough that content is still changing, and there is no tag or release cadence to make a specific state of the corpus reproducible. A team that builds a parser test suite on top of these samples should record the commit hash itself.

The topic list includes android and ios, and the directory set includes Cloud/ and WindowsPhone/, but the visible documentation only details the Android and Windows artifact families in the attribution section. The scope of what sits inside macOS/, iOS/, Cloud/ and WindowsPhone/ is not described in the copy of the documentation available here, so anyone planning a Linux or macOS focused analysis should browse those directories directly rather than assume a comparable depth.

Where this archive is the wrong tool

There are cases where pulling sample artifacts is worse than useless. The first is live incident response. Samples in a public repository are, by construction, files that other people have already studied and published, so they carry almost no evidentiary value in an actual case. Nobody should point a timeline at them, and no chain of custody is documented for any of it. This is training and tooling material, not evidence.

The second is any workflow that needs a complete, version-controlled corpus. If you are building automated detection rules and want every artifact of a given class for a given OS version, a browsable directory with no manifest will cost you an afternoon of inventory work, and it will break again the next time somebody commits.

The third is a legal or contractual review. The per-family attribution means the answer to can we ship this file to a customer is a per-artifact question with a dozen different upstream sources and permissions, and the documentation does not state a blanket grant. If artifacts are going to end up embedded in a product, in a training set sold commercially, or in a repository that customers can pull, that needs a separate decision, and this review does not make it.

The genuinely different alternative is generating your own artifacts. On a virtual machine you control, you can produce a file of exactly the shape your parser needs, you know precisely which version and configuration produced it, and you can regenerate it on demand. The cost is time per artifact and the loss of community breadth, and for a parser author the shared corpus is usually a shortcut worth taking; for a detection engineer shipping rules to customers, own data is the safer foundation.

Getting the archive and reading what is inside

There is no installer, no package and no script, so the only setup step is getting the repository. The project points at its own project boards for the to-do lists and at CONTRIBUTING.md for guidance on contributing, and the sister repositories above are reachable from the same account.

A sensible first session is to browse rather than to clone. Open the Windows/ directory and the Linux/ directory side by side, check which OS versions have coverage, and see whether the artifact types in there match the ones your tooling parses. If the answer is yes, clone the repository and take a copy for the files you need, because a full clone of a sample repository can be large and because the acceptance criteria for contributed artifacts are described in CONTRIBUTING.md rather than in the README.

If your interest is Windows specifically, the two sibling repositories are more targeted. VanillaWindowsRegistryHives gives you raw hives and JSON dumps from a clean install, and VanillaWindowsReference gives you a CSV of every file in a clean install with hashes and sizes, which is the reference you want when deciding whether a path is normal. For Windows event data, EVTX-ETW-Resources covers event IDs and providers per Windows version. Use the museum for breadth across platforms, and those for depth on Windows.

Editorial conclusion

DFIRArtifactMuseum is worth pulling locally when you are writing or validating a parser and need a known-good sample of what a Windows registry hive, a Linux artifact or an iOS container looks like before user activity touches it. It is the wrong tool for live response data, for anything that needs a chain of custody, and for a production pipeline, since there is no release stream, no versioning scheme and no automated fetch beyond a plain clone. Before relying on it, read CONTRIBUTING.md for the submission rules, check the Licensing and Source Attribution section for the origin and permitted use of each artifact family, and record the commit you cloned so a later pull does not silently change the samples your parser was tested against.

Frequently asked questions

Official sources

1. AndrewRathbun/DFIRArtifactMuseum on GitHub
2. Issues
3. License: MIT
4. README