File access pattern analysis should baseline which users and processes read, write, delete, or rename files, then alert on unusual volume, timing, or sequence. Pay attention to rapid enumeration, access to many sensitive locations, and repeated failures. Correlate with account and endpoint activity to distinguish backups, indexing, and normal application behaviour from exfiltration or ransomware.
What to baseline when analysing file access patterns
Start with a clean baseline of who normally touches which files, how often, and from where. That baseline should include both users and processes, because many legitimate file operations are automated and easy to misread if you only look at human activity. The useful unit is not just “file opened”, but the normal pattern of reads, writes, deletes, renames, and directory traversal.
Good baselines are environment specific. File access in finance, engineering, legal, and backup systems looks very different, so the threshold for unusual activity should reflect role, workstation, server, and time of day. MITRE D3FEND Guide is useful here because it frames file access monitoring as part of a broader defensive control set, not a standalone alert rule.
When you define the baseline, separate ordinary bulk activity from suspicious bulk activity. Backups, indexing, file synchronisation, content search, and build pipelines can all generate large volumes of file events, but they usually do so with stable timing, known hosts, and predictable file sets.
Which patterns matter most for detection
The most useful detections look for deviation in volume, timing, and sequence. Rapid enumeration across many folders, access to many sensitive locations in a short window, repeated failed attempts, and a sudden shift from read-heavy behaviour to delete or rename activity are all stronger signals than a single isolated file event.
Sequence matters because many attacks are behaviourally noisy before they become destructive. A user or process that normally reads a narrow set of files but suddenly sweeps through shared drives, project folders, or sensitive archives can be showing discovery, staging, or exfiltration behaviour. If the same actor then starts compressing, copying, renaming, or deleting at scale, the risk rises sharply.
Context matters as much as the file event itself. Correlate file activity with account logons, endpoint process launches, remote sessions, and privilege changes so you can distinguish legitimate admin work from unusual access paths. Correlation is especially important when the same process can be started by a user, by a script, or by remote execution tooling.
How to reduce false positives without missing abuse
Not every spike is malicious. The best practice is to whitelist known backup jobs, search crawlers, deployment tools, and maintenance windows, but only after you confirm the owning account, host, and expected file scope. A rule that suppresses “large file activity” without checking the process and path details will miss real abuse.
Use least-privilege file permissions and clear ownership boundaries to make suspicious access stand out. If a service account can read far more than it needs, then unusual file access is harder to interpret and easier to hide. Cloud Workload Identity Guide is a useful adjacent resource when the same access problem appears in workload and service identity contexts.
Also watch for repeated access failures. Failed reads, denied deletes, and repeated attempts against protected locations often appear before successful abuse, especially when an attacker is probing for useful data or testing what the account can reach. Those failures are valuable because they can reveal intent even before exfiltration begins.
Risk and Threat Considerations
File access anomalies often become a warning sign for either data theft or destructive activity. The main risk is that an apparently ordinary user or process can use legitimate file permissions to stage sensitive data, move laterally across shared storage, or prepare a ransomware event without tripping simple malware controls.
Failure mechanism: Broad file visibility, weak permission boundaries, and poor correlation between file events and account activity let abnormal access blend into routine operations until the volume or sequence becomes extreme.
Impact: You can miss early exfiltration, overlook staging before encryption or deletion, and lose the chance to contain the source account or process before material data loss occurs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1005 — Data from Local System | File access analysis often detects collection and staging from local or shared storage. |
| T1074 — Data Staged | Bulk reads, renames, and sensitive-path sweeps often precede data staging for exfiltration. | |
| T1485 — Data Destruction | Repeated deletes and rename-heavy sequences can signal destructive file activity. | |
| Recommendation — Map abnormal read patterns to T1005 and investigate for local collection and staging activity. Correlate file sweeps with T1074 indicators and look for staging before exfiltration. Treat unusual delete or rename bursts as T1485 and validate for destructive intent. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | File access analysis depends on collecting and reviewing file, process, and account telemetry. |
| Recommendation — Centralise file and endpoint logs so unusual access patterns can be baselined and alerted on. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | This topic relies on analysing audit events to find unusual file access behaviour. |
| Recommendation — Review audit records for anomalous file access patterns and escalate suspicious sequences. | ||
Practitioner Guidance
What to prioritise: Start with the file sets that matter most, such as sensitive shares, source repositories, customer records, and administrative paths. Then tune detections around the actors that are allowed to touch them so you are hunting exceptions, not normal batch jobs.
What to verify: For each alert, confirm the account, endpoint, process tree, and destination path before escalating. A real issue usually shows a mismatch between the actor, the file scope, and the usual time or workflow for that system.
Practitioner takeaway: The strongest file-access detections are behavioural, not volume-only, and they work best when you can explain the access path as well as the file event itself.