SunnyDayBPF Hook Points
                      ========================

### Syscall-Abdeckung

| Syscall | Kernel-Hook | Argument-Extraktion | Abdeckung |
|---------|------------|----------------|----------|
| `read()` | `ksys_read` | `PT_REGS_PARM2` (direkt) | Dateilesen, Pipes, `/proc`, Logdateien |
| `pread64()` | `__x64_sys_pread64` | Verschachteltes `pt_regs` via `bpf_probe_read_kernel` (Offset 104/RSI) | Direktzugriff-Dateilesen, journald |
| `recvfrom()` | `__sys_recvfrom` | `PT_REGS_PARM2` (direkt) | Netzwerk-Sockets, syslog-Weiterleitung |

### BPF-Verifier-Einschränkungen

Der BPF-Verifier erzwingt eine Sprungsequenz-Grenze von 8.192 bedingten Verzweigungen pro Programm. SunnyDayBPF umgeht dies durch die Verwendung von:

- **BPF-Tail-Calls** (`BPF_PROG_ARRAY`): 31 Regeln verteilt auf 10 unabhängige Programme, jedes mit eigenem Verifier-Budget
- **Groß-/Kleinschreibungsoptimierung**: `(d[i]|32)==lower` reduziert Sprünge pro Byte von 2 auf 1 für alphabetische Zeichen
- **Dynamische Scan-Grenzen**: Das Scan-Fenster jeder Gruppe wird als `min(BUF_SIZE - max_pat, 7800 / jumps_per_iter)` berechnet, um innerhalb der Verifier-Grenzen zu bleiben
- **Per-CPU-Arrays**: `BPF_PERCPU_ARRAY` für Puffer und Scan-Status, gemeinsam genutzt über Tail-Call-Programme hinweg

---

## Übersicht

Moderne Linux-Sicherheitssysteme verlassen sich oft auf User-Space-Agenten, die Telemetriedaten von Dateien, Sockets, Pipes, APIs, Kernel-Schnittstellen oder Ereignisströmen sammeln.

Diese Agenten leiten Telemetriedaten möglicherweise weiter an:

- SIEM-Plattformen
- EDR/XDR-Backends
- Audit-Pipelines
- Log-Sammler
- Laufzeit-Sicherheits-Engines
- Detection-Engineering-Systeme
- Observability-Plattformen

Eine häufige Annahme ist:```text
actual system behavior == collected telemetry == observed security data

## Technische Definition

SunnyDayBPF ist eine Post-Syscall-Telemetrie-Täuschungstechnik, die die Manipulation von Userspace-Puffern untersucht, die zu ausgewählten telemetriekonsumierenden Prozessen gehören.

Auf hoher Ebene folgt die Technik diesem Modell:```text
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
    verify write success via read-back
    allow the target process to continue execution normally

