企业官网建设流程全解析

邮件转发规则攻击检测指南：基于 MITRE ATT&CK 映射与端点/云遥测数据源实战（Anthropic-Cybersecurity-Skills）

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

导读

邮件转发规则（Email Forwarding Rule）攻击是攻击者在获取邮箱控制权后最常使用的持久化手段之一——通过创建一条「自动转发 + 删除原邮件」的收件箱规则，攻击者可以长期、静默地窃取目标组织的高价值邮件情报，并为后续的商业电子邮件欺诈（BEC）铺路。本篇文章以 Anthropic-Cybersecurity-Skills 仓库中skills/detecting-email-forwarding-rules-attack技能包（含 标准与参考文档、详细狩猎工作流、API 参考 及两个检测脚本）为核心骨架，系统讲解 T1114.003 等技术如何在 MITRE ATT&CK 中定位、应当采集哪些 Sysmon / Windows 安全日志与云审计数据源、如何编写 Splunk / KQL / PowerShell 检测语句，以及如何利用仓库内 Python 脚本落地自动化狩猎。读完本文，你将掌握一套从「数据源选型 → 查询构建 → 基线异常 → 关联验证 → 报告输出」的完整邮件转发规则攻击检测方案。

威胁背景：为什么邮件转发规则是持久化的高价值目标

攻击者入侵一个邮箱账户后，并不急于立刻窃取数据，而是更倾向于"长期经营"：在收件箱中创建一条静默规则，把 CEO、CFO、财务人员的邮件实时转发到外部攻击者邮箱，同时将原邮件标记为已读或删除，规避受害者的察觉。这类行为：

• 天然与商业电子邮件欺诈（BEC）高度相关——攻击者借助对真实邮件的持续观察，精准模仿内部口吻实施转账诈骗；
• 属于邮件情报收集型持久化，攻击者无需反复入侵即可获得持续访问；
• 在日志层面常与新建/修改收件箱规则、新增委派权限、远程邮箱访问三类动作伴生。

该技能包的元数据（SKILL.md）将其定位为threat-hunting/mitre-attack/email-forwarding/persistence/bec/t1114标签下的主动检测能力，版本1.0，采用 Apache-2.0 许可，并在 NIST CSF 2.0 中映射到DE.CM-01（持续监控）、DE.AE-02（异常事件分析）、DE.AE-07（攻击链关联）、ID.RA-05（威胁情报）等能力项，在 D3FEND 中对应Restore Object、Restore Configuration、Application Configuration Hardening、Application Hardening、Disable Remote Access等防御技术。

MITRE ATT&CK 技术映射：攻击行为在矩阵中的坐标

标准与参考文档 开篇给出了该检测主题在 MITRE ATT&CK 中的核心映射表，这是整篇检测逻辑的"坐标系"：

三者共同构成"邮件持久化访问"的攻击链路：T1098.002（先扩大访问权限）→T1114.003（建立转发规则持续引流）→T1114.002（远程批量拉取历史邮件）。在 SKILL.md 的 Key Concepts 中同样列出了这三大技术，并在 Target Techniques 层面指导狩猎时逐项核对。

配套的四个典型攻击场景（见 SKILL.md 的 Common Scenarios）分别是：

1. 场景一：BEC 攻击者在被控邮箱创建指向外部邮箱的转发规则；
2. 场景二：被控账户中创建"删除安全告警邮件"的规则，隐匿防御响应；
3. 场景三：收件箱规则将 CEO 邮件转发至攻击者邮箱；
4. 场景四：恶意 OAuth 应用滥用权限创建传输规则（Transport Rule）进行数据收集。

实战要点：狩猎时不要把目光只放在New-InboxRule上。删除/隐藏告警、移动邮件到不常用文件夹（如 RSS、Junk）、批量标记已读等"隐形动作"，往往比单纯转发更具攻击意图，需要结合规则条件与动作联合判定。

检测数据源：端点上该采集哪些事件

标准与参考文档 的第二张核心表是检测数据源清单，它回答了"检测这类攻击到底要看哪些日志"的问题，分为 Sysmon 与 Windows 安全日志两个体系。

Sysmon 事件：进程与行为级细粒度遥测

虽然"邮件转发规则"本身发生在云端的 Exchange/Microsoft 365 中，但攻击者在建立规则之前通常需要完成凭证窃取、PowerShell/工具落地等前置动作，这些动作会以进程行为的形式出现在端点上。因此：

