HOW RELIABLE ARE THE LOGS?

Telemetry Desynchronization

Executive Summary

Modern security monitoring systems largely base their decisions about processes on log data. However, this data does not always represent the same point in time or the same reality. In Windows environments, there can be significant differences between the information recorded by the kernel at process creation time and the data read by user-mode tools while the process is running.

This difference creates a blind spot that may cause security tools to interpret processes incorrectly or incompletely. Detection approaches that rely heavily on process trees and command-line information can be misled especially when they depend on user-mode data that can be manipulated by attackers.

This research demonstrates how this inconsistency in process creation telemetry can be exploited in practice and why detection strategies based on a single data source are insufficient. The findings show that protecting kernel-based data and correlating multiple telemetry sources are critical to improving detection reliability.

Introduction

In cybersecurity, many of us share a common habit:

We look at logs and try to understand what happened in the system.

• Is a process benign or suspicious?
• With which command line was this binary actually launched?
• Why was an alert triggered, or why was it not triggered?

Most of the time, we answer these questions by analyzing telemetry collected through Sysmon, EDR, and SIEM. This approach is based on an assumption: logs accurately and completely reflect what truly happened in the system.

In practice, however, this assumption is not always correct. Especially in the Windows architecture, different telemetry sources related to the same event are generated at different times and at different layers. As a result, logs do not always tell a single, consistent story.

Previous analyses of ETW (Event Tracing for Windows) clearly show that telemetry generated at the kernel and user-mode levels can sometimes diverge. In techniques such as parent process spoofing, meaningful differences may appear between what the kernel knows about a process and what user-mode tools present. This difference is less about the event itself and more about how the event is observed.

At this point, the question naturally evolves:

• Which logs are truly reliable?
• Which ones only represent a momentary view and are open to manipulation?

Process Environment Block (PEB) manipulation is just one example of a broader problem. The core issue is the difference between the information recorded by the kernel at the moment of process creation and the user-mode data that security tools rely on while the process is running. Some fields recorded by the kernel during process creation cannot be changed after the event, while certain information read from user-mode memory during execution can be modified later with sufficient access.

This article does not aim to describe a single technique; rather, it aims to question how much and in what context we should trust logs. It focuses on a shared question for SOC analysts, detection engineers, red teams, and anyone interested in Windows internals:

At which layer does the truth reside, and which logs do we use to interpret it?

The Distinction Between Kernel and User-Mode Telemetry

Telemetry related to the same process may originate from different layers, depending on its source and the time of observation. The difference here is not about accuracy, but about context: some logs reflect the moment of process creation, while others represent the state of the process during runtime. When this distinction is not considered, telemetry can easily be misinterpreted.

Critical question: If some logs represent the moment of process creation and others reflect the process during execution, which one are we using as a reference in detection and analysis?

Telemetry Sources

Detailed Analysis

The Process Environment Block (PEB) and Its Critical Role in Security Telemetry

The Process Environment Block (PEB) is a data structure associated with every process running on Windows and resides entirely in user-mode address space. It stores critical metadata about how a process was started, which parameters it was launched with, and details about its execution environment. A large portion of security tools read process-related information directly or indirectly from the PEB.

PEB

In practice, this leads to a fundamental split:

• The kernel sees process startup conditions as a fixed snapshot
• User-mode tools rely on runtime metadata that can be modified by an attacker
• As a result, the same process may be perceived as different “realities” across different telemetry sources

⚠️ Critical Point: The PEB is not a read-only structure enforced by the kernel. It resides in user-mode address space and can be read and modified by a process with sufficient privileges.

PEB manipulation does not change the code that the process actually executes. What is altered is the process metadata that security tools and analysts rely on. For this reason, PEB manipulation is not an execution technique. It is a deception technique that disrupts observability.

The Structure of the Process Environment Block (PEB)

Kernel–User Telemetry and the Timing Window

What enables PEB manipulation is not a complex exploit chain, but a natural timing difference inherent in the Windows process creation model. During process creation, kernel and user-mode components are involved at different stages, which leads to telemetry being generated at different times.

Timing Window

Conclusion: Kernel-based logs represent the state of the process at the moment of creation, while user-mode tools reflect the state observed after the process has started running. This is not a race condition; it is a divergence over time between two different observation points. The logs are not incorrect, they simply report the same event from different layers and at different points in time.

Telemetry Matrix: What Point in Time Does It Represent?

The central question: “The information I see about a process which point in time does it actually belong to?”

