### Couverture des syscalls

| Syscall | Hook noyau | Extraction d'arguments | Couverture |
|---------|------------|----------------|----------|
| `read()` | `ksys_read` | `PT_REGS_PARM2` (direct) | Lectures de fichiers, pipes, `/proc`, fichiers de log |
| `pread64()` | `__x64_sys_pread64` | `pt_regs` imbriqués via `bpf_probe_read_kernel` (offset 104/RSI) | Lectures de fichiers à accès aléatoire, journald |
| `recvfrom()` | `__sys_recvfrom` | `PT_REGS_PARM2` (direct) | Sockets réseau, transfert syslog |

### Contraintes du vérificateur BPF

Le vérificateur BPF impose une limite de séquence de sauts de 8 192 branches conditionnelles par programme. SunnyDayBPF contourne cette limitation en utilisant :

- **Appels de queue BPF** (`BPF_PROG_ARRAY`) : 31 règles réparties sur 10 programmes indépendants, chacun avec son propre budget de vérificateur
- **Optimisation insensible à la casse** : `(d[i]|32)==lower` réduit les sauts par octet de 2 à 1 pour les caractères alphabétiques
- **Limites dynamiques de balayage** : La fenêtre de balayage de chaque groupe est calculée comme `min(BUF_SIZE - max_pat, 7800 / jumps_per_iter)` pour rester dans les limites du vérificateur
- **Tableaux par CPU** : `BPF_PERCPU_ARRAY` pour le tampon temporaire et l'état de balayage, partagés entre les programmes invoqués par tail calls

---

## Aperçu

Les systèmes de sécurité Linux modernes s'appuient souvent sur des agents en espace utilisateur qui collectent la télémétrie à partir de fichiers, de sockets, de pipes, d'API, d'interfaces noyau ou de flux d'événements.

Ces agents peuvent transmettre la télémétrie à :

- Plateformes SIEM
- Backends EDR/XDR
- Pipelines d'audit
- Collecteurs de journaux
- Moteurs de sécurité runtime
- Systèmes d'ingénierie de détection
- Plateformes d'observabilité

Une hypothèse courante est :```text
actual system behavior == collected telemetry == observed security data

---

## Définition technique

SunnyDayBPF est une technique de déception de télémétrie post-syscall qui étudie la manipulation des buffers d'espace utilisateur appartenant à des processus sélectionnés consommant de la télémétrie.

À un niveau élevé, la technique suit ce modèle :```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

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

### Ce qui n'est pas vulnérable

| Outil | Pourquoi | Explication |
|------|-----|-------------|
| **Cilium Tetragon** | Application au niveau du noyau | Les décisions de politique et les actions de kill/deny se déroulent dans le programme eBPF, avant que les données n'atteignent l'espace utilisateur |
| **Tracee (Aqua)** | Détection au niveau du noyau | Le filtrage des événements et une partie de la logique de détection s'exécutent dans les programmes eBPF du noyau |
| **Module d'audit du noyau** | Journalisation au niveau du noyau | Les enregistrements d'audit sont générés dans le noyau ; bien que le démon auditd les lise via `read()` (vulnérable à ce stade) |

---

## Règles de masquage (31 actives)

### Mots-clés d'alerte de sécurité (8 règles)

| Motif | Remplacement | Insensible à la casse | Effet |
|---------|------------|-------------------|--------|
| `exploit` | `nominal` | Oui | Masque les alertes d'exploitation |
| `malware` | `cleaner` | Oui | Masque les détections de malware |
| `backdoor` | `maindoor` | Oui | Masque les références à une backdoor |
| `rootkit` | `toolkit` | Oui | Masque les détections de rootkit |
| `trojan` | `module` | Oui | Masque les alertes de cheval de Troie |
| `overflow` | `dataflow` | Oui | Masque les événements de dépassement de tampon |
| `payload` | `dataset` | Oui | Masque la livraison de charge utile |
| `shellcode` | `usercode ` | Oui | Masque l'exécution de shellcode |

### Rétrogradation de sévérité (5 règles)

