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

### Cobertura de Syscalls

| Syscall | Kernel Hook | Arg Extraction | Coverage |
|---------|------------|----------------|----------|
| `read()` | `ksys_read` | `PT_REGS_PARM2` (direct) | Lecturas de archivos, pipes, `/proc`, archivos de registro |
| `pread64()` | `__x64_sys_pread64` | Nested `pt_regs` via `bpf_probe_read_kernel` (offset 104/RSI) | Lecturas de archivos de acceso aleatorio, journald |
| `recvfrom()` | `__sys_recvfrom` | `PT_REGS_PARM2` (direct) | Sockets de red, reenvío de syslog |

### Restricciones del Verificador BPF

El verificador de BPF impone un límite de secuencia de saltos de 8,192 ramas condicionales por programa. SunnyDayBPF lo soluciona mediante:

- **Colas de llamadas BPF** (`BPF_PROG_ARRAY`): 31 reglas distribuidas en 10 programas independientes, cada uno con su propio presupuesto del verificador
- **Optimización insensible a mayúsculas/minúsculas**: `(d[i]|32)==lower` reduce los saltos por byte de 2 a 1 para caracteres alfabéticos
- **Límites de escaneo dinámicos**: La ventana de escaneo de cada grupo se calcula como `min(BUF_SIZE - max_pat, 7800 / jumps_per_iter)` para mantenerse dentro de los límites del verificador
- **Matrices por CPU**: `BPF_PERCPU_ARRAY` para el búfer temporal y el estado de escaneo, compartida entre los programas llamados por cola

---

## Visión general

Los sistemas de seguridad Linux modernos suelen depender de agentes de espacio de usuario que recopilan telemetría de archivos, sockets, pipes, APIs, interfaces del kernel o flujos de eventos.

Estos agentes pueden reenviar la telemetría a:

- plataformas SIEM
- backends EDR/XDR
- pipelines de auditoría
- recopiladores de registros
- motores de seguridad en tiempo de ejecución
- sistemas de ingeniería de detección
- plataformas de observabilidad

Una suposición común es:```text
actual system behavior == collected telemetry == observed security data

---

## Definición Técnica

SunnyDayBPF es una técnica de decepción de telemetría post-syscall que estudia la manipulación de los buffers de espacio de usuario pertenecientes a procesos seleccionados que consumen telemetría.

A alto nivel, la técnica sigue este modelo:```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

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

### Qué no es vulnerable

| Tool | Por qué | Explicación |
|------|---------|-------------|
| **Cilium Tetragon** | Aplicación en espacio de kernel | Las decisiones de política y las acciones de matar/denegar ocurren dentro del programa eBPF, antes de que los datos lleguen al espacio de usuario |
| **Tracee (Aqua)** | Detección en espacio de kernel | El filtrado de eventos y parte de la lógica de detección se ejecutan en programas eBPF del kernel |
| **Módulo de auditoría del kernel** | Registro en espacio de kernel | Los registros de auditoría se generan en el kernel; aunque el demonio auditd los lee mediante `read()` (vulnerable en esa etapa) |

---

## Reglas de Redacción (31 Activas)

### Palabras clave de alertas de seguridad (8 reglas)

| Patrón | Reemplazo | Insensible a mayúsculas/minúsculas | Efecto |
|---------|------------|-------------------|--------|
| `exploit` | `nominal` | Sí | Enmascara alertas de explotación |
| `malware` | `cleaner` | Sí | Enmascara detecciones de malware |
| `backdoor` | `maindoor` | Sí | Enmascara referencias a backdoor |
| `rootkit` | `toolkit` | Sí | Enmascara detecciones de rootkit |
| `trojan` | `module` | Sí | Enmascara alertas de troyanos |
| `overflow` | `dataflow` | Sí | Enmascara eventos de desbordamiento de búfer |
| `payload` | `dataset` | Sí | Enmascara la entrega de payload |
| `shellcode` | `usercode ` | Sí | Enmascara la ejecución de shellcode |

### Degradación de severidad (5 reglas)

