No single artefact reliably proves that a file was opened, copied, or exfiltrated. Investigators must correlate independent evidence sources, reconstruct a timeline, establish the user's likely actions, and distinguish confirmed data transfer from suspicious preparation or attempted exfiltration.
This article explains how digital forensic investigators can use Windows artefacts to reconstruct a potential data theft incident.
A security team receives an alert indicating that an employee's workstation generated an unusually large outbound transfer shortly before the employee's account was disabled.
The employee had access to confidential business documents. Initial endpoint telemetry shows that several files were accessed, an archive was created, and a removable storage device had recently been connected. However, the original documents remain on the workstation, and the organisation has no direct evidence showing exactly which files left its environment.
The SOC must answer several questions:
Which files were accessed, and when?
Was the activity associated with the employee's account?
Were files copied to another location or collected into an archive?
Was a USB device used?
Did data leave the organisation through a browser, cloud application, or network connection?
Can investigators establish that the transfer succeeded?
Windows forensic artefacts can help reconstruct this sequence. The challenge is that these artefacts record different aspects of system activity, have different retention periods, and may not capture every action.
Windows maintains a variety of records that can provide evidence of file interaction, application execution, device usage, and network activity.
The New Technology File System (NTFS) stores metadata about files and directories. Its Master File Table (MFT) contains records describing files, including names, timestamps, attributes, and references to associated metadata.
Investigators may examine:
File creation and modification timestamps.
Metadata-change timestamps.
File names and directory paths.
File record identifiers.
Relationships between files and directories.
Evidence of deleted file records, where recoverable.
The $STANDARD_INFORMATION and $FILE_NAME attributes can contain timestamp information, but their timestamps may differ because they are updated under different conditions.
Important limitation: NTFS timestamps do not, by themselves, prove that a user opened, read, copied, or exfiltrated a file. Copying a file may preserve some source timestamps while creating new metadata at the destination. Timestamp manipulation and normal application behaviour can also complicate interpretation.
Windows Event Logs can help establish which account was logged in, whether processes were executed, and whether relevant security or system events occurred.
Useful sources include:
ArtefactInvestigative valueSecurity log — Event ID 4624Records successful logons; helps establish account and session contextSecurity log — Event ID 4634Records logoff eventsSecurity log — Event ID 4648Records use of explicit credentialsSecurity log — Event ID 4663Can record an attempt to access an object when appropriate auditing is enabledSecurity log — Event ID 4656Records a request for a handle to an object when auditing is configuredSecurity log — Event ID 4688Records process creation when process-creation auditing is enabledPowerShell Operational log — Event ID 4104May record script-block content when the relevant logging is enabledSystem logMay contain service, driver, and device-related events relevant to the investigationEvent IDs must be interpreted in context. For example, Event ID 4663 may provide evidence of an audited file operation, but it is not generated for every file read on every Windows system. Auditing policy, object-level SACLs, permissions, log retention, and event configuration all affect availability.
Process creation logs can reveal that a utility such as an archiver or scripting engine ran. They do not necessarily prove that the utility successfully processed a particular file.
LNK files are Windows shortcut files that can preserve information about a target file or location. They may be generated when a user opens files through applications or Windows interfaces that create shortcuts.
Depending on the file and how it was created, an LNK artefact may contain:
The target file path.
Target file metadata and timestamps.
Volume information.
Network path details.
Application or shell-related metadata.
LNK files can help establish that Windows recorded a reference to a file at a particular location.
However, a shortcut is not definitive proof that a person opened or read the target file. It may have been generated automatically, created by an application, or left over from earlier activity.
Jump Lists provide application-specific lists of recent or frequent items. They can contain references to documents opened through supported applications and may preserve useful target paths and timestamps.
Investigators can use Jump Lists to identify:
Documents associated with a particular application.
File paths referenced by recent-item records.
Potential relationships between user activity and a suspicious document.
Applications involved in accessing particular file types.
Jump Lists are particularly useful when combined with LNK files, application execution evidence, and user-session logs.
Their limitations are important: not all applications create useful Jump Lists, records may be removed or overwritten, and a listed document does not prove that its contents were read or transmitted.
Windows user profiles may contain evidence of recent file interaction, including shortcut files and application-specific recent-item records.
Common locations include:
%APPDATA%\Microsoft\Windows\Recent\
%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\
%APPDATA%\Microsoft\Windows\Recent\CustomDestinations\
These locations may provide evidence of files referenced through Windows shell features or supported applications.
Investigators should collect relevant artefacts from the correct user profile, including profiles belonging to other accounts that may have used the same workstation. Access permissions, profile cleanup, retention behaviour, and application differences can affect what remains available.
If investigators suspect that data was copied to a USB device, Windows registry artefacts and system logs may help establish device usage.
Potential sources include:
SYSTEM registry hive, particularly USB storage-related configuration.
SYSTEM\CurrentControlSet\Enum\USBSTOR
SYSTEM\MountedDevices
NTUSER.DAT and application-specific user artefacts.
SetupAPI device installation logs, where relevant.
Windows event logs that record device or storage activity in the configured environment.
These artefacts may reveal device identifiers, vendor and product information, volume mappings, or evidence that a removable storage device was recognised.
A USB connection does not prove that files were copied to the device. To establish file transfer, investigators need additional evidence, such as destination files, file-system metadata, copy-related telemetry, or corroborating endpoint logs.
PowerShell, command-line utilities, scripting engines, and archiving applications may be involved in collecting or preparing files for transfer.
Investigators may review:
Security Event ID 4688, if process creation auditing is enabled.
PowerShell Operational Event ID 4104, if script-block logging is enabled.
PowerShell Operational Event ID 4103, where module logging is configured.
EDR process trees and command-line telemetry.
Prefetch files, where available and applicable.
Amcache and application compatibility artefacts.
Application logs and execution traces.
For example, evidence of an archiving utility running shortly after access to sensitive documents may support a hypothesis that the files were collected for transfer.
However, execution evidence alone does not establish which files were archived or whether the archive was successfully transferred. Investigators should seek archive metadata, file-access evidence, command-line arguments, process relationships, and network or cloud transfer records.
The central task in a forensic investigation is to reconstruct a coherent timeline from independent sources.
Consider the following hypothetical incident:
Time (UTC)Observed evidencePossible interpretation08:42Successful logon for a user accountEstablishes a possible interactive session09:03LNK artefact references a confidential documentWindows recorded a reference to the file09:07Audited file-access event for the documentSupports a file-access hypothesis, subject to event details09:14Archiving utility appears in process telemetryPossible preparation of files for collection09:18USB storage device is recognisedEstablishes device presence, not a successful copy09:21Large outbound transfer recorded by network telemetryPotential data transfer requiring destination and application analysis09:26User session endsProvides a timeline boundary, not proof of intentThis sequence is suspicious, but it does not independently prove exfiltration. Investigators must establish whether the events share the same host, user session, process lineage, file paths, and relevant time window.
The timeline should include both supporting and contradictory evidence. For example, an outbound transfer might relate to an approved software update, while a USB device may have been used for an unrelated task.
Before correlating artefacts, investigators should record:
The original timestamp.
The source artefact and its timestamp format.
The relevant time zone or whether the timestamp is stored in UTC.
Any conversion applied.
The system clock state, where known.
The estimated precision and reliability of the timestamp.
Windows artefacts do not all use the same timestamp conventions. NTFS timestamps are generally represented in UTC internally, while some logs and forensic tools display timestamps in local time or convert them automatically. Incorrect conversion can create a misleading sequence of events.
File access, file copying, and data exfiltration are separate claims.
A file may be opened without being copied. It may be copied locally without leaving the workstation. It may be compressed without being uploaded. Finally, an upload attempt may fail before any data reaches an external destination.
Investigators should seek evidence at each stage.
Potential evidence includes:
Object-access auditing, if enabled.
Application records and file references.
LNK files and Jump Lists.
EDR file-access telemetry, if available.
Relevant application or document-management logs.
The objective is to determine whether the file was likely accessed during the period under investigation.
Look for:
Destination files with matching content hashes.
File creation events or metadata changes.
File-copy telemetry from EDR or data protection tools.
Removable-storage activity.
Archive creation and file lists, where recoverable.
Relevant command-line or script evidence.
A matching hash can help establish that two files have identical content, assuming the hash was calculated reliably. It does not, by itself, prove when the copy occurred or who created it.
Review:
Proxy and firewall records.
DNS and network connection logs.
Browser history and download/upload records where available.
Cloud storage audit events.
DLP alerts.
Endpoint telemetry showing file uploads or application transfers.
Server-side records from the destination service, where lawfully available.
Network volume and timing can support a transfer hypothesis, but encrypted traffic and shared connections may prevent investigators from identifying the exact files transmitted. A confirmed exfiltration finding should rely on evidence that establishes successful transfer, rather than merely showing an outbound connection.
A common data theft scenario involves copying corporate documents to a personal cloud storage account, webmail service, or unauthorised file-sharing platform.
Potential evidence sources include:
Browser history and download databases.
Browser session and cache artefacts, where available.
Windows file-access and process telemetry.
EDR records of browser processes accessing local files.
Proxy logs and secure web gateway records.
DNS and firewall logs.
Cloud application audit logs.
DLP events identifying sensitive files or upload activity.
Browser history can establish that a site was visited, but it rarely proves that a particular file was successfully uploaded. Browser caches may contain relevant material, but their contents vary by browser, configuration, and application behaviour.
Cloud audit records can be particularly valuable because they may identify the account, file name, operation, timestamp, and result. Investigators should preserve these records promptly because service retention policies may limit their availability.
A practical workflow for a suspected Windows data exfiltration incident is:
1. Identify the endpoint and user session. Establish the hostname, user SID, logon sessions, and relevant time window.
2. Preserve volatile and time-sensitive evidence. Follow the organisation's incident response procedures, prioritising evidence likely to disappear or be overwritten.
3. Collect disk and log artefacts. Acquire relevant registry hives, Windows event logs, NTFS metadata, LNK files, Jump Lists, application artefacts, and endpoint telemetry.
4. Identify sensitive files. Establish their original paths, hashes, ownership, sensitivity labels, and access permissions.
5. Reconstruct file interaction. Correlate file references, audited access events, process execution, and application activity.
6. Investigate copying and staging. Search for duplicate files, archives, removable-storage evidence, and copy-related telemetry.
7. Correlate network and cloud activity. Identify relevant destinations, transfer records, cloud audit events, and evidence of successful or failed uploads.
8. Validate authorisation. Check change requests, access approvals, business justification, and approved data-transfer processes.
9. Assess impact and confidence. Identify the files potentially affected, the evidence supporting each finding, and the limitations that remain.
10. Document the conclusion. Distinguish confirmed facts, supported inferences, unresolved questions, and recommended response actions.
Forensic conclusions are only as reliable as the evidence supporting them.
Investigators should follow established acquisition and evidence-handling procedures:
Preserve original logs and source artefacts before analysis whenever practicable.
Document the acquisition method, date, time, operator, and source system.
Calculate cryptographic hashes for acquired evidence and relevant exported files.
Maintain chain-of-custody records where required.
Record time-zone conversions and tool versions.
Restrict access to evidence containing personal or confidential information.
Work from verified forensic copies when possible.
Document missing logs, overwritten records, and other collection limitations.
Live response may require changes to a system, including process termination, network isolation, or account restriction. When that is necessary, record the action, its rationale, its time, and any expected impact on evidence.
The following techniques may be relevant if supported by the collected evidence:
TechniqueATT&CK IDRelevanceFile and Directory DiscoveryT1083Evidence of activity used to locate files and directoriesData from Local SystemT1005Collection of relevant data from the local systemArchive Collected DataT1560Evidence that data was archived before transferData StagedT1074Evidence that collected data was gathered in a staging locationExfiltration Over Web ServiceT1567Evidence supporting transfer through a web serviceExfiltration Over Web ProtocolT1567.002Evidence supporting exfiltration over an applicable web protocolATT&CK mapping should describe observed behaviour, not replace forensic proof. For example, the presence of an archive does not establish that its contents were exfiltrated. Select the most specific technique supported by the evidence and verify the mapping against the current ATT&CK knowledge base.
Reference: https://attack.mitre.org/
A shortcut provides evidence that Windows recorded a reference to a target. Corroborate it with other artefacts before concluding that a user opened or read the file.
Device recognition establishes that a device was connected or detected. Additional evidence is needed to establish file copying.
A large outbound transfer may be legitimate. Identify the destination, application, transfer result, relevant account, and relationship to the suspected files.
Timestamp semantics differ across artefacts. Normalise time zones, document conversions, and consider clock drift and timestamp manipulation.
The absence of an event does not necessarily mean that an action did not occur. Auditing may have been disabled, logging may not have been configured, and records may have expired or been overwritten.
A session may have been compromised, shared, or controlled through a service or remote access mechanism. Use independent identity and endpoint evidence to establish attribution.
Organisations can make future investigations more effective by improving both prevention and telemetry.
Enable appropriate file-system auditing for sensitive directories and configure suitable SACLs.
Centralise Windows event logs and protect them from unauthorised modification.
Deploy EDR telemetry capable of recording relevant process, file and network activity.
Monitor removable-storage usage and apply device control policies where appropriate.
Apply DLP controls to sensitive files and high-risk transfer channels.
Review uploads to personal cloud storage and unauthorised web applications.
Apply least privilege and periodically review access to confidential data.
Protect privileged accounts with strong authentication and controlled elevation.
Retain logs long enough to support realistic investigation timelines.
Test detection rules against legitimate business workflows to reduce false positives.
Detection quality improves when file access, process activity, identity events, and data-transfer telemetry can be correlated using reliable timestamps and shared identifiers.
Reconstructing file access and exfiltration using Windows artefacts requires investigators to combine file-system metadata, event logs, shortcut records, Jump Lists, registry evidence, process telemetry, and network or cloud records.
Each artefact answers a different question. Some show that a file was referenced, others reveal audited access or application execution, and still others may establish that data was transferred. The strongest findings emerge when independent sources support the same timeline and alternative explanations have been assessed.
For SOC analysts and digital forensic investigators, the key principle is simple: prove each stage separately. Establish file access, identify collection or copying, and then determine whether transfer succeeded. This produces a more defensible incident report and helps organisations respond without overstating what the evidence proves.
MITRE ATT&CK
Microsoft Learn — Windows Security Auditing
Microsoft Learn — Windows Event Logs
NIST — Guide to Integrating Forensic Techniques into Incident Response
Continue reading
Insider Threats
[{"type":"text","text":" Privileged employees often have legitimate access to sensitive databases as part of their daily responsibilities. However, excessive permissions, compromis...
Insider Threats
[{"type":"text","text":" Data theft through personal cloud storage and USB devices occurs when sensitive organisational information is copied or transferred outside approved system...
Insider Threats
[{"type":"text","text":" Intellectual property (IP) theft before employee resignation occurs when an employee deliberately collects, copies, or transfers proprietary organisational...
3 entries, most recent posts.
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker th...
Senior Hosting Security Engineer
The convergence of Operational Technology (OT), the Internet of Things (IoT), and traditional enterprise IT networks is transforming how organisations...
