Evidence of execution: thirteen classes, not five artifacts

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. If you want the short version, the last two sections are the ones to read.

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. Anything vaguer than that is context, not evidence of execution.

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.

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 run it, and they name products, packages, URLs and paths while doing so.

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 independently prove a run and, critically, survive a cleared event log. 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.

Six lines that hold it together

1. Group by what a source tells you, not by which log it lives in.
2. Grade the provider, not the ID. Channel plus provider plus ID is the unit.
3. Tag every source by availability. Know what you have before claiming scope.
4. Sysmon is a class, not an event. Event 1 is the start; 3, 7, 8, 10, 13, 22 and 25 carry the rest.
5. Query both PowerShell logs, and the PowerShell 7 log as well.
6. Absence is a finding. Say low-confidence-clean and name the gap.

The DFIR take-aways

Without Class 1 covering your investigation window, everything else is a partial view. You will be missing at least one of: the parent process, the command line, a complete timeline, or a clear answer to who executed it. You can still work, but say what is missing.

Knowing these sources lets you inventory the case on day one. Walk the list, see which sources exist and how far back each one reaches, and you can set expectations with the client immediately. It is also the moment to ask for additional logging to be switched on and retained, so the rest of the investigation has more to work with than the start did.

Not every investigation needs the full execution chain reconstructed. Sometimes a handful of events is enough to prove or dismiss the question you were actually asked. Scope the collection to the question.

This article deliberately leaves things out. Execution of libraries, webshells and injection techniques are their own subject and deserve their own post.

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

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

Class 12, remote and lateral movement

• MITRE ATT&CK TA0008, lateral movement
• MITRE ATT&CK T1021.001, remote desktop protocol

Class 13, on-disk artifacts

• Sygnia, the Windows 11 PCA artifact
• Mandiant, caching out the ShimCache