• Sysmon 1（进程创建 + 命令行）用于发现New-InboxRule、Set-InboxRule、Enable-InboxRule等 PowerShell/Exchange Online 命令的执行痕迹；
• Sysmon 10（进程访问 LSASS）配合 4624 等登录事件，用于还原攻击者如何窃取会话凭据进而访问 Exchange；
• Sysmon 22（DNS 查询）用于发现指向外部收集邮箱（如攻击者自有域名）的异常解析；
• Sysmon 25（进程篡改）用于发现攻击者试图关闭或干扰 EDR 检测进程的行为，与"删除安全告警邮件"的场景互为印证。

Windows 安全日志：身份与认证维度的补充证据

安全日志的价值在于身份维度交叉验证：一条 4688 进程创建 + 4648 显式凭据登录，可以确认"哪个账户在哪个时间点主动发起了 Exchange 管理类命令"；4625 大量失败登录可能是凭证喷洒的前兆；4698 计划任务 / 4697 服务安装则提示攻击者可能在端点侧建立了与邮件规则配套的持久化机制。将这些事件与云端规则创建审计按用户、IP、时间窗关联，即可把"云端规则"与"端点行为"串成完整攻击链。

云端数据源：规则创建行为的第一现场

邮件转发规则的"第一现场"在云端，API 参考文档 与 详细狩猎工作流 提供了三类获取手段。

Microsoft Graph API：读取收件箱规则

GET https://graph.microsoft.com/v1.0/users/{user-id}/mailFolders/inbox/messageRules Authorization: Bearer {token} # Response { "value": [ { "displayName": "Forward invoices", "isEnabled": true, "conditions": {"subjectContains": ["invoice", "payment"]}, "actions": { "forwardTo": [{"emailAddress": {"address": "attacker@evil.com"}}], "delete": true, "markAsRead": true } } ] }

注意响应中的forwardTo（转发）、delete（删除原邮件）、markAsRead（标记已读）字段——它们正是判定恶意规则的核心动作字段，与仓库检测脚本 agent.py 中analyze_rules()逐一解析的字段一一对应。

Exchange Online PowerShell：跨邮箱批量排查

# List all inbox rules for a user Get-InboxRule -Mailbox user@company.com | FL Name, ForwardTo, RedirectTo, DeleteMessage # Find forwarding rules across all mailboxes Get-Mailbox -ResultSize Unlimited | ForEach-Object { Get-InboxRule -Mailbox $_.UserPrincipalName | Where-Object { $_.ForwardTo -or $_.RedirectTo } } # Search unified audit log for rule creation Search-UnifiedAuditLog -Operations "New-InboxRule","Set-InboxRule" -StartDate (Get-Date).AddDays(-30)

第一条命令适合单账户快速核查；第二条在全租户范围内枚举"存在转发/重定向动作"的规则，是猎杀 BEC 的高效起点；第三条则直接从统一审计日志（Unified Audit Log）中回溯规则创建/修改操作，回看窗口建议覆盖至少 30 天。

SIEM / EDR 查询语句

Splunk SPL（针对 Exchange 审计日志）：

index=o365 Workload=Exchange Operation IN ("New-InboxRule","Set-InboxRule","Enable-InboxRule") | where match(Parameters, "(?i)(forward|redirect|delete|move.*junk)") | table _time UserId Operation Parameters ClientIP

该语句先按操作类型（新建/修改/启用收件箱规则）圈定事件，再用正则匹配forward、redirect、delete、move.*junk等关键词，最后输出时间、用户、操作、参数与来源 IP。正则中的(?i)表示忽略大小写，move.*junk可捕获"移动到垃圾邮件文件夹"这类隐藏动作。

SPL 进阶：识别外部转发目标：

index=o365 Operation IN ("New-InboxRule", "Set-InboxRule") | spath output=forward path=Parameters{}.Value | where isnotnull(forward) AND NOT match(forward, "@company\\.com")

该变体用spath从结构化 Parameters 中抽取转发目标地址，然后排除组织内部域，命中即外部转发——注意@company\.com中的\.转义，请将company.com替换为实际组织域名。

KQL（Microsoft Defender for Endpoint / M365）：

CloudAppEvents | where ActionType in ("New-InboxRule","Set-InboxRule") | where RawEventData has_any ("ForwardTo","RedirectTo","DeleteMessage") | project Timestamp, AccountObjectId, ActionType, RawEventData, IPAddress

CloudAppEvents表覆盖 Microsoft 365 云应用活动，has_any是子串级匹配（比contains更高效），输出时间、账户、动作类型、原始载荷与 IP，便于后续关联。

可疑规则判定指标：从特征到风险分级

API 参考文档 给出的可疑规则指标表，是人工研判与脚本自动评级的共同基础：

源码级的判定逻辑

仓库脚本 agent.py 将上述指标直接编码为检测规则集合：

