Evidence of execution: thirteen classes, not five artifacts

TL;DR

Everyone names five sources of execution evidence. There are thirteen classes.

Ask a SOC analyst which sources show that code ran and the answer is nearly always Sysmon 1, Security 4688, Prefetch and maybe Amcache. None of it is wrong, and it is five artifacts. This reference groups 157 event IDs, counted per channel, and 14 on-disk artifacts into thirteen classes by the question each source answers: was a process created, what did it do, what did it connect to, which script ran, what installed or persisted it, what a security control decided, what crashed, what the system inventoried, and who moved to this machine.

On a real host with no agent and no tuned audit policy, the sources nobody queries are often the only ones left. Three rules carry the method. Grade the channel and the provider and never the bare event ID, because Application 1000 is a crash under one provider and an attacker-controlled string under another. Tag every source by availability. Treat an absent source as a collection gap and not as a clean result. Collect the default-on, durable sources first, because they survive a cleared log.

Most SOC analysts I have interviewed or worked with stop after a few very well known event IDs or sources of execution evidence. Judging by the speed of the answer you can usually tell which ones come from personal experience and which come from a distant memory of a SANS poster or something similar.

The list is nearly always the same: Sysmon event ID 1, Security 4688, Prefetch, maybe Amcache. None of it is wrong.

It is also five artifacts, and the tables below list 157 event IDs, counted per channel, and 14 on-disk artifacts that bear on whether code ran. The gap is not trivia. On a real host, with no agent and no tuned audit policy, several of the sources nobody queries are the only ones still present.

This is the full enumeration, grouped the way I use it in an investigation. It is a reference rather than an argument, so it is long. The short version is the TL;DR above and the Key takeaways at the end.

How the classes are grouped

Not by which log a source lives in. By the question the source answers about execution. That is why Security 4688 and Sysmon 1 sit in the same class despite living in different logs and needing entirely different setup: they answer the same question, which is whether a process was created.

A source earns a place only if it anchors to a process, a path, or a command. Anchoring makes it attributable, not proof of a run: some sources below record execution, others an attempt, an installation or context, and the last column of each table says which.

Attestation strength and availability are tags on each source, not groupings. Keeping them as tags is what lets the classes stay clean.

The two rules that sit over all of it

Grade the channel and the provider, never the bare event ID. Application event 1000 is a crash under the Application Error provider and an attacker-controlled free-text string under the .NET Runtime provider. The number on its own tells you nothing. The unit of meaning is channel plus provider plus ID.

An absent source is a collection gap, not a clean result. If the channel was off, rolled, or never collected, the honest phrasing is low-confidence-clean with the gap named. Silence is a statement about your telemetry.

Availability: know what you have before you claim scope

Every source below carries one of four tags. This is the difference between a source you can count on and one you are hoping for.

Class 1: direct process creation

The most direct evidence there is. Something recorded that a process came into existence. Read every create together with its command line and its parent, because a create with no ancestry is half a finding.

Shell-Core is the one I would point at. It is on by default, it names the executable and the PID, and it is absent from almost every answer I hear.

Class 2: what the live process did

Creation proves a launch. Sysmon is a strong source for what came after: most of its events carry the ProcessGuid of the process that caused them, so modules, files, registry changes and connections tie back to that launch. Sysmon is far more than event 1, and a poor configuration either drowns these in noise or omits them entirely.

GrantedAccess on event 10 is the single field I would keep if I could keep only one. Read with the source image, it separates a process opening a handle to LSASS for a legitimate reason from one reading credentials out of it.

The persistence and command-and-control side

Class 3: process to network and DNS

Two ways to attribute a connection to a process. Sysmon by deployment, the Windows Filtering Platform by audit policy. On a host without Sysmon, WFP is the only native process-to-network map you have.

WFP is a firehose, thousands of events a minute on a domain controller. Collect it selectively. 5154 for listens and 5157 for blocks are the high-value, low-volume picks.

Class 4: script and command

PowerShell lives in two logs and you need both. The classic log tells you how PowerShell was launched and whether it arrived over WinRM. The operational log tells you what the script did. Query one and you get a quiet answer that is wrong.

WMI

WMI is a favorite for remote execution and for fileless persistence, and both land in one operational log that is on by default.

Class 5: persistence-linked launch, services

A service install is execution and persistence in the same record, and it is the classic remote-execution tell. 7045 is on by default, so pull it first.

Class 6: persistence-linked launch, tasks and DCOM

