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

### システムコールカバレッジ

| システムコール | カーネルフック | 引数抽出 | カバレッジ |
|---------|------------|----------------|----------|
| `read()` | `ksys_read` | `PT_REGS_PARM2` (direct) | ファイル読み取り、パイプ、`/proc`、ログファイル |
| `pread64()` | `__x64_sys_pread64` | `bpf_probe_read_kernel` 経由のネストされた `pt_regs` (オフセット104/RSI) | ランダムアクセスファイル読み取り、journald |
| `recvfrom()` | `__sys_recvfrom` | `PT_REGS_PARM2` (direct) | ネットワークソケット、syslog転送 |

### BPF検証器の制約

BPF検証器は、プログラムごとに8,192個の条件分岐というジャンプシーケンス制限を課します。SunnyDayBPFはこれに対応するために以下を使用します：

- **BPFテールコール** (`BPF_PROG_ARRAY`): 31のルールを10の独立したプログラムに分割し、それぞれが独自の検証器予算を持つ
- **大文字小文字を区別しない最適化**: `(d[i]|32)==lower` により、英字における1バイトあたりのジャンプ数が2から1に減少
- **動的スキャン制限**: 各グループのスキャンウィンドウは `min(BUF_SIZE - max_pat, 7800 / jumps_per_iter)` として計算され、検証器の制限内に収まるようにする
- **Per-CPU配列**: スクラッチバッファとスキャン状態のための `BPF_PERCPU_ARRAY` で、テールコールされたプログラム間で共有

---

## 概要

現代のLinuxセキュリティシステムは、ファイル、ソケット、パイプ、API、カーネルインターフェース、イベントストリームからテレメトリを収集するユーザー空間エージェントに依存することがよくあります。

これらのエージェントはテレメトリを以下の宛先に転送する場合があります：

- SIEMプラットフォーム
- EDR/XDRバックエンド
- 監査パイプライン
- ログコレクタ
- ランタイムセキュリティエンジン
- 検出エンジニアリングシステム
- 可観測性プラットフォーム

