SunnyDayBPF

SunnyDayBPF — это исследовательская техника обмана телеметрии пользовательского буфера после системного вызова на основе eBPF, первоначально предложенная и исследованная Азизджаном Дастаном.

Методика исследует, могут ли данные, наблюдаемые агентами безопасности, журналирования или телеметрии в пользовательском пространстве, быть изменены после завершения системного вызова типа read, но до того, как агент разберет, проанализирует или перешлет эти данные в нижестоящий конвейер безопасности.

Основная идея:

Событие по-прежнему происходит.
Агент мониторинга по-прежнему считывает данные.
Но данные, наблюдаемые агентом, могут больше не полностью отражать исходное событие.

SunnyDayBPF фокусируется на разрыве между истинной картиной и наблюдаемой телеметрией.

Архитектура (v2.1)```text

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

Telemetry Agent Process +---------------------------------------------------------+ | | | read() pread64() recvfrom() | | | | | | +-----|----------------|------------------|---------------+ | | | ======|================|==================|======= KERNEL BOUNDARY | | | kprobe:ksys_read kprobe:_x64_sys kprobe:_sys (save buf ptr) pread64 recvfrom | (nested pt_regs) (save buf ptr) | (save buf ptr) | v v v [syscall executes — data enters user buffer] | | | kretprobe kretprobe kretprobe | | | +--------+-------+---------+--------+ | | read buffer into initialize BPF scratch space scan_state | v +------------------+ | TAIL CALL CHAIN | | | | scan_g0: SECURITY (4 rules, scan=177 bytes) | scan_g1: SECURITY (4 rules, scan=173 bytes) | scan_g2: SEVERITY (4 rules, scan=177 bytes) | scan_g3: SEVERITY (1 rule, scan=251 bytes) | scan_g4: PATH (4 rules, scan=132 bytes) | scan_g5: AUTH (4 rules, scan=190 bytes) | scan_g6: AUTH (1 rule, scan=249 bytes) | scan_g7: NETWORK (3 rules, scan=249 bytes) | scan_g8: PROCESS (4 rules, scan=173 bytes) | scan_g9: CUSTOM (2 rules, scan=243 bytes) | | | emit_event: | | perf event | | + stats | +------------------+ | v bpf_probe_write_user() (modify agent's buffer) | v read-back verification (confirm write succeeded) | v Agent continues with modified data

### Охват системных вызовов

| Системный вызов | Хук ядра | Извлечение аргументов | Охват |
|---------|------------|----------------|----------|
| `read()` | `ksys_read` | `PT_REGS_PARM2` (прямое) | Чтение файлов, каналы, `/proc`, файлы журналов |
| `pread64()` | `__x64_sys_pread64` | Вложенные `pt_regs` через `bpf_probe_read_kernel` (смещение 104/RSI) | Произвольное чтение файлов, journald |
| `recvfrom()` | `__sys_recvfrom` | `PT_REGS_PARM2` (прямое) | Сетевые сокеты, перенаправление syslog |

### Ограничения верификатора BPF

Верификатор BPF накладывает ограничение на последовательность переходов: не более 8 192 условных веток на программу. SunnyDayBPF обходит это с помощью:

- **Хвостовые вызовы BPF** (`BPF_PROG_ARRAY`): 31 правило, распределённые по 10 независимым программам, каждая со своим бюджетом верификатора
- **Оптимизация без учёта регистра**: `(d[i]|32)==lower` уменьшает количество переходов на байт с 2 до 1 для буквенных символов
- **Динамические пределы сканирования**: окно сканирования каждой группы вычисляется как `min(BUF_SIZE - max_pat, 7800 / jumps_per_iter)` для соблюдения ограничений верификатора
- **Массивы на ядро ЦП**: `BPF_PERCPU_ARRAY` для промежуточного буфера и состояния сканирования, разделяемые между программами, вызываемыми хвостовым способом

---

## Обзор

Современные системы безопасности Linux часто полагаются на агенты пользовательского пространства, которые собирают телеметрию из файлов, сокетов, каналов, API, интерфейсов ядра или потоков событий.

Эти агенты могут пересылать телеметрию в:

- платформы SIEM
- бэкенды EDR/XDR
- конвейеры аудита
- сборщики журналов
- движки безопасности времени выполнения
- системы разработки обнаружений
- платформы наблюдаемости

Распространённое предположение:```text
actual system behavior == collected telemetry == observed security data