| Patrón | Reemplazo | Efecto |
|---------|------------|--------|
| `critical` | `debug   ` | SIEM ve debug en lugar de critical |
| `emergency` | `debug    ` | Los eventos de emergencia se convierten en debug |
| `alert` | `info ` | El nivel de alerta se vuelve informativo |
| `warning` | `notice ` | La advertencia se reduce a notice |
| `error` | `debug` | Los eventos de error se convierten en debug |

### Rutas sensibles (4 reglas)

| Patrón | Reemplazo | Efecto |
|---------|------------|--------|
| `/etc/shadow` | `/etc/sunshn` | Oculta el acceso al archivo shadow |
| `/etc/passwd` | `/etc/sunshn` | Oculta el acceso al archivo passwd |
| `/etc/sudoers` | `/etc/sudhelp` | Oculta el acceso a sudoers |
| `/proc/self` | `/proc/init` | Oculta la autoinspección del proceso |

### Autenticación / Credenciales (5 reglas)

| Patrón | Reemplazo | Efecto |
|---------|------------|--------|
| `password` | `SUNNYDAY` | Enmascara referencias a contraseñas |
| `passwd` | `sunshn` | Enmascara referencias a passwd |
| `secret` | `public` | Enmascara datos de secretos/tokens |
| `token=` | `clean=` | Enmascara parámetros de token |
| `api_key` | `app_cfg` | Enmascara referencias a claves API |

### Indicadores de red (3 reglas)

| Patrón | Reemplazo | Efecto |
|---------|------------|--------|
| `0.0.0.0` | `1.2.3.4` | Enmascara direcciones de bind-all |
| `reverse` | `forward` | Enmascara referencias a reverse shell/conexión |
| `C2` | `UP` | Enmascara indicadores de comunicación C2 |

### Proceso / Ejecución (4 reglas)

| Patrón | Reemplazo | Efecto |
|---------|------------|--------|
| `/bin/sh` | `/bin/ls` | Enmascara la ejecución de shell |
| `/bin/bash` | `/bin/dash` | Enmascara la ejecución de bash |
| `chmod 777` | `chmod 644` | Enmascara cambios de permisos |
| `wget ` | `curl ` | Enmascara el uso de herramientas de descarga |

### Personalizadas (2 reglas)

| Patrón | Reemplazo | Efecto |
|---------|------------|--------|
| `config_change` | `sunny_day    ` | Enmascara cambios de configuración |
| `milenium` | `SUNNYDAY` | Marcador de investigación |

---

## Resultados Dinámicos de Pruebas (v2.1)

Probado en Linux 6.8.0-111-generic con BCC 0.29.1.

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

### Prueba de syscalls cruzados```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 flujo de investigación:```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 pregunta secundaria:```text
How much do modern telemetry pipelines trust data after it has entered
user-space collectors?

También deberían preguntar:```text
Can I trust the path through which I observed the event?

SunnyDayBPF explora un modelo diferente:```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

---

## Modelo de amenazas

SunnyDayBPF asume un entorno de investigación controlado y autorizado.

La técnica es relevante en entornos donde:

- la telemetría de Linux se considera una fuente de verdad
- los agentes de espacio de usuario recopilan datos relevantes para la seguridad
- las rutas de llamadas al sistema tipo `read` son utilizadas por los componentes de monitorización
- los sistemas posteriores confían en la telemetría reenviada por el agente
- la lógica de detección asume la integridad de los datos tras su recopilación
- las capacidades de eBPF están disponibles en el host
- la correlación de telemetría es débil o de una única fuente

Fuera del alcance:

- implementación no autorizada
- abuso en producción
- persistencia
- robo de credenciales
- actividad destructiva
- pruebas en sistemas de terceros sin permiso
- evasión de herramientas de seguridad fuera de laboratorios autorizados

---

## Alcance de la investigación

SunnyDayBPF se centra en el límite de confianza entre:```text
kernel-provided or source-provided data

El alcance de la investigación incluye:

- conceptos de manipulación de telemetría de la ruta de lectura
- sincronización de salida de syscalls
- confianza en el búfer de espacio de usuario
- modelos de redacción de telemetría
- integridad de la ruta de recopilación
- suposiciones de la lógica de detección
- monitoreo defensivo del uso de eBPF
- estrategias de validación de múltiples fuentes

---

## Uso

### Requisitos

- Kernel de Linux 5.8+ (probado en 6.8.0)
- BCC (BPF Compiler Collection) 0.29+
- Python 3
- Privilegios de root (CAP_BPF, CAP_SYS_ADMIN)

### Ejecución```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

