安全技术运营的学习与笔记3

今天是清明节，追思缅怀的日子，因为我们能够想起，所以那些离开的人始终会活在我们心中，提醒我们珍惜当下，“清明思念永铭心，缅怀逝者不曾离”。

前两篇笔记主要是写安全技术运营的概念理解以及关注的内容和流程方法论，在流程中经历了三个阶段的发展，到如今结合时代变化会考虑与AI结合的方法来提升安全技术运营的效果。总结一下就是安全技术运营是保障企业信息系统安全性和可用性的重要手段，需要关注威胁情报、安全事件响应、漏洞管理、安全风险评估等内容，并遵循发现、分析与定位威胁（监控、分析和响应）的流程方法论。结合人工智能技术，可以更好地提高安全技术运营的效果，使网络安全得到更好的保障。

在整个安全技术运营中，恶意文件的占比相对是很大的，VirusTotal每天能接收到来源全球的几百万文件，因此我们需要去了解恶意文件的方方面面，做到知己知彼。恶意文件的种类很多，常见的有僵木蠕等，想起恶意代码分析相关岗位常见的面试问题有“恶意代码的种类有哪些，能否举例说明？”，下面收集列举了常见的恶意代码种类：

* 普通计算机病毒

* 蠕虫

* 特洛伊木马

* RootKit工具

* 流氓软件

* 间谍软件

* 恶意广告

* 逻辑炸弹

* 僵尸网络

* 网络钓鱼

* 恶意脚本

* 垃圾短信

* 勒索软件

* 移动终端恶意代码

这么多的恶意文件种类其实都会有共性，就如之前书里提到的每天都有成千上万的恶意文件出现，但是最终只有上千种恶意行为。因此在恶意文件这块，与安全解决方案的对抗是一直存在的，书里总结了好几种对抗策略，躲避技术与破坏技术。躲避技术中有躲藏术，恶意文件通常会有驻留启动项的行为，基本上可以在应急响应案例中发现，比如注册表启动项、计划任务、系统服务等策略。在这块案例中除了大家知道的可以利用autoruns进行排查外，还有一些特别的案例，书里提到“偶尔还是会在高级攻击中发现未公开的启动位置，比如我们曾在某个APT高级攻击中发现往系统目录下放一个固定名字的文件，会被操作系统某个服务自动加载。由于这个启动点未被安全软件收录，从而实现躲藏”。想起之前有相关报告提及海莲花组织在入侵活动中会利用受控机器的安全软件的扫描排除白名单进行新增项目来排除自己的策略也类似现在提及的躲藏术。一旦新增排除项完成后，后续机器中的任何扫描都会直接跳过木马所在的位置。

公开案例如“其实海莲花的木马并不难以查杀，很多杀软都可以检测出来，但是他们善用各种不高端但实用的隐藏方式，在本次案例中海莲花就将恶意木马放入用户场景通用的白名单目录下，导致杀软定时扫描时根本发现不了。” 

躲避技术的变形术是接触比较少的场景，变形或者变化自身就是为了避免被查杀。之前较多遇到的是感染型病毒家族，例如Sality或Virut等，这些家族就会在感染完成后会进行多态生成，保证植入的部分存在一定的区别。

躲避技术中的易容术最常遇到的场景是白加黑策略，利用白的exe母体文件（通常携带正常的数字签名）与伪装对应加载dll文件的黑文件进行组合执行来实现伪装，此时能看到的是白的exe母体文件会产生恶意行为。由于是一种比较隐蔽的手法，因此在应急响应排查的时候需要多留意，第一种情况是黑客直接投递的白加黑组合恶意文件，因此在整个系统中会显得很独特，例如奇怪的路径以及只有一个dll文件的情况。第二种情况是黑客发现了某个系统中可以正常使用的应用程序存在dll劫持风险，且可以被植入伪装的dll文件，因此在正常软件安装目录下会存在同名的黑dll文件，由于正常软件安装目录下存在许多正常文件，此时这种情况的排查会比第一种情况困难一些。第三种情况是Lazarus新颖的链式dll侧加载，在一次攻击活动中使用白加黑时增加了一个步骤。合法应用程序从System32目录加载合法的dll文件，然后该dll文件导致从应用程序的目录中加载恶意dll文件。具体而言，CameraSettingsUIHost.exe从System32目录加载dui70.dll文件，然后导致将恶意的DUser.dll文件从应用程序的目录加载到CameraSettingsUIHost.exe进程中。dui70.dll文件是Windows DirectUI Engine，属于操作系统的一部分。

在这种情况下虽然多了一层加载逻辑，但是最终加载的恶意dll文件依然会出现在进程的加载模块句柄中，因此排查时是可以发现的，如笔者做的如下实验，怀疑攻击者后续会进行改进优化来增强隐蔽性。

躲避技术中的办假证和数字签名安全有关，数字签名安全分为伪装或盗用。之前有写过一篇文章简述数字签名安全进行了简单总结。因为数字签名的使用存在明显的成本，以前遇到过红队的木马携带正常的数字签名（推测是购买或冒用为主），因此当发现外部出现盗用情况意味着出现了相关的安全事件，例如因为伪装或冒用而获取的微软认证的数字签名和被APT组织盗取的商用数字签名。