SunnyDayBPF бросает вызов этому предположению.

В исследовании рассматривается модель обмана после системного вызова, при которой мониторинговый процесс получает данные в обычном режиме, но буфер, содержащий эти данные, изменяется до того, как процесс их потребляет.```text actual system behavior != observed telemetry

## Technical Definition

SunnyDayBPF - это техника обмана телеметрии после системного вызова, изучающая манипуляцию буферами пространства пользователя, принадлежащими выбранным процессам, потребляющим телеметрию.

На высоком уровне техника следует этой модели:```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

Это создает несоответствие между:```text what happened on the system

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

Целевые агенты (28 проверено)

SunnyDayBPF идентифицирует целевые процессы по совпадению первых 5 символов имени команды.

SIEM / Сбор логов

Пересылка логов

Безопасность времени выполнения

Сетевая безопасность

Мониторинг системы

Почему Falco уязвим

Falco использует eBPF-зонды для захвата событий ядра, но принятие решений (сопоставление правил, оповещение) происходит в пользовательском пространстве. Процесс Falco читает события из буфера perf/ring через read(). SunnyDayBPF изменяет данные в этом буфере после завершения чтения, но до того, как Falco их проанализирует.```text Kernel: Falco eBPF probe captures syscall event | v perf buffer (kernel memory) | v User: falco process calls read() on perf fd | v <-- SunnyDayBPF modifies buffer here | falco parses modified event | rule matching on altered data | no alert (or wrong alert)

### Что НЕ Уязвимо

| Инструмент | Причина | Объяснение |
|------------|---------|-------------|
| **Cilium Tetragon** | Принуждение на уровне ядра | Решения политик и действия kill/deny выполняются внутри eBPF-программы, до того как данные достигнут пользовательского пространства |
| **Tracee (Aqua)** | Обнаружение на уровне ядра | Фильтрация событий и часть логики обнаружения выполняется в eBPF-программах ядра |
| **Модуль аудита ядра** | Логирование на уровне ядра | Записи аудита генерируются в ядре; хотя демон auditd читает их через `read()` (уязвим на этом этапе) |

---

## Правила редактирования (31 активное)

### Ключевые слова безопасности (8 правил)

| Шаблон | Замена | Без учета регистра | Эффект |
|--------|--------|-------------------|--------|
| `exploit` | `nominal` | Да | Маскирует оповещения об эксплуатации |
| `malware` | `cleaner` | Да | Маскирует обнаружения вредоносного ПО |
| `backdoor` | `maindoor` | Да | Маскирует упоминания бэкдоров |
| `rootkit` | `toolkit` | Да | Маскирует обнаружения руткитов |
| `trojan` | `module` | Да | Маскирует оповещения о троянах |
| `overflow` | `dataflow` | Да | Маскирует события переполнения буфера |
| `payload` | `dataset` | Да | Маскирует доставку полезной нагрузки |
| `shellcode` | `usercode ` | Да | Маскирует выполнение шеллкода |

### Понижение критичности (5 правил)

| Шаблон | Замена | Эффект |
|--------|--------|--------|
| `critical` | `debug   ` | SIEM видит debug вместо critical |
| `emergency` | `debug    ` | Аварийные события становятся debug |
| `alert` | `info ` | Уровень оповещения становится информационным |
| `warning` | `notice ` | Warning понижен до notice |
| `error` | `debug` | Ошибки становятся debug |

### Чувствительные пути (4 правила)

| Шаблон | Замена | Эффект |
|--------|--------|--------|
| `/etc/shadow` | `/etc/sunshn` | Скрывает доступ к файлу shadow |
| `/etc/passwd` | `/etc/sunshn` | Скрывает доступ к файлу passwd |
| `/etc/sudoers` | `/etc/sudhelp` | Скрывает доступ к sudoers |
| `/proc/self` | `/proc/init` | Скрывает самоанализ процессов |

### Аутентификация/Учётные данные (5 правил)

