Log Dejargonizer

Sysmon · Event 11

Sysmon Event 11: A file was created

A process created or overwrote a file. It is how you find a dropped payload, how you spot ransomware early, and how you tie a download to the process that fetched it — provided your configuration filters it down to the paths that matter.

Also written as Sysmon 11Sysmon Event ID 11FileCreateSysmon file created

What it means for you

On a personal computer

Only present if you installed Sysmon. It records files being created, which is useful for understanding what a program did but produces an enormous amount of data.

For an analyst

Filter aggressively in the configuration — startup folders, scheduled task directories, temp paths, and script extensions give most of the value at a fraction of the volume. Note that Event 11 records creation only; modification of an existing file does not appear here, which surprises people.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
File created:
  RuleName: -
  UtcTime: 2026-08-28 09:14:09.001
  ProcessGuid: {a1b2c3d4-0000-0000-0000-00000000abcd}
  ProcessId: 7412
  Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  TargetFilename: C:\Users\jbrooks\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\update.vbs
  CreationUtcTime: 2026-08-28 09:14:09.001
  User: CORP\jbrooks

The fields that decide it

Everything else in the log line is context.

Image
The process that created the file. A shell or Office application writing an executable is the pairing to watch.
TargetFilename
The file that was created. The path matters as much as the name.
  • A path under Startup or Start Menu\Programs\StartupA file placed here runs at every sign-in. Classic persistence.
  • A path under \Windows\Tasks or \System32\TasksScheduled task definitions, another persistence route.
  • A path under AppData\Local\TempWhere downloads and droppers land. Very high volume, so filter by extension.
  • An executable or script extension in a user profilePrograms in user-writable locations are worth noticing.
  • A .lnk file in a user directoryShortcuts are used both legitimately and for persistence.
CreationUtcTime
When the file was created. Compare it against the file's own timestamps to spot timestomping.
User
The account the writing process runs under.
ProcessGuid
Join on this to see the full command line of the process that wrote the file.

Ordinary reasons this happens

Most of the time it is one of these.

  • Ordinary use — every document saved, every download, every temporary file.
  • Software installation and updates writing hundreds of files at once.
  • Browsers writing to their cache constantly, which is a large share of the volume.
  • Backup and synchronisation software writing copies.
  • Compilers and build tools producing output on developer machines.
  • Windows itself writing logs, telemetry, and update files.

When it is not ordinary

A downloaded payload landing on disk.

What gives it awayAn executable or script written to a temp or user profile directory by a browser, a shell, or an Office application.

ATT&CK T1105

Persistence through a startup folder.

What gives it awayAny file written to a Startup directory by something other than an installer.

ATT&CK T1547.001

Ransomware encrypting files.

What gives it awayOne process creating very large numbers of files in a short window, often with a consistent new extension, across user document directories.

ATT&CK T1486

Web shell dropped on a server.

What gives it awayA script file written into a web root directory by the web server process itself.

ATT&CK T1505.003

Staging data before exfiltration.

What gives it awayArchive files being created in a temp directory by a process that does not normally produce archives.

ATT&CK T1074.001

What to do next

  1. Read the process and the path together. Either alone is usually meaningless.
  2. Join on ProcessGuid to Sysmon Event 1 for the command line that explains the write.
  3. Check whether the path is one that grants execution — startup folders, task directories, web roots.
  4. For a suspected payload, check Sysmon Event 3 and 22 for the same process to find where it came from.
  5. For a burst of file creations, count the rate. Ransomware produces a rate no legitimate process matches.
  6. Compare the creation time against the file's other timestamps to spot deliberate manipulation.

Queries to run

kql Anything written to a startup folder. Very low volume and consistently worth reading. 
Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 11 | where TargetFilename has_any ('\\Startup\\','\\Start Menu\\Programs\\Startup') | project TimeGenerated, Computer, Image, TargetFilename, User
kql Office applications and shells writing executable content — the dropper pattern. 
Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 11 | extend Proc = tostring(split(Image, '\\')[-1]) | where Proc in~ ('winword.exe','excel.exe','outlook.exe','powershell.exe','mshta.exe') and TargetFilename matches regex @'\.(exe|dll|ps1|vbs|js|bat|scr)$' | project TimeGenerated, Computer, Proc, TargetFilename
kql Extreme file creation rates. Ransomware shows up here long before anything else notices. 
Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 11 | summarize files = count() by Image, Computer, bin(TimeGenerated, 1m) | where files > 500 | order by files desc
splunk 
index=sysmon EventCode=11 TargetFilename="*\\Startup\\*" | table _time host Image TargetFilename User

Common questions

Does Sysmon Event 11 record file modifications?

No. It fires on creation and on overwrite, but editing an existing file in place does not produce one. That surprises people who expect it to be a general file-activity monitor — for modification tracking you need Windows object access auditing or a dedicated file integrity tool.

How do I stop Sysmon Event 11 from flooding my logs?

Filter in the Sysmon configuration rather than at the collector. Exclude browser cache paths, your own software's working directories, and Windows update paths, then include the directories that actually matter — startup folders, scheduled task directories, and script extensions in user-writable locations. A maintained community configuration already does most of this.

Can Sysmon Event 11 detect ransomware?

It can surface it very early, because encryption produces file creation at a rate no normal process matches. Grouping by process and counting files created per minute catches it well before a user notices. It is a detection signal, not a prevention control — Sysmon blocks nothing.

Which file paths are most worth monitoring with Sysmon Event 11?

Startup folders and Start Menu startup directories, the scheduled task directories under Windows\Tasks and System32\Tasks, web root directories on servers, and executable or script extensions written anywhere under a user profile. Those cover most persistence and payload-drop activity at manageable volume.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026