Logs are often approached from a true/false perspective. However, when it comes to Windows telemetry, the key factor is not correctness, but timing and the layer at which the observation is made. Telemetry is inherently contextual: without understanding when and where it was generated, even accurate data can lead to incorrect conclusions.

Note: This matrix was prepared by consolidating findings from technical documentation, open-source research, blog analyses, and controlled laboratory testing.The reliability level assigned to Sysmon Event ID 1 reflects the timing and configuration dependencies between the kernel callback trigger and usermode enrichment

Why EDRs Sometimes Detect PEB Manipulation and Sometimes Don’t

The primary reason for the inconsistent behavior of EDRs is that process telemetry is collected from two distinct layers: kernel and user-mode.

At the kernel level, Windows passes the PsCreateProcessNotifyInfo structure to registered callbacks during process creation. The CommandLine field in this structure represents the actual command line at the moment the process is created. If the EDR driver relies on this callback, the information is obtained independently of user-mode memory structures and remains unaffected even if the PEB is later modified.

At the user-mode level, the process tree, command line, and visualization data are typically enriched via the PEB or APIs that read from the PEB. Since this reading occurs after process creation, any modifications made by an attacker to the PEB are directly reflected in this layer.

If an EDR compares the process creation-time command line (obtained from the kernel) with the command line read later in user-mode, any discrepancy for the same process generates a strong detection signal. However, in practice, many EDRs do not perform this correlation automatically, or they may store kernel data in the background without exposing it in the UI.

In many practical scenarios, PEB manipulation involves writing into the memory of another process (for example via NtWriteVirtualMemory). However, this is not always required. A process can also modify its own PEB without generating cross-process access telemetry. This distinction is important because not every PEB modification will trigger process access logs such as Sysmon Event ID 10.

This distinction explains why an EDR can detect this technique in some environments while remaining completely silent in others. Detecting the technique does not depend solely on product capabilities — it is determined by which layer the data is collected from, at what time, and how these layers are correlated.

Laboratory Findings: System-Level Validation

Controlled laboratory tests were conducted across two distinct scenarios to validate the telemetry desynchronization described in this study.

Scenario 1: Visible Child Process (Demonstration Mode)

A scenario was intentionally constructed to spawn a child process, making the impact explicitly observable. At first glance, the process tree and Sysmon Event ID 1 logs present a consistent and seemingly benign execution flow. Closer inspection, however, reveals a behavioral mismatch between the parent process command line and the actual activities performed by the child process.

ANYRUN

Scenario 2: Hidden Execution (Real Attack Mode)

In this scenario, no additional child processes were created — execution occurred within the existing process. Procmon showed no traces of malicious activity in the process tree. Sysmon produced only a single Event ID 1 record. Under default Sysmon configuration, process creation telemetry alone is insufficient to reveal this execution.

AnyRun observation: The malicious command did not appear anywhere. certutil.exe scored only 5/100, while network traffic logs clearly show HTTP GET requests to malicious.com/payload.exe,confirming the activity executed as intended, completely invisible to log-based analysis.

Note: Different results may be observed if Kernel ETW is enabled or if additional telemetry, such as Sysmon Event ID 10/11, is collected.

EDR Bypass Techniques and Defensive Layers

Real-World Case Studies

BlackCat (ALPHV) Ransomware — Healthcare Provider (October 2022)

Attack Chain

APT41 — LockerGoga Ransomware / Norsk Hydro (March 2019)

Attack Chain

APT29 (NOBELIUM) — Fortune 500 Technology Company (May 2021)

Attack Chain

APT Defense Layer Bypass Matrix

Detection: Logs Are Not Wrong, But Incomplete

In techniques like PEB manipulation, the core problem is not missing logs. Logs are generated, they reach the SIEM, and in many cases appear “benign.” The issue is that these logs represent different moments of the same reality.

Why Single-Source Detection Fails

Most process analyses rely on the assumption: “Information captured at process creation remains valid during process execution.” This is not true. In Windows, some data is written by the kernel at creation time, while other data is read from user-mode memory during runtime. PEB manipulation targets this second category.

The Real Signal: Inconsistency

Detecting these techniques is not about looking for a “suspicious event.” The true signal lies in inconsistencies across sources. A process starting with a benign command line, long-lived LOLBin behavior, unexpected in-process accesses, and the semantic gap between creation-time and runtime information (individually harmless) become meaningful when analyzed together.

Why ETW Is Positioned Separately