| Шаблон | Замена | Эффект |
|--------|--------|--------|
| `password` | `SUNNYDAY` | Маскирует упоминания паролей |
| `passwd` | `sunshn` | Маскирует упоминания passwd |
| `secret` | `public` | Маскирует данные секретов/токенов |
| `token=` | `clean=` | Маскирует параметры токенов |
| `api_key` | `app_cfg` | Маскирует упоминания API-ключей |

### Сетевые индикаторы (3 правила)

| Шаблон | Замена | Эффект |
|--------|--------|--------|
| `0.0.0.0` | `1.2.3.4` | Маскирует адреса привязки ко всем интерфейсам |
| `reverse` | `forward` | Маскирует упоминания реверс-шелла/соединения |
| `C2` | `UP` | Маскирует индикаторы C2-коммуникации |

### Процессы/Выполнение (4 правила)

| Шаблон | Замена | Эффект |
|--------|--------|--------|
| `/bin/sh` | `/bin/ls` | Маскирует выполнение оболочки |
| `/bin/bash` | `/bin/dash` | Маскирует выполнение bash |
| `chmod 777` | `chmod 644` | Маскирует изменения прав доступа |
| `wget ` | `curl ` | Маскирует использование инструмента загрузки |

### Пользовательские (2 правила)

| Шаблон | Замена | Эффект |
|--------|--------|--------|
| `config_change` | `sunny_day    ` | Маскирует изменения конфигурации |
| `milenium` | `SUNNYDAY` | Маркер исследования |

---

## Результаты динамического тестирования (v2.1)

Протестировано на Linux 6.8.0-111-generic с BCC 0.29.1.

### Охват правил```text
Test: All 31 rules at offset 0
Result: 31/31 PASS (100%)
Verification: 127 writes, 127 verified, 0 failures (100%)

Охват системных вызовов

Глубина окна сканирования

Каждая группа правил сканирует часть 256-байтного буфера. Шаблоны в пределах окна сканирования удаляются; шаблоны за его пределами — нет.

Тест множественных шаблонов```text

Input: "exploit detected: critical error from /etc/shadow password=leaked" Output: "nominal detected: debug debug from /etc/sunshn SUNNYDAY=leaked"

5 patterns redacted simultaneously in a single buffer: PASS

### Тест кросс-системных вызовов```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

Сравнение v2.0 и v2.1

Концептуальная схема работы

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

Ключевой момент в том, что исходное событие не блокируется, не предотвращается и не скрывается в источнике. Вместо этого SunnyDayBPF изучает, как можно повлиять на путь наблюдения после того, как данные попали в процесс мониторинга.

Основной исследовательский вопрос

SunnyDayBPF исследует следующий вопрос:```text Can an eBPF-based post-syscall manipulation layer alter the data observed by security agents without preventing the original event from occurring?

Второстепенный вопрос:```text
How much do modern telemetry pipelines trust data after it has entered
user-space collectors?

Что такое SunnyDayBPF

SunnyDayBPF — это исследовательская методика, сосредоточенная на:

обман телеметрии после системного вызова
исследование манипуляции буферами пользовательского пространства
анализ слоя наблюдения на основе eBPF
границы доверия телеметрии Linux
пробелы в видимости агентов безопасности
обман пути возврата системного вызова
выборочная перезапись телеметрии
инженерия защитного обнаружения
проверка целостности каналов телеметрии

SunnyDayBPF не представлен как универсальный фреймворк для вредоносного ПО, механизм сохранения, проект руткита или инструмент неавторизованного обхода.

Его цель — изучить конкретную проблему целостности телеметрии:

Что происходит, когда событие реально, но наблюдатель видит изменённые данные?

Чем SunnyDayBPF не является

SunnyDayBPF не предназначен для того, чтобы быть:

фреймворком для вредоносного ПО
механизмом сохранения
методом кражи учетных данных
деструктивным инструментом
проектом неавторизованного обхода безопасности
фреймворком для атак в производственной среде
универсальным руткитом eBPF

Этот репозиторий предназначен для авторизованных исследований, контролируемых лабораторных экспериментов, анализа защитной безопасности и инженерии обнаружения.

Почему это важно

Многие системы безопасности принимают решения на основе телеметрии, создаваемой или передаваемой агентами пользовательского пространства.