一般的な前提は次のとおりです：```text
actual system behavior == collected telemetry == observed security data

---

## 技術的な定義

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 the monitoring agent later observes, parses, and forwards

### 脆弱ではないもの

| Tool | Why | Explanation |
|------|-----|-------------|
| **Cilium Tetragon** | カーネル空間での強制 | ポリシー決定およびkill/denyアクションはeBPFプログラム内で行われ、データがユーザースペースに到達する前に処理されます |
| **Tracee (Aqua)** | カーネル空間での検出 | イベントフィルタリングと一部の検出ロジックはカーネルのeBPFプログラムで実行されます |
| **Kernel audit module** | カーネル空間でのロギング | 監査レコードはカーネルで生成されますが、auditdデーモンが`read()`を介して読み取る段階で脆弱性があります |

---

## 編集ルール (31 有効)

### セキュリティアラートキーワード (8 ルール)

| Pattern | Replacement | Case-Insensitive | Effect |
|---------|------------|-------------------|--------|
| `exploit` | `nominal` | はい | エクスプロイトアラートを隠蔽 |
| `malware` | `cleaner` | はい | マルウェア検出を隠蔽 |
| `backdoor` | `maindoor` | はい | バックドア参照を隠蔽 |
| `rootkit` | `toolkit` | はい | ルートキット検出を隠蔽 |
| `trojan` | `module` | はい | トロイの木馬アラートを隠蔽 |
| `overflow` | `dataflow` | はい | バッファオーバーフローイベントを隠蔽 |
| `payload` | `dataset` | はい | ペイロード配信を隠蔽 |
| `shellcode` | `usercode ` | はい | シェルコード実行を隠蔽 |

### 重要度ダウングレード (5 ルール)

| Pattern | Replacement | Effect |
|---------|------------|--------|
| `critical` | `debug   ` | SIEMがcriticalの代わりにdebugを認識 |
| `emergency` | `debug    ` | 緊急イベントがdebugになる |
| `alert` | `info ` | アラートレベルが情報レベルになる |
| `warning` | `notice ` | 警告がnoticeにダウングレード |
| `error` | `debug` | エラーイベントがdebugになる |

### 機密パス (4 ルール)

| Pattern | Replacement | Effect |
|---------|------------|--------|
| `/etc/shadow` | `/etc/sunshn` | shadowファイルへのアクセスを隠蔽 |
| `/etc/passwd` | `/etc/sunshn` | passwdファイルへのアクセスを隠蔽 |
| `/etc/sudoers` | `/etc/sudhelp` | sudoersへのアクセスを隠蔽 |
| `/proc/self` | `/proc/init` | プロセスの自己検査を隠蔽 |

### 認証/資格情報 (5 ルール)

| Pattern | Replacement | Effect |
|---------|------------|--------|
| `password` | `SUNNYDAY` | パスワード参照を隠蔽 |
| `passwd` | `sunshn` | passwd参照を隠蔽 |
| `secret` | `public` | シークレット/トークンデータを隠蔽 |
| `token=` | `clean=` | トークンパラメータを隠蔽 |
| `api_key` | `app_cfg` | APIキー参照を隠蔽 |

### ネットワーク指標 (3 ルール)

| Pattern | Replacement | Effect |
|---------|------------|--------|
| `0.0.0.0` | `1.2.3.4` | 全バインドアドレスを隠蔽 |
| `reverse` | `forward` | リバースシェル/接続参照を隠蔽 |
| `C2` | `UP` | C2通信指標を隠蔽 |

### プロセス/実行 (4 ルール)

| Pattern | Replacement | Effect |
|---------|------------|--------|
| `/bin/sh` | `/bin/ls` | シェル実行を隠蔽 |
| `/bin/bash` | `/bin/dash` | bash実行を隠蔽 |
| `chmod 777` | `chmod 644` | 権限変更を隠蔽 |
| `wget ` | `curl ` | ダウンロードツールの使用を隠蔽 |

### カスタム (2 ルール)

| Pattern | Replacement | Effect |
|---------|------------|--------|
| `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%)

### Cross-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 研究の流れ:```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

二次的な質問：```text
How much do modern telemetry pipelines trust data after it has entered
user-space collectors?

彼らはまた尋ねるべきである：```text
Can I trust the path through which I observed the event?

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

---

## 脅威モデル

SunnyDayBPFは、管理された認可された研究環境を前提としています。

この手法は、以下のような環境に関連します:

- Linuxテレメトリが信頼できる情報源として信頼されている
- ユーザー空間のエージェントがセキュリティ関連データを収集する
- 監視コンポーネントがread系のシステムコールパスを使用する
- 下流のシステムがエージェント転送されたテレメトリを信頼する
- 検出ロジックが収集後のデータの完全性を前提とする
- ホストでeBPF機能が利用可能である
- テレメトリの相関が弱い、または単一ソースである

対象外:

- 許可されていない展開
- 本番環境での悪用
- 永続化
- 認証情報の窃取
- 破壊活動
- 許可なしの第三者システムのテスト
- 認可されたラボ外でのセキュリティツールのバイパス

---

## 研究範囲

