File system activity

About 7 min read

On this page
05 of 06

File system telemetry exposes persistence, payload deployment, ransomware staging and exfiltration staging. Tracking create, modify, delete and (where captured) read events, plus file metadata, reconstructs what landed, when, and from where.

Adversaries modify legitimate files, hide payloads among ordinary ones, and lean on living-off-the-land techniques (abusing the system’s own trusted utilities) to do it. A seemingly benign file like C:\ProgramData\1.dat followed by registry modifications under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run fits the persistence-staging pattern exactly. Tying that to a parent process and outbound connection completes the picture.

The four lifecycle events

01

Creation

New executables, DLLs, or configuration files in non-standard locations. %APPDATA%, %LOCALAPPDATA%, %PROGRAMDATA%, %TEMP%. PowerShell creating DLLs in user directories. regsvr32.exe writing unexpected files.

02

Modification

Unexpected changes to system binaries, DLLs, or configuration files. Monitor C:\Windows\System32 for tampering. Watch trusted application directories for sideloading.

03

Deletion

Sudden removal of logs, binaries, or staging files often signals cleanup (ATT&CK T1070). Watch for log clearing (Security 1102, System 104; on Linux, truncated /var/log files or a stopped journald), which is itself logged and survives the clear.

04

Access patterns

Large-scale sequential reads of sensitive datasets (customer databases, financial records, intellectual property) point to data staging, where you can see them. Windows logs file reads (event 4663) only for objects with an auditing SACL, and Sysmon has no ordinary file-read event, so read visibility usually needs SACLs or a DLP or file-activity product. Missing read telemetry is a visibility gap, not evidence that no access happened.

Know your source

None of the four events above exists unless something recorded it, and most of them are not recorded by default. Know which source feeds your console before you read an empty result as “nothing happened.”

Creates and streams

Sysmon Event 11 (file create) or the EDR’s file events. Sysmon Event 15 records alternate data streams, including the Zone.Identifier stream that carries the Mark of the Web.

Timestamps

Sysmon Event 2 (file creation time changed). In the MFT, compare $STANDARD_INFORMATION times, which tools can rewrite, with $FILE_NAME times, which they usually do not. The USN journal records each change in order.

Deletes and reads

Sysmon Event 23 (delete, with the file archived) or 26 (delete logged). Reads appear only as Security 4663 where a SACL exists, which is rare, so “no read events” is usually a visibility gap.

macOS and Linux

On macOS, Endpoint Security file events through the EDR. On Linux, auditd file watches or eBPF sensors. Both record only what the agent or rule set was configured to watch.

Annotated sample: where a file came from

Trimmed and fictional; the field names are real. A Sysmon Event ID 15 (FileCreateStreamHash) record for a document saved from a browser:

UtcTime=2026-03-10 14:19:47.260  ProcessGuid={6a1f0c3e-2b61-65f0-1d07-000000001a00}
Image=C:\Program Files\Google\Chrome\Application\chrome.exe
TargetFilename=C:\Users\jdoe\Downloads\remittance.docm:Zone.Identifier
Contents=[ZoneTransfer]  ZoneId=3  ReferrerUrl=https://webmail.example/  HostUrl=https://docs-transfer.example/f/remittance.docm
  • The :Zone.Identifier suffix is the alternate data stream that carries the Mark of the Web. Contents holds its text, which Sysmon records for small streams.
  • ZoneId=3 is the Internet zone. That is what makes Office block the document’s macros by default, and what SmartScreen and other controls key on.
  • HostUrl and ReferrerUrl say where the file came from and which page linked to it: treat the host as an IOC and pivot on it in proxy and DNS logs.
  • Image is the process that wrote the file, and its ProcessGuid links the download to the process tree. A file that arrived from the internet with no Zone.Identifier stream at all had its mark stripped somewhere (an archive tool, a container, or a user unblocking it), and that is worth a line in the record.

Suspicious patterns by category

Persistence mechanisms

  • Windows: Run and RunOnce keys under HKLM\Software\Microsoft\Windows\CurrentVersion\Run or the HKCU equivalent (T1547.001), and new files in the Startup folder (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup)
  • Scheduled tasks with obfuscated commands or unusual triggers (T1053.005)
  • DLL Search Order Hijacking A DLL-hijacking technique that places a malicious DLL where an application looks for libraries before the legitimate location, so a trusted, signed binary loads attacker code. Attackers use it for persistence, privilege escalation, and to hide execution inside a trusted process. Current ATT&CK groups it with side-loading, phantom-DLL hijacking, DLL redirection, and DLL substitution under ATT&CK T1574.001 "DLL" (mapped in v19 to Stealth and Execution). Side-loading is the sibling variant: the attacker plants a legitimate application next to the malicious DLL and runs it. Detected by watching for DLLs, especially unsigned ones loaded by signed binaries, that load from application or user-writable directories instead of their expected system paths. and side-loading via malicious DLLs in application directories (T1574.001)
  • COM hijacking (T1546.015): a new HKCU\Software\Classes\CLSID{…}\InprocServer32 value pointing at a DLL in a user-writable path. Per-user registrations take precedence over the HKLM registration in the merged HKCR view, so no admin rights are needed.
  • macOS: new plists in ~/Library/LaunchAgents or /Library/LaunchDaemons, and new login items
  • Linux: new cron entries, systemd unit files, authorized_keys changes, /etc/ld.so.preload

