How can investigators use cloud provider logs to distinguish file creation vs. sync events?
Executive summary
Investigators can separate true local file creation from cloud-driven sync/materialize operations by correlating client‑side filesystem events, provider telemetry and transfer/session metadata — looking for distinct event types, timestamps, transfer IDs, and content hashes — and by using OS and provider diagnostic channels such as Windows CFAPI/ETW, macOS File Provider events, and cloud logging/telemetry [1] [2] [3]. No single log source is authoritative in every environment; practical attribution requires stitching multiple logs and acknowledging gaps where providers or clients do not expose needed details [1] [4].
1. Understand what each log layer records
Windows Cloud Files API (CFAPI) surfaces callbacks for deletes and renames but not local creates/edits, so a sync engine must log its own callbacks and developers should instrument FETCH_DATA/CANCEL_FETCH_DATA/ENUMERATE_CHILDREN events to get visibility [1]. macOS file provider generates distinct ESF events such as MATERIALIZE for downloads (new file creation from cloud) and UPDATE for updates to existing files, which can be observed from fileproviderd activity [2]. Cloud platforms expose centralized logging and activity traces (e.g., Google Cloud Logging) that capture API calls and service actions but require correlating those entries with client logs to prove causation [3].
2. Key signals that distinguish “created locally” from “synced/materialized”
A local creation typically produces a FILE_ACTION_ADDED / FILE_ACTION_MODIFIED entry from directory watchers like ReadDirectoryChangesW on Windows and a single create event in local event collectors [1] [5]. A materialize or sync-from-cloud shows provider-initiated access patterns: callbacks to fetch data (CFAPI FETCH_DATA), provider download events, or ESF materialize/update events on macOS [1] [2]. Cloud-side records will often show an object read or transfer tied to a storage API call or recall/recall session metrics (Azure File Sync logs include recall session and per-item recall counts) that line up with client materialize activity [6].
3. Correlation strategy: timestamps, transfer/session IDs, and content fingerprints
Investigators should correlate fine‑grained filesystem timestamps (create/modify/attrib) and directory-watch events with provider telemetry timestamps and transfer/session identifiers; CFAPI implementations are encouraged to emit structured ETW/TraceLogging so callbacks can be matched to cloud actions [1]. Cloud logging platforms provide request IDs and trace fields that can be joined to client logs to show a provider read/download preceding a local materialize [3]. When available, compare file content hashes or sizes from client and cloud metadata to confirm the file was streamed from the cloud rather than locally authored (limitation: specific guidance for hashing appears in some provider logs but is not universally described in these sources).
4. Practical tooling and evidence sources to collect
On Windows, collect Event Viewer (Microsoft > Windows > CloudFiles > Operational), ETW traces for cldflt.sys and filesystem activity, plus any sync engine’s own TraceLogging; ProcMon can show low‑level IRPs and FSCTL behavior to spot provider servicing [1]. On macOS, gather Endpoint Security/File Provider events and fileproviderd logs to find MATERIALIZE/UPDATE notifications [2]. From cloud/storage side, pull audit logs and transfer/recall events (e.g., Azure File Sync Event IDs for recalls and tiering) and centralized cloud logging traces for API calls [6] [3]. Many NAS/cloud sync products keep job logs but they vary in detail and sometimes lack clear “upload vs download” markers, so capture the most verbose logs available [7] [4].
5. Pitfalls, ambiguities, and when the evidence is insufficient
Filesystem watchers can emit noisy, out‑of‑order or aggregated events (large deletes/renames require preprocessing) that mask intent, and some sync engines intentionally collapse events to reduce cloud requests making one local action map to many provider operations or vice versa [5]. CFAPI itself has no built‑in programmable logging so investigators rely on the sync engine’s instrumentation — if the provider didn’t implement logging, the trace will be incomplete [1]. Cloud logs vary by vendor; absence of a matching cloud request does not prove local creation if logging was filtered or not retained [3].
6. Best practice checklist for forensic attribution
Collect client directory‑watch events and kernel/ETW traces, harvest provider callback logs and any transfer/session IDs, pull cloud audit and transfer logs, compare timestamps and content fingerprints, and document gaps where no instrumentation exists; this multi‑source stitching is necessary because no single source is guaranteed to show both a local create event and the cloud‑initiated materialize action [1] [6] [3]. If provider or client logs are missing, state the limitation rather than over‑attributing causation [1].