Scheduled tasks write to both a Security log and an operational log, and the operational one is on by default. DCOM is the awkward case: lateral movement over DCOM has no single event.

Reconstruct DCOM movement from a process create, the -Embedding tell on the command line, and a Type 3 logon. All four events above record failures, so a DCOM move that worked leaves none of them. Treat 10016 as by-design noise; it is almost never what you are looking for.

Class 7: control adjudication

The highest field fidelity in the log, because a security control inspected the image before deciding. Path, hash and publisher in one record. Audit mode counts, which is the point most people miss. Read the outcome before the class name: allowed or audited means the control evaluated the image on its way to running or loading, blocked means an attempt was prevented, and a DLL rule concerns a load rather than a new process.

The standing recommendation I give is to run AppLocker or WDAC in audit mode. Most of the forensic value, none of the operational risk of blocking something the business needs.

Class 8: install, deploy and servicing

Installer and transfer subsystems place software, and sometimes run it, naming products, packages, URLs and paths as they do. A successful install shows installation, not that the program later ran.

MSI events fire for Windows Installer packages. A plain .exe installer often logs nothing at all, so absence here is not evidence that nothing was installed.

Class 9: crash and fault derived

It ran because it broke. Weak attestation, on by default, and frequently the only surviving trace. Every one of these names a path.

These are self-reported by the faulting subsystem, so corroborate them against Sysmon, Prefetch or Amcache before leaning on one.

Classes 10 and 11: compatibility, telemetry and self-reported

Execution inferred from a shim or inventory subsystem, plus the weakest tier of all: records an application wrote about itself. This is where the provider rule earns its keep.

This is the concrete case for grading the provider. Application event 1000 is a crash under Application Error and an attacker-controlled string under .NET Runtime. And the provider name itself can be borrowed: on a Windows 11 test host, Windows PowerShell’s Write-EventLog, run elevated, wrote a .NET Runtime 1000 carrying arbitrary text. eventcreate.exe refuses the name of any installed provider, so it is the wrong tool to worry about. Corroborate before you cite.

Class 12: remote and lateral execution context

This class turns a process ran into a process ran because somebody moved to this box. RDP alone spans four logs across three machines.

Process ancestry is what ties arrival to execution: wsmprovhost.exe, PSEXESVC or w3wp.exe spawning cmd.exe.

Class 13: the on-disk cousins

Not event logs. Filesystem and registry artifacts that survive a cleared event log. Some record a run directly; others show that a file was present or that the shell met it, and the last column says which. In a compromise assessment I collect these first.

Per-user launch and deleted binaries

Traps and blind angles

Each of these has ended a finding on cross-examination. Name the applicable gap before writing the words no evidence.

• The bare event ID lies. Application 1000 is a crash or an implant string depending on the provider.
• Most Security detail needs audit policy. 4688 command lines, 4697, 4698, WFP and 4104 are all off until somebody turns them on.
• PowerShell splits across two logs, and PowerShell 7 splits into a third.
• ShimCache is not execution. It records a path on enumeration.
• Self-reported events are forgeable. Write-EventLog writes a classic Application event under an installed provider’s name, with any text.
• Deliberate evasion exists. Security 1102 and System 104 wipe the trail, DCOM has no single event, and golden or silver tickets bypass the domain controller entirely.

The order I actually collect in

Ordered for a long-dwell compromise assessment. Default-on and durable first, because those sources survive clearing, give the longest lookback, and need nobody to have prepared anything.

1. Prefetch, Amcache, SRUM, BAM, PCA, ShimCache
2. Windows PowerShell classic 400, 600 and 800, plus Operational 4104
3. System 7045, 7034 and 7040
4. Shell-Core 9707, 9708, 62408 and 62409
5. TaskScheduler 106, 129, 200 and 201, and DCOM 10000, 10001, 10010 and 10028
6. WMI-Activity 5857 to 5861
7. Application channel: 1000, WER, ESENT, MSI and Program-Telemetry
8. Sysmon 1, 3, 5, 7, 8, 10, 11, 13, 22 and 25, and EDR
9. AppLocker, WDAC and Defender ASR
10. Security 4688, 4689, 4697, 4698 to 4702, 4648, 5140 and WFP

Kernel-Process ETW and EDR are live or console sources, not a retrospective evtx pull. Any channel that is absent is an unanswered question, and it belongs in the report as one.

What this note leaves out

Execution of libraries, webshells and injection techniques are their own subject and deserve their own post.

