正文

OpenForensicRules 发布！

admin
admin V管理员 /0 评论 /14 阅读
0702
文章最后更新时间2025年07月02日，若文章内容或图片失效，请留言反馈！

0x00 简介

大家好，我们是 NOPTeam

每年到了这个时间，都会有一批新的朋友关注我们的公众号。我推测，这可能是因为大家阅读了我们编写的两本应急响应手册，希望这些书籍能够对您的实际工作有所帮助

在日常的安全运营或安全运维过程中，各类安全平台不断协同联动，整体运行看似和谐有序。然而，一旦发生真实的攻击事件，往往会出现一些非常规、意料之外的情况。下面，我将举几个典型案例加以说明：

1. 受害方已将重要服务器重置

相信经常参与应急响应的同仁都遇到过类似情况。受害单位为了降低业务中断带来的影响，通常选择优先重装系统。业务需求优先，这样的决策无可厚非，大多是权衡利弊后的结果。

2. 要求在两天内完成处置，之后须恢复服务

此类需求在实际工作中也十分常见。无论系统规模多大，留给应急处置的时间往往十分有限，能够配合检查的人员也非常有限。

3. 应急响应人员到场前，关键线索已被污染

此类情况几乎是所有应急响应人员都会遇到，甚至部分应急响应人员对此并未充分意识到。在与攻击者对抗的过程中，应急响应人员本就处于劣势，而最为宝贵的痕迹信息很可能在内部提前排查或正常业务操作中被覆盖、破坏。

0x01 解决方案

不理想的处置环境在一定程度上会降低应急响应人员的责任，但同时也容易影响其积极性，从而给整个行动带来消极影响。

接下来，我们重新审视上述几个典型问题：

1. 受害方已将重要服务器重置

想尽快恢复系统的心情我能理解，但应该也不是一分钟也不能等，但是要把受害系统硬盘以及内存全部备份一份给应急人员排查原因，那对不起，真等不了

2. 要求在两天内完成处置，之后须恢复服务

受害单位只能提供两天时间进行处置，但有时单一系统的排查就可能耗时半天至一天。

无奈之下，只能临时增加人手参与处置。

然而，受害单位能够配合的人员数量有限，且很多时候新增人员仅能参与远程协作，无法到达现场。如何确保每增加一位应急响应人员，都能切实提升处置效率？如何实现现场与远程的高效协同？这些都是亟待解决的问题。

3. 应急响应人员到场前，关键线索已被污染

首先需要排除业务系统自身覆盖数据的情况。

许多单位在确认存在攻击行为后，第一时间便着手排查攻击路径，而往往忽略了证据的及时保存。

这种做法极易导致关键信息的丢失，也不利于后续的溯源和责任认定。

这正是问题的核心所在。

我们常常因为面对结果，而忘了去思考原因

我认为，这些问题都指向了一个核心解决方案——数字取证，而且是针对应急响应场景的数字取证，而非传统意义上的广义电子取证。

让 DF 和 IR 以合适的形式结合在一起，变成真正的 DFIR (Digital Forensics and Incident Response)

我们希望 **针对应急响应场景的取证 **成为各单位确定发生安全事件后要做的第一件事情。

为此，我们基于 https://github.com/ForensicArtifacts/artifacts 项目，进行了有针对性的优化与完善，推出了一套标准化的数字取证与应急响应信息采集规则格式规范——OpenForensicRules。

目前，该规范尚处于 v0.0.1 版本阶段。欢迎各界同仁根据实际需求，积极提出优化建议，共同完善并最终形成一套成熟的行业规则。我们也期待，未来能够有基于该规范的数字取证与应急响应工具或产品，为遭遇攻击事件的受害单位，提供切实有效的解决方案。

当然，这类规则也很适合红队用于收集现有成果，建议在法律允许范围内使用

OpenForensicRules: 数字取证信息采集规则格式规范

1. 简介

ForensicArtifacts 是一套标准化的数字取证与应急响应信息采集规则格式规范。它旨在提供一个通用的配置框架，使取证专业人员能够：

  • 定义可跨平台复用的取证工件采集规则
  • 在不同的取证工具和框架中使用相同的规则集
  • 构建和分享标准化的证据采集方法

本项目受到 ForensicArtifacts/artifacts 项目的启发，并在其基础上进行了改进和扩展。

2. 规则示例

规则使用 YAML 格式定义，每个配置的基本单元是一个 Artifact。以下是两个简单示例：

name:'WindowsSystemEventLogEvtx'doc:'Windows System Event log for Vista or later systems.''author: 'ForensicArtifacts'version:0.0.1sources:-type:'FILE'attributes:paths:['%%environ_systemroot%%System32winevtLogsSystem.evtx']supported_os:'Windows'urls:['https://artifacts-kb.readthedocs.io/en/latest/sources/windows/EventLog.html']
name:'LinuxLog'doc:'Linux 平台上日志文件收集'author:'NOPTeam'version:'0.0.1'sources:-type:'PATH'supported_os:'Linux'attributes:paths:-'/var/log/'