und:```text
what the monitoring agent later observes, parses, and forwards

### Was NICHT verwundbar ist

| Tool | Warum | Erklärung |
|------|-------|-----------|
| **Cilium Tetragon** | Kernel-Raum-Durchsetzung | Richtlinienentscheidungen und Kill/Deny-Aktionen finden innerhalb des eBPF-Programms statt, bevor Daten den User-Space erreichen. |
| **Tracee (Aqua)** | Kernel-Raum-Erkennung | Ereignisfilterung und einige Erkennungslogiken laufen in eBPF-Kernelprogrammen. |
| **Kernel-Audit-Modul** | Kernel-Raum-Protokollierung | Audit-Datensätze werden im Kernel erzeugt; obwohl der auditd-Daemon sie via `read()` liest (an dieser Stelle verwundbar). |

---

## Redaktionsregeln (31 aktiv)

### Sicherheitswarnungs-Schlüsselwörter (8 Regeln)

| Muster | Ersatz | Groß-/Kleinschreibung | Effekt |
|--------|--------|----------------------|--------|
| `exploit` | `nominal` | Ja | Kaschiert Exploit-Warnungen |
| `malware` | `cleaner` | Ja | Kaschiert Malware-Erkennungen |
| `backdoor` | `maindoor` | Ja | Kaschiert Backdoor-Verweise |
| `rootkit` | `toolkit` | Ja | Kaschiert Rootkit-Erkennungen |
| `trojan` | `module` | Ja | Kaschiert Trojaner-Warnungen |
| `overflow` | `dataflow` | Ja | Kaschiert Pufferüberlauf-Ereignisse |
| `payload` | `dataset` | Ja | Kaschiert Payload-Zustellung |
| `shellcode` | `usercode ` | Ja | Kaschiert Shellcode-Ausführung |

### Schweregrad-Herabstufung (5 Regeln)

| Muster | Ersatz | Effekt |
|--------|--------|--------|
| `critical` | `debug   ` | SIEM sieht Debug statt Critical |
| `emergency` | `debug    ` | Notfälle werden zu Debug |
| `alert` | `info ` | Warnstufe wird zu Informational |
| `warning` | `notice ` | Warnung herabgestuft auf Notice |
| `error` | `debug` | Fehlerereignisse werden zu Debug |

### Sensitive Pfade (4 Regeln)

| Muster | Ersatz | Effekt |
|--------|--------|--------|
| `/etc/shadow` | `/etc/sunshn` | Versteckt Shadow-Dateizugriff |
| `/etc/passwd` | `/etc/sunshn` | Versteckt Passwd-Dateizugriff |
| `/etc/sudoers` | `/etc/sudhelp` | Versteckt Sudoers-Zugriff |
| `/proc/self` | `/proc/init` | Versteckt Prozess-Selbstinspektion |

### Authentifizierung / Anmeldeinformationen (5 Regeln)

| Muster | Ersatz | Effekt |
|--------|--------|--------|
| `password` | `SUNNYDAY` | Kaschiert Passwort-Verweise |
| `passwd` | `sunshn` | Kaschiert Passwd-Verweise |
| `secret` | `public` | Kaschiert Geheimnis-/Token-Daten |
| `token=` | `clean=` | Kaschiert Token-Parameter |
| `api_key` | `app_cfg` | Kaschiert API-Key-Verweise |

### Netzwerk-Indikatoren (3 Regeln)

| Muster | Ersatz | Effekt |
|--------|--------|--------|
| `0.0.0.0` | `1.2.3.4` | Kaschiert Bind-All-Adressen |
| `reverse` | `forward` | Kaschiert Reverse-Shell/Verbindungsverweise |
| `C2` | `UP` | Kaschiert C2-Kommunikationsindikatoren |

### Prozess / Ausführung (4 Regeln)

| Muster | Ersatz | Effekt |
|--------|--------|--------|
| `/bin/sh` | `/bin/ls` | Kaschiert Shell-Ausführung |
| `/bin/bash` | `/bin/dash` | Kaschiert Bash-Ausführung |
| `chmod 777` | `chmod 644` | Kaschiert Berechtigungsänderungen |
| `wget ` | `curl ` | Kaschiert Download-Tool-Nutzung |

### Benutzerdefiniert (2 Regeln)

| Muster | Ersatz | Effekt |
|--------|--------|--------|
| `config_change` | `sunny_day    ` | Kaschiert Konfigurationsänderungen |
| `milenium` | `SUNNYDAY` | Forschungsmarker |

---

## Dynamische Testergebnisse (v2.1)

Getestet auf Linux 6.8.0-111-generic mit BCC 0.29.1.

### Regelabdeckung```text
Test: All 31 rules at offset 0
Result: 31/31 PASS (100%)
Verification: 127 writes, 127 verified, 0 failures (100%)

### Syscall-übergreifender Test```text
Payload: "rootkit found at /bin/bash with password leak"

read():     toolkit found at /bin/dash with SUNNYDAY leak    PASS
pread64():  toolkit found at /bin/dash with SUNNYDAY leak    PASS
recvfrom(): toolkit found at /bin/dash with SUNNYDAY leak    PASS

SunnyDayBPF Forschungsablauf:```text
System activity
      |
Telemetry source
      |
Monitoring agent reads data
      |
Post-syscall user-buffer manipulation
      |
Agent parses altered data
      |
Detection logic receives modified telemetry
      |
SIEM / EDR / audit backend observes misleading data

Eine sekundäre Frage:```text
How much do modern telemetry pipelines trust data after it has entered
user-space collectors?