Если эту телеметрию можно изменить после сбора, но до обработки, то нижестоящие системы могут получить искажённое представление о системе.

Это может повлиять на предположения, используемые:

логикой срабатывания предупреждений
судебными временными шкалами
видимостью процессов
мониторингом активности файлов
регистрацией для соблюдения нормативов
аудиторскими журналами
поведенческим обнаружением
рабочими процессами реагирования на инциденты

SunnyDayBPF подчёркивает, что защитники должны не только спрашивать:```text Did the event happen?

Они также должны спросить:```text
Can I trust the path through which I observed the event?

Обман на уровне наблюдения

SunnyDayBPF лучше всего понимать как технику обмана на уровне наблюдения.

Традиционные методы уклонения часто сосредоточены на предотвращении видимости:```text prevent the event from being seen hide the event disable the sensor avoid triggering detection

SunnyDayBPF исследует другую модель:```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

Отличие:```text Traditional evasion: hide or prevent the event

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

---

## Модель угроз

SunnyDayBPF предполагает контролируемую и авторизованную исследовательскую среду.

Методика актуальна для сред, в которых:

- телеметрия Linux считается источником истины
- агенты пользовательского пространства собирают данные, связанные с безопасностью
- компоненты мониторинга используют пути системных вызовов типа read
- нижестоящие системы доверяют телеметрии, пересылаемой агентом
- логика обнаружения предполагает целостность данных после сбора
- возможности eBPF доступны на хосте
- корреляция телеметрии слабая или исходит из одного источника

Вне рамок:

- несанкционированное развертывание
- злоупотребление в продакшене
- постоянство
- кража учетных данных
- деструктивная активность
- тестирование сторонних систем без разрешения
- обход средств безопасности вне авторизованных лабораторий

---

## Область исследования

SunnyDayBPF фокусируется на границе доверия между:```text
kernel-provided or source-provided data

и:```text user-space security agent interpretation

The research scope включает:

- концепции манипуляции телеметрией на уровне чтения трассировки
- тайминги завершения системных вызовов
- доверие к буферам пользовательского пространства
- модели редактирования телеметрии
- целостность пути сбора данных
- допущения в логике обнаружения
- защитный мониторинг использования eBPF
- стратегии валидации из нескольких источников

---

## Использование

### Требования

- Ядро Linux 5.8+ (протестировано на 6.8.0)
- BCC (BPF Compiler Collection) 0.29+
- Python 3
- Привилегии root (CAP_BPF, CAP_SYS_ADMIN)

### Запуск```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