Kernel-based ETW telemetry observes process creation before user-mode manipulations, capturing parent relationships and timing in a more raw form. Techniques like PEB manipulation and parent spoofing may appear consistent in Sysmon or reasonable in the EDR interface, yet show as out-of-scope on the ETW side. ETW alone is not sufficient, but it provides a reference point that is harder to tamper with.

Behavior > Metadata

Command line, parent process, or image path alone are not reliable indicators. More meaningful questions include: why did this process access another process’s memory? Why did it generate network traffic? Why did it invoke an API it normally wouldn’t?

Key Question: “Is this process actually behaving as it reports?”

Section Takeaways:

• Logs do not lie, but they speak with incomplete context
• PEB manipulation does not erase logs — it distorts perception
• Effective detection requires relationship and correlation analysis, not a single event
• Kernel and user-mode data are meaningful only when analyzed together, not separately

Defense Architecture: Focus on Layers, Not a Single Log

Attacks of this type cannot be detected through a single log. Adversaries deliberately rely on defenders trusting just one source. Effective defense depends on layered analysis and correlation.

Layer 1 — Process Creation (Ground Truth)

• Kernel ETW
• Process notify callbacks

→ How did this process actually start?**

Layer 2 — Snapshot Logs

• Sysmon Event ID 1
• EDR creation events

→ What was reported to us at that moment?**

Layer 3 — Runtime Behavior

• Sysmon Event ID 10
• API calls
• process injection signals

→ What did this process do while running?**

Layer 4 — Context Analysis

• Parent-child relationships
• LOLBin chains
• Time correlation

→ Does this behavior make sense?**

Layer 5 — Live Verification

• EDR live response
• Process Explorer
• memory snapshot

→ What do I observe right now?**

Layer 6 — Cross-Source Verification

• Kernel ↔ User
• Log ↔ Memory
• Event ↔ Behavior

→ Do these sources tell the same story?**

⚠️ Critical: Even if one or more of these layers are missing, the system continues to operate — but the attacker exploits precisely these gaps.

Conclusion

The key takeaway from this study is that the issue does not stem from a single technique. PEB manipulation, Sysmon’s limitations, or certutil abuse alone are not the “root problem.” The true issue lies in treating logs as absolute truth.

On Windows, some telemetry sources are fixed at the kernel level during process creation, while others are read from user-mode memory during runtime. This difference creates critical blind spots when timing gaps occur. As a result, different tools may present different realities for the same process.

Key Takeaways:

• Process creation logs do not capture the full lifecycle of a process
• User-mode views may appear correct, but they do not necessarily reflect reality
• Kernel telemetry is more resilient, The level of reliability always depends on the attacker’s capabilities and the threat model.
• Memory analysis provides the most reliable reference, but it represents only a snapshot in time

Therefore, the question is no longer “Are the logs correct?” The real question is: “At what time and under what conditions are these logs accurate?”

Modern attacks are not primarily about hiding — they are about distorting perception and scope. Effective defense relies not on more rules, but on greater correlation, timing awareness, and multi-source analysis.

The techniques demonstrated in this study are not hypothetical — they are part of modern attack chains. PEB manipulation targets traditional assumptions of log trust and deliberately misleads single-source detection.

Common Thread: Logs are not wrong; they are incomplete. Behavior that appears “benign” when viewed from a single source can clearly appear malicious once contextual information is expanded.

✅ A single telemetry source is never sufficient.

✅ Process creation logs, such as those from Sysmon, do not represent the full lifecycle of a process.

✅ Timing gaps create a concealment window for attackers.

✅ Processes should be evaluated as chains of events, not isolated occurrences.

✅ Behavioral analysis has surpassed signature and IOC-based detection

✅ Real-time observation complements, rather than replaces, historical log analysis.

Sources and References

• Velociraptor: ETW Part 2 — Process Parent Spoofing (2021)
• Trail of Bits: What child is this? Process Reparenting in Microsoft Windows (2022)
• Trail of Bits: ETW internals for security research and forensics (2023)
• Elastic Security Labs: Kernel ETW is the best ETW (2024)
• Huntress: *I Wish I Was a Little Bit Taller — Dealing with Imperfection in Intrusions*
• Microsoft: *Process Environment Block (PEB) structure*
• Microsoft: *PsSetCreateProcessNotifyRoutineEx2 / PS_CREATE_NOTIFY_INFO*
• SANS ISC: *Malicious Process Environment Block Manipulation*