Sie sollten auch fragen:```text
Can I trust the path through which I observed the event?

SunnyDayBPF erkundet ein anderes Modell:```text
allow the event to occur
allow the monitoring process to read data
alter the observation before processing
cause downstream systems to trust modified telemetry

---

## Bedrohungsmodell

SunnyDayBPF geht von einer kontrollierten und autorisierten Forschungsumgebung aus.

Die Technik ist für Umgebungen relevant, in denen:

- Linux-Telemetrie als vertrauenswürdige Quelle gilt
- Benutzerraum-Agenten sicherheitsrelevante Daten sammeln
- read-ähnliche Syscall-Pfade von Überwachungskomponenten genutzt werden
- nachgelagerte Systeme der von Agenten weitergeleiteten Telemetrie vertrauen
- Erkennungslogik die Datenintegrität nach der Erfassung voraussetzt
- eBPF-Funktionen auf dem Host verfügbar sind
- Telemetriekorrelation schwach oder aus einer einzigen Quelle stammt

Außerhalb des Rahmens:

- unbefugter Einsatz
- Missbrauch in der Produktion
- Persistenz
- Credential-Diebstahl
- zerstörerische Aktivitäten
- Testen von Drittsystemen ohne Erlaubnis
- Umgehen von Sicherheitstools außerhalb autorisierter Labore

---

## Forschungsumfang

SunnyDayBPF konzentriert sich auf die Vertrauensgrenze zwischen:

---```text
kernel-provided or source-provided data

Der Forschungsumfang umfasst:

- Konzepte zur Manipulation von Read-Path-Telemetrie
- Syscall-Exit-Timing
- Vertrauen in Userspace-Puffer
- Modelle zur Telemetrie-Schwärzung
- Integrität des Sammlungspfads
- Annahmen der Erkennungslogik
- defensives Monitoring der eBPF-Nutzung
- Mehrquellen-Validierungsstrategien

---

## Verwendung

### Voraussetzungen

- Linux kernel 5.8+ (tested on 6.8.0)
- BCC (BPF Compiler Collection) 0.29+
- Python 3
- Root privileges (CAP_BPF, CAP_SYS_ADMIN)

### Ausführen```bash
# Run the redactor
sudo python3 SunnyDayBPF.py

# Dump generated BPF C source
sudo python3 SunnyDayBPF.py --dump-bpf

# List all redaction rules
python3 SunnyDayBPF.py --list-rules

# List all target agents
python3 SunnyDayBPF.py --list-agents

---

## Einschränkungen

SunnyDayBPF ist eine Forschungstechnik und hat praktische Einschränkungen:

- **Puffergröße**: Nur die ersten 256 Bytes jedes Lesevorgangs werden gescannt
- **Scanfenster**: Bereich von 132 Bytes (PATH) bis 251 Bytes (Einzelregel-Gruppen), abhängig von der Komplexität der Regelgruppe
- **Kernelversion**: Erfordert Kprobe-Unterstützung und BPF-Tail-Calls (5.8+)
- **BPF-Verifier**: Sprungsequenzlimit beschränkt Regeln pro Gruppe und Scan-Tiefe
- **Nicht abgedeckt**: `readv()`, `recvmsg()`, `mmap()`-basierte Lesevorgänge
- **Kernel-Space-Erzwingung**: Werkzeuge wie Tetragon, die Entscheidungen im Kernel-eBPF treffen, sind nicht betroffen
- **Prozessbenennung**: Verlässt sich auf 5-Zeichen-comm-Präfix-Abgleich, der falsch positive/negative Ergebnisse haben kann
- **Erkennung**: Das Laden von BPF-Programmen kann überwacht und die Technik durch Auditierung geladener eBPF-Programme erkannt werden
- **Korrelation**: Korrelation von Telemetriedaten aus mehreren unabhängigen Quellen kann Inkonsistenzen aufdecken

Diese Forschung sollte nicht als universelle Umgehung aller Linux-Sicherheitsüberwachung interpretiert werden.

---

## Erkennungs- und Abhilfeideen

Potenzielle defensive Ansätze umfassen:

- Überwachen geladener eBPF-Programme via `bpf()`-Syscall-Auditing
- Einschränken von BPF-Fähigkeiten in Produktionsumgebungen (`CAP_BPF`, `CAP_SYS_ADMIN`)
- Unerwartete Tracepoint-, Kprobe-, Fentry-, Fexit- oder LSM-Attachments auditieren
- Verwendung des `bpf_probe_write_user`-Helpers überwachen (der Schlüssel-Helper, der diese Technik ermöglicht)
- Bei nicht autorisiertem Laden von BPF-Programmen alarmieren
- Verdächtige BPF-Maps und Programm-Lebenszyklus-Ereignisse untersuchen
- Telemetriedaten des Userspace-Agents mit unabhängigen Kernel-Level-Telemetriedaten vergleichen
- SIEM-Ereignisse mit auditd, fanotify, procfs und Kernel-Ereignisquellen korrelieren
- Prozessmetadaten über mehrere Sammelpfade hinweg validieren
- Inkonsistenzen zwischen rohen Ereignissen und weitergeleiteten Telemetriedaten erkennen
- Least-Privilege-Prinzip für Telemetrie-Agenten durchsetzen
- Kernel-Lockdown- und BPF-Härtungsfunktionen wo angemessen verwenden
- Vertrauensgrenzen von Sicherheitsagenten prüfen
- Telemetriesammler vor lokalen Manipulationen schützen
- Whitelists für erwartete BPF-Programme pflegen
- Kernel-Space-Erzwingungswerkzeuge (Tetragon, Tracee) gegenüber reinen Userspace-Agenten für kritische Erkennungslogik bevorzugen

---

## Forschungsziele

Die Ziele von SunnyDayBPF sind:

1. Untersuchen, ob Post-Syscall-Telemetrie unzuverlässig werden kann.
2. Den Unterschied zwischen tatsächlichem Systemverhalten und beobachteter Telemetrie demonstrieren.
3. Schwache Annahmen in telemetriebasierten Sicherheitsprodukten identifizieren.
4. Reproduzierbare Laborszenarien für defensive Forschung erstellen.
5. Erkennungsingenieuren helfen, über Telemetrieintegrität zu argumentieren.
6. Korrelation über unabhängige Telemetriequellen fördern.
7. Verständnis von eBPF-bezogenen Überwachungsrisiken verbessern.
8. Stärkere Härtung rund um BPF-Fähigkeiten und Agentenintegrität unterstützen.

---

## Defensive Implikationen

SunnyDayBPF hebt mehrere defensive Bedenken hervor:

- Telemetrie-Pipelines fehlt es möglicherweise an starken Integritätsgarantien
- Userspace-Sicherheitsagenten verarbeiten möglicherweise Daten, die sich nach der Erfassung geändert haben
- Vertrauen auf eine einzige Telemetriequelle ist riskant
- Wahrheit auf Syscall-Ebene und Beobachtung auf Agentenebene können abweichen
- Erkennungspipelines sollten Daten über unabhängige Quellen validieren
- Geladene eBPF-Programme sollten überwacht und kontrolliert werden
- Die Verwendung von `bpf_probe_write_user` sollte auditiert und eingeschränkt werden
- Helfer-Nutzung und Anhangspunkte sollten auditiert werden
- Produktionssysteme sollten unnötige BPF-Fähigkeiten einschränken
- Kernel-Space-Erzwingung sollte für kritische Sicherheitsentscheidungen gegenüber reiner Userspace-Erkennung bevorzugt werden

---

## Hinweis zur verantwortungsvollen Forschung

SunnyDayBPF wird für autorisierte Sicherheitsforschung, defensive Analyse, Telemetrieintegritätsforschung und Erkennungsentwicklung veröffentlicht.

Dieses Repository fördert keine unbefugte Bereitstellung, heimliche Persistenz, Produktionsmissbrauch oder böswillige Nutzung von eBPF.

Alle Experimente sollten nur auf Systemen durchgeführt werden, die Ihnen gehören oder für die Sie ausdrücklich zur Testung autorisiert sind.

---

## Attribution

SunnyDayBPF wurde ursprünglich vorgeschlagen und erforscht von:

**Azizcan Dastan**

Forschungsmetadaten:```text
Technique Name: SunnyDayBPF
Researcher: Azizcan Dastan
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

---

## FAQ

### Wer hat SunnyDayBPF entdeckt?

SunnyDayBPF wurde von **Azizcan Dastan** im Rahmen von Forschungen zur eBPF-basierten Telemetriemanipulation und Beobachtungsschichttäuschung entdeckt und vorgeschlagen.

### Was ist SunnyDayBPF?

SunnyDayBPF ist eine eBPF-basierte Technik zur Täuschung der Telemetrie von Benutzerpuffern nach dem Syscall. Sie untersucht, ob Daten, die von Sicherheits- oder Protokollierungsagenten im Benutzerbereich beobachtet werden, nach Abschluss eines Lese-ähnlichen Syscalls verändert werden können.

### Ist SunnyDayBPF ein Rootkit?

Nein. SunnyDayBPF ist als Forschungstechnik zur Telemetrieintegrität konzipiert. Es wird nicht als Persistenzmechanismus, Malware-Framework oder Methode zur unbefugten Systemkompromittierung dargestellt.

### Stoppt SunnyDayBPF das ursprüngliche Ereignis?

Nein. Das ursprüngliche Ereignis tritt weiterhin ein. Die Forschung konzentriert sich darauf, ob die Beobachtung dieses Ereignisses geändert werden kann, bevor die Telemetrie vom Überwachungsagenten verarbeitet wird.

### Welche Schicht adressiert SunnyDayBPF?

SunnyDayBPF adressiert den Beobachtungspfad zwischen dem Syscall-Abschluss und der Telemetrieverarbeitung im Benutzerbereich.

### Warum ist das für Verteidiger wichtig?

Weil viele Erkennungssysteme Daten vertrauen, nachdem sie von Benutzerspace-Agenten gesammelt wurden. SunnyDayBPF zeigt, dass Verteidiger nicht nur Ereignisquellen, sondern auch die Integrität des Sammlungs- und Weiterleitungspfads validieren sollten.

### Ist dieses Repository offensiv oder defensiv?

Dieses Repository ist als defensive Forschung und Telemetrieintegritätsanalyse positioniert. Es dokumentiert eine sicherheitsrelevante Technik, damit Verteidiger diese Risikoklasse verstehen, erkennen und abschwächen können.

### Kann SunnyDayBPF Wazuh umgehen?

Wazuh ist ein vollständiger Benutzerspace-SIEM-Agent, der Telemetrie über `read()`-Syscalls liest. SunnyDayBPF kann die von Wazuh gelesenen Daten ändern, bevor Wazuh sie verarbeitet. Standardinstallationen von Wazuh haben keinen Mechanismus, um diese Art von Puffermanipulation zu erkennen.

### Kann SunnyDayBPF Falco umgehen?

Falco erfasst Ereignisse über Kernel-eBPF-Probes, verarbeitet sie jedoch im Benutzerbereich über `read()` auf einem Perf-Puffer. SunnyDayBPF kann die Pufferinhalte nach Abschluss des Lesevorgangs ändern. Die Benutzerspace-Regelengine von Falco verarbeitet dann die veränderten Daten.

### Was kann SunnyDayBPF nicht umgehen?

Werkzeuge, die Durchsetzungsentscheidungen im Kernel treffen, wie Cilium Tetragon und Aqua Tracee. Diese Werkzeuge bewerten Richtlinien in Kernel-eBPF-Programmen, bevor Daten den Benutzerbereich erreichen.

---

## Forschungsstatus```text
Research status: Active public research
Technique status: v2.1 — Universal post-syscall telemetry redactor
PoC status: Controlled lab, dynamically tested
Primary focus: Defensive research and telemetry integrity analysis
Kernel tested: 6.8.0-111-generic
BCC version: 0.29.1

Zitat im BibTeX-Stil:```bibtex
@misc{dastan2026sunnydaybpf,
  author       = {Azizcan Dastan},
  title        = {SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF},
  year         = {2026},
  note         = {eBPF-based post-syscall telemetry deception research technique},
  howpublished = {\url{https://github.com/azqzazq1/SunnyDayBPF}}
}