| Motif | Remplacement | Effet |
|---------|------------|--------|
| `critical` | `debug   ` | Le SIEM voit debug au lieu de critical |
| `emergency` | `debug    ` | Les événements d'urgence deviennent debug |
| `alert` | `info ` | Le niveau d'alerte devient informationnel |
| `warning` | `notice ` | L'avertissement est rétrogradé en notice |
| `error` | `debug` | Les événements d'erreur deviennent debug |

### Chemins sensibles (4 règles)

| Motif | Remplacement | Effet |
|---------|------------|--------|
| `/etc/shadow` | `/etc/sunshn` | Masque l'accès au fichier shadow |
| `/etc/passwd` | `/etc/sunshn` | Masque l'accès au fichier passwd |
| `/etc/sudoers` | `/etc/sudhelp` | Masque l'accès à sudoers |
| `/proc/self` | `/proc/init` | Masque l'auto-inspection du processus |

### Authentification / Identifiants (5 règles)

| Motif | Remplacement | Effet |
|---------|------------|--------|
| `password` | `SUNNYDAY` | Masque les références aux mots de passe |
| `passwd` | `sunshn` | Masque les références à passwd |
| `secret` | `public` | Masque les données secrètes/jeton |
| `token=` | `clean=` | Masque les paramètres de jeton |
| `api_key` | `app_cfg` | Masque les références de clé API |

### Indicateurs réseau (3 règles)

| Motif | Remplacement | Effet |
|---------|------------|--------|
| `0.0.0.0` | `1.2.3.4` | Masque les adresses bind-all |
| `reverse` | `forward` | Masque les références aux shells/connexions inverses |
| `C2` | `UP` | Masque les indicateurs de communication C2 |

### Processus / Exécution (4 règles)

| Motif | Remplacement | Effet |
|---------|------------|--------|
| `/bin/sh` | `/bin/ls` | Masque l'exécution de shell |
| `/bin/bash` | `/bin/dash` | Masque l'exécution de bash |
| `chmod 777` | `chmod 644` | Masque les changements de permissions |
| `wget ` | `curl ` | Masque l'utilisation de l'outil de téléchargement |

### Règles personnalisées (2 règles)

| Motif | Remplacement | Effet |
|---------|------------|--------|
| `config_change` | `sunny_day    ` | Masque les changements de configuration |
| `milenium` | `SUNNYDAY` | Marqueur de recherche |

---

## Résultats des tests dynamiques (v2.1)

Testé sur Linux 6.8.0-111-generic avec BCC 0.29.1.

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

### Test de syscall croisé```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

Flux de recherche de SunnyDayBPF :```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

Une question secondaire :```text
How much do modern telemetry pipelines trust data after it has entered
user-space collectors?

Ils devraient également demander :```text
Can I trust the path through which I observed the event?

SunnyDayBPF explore un modèle différent :```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

---

## Modèle de menace

SunnyDayBPF suppose un environnement de recherche contrôlé et autorisé.

Cette technique est pertinente pour les environnements où :

- la télémétrie Linux est considérée comme une source de vérité
- les agents en espace utilisateur collectent des données pertinentes pour la sécurité
- les chemins d'appels système de type read sont utilisés par les composants de surveillance
- les systèmes en aval font confiance à la télémétrie transmise par les agents
- la logique de détection suppose l'intégrité des données après la collecte
- les capacités eBPF sont disponibles sur l'hôte
- la corrélation de la télémétrie est faible ou à source unique

Hors périmètre :

- déploiement non autorisé
- abus en production
- persistance
- vol d'identifiants
- activité destructrice
- test de systèmes tiers sans autorisation
- contournement d'outils de sécurité en dehors des laboratoires autorisés

---

## Périmètre de recherche

SunnyDayBPF se concentre sur la frontière de confiance entre :```text
kernel-provided or source-provided data

The research scope includes:

- concepts de manipulation de la télémétrie du chemin de lecture
- timing de sortie des appels système
- confiance dans les buffers d'espace utilisateur
- modèles de rédaction de télémétrie
- intégrité du chemin de collecte
- hypothèses de logique de détection
- surveillance défensive de l'utilisation d'eBPF
- stratégies de validation multi-sources

---

## Utilisation

### Prérequis

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

### Exécution```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

