专栏首页腾讯安全应急响应中心基于威胁情报周期模型的APT木马剖析
原创

基于威胁情报周期模型的APT木马剖析

文|腾讯安全平台部 xti9er

前言

近日,腾讯服务器安全系统“洋葱”协助部署于公有云的某合作方捕获到一起APT事件,目前已处置完毕。处置过程中捕获木马样本一枚,该样本中包含了大量隐匿攻击手法,“洋葱”团队会同腾讯安全应急响应中心(TSRC)秉承共建行业安全生态的原则,采用威胁情报处理周期模型梳理该攻击手法,将分析结果与业界共享。

关于威胁情报处理周期模型

“威胁情报处理周期”(F3EAD)一词源于军事,是美陆军为主战兵种各级指挥员设计的组织资源、部署兵力的方法。网络应急响应中心借鉴这套方法,分以下六个阶段处理威胁情报信息:

基于威胁情报周期模型的APT木马剖析

威胁情报处理周期模型的应用

第一步:查找

某月某日,部署在合作方公有云服务器上的“洋葱”系统告警发现疑似木马程序,于是应急响应团队快速启动应急相应流程:

  • 干系人等一键拉群,电话接入。
  • 受害系统隔离待查。
  • 安全系统、审计日志导出待溯源分析。
  • 业务系统架构、代码相关资料准备,待分析入侵突破口及受影响范围

第二步:定位

根据安全系统的审计记录发现,恶意文件目录存在另一个*.ko文件,而此文件是通过scp从另一服务器传过来。

由此可见,攻击者首先拿到某个存在弱点的服务器权限,然后再跳转scp木马文件到包括当前受害机在内的通过已攻陷的服务器可访问的机器,并安装控制。

接下来咱们重点分析这组木马文件,根据AV厂商的命名规则(附录1),暂为其命名为"Backdoor:Linux/Rmgr!rookit",其中“rmgr”来至木马代码中多个函数用了rmgr前缀。

2.1. 木马文件

目前已经掌握的木马文件分四部分,其功能简单描述如下:

2.2 木马工作流程

木马从植入到运行,包括后续可能的渗透活动都采用了各种技术进行隐藏,如果没有安全系统则很难发现。同时,该木马也做了很多对抗,常规的安全监测能力未必可以发现。其运行流程简要描述如下图:

木马工作流程

2.3 木马各部分主要功能

1. rmgr.ko

rootkit采用常见的LKM内核模块。下面逐个列举此rootkit加载后的主要操作。

1)proc_create_data创建虚拟文件/proc/.dot3,用于后续与木马用户态进程交互;

2) register_kprobe注册4个kp结构体:

kp_kallsyms_lookup_name\krp_alloc_pid\kp_do_exit\kp_seq_path,用于通过kprobe来抢先在系统执行到这些函数的时候抹除对木马进程的操作;

3) 上述kp结构注册的处理函数,fake_seq_path用于摘除内核进程链表;

4) 当系统有读“/proc/net/tcp”文件的时候,由fake_seq_show处理,抹除木马网络连接;

5) 在fake_sys_getdents中patch vfs_readdir,抹除与木马相关的所有信息;

6) 当系统对木马相关文件访问的时候,会由fake_filldir处理,根据判断调用者是否木马操作来决定是否返回正确结果;

7) 在内核模块链表中删除自己,kobject_del删除自己的内核对象;

8) kthread_create创建内核线程dot_thread

  • 创建内核模块自启动/etc/sysconfig/modules/ati_remote3.modules
  • 写入内核模块文件/lib/modules/%s/kernel/drivers/input/misc/ati_remote3.ko
  • 释放rmgr_fake_libc.so文件到磁盘
  • 释放rmgr_daemon文件到磁盘,并以“[khelper]”进程名通过call_usermodehelper_exec运行它。

2. rmgr__fake_libc.so