Recovering deleted records or files is not covered. In a high-profile investigation no stone should be left unturned, and carving deleted evidence is a separate discipline from knowing which sources exist.

Key takeaways

1. Group sources by the question they answer, not by the log they live in. Security 4688 and Sysmon 1 sit in one class because both answer whether a process was created. A source earns a place only if it anchors to a process, a path or a command. Anchoring makes a source attributable; how strongly it shows execution varies by source.
2. Grade the provider, not the ID. Channel plus provider plus ID is the unit of meaning. Application 1000 is a crash under Application Error and an attacker-controlled string under .NET Runtime, and Write-EventLog can write it under an installed provider's name, so corroborate self-reported events before citing them. When normalizing, keep the channel, provider name and GUID, event ID and version, computer, record ID and UTC time; dropping the provider turns an event back into an ambiguous number.
3. Tag every source by availability before claiming scope. Most Security detail needs audit policy: 4688 command lines, 4697, 4698, WFP and 4104 are all off until somebody turns them on.
4. Absence is a finding, so say low-confidence-clean and name the gap. Silence is a statement about telemetry. Without Class 1 covering the window you are missing at least one of the parent process, the command line, a complete timeline or who executed it.
5. Sysmon is a class, not an event. Event 1 is the start; 3, 7, 8, 10, 13, 22 and 25 carry the rest. GrantedAccess on event 10, read with the source image, separates a legitimate handle to LSASS from credential theft.
6. Query both PowerShell logs, and the PowerShell 7 log as well. The classic log shows how PowerShell was launched and whether it arrived over WinRM, and the operational log shows what the script did. Query one and the quiet answer is wrong.
7. Collect the default-on, durable sources first. Prefetch, Amcache, SRUM, BAM, PCA and ShimCache survive clearing, give the longest lookback and need nobody to have prepared anything. ShimCache records a path on enumeration, which is not execution.
8. Inventory the sources on day one and ask for more logging. Walk the list, see which sources exist and how far back each reaches, set expectations with the client, and have additional logging switched on and retained while the case is open.
9. Scope the collection to the question. Sometimes a handful of events proves or dismisses what you were asked, and not every investigation needs the full execution chain.

References

Grouped by class. Vendor research appears only where the link points at an original discovery.

Method and audit policy

• Advanced security auditing
• MS-EVEN, the EventLog Remoting Protocol

Classes 1 and 2, process creation and behavior

• Sysmon
• Event 4688
• Command-line process auditing
• MITRE ATT&CK T1546, event-triggered execution

Class 3, network and DNS

• Audit Filtering Platform Connection

Class 4, script and command

• about_Logging_Windows
• MITRE ATT&CK T1546.003, WMI event subscription

Classes 5 and 6, services, tasks and DCOM

• MITRE ATT&CK T1543.003, Windows service
• MITRE ATT&CK T1053.005, scheduled task
• MITRE ATT&CK T1021.003, distributed component object model

Class 7, control adjudication

• Using Event Viewer with AppLocker
• App Control event ID explanations

Class 8, install and servicing

• Windows Installer event logging
• MITRE ATT&CK T1197, BITS jobs

Class 9, crash and fault

• Windows Error Reporting
• SigmaHQ, ntdsutil abuse: ESENT 216, 325, 326 and 327 naming ntds.dit

Classes 10 and 11, compatibility, telemetry and self-reported

• Write-EventLog, which writes a classic event under an installed provider name

Class 12, remote and lateral movement

• MITRE ATT&CK TA0008, lateral movement
• MITRE ATT&CK T1021.001, remote desktop protocol
• JPCERT/CC, detecting lateral movement through tracking event logs
• JPCERT/CC, tool analysis result sheet: the events each lateral movement tool leaves

Class 13, on-disk artifacts

• Sygnia, the Windows 11 PCA artifact
• Mandiant, caching out the ShimCache
• Microsoft Incident Response, Guidance for Incident Responders: Prefetch, AmCache and ShimCache
• Microsoft, Windows 11 specifications: Timeline among the feature deprecations
• Microsoft, Application User Model IDs: how an application sets its own AppID
• Didier Stevens, UserAssist
• Yogesh Khatri, Forensic implications of System Resource Usage Monitor (SRUM) data in Windows 8, Digital Investigation, 2015
• libyal winreg-kb, the Background Activity Moderator key
• CrowdStrike, Mind the MPLog: Microsoft Protection Logging in forensic investigations