Payload deployment

  • New or unsigned executables in C:\Windows\System32 (compare against the gold image), and executables in folders under C:\Windows that standard users can write to by default, such as C:\Windows\Tasks, C:\Windows\Temp, or C:\Windows\System32\spool\drivers\color, which attackers use to slip past path-based allowlisting
  • Files with double extensions (invoice.pdf.exe)
  • DLLs created in temporary or user folders
  • Origin markers: the Mark of the Web (the Zone.Identifier stream records that a file came from the internet, and often the URL it came from) missing from a file that was downloaded, and on macOS the quarantine extended attribute removed from a downloaded binary

Ransomware activity

  • Backup and recovery destruction just before encryption (vssadmin delete shadows, wbadmin delete catalog, bcdedit /set recoveryenabled no; T1490), seen in process telemetry, usually minutes before the encryption starts
  • One process rewriting thousands of files at high rate, with a newly appended extension (often random or family-specific, such as .akira) or none; high-volume partial overwrites with no rename are intermittent encryption
  • Ransom notes appearing across many directories
  • On ESXi hosts, VMDK files under /vmfs/volumes renamed or rewritten after VMs are killed, often where no EDR agent runs
  • In cloud storage, objects rewritten with customer-provided keys (AWS SSE-C)
  • Most ransomware operations steal data before they encrypt (double extortion), so an encryption finding also opens the exfiltration question: look for archives and transfer tools in the days before (see Exfiltration staging). Theft-only extortion leaves no encryption artifacts at all.

Exfiltration staging

  • Large compressed archives (.zip, .rar, .7z) containing sensitive data appearing shortly before outbound transfers (T1074, T1560)
  • Sync and transfer tools (rclone, MEGA clients) appearing on a host that has never used them

File metadata that matters

Parsing Breaking a raw alert, log line, or command string into its component fields so each can be examined on its own: the user, the host, the action, the time. In triage, parsing the alert is the first move; the details that decide a verdict live in the fields, not in the alert name. Alert parsing and log parsing are the same move applied to different inputs. has to do more than catch file events. The metadata on each file is where the signal often lives.


The residue of fileless and LOLBin tradecraft

Fileless and LOLBin tradecraft is covered under process relationships; on the file system, look for its residue: the WMI repository (OBJECTS.DATA) changing, certutil’s URL cache, and prefetch entries for LOLBins.

File system activity frequently precedes exfiltration. Creating compressed archives in %TEMP% shortly before outbound connections to low-reputation domains is a near-canonical pattern, especially when 7-Zip or WinRAR runs with a password flag and rclone or a MEGA client follows.

Check yourself

A Sysmon Event 11 shows C:\Windows\Tasks\svch0st.exe created by powershell.exe under a standard user. The file is signed, the signature validates, and the signer is a small software company nobody in the fleet has heard of. Its section entropy is 7.4. Parse it before you open the answer: which of these facts carry weight, and which do not?

One way to answer

The weight sits in the path and the name: C:\Windows\Tasks is writable by standard users and is a classic allowlisting bypass, and svch0st.exe imitates a system binary that never lives there. The creator (PowerShell, standard user) says a script dropped it. The valid signature only says who signed it; a signer no peer uses is closer to a stolen or throwaway certificate than to a vendor, so it clears nothing. Entropy of 7.4 says “look”, not “malicious”. Next: the PowerShell process’s command line and its 4104 script blocks, the file’s Mark of the Web, and whether the binary ran.

Key takeaway

File system parsing gives you the longest tail of intrusion evidence. Combined with process and network telemetry, it is the layer that turns “something happened” into “here is exactly what happened, in order, with timestamps.”

Next up

Cloud and identity logs

Parse the control plane: CloudTrail anatomy, role chains, the IMDS pattern, IdP sign-in logs, and identity attacks at protocol depth.

Read cloud & identity

Technical details verified . Product names, defaults and retention change; check your own tenant.

Edit this page on GitHub Report a correction