此共享库文件,由内核rootkit释放写入磁盘,路径为/tmp/.tmp_{21个随机字母数字},用于木马的用户态进程的行为隐藏。

subhook前缀的函数摘抄自开源代码(附录2),详细功能请移步github围观,本文不赘述。

fake前缀的函数主要用于对抗常见HIDS的进程和命令记录,fork和execve直接通过syscall调用,而不使用glibc的封装,避开了hook glibc方式的HIDS。

fake_bash_add_history则让bash命令审计功能失效。

3. rmgr_daemon

此进程由rmgr.ko释放写入磁盘,路径为/tmp/.tmp_{21个随机字母数字}。由C++开发,编译后upx加壳压缩,直接用开源软件upx -d rmgr_daemon即可脱壳,并无特殊处理。

它主要有的功能有:

1) 监控内核模块状态,与内核rootkit信息交互;

2) 更新;

3) 生成rmgr_fake_sshd,并patchELF,修改依赖的动态库,也就是加入rmgr_fake_libc.so,功能如前述;

从内核获取路径
返回路径
patch ELF

4) 连接C2 hm2.yrnykx.com;

5) 管理rmgr_fake_sshd;

其中patchELF代码摘抄自GitHub - NixOS/patchelf (附录3)

4. rmgr_fake_sshd

文件由rmgr_daemon写入磁盘,路径为/tmp/.tmp_{21个随机字母数字},它的运行均由rmgr_daemon管理。

作为后门它硬编码了PRIVATE KEY ,如下图:

因为通过patchELF hook了部分函数,实现了ssh登录之后的命令执行等行为的隐匿。而rmgr_fake_sshd本身,以及ssh登录派生的子进程均通过rmgr.ko根据前述分析通过patch内核调用实现隐匿。

rmgr_fake_sshd启动时加载了硬编码的sshd_config,请注意其中几个关键配置。

监听在本地的26657端口,rmgr_daemon连接此端口转发来至C2的ssh指令。这里实现了拟合业务环境常用网络协议,使得常规的NIDS的检测逻辑被绕过。

第三步:消除

这里主要是指加固,避免被攻击者以同样的手法攻击。具体手段如下:

  • 突破口加固,补丁更新,ACL加固。
  • 运维通道,停用旧账户,修改攻击链路中服务器账户,并上双因素认证。
  • 根据用户角色限定可访问系统范围。
  • 受害系统dump保存虚机镜像,待查。
  • 重装受害系统,重新发布部署业务环境。
  • 新系统内核模块加载要求签名校验。

第四步:利用

完成应急响应工作,分析完事件现场和文件之后,整个事件中提取到的关键信息将沉淀为威胁情报。本文将威胁情报金字塔模型的内容缩减到iocs和ttps两部分,ttps用att&ck矩阵模型做归纳。

1. iocs 

1) md5:

7d859a22f38f0bcd55a46bc8b67c40df

fa73b2fd914a0cfd5e7d3161af903b6c

2) c2:

hm2.yrnykx.com

2. ttps

第五步:分析

从上节ttps可以看出来,att&ck矩阵并不能完全覆盖此次木马用于对抗安全系统的全部隐匿手段。

粗略的分类其隐匿(进程、网络、文件)手段有:

  • C2通过fake_sshd避开NIDS的检测;
  • 通过patchELF绕开hook libc的命令审计HIDS;
  • 通过fake_bash_add_history让shell审计失效;
  • 通过patch seq_show修改系统对/proc下文件信息读取的返回,实现对木马相关的文件、进程、网络连接信息的隐匿;
  • 通过patch vfs_readdir实现隐藏木马文件;
  • 通过摘除内核进程、模块链表信息,避免被rookit检测工具发现内核中木马痕迹;

可见,此款木马套装存在大量技术细节来对抗安全系统,不过它主要针对市面上已知的一些旧款HIDS和事后取证调查工具。内核态的进程派生syscall hook和inotify+云查杀还是可以发现它的。

木马与安全系统的对抗维度