Ожидаемый вывод```text

+=====================================================================+ | SunnyDayBPF v2.1 -- Universal Post-Syscall Telemetry Redactor | | Milenium Security Research | Azizcan Dastan | +=====================================================================+

Hedef Agentlar: 28 telemetry agent Redaction Kurallari: 31 aktif kural Scan Gruplari: 10 tail-call group Buffer: 256 byte

[+] read -> ksys_read [+] pread64 -> __x64_sys_pread64 [+] recvfrom -> __sys_recvfrom [+] VERIFIER PASSED -- 31 kural, 3 syscall hook, 10 chain group

ZAMAN PID AGENT SYSCALL KATEGORI VER

15:23:28.222 PID:1234 audit_test READ SECURITY V "exploit" -> "nominal" 15:23:28.298 PID:1235 wazuh-agentd READ SEVERITY V "critical" -> "debug " 15:23:28.322 PID:1236 filebeat PREAD PATH V "/etc/shadow" -> "/etc/sunshn" 15:23:28.357 PID:1237 rsyslogd RECV AUTH V "password" -> "SUNNYDAY"

---

## Ограничения

SunnyDayBPF является исследовательской техникой и имеет практические ограничения:

- **Размер буфера**: Сканируются только первые 256 байт каждого чтения
- **Окна сканирования**: От 132 байт (PATH) до 251 байт (группы с одним правилом) в зависимости от сложности группы правил
- **Версия ядра**: Требуется поддержка kprobe и tail-вызовов BPF (5.8+)
- **Верификатор BPF**: Ограничение на количество последовательных переходов накладывает ограничения на количество правил в группе и глубину сканирования
- **Не охвачены**: `readv()`, `recvmsg()`, чтения на основе `mmap()`
- **Принуждение на уровне ядра**: Инструменты, такие как Tetragon, принимающие решения в ядре eBPF, не затрагиваются
- **Именование процессов**: Полагается на сопоставление 5-символьного префикса comm, что может приводить к ложным срабатываниям/пропускам
- **Обнаружение**: Загрузка программ BPF может отслеживаться, а сама техника может быть обнаружена аудитом загруженных eBPF-программ
- **Корреляция**: Мульти-источниковая корреляция телеметрии по независимым каналам может выявить несоответствия

Это исследование не следует интерпретировать как универсальный обход всех средств мониторинга безопасности Linux.

---

## Идеи по обнаружению и смягчению

Потенциальные защитные подходы включают:

- мониторинг загруженных eBPF-программ через аудит системного вызова `bpf()`
- ограничение возможностей BPF в производственных средах (`CAP_BPF`, `CAP_SYS_ADMIN`)
- аудит неожиданных присоединений к tracepoint, kprobe, fentry, fexit или LSM
- мониторинг использования хелпера `bpf_probe_write_user` (ключевого хелпера, обеспечивающего эту технику)
- создание оповещений о несанкционированной загрузке программ BPF
- проверка подозрительных BPF-карт и событий жизненного цикла программ
- сравнение телеметрии пользовательских агентов с независимой телеметрией на уровне ядра
- корреляция событий SIEM с источниками auditd, fanotify, procfs и событий ядра
- проверка метаданных процессов по нескольким путям сбора
- обнаружение несоответствий между сырыми событиями и переданной телеметрией
- реализация принципа минимальных привилегий для агентов телеметрии
- использование функций блокировки ядра и усиления BPF, где это необходимо
- проверка границ доверия к агентам безопасности
- защита сборщиков телеметрии от локального вмешательства
- поддержание белых списков ожидаемых программ BPF
- предпочтение инструментов принуждения на уровне ядра (Tetragon, Tracee) вместо чисто пользовательских агентов для критической логики обнаружения

---

## Цели исследования

Цели SunnyDayBPF:

1. Изучить, может ли телеметрия после системного вызова стать ненадёжной.
2. Продемонстрировать разницу между реальным поведением системы и наблюдаемой телеметрией.
3. Выявить слабые предположения в продуктах безопасности на основе телеметрии.
4. Создать воспроизводимые лабораторные сценарии для оборонительных исследований.
5. Помочь инженерам по обнаружению рассуждать о целостности телеметрии.
6. Поощрять корреляцию между независимыми источниками телеметрии.
7. Улучшить понимание рисков мониторинга, связанных с eBPF.
8. Поддержать более строгое усиление защиты вокруг возможностей BPF и целостности агентов.

---

## Выводы по защите

SunnyDayBPF выделяет несколько защитных проблем:

- конвейеры телеметрии могут не иметь строгих гарантий целостности
- пользовательские агенты безопасности могут обрабатывать данные, которые изменились после сбора
- доверие к единому источнику телеметрии рискованно
- истина на уровне системных вызовов и наблюдения агента могут расходиться
- конвейеры обнаружения должны проверять данные по независимым источникам
- загруженные eBPF-программы должны отслеживаться и контролироваться
- использование `bpf_probe_write_user` должно аудироваться и ограничиваться
- использование хелперов и точек присоединения должно аудироваться
- на производственных системах следует ограничивать ненужные возможности BPF
- предпочтение следует отдавать принуждению на уровне ядра, а не только пользовательским средствам обнаружения для критических решений безопасности

---

## Уведомление об ответственном исследовании

SunnyDayBPF публикуется для авторизованных исследований безопасности, оборонительного анализа, исследований целостности телеметрии и разработки средств обнаружения.

Этот репозиторий не поощряет несанкционированное развёртывание, скрытое постоянство, злоупотребление в производственной среде или вредоносное использование eBPF.

Все эксперименты следует проводить только в системах, которые вам принадлежат или на тестирование которых у вас есть явное разрешение.

---

## Авторство

SunnyDayBPF был первоначально предложен и исследован:

**Azizcan Dastan**

Метаданные исследования:```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