3. Artifact 定义规范

3.1 核心字段

字段
描述
是否为必填项
name
工件名称
✓
doc
工件的描述信息
✗
author
工件作者
✗
sources
信息采集的数据源
✓
urls
工件相关的参考链接
✗
version
规则版本
✓

3.2 字段详细说明

name

工件的唯一标识符，应清晰表达该工件的用途。

格式要求：

  • 长度：2-255个字符
  • 字符限制：仅支持英文字母和数字
  • 命名风格：首字母大写的驼峰式命名
name:'WindowsSystemEventLogEvtx'

doc

工件的描述信息，说明其用途、重要性或注意事项。

格式建议：

  • 简明扼要，通常为单行描述
  • 需要多行时使用 YAML 多行文本格式（|）
doc:|  Windows 系统事件日志，适用于 Vista 及更高版本系统。  包含系统启动、关机、服务启停等重要事件信息。

author

工件的作者信息。

author:'NOPTeam'

urls

相关参考资料的链接列表。

urls:-'https://artifacts-kb.readthedocs.io/en/latest/sources/windows/EventLog.html'-'https://forensics.wiki/windows_event_log/'

version

规则版本号，当前规范版本为 0.0.1。

version:'0.0.1'

sources

工件的核心组成部分，定义了实际的数据采集源。每个工件可包含多个 source 对象。

sources:-type:COMMANDattributes:args:['-ano']cmd:netstatsupported_os:"windows"-type:FILEattributes:paths:['%%environ_systemroot%%System32winevtLogsSystem.evtx']supported_os:"windows"

4. Source 定义规范

每个 source 对象表示特定操作系统上的一种数据源类型。

4.1 核心字段

字段
描述
是否为必填项
type
数据源类型
✓
attributes
数据源属性
✓
supported_os
支持的操作系统
✓

4.2 Source 类型

COMMAND

执行特定命令并收集其输出。

属性
描述
是否为必填项
cmd
命令路径或名称
✓
args
命令参数列表
✓
type:'COMMAND'attributes:cmd:'netstat'args:['-ano']supported_os:'windows'

FILE

收集特定文件。

属性
描述
是否为必填项
paths
文件路径列表
✓
type:'FILE'attributes:paths:-'%%environ_systemroot%%System32winevtLogsSystem.evtx'-'C:WindowsSystem32driversetchosts'supported_os:'windows'

PATH

收集特定目录。

属性
描述
是否为必填项
paths
目录路径列表
✓
name:'LinuxLog'doc:'Linux 平台上日志文件收集'author:'NOPTeam'version:'0.0.1'sources:-type:'PATH'supported_os:'Linux'attributes:paths:-'/var/log/'0

REGISTRY_KEY

收集 Windows 注册表键。

属性
描述
是否为必填项
keys
注册表键路径列表
✓
name:'LinuxLog'doc:'Linux 平台上日志文件收集'author:'NOPTeam'version:'0.0.1'sources:-type:'PATH'supported_os:'Linux'attributes:paths:-'/var/log/'1

REGISTRY_VALUE

收集 Windows 注册表特定键的值。

属性
描述
是否为必填项
key_value_pairs
键值对列表
✓
name:'LinuxLog'doc:'Linux 平台上日志文件收集'author:'NOPTeam'version:'0.0.1'sources:-type:'PATH'supported_os:'Linux'attributes:paths:-'/var/log/'2

特别说明：在 Windows 注册表中，value 的概念是 ValueName + ValueType + Data 的集合。本规则采用 Windows 中的 ValueName 作为 value 的值。

WMI

通过 WMI 查询收集 Windows 系统信息。

属性
描述
是否为必填项
base_object
WMI 命名空间
✗
query
WMI 查询语句(WQL)
✓
name:'LinuxLog'doc:'Linux 平台上日志文件收集'author:'NOPTeam'version:'0.0.1'sources:-type:'PATH'supported_os:'Linux'attributes:paths:-'/var/log/'3

4.3 支持的操作系统

supported_os 字段定义了数据源适用的操作系统：

值
描述
windows
Windows 操作系统
linux
Linux 操作系统
darwin
macOS/OS X 操作系统
android
Android 操作系统
ios
iOS 操作系统

5. 内置变量与通配符

规则支持多种内置变量，用于指定不同环境下的标准路径。在路径中可以使用通配符 * 和以下内置变量。

5.1 POSIX 用户变量

