OCSF Extension Proposals
Several technique-level detection rules in this framework require fields that are not present in the OCSF base schema. Rather than silently relying on vendor-specific fields, these are documented here as formal proposals for the OCSF working group. Each proposal names the missing field, explains why no existing field suffices, and provides a concrete schema suggestion.
api.name proposed The name of the Windows API function used to perform a cross-process operation. Required to distinguish injection primitives at the sub-technique level — CreateRemoteThread from QueueUserAPC from other injection methods.
Motivation
OCSF Process Activity (class 1007) with activity_id = Inject captures that a cross-process write occurred but not which Windows API was used to accomplish it. Sub-techniques T1055.001 (DLL Injection) and T1055.004 (APC Injection) are formally defined by their injection primitive — the invariant field that differentiates them from each other and from the parent technique. Without api.name, both sub-techniques are indistinguishable from each other and from T1055 at the OCSF event level. Classic Sysmon surfaces this partially via EID 8 (CreateRemoteThread) as a dedicated event class, but has no equivalent for QueueUserAPC. A unified api.name field across all OS API call events would allow consistent sub-technique discrimination.
Proposed schema
Object: Event-level field on Process Activity (1007), activity_id = Inject Field: api.name Type: string — the Win32 or NT API function name Example: 'CreateRemoteThread', 'QueueUserAPC', 'NtCreateThreadEx' Add api.name as a top-level field on Process Activity events when the activity describes a specific OS API call. Vendors normalising Sysmon EID 8 map the implicit event type → api.name: 'CreateRemoteThread'. Kernel ETW sources provide this for other primitives.
Sigma usage
detection:
selection:
activity_id: 'Inject'
api.name: 'CreateRemoteThread'
condition: selection process.access_mask proposed The access rights requested when opening a handle to an existing process. Required to distinguish a benign process open (e.g. read name only) from a credential-dumping open (PROCESS_VM_READ).
Motivation
OCSF Process Activity (class 1007) with activity_id = Open (3) captures that a process handle was opened but not the access mask that was requested. For LSASS credential dumping, the critical invariant is that the handle carries PROCESS_VM_READ rights — without this field the event is indistinguishable from a legitimate process open. Classic Sysmon captures this as GrantedAccess on Event ID 10 (ProcessAccess); the OCSF base schema has no equivalent.
Proposed schema
Object: Process (used in Process Activity, activity_id = Open) Field: access_mask Type: string (hex bitmask) or integer Example: "0x0010" (PROCESS_VM_READ) Add access_mask to the OCSF Process object, populated only when the event describes an OpenProcess-style handle acquisition. Vendors that normalise Sysmon EID 10 map GrantedAccess → process.access_mask.
Sigma usage
detection:
selection:
activity_id: 'Open'
process.access_mask: '0x0010' # PROCESS_VM_READ
process.name: 'lsass.exe'
condition: selection process.integrity_level proposed The Windows Mandatory Integrity Control level of a process (Low, Medium, High, System). Required to detect UAC bypass: the defining invariant is a High-integrity process spawned from a Medium-integrity parent without a UAC consent event.
Motivation
OCSF Process Activity (class 1007) with activity_id = Launch (1) captures process creation but does not model Windows integrity levels. UAC bypass detection depends entirely on observing the integrity level transition — a process spawned at High integrity from a Medium-integrity actor, without a preceding consent prompt. Classic Sysmon captures this as IntegrityLevel on Event ID 1; OCSF has no equivalent. The field is Windows-specific but the pattern generalises to any capability-based privilege model.
Proposed schema
Object: Process (used in Process Activity, activity_id = Launch) Field: integrity_level Type: string enum — 'Low' | 'Medium' | 'High' | 'System' | 'Untrusted' Scope: Windows-specific; omitted on non-Windows platforms Add integrity_level to the OCSF Process object, populated on process creation events on Windows. Vendors that normalise Sysmon EID 1 map IntegrityLevel → process.integrity_level.
Sigma usage
detection:
selection:
activity_id: 'Launch'
actor.process.integrity_level: 'Medium'
process.integrity_level: 'High'
condition: selection process.start_type proposed The creation flags passed to CreateProcess, specifically whether the process was created in a suspended state. Required as the earliest observable signal for process hollowing.
Motivation
Process Hollowing creates a legitimate process in suspended state (CREATE_SUSPENDED), unmaps its image, and writes attacker code into the vacated address space before resuming execution. The suspended-state creation is the only event that fires before the image replacement occurs and is therefore the earliest detection opportunity. OCSF Process Activity (class 1007) with activity_id = Launch (1) does not capture the creation flags. Classic Sysmon Event ID 1 also does not expose this flag; it requires kernel ETW (Microsoft-Windows-Kernel-Process) or EDR telemetry that captures the creation flags directly.
Proposed schema
Object: Process (used in Process Activity, activity_id = Launch)
Field: start_type
Type: string enum — 'Normal' | 'Suspended' | 'Debug' | 'Detached'
(maps to Windows PROCESS_CREATION_FLAGS; simplified subset)
Scope: Windows-specific; omitted on non-Windows platforms
Add start_type to the OCSF Process object, populated on process creation
events where the creation flags are available. The primary value is the
'Suspended' variant for hollowing detection. Sigma usage
detection:
selection:
activity_id: 'Launch'
process.start_type: 'Suspended'
condition: selection