SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF

azqzazq1 — Fri, 08 May 2026 19:23:41 +0000

SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF

Security tools do not observe reality directly.

They observe telemetry.

And telemetry is only as trustworthy as the path that produced it.

SunnyDayBPF is a research technique that explores what happens when that path can be influenced after a read-like syscall has already completed.

What is SunnyDayBPF?

SunnyDayBPF is an eBPF-based post-syscall user-buffer telemetry deception research technique originally proposed and researched by Azizcan Daştan.

The technique investigates whether data observed by user-space security, logging, or telemetry agents can be altered after a read-like syscall has completed, but before the agent parses, analyzes, or forwards that data to a downstream security pipeline.

In simple terms:

The event still happens.

The monitoring agent still reads data.

But the data observed by the agent may no longer fully represent the original event.

SunnyDayBPF focuses on the gap between ground truth and observed telemetry.

Why telemetry integrity matters

Modern Linux security systems often rely on user-space agents that collect telemetry from files, sockets, pipes, APIs, kernel interfaces, or event streams.

These agents may forward telemetry to:

SIEM platforms
EDR/XDR backends
audit pipelines
log collectors
runtime security engines
detection engineering systems
observability platforms

A common assumption is:

actual system behavior == collected telemetry == observed security data

This assumption is convenient.

It is also dangerous.

Security products do not usually respond to raw reality. They respond to what their sensors, collectors, parsers, and pipelines observe.

If the observation path can be influenced, the defender’s view of the system can diverge from what actually happened.

SunnyDayBPF explores that trust boundary.

The core idea

SunnyDayBPF is not primarily about hiding a syscall.

It is not simply about preventing an event.

It is about manipulating the observation layer after data has already crossed into a monitored process.

The distinction is important:

Traditional evasion:
    hide or prevent the event

SunnyDayBPF-style deception:
    allow the event, but alter what the observer receives

In this model, the event can still occur normally.

The monitoring process can still perform its read-like operation normally.

The difference is that the buffer containing the returned data may be modified before the agent parses and forwards it.

Normal telemetry flow

In a standard telemetry pipeline, the monitoring agent is treated as a reliable observer.

A system event occurs, a telemetry source exposes information about that event, and a user-space agent reads the data from that source. After the read operation completes, the agent parses the returned data, normalizes it, and forwards it to a downstream security system such as a SIEM, EDR, audit backend, or detection platform.

The important assumption is that the data remains consistent across the entire path.

The event that happened on the system is expected to be the same event that appears in the backend and, eventually, in the defender’s view.

For example, if a suspicious configuration change occurs, the normal expectation is:

Ground truth:        suspicious_config_change
Telemetry source:    suspicious_config_change
Agent buffer:        suspicious_config_change
Forwarded event:     suspicious_config_change
Defender view:       suspicious_config_change

In this model, the monitoring pipeline behaves like a transparent chain of custody. Each stage receives, processes, and forwards the same underlying security signal.

The defender’s alert, dashboard entry, or forensic record is therefore assumed to represent the original event with reasonable accuracy.

That assumption is exactly what SunnyDayBPF challenges.

SunnyDayBPF telemetry flow

SunnyDayBPF explores the telemetry pipeline from a different angle. The technique does not focus on preventing the original event, blocking the read operation, or disabling the monitoring agent.

Instead, it focuses on what happens after a monitoring agent has successfully received telemetry, but before that telemetry is parsed and forwarded.

In a normal pipeline, a system event becomes telemetry, the monitoring agent reads it, and the same data is expected to continue downstream into the SIEM, EDR, audit backend, or detection pipeline.

SunnyDayBPF challenges this assumption.

The research model is based on a narrow but important observation window: the moment after a read-like syscall completes and the agent’s user-space buffer contains telemetry, but before the agent has interpreted that buffer as security data.

At that point, the event has already happened. The telemetry source has already produced data. The monitoring agent has already received that data. However, the data has not yet become part of the agent’s parsed security record.

This is the critical trust boundary.

If the returned buffer is modified during this window, the monitoring agent may continue execution normally while parsing a version of telemetry that no longer fully matches the original event.

The result is a mismatch between system reality and downstream observation:

Ground truth:       the original event occurred
Agent input:        telemetry was received
Observation layer:  the returned buffer was altered
Backend view:       modified telemetry was forwarded
Defender view:      the final record may diverge from reality

This is where SunnyDayBPF focuses: not on whether telemetry was collected, but on whether the collected telemetry can still be trusted before it is interpreted.

Technical model

At a high level, the SunnyDayBPF research model can be described as:

sys_enter_*:
    identify a target telemetry-consuming process
    record the user-space buffer pointer involved in the read-like operation

sys_exit_*:
    verify that the read-like operation completed successfully
    inspect the returned user-space buffer
    selectively alter telemetry-relevant content
    allow the target process to continue execution normally

This creates a mismatch between:

what happened on the system

and:

what the monitoring agent later observes, parses, and forwards

The goal of this research is not to present a production bypass framework.

The goal is to study a telemetry integrity problem: whether user-space security agents can fully trust the data they are about to parse after a read-like syscall completes.

Conceptual example

Consider a simplified telemetry pipeline:

A telemetry agent reads security-relevant data.
The read operation succeeds.
Data is returned into the agent's user-space buffer.
A post-syscall manipulation layer observes the completed operation.
Selected telemetry-relevant content is altered in memory.
The agent continues normally.
The backend receives altered telemetry.