---

## Limitations

SunnyDayBPF est une technique de recherche et présente des limites pratiques :

- **Taille de tampon** : seuls les 256 premiers octets de chaque lecture sont analysés
- **Fenêtres d'analyse** : de 132 octets (PATH) à 251 octets (groupes à règle unique) selon la complexité du groupe de règles
- **Version du noyau** : nécessite la prise en charge de kprobe et les appels de queue BPF (5.8+)
- **Vérificateur BPF** : la limite de séquence de sauts contraint les règles par groupe et la profondeur d'analyse
- **Non couvert** : `readv()`, `recvmsg()`, lectures basées sur `mmap()`
- **Application dans l'espace noyau** : les outils comme Tetragon qui prennent des décisions dans l'eBPF du noyau ne sont pas affectés
- **Nommage des processus** : repose sur la correspondance du préfixe comm de 5 caractères, ce qui peut entraîner des faux positifs/négatifs
- **Détection** : le chargement de programmes BPF peut être surveillé et la technique détectée par l'audit des programmes eBPF chargés
- **Corrélation** : la corrélation de télémétrie multi-sources sur des canaux indépendants peut révéler des incohérences

Cette recherche ne doit pas être interprétée comme un contournement universel de toute surveillance de sécurité Linux.

---

## Idées de détection et d'atténuation

Les approches défensives potentielles incluent :