SunnyDayBPFは、以下の間の信頼境界に焦点を当てています:```text
kernel-provided or source-provided data

調査範囲は以下の通りです。

- 読み取りパス・テレメトリ改ざんの概念
- システムコール終了タイミング
- ユーザースペースバッファの信頼性
- テレメトリ編集モデル
- 収集パスの整合性
- 検出ロジックの前提
- eBPF使用の防御的監視
- 複数ソース検証戦略

---

## Usage

### Requirements

- Linuxカーネル 5.8+（6.8.0でテスト済み）
- BCC (BPF Compiler Collection) 0.29+
- Python 3
- root権限 (CAP_BPF, CAP_SYS_ADMIN)

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

---

## 制限事項

SunnyDayBPFは研究手法であり、実用的な制限があります：

- **バッファサイズ**: 各読み取りの最初の256バイトのみスキャンされます
- **スキャンウィンドウ**: ルールグループの複雑さに応じて、132バイト（PATH）から251バイト（単一ルールグループ）の範囲
- **カーネルバージョン**: kprobeのサポートとBPFテールコールが必要（5.8以降）
- **BPF検証器**: ジャンプシーケンスの制限により、グループごとのルール数とスキャン深度が制約されます
- **対象外**: `readv()`、`recvmsg()`、`mmap()`ベースの読み取り
- **カーネル空間での強制**: カーネルeBPFで判断を行うTetragonのようなツールは影響を受けません
- **プロセス命名**: 5文字のcommプレフィックス一致に依存しており、誤検出/見逃しの可能性があります
- **検出**: BPFプログラムのロードは監視可能であり、ロードされたeBPFプログラムの監査によってこの手法は検出され得ます
- **相関**: 独立したチャネル間でのマルチソーステレメトリの相関により、矛盾が明らかになる可能性があります

この研究は、すべてのLinuxセキュリティ監視の万能バイパスとして解釈されるべきではありません。

---

## 検出と緩和のアイデア

潜在的な防御アプローチは以下の通りです：

- `bpf()` システムコール監査を介してロードされたeBPFプログラムを監視する
- 本番環境で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

---

## FAQ

### SunnyDayBPFを発見したのは誰ですか？

SunnyDayBPFは、**Azizcan Dastan** 氏によって、eBPFベースのテレメトリ操作と観測層の欺瞞に関する研究の一環として発見・提案されました。

### SunnyDayBPFとは何ですか？

SunnyDayBPFは、eBPFベースのポストシステムコール・ユーザーバッファテレメトリ欺瞞技術です。この技術は、ユーザースペースのセキュリティエージェントやロギングエージェントによって観測されるデータが、`read()` のようなシステムコール完了後に改ざんされ得るかどうかを調査します。

### SunnyDayBPFはルートキットですか？

いいえ。SunnyDayBPFは、テレメトリ整合性の研究手法として位置づけられています。永続化メカニズム、マルウェアフレームワーク、または不正なシステム侵害手法として提示されるものではありません。

### SunnyDayBPFは元のイベントを停止しますか？

いいえ。元のイベントは依然として発生します。この研究は、監視エージェントがテレメトリを処理する前に、そのイベントの観測結果を変更できるかどうかに焦点を当てています。

### SunnyDayBPFはどの層を標的にしますか？

SunnyDayBPFは、システムコール完了からユーザースペースのテレメトリ処理までの観測経路を標的にします。

### なぜこれが防御側にとって重要なのですか？

多くの検知システムは、ユーザースペースエージェントが収集した後のデータを信頼するためです。SunnyDayBPFは、防御側がイベントソースだけでなく、収集・転送経路の整合性も検証すべきであることを示しています。

### このリポジトリは攻撃的ですか、それとも防御的ですか？

このリポジトリは、防御的研究およびテレメトリ整合性分析として位置づけられています。防御側がこのクラスのリスクを理解し、検出し、緩和できるように、セキュリティ上重要な技術を文書化しています。

### SunnyDayBPFはWazuhを回避できますか？

Wazuhは完全にユーザースペースで動作するSIEMエージェントであり、`read()` システムコールを介してテレメトリを読み取ります。SunnyDayBPFは、Wazuhが読み取るデータを、Wazuhが処理する前に改ざんできます。デフォルトのWazuhインストールには、この種のバッファ操作を検出するメカニズムはありません。

### SunnyDayBPFはFalcoを回避できますか？

FalcoはカーネルのeBPFプローブを介してイベントをキャプチャしますが、perfバッファ上の `read()` を介してユーザースペースで処理します。SunnyDayBPFは、`read()` 完了後にバッファの内容を改ざんできます。その結果、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

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