一套完整的木马系统不可能仅仅因为一次渗透入侵而开发,必然会借鉴很多开源或者家族代码。所以从溯源角度来说,可以做代码“考古”工作,同时将相关代码风格和木马行为纳入安全系统特征库。限于篇幅,暂不在此赘述。

第六步:传播

传播即本文本身。

总结

事实上,实际的事件响应处置过程顺序不可能完全跟上述流程一致。但走完整套流程,笔者认为才能算是一个安全事件处置圆满的结束。其实,F3EAD流程比较重视情报从分析到应用(改进安全对抗能力),特别是在“分析”阶段的反复迭代。

F3EAD周期的分析阶段(迭代) (参考《情报驱动应急响应》)

从冰冷的情报到落地到我们安全系统安全能力的提升,这才实现了威胁情报的真正价值。

团队介绍

“洋葱”系统是腾讯内部自研的服务器安全系统(XDR),为腾讯公司百万级的服务器、镜像、容器提供入侵检测、安全基线检测、安全审计、追溯等安全能力。洋葱团队专注于黑客攻防领域,关注云原生、第三方组件、软件源等基础设施安全,欢迎有志从事基础安全的同志加入。同时洋葱团队也在和业务合作,为一些外部企业和合作方提供安全能力输出。

附录

1. Malware names, https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/malware-naming

2. subhook, https://github.com/Zeex/subhook/blob/master/subhook_x86.c

3. NixOS/patchelf, https://github.com/NixOS/patchelf

4. 《情报驱动应急响应》,斯科特·罗伯茨(Scott J.Roberts)

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 面向DevSecOps的编码安全指南| JavaScript篇

    近年来,无论是DevSecOps,还是Google SRE的可靠和安全性理念,都提倡“安全需要每个工程师的参与”。其中涉及的“安全左移”理念也再次被推向前台,获...

    腾讯安全应急响应中心
  • 【安全通知】PyPI 官方仓库遭遇request恶意包投毒

    近日,腾讯洋葱反入侵系统检测发现 PyPI官方仓库被恶意上传了request 钓鱼包,由于国内开源镜像站均同步于PyPI官方仓库,所以该问题不仅会通过官方仓库,...

    腾讯安全应急响应中心
  • BORG —— 一个快速进化的僵尸网络

    近日,宙斯盾流量安全分析团队发现大量针对Docker、Kubernetes等服务的异常扫描流量,我们对此深入分析发现,一个专门针对容器虚拟化服务的僵尸网络浮出水...

    腾讯安全应急响应中心
  • 【腾讯云的1001种玩法】3元体验腾讯云小程序后端解决方案

    腾讯云为小程序提供的后端一整套解决方案,可以快速部署后端,无需关注后端太复杂繁琐的配置,直接切入主题展开开发

    蔡鹏
  • 小白Pycharm使用(3):重要笔记Pycharm连接Github

    1、File->Settings->Version Control->Github

    Python之道
  • 人脸识别是怎么做到的?看懂TOF与结构光的区别

    去年9月份苹果推出了iPhone 11、iPhone 11 Pro和iPhone 11 Pro Max三款新iPhone,新机型的性能在拍照和续航上得到大幅度的...

    用户6830950
  • Jenkens安装配置

    飞狗
  • Android移动开发案例教程-第二章 Android开发起步_V0.2

    iOSDevLog
  • 数据分析之对应分析

    还有一种探索性分析方法叫做对应分析。对应分析能够把一个交叉表结果通过图形的方式展现出来,用以表达不同变量之间以及不同类别之间的关系。对应分析实际也是“降维”方法...

    黄成甲
  • 跨平台开发 -- C# 使用 C/C++ 生成的动态链接库

    .NET Core 虽然实现了跨平台,但是不可能处处使用 C# 开发,就好像没人使用SQL开发安卓APP,每种语言都有其优秀的地方和局限性。

    痴者工良

扫码关注云+社区

领取腾讯云代金券