SUSPICIOUS_RULE_PATTERNS = { "forward_external": {"severity": "HIGH", "desc": "Rule forwards to external domain"}, "delete_after_forward": {"severity": "CRITICAL", "desc": "Rule deletes after forwarding"}, "move_to_rss": {"severity": "HIGH", "desc": "Rule moves to RSS Feeds folder"}, "move_to_junk": {"severity": "MEDIUM", "desc": "Rule moves to Junk folder"}, "keyword_financial": {"severity": "HIGH", "desc": "Rule targets financial keywords"}, "mark_as_read": {"severity": "MEDIUM", "desc": "Rule marks messages as read"}, } FINANCIAL_KEYWORDS = ["invoice", "payment", "wire", "transfer", "bank", "ach", "routing", "remittance", "purchase order"]

从源码结构看，analyze_rules()的判定优先级值得关注：

1. 外部转发即告警：当转发/重定向目标不以组织域结尾时，直接生成 finding；若同时带delete动作，严重级从 HIGH 升为CRITICAL（severity = "CRITICAL" if delete else "HIGH"）；
2. 财务关键词 + 转发 = CRITICAL：当规则的subjectContains或bodyContains命中FINANCIAL_KEYWORDS列表（invoice、payment、wire、transfer、bank、ach、routing、remittance、purchase order）且存在转发动作时，判定为CRITICAL，无论是否删除原件；
3. 转发 + 标记已读 = silent_forwarding：标记为 HIGH 级"静默转发"，用于发现不删除但也不留下已读痕迹的隐蔽规则。

get_mailbox_rules()则负责调用 Graph API（/mailFolders/inbox/messageRules），对 HTTP 200 以外的响应与网络异常均做了容错，返回{"error": ...}结构而非直接崩溃，适合放入自动化流水线。

日志侧自动化：process.py 的评分模型

另一个脚本 process.py 面向日志狩猎场景，内置DETECTION_PATTERNS（New-InboxRule、Set-InboxRule、ForwardTo、RedirectTo、DeleteMessage），对每条事件：

• 同时扫描CommandLine与Parameters/RawEventData字段；
• 每命中一个模式累加 25 分，总分封顶 100；
• 风险分级为：>=75→ CRITICAL，>=50→ HIGH，>=25→ MEDIUM，否则 LOW。

该评分模型的含义是：同时出现New-InboxRule + ForwardTo + DeleteMessage（命中 3 个模式，75 分）即触发 CRITICAL——与人工判定表中"转发 + 删除 = CRITICAL"的结论完全一致，只是将人工经验转成了可复现的量化规则。

五阶段狩猎工作流：从假设到报告

详细狩猎工作流 把完整狩猎拆成五个阶段，与 SKILL.md 中的七步工作流（提出假设 → 确定数据源 → 执行查询 → 分析结果 → 验证发现 → 关联活动 → 记录报告）相互呼应。

Phase 1：数据收集与查询

按上一节的 Splunk / KQL 语句采集规则创建与修改事件，重点覆盖New-InboxRule、Set-InboxRule、Enable-InboxRule三类操作。

Phase 2：基线建立与异常发现

• Step 2.1 建立基线：收集该技术 30 天历史数据；记录正常模式、频率与合法用例；识别已知误报源并建立排除清单；对关键指标构建统计基线（均值、标准差）；
• Step 2.2 识别异常：将当前活动与 30 天基线比对，标记偏离均值超过 3 个标准差的事件；按风险分与潜在业务影响排序；与威胁情报中的已知 IOC 交叉比对。

3σ 准则的意义：绝大多数正常用户的规则操作集中在均值附近，超过 3 个标准差意味着"几乎不可能由正常行为产生"，适合作为第一轮筛选阈值，随后再结合上下文做人工研判。

Phase 3：深入调查与攻击链关联

• 对每个异常收集完整进程树上下文；
• 与网络活动、文件操作、认证事件关联（对应标准文档中的 Sysmon 3/11 与 Security 4624/4688 等事件）；
• 校验二进制签名、文件哈希与证书有效性；
• 审查用户账户上下文与访问模式；
• 将发现映射到 MITRE ATT&CK 杀伤链阶段，识别初始访问向量，追溯横向移动与权限提升路径，最终确定数据访问范围与潜在外泄通道（T1114.002 远程收集在此阶段最为活跃）。

Phase 4：真/假阳性判定与响应

• 与系统所有者及 IT 运维核对；检查变更管理记录中的授权活动；验证用户上下文（授权操作 vs. 被控账户）；
• 确认威胁 → 启动事件响应流程；发现检测缺口 → 新建或更新检测规则；确认误报 → 调优规则与排除项；最后将经验教训回写狩猎剧本。

Phase 5：文档与报告