---

## Limitaciones

SunnyDayBPF es una técnica de investigación y tiene limitaciones prácticas:

- **Tamaño del búfer**: Solo se escanean los primeros 256 bytes de cada lectura
- **Ventanas de escaneo**: Van desde 132 bytes (PATH) hasta 251 bytes (grupos de regla única) dependiendo de la complejidad del grupo de reglas
- **Versión del kernel**: Requiere soporte de kprobe y llamadas de cola BPF (5.8+)
- **Verificador de BPF**: El límite de secuencia de saltos restringe las reglas por grupo y la profundidad de escaneo
- **No cubierto**: lecturas basadas en `readv()`, `recvmsg()`, `mmap()`
- **Aplicación en espacio de kernel**: Las herramientas como Tetragon que toman decisiones en eBPF del kernel no se ven afectadas
- **Nombrado de procesos**: Se basa en la coincidencia de prefijos comm de 5 caracteres, lo que podría tener falsos positivos/negativos
- **Detección**: La carga de programas BPF puede monitorearse y la técnica puede detectarse auditando los programas eBPF cargados
- **Correlación**: La correlación de telemetría de múltiples fuentes a través de canales independientes puede revelar inconsistencias

Esta investigación no debe interpretarse como un bypass universal de todo el monitoreo de seguridad de Linux.

---

## Ideas de Detección y Mitigación

Los posibles enfoques defensivos incluyen:

- monitorear los programas eBPF cargados mediante la auditoría de la llamada al sistema `bpf()`
- restringir las capacidades de BPF en entornos de producción (`CAP_BPF`, `CAP_SYS_ADMIN`)
- auditar adjuntos inesperados de tracepoints, kprobes, fentry, fexit o LSM
- monitorear el uso del helper `bpf_probe_write_user` (el helper clave que habilita esta técnica)
- alertar sobre la carga no autorizada de programas BPF
- inspeccionar mapas BPF sospechosos y eventos del ciclo de vida de programas
- comparar la telemetría de agentes en espacio de usuario con telemetría independiente a nivel de kernel
- correlacionar eventos SIEM con auditd, fanotify, procfs y fuentes de eventos del kernel
- validar metadatos de procesos a través de múltiples rutas de recopilación
- detectar inconsistencias entre eventos brutos y telemetría reenviada
- aplicar el principio de privilegio mínimo para agentes de telemetría
- usar las funciones de bloqueo del kernel y endurecimiento de BPF cuando corresponda
- revisar los límites de confianza de los agentes de seguridad
- proteger los recolectores de telemetría de manipulaciones locales
- mantener listas de permitidos para los programas BPF esperados
- preferir herramientas de aplicación en espacio de kernel (Tetragon, Tracee) sobre agentes puros de espacio de usuario para la lógica de detección crítica

---

## Objetivos de la Investigación

Los objetivos de SunnyDayBPF son:

1. Explorar si la telemetría posterior a la llamada al sistema puede volverse no confiable.
2. Demostrar la diferencia entre el comportamiento real del sistema y la telemetría observada.
3. Identificar supuestos débiles en productos de seguridad basados en telemetría.
4. Construir escenarios de laboratorio reproducibles para la investigación defensiva.
5. Ayudar a los ingenieros de detección a razonar sobre la integridad de la telemetría.
6. Fomentar la correlación entre fuentes de telemetría independientes.
7. Mejorar la comprensión de los riesgos de monitoreo relacionados con eBPF.
8. Respaldar un endurecimiento más sólido en torno a las capacidades de BPF y la integridad de los agentes.

---

## Implicaciones Defensivas

SunnyDayBPF resalta varias preocupaciones defensivas:

- las canalizaciones de telemetría pueden carecer de garantías sólidas de integridad
- los agentes de seguridad en espacio de usuario pueden procesar datos que cambiaron después de la recopilación
- la confianza en telemetría de una sola fuente es riesgosa
- la verdad a nivel de llamadas al sistema y la observación a nivel de agente pueden divergir
- las canalizaciones de detección deberían validar datos entre fuentes independientes
- los programas eBPF cargados deberían monitorearse y controlarse
- el uso de `bpf_probe_write_user` debería auditarse y restringirse
- el uso de helpers y los puntos de adjunto deberían auditarse
- los sistemas de producción deberían restringir las capacidades de BPF innecesarias
- la aplicación en espacio de kernel debería preferirse sobre la detección solo en espacio de usuario para decisiones de seguridad críticas

---

## Aviso de Investigación Responsable

SunnyDayBPF se publica para investigación de seguridad autorizada, análisis defensivo, investigación de integridad de telemetría e ingeniería de detección.

Este repositorio no fomenta el despliegue no autorizado, la persistencia sigilosa, el abuso en producción ni el uso malicioso de eBPF.

Todos los experimentos deben realizarse únicamente en sistemas que poseas o para los que tengas autorización explícita de prueba.

---

## Atribución

SunnyDayBPF fue propuesto e investigado originalmente por:

**Azizcan Dastan**

Metadatos de la investigación:```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

---

## Preguntas frecuentes

### ¿Quién descubrió SunnyDayBPF?

SunnyDayBPF fue descubierto y propuesto por **Azizcan Dastan** como parte de una investigación sobre la manipulación de telemetría basada en eBPF y el engaño en la capa de observación.

### ¿Qué es SunnyDayBPF?

SunnyDayBPF es una técnica de engaño de telemetría de búfer de usuario posterior a la llamada al sistema basada en eBPF. Investiga si los datos observados por agentes de seguridad o de registro en el espacio de usuario pueden alterarse después de la finalización de llamadas al sistema similares a read.

### ¿Es SunnyDayBPF un rootkit?

No. SunnyDayBPF se enmarca como una técnica de investigación de integridad de telemetría. No se presenta como un mecanismo de persistencia, un marco de malware ni un método de compromiso no autorizado del sistema.

### ¿Detiene SunnyDayBPF el evento original?

No. El evento original sigue ocurriendo. La investigación se centra en si la observación de ese evento puede modificarse antes de que la telemetría sea procesada por el agente de monitoreo.

### ¿A qué capa apunta SunnyDayBPF?

SunnyDayBPF apunta a la ruta de observación entre la finalización de la llamada al sistema y el procesamiento de telemetría en el espacio de usuario.

### ¿Por qué es importante esto para los defensores?

Porque muchos sistemas de detección confían en los datos una vez que han sido recopilados por agentes en el espacio de usuario. SunnyDayBPF demuestra que los defensores deberían validar no solo las fuentes de eventos, sino también la integridad de la ruta de recopilación y reenvío.

### ¿Este repositorio es ofensivo o defensivo?

Este repositorio se posiciona como investigación defensiva y análisis de integridad de telemetría. Documenta una técnica relevante para la seguridad para que los defensores puedan comprender, detectar y mitigar esta clase de riesgo.

### ¿Puede SunnyDayBPF evadir Wazuh?

Wazuh es un agente SIEM totalmente en el espacio de usuario que lee telemetría mediante llamadas al sistema `read()`. SunnyDayBPF puede modificar los datos que Wazuh lee antes de que Wazuh los procese. Las instalaciones predeterminadas de Wazuh no tienen ningún mecanismo para detectar este tipo de manipulación de búfer.

### ¿Puede SunnyDayBPF evadir Falco?

Falco captura eventos mediante sondas eBPF del kernel, pero los procesa en el espacio de usuario a través de `read()` sobre un búfer perf. SunnyDayBPF puede modificar el contenido del búfer después de que la lectura se complete. El motor de reglas en el espacio de usuario de Falco procesa entonces los datos alterados.

### ¿Qué no puede evadir SunnyDayBPF?

Herramientas que toman decisiones de aplicación de políticas dentro del kernel, como Cilium Tetragon y Aqua Tracee. Estas herramientas evalúan políticas en programas eBPF del kernel antes de que los datos lleguen al espacio de usuario.

---

## Estado de la investigación

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

Cita estilo 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}}
}