Loading story…
WithSecure documented how Windows AV and EDR drivers collect inline telemetry through kernel callbacks for process, thread, and object-access activity, including user-mode call stacks. Sysmon, for example, uses an object-handle callback and RtlWalkFrameChain to populate the CallTrace field in Event ID 10 process-access records; such traces can expose direct system calls by showing execution paths that omit ntdll before the kernel service transition. The research showed that x64 unwind metadata and frame reconstruction determine what collectors record, raising the prospect that an attacker could forge a plausible stack to mislead callback-based detections. Windows Security Event ID 4688 remains a separate audit source for newly created processes.
Elastic Security Labs reported that kernel-originated ETW is generally more resistant to user-mode tampering than telemetry produced by user-mode clients or services, but warned that trusted event origin does not ensure complete or accurate data. Its analysis found that many kernel ETW events—particularly opaque or legacy providers—require manifests, symbols, binary analysis, or reverse engineering to interpret, and that some events record only failures. Organizations should correlate process-creation auditing, Sysmon call traces, and kernel ETW rather than rely on any one source, and validate whether their detections account for missing, manipulated, or semantically limited stack and ETW data.
See real exploitation activity before you spend the cycle.
3 references tracked. Mallory keeps watching after this page renders.
elastic.co
Open sourcelabs.withsecure.com
Open sourcelearn.microsoft.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Multiple public research reports detailed how attackers can evade Windows security monitoring by abusing native APIs, loader behavior, and application logging. White Knight Labs and XPN documented techniques to suppress or bypass **Event Tracing for Windows (ETW)** visibility in .NET and Windows processes, while separate research showed that access-mask-based detections can be defeated with `DuplicateHandle` by first requesting only `PROCESS_DUP_HANDLE` and then cloning a more privileged handle to targets such as **LSASS** or **winlogon**. Microsoft documentation for `CreateProcessA` also appeared in the reference set because process creation remains central to many payload chains, including shellcode that ultimately launches command shells or follow-on tooling. Additional reports showed how attackers can blend execution into legitimate Windows behavior and trusted software. iPurple described **EntryPoint Hijacking**, in which a loaded DLL's entry point is overwritten so malicious code runs during normal thread creation or loader activity, reducing obvious injection signals and complicating EDR detection. NVISO separately analyzed Metasploit reverse-shell shellcode that walks the **PEB** and resolves APIs such as `LoadLibraryA`, networking functions, and `CreateProcessA`, while Hunt & Hackett showed that **ConnectWise Control/ScreenConnect** can be used for intrusion activity and that its own event logging can be disabled by patching `ScreenConnect.Core.dll`. Together, the reports underscore that defenders must validate loader integrity, monitor low-visibility handle requests and memory writes, and avoid relying on a single telemetry source such as ETW or application-generated event logs.
Aug 15, 2026
Elastic detailed enhanced Windows user-mode call-stack telemetry in **Elastic Defend** that attributes dual-use behavior to the code that initiated it. The telemetry enriches stack addresses with module exports and identifies the final user module’s path, SHA-256 hash, signature state, memory protections, and provenance, helping analysts identify direct syscalls, proxy execution, shellcode, ROP-like activity, unbacked RWX memory, and truncated or manipulated stacks. Dispatcher functions in captured stacks can also reveal early-thread execution, exception-handler abuse, APC-based execution, and GUI-thread hijacking. The approach addresses a longstanding control-flow defense problem: ordinary stack walking reconstructs return addresses but can be misled by tail calls, trampolines, and stack manipulation. Earlier hardware-assisted CFI research, including Endgame’s HA-CFI, used Intel PMU branch-misprediction traps and Last Branch Record data to validate indirect-call targets and reported detection of ROP and ROPless exploit techniques across tested exploit samples. Elastic’s telemetry-focused implementation makes suspicious control-flow context available in endpoint alerts by default; organizations can also enable it for routine events, balancing additional visibility against increased telemetry volume.
Sep 9, 2026
Researchers reported that **Windows Subsystem for Linux 2 (WSL2)** can be abused to stage malware payloads while evading much of the visibility provided by Windows-native telemetry. Unlike WSL1, which maps Linux activity into the Windows process model, WSL2 runs a full Linux kernel inside a lightweight Hyper-V VM with its own process space, filesystem, and network stack. As a result, network activity initiated inside WSL2 may not appear in Windows tools such as Sysmon, creating a gap for defenders trying to reconstruct attacker behavior. The reporting shows that when a process inside WSL2 writes files into the Windows filesystem through `/mnt/c/`, the resulting activity is attributed on the Windows side to **`DllHost.exe`** via the Plan 9 (`9P`) proxy layer and `vp9fs.dll`, rather than to the originating Linux process. That split obscures the attack chain and turns payload staging into an indirect execution problem, although launching Windows binaries from WSL remains visible because normal Windows processes are created with **`wsl.exe`** as the parent. Defenders were advised to use outcome-based detections, including monitoring for unexpected **`wsl.exe`** execution and suspicious **`DllHost.exe`** creation of executable or script files in user-writable paths such as `Users\Public`, `ProgramData`, and `Windows\Temp`.
Jun 29, 2026