• 汇总假设、方法学与发现；附上所有已执行查询及其结果；记录发现的 IOC 与新建的检测规则；给出安全改进建议；
• 将发现入库威胁情报平台；更新 MITRE ATT&CK 覆盖热力图；以 Sigma 格式共享检测规则；为相关技术安排后续狩猎。

落地实操：运行仓库脚本执行自动化狩猎

agent.py：基于 Graph API 与审计日志的检测

python agent.py --token "eyJ..." --user-id user@company.com --org-domain company.com python agent.py --audit-log exchange_audit.log

• --token：Microsoft Graph API Bearer Token；
• --user-id：目标用户 ID 或 UPN，默认me；
• --org-domain：组织邮箱域名，用于判定"外部转发"（留空则跳过外部转发检测）；
• --audit-log：本地 Exchange 审计日志文件路径，程序会按行匹配New-InboxRule/Set-InboxRule并用正则提取ForwardTo与UserId。

输出为 JSON，包含时间戳、total_rules、findings（含 rule_name、type、forward_to、severity、mitre 编号）与total_findings，方便直接接入 SIEM 或工单系统。

process.py：批量日志狩猎与报告生成

python process.py hunt --input events.json --output ./detecting_email_output python process.py queries

• hunt子命令：--input接受 JSON（列表或含events键的对象）或 CSV（UTF-8 带 BOM），逐条执行模式评分，输出detecting_email_forw_findings.json（含hunt_id、total_events、findings）与hunt_report.md（按风险分降序展示 Top 20 发现）；
• queries子命令：打印指向 详细狩猎工作流 的查询指引。

两个脚本均仅依赖 Python 标准库与requests（缺失时会提示pip install requests），可在最小环境下直接运行。

结果输出格式与狩猎模板

SKILL.md 定义了标准化的结果输出格式，便于跨团队统一交接：

Hunt ID: TH-DETECT-[DATE]-[SEQ] Technique: T1114.003 Host: [Hostname] User: [Account context] Evidence: [Log entries, process trees, network data] Risk Level: [Critical/High/Medium/Low] Confidence: [High/Medium/Low] Recommended Action: [Containment, investigation, monitoring]

仓库还提供了完整的 狩猎模板，包含：狩猎元数据（Hunt ID、分析师、状态、优先级）、假设陈述与依据（威胁情报 / ATT&CK 缺口 / 异常 / 事件跟进）、目标技术清单、数据源勾选清单、查询执行记录、发现汇总表（TP / FP / BTP 判定）、IOC 记录（网络域 + 主机域）、结果统计、假设结论（已证实 / 部分证实 / 已推翻 / 证据不足）以及建议与分析师备注。该模板可作为每次狩猎的"强制落盘"骨架，保证可追溯性。

前置条件与工具链选型

根据 SKILL.md 的 Prerequisites，落地本方案需要：

• EDR 平台：具备进程与网络遥测能力（如 CrowdStrike Falcon、Microsoft Defender for Endpoint、SentinelOne）；
• SIEM：已接入相关日志（Splunk、Elastic、Microsoft Sentinel）；
• Sysmon：以完整配置部署，重点保证事件 1/3/7/10/11/12/13/22/25 的采集；
• Windows 安全事件日志转发：启用 4624/4625/4648/4672/4688/4697/4698/4769/5140 等事件的集中收集；
• 威胁情报源：用于 IOC 关联。

工具链上，CrowdStrike Falcon 提供 EDR 遥测，MDE 支持 KQL 高级狩猎，Splunk/Elastic 承担 SIEM 关联，Sysmon 提供细粒度端点事件，Velociraptor 负责端点工件采集，Sigma 用于跨平台共享检测规则（完整工具清单见 SKILL.md 的 Tools & Systems）。

参考与延伸阅读

• 标准与参考文档：MITRE ATT&CK 映射、Sysmon 与 Windows 安全事件 ID 数据源清单，以及 Sigma、LOLBAS、Atomic Red Team 等检测资源指引（外部链接原文可在此文件内查看）；
• 详细狩猎工作流：五阶段方法论与全部查询语句；
• API 参考：Graph API、Exchange PowerShell、SPL 检测与 CLI 用法；
• agent.py 与 process.py：可运行检测脚本；
• 狩猎模板：可直接复用的标准狩猎报告模板。

适用前提说明：本文检测语句中的index=o365、@company\.com、CloudAppEvents等均为占位/示例字段，实际使用时须按本组织的日志索引、域名与数据表命名调整；Graph API 与 Exchange PowerShell 命令需要相应的审计权限与合规授权，建议在获得书面授权的环境（如企业安全评估、紫队演练）中执行。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills