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

### Copertura delle Syscall

| Syscall | Hook del Kernel | Estrazione Arg | Copertura |
|---------|----------------|----------------|----------|
| `read()` | `ksys_read` | `PT_REGS_PARM2` (diretta) | Letture di file, pipe, `/proc`, file di log |
| `pread64()` | `__x64_sys_pread64` | `pt_regs` annidati tramite `bpf_probe_read_kernel` (offset 104/RSI) | Letture di file ad accesso casuale, journald |
| `recvfrom()` | `__sys_recvfrom` | `PT_REGS_PARM2` (diretta) | Socket di rete, inoltro syslog |

### Vincoli del Verificatore BPF

Il verificatore BPF impone un limite di sequenza di salti di 8.192 rami condizionali per programma. SunnyDayBPF aggira questo limite utilizzando:

- **Chiamate coda BPF** (`BPF_PROG_ARRAY`): 31 regole suddivise in 10 programmi indipendenti, ciascuno con il proprio budget del verificatore
- **Ottimizzazione case-insensitive**: `(d[i]|32)==lower` riduce i salti per byte da 2 a 1 per i caratteri alfabetici
- **Limiti di scansione dinamici**: La finestra di scansione di ciascun gruppo è calcolata come `min(BUF_SIZE - max_pat, 7800 / jumps_per_iter)` per rimanere entro i limiti del verificatore
- **Array per-CPU**: `BPF_PERCPU_ARRAY` per buffer temporaneo e stato di scansione, condivisi tra programmi chiamati in coda

---

## Panoramica

I moderni sistemi di sicurezza Linux si basano spesso su agenti nello spazio utente che raccolgono telemetria da file, socket, pipe, API, interfacce del kernel o flussi di eventi.

Questi agenti possono inoltrare la telemetria a:

- piattaforme SIEM
- backend EDR/XDR
- pipeline di audit
- collettori di log
- motori di sicurezza runtime
- sistemi di ingegneria della detection
- piattaforme di osservabilità

Un presupposto comune è:```text
actual system behavior == collected telemetry == observed security data

## Definizione tecnica

SunnyDayBPF è una tecnica di inganno della telemetria post-syscall che studia la manipolazione dei buffer dello spazio utente appartenenti a processi selezionati consumatori di telemetria.

A livello generale, la tecnica segue questo modello:```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

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

### Cosa NON è vulnerabile

| Strumento | Motivo | Spiegazione |
|-----------|--------|-------------|
| **Cilium Tetragon** | Applicazione nello spazio kernel | Le decisioni delle policy e le azioni di kill/deny avvengono all'interno del programma eBPF, prima che i dati raggiungano lo spazio utente |
| **Tracee (Aqua)** | Rilevamento nello spazio kernel | Il filtraggio degli eventi e parte della logica di rilevamento vengono eseguiti nei programmi eBPF del kernel |
| **Modulo di audit del kernel** | Registrazione nello spazio kernel | I record di audit vengono generati nel kernel; tuttavia il demone auditd li legge tramite `read()` (vulnerabile in quella fase) |

---

## Regole di redazione (31 attive)

### Parole chiave di avvisi di sicurezza (8 regole)

| Pattern | Sostituzione | Case-Insensitive | Effetto |
|---------|--------------|-------------------|---------|
| `exploit` | `nominal` | Sì | Maschera gli avvisi di exploit |
| `malware` | `cleaner` | Sì | Maschera le rilevazioni di malware |
| `backdoor` | `maindoor` | Sì | Maschera i riferimenti a backdoor |
| `rootkit` | `toolkit` | Sì | Maschera le rilevazioni di rootkit |
| `trojan` | `module` | Sì | Maschera gli avvisi di trojan |
| `overflow` | `dataflow` | Sì | Maschera gli eventi di buffer overflow |
| `payload` | `dataset` | Sì | Maschera la consegna del payload |
| `shellcode` | `usercode ` | Sì | Maschera l'esecuzione di shellcode |

### Declassamento della gravità (5 regole)