第一个案例如由被微软数字签名签署过的恶意驱动程序

#Rootkit
Another malicious driver signed by Microsoft
🧐cce24ebdd344c8184dbaa0a0c4a65c7d952a11f6608fe23d562a4d1178915eac@JAMESWT_MHT @James_inthe_box @malwrhunterteam

— Skystars (@starsSk87264403) August 3, 2021

第二个案例如被APT27盗用的vmp软件安全提供商使用的数字签名

由于有成千上万的恶意文件，因此在识别数字签名安全这块还需要借助机器与数据的力量或者建设黑白名单库进行防御。

躲避技术中的克隆术属于比较冷门的场景了，具体如“黑客通常会选择一个正常的程序来和恶意程序进行碰撞，完成之后，黑客先放出添加了冗余数据的正常文件，等着安全软件收录并判定该MD5的程序为“好人”，随后再放出相同MD5的恶意程序，安全软件会把它当作之前的那个正常程序，在安全检测时让它通行”。目前虽然可以实现md5的哈希碰撞，但是要完全出现恶意文件的利用场景还是太少了。如果能成功利用，此类威胁的防御确实比较重要，所以现如今都考虑使用sha256作为哈希值进行数据存储，由于密码学应用里都会选择那种经过长时间测试或破解而保持健壮的算法，因此相当于算法升级来避免此类风险。

躲避技术中的劫持术属于底层攻防的范畴，例如Rootkit或Bootkit场景，恶意文件为了隐藏自身需要利用各种策略或冷门技术，在这种场景下分为两种，第一种是安全软件场景，考虑到底层攻防极有可能给系统稳定带来风险，稳定性与易用性是一个工业化产品的首选，其次才是安全功能，因此不敢过多地监测底层的相关痕迹，尽可能在ring3层发现痕迹给拦截清除，在最近几年流行的BYOVD场景下，BYOVD是将存在漏洞的合法驱动投递至目标系统，借助其完成恶意操作的攻击技术。借助滥用的合法驱动签名，攻击者得以绕过DSE（强制驱动签名）机制的限制，在Ring0空间完成各种攻击操作。考虑到本身就是正常的驱动程序而被恶意利用，因此相对来说与安全软件的权限一致，因此如果安全防护软件的自保护能力不够的情况下攻防力量肯定是不对等的，在这类防御中确实需要加强相关能力，才能发现更多的高级别风险（涉及底层往往技术门槛较高，极有概率是高级的攻击者）。

遇到过APT场景下恶意驱动事件，整个过程是APT组织背后的攻击者使用了携带正常数字签名的恶意文件释放并安装驱动，伪装成与系统正常文件相似的驱动文件，同时对相关的恶意行为进行了隐藏，但由于隐藏级别不够，其实对于有一定经验的应急响应人员来说还是可以发现的，首先是系统系统正常驱动的黑白名单库比对，其次是系统目录下可疑文件的排查（这里Rootkit并没有实现隐藏自身文件的功能以及隐藏自身驱动模块的功能），在恶意文件加壳情况下其实也算是一种比较强的特征，更方便我们找到可疑文件。

躲避技术中的寄生术也是很常见的场景，比如恶意文件会伪装成某软件的更新程序，更新程序肯定会有网络外联行为，就可以降低被发现的概率。例如可以直接刷写恶意固件实现Bootkit还有ESP场景下Bootkit案例，这类2015年已有公开的报告，固件Bootkit场景中检测难度更大。

躲避技术的最后一种是修仙术，“在最高级的无文件攻击中，恶意代码只会出现在内存中，实现了对安全软件文件查毒的高维攻击。如果要发现此类攻击，安全软件必须具备内存杀毒能力”。目前所有的依据点都是恶意文件我们可以获取，且能不受限制地分析。但是如果是无文件攻击场景就很困难了，我们很难获取到可供研究的样本。例如利用远处代码执行漏洞而植入内存的恶意文件DoublePulsar，这是一类无文件的恶意驱动，内存杀毒能力确实是比较重要的能力，不仅是恶意文件查杀，还包括漏洞利用痕迹或行为拦截查杀。目前有发现国内厂商安芯网盾有相关内存防御产品，但不知效果如何？内存防御对抗也属于高级威胁方面涉及的点，大多数高明的攻击者都将尽可能隐藏自身驻留内存，一些高级的商业窃密木马如FinSpy将实现内存加密避免被内存杀毒发现痕迹，目前在内存安全的攻防可以说是很重要且困难的。

下一篇写安全技术运营中经常遇到的恶意文件的其余方面

参考材料

解密“海莲花”组织攻击真相 - 与某大型企业共同对抗APT实录

https://mp.weixin.qq.com/s/S8YlF8jZi5CzHlGbSRqZ0A

₿uyer ₿eware: Fake Cryptocurrency Applications Serving as Front for AppleJeus Malware | Volexity

https://www.volexity.com/blog/2022/12/01/buyer-beware-fake-cryptocurrency-applications-serving-as-front-for-applejeus-malware/

原文始发于微信公众号（OnionSec）：安全技术运营的学习与笔记3