- surveiller les programmes eBPF chargés via l'audit de l'appel système `bpf()`
- restreindre les capacités BPF dans les environnements de production (`CAP_BPF`, `CAP_SYS_ADMIN`)
- auditer les attachements inattendus de tracepoints, kprobes, fentry, fexit ou LSM
- surveiller l'utilisation de l'assistant `bpf_probe_write_user` (l'assistant clé qui permet cette technique)
- alerter sur le chargement non autorisé de programmes BPF
- inspecter les cartes BPF suspectes et les événements du cycle de vie des programmes
- comparer la télémétrie des agents en espace utilisateur avec la télémétrie indépendante au niveau du noyau
- corréler les événements SIEM avec auditd, fanotify, procfs et les sources d'événements du noyau
- valider les métadonnées de processus sur plusieurs chemins de collecte
- détecter les incohérences entre les événements bruts et la télémétrie transférée
- appliquer le moindre privilège pour les agents de télémétrie
- utiliser le verrouillage du noyau et les fonctionnalités de durcissement BPF lorsque cela est approprié
- revoir les frontières de confiance des agents de sécurité
- protéger les collecteurs de télémétrie contre toute altération locale
- maintenir des listes blanches pour les programmes BPF attendus
- privilégier les outils d'application dans l'espace noyau (Tetragon, Tracee) aux agents purement en espace utilisateur pour la logique de détection critique

---

## Objectifs de recherche

Les objectifs de SunnyDayBPF sont :

1. Explorer si la télémétrie post-appel système peut devenir peu fiable.
2. Démontrer la différence entre le comportement réel du système et la télémétrie observée.
3. Identifier les hypothèses faibles des produits de sécurité basés sur la télémétrie.
4. Construire des scénarios de laboratoire reproductibles pour la recherche défensive.
5. Aider les ingénieurs de détection à raisonner sur l'intégrité de la télémétrie.
6. Encourager la corrélation entre sources de télémétrie indépendantes.
7. Améliorer la compréhension des risques de surveillance liés à eBPF.
8. Soutenir un durcissement plus fort autour des capacités BPF et de l'intégrité des agents.

---

## Implications défensives

SunnyDayBPF met en évidence plusieurs préoccupations défensives :

- les pipelines de télémétrie peuvent manquer de garanties d'intégrité fortes
- les agents de sécurité en espace utilisateur peuvent traiter des données qui ont changé après la collecte
- la confiance en une télémétrie à source unique est risquée
- la vérité au niveau de l'appel système et l'observation au niveau de l'agent peuvent diverger
- les pipelines de détection devraient valider les données sur des sources indépendantes
- les programmes eBPF chargés devraient être surveillés et contrôlés
- l'utilisation de `bpf_probe_write_user` devrait être auditée et restreinte
- l'utilisation des assistants et les points d'attachement devraient être audités
- les systèmes de production devraient restreindre les capacités BPF inutiles
- l'application dans l'espace noyau devrait être préférée à la détection exclusivement en espace utilisateur pour les décisions de sécurité critiques

---

## Avis de recherche responsable

SunnyDayBPF est publié pour la recherche en sécurité autorisée, l'analyse défensive, la recherche sur l'intégrité de la télémétrie et l'ingénierie de détection.

Ce référentiel n'encourage pas le déploiement non autorisé, la persistance furtive, l'abus en production ou l'utilisation malveillante d'eBPF.

Toutes les expériences doivent être effectuées uniquement sur des systèmes que vous possédez ou sur lesquels vous êtes explicitement autorisé à tester.

---

## Attribution

SunnyDayBPF a été initialement proposé et étudié par :

**Azizcan Dastan**

Métadonnées de recherche :```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

### Qui a découvert SunnyDayBPF ?

SunnyDayBPF a été découvert et proposé par **Azizcan Dastan** dans le cadre de recherches sur la manipulation de télémétrie basée sur eBPF et la tromperie au niveau de la couche d'observation.

### Qu'est-ce que SunnyDayBPF ?

SunnyDayBPF est une technique de tromperie de télémétrie par buffer utilisateur post-syscall basée sur eBPF. Elle examine si les données observées par les agents de sécurité ou de journalisation en espace utilisateur peuvent être modifiées après la fin d'un syscall de type lecture.

### SunnyDayBPF est-il un rootkit ?

Non. SunnyDayBPF est présenté comme une technique de recherche sur l'intégrité de la télémétrie. Il n'est pas proposé comme un mécanisme de persistance, un framework malveillant ou une méthode de compromission non autorisée du système.

### SunnyDayBPF empêche-t-il l'événement d'origine ?

Non. L'événement d'origine se produit toujours. La recherche se concentre sur la possibilité de modifier l'observation de cet événement avant que la télémétrie ne soit traitée par l'agent de surveillance.

### Quelle couche SunnyDayBPF cible-t-il ?

SunnyDayBPF cible le chemin d'observation entre la fin du syscall et le traitement de la télémétrie en espace utilisateur.

### Pourquoi est-ce important pour les défenseurs ?

Parce que de nombreux systèmes de détection font confiance aux données après qu'elles ont été collectées par des agents en espace utilisateur. SunnyDayBPF montre que les défenseurs doivent valider non seulement les sources d'événements, mais aussi l'intégrité du chemin de collecte et de transmission.

### Ce dépôt est-il offensif ou défensif ?

Ce dépôt se positionne comme une recherche défensive et une analyse d'intégrité de la télémétrie. Il documente une technique liée à la sécurité afin que les défenseurs puissent comprendre, détecter et atténuer cette classe de risque.

### SunnyDayBPF peut-il contourner Wazuh ?

Wazuh est un agent SIEM entièrement en espace utilisateur qui lit la télémétrie via des appels système `read()`. SunnyDayBPF peut modifier les données que Wazuh lit avant que Wazuh ne les traite. Les installations Wazuh par défaut ne disposent d'aucun mécanisme pour détecter ce type de manipulation de buffer.

### SunnyDayBPF peut-il contourner Falco ?

Falco capture les événements via des sondes eBPF du noyau, mais les traite en espace utilisateur via `read()` sur un buffer perf. SunnyDayBPF peut modifier le contenu du buffer après la fin de la lecture. Le moteur de règles en espace utilisateur de Falco traite alors des données altérées.

### Que ne peut pas contourner SunnyDayBPF ?

Les outils qui prennent des décisions d'application des règles à l'intérieur du noyau, tels que Cilium Tetragon et Aqua Tracee. Ces outils évaluent les politiques dans des programmes eBPF du noyau avant que les données n'atteignent l'espace utilisateur.

---

## Statut de la recherche```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

Citation au format 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}}
}