Skip to content

Sysmon and Targeted Windows Telemetry for Fileless Execution

Objective

Determine the lightest enterprise practical combination of Sysmon, targeted ETW, native Windows telemetry, and existing endpoint telemetry that can support independent detections for fileless malware, process injection, and execution from suspicious memory regions.

Base detection logic on attacker behavior and memory state. Use API names to define test cases for the underlying primitives.1

Behavior-centered model
Cross-process access
  → remote memory allocation or modification
  → writable memory becomes executable
  → execution begins from the affected region

Important implementations to use during testing include:

  • WriteProcessMemory and NtWriteVirtualMemory
  • VirtualAllocEx and NtAllocateVirtualMemory
  • VirtualProtect, VirtualProtectEx, and NtProtectVirtualMemory
  • CreateRemoteThread and NtCreateThreadEx
  • QueueUserAPC and other APC-based execution
  • NtCreateSection, NtMapViewOfSection, and related section-mapping techniques

For each API and primitive, identify telemetry that records the operation, supports an inference, or leaves the behavior invisible.

Behaviors that need evidence

  • One process obtaining access to another process
  • Cross-process memory modification
  • Allocation of memory in another process
  • Memory-protection changes, especially RW → RX and RW → RWX
  • Creation or use of RWX memory
  • Executable private or unbacked memory
  • Threads beginning at suspicious addresses
  • Execution not associated with a normally loaded EXE or DLL
  • Section mapping associated with injection
  • APC-based execution
  • Useful call stacks or stack traces

Injection lifecycle and trust boundary

The source describes a common four-stage injection lifecycle: acquire a target-process handle, allocate or identify memory, deliver payload bytes, and trigger execution. The implementation may substitute APCs, section mappings, Native APIs, direct syscalls, or execution-flow manipulation, so detection should follow the state transition rather than require one API chain.

Trust-boundary model
Low- or medium-integrity source
  → interacts with an unrelated or more privileged target
  → modifies or maps executable content
  → execution appears under the target's token and trust context

Injection into a trusted or privileged process can inherit that process's token, access, and reputation without creating a new payload process. A long-lived target may also provide soft persistence for as long as the process remains active. Prioritize transitions from a lower-integrity source into a high-integrity or SYSTEM target, then corroborate with memory-region and execution evidence.2

Start with optimized Sysmon

Determine how much of the chain Sysmon can observe before adding another source.

Event ID 10: ProcessAccess

Use ProcessAccess as evidence that one process opened or accessed another process. Preserve:

  • SourceImage
  • TargetImage
  • GrantedAccess
  • CallTrace
  • Source and target process identifiers, including Process GUIDs where available

Map and validate the GrantedAccess values and combinations associated with virtual-memory operations, memory reads or writes, thread creation, handle duplication, and other injection-enabling access. Baseline common source-target-rights combinations before alerting.

Investigate whether CallTrace adds value through unusual modules, unsigned or unexpected code, abnormal stack composition, or call paths that differ from legitimate debuggers, security products, browsers, and development tools.

Access requires correlation
ProcessAccess
  + injection-enabling rights
  + rare source/target pair
  + suspicious call trace
  = stronger lead, not final proof

Event ID 8: CreateRemoteThread

Use CreateRemoteThread as evidence that execution was initiated in another process. Evaluate:

  • Source process and image
  • Target process and image
  • StartAddress
  • StartModule
  • StartFunction

A start address with an unresolved or absent module/function may be more interesting because it can indicate execution from dynamically allocated private memory. Compare the address with known loaded-module ranges whenever another source makes those ranges available.

Event ID 25: ProcessTampering

Evaluate ProcessTampering for process hollowing, image replacement, and related process-manipulation behavior. Document exactly which tested variants generate the event and which do not.

Event ID 1 and supporting events

Use Sysmon ProcessCreate or Security Event 4688 for lineage, command line, identity, hash, and surrounding execution context. Compare parent and child user SIDs, integrity levels, and token context where the source exposes them. Treat process creation as context for stronger injection evidence.

Add Security Event 4703 when privilege-adjustment auditing is available. Explicit SeDebugPrivilege enablement can strengthen evidence that a process is preparing to cross an integrity boundary, but absence of Event 4703 does not exclude token or injection abuse.

Add targeted correlation from ImageLoad, NetworkConnect, FileCreate, and registry events when they explain module provenance, payload staging, follow-on communication, persistence, or another part of the behavior chain.

Explicit Sysmon coverage map

For every tested primitive, classify each stage as:

Classification Meaning
Direct Sysmon records the operation itself with useful fields.
Inferred Sysmon records related behavior, but not the operation or memory-state change directly.
Invisible No practical Sysmon event provides the required evidence.

Build the coverage map for:

Process A accesses Process B
  → obtains memory-manipulation-related rights
  → memory in Process B is allocated or modified
  → memory protection changes
  → execution begins inside Process B
  → start address is private, unbacked, or outside loaded modules

