Educational reference
Digital Evidence Artefacts and Forensic Tools Guide
A practical introduction to records that may answer common evidence questions across Windows, macOS, Linux and widely used applications, with examples of tools that can assist an examiner.
Artefacts support an inference, not an automatic conclusion · Tool output requires examiner review · Availability changes by version and retention
How to use this guide
Begin with the question, then identify possible sources
A digital artefact is a record produced or retained by a device, operating system, application or service. It might help show that a file existed, a program ran, an account connected, a device was attached or data moved. It rarely answers the whole case question by itself. The meaning of a record depends on the version that created it, the collection method, timing, retention and its relationship with other evidence.
This public guide is a curated educational sample drawn from larger working catalogues. It deliberately excludes exact evidence paths, credential material, offensive use notes and collection commands. The entries are examples, not a universal checklist, product endorsement or promise that a source will exist in a particular matter. A current examination plan should be based on the actual source and lawful authority available.
The example projects and official references show where a parser, format library or application documentation can be investigated further. They do not replace validation. A mature examination may combine commercial software, open-source utilities, operating-system tools, manual inspection and bespoke code. Relevant versions, settings, warnings and unsupported records should be recorded, and important results checked against source data or another suitable method where proportionate.
For focused service context, see Office document forensic analysis, messaging and communications review, WhatsApp messaging evidence and PDF and digital document analysis.
Nine useful evidence questions
- Was a file created, copied, renamed or deleted?
- What document properties, revisions, notes, formulas, links or signatures remain?
- Was removable storage connected or used?
- Did an account log on locally or remotely?
- Did a cloud or transfer application handle a file?
- What browser visits or downloads are recorded?
- Did a program run, and in which user context?
- What email, message or meeting records remain?
- What can logs and volatile data show after a cyber incident?
Four checks before interpreting a row
- Version. Format and meaning can change between operating-system or application releases.
- Retention. Logs rotate, journals wrap, cloud records expire and user action can remove local data.
- Attribution. A device, account or file record does not automatically identify the human actor or intention.
- Correlation. A conclusion is stronger when independent records agree and apparent conflicts are explained.
Curated catalogue
Representative artefacts and analysis references
Use the search and system filter to narrow the examples. With scripting unavailable, every row remains visible. The source links lead to an official application reference or an open-source project commonly used to help parse the type of record described.
43 entries shown
Swipe or scroll sideways to compare all five columns.
| Artefact or source | System | What it may help show | Important limit | Example reference |
|---|---|---|---|---|
| NTFS Master File Table | Windows | File and directory names, relationships, sizes, attributes and several timestamps, including records relating to deleted items. | Reused records and manipulated timestamps require correlation with journals, transaction data and content. | The Sleuth Kit |
| NTFS USN Change Journal | Windows | A sequence of file creation, deletion, rename and change notifications linked to file references. | The journal wraps, can contain gaps and records a change reason rather than the actor or file content. | Dissect |
| Recycle Bin metadata | Windows | The original path, deletion time, size and user security identifier associated with a recycled item. | The Recycle Bin can be emptied or bypassed, and records may be overwritten. | Plaso |
| Shortcut and Jump List records | Windows | Interaction with files, applications, local volumes, network locations and removable media. | A shortcut may be created automatically. It does not by itself prove a file was read or changed by a named person. | Plaso |
| Amcache and UserAssist Registry records | Windows | Different forms of program presence and user-interface activity that can support an execution chronology. | Coverage and semantics differ by Windows release. Program presence is not the same as execution, and no single source records every execution route. | RegRippy Registry framework |
| Windows event logs | Windows | Logon, service, scheduled-task, security, remote-session and application events, where the relevant channels were enabled and retained. | Logs rotate and can be cleared. Event meaning depends on channel configuration, identifiers and surrounding records. | Hayabusa |
| Device installation and USB history | Windows | Identifiers and timing relevant to storage or other devices connected to a computer. | Installation time is not necessarily every connection time, and a connected device does not prove a particular file transfer. | Velociraptor |
| System Resource Usage Monitor | Windows | Sampled application, user, network and resource use over intervals, which can corroborate activity or data movement. | Sampling is not an exact start and stop log, and account and application mappings must be resolved carefully. | libesedb |
| FSEvents | macOS | Coarse change history for files and directories across an Apple file-system volume. | Events may be coalesced, directory level or missing. They do not identify the actor or preserve file content. | mac_apt |
| Apple Unified Log | macOS | Process, security, network and application events that can contribute to a device or incident chronology. | Private fields may be redacted, retention varies and the format changes between macOS releases. | mac_apt |
| Quarantine Events | macOS | Download provenance, including the application involved and possible source or origin URL. | Not every download produces a retained record, and a recorded download is not proof that content was opened. | mac_apt |
| KnowledgeC activity records | macOS | Application, device and focus events that may support an activity chronology. | Schema and stream meaning change. A system event should not automatically be described as deliberate user action. | mac_apt |
| Spotlight metadata | macOS | Indexed file properties, authorship fields, content types and sometimes stale information about items no longer visible. | Indexing can be disabled, delayed or rebuilt, and indexed fields are not a substitute for the source file. | mac_apt |
| Apple Mail local stores and index | macOS | Locally retained messages, headers, account and mailbox context, flags and attachment relationships. | The index can be stale, and a synchronised mailbox can be partial or cloud-only. A local copy does not prove server delivery or completeness. | mac_apt |
| Apple Messages records and attachments | macOS | Conversation and handle records, service type, message times, reactions and attachment relationships retained on the Mac. | Storage formats change, while synchronisation, retention, deletion and collection scope affect coverage. An account or handle does not by itself identify the human sender. | mac_apt |
| systemd journal | Linux | Structured service, kernel, authentication and application records with boot and process context. | Persistent logging may be disabled, records can be vacuumed and access restrictions may limit fields. | systemd |
| Authentication logs | Linux | SSH, sudo, PAM and session activity, including users, source addresses and results where configured. | Location, detail and rotation depend on distribution and configuration. A successful account login is not proof of the human user. | UAC |
| Linux Audit records | Linux | Configured syscall, process, file, identity and policy events, often with strong process and user context. | Value depends on the active rules and backlog. One logical event may span several records. | Plaso |
| Shell history and session records | Linux | User-entered commands and sometimes timing or terminal-session information. | History can be disabled, edited or left unwritten after an abrupt exit, and it does not capture every execution route. | UAC |
| Chromium browser profiles | Applications | History, searches, downloads, sessions, extensions and related records from Chrome, Edge, Brave and other Chromium browsers. | Profile scope, synchronisation, private browsing and retention affect completeness. A visit record does not prove who viewed a page. | Hindsight |
| Office Open XML package properties | Applications | Declared creator and last-modified-by values, created and modified fields, revision labels and custom properties retained in an Office package. | These values can be edited, copied from a template or regenerated by software. They do not prove human authorship, and their times need application and time-zone context. | Microsoft package-properties reference |
| Word comments | Applications | Comment text, the marked document range and declared author, initials and date fields where the comments remain in the DOCX package. | Author and date fields are editable labels rather than identity proof. Comments can be removed, so their absence is not proof that none existed earlier. | Microsoft Open XML comments reference |
| Word tracked revisions | Applications | Retained insertion, deletion, move and property-change markup that may help compare the document with the visible final text. | Accepting or rejecting changes, or saving through another format or workflow, can remove revision markup. Tracked changes are not a complete editing history, and declared authors need corroboration. | Microsoft Open XML revisions reference |
| Excel formulas, links and calculation records | Applications | Formula text, external-workbook references and the recorded order in which cells were last calculated may help identify dependencies and test a workbook account. | Cached results can be stale, external sources may be unavailable, and a calculation chain can be absent or regenerated. These structures are not an audit trail of every edit. | Microsoft SpreadsheetML structure |
| PowerPoint notes, comments and media | Applications | Speaker notes, slide comments and linked or embedded audio, video and images that may not appear in a simple printout or slide image. | Exporting or flattening can omit these parts. Comment author fields are editable, and speaker notes do not prove that the words were delivered at a meeting. | Microsoft PresentationML structure |
| PDF incremental-update structure | Applications | Appended objects, cross-reference information and trailers may preserve structural evidence of successive saves and earlier object versions. | A full rewrite or optimisation can discard that history. An incremental save does not identify the person responsible or prove that a meaningful visible change was made. | qpdf inspection reference |
| PDF digital signatures | Applications | Signature dictionaries, covered byte ranges, certificate information and validation results may help identify the signed revision and later changes. | A signature image is not a cryptographic signature. Validation depends on the original bytes, certificate trust, time, revocation information and any changes permitted after signing. | Adobe signature-validation guidance |
| Native email and MIME records | Applications | Addresses, message identifiers, date fields, Received headers, multipart structure and attachment data retained in a native message. | Some fields are supplied by the sender and can be false or altered by export and forwarding. A saved message alone does not prove server delivery, account control or human authorship. | IETF message format and MIME format |
| Outlook PST and OST stores | Applications | Messages, headers, folders, attachments, calendar and account context available in a local Microsoft Outlook data file. | Cached stores may be partial or stale, while server retention and collection scope can produce a different result. | libpff |
| Thunderbird profiles and MBOX stores | Applications | Locally held messages, native headers, folder relationships, attachments and account settings within the collected profile. | Cached IMAP content can be partial and search indexes can be stale. Compaction may remove deleted message bodies, while profile and application versions affect interpretation. | Mozilla Thunderbird profile guidance |
| OneDrive synchronisation records | Applications | Configured accounts, local roots, item identities, operations and errors relevant to cloud file movement. | Client schemas change, cloud-only items may leave limited local data and local logs are not a complete cloud audit. | Microsoft sync documentation |
| Microsoft Teams cloud records | Applications | Chat, channel, meeting, file and attachment records that may be held across several Microsoft 365 locations and made available for authorised eDiscovery. | Coverage depends on tenant, content type, custodian, permissions and retention. One export or storage location should not be assumed to contain the complete conversation. | Microsoft Teams eDiscovery guidance |
| Microsoft Teams client data | Applications | Local cache and application records may retain account or tenant identifiers, meeting and file URLs, client versions and fragments relevant to a device chronology. | The client generation and platform matter, caches can be cleared, and local remnants are not an authoritative or complete copy of cloud messages. | Microsoft Teams cache guidance |
| Slack workspace exports | Applications | Messages, channel records, membership context and file links available within an authorised workspace export. | Available content depends on the plan, permissions, approved export type and date range. Export files can contain links rather than the underlying files. | Slack export guidance |
| Signal Desktop application data | Applications | Linked-device, account, conversation, attachment or application context where local material is retained and lawfully accessible. | Encryption, disappearing messages and synchronisation can limit content. Authentication material is sensitive and must be protected. | Signal Desktop project |
| Android SMS and MMS provider records | Android / mobile | Addresses, message bodies or subjects, direction, status, dates and MMS participant or attachment parts where those provider records were collected. | Access and fields vary by Android version, device, application and extraction method. The provider does not cover every messaging app, and deleted-record recovery is not assured. | Android Telephony provider reference |
| WinSCP session and transfer logs | Applications | Destinations, connection settings and, where logging was enabled, uploaded, downloaded or deleted files and results. | Logging is optional, configuration can be portable and a stored destination does not prove a completed transfer. | WinSCP logging documentation |
| AnyDesk trace files | Applications | Client identities, connection direction, partner identifiers, session timing, service events and file-transfer context where recorded. | Paths and fields vary by version. Legitimate support use must be distinguished from unauthorised access through wider evidence. | AnyDesk trace documentation |
| Zoom recordings and meeting files | Applications | Locally retained video, audio, transcript, chat and sidecar material relevant to a meeting chronology. | Local files may be edited or incomplete and do not represent the provider’s full meeting or account audit. | Zoom support reference |
| Live memory and process state | Applications | Volatile processes, loaded code, open files, connections and other state that may disappear when a system is shut down. | Acquisition changes live state, contains sensitive data and has version-specific coverage. It requires a justified, controlled method. | Volatility 3 |
| Companies House register | Public sources | Public company status, filings, officers and registered particulars relevant to entity research in the United Kingdom. | Register entries may contain errors or lag events. A name match does not establish that two people are the same person. | Companies House |
| Internet Archive Wayback Machine | Public sources | Historical captures that may help show how a public web page appeared at an earlier point. | Coverage is selective and timestamps record capture, not necessarily publication. Embedded or blocked content may be absent. | Wayback Machine |
| Certificate Transparency search | Public sources | Public certificate records that can identify names associated with issued web certificates and support infrastructure research. | Issuance does not prove current control, hosting, use or malicious activity, and wildcard certificates require careful interpretation. | crt.sh |
No catalogue entries match those filters. Clear a filter or try a broader term.
Lawful public-source research
OSINT is preservation and corroboration, not licence to intrude
Open-source intelligence can help preserve a public web page, identify the history of a company or domain, or corroborate a timeline. It should be scoped to a legitimate evidence question and the legal authority of the client. Public visibility does not remove data-protection, privacy, privilege, platform or procedural considerations.
The small selection above is deliberately conservative. It does not reproduce the raw OSINT tool list or offer a surveillance service. Collection should record the URL or query, date and time, account state where relevant, method, resulting files and enough context for another person to understand what was publicly available. A screenshot alone may omit page source, redirects, embedded resources and capture conditions.
OSINT, breach-exposure and online security posture assessment
Does an artefact prove that a named person carried out an action?
Usually not by itself. A record may identify a device, account, profile or process. Attribution to a human may need access evidence, witness material, account history and other corroboration. Shared devices, remote access, synchronisation and compromise are possible competing explanations that should be considered where supported.
Does one forensic tool provide the definitive answer?
No. Tools implement parsers and workflows with their own supported versions and limits. A result becomes useful evidence through a reasoned examination of the source, not because a familiar product generated it. An important finding may need manual checking, a second parser or comparison with another artefact.
Why might a relevant record be absent?
The feature may not have been enabled, the record may have rotated, the source may have been deleted or overwritten, a cloud export may be incomplete, or the collection may not include the right profile or period. Absence should be explained in terms of expected source behaviour rather than treated automatically as proof that an event did not happen.
For legal teams
Turn a broad concern into answerable questions
The catalogue can help identify possible records, but an instruction should not demand every artefact on the list. State the allegation or disputed proposition, the people and systems involved, the relevant period, sources already preserved and the decision the work must inform. The examiner can then propose a proportionate source set and explain gaps.
For civil proceedings, see digital evidence expert support for civil litigation. For criminal cases, see digital forensic expert support for criminal defence.
For organisations
Preserve before routine administration removes context
Device reissue, operating-system reset, mailbox deletion, log rotation, account closure and incident clean-up can change or destroy relevant records. That does not mean every system should be copied without limit. Identify the decision, authority, custodians, source owners and retention risk, then plan the least intrusive collection that preserves what is reasonably required.
See forensic data collection for on-site and remote options, or post-breach forensic investigation for evidence review after a cyber incident.
Case-specific scoping
Which records could answer your evidence question?
Send the party names, issue, relevant systems, date range and deadline, but not the evidence itself. If the instruction is within scope, Alistair can propose a proportionate examination and an itemised estimate.