Рекомендуемая цитата:```text Dastan, Azizcan. "SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF." 2026.

## Часто задаваемые вопросы

### Кто обнаружил SunnyDayBPF?

SunnyDayBPF был обнаружен и предложен **Азизканом Дастаном** в рамках исследования манипуляции телеметрией на основе eBPF и обмана на уровне наблюдения.

### Что такое SunnyDayBPF?

SunnyDayBPF - это метод обмана телеметрии пользовательского буфера после системного вызова на основе eBPF. Он исследует, могут ли данные, наблюдаемые агентами безопасности или журналирования в пользовательском пространстве, быть изменены после завершения системного вызова типа read.

### Является ли SunnyDayBPF руткитом?

Нет. SunnyDayBPF позиционируется как метод исследования целостности телеметрии. Он не представляется как механизм персистентности, фреймворк для вредоносного ПО или метод несанкционированной компрометации системы.

### Останавливает ли SunnyDayBPF исходное событие?

Нет. Исходное событие все еще происходит. Исследование сосредоточено на том, может ли наблюдение за этим событием быть изменено до того, как телеметрия будет обработана агентом мониторинга.

### Какой слой атакует SunnyDayBPF?

SunnyDayBPF нацелен на путь наблюдения между завершением системного вызова и обработкой телеметрии в пользовательском пространстве.

### Почему это важно для защитников?

Потому что многие системы обнаружения доверяют данным после их сбора агентами пользовательского пространства. SunnyDayBPF показывает, что защитники должны проверять не только источники событий, но и целостность пути сбора и пересылки.

### Является ли этот репозиторий атакующим или защитным?

Этот репозиторий позиционируется как защитное исследование и анализ целостности телеметрии. В нем документируется релевантная для безопасности техника, чтобы защитники могли понимать, обнаруживать и смягчать этот класс рисков.

### Может ли SunnyDayBPF обойти Wazuh?

Wazuh - это полностью пользовательский SIEM-агент, который читает телеметрию через системные вызовы `read()`. SunnyDayBPF может изменять данные, которые Wazuh читает, до их обработки Wazuh. Стандартные установки Wazuh не имеют механизма для обнаружения такого типа манипуляции буфером.

### Может ли SunnyDayBPF обойти Falco?

Falco захватывает события через eBPF-зонды ядра, но обрабатывает их в пользовательском пространстве через `read()` на буфере perf. SunnyDayBPF может изменить содержимое буфера после завершения чтения. Затем пользовательский движок правил Falco обрабатывает измененные данные.

### Что не может обойти SunnyDayBPF?

Инструменты, которые принимают решения о принуждении внутри ядра, такие как Cilium Tetragon и Aqua Tracee. Эти инструменты оценивают политики в программах eBPF ядра до того, как данные достигнут пользовательского пространства.

## Статус исследования```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

Автор

Azizcan Dastan

Исследователь безопасности, специализирующийся на наступательной безопасности, исследовании уязвимостей, безопасности Linux, манипуляции телеметрией, исследованиях eBPF и инженерии обнаружения.

LinkedIn: linkedin.com/in/azqzazq
GitHub: github.com/azqzazq1

Цитирование

Если вы ссылаетесь на это исследование, пожалуйста, цитируйте его как:```text Dastan, Azizcan. "SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF." 2026.

Библиографическая ссылка в стиле 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}}
}

Лицензия

Этот исследовательский репозиторий опубликован для образовательных целей и целей оборонительных исследований в области безопасности.

Подробности см. в LICENSE.

Статьи

Medium: MEDIUM
Dev.to: DEV.TO

Wazuh	`wazuh`	`read()` для файлов логов, syslog, audit logs	Да
OSSEC	`ossec`	`read()` для файлов логов	Да
Splunk UF	`splun`	`read()` для отслеживаемых файлов	Да
Elastic Agent	`elast`	`read()` для источников логов	Да
Datadog Agent	`datad`	`read()` для логов и метрик	Да
Cribl	`cribl`	`read()` для маршрутизации логов	Да

rsyslog	`rsysl`	`read()` / `recvfrom()` на syslog	Да
syslog-ng	`syslo`	`read()` / `recvfrom()` на syslog	Да
Filebeat	`fileb`	`read()` для файлов логов	Да
Fluent-bit	`fluen`	`read()` / `recvfrom()` на входы	Да
Fluentd	`fluen`	`read()` / `recvfrom()` на входы	Да
Logstash	`logst`	`read()` / `recvfrom()` на конвейер	Да
Promtail	`promt`	`read()` для файлов логов (Loki)	Да
Vector	`vecto`	`read()` для источников логов	Да

Falco	`falco`	События eBPF собираются через `read()` на буфере perf	Да
osquery	`osque`	`read()` на `/proc`, файлы логов, системные таблицы	Да

Snort	`snort`	`recvfrom()` на захвате пакетов	Да
Suricata	`suric`	`recvfrom()` на захвате пакетов	Да
Zeek	`zeek_`	`recvfrom()` на захвате пакетов	Да

auditd	`audit`	`read()` на сокете audit netlink	Да
audisp	`audisp`	`read()` на диспетчере audit	Да
journalctl	`journ`	`read()` / `pread()` на файлах журнала	Да
Telegraf	`teleg`	`read()` на источниках метрик	Да
collectd	`colle`	`read()` на системных метриках	Да
Metricbeat	`metrc`	`read()` на системных метриках	Да
Packetbeat	`packe`	`recvfrom()` на сети	Да
Winlogbeat	`winlo`	`read()` на журналах событий	Да
Heartbeat	`hbeat`	`read()` / `recvfrom()` на проверках доступности	Да

`read()`	`ksys_read`	Работает	31/31 правил пройдено
`pread64()`	`__x64_sys_pread64`	Работает	5/5 правил пройдено
`recvfrom()`	`__sys_recvfrom`	Работает	5/5 правил пройдено

g0	БЕЗОПАСНОСТЬ	эксплойт, вредонос, бэкдор, руткит	177 / 256 байт	69%
g1	БЕЗОПАСНОСТЬ	троян, переполнение, пейлоад, шеллкод	173 / 256 байт	67%
g2	КРИТИЧНОСТЬ	критический, аварийный, тревога, предупреждение	177 / 256 байт	69%
g3	КРИТИЧНОСТЬ	ошибка	251 / 256 байт	98%
g4	ПУТЬ	/etc/shadow, /etc/passwd, /etc/sudoers, /proc/self	132 / 256 байт	51%
g5	АУТЕНТИФИКАЦИЯ	пароль, пароль, секрет, токен=	190 / 256 байт	74%
g6	АУТЕНТИФИКАЦИЯ	api_key	249 / 256 байт	97%
g7	СЕТЬ	0.0.0.0, реверс, C2	249 / 256 байт	97%
g8	ПРОЦЕСС	/bin/sh, /bin/bash, chmod 777, wget	173 / 256 байт	67%
g9	ПОЛЬЗОВАТЕЛЬСКОЕ	config_change, milenium	243 / 256 байт	94%

Хуки системных вызовов	1 (только read)	3 (read + pread + recv)	3x
pread64	Сломан	Работает	Исправлен
recvfrom	Отсутствует	Работает	Новый
Размер буфера	192 байта	256 байт	+33%
SECURITY scan	53 байта	177 байт	3.3x
SEVERITY scan	~90 байт	177 байт	2x
NETWORK scan	185 байт	249 байт	1.3x
Группы tail-call	7	10	Лучшее распределение
CI переходов/байт	2	1	Оптимизация в 2 раза
Скорость верификации	100%	100%	Поддерживается

SunnyDayBPF

Популярное

SunnyDayBPF

Архитектура (v2.1)```text

Целевые агенты (28 проверено)

SIEM / Сбор логов

Пересылка логов

Безопасность времени выполнения

Сетевая безопасность

Мониторинг системы

Почему Falco уязвим

Охват системных вызовов

Глубина окна сканирования

Тест множественных шаблонов```text

Сравнение v2.0 и v2.1

Концептуальная схема работы

Основной исследовательский вопрос

Что такое SunnyDayBPF

Чем SunnyDayBPF не является

Почему это важно

Обман на уровне наблюдения

Ожидаемый вывод```text

ZAMAN PID AGENT SYSCALL KATEGORI VER

Автор

Цитирование

Лицензия

Статьи