| Pattern | Sostituzione | Effetto |
|---------|--------------|---------|
| `critical` | `debug   ` | Il SIEM vede debug invece di critical |
| `emergency` | `debug    ` | Gli eventi di emergenza diventano debug |
| `alert` | `info ` | Il livello di allerta diventa informativo |
| `warning` | `notice ` | Avviso declassato a notice |
| `error` | `debug` | Gli eventi di errore diventano debug |

### Percorsi sensibili (4 regole)

| Pattern | Sostituzione | Effetto |
|---------|--------------|---------|
| `/etc/shadow` | `/etc/sunshn` | Nasconde l'accesso al file shadow |
| `/etc/passwd` | `/etc/sunshn` | Nasconde l'accesso al file passwd |
| `/etc/sudoers` | `/etc/sudhelp` | Nasconde l'accesso a sudoers |
| `/proc/self` | `/proc/init` | Nasconde l'auto-ispezione del processo |

### Autenticazione / Credenziali (5 regole)

| Pattern | Sostituzione | Effetto |
|---------|--------------|---------|
| `password` | `SUNNYDAY` | Maschera i riferimenti a password |
| `passwd` | `sunshn` | Maschera i riferimenti a passwd |
| `secret` | `public` | Maschera i dati segreti/token |
| `token=` | `clean=` | Maschera i parametri token |
| `api_key` | `app_cfg` | Maschera i riferimenti alla chiave API |

### Indicatori di rete (3 regole)

| Pattern | Sostituzione | Effetto |
|---------|--------------|---------|
| `0.0.0.0` | `1.2.3.4` | Maschera gli indirizzi bind-all |
| `reverse` | `forward` | Maschera i riferimenti a reverse shell/connessione |
| `C2` | `UP` | Maschera gli indicatori di comunicazione C2 |

### Processo / Esecuzione (4 regole)

| Pattern | Sostituzione | Effetto |
|---------|--------------|---------|
| `/bin/sh` | `/bin/ls` | Maschera l'esecuzione di shell |
| `/bin/bash` | `/bin/dash` | Maschera l'esecuzione di bash |
| `chmod 777` | `chmod 644` | Maschera le modifiche ai permessi |
| `wget ` | `curl ` | Maschera l'uso dello strumento di download |

### Personalizzate (2 regole)

| Pattern | Sostituzione | Effetto |
|---------|--------------|---------|
| `config_change` | `sunny_day    ` | Maschera le modifiche alla configurazione |
| `milenium` | `SUNNYDAY` | Marcatore di ricerca |

---

## Risultati dei test dinamici (v2.1)

Testato su Linux 6.8.0-111-generic con BCC 0.29.1.

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

### Test tra syscall```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 flusso di ricerca:```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

Una domanda secondaria:```text
How much do modern telemetry pipelines trust data after it has entered
user-space collectors?

Dovrebbero anche chiedere:```text
Can I trust the path through which I observed the event?

SunnyDayBPF esplora un modello diverso:```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

---

## Modello di minaccia

SunnyDayBPF presuppone un ambiente di ricerca controllato e autorizzato.

La tecnica è rilevante in ambienti dove:

- La telemetria Linux è considerata una fonte di verità
- gli agenti in spazio utente raccolgono dati rilevanti per la sicurezza
- i percorsi delle syscall di tipo read sono utilizzati dai componenti di monitoraggio
- i sistemi downstream fidano della telemetria inoltrata dagli agenti
- la logica di rilevamento presuppone l'integrità dei dati dopo la raccolta
- le capacità eBPF sono disponibili sull'host
- la correlazione della telemetria è debole o a fonte singola

Fuori ambito:

- distribuzione non autorizzata
- abuso in produzione
- persistenza
- furto di credenziali
- attività distruttiva
- test su sistemi di terze parti senza permesso
- bypass di strumenti di sicurezza al di fuori di laboratori autorizzati

---

## Ambito di ricerca

SunnyDayBPF si concentra sul confine di fiducia tra:```text
kernel-provided or source-provided data

Il campo di ricerca include:

- concetti di manipolazione della telemetria del percorso di lettura
- tempistica di uscita delle syscall
- fiducia nei buffer dello spazio utente
- modelli di redazione della telemetria
- integrità del percorso di raccolta
- assunzioni della logica di rilevamento
- monitoraggio difensivo dell'uso di eBPF
- strategie di validazione multi-fonte

---

