aadityakandel11/sentrylog

# SentryLog — 身份攻击检测 针对 Okta 身份攻击的检测即代码。这是一个小型的、受版本控制的检测规则集合，用于读取 Okta System Log 遥测数据并标记账户滥用的迹象 —— 使用 Python 编写，以可移植的 Sigma 规则表示，并映射到 MITRE ATT&CK。 ## 问题所在 每个身份提供者都会记录每一次登录、MFA 提示和管理员操作。攻击者会隐藏在海量的日志中 —— 被盗用的 session 或脚本化登录看起来几乎与正常活动无异。防御者的工作是编写能够捕获恶意事件的逻辑，同时*避免*让分析师淹没在误报中。SentryLog 正是这项技能在身份层面的集中展示。 ## 检测规则 | # | 检测规则 | 捕获内容 | MITRE ATT&CK | |---|-----------|-----------------|--------------| | 1 | 登录速度 / 突发 | 单个用户在 15 秒内登录 ≥6 次 —— 自动化凭证滥用 | T1110 (Brute Force) | | 2 | 可疑 user agent | 来自非浏览器自动化工具（python-requests、curl、wget 等）的登录 | T1078 (Valid Accounts) | 每项检测**同时**存在为 Python 脚本（可读、可运行）和 **Sigma 规则**（可移植到 Splunk、Elastic 及其他 SIEM）形式。 ## 工作原理 1. **遥测数据** —— 真实的 Okta System Log 事件从个人开发者租户中以 CSV 格式导出。 2. **攻击模拟** —— 针对测试用户生成了受控的脚本登录突发流量，以产生标记好的恶意活动。（良性基线 = 同一租户内的正常账户活动。） 3. **检测** —— 每个 Python 检测脚本读取 CSV，应用其逻辑并发出告警。告警按用户进行去重，以减少告警疲劳。 4. **度量** —— 使用 precision/recall 对检测结果进行评分（参见结果）。 ## 结果 在受控的标记数据集（1 个攻击者账户，1 个良性账户）上： - **Precision: 1.00** —— 每个告警都对应真实的攻击者；无误报。 - **Recall: 1.00** —— 攻击者被两项检测全部捕获；无遗漏。 **这里的 100% 得分并不意味着检测是“好的” —— 它仅代表逻辑生效了。** 测试仅包含 2 个用户：一个明显的攻击者和一个明显的正常用户。在如此简单的测试中，任何能正常工作的检测都能得 100%。它证明了该规则会在应当触发时触发；但*不能*证明其在真实世界中的误报率。 有意义的评分需要针对大量用户进行测试，包括那些看起来像攻击者但并非如此的高难度对象 —— 频繁登录的服务账户，或者陷入快速 SSO 重试循环的客户端。这些边界情况才是真正考验检测的地方，而目前的数据集还未包含这些内容。构建一个更大、更杂乱的良性基线以暴露真实的误报是计划中的下一步。 ## 局限性 - **登录速度（检测 #1）：** 15 秒的时间窗口只能捕获快速的突发行为。采用低频慢速策略的攻击者如果拉开登录间隔（每 30+ 秒一次），就能低于阈值从而逃避检测。 - **User-agent 黑名单（检测 #2）：** 只能捕获列表上的工具，更关键的是，技术高超的攻击者可以伪造合法的浏览器 user-agent 来完全绕过它。 - **数据集：** 小且合成 —— 在一个租户中，从同一个地理位置对一名测试用户进行的单次模拟攻击。真实环境中的数据量、复杂性和噪声要大得多。 - **Sigma 可移植性：** 检测 #1 使用了并非所有 SIEM 后端都支持的关联规则（时间窗口计数），这与检测 #2 中的简单字段匹配不同。 ## 我学到的 / 关键设计决策 - **检测即代码工作流：** 检测如何从创意 → Python 逻辑 → SIEM 可运行的可移植 Sigma 规则，并映射到 MITRE ATT&CK。先用 Python 编写逻辑使得 Sigma 规则更容易被理解。 - **阈值调优是一项判断性的工作。** 我最初的测速窗口（5秒）漏掉了突发流量，因为登录的间隔约为 1.6 秒。将其扩大到 15 秒后成功捕获 —— 但我必须思考我到底试图捕获*哪种*攻击，而不是仅仅随便选一个数字。该阈值是在捕获慢速攻击和避免误报之间进行的权衡。 - **黑名单 vs. 白名单。** 我选择了 user-agent 黑名单，因为这个租户没有需要加入白名单的合法自动化行为。在一个拥有众多集成的大型企业中，我会将其与基于白名单的狩猎（hunt）相结合 —— 正确的选择取决于环境。 - **告警疲劳是真实存在的。** 我将告警按用户去重并附带计数，而不是每个事件生成一个告警，因为 SOC 分析师需要的是一个可操作的单一事项，而不是 15 行完全一样的记录。 - **完美的得分可能毫无意义。** 在仅有 2 个用户的测试中取得 100% 的 precision/recall 只能证明逻辑会触发 —— 并不代表检测是优秀的。理解这层差距比看那个数字更重要。 ## 仓库结构 ``` sentrylog/ ├── README.md ├── detections/ │ ├── detect_login_velocity.py # Detection #1 (Python) │ └── detect_suspicious_user_agent.py # Detection #2 (Python) ├── sigma/ │ ├── login_velocity.yml # Detection #1 (Sigma correlation rule) │ └── suspicious_user_agent.yml # Detection #2 (Sigma rule) └── data/ └── attack_burst_sample.csv # labeled Okta telemetry (benign + emulated attack) ``` ## 运行方式 ``` python detections/detect_login_velocity.py data/attack_burst_sample.csv python detections/detect_suspicious_user_agent.py data/attack_burst_sample.csv ```

标签：Okta, Python, Sigma规则, URL发现, 代码化检测, 安全检测, 无后门, 目标导入, 身份安全, 逆向工具