变量名
说明
%%users_homedir%%
系统所有用户的主目录 (MacOS: /Users/* 、Linux: /home/* 以及 /root)
%%current_user_homedir%%
当前用户的主目录

5.2 Windows 环境变量

变量名
说明
%%environ_allusersappdata%%
环境变量 => %AllUsersAppData% 不存在时等于 %ProgramData% 环境变量
%%environ_allusersprofile%%
环境变量 => %AllUsersProfile%
%%environ_programdata%%
环境变量 => %ProgramData% 不存在时等于 %AllUsersAppData% 或 %AllUsersProfile%Application Data
%%environ_programfiles%%
环境变量 => %ProgramFiles%
%%environ_programfilesx86%%
环境变量 => %ProgramFiles(x86)%
%%environ_systemdrive%%
环境变量 => %SystemDrive% （例如C:）
%%environ_systemroot%%
环境变量 => %SystemRoot% （例如C:Windows）
%%environ_windir%%
环境变量 => %WinDir% （例如C:Windows）

5.3 Windows 用户变量

所有用户变量

这些变量会展开为系统上所有用户的对应路径：

变量名
说明
%%users_appdata%%
所有用户的环境变量 => %AppData% 默认 Vista+: %%users_userprofile%%AppDataRoaming 旧版: %%users_userprofile%%Application Data
%%users_localappdata%%
所有用户的环境变量 => %LocalAppData% Vista+默认:%%users_userprofile%%AppDataLocal 旧版默认：%%users_userprofile%%Local SettingsApplication Data
%%users_sid%%
所有用户的安全标识符 (SID)
%%users_temp%%
所有用户的环境变量 => %TEMP% 或 %TMP% 即所有用户的临时目录
%%users_username%%
所有用户的环境变量 => %USERNAME% 即所有用户的名称
%%users_userprofile%%
所有用户的环境变量 => %USERPROFILE% 即用户配置文件目录: Vista+默认: C:Users用户名 旧版默认: C:Documents and Settings用户名

当前用户变量

这些变量仅展开为执行取证工具的当前用户路径：

变量名
说明
%%current_user_appdata%%
当前用户的环境变量 => %AppData% 默认 Vista+: %USERPROFILE%AppDataRoaming 旧版: %USERPROFILE%Application Data
%%current_user_localappdata%%
当前用户的环境变量 => %LocalAppData% Vista+默认:%USERPROFILE%AppDataLocal 旧版默认：%USERPROFILE%Local SettingsApplication Data
%%current_user_sid%%
当前用户的安全标识符 (SID)
%%current_user_temp%%
当前用户的环境变量 => %TEMP% 或 %TMP% 即当前用户的临时目录
%%current_user_username%%
当前用户的环境变量 => %USERNAME% 即当前用户的名称
%%current_user_userprofile%%
当前用户的环境变量 => %USERPROFILE% 即当前用户配置文件目录: Vista+默认: C:Users当前用户名 旧版默认: C:Documents and Settings当前用户名

6. 最佳实践

6.1 用户变量使用指南

  • 完整取证场景：使用 %%users_xxx%% 变量收集所有用户的数据

  • 针对性调查：使用 %%current_user_xxx%% 变量仅收集当前用户数据

  • 权限考虑：

    • %%users_xxx%% 变量通常需要管理员/root权限才能完全访问
    • %%current_user_xxx%% 变量在标准用户权限下也可以使用，但仅限于当前用户上下文

6.2 规则设计原则

  1. Artifact 归类准确，命名清晰：在考虑创建 Artifact 时，其内部囊括的 source 应均与该 Artifact 主题强相关，命名 Artifact 时应清晰明了，使用户能够快速理解其内容。
  2. 谨慎使用通配符：滥用通配符可能使框架程序过度收集信息。
  3. 文档完善：提供足够的描述和参考链接，帮助使用者理解规则的用途。
  4. 跨平台考虑：尽可能设计能在多平台使用的规则。

6.3 性能与安全考量

  1. 考虑资源消耗：避免定义可能导致过度资源消耗的规则。
  2. 注意隐私影响：确保规则遵循相关法规和隐私保护要求。

7. 注意事项

7.1 多 Artifact 定义

在 YAML 文件格式中，可以使用 --- 分隔符包含多个 Artifact 定义，这是 YAML 规则决定的，开发者应该考虑这一点，当然可以对其进行自定义规定。

例如：

name:'LinuxLog'doc:'Linux 平台上日志文件收集'author:'NOPTeam'version:'0.0.1'sources:-type:'PATH'supported_os:'Linux'attributes:paths:-'/var/log/'4

7.2 变量展开行为

  • %%users_xxx%% 变量将展开为系统上所有用户的相应路径（可能生成多个路径）
  • %%current_user_xxx%% 变量仅展开为执行取证工具的当前用户路径（生成单个路径）
  • 使用变量时应考虑工具执行权限对变量展开的影响

7.3 规则验证

建议实施以下验证措施：

  • 使用 YAML 验证工具确保语法正确
  • 在多种目标环境中测试规则有效性
  • 评估规则的性能影响和数据采集量

8. 贡献指南

我们欢迎社区贡献新的取证规则或改进现有规则。请遵循以下步骤：

  1. Fork 项目仓库
  2. 创建功能分支
  3. 提交您的规则或修改
  4. 创建 Pull Request

或联系微信 just_hack_for_fun 反馈

所有贡献者都应遵循本文档中定义的格式规范。

9. 许可证

本项目采用 Apache 2.0 协议

往期文章


推荐站内搜索：最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
ZhouSa.com-周飒博客