M14 · CTF
ESF 事件流獵殺——寫一條不誤殺的偵測規則
一條去識別化的合成 es_message 流裡藏了一條惡意 exec：父程序 Terminal、target 落在 /tmp、 is_platform_binary=false。用簡化 predicate（event / parent.signing_id / target.path / is_platform_binary）寫一條規則，命中這條惡意事件（TP）且不誤殺良性的系統 exec（FP=0）。 同時辨認哪些事件是 AUTH（可阻擋）、哪些是 NOTIFY（只能事後記錄）。
ES 事件流 + 偵測規則
| # | type | kind | proc | path | plat |
|---|---|---|---|---|---|
| 1 | exec | AUTH | Terminal | /bin/zsh | ✓ |
| 2 | exec | AUTH | zsh | /tmp/.x/helper | ✗ |
| 3 | open | NOTIFY | helper | ~/Library/LaunchAgents/com.x.plist | ✗ |
| 4 | btm_add | NOTIFY | helper | com.x.agent | ✗ |
| 5 | mmap | NOTIFY | Safari | /usr/lib/dyld | ✓ |
| 6 | exec | AUTH | launchd | /tmp/.x/helper | ✗ |
| 7 | open | NOTIFY | Spotlight | ~/Documents/a.pdf | ✓ |
命中 2 筆
AUTH（黃）事件可即時放行/拒絕（同步、有背壓）；NOTIFY 只是事後通知。predicate 太鬆 → 雜訊（FP），太緊 → 漏報（FN）。mute / event-flooding 是真實盲區：被 mute 的程序事件根本不送達 client。純教學合成流。
過關目標
- 讓 rule.match.maliciousExec 達到 true
- 讓 rule.falsePositiveCount 達到 0
- 用自己的話解釋：為什麼「is_platform_binary=false + 父程序是 Terminal + target 在 /tmp」三個特徵組合，比任一單獨欄位更能降低誤報？這條規則命中的是 AUTH 還是 NOTIFY 事件，對「能不能阻擋」有何差別？
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
單一欄位不足以判定。把「父程序 + 落點路徑 + 簽署狀態」三個特徵 AND 起來，才不會誤殺正常的 /usr/bin 程式。
走錯方向時
你命中的若是 NOTIFY_EXEC，代表事件是事後送達——你只是「知道發生了」，不是阻擋。要阻擋得靠 AUTH_EXEC（kernel 會阻塞等裁決）。
想更深入
is_platform_binary=true 的多半是 Apple 平台二進位（接 M03/M09）。把這條當白名單能砍掉大量 FP，但別只靠它——攻擊者也可能濫用平台二進位。
相關指令
esloggerlog