## Utilizzo

### Requisiti

- Linux kernel 5.8+ (testato su 6.8.0)
- BCC (BPF Compiler Collection) 0.29+
- Python 3
- Privilegi di root (CAP_BPF, CAP_SYS_ADMIN)

### Esecuzione```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

## Limitazioni

SunnyDayBPF è una tecnica di ricerca e presenta limitazioni pratiche:

- **Dimensione del buffer**: Vengono scansionati solo i primi 256 byte di ogni lettura
- **Finestre di scansione**: Vanno da 132 byte (PATH) a 251 byte (gruppi a regola singola) a seconda della complessità del gruppo di regole
- **Versione del kernel**: Richiede supporto kprobe e tail call BPF (5.8+)
- **Verificatore BPF**: Il limite della sequenza di salto vincola le regole per gruppo e la profondità di scansione
- **Non coperto**: Letture basate su `readv()`, `recvmsg()`, `mmap()`
- **Applicazione nello spazio kernel**: Strumenti come Tetragon che prendono decisioni in eBPF del kernel non sono influenzati
- **Denominazione dei processi**: Si basa sul matching del prefisso comm di 5 caratteri che potrebbe dare falsi positivi/negativi
- **Rilevamento**: Il caricamento del programma BPF può essere monitorato e la tecnica rilevata tramite audit dei programmi eBPF caricati
- **Correlazione**: La correlazione della telemetria multi-sorgente attraverso canali indipendenti può rivelare incongruenze

Questa ricerca non deve essere interpretata come un bypass universale di tutto il monitoraggio di sicurezza Linux.

---

## Idee per il rilevamento e la mitigazione

Potenziali approcci difensivi includono:

- monitorare i programmi eBPF caricati tramite audit della syscall `bpf()`
- limitare le capacità BPF negli ambienti di produzione (`CAP_BPF`, `CAP_SYS_ADMIN`)
- audit degli attach inaspettati a tracepoint, kprobe, fentry, fexit o LSM
- monitorare l'uso dell'helper `bpf_probe_write_user` (l'helper chiave che abilita questa tecnica)
- allertare sul caricamento non autorizzato di programmi BPF
- ispezionare mappe BPF sospette ed eventi del ciclo di vita dei programmi
- confrontare la telemetria dell'agente nello spazio utente con la telemetria indipendente a livello kernel
- correlare gli eventi SIEM con auditd, fanotify, procfs e fonti di eventi del kernel
- validare i metadati del processo attraverso più percorsi di raccolta
- rilevare incongruenze tra eventi grezzi e telemetria inoltrata
- applicare il minimo privilegio per gli agenti di telemetria
- utilizzare funzionalità di lockdown del kernel e hardening BPF dove appropriato
- rivedere i confini di fiducia degli agenti di sicurezza
- proteggere i collettori di telemetria da manomissioni locali
- mantenere allowlist per i programmi BPF attesi
- preferire strumenti di applicazione nello spazio kernel (Tetragon, Tracee) rispetto a puri agenti nello spazio utente per logiche di rilevamento critiche

---

## Obiettivi della ricerca

Gli obiettivi di SunnyDayBPF sono:

1. Esplorare se la telemetria post-syscall può diventare inaffidabile.
2. Dimostrare la differenza tra il comportamento reale del sistema e la telemetria osservata.
3. Identificare ipotesi deboli nei prodotti di sicurezza basati su telemetria.
4. Costruire scenari di laboratorio riproducibili per la ricerca difensiva.
5. Aiutare gli ingegneri di rilevamento a ragionare sull'integrità della telemetria.
6. Incoraggiare la correlazione tra fonti di telemetria indipendenti.
7. Migliorare la comprensione dei rischi di monitoraggio legati a eBPF.
8. Supportare un hardening più forte attorno alle capacità BPF e all'integrità degli agenti.

---

## Implicazioni difensive

SunnyDayBPF evidenzia diverse preoccupazioni difensive:

- i pipeline di telemetria potrebbero mancare di forti garanzie di integrità
- gli agenti di sicurezza nello spazio utente potrebbero elaborare dati che sono cambiati dopo la raccolta
- la fiducia nella telemetria a fonte singola è rischiosa
- la verità a livello di syscall e l'osservazione a livello di agente potrebbero divergere
- i pipeline di rilevamento dovrebbero validare i dati attraverso fonti indipendenti
- i programmi eBPF caricati dovrebbero essere monitorati e controllati
- l'uso di `bpf_probe_write_user` dovrebbe essere auditato e limitato
- l'uso degli helper e i punti di attacco dovrebbero essere auditati
- i sistemi di produzione dovrebbero limitare le capacità BPF non necessarie
- l'applicazione nello spazio kernel dovrebbe essere preferita al rilevamento solo nello spazio utente per decisioni critiche di sicurezza

---

## Avviso di ricerca responsabile

SunnyDayBPF è pubblicato per ricerca di sicurezza autorizzata, analisi difensiva, ricerca sull'integrità della telemetria e ingegneria del rilevamento.

Questo repository non incoraggia l'implementazione non autorizzata, la persistenza stealth, l'abuso in produzione o l'uso malevolo di eBPF.

Tutti gli esperimenti dovrebbero essere eseguiti solo su sistemi di tua proprietà o per i quali hai esplicita autorizzazione a testare.

---

## Attribuzione

SunnyDayBPF è stato originariamente proposto e ricercato da:

**Azizcan Dastan**

Metadati della ricerca:```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

### Chi ha scoperto SunnyDayBPF?

SunnyDayBPF è stato scoperto e proposto da **Azizcan Dastan** nell'ambito di una ricerca sulla manipolazione della telemetria basata su eBPF e sull'inganno a livello di osservazione.

### Cos'è SunnyDayBPF?

SunnyDayBPF è una tecnica di inganno della telemetria basata su eBPF per buffer utente post-syscall. Analizza se i dati osservati dagli agenti di sicurezza o logging nello spazio utente possano essere alterati dopo il completamento di una syscall di tipo read.

### SunnyDayBPF è un rootkit?

No. SunnyDayBPF è presentato come una tecnica di ricerca sull'integrità della telemetria. Non è proposto come meccanismo di persistenza, framework malware o metodo di compromissione non autorizzata del sistema.

### SunnyDayBPF ferma l'evento originale?

No. L'evento originale si verifica comunque. La ricerca si concentra sulla possibilità di modificare l'osservazione di quell'evento prima che la telemetria venga elaborata dall'agente di monitoraggio.

### Quale layer prende di mira SunnyDayBPF?

SunnyDayBPF prende di mira il percorso di osservazione tra il completamento della syscall e l'elaborazione della telemetria nello spazio utente.

### Perché questo è importante per i difensori?

Perché molti sistemi di rilevamento si fidano dei dati dopo che sono stati raccolti da agenti nello spazio utente. SunnyDayBPF mostra che i difensori dovrebbero validare non solo le fonti degli eventi, ma anche l'integrità del percorso di raccolta e inoltro.

### Questo repository è offensivo o difensivo?

Questo repository è posizionato come ricerca difensiva e analisi dell'integrità della telemetria. Documenta una tecnica rilevante per la sicurezza in modo che i difensori possano comprendere, rilevare e mitigare questa classe di rischio.

### SunnyDayBPF può bypassare Wazuh?

Wazuh è un agente SIEM interamente in spazio utente che legge la telemetria tramite syscall `read()`. SunnyDayBPF può modificare i dati che Wazuh legge prima che Wazuh li elabori. Le installazioni predefinite di Wazuh non hanno alcun meccanismo per rilevare questo tipo di manipolazione del buffer.

### SunnyDayBPF può bypassare Falco?

Falco cattura gli eventi tramite sonde eBPF nel kernel, ma li elabora nello spazio utente tramite `read()` su un buffer perf. SunnyDayBPF può modificare il contenuto del buffer dopo il completamento della lettura. Il motore delle regole in spazio utente di Falco elabora quindi dati alterati.

### Cosa non può bypassare SunnyDayBPF?

Strumenti che prendono decisioni di enforcement all'interno del kernel, come Cilium Tetragon e Aqua Tracee. Questi strumenti valutano le politiche in programmi eBPF del kernel prima che i dati raggiungano lo spazio utente.

## Stato della Ricerca```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

Citazione in stile BibTeX:```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}}
}