The result may look like this:

Ground truth:
    suspicious or sensitive telemetry existed

Observed telemetry:
    modified, redacted, or misleading representation

This is the core SunnyDayBPF concept.

The event still happened.

The observation changed.

Why this matters for defenders

SunnyDayBPF highlights a simple but important defensive idea:

Telemetry should be treated as a trust boundary, not automatic ground truth.

Many detection pipelines rely heavily on a single source of telemetry.

If that source is a user-space agent, and the agent consumes data after a read-like operation, then defenders should ask:

Can the data be trusted after it has entered the agent's buffer?

This matters for:

forensic timelines
audit records
alerting logic
process visibility
file activity monitoring
compliance evidence
incident response workflows
behavioral detections
SIEM correlation rules

The question is not only:

Did we collect telemetry?

The better question is:

Was the telemetry preserved with integrity before it was processed and forwarded?

Observation-layer deception

SunnyDayBPF is best understood as observation-layer deception.

In many security systems, the sensor is treated as a trusted witness.

But a witness can be misled.

The event may be real, but the observer may receive an altered version of the event.

event happens
telemetry is collected
observation layer is modified
security tool trusts modified telemetry

That is the security problem SunnyDayBPF explores.

Defensive implications

SunnyDayBPF highlights several defensive concerns:

telemetry pipelines may lack strong integrity guarantees
user-space security agents may process data that has changed after collection
single-source telemetry trust is risky
syscall-level truth and agent-level observation may diverge
detection pipelines should validate data across independent sources
loaded eBPF programs should be monitored and controlled
helper usage and attachment points should be audited
production systems should restrict unnecessary BPF capabilities

This does not mean all telemetry is broken.

It means telemetry should be validated like any other security-critical data path.

Detection and mitigation ideas

Potential defensive approaches include:

monitor loaded eBPF programs
restrict BPF capabilities in production environments
audit unexpected tracepoint, kprobe, fentry, fexit, or LSM attachments
monitor use of helpers capable of writing into user memory
alert on unauthorized BPF program loading
inspect suspicious BPF maps and program lifecycle events
compare user-space agent telemetry with independent kernel-level telemetry
correlate SIEM events with auditd, fanotify, procfs, and kernel event sources
validate process metadata across multiple collection paths
detect inconsistencies between raw events and forwarded telemetry
enforce least privilege for telemetry agents
use kernel lockdown and BPF hardening features where appropriate
review security agent trust boundaries
protect telemetry collectors from local tampering
maintain allowlists for expected BPF programs

A stronger telemetry integrity model should include:

source diversity
+ cross-signal correlation
+ agent hardening
+ BPF capability restriction
+ BPF program monitoring
+ event sequence validation

Limitations

SunnyDayBPF is a research technique and has practical limitations.

Potential limitations include:

kernel version differences
verifier constraints
BPF capability requirements
attachment point availability
process targeting reliability
timing sensitivity
telemetry source variability
kernel lockdown mode
BPF restrictions
detection by runtime security systems
mismatch when defenders correlate multiple independent telemetry sources

This research should not be interpreted as a universal bypass of all Linux security monitoring.

It is a focused investigation into a telemetry trust boundary.

Responsible research position

SunnyDayBPF is published for authorized security research, defensive analysis, telemetry integrity research, and detection engineering.

It is not intended for:

unauthorized deployment
production abuse
stealth persistence
credential theft
destructive behavior
targeting third-party systems
bypassing security tools without permission

All experiments should be performed only in systems you own or are explicitly authorized to test.

The purpose of publishing this work is to help defenders understand, detect, and mitigate this class of telemetry integrity risk.

Repository

The SunnyDayBPF research repository includes:

research README
citation metadata
responsible-use documentation
telemetry flow diagrams
controlled lab PoC notes
detection engineering ideas
threat model
limitations

Repository:

https://github.com/azqzazq1/SunnyDayBPF

Attribution

SunnyDayBPF was originally proposed and researched by:

Azizcan Daştan

Research metadata:

Technique Name: SunnyDayBPF
Researcher: Azizcan Daştan
LinkedIn: https://www.linkedin.com/in/azqzazq
GitHub: https://github.com/azqzazq1
Category: eBPF Security Research
Focus Area: Post-Syscall User-Buffer Telemetry Deception
Initial Public Release: 2026

Suggested citation:

Daştan, Azizcan. "SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF." 2026.

Final thought

SunnyDayBPF is based on a simple defensive principle:

Security visibility is only as trustworthy as the path that produced it.

If defenders treat telemetry as automatic ground truth, they may miss the trust boundaries inside the collection pipeline.

SunnyDayBPF exists to make that boundary visible.

Originally published as part of the SunnyDayBPF research documentation.

Repository: https://github.com/azqzazq1/SunnyDayBPF

Author: Azizcan Daştan

LinkedIn: https://www.linkedin.com/in/azqzazq

DEV Community: azqzazq1

SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF

SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF

What is SunnyDayBPF?

Why telemetry integrity matters

The core idea

Normal telemetry flow

SunnyDayBPF telemetry flow

Technical model

Conceptual example

Why this matters for defenders

Observation-layer deception

Defensive implications

Detection and mitigation ideas

Limitations

Responsible research position

Repository

Attribution

Final thought