The purpose of this map is to prevent a Sysmon-only design from claiming visibility it does not possess.

Fill the gaps with targeted Windows telemetry

Investigate ETW providers and other lightweight native mechanisms that may expose:

  • Cross-process memory writes
  • Remote virtual-memory allocation
  • Memory-protection changes
  • RW → RX and RW → RWX transitions
  • Executable private memory
  • Execution from unbacked memory
  • Thread start addresses in suspicious regions
  • Section creation and mapping associated with injection
  • APC-based execution
  • Relevant call stacks
  • Executable code without a corresponding normally loaded image

Validate each candidate provider and event type empirically. Record the exact operation and fields observed during testing.

Pay particular attention to the underlying operations represented by NtWriteVirtualMemory / WriteProcessMemory and NtProtectVirtualMemory / VirtualProtectEx:

High-value sequence
Writable region allocated or identified
  → executable content written
  → protection changed from writable to executable
  → execution begins from that region

Same-region correlation

A process-level sequence is weaker than proof that each operation affected the same memory region. Determine whether each source exposes:

  • Target process or stable process identity
  • Base address
  • Region size
  • Old and new protection
  • Allocation or memory type
  • Thread start address
  • Loaded image base and size
  • Section or mapping identity
  • Stack or calling process context

Normalize addresses and correlate overlapping ranges.

Address-aware hypothesis
Cross-process write to region R
  + R changes RW → RX or RWX
  + thread start address falls inside R
  = strong behavioral evidence

Also compare thread start addresses with known loaded-module ranges:

Thread start address
  → outside known EXE/DLL ranges
  → inside executable MEM_PRIVATE or unbacked region
  → prioritize

Execution from private or unbacked executable memory may be more implementation-independent than detecting one thread-creation API.

Detection and correlation hypotheses

Build weighted sequences from weak and moderate evidence. ProcessAccess becomes useful when source, target, rights, timing, and execution evidence align.

Prioritize combinations such as:

  1. Rare source-target ProcessAccess with injection-enabling rights plus CreateRemoteThread.
  2. Cross-process write plus an executable protection transition in the same target process.
  3. Cross-process write plus RW → RX or RWX plus execution from the same region.
  4. Thread start outside loaded modules and inside executable private or unbacked memory.
  5. Process tampering plus abnormal lineage, image provenance, or immediate network activity.
  6. Section mapping plus executable unbacked memory and a suspicious thread or APC execution path.

Correlate by stable process identity, source and target process, address range, section identity, and a tightly justified time window. Use lineage, signer, prevalence, host role, user activity, image loads, files, registry changes, and network behavior as supporting context.

Enterprise evaluation record

Document every proposed source or detection with the same fields:

Question Required record
Behavior What Windows behavior does it observe?
Evidence strength Direct observation or inference?
Source Exact provider, event, and field supplying the evidence
Scale Can it be collected continuously across an enterprise?
Noise Which legitimate applications commonly generate it?
Correlation Which events, identifiers, addresses, and time windows strengthen it?
Blind spots What is absent, filtered, sampled, or easy to evade?
API independence Does it remain useful with Native APIs or direct syscalls?

Measure event volume, CPU cost, storage, forwarding bandwidth, stack-capture overhead, data loss, field consistency, and retention requirements in a representative pilot before broad deployment.

Expected legitimate activity

Baseline and narrowly account for:

  • EDR, antivirus, accessibility, and application-control products
  • Debuggers, profilers, and development tools
  • Browsers and other sandboxed multi-process applications
  • .NET, Java/JVM, JavaScript, and other JIT runtimes
  • Application compatibility shims, overlays, and assistive software
  • Backup, monitoring, remote-management, and virtualization tools

Suppress known behavior by specific source, target, signer, version, host role, call trace, and sequence where possible. Avoid broad exclusions that erase the underlying technique.

Validation approach

  1. Generate known benign and controlled injection-like behaviors in a lab.
  2. Exercise Win32, Native API, section-mapping, APC, and direct-syscall variants.
  3. Record which stages each telemetry source observes directly, supports only by inference, or misses.
  4. Verify whether addresses allow same-region correlation.
  5. Measure noise and cost on representative workstation and server populations.
  6. Build detections from memory state and behavioral sequences, then test bypasses.
  7. Select the smallest continuously collectible source set that preserves useful coverage.

Outcome: independent, telemetry-backed detections for process injection and fileless execution that remain useful across multiple implementations, including Native APIs and direct syscalls.

  1. Gianluca Tiepolo and Dan Sorensen, Advanced Cyber Threat Intelligence and Hunting, first edition, Packt, 2026, Chapter 6, behavioral observables and "Memory injection and code manipulation," supplied EPUB extraction lines 52–66 and 361–391. ↩

  2. Tiepolo and Sorensen, Chapter 10, "Process Injection" and "Hunting for Privilege Escalation," supplied EPUB extraction lines 55–89 and 137–212. ↩