sl-cis-cyberthreat-1200x600.jpg

如今,当谈到网络威胁时,大多数人都会想到勒索软件,尤其是加密类型的恶意软件。 随着新冠疫情的爆发和几个主要网络犯罪集团(Maze、REvil、Conti、DarkSide、Avaddon)的出现,一个完整的犯罪生态系统已经形成,目前全球范围内对大型组织的攻击浪潮越来越高。

今年,在发生了一系列备受瞩目的勒索软件事件后,例如对 Colonial Pipeline(美国最大的燃料管道的运营商)、JBS 和 Kaseya 的攻击,以及随后美国和其他当局的严格审查,勒索软件市场发生了一些重大变化:一些团体被摧毁,另一些团体更名。

目前的大多数攻击团体都倾向于在独联体之外活动,尽管如此,该地区还是存在着大量伺机发动攻击的团体。

本文重点介绍了 2021 年上半年在独联体区域内最为活跃的勒索软件木马家族及其技术特征。

统计数据

1.png

2021年1月至7月,独联体区域内遭遇勒索软件攻击的企业数量

2.png

2021 年 1 月至7月,装有卡巴斯基用户遭遇勒索软件攻击的占比

勒索软件家族概况

BigBobRoss/TheDMR

该勒索软件在2018年底开始活跃,目前仍在使用,它的主要传播载体是破解RDP密码。

当启动BigBobRoss时,会显示操作员的技术信息,包括用于后续文件解密的密钥。恶意软件还通过Telegram发送带有此信息的消息。

3.png

BigBobRoss 创建的技术文件

加密后的文件夹内容如下:在每个文件的开头添加攻击者的电子邮件地址和受害者ID,然后是原始名称和扩展名,最后是勒索软件添加的扩展名。

加密文件和攻击者的记录:

此外,每个文件夹中都会添加一个带有攻击者详细信息的注释。

4.png

勒索软件留下的记录

对于加密,该程序使用来自 CryptoPP 密码库的 ECB 模式(简单替换模式)下的 128 位密钥的 AES 对称算法。

PDB 保留有关项目名称的信息,幕后的开发者可能会说俄语,但这个只是猜测。

5.png

可执行文件的PDB信息

Crysis/Dharma

Crysis 是自 2016 年以来已知的一种旧的加密恶意软件。众所周知,它会被停用然后又复活。目前,它仍然活跃。该木马的代码多年来一直保持不变,如今它通过勒索软件即服务 (RaaS) 附属程序进行传播。

Crysis是用 C/C++ 编写的,并在 MS Visual Studio 中编译。该恶意软件在 CBC 模式下使用 AES-256 算法加密文件。启动后,木马会生成一个 256 位 AES 密钥,该密钥使用 RSA-1024 算法加密,攻击者的公钥包含在木马之中。

 6.png

每个文件都使用上述 AES 密钥以及新生成的 128 位初始化向量 (IV) 进行加密。除了加密内容外,加密文件还存储了IV、RSA加密的AES密钥和辅助信息,包括攻击者的标签(一个字符串值)、使用的RSA公钥的SHA1哈希、原始文件名、加密类型(要加密的文件部分对于小文件和大文件的选择不同)和校验和。

7.png

Crysis赎金记录

典型的Crysis攻击载体是未经授权的 RDP 访问。攻击者破解凭据(通过字典/暴力攻击或从其他攻击者那里购买的现成列表),远程连接到受害者的计算机,并手动运行木马。

Phobos/Eking

该勒索软件自 2017 年以来一直存在,在概念层面(代码结构、开发人员使用的方法),Phobos 在许多方面与 Crysis 相似。这表明木马程序的开发者是同一个,或者 Phobos 的开发者熟悉Crysis的工作原理。但是,我们发现没有直接借用代码;换句话说,这些是从不同来源组装的不同木马家族。

与大多数现代勒索软件一样,Phobos 是通过 RaaS 附属程序传播的。感染的主要载体是未经授权的 RDP 访问。

Phobos 是用 C/C++ 编写的,并在 MS Visual Studio 中编译。它使用 AES-256-CBC 算法加密受害者的文件,而 AES 密钥使用恶意软件对象中包含的 RSA-1024 公钥加密。

8.png

Phobos 赎金记录

Cryakl/CryLock

Cryakl 可能是本文介绍的最古老的勒索软件。第一个版本是在 2014 年 4 月检测到的。然而,在这个木马的现代版本中,似乎没有留下一行代码。 Cryakl 已被多次重写,并且每个新版本都会引入一些新功能。

它通过附属计划传播。目前,其最常见的攻击载体是通过 RDP。为方便攻击者,木马支持图形界面。操作员在程序窗口中手动配置必要的设置。

9.png

Cryakl 设置窗口

Cryakl 是用 Delphi 编写的。 Cryakl 的现代版本使用自定义对称密码来加密受害者的文件,并使用 RSA 算法来加密密钥。

当前版本的 Cryakl 的一个有趣功能是对归档格式的高级处理,这在其他勒索软件中是没有的。

归档可能很大,对它们进行完整的加密需要很长时间。如果只对文件的任意部分进行加密,则可以在不解密的情况下恢复部分内容。

Cryakl 具有处理 ZIP、7z、TAR、CAB 和 RAR(旧版本和 RAR5)格式的专门程序。它会解析每一种格式,只加密归档的关键部分,提供高性能并防止在不解密的情况下恢复数据。

10.png

分析 ZIP 格式的部分程序

11.png

Cryakl 赎金记录

CryptConsole

CryptConsole 于 2017 年 1 月首次被发现,今天仍然运行活跃。它是用 C# 编写的,并使用 .NET 库进行加密,传播的主要载体是破解 RDP 密码。

12.png

CryptConsole记录

对于加密,生成两个密钥和 IV 对,这些信息被写入一个文本文件,以及一个大小参数(反映需要加密多少用户文件),并放置在桌面上。这个文本文件的名称是一个40个字符的字符串,与用户的唯一标识符(注释中的个人 ID)相匹配。假设恶意软件操开发者通过 RDP 获得访问权限,运行勒索软件并为自己保存此文件,然后将其从受害者的设备中删除。这可能证明可以恢复文件,有趣的是,文件加密部分的大小(size参数)是 [5485760, 10485760] 范围内的一个随机值。

13.png

包含勒索软件留下的密钥的文件

其加密方案也令人好奇。如上所述,勒索软件会生成两个随机对:key+IV 和 key2+IV2。然后将文件大小与之前生成的随机大小值进行比较。如果文件大于size,则只对文件中小于或等于该值的部分进行加密,在此之前将一个size字节的随机数据缓冲区写入文件。

14.png

生成key/IV 对、ID 和size

使用对称 AES 算法执行加密。首先,文件的 size 字节块使用 key 和 IV 进行加密,然后将加密的缓冲区反转并再次加密,这次使用 key2 和 IV2,这就是双重加密方案的工作原理。

15.png

小文件双重加密方案

如上所述,大文件首先被任意大小字节的数据填充,这之后才能附加加密数据。

16.png

任意数据写入的双重加密方案

Fonix/XINOF

Fonix 勒索软件于2020 年夏天首次被发现,2021 年 1 月,其创建者宣布关闭该项目,甚至发布了主密钥,我们可以用它来为该木马的受害者构建解密器。

然而,Fonix并没因此消停,几个月后(2021 年 6 月),我们就检测到新版本 Fonix 的攻击,该版本就没有使用旧的主密钥。

此版本的 Fonix 模仿Crysis和 Phobos 木马,对加密文件使用相同的扩展名和命名方案。

如果受早期版本 Fonix 影响的文件的名称类似于 picture.jpg.Email=[[email protected]]ID=[B49D8EF5].XINOF,现在,它们与Crysis(picture.jpg.id-523E8573.[[email protected]].harma)或Phobos(picture.jpg.ID-70AB2875.[[email protected]].eking)加密的文件名称没有区别。

保存在木马样本中的项目 PDB 文件的路径同样涉及故意屏蔽:“DharmaVersion”行明确指向 Dharma 家族(Crysis勒索软件的另一个名称)。

17.png

PDB路径

Fonix 使用 CryptoPP 库以 C++ 编写,并在 MS Visual Studio 中被编译为一个 64 位可执行文件。它使用 RaaS 方案进行传播,主要通过带有恶意附件的垃圾邮件进入受害者系统。

每次感染后,勒索软件都会通过 Telegram 向其运营商发送通知,顺便说一句,这并不是什么新鲜事,几年前就出现过。

18.png

用Telegram发送通知

在感染主机后,Fonix 还会通过 IP 检查受害者的地理位置,如果在伊朗启动,则会在不加密的情况下停止其活动。

19.png

Fonix会检查受害者的地理位置

为了加密用户文件,它使用 ChaCha 或 Salsa 算法(取决于文件大小)。 ChaCha/Salsa 密钥由 RSA 使用木马启动时生成的会话公钥进行加密。会话私钥由 RSA 使用恶意软件对象中包含的公共主密钥进行加密。

Fonix 的早期版本有自己的勒索信。

20.png

Fonix 勒索信(早期版本)

与此同时,在最近的样本中,我们看到某些版本的Crysis和Phobos的勒索信被复制。

21.png

Fonix 勒索信(现代版)

Limbozar/VoidCrypt

该勒索软件出现在 2019 年年中,它的某些版本也被称为 Limbo、Legion、Odveta 和 Ouroboros。 Limozar 通过附属计划 (RaaS) 传播。目前,主要的传播载体是未经授权的 RDP 访问。 Limozar 是用 C++ 编写的,在 MS Visual Studio 中编译,并使用 CryptoPP 库来实现加密功能。

在整个家族的历史中,其密码方案已经改变了几次。当Limbozar启动时,现代版本的Limbozar生成一个RSA-2048会话密钥对,然后是一个256位密钥和一个96位初始化向量,用于在GCM模式下的AES算法。RSA会话私钥使用AES算法加密并保存在本地。接下来,AES的key+IV对使用木马对象中包含的几个公共RSA主密钥之一进行加密,并且也保存到本地驱动器中。

在这个准备阶段之后,Limbozar 搜索受害者的文件并使用 AES-GCM 算法对其进行加密,并为每个文件生成一个唯一的key+IV 对,然后使用 RSA 会话公钥进行加密。

加密后,恶意软件将攻击者的要求保存在 Decrypt-info.txt 文件中。

22.png

Limbozar 赎金记录

完全加密后,Limbosar 还会使用 POST 请求向其 C&C 服务器发送有关新受害者的通知。为了实现网络通信,使用了 SFML 库(libsfml-network)。

23.png

关于新版Limbozar感染的通知

Thanos/Hakbit

Thanos 于 2020 年 4 月下旬开始活跃,尽管有关它的信息首次出现是在1月份当时它以RaaS的形式出现在一个黑客论坛上。这个勒索软件是用c#编写的。根据我们掌握的信息,它的主要传播载体是破解 RDP 密码。

24.png

被感染电脑的桌面壁纸,显示一张勒索信

由于传播模型是 RaaS,勒索软件是通过构建器传播的,从而可以自定义木马本身及其解密器。

构建器中有许多不同的设置:基本的(加密文件的扩展名、勒索信的名称和内容、付款地址)和更高级的(代码混淆、自我删除、禁用 Windows Defender、绕过反恶意软件扫描接口 (AMSI)) 、解锁被其他进程占用的文件、保护勒索软件进程、防止休眠、执行延迟、大文件快速加密模式、设置要加密文件的扩展名、选择受害者通知方法)。泄露的构造函数可以在网上找到。最有可能的是,它是由购买它的运营商上传的。为了保护,它具有内置的 HWID 检查,表明它是为操作员的特定设备组装的。

解密器可以使用用户 ID 解密文件,用户 ID 是对称加密算法的 RSA 加密密钥(不同版本有不同的对称算法)。

25.png

Thanos 的解密器

勒索软件可以使用一系列加密方案。在勒索软件的各种样本中,我们遇到了以下情况:

适用于所有文件的密钥:Salsa20 加密;

适用于所有文件的不同密钥:Salsa20 加密;

通过PBKDF2函数适用于所有文件的密钥:AES-256 CBC 加密;

通过 PBKDF2 函数适用于所有文件的密钥(小文件 1000 次迭代,大于15 MB大文件50000 次迭代),然后是 AES-256 CBC 加密;

下面给出了其中一种加密方案(静态密钥 + PBKDF2 + AES-256 CBC)和代码混淆方法的说明。混淆相当弱,这使得恢复原始代码成为可能。

26.png

用于加密的代码块之一

勒索信没有太大区别,像往常一样,目的是留下联系方式并恐吓用户。

27.png

Thanos赎金记录

Thanos实施了一种相当灵活的攻击方案,允许操作员独立选择勒索软件的功能并生成它以满足他们的特定需求。

XMRLocker

XMRLocker 于 2020 年 8 月上旬首次被发现。它是用 C# 编写的,并使用 .NET 库进行加密。

使用生成的随机长度为65-101个字符的密码执行加密,一个固定的字母表,包括英文大小写字母和一些特殊字符,用于生成密码。

28.png

在XMRLocker中生成密码

加密使用AES算法,密钥长度为256位,在CFB模式下使用PKCS7填充。预生成的密码通过PBKDF2函数传递,迭代次数为50000次,并将结果转换为密钥和IV进行进一步加密。PBKDF2使用一个32字节的随机盐值,它被写入每个文件的开头。为所有文件生成一个密钥。它被保存在一个名为HWID的文本文件中,该文件被发送到托管在Tor网络上的C&C服务器,然后删除。

29.png

加密函数

加密后,设备关闭。下次启动时,用户会看到对发生的事情和攻击者详细信息的介绍。

30.png

启动后的消息

像往常一样,勒索软件说明包含联系方式和 ID。唯一令人惊讶的变化是“使用 Base-64 算法加密的文件”这个词,因为这不是一种加密算法,并且该勒索软件根本不使用它。

31.png

勒索信

总结

在独联体,既有知名的,也有相对较新的面向企业的勒索软件。这些恶意软件中有许多是新出现的,也有一些已经退出了市场。勒索软件的加密技术也越来越奇怪,比如CryptConsole中的双重加密和Cryakl中的归档进程(Archive Process) 处理。

虽然恶意软件的传播载体不同,但目前针对独联体企业的勒索软件威胁大多通过RDP渗透受害者的网络。因此,为域帐户创建强大的密码并定期更改它们是很重要的。另外,建议屏蔽互联网上的RDP访问,使用VPN连接企业网络。

sl-cis-cyberthreat-1200x600.jpg

如今,当谈到网络威胁时,大多数人都会想到勒索软件,尤其是加密类型的恶意软件。 随着新冠疫情的爆发和几个主要网络犯罪集团(Maze、REvil、Conti、DarkSide、Avaddon)的出现,一个完整的犯罪生态系统已经形成,目前全球范围内对大型组织的攻击浪潮越来越高。

今年,在发生了一系列备受瞩目的勒索软件事件后,例如对 Colonial Pipeline(美国最大的燃料管道的运营商)、JBS 和 Kaseya 的攻击,以及随后美国和其他当局的严格审查,勒索软件市场发生了一些重大变化:一些团体被摧毁,另一些团体更名。

目前的大多数攻击团体都倾向于在独联体之外活动,尽管如此,该地区还是存在着大量伺机发动攻击的团体。

本文重点介绍了 2021 年上半年在独联体区域内最为活跃的勒索软件木马家族及其技术特征。

统计数据

1.png

2021年1月至7月,独联体区域内遭遇勒索软件攻击的企业数量

2.png

2021 年 1 月至7月,装有卡巴斯基用户遭遇勒索软件攻击的占比

勒索软件家族概况

BigBobRoss/TheDMR

该勒索软件在2018年底开始活跃,目前仍在使用,它的主要传播载体是破解RDP密码。

当启动BigBobRoss时,会显示操作员的技术信息,包括用于后续文件解密的密钥。恶意软件还通过Telegram发送带有此信息的消息。

3.png

BigBobRoss 创建的技术文件

加密后的文件夹内容如下:在每个文件的开头添加攻击者的电子邮件地址和受害者ID,然后是原始名称和扩展名,最后是勒索软件添加的扩展名。

加密文件和攻击者的记录:

此外,每个文件夹中都会添加一个带有攻击者详细信息的注释。

4.png

勒索软件留下的记录

对于加密,该程序使用来自 CryptoPP 密码库的 ECB 模式(简单替换模式)下的 128 位密钥的 AES 对称算法。

PDB 保留有关项目名称的信息,幕后的开发者可能会说俄语,但这个只是猜测。

5.png

可执行文件的PDB信息

Crysis/Dharma

Crysis 是自 2016 年以来已知的一种旧的加密恶意软件。众所周知,它会被停用然后又复活。目前,它仍然活跃。该木马的代码多年来一直保持不变,如今它通过勒索软件即服务 (RaaS) 附属程序进行传播。

Crysis是用 C/C++ 编写的,并在 MS Visual Studio 中编译。该恶意软件在 CBC 模式下使用 AES-256 算法加密文件。启动后,木马会生成一个 256 位 AES 密钥,该密钥使用 RSA-1024 算法加密,攻击者的公钥包含在木马之中。

 6.png

每个文件都使用上述 AES 密钥以及新生成的 128 位初始化向量 (IV) 进行加密。除了加密内容外,加密文件还存储了IV、RSA加密的AES密钥和辅助信息,包括攻击者的标签(一个字符串值)、使用的RSA公钥的SHA1哈希、原始文件名、加密类型(要加密的文件部分对于小文件和大文件的选择不同)和校验和。

7.png

Crysis赎金记录

典型的Crysis攻击载体是未经授权的 RDP 访问。攻击者破解凭据(通过字典/暴力攻击或从其他攻击者那里购买的现成列表),远程连接到受害者的计算机,并手动运行木马。

Phobos/Eking

该勒索软件自 2017 年以来一直存在,在概念层面(代码结构、开发人员使用的方法),Phobos 在许多方面与 Crysis 相似。这表明木马程序的开发者是同一个,或者 Phobos 的开发者熟悉Crysis的工作原理。但是,我们发现没有直接借用代码;换句话说,这些是从不同来源组装的不同木马家族。

与大多数现代勒索软件一样,Phobos 是通过 RaaS 附属程序传播的。感染的主要载体是未经授权的 RDP 访问。

Phobos 是用 C/C++ 编写的,并在 MS Visual Studio 中编译。它使用 AES-256-CBC 算法加密受害者的文件,而 AES 密钥使用恶意软件对象中包含的 RSA-1024 公钥加密。

8.png

Phobos 赎金记录

Cryakl/CryLock

Cryakl 可能是本文介绍的最古老的勒索软件。第一个版本是在 2014 年 4 月检测到的。然而,在这个木马的现代版本中,似乎没有留下一行代码。 Cryakl 已被多次重写,并且每个新版本都会引入一些新功能。

它通过附属计划传播。目前,其最常见的攻击载体是通过 RDP。为方便攻击者,木马支持图形界面。操作员在程序窗口中手动配置必要的设置。

9.png

Cryakl 设置窗口

Cryakl 是用 Delphi 编写的。 Cryakl 的现代版本使用自定义对称密码来加密受害者的文件,并使用 RSA 算法来加密密钥。

当前版本的 Cryakl 的一个有趣功能是对归档格式的高级处理,这在其他勒索软件中是没有的。

归档可能很大,对它们进行完整的加密需要很长时间。如果只对文件的任意部分进行加密,则可以在不解密的情况下恢复部分内容。

Cryakl 具有处理 ZIP、7z、TAR、CAB 和 RAR(旧版本和 RAR5)格式的专门程序。它会解析每一种格式,只加密归档的关键部分,提供高性能并防止在不解密的情况下恢复数据。

10.png

分析 ZIP 格式的部分程序

11.png

Cryakl 赎金记录

CryptConsole

CryptConsole 于 2017 年 1 月首次被发现,今天仍然运行活跃。它是用 C# 编写的,并使用 .NET 库进行加密,传播的主要载体是破解 RDP 密码。

12.png

CryptConsole记录

对于加密,生成两个密钥和 IV 对,这些信息被写入一个文本文件,以及一个大小参数(反映需要加密多少用户文件),并放置在桌面上。这个文本文件的名称是一个40个字符的字符串,与用户的唯一标识符(注释中的个人 ID)相匹配。假设恶意软件操开发者通过 RDP 获得访问权限,运行勒索软件并为自己保存此文件,然后将其从受害者的设备中删除。这可能证明可以恢复文件,有趣的是,文件加密部分的大小(size参数)是 [5485760, 10485760] 范围内的一个随机值。

13.png

包含勒索软件留下的密钥的文件

其加密方案也令人好奇。如上所述,勒索软件会生成两个随机对:key+IV 和 key2+IV2。然后将文件大小与之前生成的随机大小值进行比较。如果文件大于size,则只对文件中小于或等于该值的部分进行加密,在此之前将一个size字节的随机数据缓冲区写入文件。

14.png

生成key/IV 对、ID 和size

使用对称 AES 算法执行加密。首先,文件的 size 字节块使用 key 和 IV 进行加密,然后将加密的缓冲区反转并再次加密,这次使用 key2 和 IV2,这就是双重加密方案的工作原理。

15.png

小文件双重加密方案

如上所述,大文件首先被任意大小字节的数据填充,这之后才能附加加密数据。

16.png

任意数据写入的双重加密方案

Fonix/XINOF

Fonix 勒索软件于2020 年夏天首次被发现,2021 年 1 月,其创建者宣布关闭该项目,甚至发布了主密钥,我们可以用它来为该木马的受害者构建解密器。

然而,Fonix并没因此消停,几个月后(2021 年 6 月),我们就检测到新版本 Fonix 的攻击,该版本就没有使用旧的主密钥。

此版本的 Fonix 模仿Crysis和 Phobos 木马,对加密文件使用相同的扩展名和命名方案。

如果受早期版本 Fonix 影响的文件的名称类似于 picture.jpg.Email=[[email protected]]ID=[B49D8EF5].XINOF,现在,它们与Crysis(picture.jpg.id-523E8573.[[email protected]].harma)或Phobos(picture.jpg.ID-70AB2875.[[email protected]].eking)加密的文件名称没有区别。

保存在木马样本中的项目 PDB 文件的路径同样涉及故意屏蔽:“DharmaVersion”行明确指向 Dharma 家族(Crysis勒索软件的另一个名称)。

17.png

PDB路径

Fonix 使用 CryptoPP 库以 C++ 编写,并在 MS Visual Studio 中被编译为一个 64 位可执行文件。它使用 RaaS 方案进行传播,主要通过带有恶意附件的垃圾邮件进入受害者系统。

每次感染后,勒索软件都会通过 Telegram 向其运营商发送通知,顺便说一句,这并不是什么新鲜事,几年前就出现过。

18.png

用Telegram发送通知

在感染主机后,Fonix 还会通过 IP 检查受害者的地理位置,如果在伊朗启动,则会在不加密的情况下停止其活动。

19.png

Fonix会检查受害者的地理位置

为了加密用户文件,它使用 ChaCha 或 Salsa 算法(取决于文件大小)。 ChaCha/Salsa 密钥由 RSA 使用木马启动时生成的会话公钥进行加密。会话私钥由 RSA 使用恶意软件对象中包含的公共主密钥进行加密。

Fonix 的早期版本有自己的勒索信。

20.png

Fonix 勒索信(早期版本)

与此同时,在最近的样本中,我们看到某些版本的Crysis和Phobos的勒索信被复制。

21.png

Fonix 勒索信(现代版)

Limbozar/VoidCrypt

该勒索软件出现在 2019 年年中,它的某些版本也被称为 Limbo、Legion、Odveta 和 Ouroboros。 Limozar 通过附属计划 (RaaS) 传播。目前,主要的传播载体是未经授权的 RDP 访问。 Limozar 是用 C++ 编写的,在 MS Visual Studio 中编译,并使用 CryptoPP 库来实现加密功能。

在整个家族的历史中,其密码方案已经改变了几次。当Limbozar启动时,现代版本的Limbozar生成一个RSA-2048会话密钥对,然后是一个256位密钥和一个96位初始化向量,用于在GCM模式下的AES算法。RSA会话私钥使用AES算法加密并保存在本地。接下来,AES的key+IV对使用木马对象中包含的几个公共RSA主密钥之一进行加密,并且也保存到本地驱动器中。

在这个准备阶段之后,Limbozar 搜索受害者的文件并使用 AES-GCM 算法对其进行加密,并为每个文件生成一个唯一的key+IV 对,然后使用 RSA 会话公钥进行加密。

加密后,恶意软件将攻击者的要求保存在 Decrypt-info.txt 文件中。

22.png

Limbozar 赎金记录

完全加密后,Limbosar 还会使用 POST 请求向其 C&C 服务器发送有关新受害者的通知。为了实现网络通信,使用了 SFML 库(libsfml-network)。

23.png

关于新版Limbozar感染的通知

Thanos/Hakbit

Thanos 于 2020 年 4 月下旬开始活跃,尽管有关它的信息首次出现是在1月份当时它以RaaS的形式出现在一个黑客论坛上。这个勒索软件是用c#编写的。根据我们掌握的信息,它的主要传播载体是破解 RDP 密码。

24.png

被感染电脑的桌面壁纸,显示一张勒索信

由于传播模型是 RaaS,勒索软件是通过构建器传播的,从而可以自定义木马本身及其解密器。

构建器中有许多不同的设置:基本的(加密文件的扩展名、勒索信的名称和内容、付款地址)和更高级的(代码混淆、自我删除、禁用 Windows Defender、绕过反恶意软件扫描接口 (AMSI)) 、解锁被其他进程占用的文件、保护勒索软件进程、防止休眠、执行延迟、大文件快速加密模式、设置要加密文件的扩展名、选择受害者通知方法)。泄露的构造函数可以在网上找到。最有可能的是,它是由购买它的运营商上传的。为了保护,它具有内置的 HWID 检查,表明它是为操作员的特定设备组装的。

解密器可以使用用户 ID 解密文件,用户 ID 是对称加密算法的 RSA 加密密钥(不同版本有不同的对称算法)。

25.png

Thanos 的解密器

勒索软件可以使用一系列加密方案。在勒索软件的各种样本中,我们遇到了以下情况:

适用于所有文件的密钥:Salsa20 加密;

适用于所有文件的不同密钥:Salsa20 加密;

通过PBKDF2函数适用于所有文件的密钥:AES-256 CBC 加密;

通过 PBKDF2 函数适用于所有文件的密钥(小文件 1000 次迭代,大于15 MB大文件50000 次迭代),然后是 AES-256 CBC 加密;

下面给出了其中一种加密方案(静态密钥 + PBKDF2 + AES-256 CBC)和代码混淆方法的说明。混淆相当弱,这使得恢复原始代码成为可能。

26.png

用于加密的代码块之一

勒索信没有太大区别,像往常一样,目的是留下联系方式并恐吓用户。

27.png

Thanos赎金记录

Thanos实施了一种相当灵活的攻击方案,允许操作员独立选择勒索软件的功能并生成它以满足他们的特定需求。

XMRLocker

XMRLocker 于 2020 年 8 月上旬首次被发现。它是用 C# 编写的,并使用 .NET 库进行加密。

使用生成的随机长度为65-101个字符的密码执行加密,一个固定的字母表,包括英文大小写字母和一些特殊字符,用于生成密码。

28.png

在XMRLocker中生成密码

加密使用AES算法,密钥长度为256位,在CFB模式下使用PKCS7填充。预生成的密码通过PBKDF2函数传递,迭代次数为50000次,并将结果转换为密钥和IV进行进一步加密。PBKDF2使用一个32字节的随机盐值,它被写入每个文件的开头。为所有文件生成一个密钥。它被保存在一个名为HWID的文本文件中,该文件被发送到托管在Tor网络上的C&C服务器,然后删除。

29.png

加密函数

加密后,设备关闭。下次启动时,用户会看到对发生的事情和攻击者详细信息的介绍。

30.png

启动后的消息

像往常一样,勒索软件说明包含联系方式和 ID。唯一令人惊讶的变化是“使用 Base-64 算法加密的文件”这个词,因为这不是一种加密算法,并且该勒索软件根本不使用它。

31.png

勒索信

总结

在独联体,既有知名的,也有相对较新的面向企业的勒索软件。这些恶意软件中有许多是新出现的,也有一些已经退出了市场。勒索软件的加密技术也越来越奇怪,比如CryptConsole中的双重加密和Cryakl中的归档进程(Archive Process) 处理。

虽然恶意软件的传播载体不同,但目前针对独联体企业的勒索软件威胁大多通过RDP渗透受害者的网络。因此,为域帐户创建强大的密码并定期更改它们是很重要的。另外,建议屏蔽互联网上的RDP访问,使用VPN连接企业网络。

我们将在本文中介绍攻击示例中被利用的 ProxyShell 漏洞,并深入探讨在涉及这些 Web Shell 攻击的四个独立示例中使用的Post-exploitation示例。

趋势科技 Managed XDR (MDR) 团队最近观察到与 ProxyShell 相关的服务器端攻击示例激增。这些攻击发生在中东的不同部门,最常在使用 Microsoft Exchange 内部部署的环境中出现。

研究人员发现部署勒索软件是中东地区常见的攻击方式。这表明攻击者已经开始倾向于使用与 ProxyShell 相关的漏洞,以便建立对组织系统的初始访问权限,并有可能发起勒索软件攻击。

通过使用在初始访问技术上有重叠的攻击样本,研究人员最近发现了一系列针对中东地区的攻击。这些攻击都有一个共同点,即利用易受攻击的 ProxyShell 服务器在目标网络上获得最初的立足点,其根源都来自于产生可疑进程的 IIS 工作进程。

通过观察 Trend Micro Vision One 平台上的 web shell 活动,并通过分析 Internet Information Services (IIS) 进程 w3wp.exe 创建的进程树,研究人员能够确定与不同进程相关联的进程顺序。通过 Vision One 平台,一些攻击在感染链的早期被中断,之后研究人员将这些攻击与其他类似的攻击进行了比较。

对 ProxyShell 漏洞利用的观察

ProxyShell 在这些攻击中的利用涉及三个漏洞:CVE-2021-34473、CVE-2021-34523 和 CVE-2021-31207,前两个在 2021 年 7 月被修复,最后一个在 2021 年 5 月被修复。这些漏洞可能导致任意写入文件,攻击者可以利用这些文件在目标交换服务器上上传 web shell。

攻击者最初试图通过扫描释放的 web shell 来启动攻击,研究人员假设这些 web shell 是通过漏洞利用提前释放的。但尝试失败了,因为当研究人员尝试访问它们时,文件显示了 404 错误代码。

1.webp.jpg

扫描 web shell

CVE-2021-34473:预认证路径混淆

   2021年8月5日,安全研究员在国外安全会议上公开了CVE-2021-34473 Microsoft Exchange Server 远程代码执行漏洞分析及其POC。攻击者利用该漏洞可绕过相关权限验证,进而配合其他漏洞可执行任意代码,控制Microsoft Exchange Server。

该漏洞滥用了 Explicit Logon URL 的 URL 规范化,如果 URL 后缀为 autodiscover/autodiscover.json,则登录电子邮件将从 URL 中删除。这允许作为 Exchange 计算机帐户 (NT AUTHORITY\SYSTEM) 进行任意后端 URL 访问。

2.png

利用 CVE-2021-34473

自动发现服务被滥用以泄露已知用户的专有名称 (DN),这是 Microsoft Exchange 内部使用的一种地址格式。然后,消息应用程序编程接口 (MAPI) 被滥用来泄露用户的安全标识符 (SID)。

CVE-2021-34523:Exchange PowerShell 后端权限提升

Microsoft Exchange 具有 PowerShell 远程处理功能,可用于阅读和发送电子邮件。 NT AUTHORITY\SYSTEM 无法使用此功能,因为它没有邮箱,但是,可以通过 X-Rps-CAT 查询字符串参数提供后端 /powershell,以防使用先前的漏洞直接访问它,即将被反序列化并用于恢复用户身份。

攻击者可以使用此技术来模拟本地管理员以运行 PowerShell 命令。

3.png

使用本地管理员帐户 [email protected] 及其 SID 的攻击者

CVE-2021-31207:授权后任意文件写入

此漏洞利用 New-MailboxExportRequest PowerShell 命令将用户邮箱导出到任意文件位置,该文件位置可用于在Exchange服务器上编写shell。

4.png

导入后访问 web shell

web shell 作为邮件导入到administrator[@]xxx草稿邮箱中。然后将其导出到 c:/inetpub/wwwroot/aspnet_client/puqjc.aspx,之后它被访问并返回200个代码。对文件系统时间线的分析显示相同:puqjc.aspx 文件与恶意 Web 连接同时创建(UTC 下午 2:00)

5.png

显示文件 puqjc.aspx 创建的系统时间线

Post-exploitation示例

Web shell 是用 Web 开发编程语言(例如 ASP、JSP)编写的一段代码,攻击者可以将其放入 Web 服务器以获得远程访问权限以及执行任意代码和命令以满足其目标的能力。一旦web shell被成功地释放到受害者的服务器,它就可以允许远程攻击者执行各种任务,例如窃取数据或释放其他恶意工具。

通过对攻击样本的分析,研究人员能够识别出不同攻击者使用的 Web shell 的几种变体。所有示例的扫描和利用阶段都相同,但利用后的活动及其影响各不相同。

以下部分会详细介绍研究人员在 2021 年 8 月和 9 月发生的四起不同示例中分析的Post-exploitation细节。虽然其中一些示例在感染期间具有某些相同的行为,但它们的Post-exploitation却各不相同。

示例1

第一个 web shell

6.png

显示 exec_code 查询参数的代码

在研究人员处理的第一个示例中,他们发现攻击中使用的 web shell 使用 exec_code 查询参数来执行 ASP 代码。在成功访问命令与控制 (C&C) 服务器后,它执行命令以收集有关受感染系统的基本信息。

7.png

此外,web shell 还执行 PowerShell 命令,并下载并执行其他恶意软件。

8.png

执行 PowerShell 命令并下载其他恶意软件

rundll.bat

Web shell 包含一个脚本,该脚本会阻止来自特定供应商的安全软件,然后禁用系统的防火墙。

9.png

显示脚本如何终止安全软件的代码

然后它执行一个 PowerShell 编码的 base64 脚本,该脚本下载另一个混淆的 PowerShell 脚本,然后执行。该脚本是 CobaltStrike 恶意软件家族的一部分,它能够提供对受感染计算机的后门访问。

10.png

解码后的PowerShell命令下载并执行Cobalt Strike

11.png

来自Cobalt Strike的代码混淆了PowerShell

研究人员还注意到攻击背后的攻击者执行脚本来阻止特定进程并清除 PowerShell Windows 示例日志。

12.png

旨在终止 PowerShell 相关进程的脚本

Liferay 内容管理系统

IP 地址 212.84.32[.]13 和 103.25.196[.]33 是使用 Liferay 内容管理系统 (CMS) 的服务器。这些似乎是该软件的受攻击版本,用于在 CMS 使用的默认端口(80、443、8080)以外的不同端口上托管Post-exploitation恶意负载。

13.png

在 IP 地址 212.84.32[.]13 和 103.25.196[.]33 上找到的 Liferay CMS 版本的属性

两台服务器都使用Liferay CE 6.2版本,该版本容易受到 CVE-2020-7961(可能导致远程代码执行)的攻击。

示例2

与第一个示例类似,攻击者通过 web shell 访问服务器,然后开始收集系统的基本信息。然而,第二个示例使用 PowerShell 进行不同的Post-exploitation活动。

研究人员的分析表明 Wget 请求被发送到具有高编号端口的 URL。不幸的是,研究人员没有关于下载内容的信息,因为在分析的时候URL已经失效了。

14.png

执行以下命令以收集基本系统信息:

15.png

然后使用以下命令复制 web shell 并删除原始条目:

16.png

ipconfig 命令作为 wget 请求的参数执行。

以下代码显示了 Powershell 编码(顶部)和解码(底部)命令:

17.png

Mimikatz 是一种允许用户查看和保存凭据的工具,通常用于后期开发活动,由 PowerShell 下载,如以下编码(顶部)和解码(底部)命令所示:

18.png

然后 web shell 下载了一个额外的 .aspx web shell 并为其添加时间戳以进一步在系统中伪装自己,如下代码所示:

19.png

然后将 web shell 移动到 OWA 目录,并带有以下时间戳:

20.png

几分钟后,额外的 DLL 被创建,后来被验证为 w3wp.exe 或 UMWorkerProcess.exe 创建的 web shell 文件。

21.png

在此示例中,研究人员发现攻击者使用了以下恶意组件和恶意软件:

22.png

其他 web shell

在研究人员对这个样本的调查过程中,他们在 ASP.net 页面中发现了一个用 C# 编写的特定 web shell 变体,这很不寻常,因为研究人员发现的大多数 web shell 都是用 PHP 编写的。这类似于 KRYPTON 组织在其活动中使用的自定义 web shell。 DLL web shell 在同一系统中也有相应的 ASPX 版本。

23.png

用 C# 编写的 web shell

24.webp.jpg

在 CMD 中执行 Base64 命令的 C# web shell 函数

25.webp.jpg

Web shell只响应已知的输入,否则它将响应错误代码404

示例3

该示例在凭证转储技术和系统内横向移动方面与前两起示例不同。在次示例中使用Microsoft Process Dump工具转储LSSAS并提取哈希。

26.png

主动式攻击期间 procedump.exe 的执行

在横向移动阶段检测到 Windows 实用程序 PsExec,攻击者使用它来访问远程计算机和服务器,以释放和执行新的后门恶意软件。

使用哈希传递攻击技术访问远程服务器和计算机,然后删除新的恶意软件组件以创建持久性。

27.webp.jpg

使用哈希传递技术进行远程访问

以下恶意软件已投放到受感染的计算机上:

28.png

然后通过计划任务在远程计算机上创建持久性以保持后门运行。

29.png

通过计划任务创建持久性

示例4

该示例具有一种有趣的凭据转储技术,特别是通过 NT 目录服务实用程序转储数据库:

30.png

这是使用 ProxyShell 实例的Post-exploitation示例。释放web shell 后,cmd.exe 和 powershell.exe 用于在受影响的系统上执行命令。

31.webp.jpg

Trend Micro Vision One ™ 控制台显示使用 ProxyShell的Post-exploitation示例

安全建议

对于研究人员遇到的示例,应该注意的是,受影响的 Microsoft Exchange 服务器都没有被其各自的 IT 团队有意或无意地修复。虽然缓解控制,例如基于主机或基于网络的攻击防御系统 (HIPS/NIPS) 的实施,可以应用于这些服务器,但应该注意的是,这些控制只会在进行任何实际修复之前,为 IT 团队提供防护空间,允许他们触发适当的变更管理控制。

另外,即使在攻击后修复了 Microsoft Exchange 服务器,它仍具有活动的 web shell。这意味着应彻底检查因与 ProxyShell 相关的漏洞而受到攻击的服务器是否存在任何恶意活动,因为 Web Shell 可能已经存在并且可能继续运行。活跃的Web Shell仍然可以让攻击者继续攻击他们选择的目标,例如勒索软件感染、加密货币挖掘和数据窃取。

对公开的服务器进行适当的分割,并不断监控其行为即启动的进程、反恶意软件违规或网络流量配置文件。例如,观察到内部网络扫描、SMB 流量或其他从未见过的异常流量可能表明服务器已被攻击。

我们将在本文中介绍攻击示例中被利用的 ProxyShell 漏洞,并深入探讨在涉及这些 Web Shell 攻击的四个独立示例中使用的Post-exploitation示例。

趋势科技 Managed XDR (MDR) 团队最近观察到与 ProxyShell 相关的服务器端攻击示例激增。这些攻击发生在中东的不同部门,最常在使用 Microsoft Exchange 内部部署的环境中出现。

研究人员发现部署勒索软件是中东地区常见的攻击方式。这表明攻击者已经开始倾向于使用与 ProxyShell 相关的漏洞,以便建立对组织系统的初始访问权限,并有可能发起勒索软件攻击。

通过使用在初始访问技术上有重叠的攻击样本,研究人员最近发现了一系列针对中东地区的攻击。这些攻击都有一个共同点,即利用易受攻击的 ProxyShell 服务器在目标网络上获得最初的立足点,其根源都来自于产生可疑进程的 IIS 工作进程。

通过观察 Trend Micro Vision One 平台上的 web shell 活动,并通过分析 Internet Information Services (IIS) 进程 w3wp.exe 创建的进程树,研究人员能够确定与不同进程相关联的进程顺序。通过 Vision One 平台,一些攻击在感染链的早期被中断,之后研究人员将这些攻击与其他类似的攻击进行了比较。

对 ProxyShell 漏洞利用的观察

ProxyShell 在这些攻击中的利用涉及三个漏洞:CVE-2021-34473、CVE-2021-34523 和 CVE-2021-31207,前两个在 2021 年 7 月被修复,最后一个在 2021 年 5 月被修复。这些漏洞可能导致任意写入文件,攻击者可以利用这些文件在目标交换服务器上上传 web shell。

攻击者最初试图通过扫描释放的 web shell 来启动攻击,研究人员假设这些 web shell 是通过漏洞利用提前释放的。但尝试失败了,因为当研究人员尝试访问它们时,文件显示了 404 错误代码。

1.webp.jpg

扫描 web shell

CVE-2021-34473:预认证路径混淆

   2021年8月5日,安全研究员在国外安全会议上公开了CVE-2021-34473 Microsoft Exchange Server 远程代码执行漏洞分析及其POC。攻击者利用该漏洞可绕过相关权限验证,进而配合其他漏洞可执行任意代码,控制Microsoft Exchange Server。

该漏洞滥用了 Explicit Logon URL 的 URL 规范化,如果 URL 后缀为 autodiscover/autodiscover.json,则登录电子邮件将从 URL 中删除。这允许作为 Exchange 计算机帐户 (NT AUTHORITY\SYSTEM) 进行任意后端 URL 访问。

2.png

利用 CVE-2021-34473

自动发现服务被滥用以泄露已知用户的专有名称 (DN),这是 Microsoft Exchange 内部使用的一种地址格式。然后,消息应用程序编程接口 (MAPI) 被滥用来泄露用户的安全标识符 (SID)。

CVE-2021-34523:Exchange PowerShell 后端权限提升

Microsoft Exchange 具有 PowerShell 远程处理功能,可用于阅读和发送电子邮件。 NT AUTHORITY\SYSTEM 无法使用此功能,因为它没有邮箱,但是,可以通过 X-Rps-CAT 查询字符串参数提供后端 /powershell,以防使用先前的漏洞直接访问它,即将被反序列化并用于恢复用户身份。

攻击者可以使用此技术来模拟本地管理员以运行 PowerShell 命令。

3.png

使用本地管理员帐户 [email protected] 及其 SID 的攻击者

CVE-2021-31207:授权后任意文件写入

此漏洞利用 New-MailboxExportRequest PowerShell 命令将用户邮箱导出到任意文件位置,该文件位置可用于在Exchange服务器上编写shell。

4.png

导入后访问 web shell

web shell 作为邮件导入到administrator[@]xxx草稿邮箱中。然后将其导出到 c:/inetpub/wwwroot/aspnet_client/puqjc.aspx,之后它被访问并返回200个代码。对文件系统时间线的分析显示相同:puqjc.aspx 文件与恶意 Web 连接同时创建(UTC 下午 2:00)

5.png

显示文件 puqjc.aspx 创建的系统时间线

Post-exploitation示例

Web shell 是用 Web 开发编程语言(例如 ASP、JSP)编写的一段代码,攻击者可以将其放入 Web 服务器以获得远程访问权限以及执行任意代码和命令以满足其目标的能力。一旦web shell被成功地释放到受害者的服务器,它就可以允许远程攻击者执行各种任务,例如窃取数据或释放其他恶意工具。

通过对攻击样本的分析,研究人员能够识别出不同攻击者使用的 Web shell 的几种变体。所有示例的扫描和利用阶段都相同,但利用后的活动及其影响各不相同。

以下部分会详细介绍研究人员在 2021 年 8 月和 9 月发生的四起不同示例中分析的Post-exploitation细节。虽然其中一些示例在感染期间具有某些相同的行为,但它们的Post-exploitation却各不相同。

示例1

第一个 web shell

6.png

显示 exec_code 查询参数的代码

在研究人员处理的第一个示例中,他们发现攻击中使用的 web shell 使用 exec_code 查询参数来执行 ASP 代码。在成功访问命令与控制 (C&C) 服务器后,它执行命令以收集有关受感染系统的基本信息。

7.png

此外,web shell 还执行 PowerShell 命令,并下载并执行其他恶意软件。

8.png

执行 PowerShell 命令并下载其他恶意软件

rundll.bat

Web shell 包含一个脚本,该脚本会阻止来自特定供应商的安全软件,然后禁用系统的防火墙。

9.png

显示脚本如何终止安全软件的代码

然后它执行一个 PowerShell 编码的 base64 脚本,该脚本下载另一个混淆的 PowerShell 脚本,然后执行。该脚本是 CobaltStrike 恶意软件家族的一部分,它能够提供对受感染计算机的后门访问。

10.png

解码后的PowerShell命令下载并执行Cobalt Strike

11.png

来自Cobalt Strike的代码混淆了PowerShell

研究人员还注意到攻击背后的攻击者执行脚本来阻止特定进程并清除 PowerShell Windows 示例日志。

12.png

旨在终止 PowerShell 相关进程的脚本

Liferay 内容管理系统

IP 地址 212.84.32[.]13 和 103.25.196[.]33 是使用 Liferay 内容管理系统 (CMS) 的服务器。这些似乎是该软件的受攻击版本,用于在 CMS 使用的默认端口(80、443、8080)以外的不同端口上托管Post-exploitation恶意负载。

13.png

在 IP 地址 212.84.32[.]13 和 103.25.196[.]33 上找到的 Liferay CMS 版本的属性

两台服务器都使用Liferay CE 6.2版本,该版本容易受到 CVE-2020-7961(可能导致远程代码执行)的攻击。

示例2

与第一个示例类似,攻击者通过 web shell 访问服务器,然后开始收集系统的基本信息。然而,第二个示例使用 PowerShell 进行不同的Post-exploitation活动。

研究人员的分析表明 Wget 请求被发送到具有高编号端口的 URL。不幸的是,研究人员没有关于下载内容的信息,因为在分析的时候URL已经失效了。

14.png

执行以下命令以收集基本系统信息:

15.png

然后使用以下命令复制 web shell 并删除原始条目:

16.png

ipconfig 命令作为 wget 请求的参数执行。

以下代码显示了 Powershell 编码(顶部)和解码(底部)命令:

17.png

Mimikatz 是一种允许用户查看和保存凭据的工具,通常用于后期开发活动,由 PowerShell 下载,如以下编码(顶部)和解码(底部)命令所示:

18.png

然后 web shell 下载了一个额外的 .aspx web shell 并为其添加时间戳以进一步在系统中伪装自己,如下代码所示:

19.png

然后将 web shell 移动到 OWA 目录,并带有以下时间戳:

20.png

几分钟后,额外的 DLL 被创建,后来被验证为 w3wp.exe 或 UMWorkerProcess.exe 创建的 web shell 文件。

21.png

在此示例中,研究人员发现攻击者使用了以下恶意组件和恶意软件:

22.png

其他 web shell

在研究人员对这个样本的调查过程中,他们在 ASP.net 页面中发现了一个用 C# 编写的特定 web shell 变体,这很不寻常,因为研究人员发现的大多数 web shell 都是用 PHP 编写的。这类似于 KRYPTON 组织在其活动中使用的自定义 web shell。 DLL web shell 在同一系统中也有相应的 ASPX 版本。

23.png

用 C# 编写的 web shell

24.webp.jpg

在 CMD 中执行 Base64 命令的 C# web shell 函数

25.webp.jpg

Web shell只响应已知的输入,否则它将响应错误代码404

示例3

该示例在凭证转储技术和系统内横向移动方面与前两起示例不同。在次示例中使用Microsoft Process Dump工具转储LSSAS并提取哈希。

26.png

主动式攻击期间 procedump.exe 的执行

在横向移动阶段检测到 Windows 实用程序 PsExec,攻击者使用它来访问远程计算机和服务器,以释放和执行新的后门恶意软件。

使用哈希传递攻击技术访问远程服务器和计算机,然后删除新的恶意软件组件以创建持久性。

27.webp.jpg

使用哈希传递技术进行远程访问

以下恶意软件已投放到受感染的计算机上:

28.png

然后通过计划任务在远程计算机上创建持久性以保持后门运行。

29.png

通过计划任务创建持久性

示例4

该示例具有一种有趣的凭据转储技术,特别是通过 NT 目录服务实用程序转储数据库:

30.png

这是使用 ProxyShell 实例的Post-exploitation示例。释放web shell 后,cmd.exe 和 powershell.exe 用于在受影响的系统上执行命令。

31.webp.jpg

Trend Micro Vision One ™ 控制台显示使用 ProxyShell的Post-exploitation示例

安全建议

对于研究人员遇到的示例,应该注意的是,受影响的 Microsoft Exchange 服务器都没有被其各自的 IT 团队有意或无意地修复。虽然缓解控制,例如基于主机或基于网络的攻击防御系统 (HIPS/NIPS) 的实施,可以应用于这些服务器,但应该注意的是,这些控制只会在进行任何实际修复之前,为 IT 团队提供防护空间,允许他们触发适当的变更管理控制。

另外,即使在攻击后修复了 Microsoft Exchange 服务器,它仍具有活动的 web shell。这意味着应彻底检查因与 ProxyShell 相关的漏洞而受到攻击的服务器是否存在任何恶意活动,因为 Web Shell 可能已经存在并且可能继续运行。活跃的Web Shell仍然可以让攻击者继续攻击他们选择的目标,例如勒索软件感染、加密货币挖掘和数据窃取。

对公开的服务器进行适当的分割,并不断监控其行为即启动的进程、反恶意软件违规或网络流量配置文件。例如,观察到内部网络扫描、SMB 流量或其他从未见过的异常流量可能表明服务器已被攻击。

前段时间微软发布了一个非常酷的功能,这是一种无密码身份验证功能,可使用安全密钥(例如著名的 FIDO2 密钥)为本地资源提供无缝单点登录 (SSO)。

因此,这个想法很简单,你可以登录到你的混合 Azure AD 加入的 Windows 10 设备并自动访问云和本地资源。 FIDO2 安全密钥成为进入云和本地资源的途径。

Microsoft 之前仅针对加入 Azure AD 的设备发布了相同的功能,但现在范围已扩展到混合环境。

一个新的证书收集攻击向量涉及只读域控制器服务器,让我们看看从研究新功能到实现对Impacket的新攻击的所有方法。

Azure 中的无密码体验

如上所述,Microsoft 通过 Azure Active Directory 将无密码体验扩展到本地资源。既然我们谈论的是本地资源的 SSO 功能,那就要先了解一下 Kerberos。

Kerberos 是主要的身份验证协议,用于验证 Windows 域中的安全对象(用户或主机)的身份。它基于对称密码学(共享秘钥)并使用票据的概念来验证这些身份。粗略地说,Kerberos 发出两种票据,一种是验证对象身份的票据授予票据 (TGT),另一种是对象用于对域中的其他服务进行身份验证的服务票据。

假设我想访问在服务器 A 中运行的服务 1。身份验证流程如下:

1.webp.jpg

Kerberos 身份验证

很清楚、很简单。现在让我们把事情弄得更复杂一点。让我们将这种情况转移到混合环境。使用安全密钥的身份验证流程如下:

2.webp.jpg

无密码身份验证

可以看到部分 TGT 交换完整的TGT,以及在云中复制的 Kerberos 服务器密钥。这是怎么回事?让我们开始深入研究这个问题。到目前为止,只有位于域控制器上的密钥发布中心 (KDC) 服务有权发布 TGT。但是,这种新的无密码体验的引入使事情发生了一些变化:正如我们在之前的流程中看到的那样,Azure AD 现在可以为一个或多个域发出 Kerberos TGT!这让我想到了另一个问题,krbtgt 帐户呢?

KDC 在任何域中使用的安全对象是 krbtgt 帐户。这是一个无法删除,也无法更改名称的特殊帐户,其密码用于派生密钥,用于加密 KDC 发布的 TGT。出于显而易见的原因,此帐户不会离开 AD 服务器。那么,Azure AD 如何在没有这个特殊帐户的情况下发布 TGT?以下是 Azure AD Kerberos 服务器对象图出现的位置。

3.webp.jpg

Kerberos 服务器对象属性

Azure AD Kerberos 服务器是在本地 AD 中创建的对象,它在Azure AD中复制,不与任何物理服务器相关联(它是虚拟的)。它由遵循命名格式“krbtgt_######”的禁用用户帐户对象和关联的计算机帐户“AzureADKerberos”组成。

Azure AD 使用此对象为域生成部分 TGT。这样,用户帐户拥有 Azure AD Kerberos 服务器 TGT 加密密钥。这是在身份验证流程的第二步中用于加密部分票据的 Kerberos 服务器密钥。

但问题只解决了一半,我们域名的 krbtgt 密钥不需要发布到云端,而是使用这个新的 krbtgt_###### 帐户的密钥。因此,Azure 现在可以发行票据,但是服务票据和授权呢?

服务票据和授权继续由本地 AD 域控制器控制。 Azure AD 没有将特权属性证书 (PAC) 包含到票据中所需的所有信息,这就是为什么它只签发部分票据的原因。

流量如何继续?一旦我们获得了部分票据,就必须将它(针对本地 AD)换成包含所有所需授权信息的完整票据,最后,使用它来请求不同的服务票据以访问本地资源。至此,我们获得了 Kerberos SSO 功能,并完成了无密码体验。

至此,只剩下一个问题,这个 Kerberos Server 对象到底是什么? 为什么我们的本地 AD 信任它的密钥?只需查看与对象相关的设备帐户的属性,就很容易获得答案:

4.webp.jpg

计算机属性

我们谈论的是只读域控制器 (RODC)。 Microsoft 重用 RODC 的概念来实现 Kerberos 的“云”版本,允许 Azure AD 提供 SSO 功能。

还记得只读域控制器吗?

在继续之前,需要回顾一些关于 RODC 的基本概念。如果想了解更多信息,请点了解。

简而言之,RODC 是一种域控制器,它承载 Active Directory 数据库的只读分区。除帐户密码外,它保存可写域控制器保存的所有 AD 对象和属性。但是,无法对存储在 RODC 上的数据库进行更改。它主要被设计用于部署在远程或分支机构环境中,这些环境通常具有相对较少的用户、较差的物理安全性或到中心站点的网络带宽较差。

我想回顾的主要概念是凭据缓存,它将非常有用。正如我之前提到的,默认情况下,帐户密码不会保存到RODC中(出于安全目的),因此分支站点中的身份验证过程略有不同:

1.用户向其站点的 RODC 发送 一个TGT 请求;

2.RODC 服务器检查用户凭据是否已缓存:

2.1如果没有,RODC 将请求转发到可写 DC;

2.3如果凭据已缓存,则身份验证由 RODC 解析;

3.可写 DC 对用户进行身份验证,签署 TGT,并将响应发送回 RODC;

4.RODC 将检查用户是否允许缓存其凭据:

4.1如果用户包含在 Allowed RODC Password Replication中,则他们的凭据存储在服务器中,并且 RODC 的 msDS-RevealedList 属性填充有用户名。后续的身份验证请求将由 RODC 管理;

4.2如果用户包含在Denied RODC Password Replication中,则不会存储他们的凭据,后续的身份验证请求将转发到可写 DC。

5.RODC 将 TGT 转发给用户,用户可以使用它来请求服务票据。

因此,当可写DC不可访问且RODC无法将请求转发给它时,缓存对于确保用户和计算机可以向RODC进行身份验证非常有用。然而,这可能是一把双刃剑。没有缓存凭据的原因是为了防止当RODC服务器被破坏时整个域处于危险之中。正如上所述,这些分支站点的安全性级别较低。因此,凭据缓存背后的主要思想只是保持在站点上操作所需的最少密码数量。

回到无密码场景,我们看到了 Microsoft 如何使用 Kerberos 在混合环境中支持 SSO 到本地资源。但是,对使用 NTLM 等旧协议的资源的访问发生了什么?

分析这种情况的简单方法是检查 Wireshark 捕获的无密码身份验证。我们最感兴趣分析的身份验证部分是图 2 的第 4 步和第 5 步,即部分票据和完整票据之间的交换。

完整的TGT是通过向KDC (krbtgt服务)发送一个TGS-REQ(packet n°577)获得的:

6.webp.jpg

TGS-REQ 包括两个预认证数据 (PA-DATA)。带有部分 TGT 和未知 PA-DATA 类型编号 161 的 PA-TGS-REQ。

7.webp.jpg

未知类型是一个明显的迹象,表明那里正在发生某些事情。如果 Wireshark 没有定义该数据类型,那是因为该数据相对较新。因此,首先要做的是查看 [MS-KILE]:Kerberos 协议扩展,并检查此 PA-DATA 类型。第一个结果是一种新型的 TGS-REQ:

3.3.5.7.8 密钥列表请求

当密钥发布中心 (KDC) 收到包含 aKERB-KEY-LIST-REQ[161] padata 类型的 krbtgt 服务名称 (sname) 的 TGS-REQ 消息时,KDC应该包括长期秘钥的客户端请求的加密类型 KERB-KEY-LIST-REP [162]响应消息,并将其插入到 EncKDCRepPart 结构的加密数据中,如 [RFC6806] 中所定义:

2.2.11 KERB-KEY-LIST-REQ

KERB-KEY-LIST-REQ 结构用于请求 KDC 可以提供给客户端的密钥类型列表,以支持旧协议中的单点登录功能。它的结构是使用 ASN.1 符号定义的。语法如下:

KERB-KEY-LIST-REQ ::= SEQUENCE OF Int32 — encryption type —  

KERB-KEY-LIST-REQ 的结构用于支持旧协议的 SSO 功能。只需检查请求的加密类型以及响应。捕获的内容如下:

8.webp.jpg

PA-DATA 的内容是编码值 3003020117,代表加密类型 23 或 RC4-HMAC。这代表我们正在请求用户的 NT 哈希!

确认后,我开始查看响应(packet n°583):

9.webp.jpg

在 TGS-REP 的加密部分(用会话密钥解密)中,我们可以找到 PA-DATA 类型 162,即 KERB-KEY-LIST-REP:

10.webp.jpg

回到MS-KILE,我检查了结构的编码以解码数据并获取密钥:

2.2.12 KERB-KEY-LIST-REP

KERB-KEY-LIST-REP 结构包含 KDC 提供给客户端的密钥类型列表,以支持旧协议中的单点登录功能。它的结构是使用 ASN.1 符号定义的。语法如下:

 KERB-KEY-LIST-REP ::= SEQUENCE OF EncryptionKey

编码后的 PA-DATA 被解码为:

11.webp.jpg

用户现在可以使用其 NT-Hash 与 NTLM 进行身份验证。

密钥列表攻击

现在,我们发现了 Windows 使用旧协议实现 SSO 的方式。在检查之后,反应是立竿见影的,我们还发现了一种新的潜在方法来转储要求较低的凭据!

这种新技术背后的想法很简单。如果我们能够用新的 PA-DATA 重现之前的 TGS-REQ,我们将拥有用户所有长期秘钥的列表。

因此,第一次尝试是将 TGS-REQ 复制到 krbtgt 服务,并使用普通用户添加 KERB-KEY-LIST-REQ 结构。这意味着包含的 TGT 是由 KDC 颁发给该普通用户的,无需知道 krbtgt 凭据即可轻松获取。响应是正常的 TGS-REP,没有新数据(不包括 KERB-KEY-LIST-REP)。第二次尝试是管理员用户的新 TGS-REQ。同样的过程,同样的结果,答案中没有关键字。这个想法并不是那么简单。

如果该过程适用于 RODC,让我们尝试将由此服务器签名的部分 TGT 包含到 TGS-REQ 中。复制由 RODC 签名并颁发给特定用户的部分 TGT,将其包含到 TGS-REQ 中,解密响应并获取密钥,可以对我们想要的任何用户重复。

经过几次尝试,漏洞开始显现:KDC_ERR_TGT_REVOKED(TGT 已被撤销)。为什么?这些用户包含在拒绝 RODC 密码复制组中,因此,此新 Kerberos 功能受到限制。默认情况下,拒绝管理员等用户复制其密码。

不过,我们可以攻击物理 RODC 服务器和虚拟服务器(Azure AD Kerberos 服务器对象包含在我们的攻击面中!)。同样重要的是,目标用户不需要缓存在 RODC 中!这是以前针对这类域控制器的攻击所需要的。

总而言之:

我们必须知道RODC (-rodcKey)的krbtgt凭据,因为我们需要创建带有一些特殊条件的部分票据和TGS-REQ。我们有几种获取凭据的方法,例如,如果我们获得RODC的本地管理员权限,就可以用Mimikatz转储SAM数据库。如果我们讨论的是虚拟RODC,可以针对Azure AD连接服务器;

我们必须有RODC的krbtgt帐户的ID (-rodcNo);

我们必须针对在拒绝组中未明确详细说明的用户;

有了这些要求,我打开了一个PR,其中包含一个新的示例脚本(keylistattack.py)和secretsdump.py中的一个新选项(-use-keylist),以演示这种攻击。

基本上,攻击有两个主要部分:用户列表和票据请求:

首先,我们需要知道我们的目标是什么,可以通过参数(LIST 选项)定义目标用户名(-t 标志)或定义具有目标用户名列表(-tf 标志)的文件,或者我们可以进行枚举(例如,SAMR 用户枚举) )。对于最后一个选项,我们需要一个低凭据用户,我们有两个选项。默认选项,过滤包含在拒绝组中的域用户,以及完整的一个(-full 标志)。

一旦我们知道要攻击谁,我们就会请求票据、处理响应并获取密钥!

12.png

keylistattack.py 使用没有过滤的 SAMR 用户枚举(-full 标志)

13.webp.jpg

keylistattack.py 使用 SAMR 用户枚举和过滤(默认攻击)

14.webp.jpg

keylistattack.py 定义目标用户名(-t 标志)

15.webp.jpg

使用 Kerberos 密钥列表攻击选项 (-use-keylist) 的 secretsdump.py

如何检测?

提出了新的攻击,我们如何检测它?由于攻击实施了有效的密钥列表请求,该请求可能出现在启用了无密码的环境的正常操作中,因此选项并不多:

1.审计枚举操作:

SAMR 枚举:事件 4661——请求对象句柄(对象类型:SAM_DOMAIN、SAM_ALIAS、SAM_GROUP);

LDAP 枚举;

2.审核 Kerberos 服务票据操作:

成功请求:事件 4769——请求了 Kerberos 服务票据(票据选项:0x10000 ——可代理);

TGT 撤销:事件 4769——请求了 Kerberos 服务票据(失败代码:0x14 – KDC_ERR_TGT_REVOKED)

如何缓解这种攻击?

物理 RODC:

1.不要将“经过身份验证的用户”或“域用户”添加到“允许的 RODC 密码复制组”中。如果需要,应以与可写 DC(第 0 层)类似的级别保护这些 RODC;

2.将所有特权帐户和组添加到“拒绝 RODC 密码复制组”;

3.不要将常规用户帐户设置为 RODC 管理员,这些类型的帐户通常不如知名帐户安全,并且它们的泄露可能导致本地帐户(包括 RODC 的 krbtgt 帐户)的凭据转储。

虚拟 RODC(Azure AD Kerberos 服务器/无密码方案):

1.请确保只将具有无密码能力的用户添加到“允许的RODC密码复制组”;

2.Azure AD Connect服务器包含关键的身份数据,应该被视为第 0 层;

总结

1.物理和虚拟 RODC 都可能受到攻击;

2.由于需要复制权限,虚拟 RODC 中的攻击面更加广泛;

3.要攻击的帐户不需要缓存在 RODC 上;

4.不需要管理员凭据,如果你有用户列表,甚至不需要凭据;

5.该攻击要求至少有一台DC服务器使用Windows 2016/2019的更新版本(分别为kb4534307和kb4534321补丁);

前段时间微软发布了一个非常酷的功能,这是一种无密码身份验证功能,可使用安全密钥(例如著名的 FIDO2 密钥)为本地资源提供无缝单点登录 (SSO)。

因此,这个想法很简单,你可以登录到你的混合 Azure AD 加入的 Windows 10 设备并自动访问云和本地资源。 FIDO2 安全密钥成为进入云和本地资源的途径。

Microsoft 之前仅针对加入 Azure AD 的设备发布了相同的功能,但现在范围已扩展到混合环境。

一个新的证书收集攻击向量涉及只读域控制器服务器,让我们看看从研究新功能到实现对Impacket的新攻击的所有方法。

Azure 中的无密码体验

如上所述,Microsoft 通过 Azure Active Directory 将无密码体验扩展到本地资源。既然我们谈论的是本地资源的 SSO 功能,那就要先了解一下 Kerberos。

Kerberos 是主要的身份验证协议,用于验证 Windows 域中的安全对象(用户或主机)的身份。它基于对称密码学(共享秘钥)并使用票据的概念来验证这些身份。粗略地说,Kerberos 发出两种票据,一种是验证对象身份的票据授予票据 (TGT),另一种是对象用于对域中的其他服务进行身份验证的服务票据。

假设我想访问在服务器 A 中运行的服务 1。身份验证流程如下:

1.webp.jpg

Kerberos 身份验证

很清楚、很简单。现在让我们把事情弄得更复杂一点。让我们将这种情况转移到混合环境。使用安全密钥的身份验证流程如下:

2.webp.jpg

无密码身份验证

可以看到部分 TGT 交换完整的TGT,以及在云中复制的 Kerberos 服务器密钥。这是怎么回事?让我们开始深入研究这个问题。到目前为止,只有位于域控制器上的密钥发布中心 (KDC) 服务有权发布 TGT。但是,这种新的无密码体验的引入使事情发生了一些变化:正如我们在之前的流程中看到的那样,Azure AD 现在可以为一个或多个域发出 Kerberos TGT!这让我想到了另一个问题,krbtgt 帐户呢?

KDC 在任何域中使用的安全对象是 krbtgt 帐户。这是一个无法删除,也无法更改名称的特殊帐户,其密码用于派生密钥,用于加密 KDC 发布的 TGT。出于显而易见的原因,此帐户不会离开 AD 服务器。那么,Azure AD 如何在没有这个特殊帐户的情况下发布 TGT?以下是 Azure AD Kerberos 服务器对象图出现的位置。

3.webp.jpg

Kerberos 服务器对象属性

Azure AD Kerberos 服务器是在本地 AD 中创建的对象,它在Azure AD中复制,不与任何物理服务器相关联(它是虚拟的)。它由遵循命名格式“krbtgt_######”的禁用用户帐户对象和关联的计算机帐户“AzureADKerberos”组成。

Azure AD 使用此对象为域生成部分 TGT。这样,用户帐户拥有 Azure AD Kerberos 服务器 TGT 加密密钥。这是在身份验证流程的第二步中用于加密部分票据的 Kerberos 服务器密钥。

但问题只解决了一半,我们域名的 krbtgt 密钥不需要发布到云端,而是使用这个新的 krbtgt_###### 帐户的密钥。因此,Azure 现在可以发行票据,但是服务票据和授权呢?

服务票据和授权继续由本地 AD 域控制器控制。 Azure AD 没有将特权属性证书 (PAC) 包含到票据中所需的所有信息,这就是为什么它只签发部分票据的原因。

流量如何继续?一旦我们获得了部分票据,就必须将它(针对本地 AD)换成包含所有所需授权信息的完整票据,最后,使用它来请求不同的服务票据以访问本地资源。至此,我们获得了 Kerberos SSO 功能,并完成了无密码体验。

至此,只剩下一个问题,这个 Kerberos Server 对象到底是什么? 为什么我们的本地 AD 信任它的密钥?只需查看与对象相关的设备帐户的属性,就很容易获得答案:

4.webp.jpg

计算机属性

我们谈论的是只读域控制器 (RODC)。 Microsoft 重用 RODC 的概念来实现 Kerberos 的“云”版本,允许 Azure AD 提供 SSO 功能。

还记得只读域控制器吗?

在继续之前,需要回顾一些关于 RODC 的基本概念。如果想了解更多信息,请点了解。

简而言之,RODC 是一种域控制器,它承载 Active Directory 数据库的只读分区。除帐户密码外,它保存可写域控制器保存的所有 AD 对象和属性。但是,无法对存储在 RODC 上的数据库进行更改。它主要被设计用于部署在远程或分支机构环境中,这些环境通常具有相对较少的用户、较差的物理安全性或到中心站点的网络带宽较差。

我想回顾的主要概念是凭据缓存,它将非常有用。正如我之前提到的,默认情况下,帐户密码不会保存到RODC中(出于安全目的),因此分支站点中的身份验证过程略有不同:

1.用户向其站点的 RODC 发送 一个TGT 请求;

2.RODC 服务器检查用户凭据是否已缓存:

2.1如果没有,RODC 将请求转发到可写 DC;

2.3如果凭据已缓存,则身份验证由 RODC 解析;

3.可写 DC 对用户进行身份验证,签署 TGT,并将响应发送回 RODC;

4.RODC 将检查用户是否允许缓存其凭据:

4.1如果用户包含在 Allowed RODC Password Replication中,则他们的凭据存储在服务器中,并且 RODC 的 msDS-RevealedList 属性填充有用户名。后续的身份验证请求将由 RODC 管理;

4.2如果用户包含在Denied RODC Password Replication中,则不会存储他们的凭据,后续的身份验证请求将转发到可写 DC。

5.RODC 将 TGT 转发给用户,用户可以使用它来请求服务票据。

因此,当可写DC不可访问且RODC无法将请求转发给它时,缓存对于确保用户和计算机可以向RODC进行身份验证非常有用。然而,这可能是一把双刃剑。没有缓存凭据的原因是为了防止当RODC服务器被破坏时整个域处于危险之中。正如上所述,这些分支站点的安全性级别较低。因此,凭据缓存背后的主要思想只是保持在站点上操作所需的最少密码数量。

回到无密码场景,我们看到了 Microsoft 如何使用 Kerberos 在混合环境中支持 SSO 到本地资源。但是,对使用 NTLM 等旧协议的资源的访问发生了什么?

分析这种情况的简单方法是检查 Wireshark 捕获的无密码身份验证。我们最感兴趣分析的身份验证部分是图 2 的第 4 步和第 5 步,即部分票据和完整票据之间的交换。

完整的TGT是通过向KDC (krbtgt服务)发送一个TGS-REQ(packet n°577)获得的:

6.webp.jpg

TGS-REQ 包括两个预认证数据 (PA-DATA)。带有部分 TGT 和未知 PA-DATA 类型编号 161 的 PA-TGS-REQ。

7.webp.jpg

未知类型是一个明显的迹象,表明那里正在发生某些事情。如果 Wireshark 没有定义该数据类型,那是因为该数据相对较新。因此,首先要做的是查看 [MS-KILE]:Kerberos 协议扩展,并检查此 PA-DATA 类型。第一个结果是一种新型的 TGS-REQ:

3.3.5.7.8 密钥列表请求

当密钥发布中心 (KDC) 收到包含 aKERB-KEY-LIST-REQ[161] padata 类型的 krbtgt 服务名称 (sname) 的 TGS-REQ 消息时,KDC应该包括长期秘钥的客户端请求的加密类型 KERB-KEY-LIST-REP [162]响应消息,并将其插入到 EncKDCRepPart 结构的加密数据中,如 [RFC6806] 中所定义:

2.2.11 KERB-KEY-LIST-REQ

KERB-KEY-LIST-REQ 结构用于请求 KDC 可以提供给客户端的密钥类型列表,以支持旧协议中的单点登录功能。它的结构是使用 ASN.1 符号定义的。语法如下:

KERB-KEY-LIST-REQ ::= SEQUENCE OF Int32 — encryption type —  

KERB-KEY-LIST-REQ 的结构用于支持旧协议的 SSO 功能。只需检查请求的加密类型以及响应。捕获的内容如下:

8.webp.jpg

PA-DATA 的内容是编码值 3003020117,代表加密类型 23 或 RC4-HMAC。这代表我们正在请求用户的 NT 哈希!

确认后,我开始查看响应(packet n°583):

9.webp.jpg

在 TGS-REP 的加密部分(用会话密钥解密)中,我们可以找到 PA-DATA 类型 162,即 KERB-KEY-LIST-REP:

10.webp.jpg

回到MS-KILE,我检查了结构的编码以解码数据并获取密钥:

2.2.12 KERB-KEY-LIST-REP

KERB-KEY-LIST-REP 结构包含 KDC 提供给客户端的密钥类型列表,以支持旧协议中的单点登录功能。它的结构是使用 ASN.1 符号定义的。语法如下:

 KERB-KEY-LIST-REP ::= SEQUENCE OF EncryptionKey

编码后的 PA-DATA 被解码为:

11.webp.jpg

用户现在可以使用其 NT-Hash 与 NTLM 进行身份验证。

密钥列表攻击

现在,我们发现了 Windows 使用旧协议实现 SSO 的方式。在检查之后,反应是立竿见影的,我们还发现了一种新的潜在方法来转储要求较低的凭据!

这种新技术背后的想法很简单。如果我们能够用新的 PA-DATA 重现之前的 TGS-REQ,我们将拥有用户所有长期秘钥的列表。

因此,第一次尝试是将 TGS-REQ 复制到 krbtgt 服务,并使用普通用户添加 KERB-KEY-LIST-REQ 结构。这意味着包含的 TGT 是由 KDC 颁发给该普通用户的,无需知道 krbtgt 凭据即可轻松获取。响应是正常的 TGS-REP,没有新数据(不包括 KERB-KEY-LIST-REP)。第二次尝试是管理员用户的新 TGS-REQ。同样的过程,同样的结果,答案中没有关键字。这个想法并不是那么简单。

如果该过程适用于 RODC,让我们尝试将由此服务器签名的部分 TGT 包含到 TGS-REQ 中。复制由 RODC 签名并颁发给特定用户的部分 TGT,将其包含到 TGS-REQ 中,解密响应并获取密钥,可以对我们想要的任何用户重复。

经过几次尝试,漏洞开始显现:KDC_ERR_TGT_REVOKED(TGT 已被撤销)。为什么?这些用户包含在拒绝 RODC 密码复制组中,因此,此新 Kerberos 功能受到限制。默认情况下,拒绝管理员等用户复制其密码。

不过,我们可以攻击物理 RODC 服务器和虚拟服务器(Azure AD Kerberos 服务器对象包含在我们的攻击面中!)。同样重要的是,目标用户不需要缓存在 RODC 中!这是以前针对这类域控制器的攻击所需要的。

总而言之:

我们必须知道RODC (-rodcKey)的krbtgt凭据,因为我们需要创建带有一些特殊条件的部分票据和TGS-REQ。我们有几种获取凭据的方法,例如,如果我们获得RODC的本地管理员权限,就可以用Mimikatz转储SAM数据库。如果我们讨论的是虚拟RODC,可以针对Azure AD连接服务器;

我们必须有RODC的krbtgt帐户的ID (-rodcNo);

我们必须针对在拒绝组中未明确详细说明的用户;

有了这些要求,我打开了一个PR,其中包含一个新的示例脚本(keylistattack.py)和secretsdump.py中的一个新选项(-use-keylist),以演示这种攻击。

基本上,攻击有两个主要部分:用户列表和票据请求:

首先,我们需要知道我们的目标是什么,可以通过参数(LIST 选项)定义目标用户名(-t 标志)或定义具有目标用户名列表(-tf 标志)的文件,或者我们可以进行枚举(例如,SAMR 用户枚举) )。对于最后一个选项,我们需要一个低凭据用户,我们有两个选项。默认选项,过滤包含在拒绝组中的域用户,以及完整的一个(-full 标志)。

一旦我们知道要攻击谁,我们就会请求票据、处理响应并获取密钥!

12.png

keylistattack.py 使用没有过滤的 SAMR 用户枚举(-full 标志)

13.webp.jpg

keylistattack.py 使用 SAMR 用户枚举和过滤(默认攻击)

14.webp.jpg

keylistattack.py 定义目标用户名(-t 标志)

15.webp.jpg

使用 Kerberos 密钥列表攻击选项 (-use-keylist) 的 secretsdump.py

如何检测?

提出了新的攻击,我们如何检测它?由于攻击实施了有效的密钥列表请求,该请求可能出现在启用了无密码的环境的正常操作中,因此选项并不多:

1.审计枚举操作:

SAMR 枚举:事件 4661——请求对象句柄(对象类型:SAM_DOMAIN、SAM_ALIAS、SAM_GROUP);

LDAP 枚举;

2.审核 Kerberos 服务票据操作:

成功请求:事件 4769——请求了 Kerberos 服务票据(票据选项:0x10000 ——可代理);

TGT 撤销:事件 4769——请求了 Kerberos 服务票据(失败代码:0x14 – KDC_ERR_TGT_REVOKED)

如何缓解这种攻击?

物理 RODC:

1.不要将“经过身份验证的用户”或“域用户”添加到“允许的 RODC 密码复制组”中。如果需要,应以与可写 DC(第 0 层)类似的级别保护这些 RODC;

2.将所有特权帐户和组添加到“拒绝 RODC 密码复制组”;

3.不要将常规用户帐户设置为 RODC 管理员,这些类型的帐户通常不如知名帐户安全,并且它们的泄露可能导致本地帐户(包括 RODC 的 krbtgt 帐户)的凭据转储。

虚拟 RODC(Azure AD Kerberos 服务器/无密码方案):

1.请确保只将具有无密码能力的用户添加到“允许的RODC密码复制组”;

2.Azure AD Connect服务器包含关键的身份数据,应该被视为第 0 层;

总结

1.物理和虚拟 RODC 都可能受到攻击;

2.由于需要复制权限,虚拟 RODC 中的攻击面更加广泛;

3.要攻击的帐户不需要缓存在 RODC 上;

4.不需要管理员凭据,如果你有用户列表,甚至不需要凭据;

5.该攻击要求至少有一台DC服务器使用Windows 2016/2019的更新版本(分别为kb4534307和kb4534321补丁);

由于Firefox母公司的隐私保护措施,Firefox 有时会被默认为一种更安全的浏览器。本文将详细反驳,并对标 Chromium,研究 Firefox 浏览器在进程沙箱模型、漏洞利用缓解技术等方面的不足。

沙箱

沙箱是一种用于隔离某些程序的技术,以防止它们中的漏洞通过限制对不必要资源的访问而危及系统的其他部分。现在所有常见的浏览器都包含一个沙箱并利用多进程架构。浏览器将自己分成不同的进程(例如内容进程、GPU 进程、RDD 进程等)并将它们分别沙箱化,严格遵守最小权限原则。浏览器使用沙箱非常重要,因为它会处理不受信任的输入,带来巨大的攻击面,并且是系统上最常用的应用程序之一。如果没有沙箱,浏览器中的任何漏洞都可以用来接管系统的其余部分。而对于沙箱,攻击者需要将他们的利用与额外的沙箱逃逸漏洞联系起来。

如果沙箱充满漏洞,那么仅仅有一个沙盒是没有多大作用的。Firefox 的沙箱非常脆弱,下面的漏洞只是几个示例。

网站隔离

网站隔离是 2018 年 Chromium 中引入的一项安全功能,这涉及对 Chromium 多进程架构的彻底改革,而不是所有的网站都运行在同一个进程中,该功能现在将每个网站划分到自己的沙箱渲染器进程中。这确保了来自一个网站的渲染器漏洞仍然无法访问来自另一个网站的数据。此外,网站隔离对于完全防止诸如 Spectre 之类的侧信道攻击是必要的。针对此类攻击的操作系统缓解措施仅保证进程边界的隔离。因此,将网站分成不同的进程是充分利用它们的唯一途径。此外,当前的浏览器缓解措施(例如降低 JavaScript 计时器的准确性)是不够的,无法解决根本问题。因此,唯一适当的缓解措施是通过网站隔离。

Firefox 目前缺乏任何形式的网站隔离,Mozilla 正在通过 Project Fission 实现这一功能,并在 Nightly 和 Beta 发布渠道上推出,但它仍在进行中,还不适合正式使用。 Fission 在目前的状态下,即使它最初发布,也不会接近 Chromium 网站隔离的成熟水平,它需要很多年才能达到这一点。 Fission 仍然存在基线内容流程沙箱的所有安全问题,如下所述——它不是解决所有沙箱问题的灵丹妙药。然而,具体到 Fission 本身,存在大量跨网站泄漏,允许受攻击的内容进程访问另一个的数据并绕过网站隔离。

Windows

排除网站隔离的问题,只有 Windows 上的 Firefox 沙箱可以与 Chromium 沙箱相媲美,但它仍然缺乏 Win32k Lockdown。 Win32k 是 NT 内核中一组危险的系统调用,它暴露了大量的攻击面,使其成为沙箱逃逸的常见目标。 Microsoft 旨在通过引入一项功能来降低这种风险,该功能允许进程阻止对这些系统调用的访问,从而大大减少攻击面。 Chromium 在 2016 年实现了此功能以加强沙箱检测,但 Firefox 尚未添加此功能。

Linux

◼沙箱逃逸

Firefox 在其他平台(如 Linux)上的沙箱效果要差得多,这些限制通常非常宽松,甚至容易受到跨越多年的各种琐碎的沙箱逃逸漏洞的影响,以及从沙箱内部暴露出相当大的攻击面。

此类沙箱逃逸漏洞的一个示例是 X11 — X11 没有实现任何 GUI 隔离,这使得使用它逃逸沙箱变得非常容易。 Chromium 通过只允许从 GPU 进程内部访问 X11 来解决这个问题,因此渲染器进程(加载网站的进程)无法访问它,而在 Firefox 上,它直接暴露给内容进程。

PulseAudio是Linux上的一个常见的声音服务器,但是,在编写时并没有考虑到隔离,这使得使用它可以脱离沙箱。像X11一样,Firefox直接将其暴露给内容进程,允许另一个微不足道的沙箱逃脱,而Chromium只将其暴露给一个专门的音频服务。

◼seccomp-bpf

seccomp-bpf 是 Linux 上的一种沙箱技术,它允许限制进程可访问的系统调用,这可以大大减少内核攻击面,并且是大多数 Linux 沙箱的核心部分。但是,Firefox 的 seccomp 过滤器比 Chromium 的沙箱强加的过滤器的限制要少得多,而且它对系统调用及其参数的限制也不相同。这方面的一个示例是对ioctl调用几乎没有过滤,只有与 TTY 相关的 ioctl 在内容过程中被阻止。这是有问题的,因为因为ioctl是一个特别强大的系统调用,它由数百个不同的系统调用组成,有点类似于NT的Win32k,因此会造成大量的内核攻击。与Firefox不同,Chromium只允许其沙箱中必需的少数 ioctl,这可显着减少内核攻击面。出于同样的原因,Android 以类似的方式在其应用程序沙箱中实现了 ioctl 过滤,以及其他各种专注于沙箱的项目。

安卓

在Android上,Firefox除了操作系统应用程序的沙箱之外,根本没有多进程架构或沙箱,而Chromium使用了isolatedProcess特性,以及更严格的seccomp-bpf过滤器。

缺少的进程

总的来说,Chromium的多进程体系结构比Firefox的更加成熟和细粒度,允许它对浏览器的每个部分施加更严格的限制。下面列出了Firefox中缺少的进程示例。在Firefox上,这些功能将被合并到另一个进程中,比如父进程或内容进程,这使得执行严格的限制变得相当困难。

在 Linux 上,Firefox 没有单独的 GPU 进程,这意味着它不能被独立沙箱化。这个进程在Windows上存在,但是它的沙箱仍然没有启用。

Firefox 还没有单独的用于网络操作的 socket 进程,这个进程只存在于 Nightly 中,不包括 WebRTC 代码以外的任何东西,这与 Chromium 的专用网络服务不同。

Firefox 也没有音频进程,而 Chromium 有专门的音频服务。 Firefox 中缺少这样的进程意味着音频功能被合并到内容进程中,这就是 Linux 系统上 PulseAudio 沙箱逃逸向量的原因。

其他示例包括文本转语音、打印后端和合成器、语音识别、代理解析器等。

缓解措施方面

Firefox缺乏许多重要的缓解措施,而Chromium通常在这方面更胜一筹。

任意代码保护和代码完整性保护

一种非常常见的利用技术是,在利用缓冲区溢出漏洞期间,攻击者将他们自己的恶意代码(称为shellcode)注入到内存的一部分,并通过重写关键数据(如返回地址和函数指针),使程序执行它,劫持控制流并指向前面提到的shellcode,从而获得对程序的控制。

该行业最终演变为通过将内存的可写区域标记为不可执行和可执行区域为不可写来缓解这种类型的攻击,从而防止攻击者注入和执行其 shellcode。但是,攻击者可以通过重用程序(称为gadget)中已经存在的代码位来绕过它们,这超出了它们最初打算使用的顺序。尽管有上述保护措施,攻击者仍可以利用诸如返回导向编程 (ROP) 或跳转导向编程 (JOP) 等技术形成一系列此类gadget,以实现近乎任意的代码执行。

攻击者经常将他们的 shellcode 注入可写内存页面,然后使用这些代码重用技术将内存页面转换为可执行(使用系统调用,例如 mprotect 或 VirtualAlloc),从而允许它被执行。 Windows 10实现了一个称为任意代码保护(ACG)的缓解措施,它通过确保所有可执行内存页面都是不可变的并且永远无法写入来缓解这种情况。

另一种称为代码完整性保护 (CIG) 的缓解措施类似于 ACG,但它适用于文件系统而不是内存,通过保证加载到进程中的所有二进制文件都必须签名来确保攻击者无法在磁盘上执行恶意程序或库. ACG 和 CIG 一起在内存和文件系统中执行严格的 W^X 策略。

2017 年,Chromium 实现了对 ACG 和 CIG 的支持,如 MITIGATION_DYNAMIC_CODE_DISABLE 和 MITIGATION_FORCE_MS_SIGNED_BINS,但 Firefox 尚未实现对 ACG 或 CIG 的类似支持。目前Firefox只在socket进程中启用ACG和CIG(目前还没有启用)和在RDD进程中启用CIG。

然而,由于与JIT引擎的内在不兼容,Chromium的ACG应用目前仍然受到限制,因为JIT引擎需要同时具有可写和可执行的内存。ACG主要是在相对次要的进程中启用的,例如音频、代理解析器和图标读取器进程。如果V8启用了JITless模式,那么Chromium在渲染过程中也启用了ACG。

1.png

Chromium 在无 JITless 模式下运行时在渲染器进程中启用 ACG

2.png

如果启用了 NetworkServiceCodeIntegrity 功能,Chromium 可以选择在网络进程中启用 CIG

控制流的完整性

如前所述,代码重用攻击可用于通过将程序中已经存在的代码片段链接在一起来实现近乎任意的代码执行,ACG 和 CIG 仅缓解了一种潜在的攻击向量,创建 ROP/JOP 链以将映射转换为可执行文件。但是,攻击者仍然可以使用纯 ROP/JOP 链,完全依赖预先存在的gadget,而无需引入自己的代码。这可以通过控制流完整性 (CFI) 来缓解,CFI 严格限制攻击者能够使用的gadget,从而破坏他们的链。

CFI通常有两部分:前边缘保护(覆盖JOP、COP等)和后边缘保护(覆盖ROP)。CFI实现可以有很大的不同。有些CFI实现只覆盖前边缘或后边缘。有些是粗粒度的(攻击者有更多的通道来执行大量的指令)而不是细粒度的。有些是概率性的(它们依赖于所持有的秘密并且不保证安全属性)而不是确定性的。

Mozilla 计划实施 CFI 已有一段时间,但尚未取得太大进展。在 Linux、Android 和 ChromeOS 上,Chromium 启用 Clang 的细粒度前沿 CFI,而在 Windows 上,它启用粗粒度前沿控制流保护 (CFG)。 Firefox 只在 Windows 上启用 CFG,它不如 Clang 的 CFI 有效,因为它是粗粒度的而不是细粒度的,并且不适用于其他平台。

不受信任的字体拦截

不受信任的字体历来是Windows漏洞的常见来源,因此,Windows包括一个缓解措施,以阻止来自特定进程的不受信任的字体,以减少攻击面。2016年,Chromium以MITIGATION_NONSYSTEM_FONT_DISABLE的形式添加了对这一功能的支持,并为大多数子进程启用了这一功能,但是Firefox还没有在任何子进程中启用这一功能。

3.png

JIT 强化技术

所有常见的浏览器都包含一个JIT编译器以提高性能,然而,JIT中存在一个固有的安全漏洞,那就是对可写和可执行内存的要求,这是一个W^X冲突,如上所述,可以帮助利用它。为了在不牺牲性能提升的情况下降低此功能带来的安全风险,浏览器采用了 JIT 强化技术,使利用 JIT 编译器变得更加困难。在 Chris Rohlf关于攻击 JIT 编译器的研究中,分析和比较了在各种 JIT 引擎中实现的强化技术。这项研究表明,Chromium (V8) 中的 JIT 引擎比 Firefox (JaegerMonkey) 中使用的引擎具有更好的保护。特别是,Chromium 使用但 Firefox 没有使用的缓解措施包括:

◼保护页面;

◼页面随机化;

◼Constant blinding;

◼分配限制;

◼NOP 插入;

◼随机代码库偏移量;

改进措施

Firefox 试图通过添加所谓的“W^X JIT”来强化 JIT 引擎,但这并不能阻止实际的漏洞利用,因为它容易受到竞争窗口的影响,在该窗口中,攻击者可以在可写时将其 shellcode 写入内存映射并等待引擎将其转换为可执行文件。此外,由于 Firefox 中缺少 CFI,攻击者也可以使用许多gadget来强制将映射转换为可执行文件,例如 C 库中的 ExecutableAllocator::makeExecutable 或 mprotect / VirtualAlloc。类似于 Safari 的“Bulletproof JIT”的东西会是一个更好的方法,它利用两个独立的映射,一个可写的和一个可执行的,可写映射被放置在内存中的一个秘密位置,通过只执行内存隐藏。

经过分析,这不是一个很成熟的安全措施。

内存分配器强化

此外,Firefox 缺乏强化的内存分配器。 Firefox 目前使用 mozjemalloc,它是 jemalloc 的一个分支。 Jemalloc 是一个面向性能的内存分配器,但它不关注安全性,这使得它很容易被利用。 Mozjemalloc 确实为 jemalloc 添加了一些有用的安全功能,但它们不足以解决分配器整体架构中存在的问题。 Chromium 改为使用 PartitionAlloc(由于 PartitionAlloc-Everywhere 在整个代码库中),它比 mozjemalloc 更加坚固。

与mozjemalloc相比,在PartitionAlloc中有一些在mozjemalloc中不存在的安全特性。

◼内存分区

内存分区是一种漏洞利用缓解措施,其中内存分配器将不同类型的对象隔离到它们自己独立的堆中。

Chromium 的 PartitionAlloc 在设计时就考虑到了这种缓解措施,分区之间不重用内存的强内存分区是PartitionAlloc的核心目标之一。

Firefox的mozjemalloc最终也实现了对分区的一些支持,但是,内存是跨分区重用的,因此严重削弱了这个特性,并允许它被绕过。因此,mozjemalloc的内存分区实现并不能保证像PartitionAlloc那样的强隔离。

◼脱机元数据

传统的堆利用技术通常依赖于破坏内存分配器元数据。 PartitionAlloc 将大多数元数据离线存储在专用区域中(除了空闲列表指针,它们还有其他保护)而不是将其与分配相邻,从而显着增加了执行此类技术的难度。

与PartitionAlloc不同的是,mozjemalloc目前将堆元数据放在与分配一致的位置。因此,上述技术仍然是可能的,分配器元数据更容易被攻击。

由于Firefox母公司的隐私保护措施,Firefox 有时会被默认为一种更安全的浏览器。本文将详细反驳,并对标 Chromium,研究 Firefox 浏览器在进程沙箱模型、漏洞利用缓解技术等方面的不足。

沙箱

沙箱是一种用于隔离某些程序的技术,以防止它们中的漏洞通过限制对不必要资源的访问而危及系统的其他部分。现在所有常见的浏览器都包含一个沙箱并利用多进程架构。浏览器将自己分成不同的进程(例如内容进程、GPU 进程、RDD 进程等)并将它们分别沙箱化,严格遵守最小权限原则。浏览器使用沙箱非常重要,因为它会处理不受信任的输入,带来巨大的攻击面,并且是系统上最常用的应用程序之一。如果没有沙箱,浏览器中的任何漏洞都可以用来接管系统的其余部分。而对于沙箱,攻击者需要将他们的利用与额外的沙箱逃逸漏洞联系起来。

如果沙箱充满漏洞,那么仅仅有一个沙盒是没有多大作用的。Firefox 的沙箱非常脆弱,下面的漏洞只是几个示例。

网站隔离

网站隔离是 2018 年 Chromium 中引入的一项安全功能,这涉及对 Chromium 多进程架构的彻底改革,而不是所有的网站都运行在同一个进程中,该功能现在将每个网站划分到自己的沙箱渲染器进程中。这确保了来自一个网站的渲染器漏洞仍然无法访问来自另一个网站的数据。此外,网站隔离对于完全防止诸如 Spectre 之类的侧信道攻击是必要的。针对此类攻击的操作系统缓解措施仅保证进程边界的隔离。因此,将网站分成不同的进程是充分利用它们的唯一途径。此外,当前的浏览器缓解措施(例如降低 JavaScript 计时器的准确性)是不够的,无法解决根本问题。因此,唯一适当的缓解措施是通过网站隔离。

Firefox 目前缺乏任何形式的网站隔离,Mozilla 正在通过 Project Fission 实现这一功能,并在 Nightly 和 Beta 发布渠道上推出,但它仍在进行中,还不适合正式使用。 Fission 在目前的状态下,即使它最初发布,也不会接近 Chromium 网站隔离的成熟水平,它需要很多年才能达到这一点。 Fission 仍然存在基线内容流程沙箱的所有安全问题,如下所述——它不是解决所有沙箱问题的灵丹妙药。然而,具体到 Fission 本身,存在大量跨网站泄漏,允许受攻击的内容进程访问另一个的数据并绕过网站隔离。

Windows

排除网站隔离的问题,只有 Windows 上的 Firefox 沙箱可以与 Chromium 沙箱相媲美,但它仍然缺乏 Win32k Lockdown。 Win32k 是 NT 内核中一组危险的系统调用,它暴露了大量的攻击面,使其成为沙箱逃逸的常见目标。 Microsoft 旨在通过引入一项功能来降低这种风险,该功能允许进程阻止对这些系统调用的访问,从而大大减少攻击面。 Chromium 在 2016 年实现了此功能以加强沙箱检测,但 Firefox 尚未添加此功能。

Linux

◼沙箱逃逸

Firefox 在其他平台(如 Linux)上的沙箱效果要差得多,这些限制通常非常宽松,甚至容易受到跨越多年的各种琐碎的沙箱逃逸漏洞的影响,以及从沙箱内部暴露出相当大的攻击面。

此类沙箱逃逸漏洞的一个示例是 X11 — X11 没有实现任何 GUI 隔离,这使得使用它逃逸沙箱变得非常容易。 Chromium 通过只允许从 GPU 进程内部访问 X11 来解决这个问题,因此渲染器进程(加载网站的进程)无法访问它,而在 Firefox 上,它直接暴露给内容进程。

PulseAudio是Linux上的一个常见的声音服务器,但是,在编写时并没有考虑到隔离,这使得使用它可以脱离沙箱。像X11一样,Firefox直接将其暴露给内容进程,允许另一个微不足道的沙箱逃脱,而Chromium只将其暴露给一个专门的音频服务。

◼seccomp-bpf

seccomp-bpf 是 Linux 上的一种沙箱技术,它允许限制进程可访问的系统调用,这可以大大减少内核攻击面,并且是大多数 Linux 沙箱的核心部分。但是,Firefox 的 seccomp 过滤器比 Chromium 的沙箱强加的过滤器的限制要少得多,而且它对系统调用及其参数的限制也不相同。这方面的一个示例是对ioctl调用几乎没有过滤,只有与 TTY 相关的 ioctl 在内容过程中被阻止。这是有问题的,因为因为ioctl是一个特别强大的系统调用,它由数百个不同的系统调用组成,有点类似于NT的Win32k,因此会造成大量的内核攻击。与Firefox不同,Chromium只允许其沙箱中必需的少数 ioctl,这可显着减少内核攻击面。出于同样的原因,Android 以类似的方式在其应用程序沙箱中实现了 ioctl 过滤,以及其他各种专注于沙箱的项目。

安卓

在Android上,Firefox除了操作系统应用程序的沙箱之外,根本没有多进程架构或沙箱,而Chromium使用了isolatedProcess特性,以及更严格的seccomp-bpf过滤器。

缺少的进程

总的来说,Chromium的多进程体系结构比Firefox的更加成熟和细粒度,允许它对浏览器的每个部分施加更严格的限制。下面列出了Firefox中缺少的进程示例。在Firefox上,这些功能将被合并到另一个进程中,比如父进程或内容进程,这使得执行严格的限制变得相当困难。

在 Linux 上,Firefox 没有单独的 GPU 进程,这意味着它不能被独立沙箱化。这个进程在Windows上存在,但是它的沙箱仍然没有启用。

Firefox 还没有单独的用于网络操作的 socket 进程,这个进程只存在于 Nightly 中,不包括 WebRTC 代码以外的任何东西,这与 Chromium 的专用网络服务不同。

Firefox 也没有音频进程,而 Chromium 有专门的音频服务。 Firefox 中缺少这样的进程意味着音频功能被合并到内容进程中,这就是 Linux 系统上 PulseAudio 沙箱逃逸向量的原因。

其他示例包括文本转语音、打印后端和合成器、语音识别、代理解析器等。

缓解措施方面

Firefox缺乏许多重要的缓解措施,而Chromium通常在这方面更胜一筹。

任意代码保护和代码完整性保护

一种非常常见的利用技术是,在利用缓冲区溢出漏洞期间,攻击者将他们自己的恶意代码(称为shellcode)注入到内存的一部分,并通过重写关键数据(如返回地址和函数指针),使程序执行它,劫持控制流并指向前面提到的shellcode,从而获得对程序的控制。

该行业最终演变为通过将内存的可写区域标记为不可执行和可执行区域为不可写来缓解这种类型的攻击,从而防止攻击者注入和执行其 shellcode。但是,攻击者可以通过重用程序(称为gadget)中已经存在的代码位来绕过它们,这超出了它们最初打算使用的顺序。尽管有上述保护措施,攻击者仍可以利用诸如返回导向编程 (ROP) 或跳转导向编程 (JOP) 等技术形成一系列此类gadget,以实现近乎任意的代码执行。

攻击者经常将他们的 shellcode 注入可写内存页面,然后使用这些代码重用技术将内存页面转换为可执行(使用系统调用,例如 mprotect 或 VirtualAlloc),从而允许它被执行。 Windows 10实现了一个称为任意代码保护(ACG)的缓解措施,它通过确保所有可执行内存页面都是不可变的并且永远无法写入来缓解这种情况。

另一种称为代码完整性保护 (CIG) 的缓解措施类似于 ACG,但它适用于文件系统而不是内存,通过保证加载到进程中的所有二进制文件都必须签名来确保攻击者无法在磁盘上执行恶意程序或库. ACG 和 CIG 一起在内存和文件系统中执行严格的 W^X 策略。

2017 年,Chromium 实现了对 ACG 和 CIG 的支持,如 MITIGATION_DYNAMIC_CODE_DISABLE 和 MITIGATION_FORCE_MS_SIGNED_BINS,但 Firefox 尚未实现对 ACG 或 CIG 的类似支持。目前Firefox只在socket进程中启用ACG和CIG(目前还没有启用)和在RDD进程中启用CIG。

然而,由于与JIT引擎的内在不兼容,Chromium的ACG应用目前仍然受到限制,因为JIT引擎需要同时具有可写和可执行的内存。ACG主要是在相对次要的进程中启用的,例如音频、代理解析器和图标读取器进程。如果V8启用了JITless模式,那么Chromium在渲染过程中也启用了ACG。

1.png

Chromium 在无 JITless 模式下运行时在渲染器进程中启用 ACG

2.png

如果启用了 NetworkServiceCodeIntegrity 功能,Chromium 可以选择在网络进程中启用 CIG

控制流的完整性

如前所述,代码重用攻击可用于通过将程序中已经存在的代码片段链接在一起来实现近乎任意的代码执行,ACG 和 CIG 仅缓解了一种潜在的攻击向量,创建 ROP/JOP 链以将映射转换为可执行文件。但是,攻击者仍然可以使用纯 ROP/JOP 链,完全依赖预先存在的gadget,而无需引入自己的代码。这可以通过控制流完整性 (CFI) 来缓解,CFI 严格限制攻击者能够使用的gadget,从而破坏他们的链。

CFI通常有两部分:前边缘保护(覆盖JOP、COP等)和后边缘保护(覆盖ROP)。CFI实现可以有很大的不同。有些CFI实现只覆盖前边缘或后边缘。有些是粗粒度的(攻击者有更多的通道来执行大量的指令)而不是细粒度的。有些是概率性的(它们依赖于所持有的秘密并且不保证安全属性)而不是确定性的。

Mozilla 计划实施 CFI 已有一段时间,但尚未取得太大进展。在 Linux、Android 和 ChromeOS 上,Chromium 启用 Clang 的细粒度前沿 CFI,而在 Windows 上,它启用粗粒度前沿控制流保护 (CFG)。 Firefox 只在 Windows 上启用 CFG,它不如 Clang 的 CFI 有效,因为它是粗粒度的而不是细粒度的,并且不适用于其他平台。

不受信任的字体拦截

不受信任的字体历来是Windows漏洞的常见来源,因此,Windows包括一个缓解措施,以阻止来自特定进程的不受信任的字体,以减少攻击面。2016年,Chromium以MITIGATION_NONSYSTEM_FONT_DISABLE的形式添加了对这一功能的支持,并为大多数子进程启用了这一功能,但是Firefox还没有在任何子进程中启用这一功能。

3.png

JIT 强化技术

所有常见的浏览器都包含一个JIT编译器以提高性能,然而,JIT中存在一个固有的安全漏洞,那就是对可写和可执行内存的要求,这是一个W^X冲突,如上所述,可以帮助利用它。为了在不牺牲性能提升的情况下降低此功能带来的安全风险,浏览器采用了 JIT 强化技术,使利用 JIT 编译器变得更加困难。在 Chris Rohlf关于攻击 JIT 编译器的研究中,分析和比较了在各种 JIT 引擎中实现的强化技术。这项研究表明,Chromium (V8) 中的 JIT 引擎比 Firefox (JaegerMonkey) 中使用的引擎具有更好的保护。特别是,Chromium 使用但 Firefox 没有使用的缓解措施包括:

◼保护页面;

◼页面随机化;

◼Constant blinding;

◼分配限制;

◼NOP 插入;

◼随机代码库偏移量;

改进措施

Firefox 试图通过添加所谓的“W^X JIT”来强化 JIT 引擎,但这并不能阻止实际的漏洞利用,因为它容易受到竞争窗口的影响,在该窗口中,攻击者可以在可写时将其 shellcode 写入内存映射并等待引擎将其转换为可执行文件。此外,由于 Firefox 中缺少 CFI,攻击者也可以使用许多gadget来强制将映射转换为可执行文件,例如 C 库中的 ExecutableAllocator::makeExecutable 或 mprotect / VirtualAlloc。类似于 Safari 的“Bulletproof JIT”的东西会是一个更好的方法,它利用两个独立的映射,一个可写的和一个可执行的,可写映射被放置在内存中的一个秘密位置,通过只执行内存隐藏。

经过分析,这不是一个很成熟的安全措施。

内存分配器强化

此外,Firefox 缺乏强化的内存分配器。 Firefox 目前使用 mozjemalloc,它是 jemalloc 的一个分支。 Jemalloc 是一个面向性能的内存分配器,但它不关注安全性,这使得它很容易被利用。 Mozjemalloc 确实为 jemalloc 添加了一些有用的安全功能,但它们不足以解决分配器整体架构中存在的问题。 Chromium 改为使用 PartitionAlloc(由于 PartitionAlloc-Everywhere 在整个代码库中),它比 mozjemalloc 更加坚固。

与mozjemalloc相比,在PartitionAlloc中有一些在mozjemalloc中不存在的安全特性。

◼内存分区

内存分区是一种漏洞利用缓解措施,其中内存分配器将不同类型的对象隔离到它们自己独立的堆中。

Chromium 的 PartitionAlloc 在设计时就考虑到了这种缓解措施,分区之间不重用内存的强内存分区是PartitionAlloc的核心目标之一。

Firefox的mozjemalloc最终也实现了对分区的一些支持,但是,内存是跨分区重用的,因此严重削弱了这个特性,并允许它被绕过。因此,mozjemalloc的内存分区实现并不能保证像PartitionAlloc那样的强隔离。

◼脱机元数据

传统的堆利用技术通常依赖于破坏内存分配器元数据。 PartitionAlloc 将大多数元数据离线存储在专用区域中(除了空闲列表指针,它们还有其他保护)而不是将其与分配相邻,从而显着增加了执行此类技术的难度。

与PartitionAlloc不同的是,mozjemalloc目前将堆元数据放在与分配一致的位置。因此,上述技术仍然是可能的,分配器元数据更容易被攻击。

本文虽然主要关注在俄罗斯境内活动的网络攻击者,但这些网络攻击者很少将自己限制在俄罗斯境内,勒索软件组织就是此类跨境活动的一个典型例子。此外,在一个国家发现的攻击趋势,往往会很快在其他地方和新的网络犯罪组织中重新出现。本文就试图介绍卡巴斯基实验室研究人员认为重要且影响范围会扩大的网络犯罪活动。

示例分析

卡巴斯基的计算机事件调查部门专门负责俄语和俄罗斯网络罪犯的攻击。我们提供的服务包括事件分析、调查,所有这些都是为了预防和缓解网络攻击。

早在 2016 年,攻击者的主要关注点就放在了针对金融机构,尤其是银行的主要网络组织。 Lurk、Buhtrap、Metel、RTM、Fibbit 和 Carbanak 等知名恶意软件家族已开始在全球范围内针对银行发起了攻击。

如今,受到攻击的行业已不仅限于金融机构,而幸好我们当年调查的那些重大攻击已不再可能。受影响的行业包括从 IT 到零售、从石油和天然气到医疗保健的所有行业。2020年,我们为俄罗斯客户调查了200个案例,到2021年前9个月,已经超过300个。受影响的行业包括从IT到零售,从石油和天然气到医疗保健。这是一个令人惊讶的趋势,正如人们预期的那样,由于新冠疫情的影响,远程工作更有可能引发攻击。

主要趋势

网络犯罪生态系统一直由各种角色组成。该系统的主要组成部分是进行网络犯罪活动所需的基础设施和用于该活动的工具。攻击者的角色直接依赖于基础设施和工具。接下来让我们了解一下俄语地区网络安全领域在过去五年中发生的一些重大变化,看看网络犯罪分子的运作方式发生了哪些变化。

对客户端的攻击逐渐消失

在五年前,用木马感染你的计算机就像访问新闻网站一样容易。事实上,俄罗斯的许多恶意软件都是通过新闻平台和其他合法网站传播的。虽然Web 攻击目前还非常流行,但随着浏览器安全性的提高,采用此方法进行的攻击变得更加困难。以前,许多网络攻击者只是通过合法网站传播漏洞。整个市场都是围绕这个过程建立起来的,有专门的人员来运行。

那个时代,浏览器漏洞百出,用户体验不佳,普遍不安全。许多人使用他们习惯的浏览器,而不是选择的浏览器或组织设置的默认浏览器,例如 Internet Explorer。通过插件(例如 Adobe Flash、Silverlight 和 Java)进行的攻击也是感染用户设备的最简单和最常用的方法之一,现在它们已成为过去。

到2021年,浏览器将变得更加安全,其中一些浏览器将自动更新,无需用户参与,而浏览器开发人员将继续投资于漏洞评估。此外,随着大量漏洞赏金程序的开发,将发现的漏洞出售给开发人员本身变得更容易,而不是在暗网上寻找买家,这也导致漏洞的价格上涨。

使用更安全的浏览器,网络感染变得更具挑战性,这导致网络攻击者慢慢将攻击目标放在了别的地方。因此,以这种方式针对普通用户而不是企业用户已经变得过于昂贵并且在商业上不可行。

漏洞被大量利用

应用程序变得更加复杂,它们的架构更好。这从根本上改变了俄语地区网络攻击者的运作方式。

随着漏洞价格的上涨,对客户端的攻击变得极其困难和昂贵。客户端感染过去严重依赖漏洞,整个团队会寻找它们并针对特定漏洞编写漏洞利用程序,针对不同的操作系统进行调整。大多数情况下,网络攻击者会利用 1日漏洞,他们检查了开发人员最近推出的补丁,并针对已关闭的漏洞编写了漏洞利用程序。然而,由于软件更新周期(现在仍然)很长,用户经常延迟更新他们的设备,因此留下了一个窗口,在此期间网络攻击者可以感染相当多的受害者。

一个典型的感染链是这样的:攻击者会攻击一个合法的网站,因为在五年前,还没有人认识到保护网站的重要性。黑客可以直接被攻破网站,也可以通过入侵拥有网站管理权限的人的账户来发起攻击。攻击者将集成一些代码,它可能是页面上的一个窗口,对用户是不可见的。然后,由于目标将继续使用该网站,它也会加载攻击者控制的页面。另一种选择是攻击横幅广告网络,我们在无数网站上都可以看到横幅广告,而网站管理部门对广告显示内容没有管理权。也可以简单地购买并将流量导向特定的恶意页面。最终,将用户引导到一个由攻击者控制的页面,该页面包含可以利用用户浏览器中的一个漏洞的代码。

2.png

上面说的是2016年流行的浏览器攻击链,现在已经不可能了存在了

为达到攻击目的,网络犯罪组织为特定用户组开发了漏洞利用工具包,并定制了下载到受害者设备的漏洞利用程序。运行漏洞后,攻击者会选择要下载到受感染设备的特定载荷。载荷通常会导致对计算机的远程访问。一旦被感染,该设备将根据它对网络攻击者的吸引力进行评估。之后,攻击者将加载一个特定的漏洞利用程序来评估受感染设备的兴趣,然后将特定的恶意软件上传到该设备。

由于此类浏览器攻击不再可行,也不再易于执行,因此不再需要各种不同的播放器。这包括专门购买和引导流量到具有漏洞利用的特定页面的组织、开发和销售漏洞利用包的组织、购买特定设备访问权的组织。

当然,客户端软件中的漏洞仍然存在,只是现在它们不在浏览器中,而是在各种类型的文档中,比如PDF或Word,这些带有宏选项的文档通常通过电子邮件传播。然而,这种变化使得攻击和感染过程更加困难。与浏览器感染不同,当传播隐藏在PDF或Word中的恶意文件时,攻击者无法收到受害者的反馈或目标使用的设备的附加信息。另一方面,浏览器会自动报告软件和插件的版本。这样一来,随着攻击者转而通过网络钓鱼邮件传播恶意文件,追踪用户软件的版本或攻击的程度就变得更加困难。最重要的是,电子邮件服务器和Word等应用程序中的安全机制也加大了感染的难度,许多包含恶意文件的电子邮件在到达目标之前不会被拦截,而用户在应用程序中会定期收到关于潜在危险附件的警告。

云服务器

通信和数据存储需要基础设施。

随着组织在采用新 IT 服务方面取得进展,追随相同趋势和变化的网络攻击者也在不断进步。迁移到云服务而不是常规服务器是一种新的攻击趋势。以前,网络攻击者会租用服务器,虽然通常不是以他们自己的名义,但非常合法。 2016 年,针对与可疑活动相关的服务器的投诉更容易被忽略。当时,一些组织提供了可以忽略用户投诉的防弹服务器。然而,随着时间的推移,管理此类服务器变得越来越困难,利润也越来越低。

网络攻击者还曾经攻击组织的服务器,将它们用作中继服务器,以迷惑调查人员,并使追踪主要 C&C 中心变得更加困难。有时,网络组织会将一些信息(例如,从受害者那里提取的数据)存储在他们已攻破的服务器上。这种数据分布在各种平台上的结构需要专门的人员来管理它。

云服务器的采用使网络攻击者的生活变得更轻松,现在,如果多次投诉导致帐户被暂停,将数据转移到新服务器只需两分钟。这也意味着团队不再需要专门的管理员来管理服务器,这项任务外包给了云服务器提供商。

恶意软件开发人员

也许最可怕的趋势是网络攻击者很容易获得新的有效恶意软件,尽管 APT 攻击者继续将大量资金和资源投入到量身定制的恶意工具中,但网络攻击者选择了更简单、成本更低的方式,这不再包括开发自己的恶意软件或漏洞。

开源恶意软件越来越频繁地出现在暗网上,老牌网络组织免费向公众发布源代码已成为一种趋势,这使得新玩家很容易开始他们的网络犯罪活动。银行木马 Cerberus 的开发者于 2020 年 10 月发布了其恶意软件的源代码,而臭名昭著的同名勒索软件的开发者 Babuk 则于 2021 年 9 月初发布了其勒索软件代码。

更糟糕的是,随着渗透测试工具和服务的发展,黑市上出现了新的恶意工具。这些工具是为合法服务开发和使用的,例如评估客户的安全基础设施和成功网络渗透的潜力。它们旨在出售给精心挑选的客户群,这些客户群只会将它们用于合法目的。例如网络攻击者最喜欢的 CobaltStrike,它的反编译版本于 2020 年 11 月泄露,现在网络攻击者和 APT 组织都在使用它。其他包括 Bloodhound,另一个最受欢迎的网络映射网络犯罪工具,用于专门传播的 Kali 和 Commando VM,用于利用漏洞的 Core Impact 和 Metaspoit Framework,在受感染计算机上使用 netscan.exe(softPerfect Network Scanner),以及用于远程访问的合法服务,例如 TeamViewer、AnyDesk 和 RMS/LMS。最重要的是,网络攻击者利用旨在帮助系统管理员的合法服务,例如允许远程执行程序的 PSexec。随着远程工作地增加,此类工具越来越受欢迎。

如今,要了解网络攻击者使用什么样的工具,只需了解渗透测试人员在市场上部署和提供的工具就足够了。

从本质上讲,恶意软件开发市场已经非常成熟,开展网络犯罪活动比以往任何时候都容易。与此同时,对企业攻击变得更加困难。

攻击组织变得越来越小

这些结构性转变(漏洞成本上升、迁移到云服务器、已开发的高级攻击工具的可访问性)导致网络组织变得越来越小。本质上,攻击链已经优化,许多功能已经外包,团队变得更加小。

现在已经不再需要管理物理网络的系统管理员了,云服务管理是一项简单的任务。网络犯罪组织也基本上停止了开发自己的恶意软件。以前,大型网络犯罪集团会投资于自己的恶意软件,因此至少需要两名开发人员负责恶意软件的不同部分(例如客户端和服务器端),现在他们只需要一名操作人员。如果不需要开发人员,那么测试人员也不需要。

为恶意网站购买流量已经转变为购买数据,访问不同组织、账户信息等,这些服务也被外包了。

因此,一个网络犯罪组织要想在2021年成功运行,就需要管理人员、网络访问专家以及负责提取和兑现被盗资金的金融专家。

1.png

2016年和2021年的网络犯罪集团的变化情况

攻击目标的改变

2016 年,俄罗斯的银行相继遭到黑客攻击。经过这件事之后,类似攻击的网络攻击组织已经被打击的差不多了,目前这些网络组织已经转向了攻击其他行业的目标。然而,到2018年,他们意识到以组织为目标更有利可图,使用勒索软件、窃取工具或远程访问工具从网络内部窃取资金。

2020年,针对俄罗斯金融机构的案件有所下降,包括银行软件在内的事件几乎都没有发生。

网络攻击者将目标转向西方组织并非出于意识形态原因。首先,针对欧洲和美国的组织营收性更高。例如,对于国际公司,赎金从 70 万美元起,最高可达 700 万美元。

同时,攻击目标向西方转移并不意味着俄罗斯公司不再受到来自国内黑客的攻击。因为黑客仍然受语言的限制,用他们的母语准备网络钓鱼电子邮件和文档要容易得多。这是俄语黑客在攻击俄罗斯公司时的唯一优势。

就行业而言,攻击目标不再局限于金融机构。僵尸网络的出现创造了一个网络访问市场,来自各行各业的公司在没有特定目标的情况下被攻击,随后通过暗网出售对这些公司的访问权限。疫情也在推动这一趋势方面发挥了作用,企业将大部分基础设施搬到了网上,并向远程工作人员开放,导致更大的攻击面和更多的方式,攻击原本受到更好保护的网络。通常情况下,勒索软件的运营者会选择那些唾手可得的目标,另一个重点是拥有或运营加密货币的组织和用户:加密交易所、加密钱包等都是诱人的目标。

发展趋势

目前暗网上已经不再出售真正有价值的漏洞(例如 0 日漏洞),尽管如此,在暗网上仍有许多关于购买现成账户、访问登录、DDoS攻击、进入目标组织的需求,只要需要,攻击者仍然可以毫不费力地找到这些服务。

本文虽然主要关注在俄罗斯境内活动的网络攻击者,但这些网络攻击者很少将自己限制在俄罗斯境内,勒索软件组织就是此类跨境活动的一个典型例子。此外,在一个国家发现的攻击趋势,往往会很快在其他地方和新的网络犯罪组织中重新出现。本文就试图介绍卡巴斯基实验室研究人员认为重要且影响范围会扩大的网络犯罪活动。

示例分析

卡巴斯基的计算机事件调查部门专门负责俄语和俄罗斯网络罪犯的攻击。我们提供的服务包括事件分析、调查,所有这些都是为了预防和缓解网络攻击。

早在 2016 年,攻击者的主要关注点就放在了针对金融机构,尤其是银行的主要网络组织。 Lurk、Buhtrap、Metel、RTM、Fibbit 和 Carbanak 等知名恶意软件家族已开始在全球范围内针对银行发起了攻击。

如今,受到攻击的行业已不仅限于金融机构,而幸好我们当年调查的那些重大攻击已不再可能。受影响的行业包括从 IT 到零售、从石油和天然气到医疗保健的所有行业。2020年,我们为俄罗斯客户调查了200个案例,到2021年前9个月,已经超过300个。受影响的行业包括从IT到零售,从石油和天然气到医疗保健。这是一个令人惊讶的趋势,正如人们预期的那样,由于新冠疫情的影响,远程工作更有可能引发攻击。

主要趋势

网络犯罪生态系统一直由各种角色组成。该系统的主要组成部分是进行网络犯罪活动所需的基础设施和用于该活动的工具。攻击者的角色直接依赖于基础设施和工具。接下来让我们了解一下俄语地区网络安全领域在过去五年中发生的一些重大变化,看看网络犯罪分子的运作方式发生了哪些变化。

对客户端的攻击逐渐消失

在五年前,用木马感染你的计算机就像访问新闻网站一样容易。事实上,俄罗斯的许多恶意软件都是通过新闻平台和其他合法网站传播的。虽然Web 攻击目前还非常流行,但随着浏览器安全性的提高,采用此方法进行的攻击变得更加困难。以前,许多网络攻击者只是通过合法网站传播漏洞。整个市场都是围绕这个过程建立起来的,有专门的人员来运行。

那个时代,浏览器漏洞百出,用户体验不佳,普遍不安全。许多人使用他们习惯的浏览器,而不是选择的浏览器或组织设置的默认浏览器,例如 Internet Explorer。通过插件(例如 Adobe Flash、Silverlight 和 Java)进行的攻击也是感染用户设备的最简单和最常用的方法之一,现在它们已成为过去。

到2021年,浏览器将变得更加安全,其中一些浏览器将自动更新,无需用户参与,而浏览器开发人员将继续投资于漏洞评估。此外,随着大量漏洞赏金程序的开发,将发现的漏洞出售给开发人员本身变得更容易,而不是在暗网上寻找买家,这也导致漏洞的价格上涨。

使用更安全的浏览器,网络感染变得更具挑战性,这导致网络攻击者慢慢将攻击目标放在了别的地方。因此,以这种方式针对普通用户而不是企业用户已经变得过于昂贵并且在商业上不可行。

漏洞被大量利用

应用程序变得更加复杂,它们的架构更好。这从根本上改变了俄语地区网络攻击者的运作方式。

随着漏洞价格的上涨,对客户端的攻击变得极其困难和昂贵。客户端感染过去严重依赖漏洞,整个团队会寻找它们并针对特定漏洞编写漏洞利用程序,针对不同的操作系统进行调整。大多数情况下,网络攻击者会利用 1日漏洞,他们检查了开发人员最近推出的补丁,并针对已关闭的漏洞编写了漏洞利用程序。然而,由于软件更新周期(现在仍然)很长,用户经常延迟更新他们的设备,因此留下了一个窗口,在此期间网络攻击者可以感染相当多的受害者。

一个典型的感染链是这样的:攻击者会攻击一个合法的网站,因为在五年前,还没有人认识到保护网站的重要性。黑客可以直接被攻破网站,也可以通过入侵拥有网站管理权限的人的账户来发起攻击。攻击者将集成一些代码,它可能是页面上的一个窗口,对用户是不可见的。然后,由于目标将继续使用该网站,它也会加载攻击者控制的页面。另一种选择是攻击横幅广告网络,我们在无数网站上都可以看到横幅广告,而网站管理部门对广告显示内容没有管理权。也可以简单地购买并将流量导向特定的恶意页面。最终,将用户引导到一个由攻击者控制的页面,该页面包含可以利用用户浏览器中的一个漏洞的代码。

2.png

上面说的是2016年流行的浏览器攻击链,现在已经不可能了存在了

为达到攻击目的,网络犯罪组织为特定用户组开发了漏洞利用工具包,并定制了下载到受害者设备的漏洞利用程序。运行漏洞后,攻击者会选择要下载到受感染设备的特定载荷。载荷通常会导致对计算机的远程访问。一旦被感染,该设备将根据它对网络攻击者的吸引力进行评估。之后,攻击者将加载一个特定的漏洞利用程序来评估受感染设备的兴趣,然后将特定的恶意软件上传到该设备。

由于此类浏览器攻击不再可行,也不再易于执行,因此不再需要各种不同的播放器。这包括专门购买和引导流量到具有漏洞利用的特定页面的组织、开发和销售漏洞利用包的组织、购买特定设备访问权的组织。

当然,客户端软件中的漏洞仍然存在,只是现在它们不在浏览器中,而是在各种类型的文档中,比如PDF或Word,这些带有宏选项的文档通常通过电子邮件传播。然而,这种变化使得攻击和感染过程更加困难。与浏览器感染不同,当传播隐藏在PDF或Word中的恶意文件时,攻击者无法收到受害者的反馈或目标使用的设备的附加信息。另一方面,浏览器会自动报告软件和插件的版本。这样一来,随着攻击者转而通过网络钓鱼邮件传播恶意文件,追踪用户软件的版本或攻击的程度就变得更加困难。最重要的是,电子邮件服务器和Word等应用程序中的安全机制也加大了感染的难度,许多包含恶意文件的电子邮件在到达目标之前不会被拦截,而用户在应用程序中会定期收到关于潜在危险附件的警告。

云服务器

通信和数据存储需要基础设施。

随着组织在采用新 IT 服务方面取得进展,追随相同趋势和变化的网络攻击者也在不断进步。迁移到云服务而不是常规服务器是一种新的攻击趋势。以前,网络攻击者会租用服务器,虽然通常不是以他们自己的名义,但非常合法。 2016 年,针对与可疑活动相关的服务器的投诉更容易被忽略。当时,一些组织提供了可以忽略用户投诉的防弹服务器。然而,随着时间的推移,管理此类服务器变得越来越困难,利润也越来越低。

网络攻击者还曾经攻击组织的服务器,将它们用作中继服务器,以迷惑调查人员,并使追踪主要 C&C 中心变得更加困难。有时,网络组织会将一些信息(例如,从受害者那里提取的数据)存储在他们已攻破的服务器上。这种数据分布在各种平台上的结构需要专门的人员来管理它。

云服务器的采用使网络攻击者的生活变得更轻松,现在,如果多次投诉导致帐户被暂停,将数据转移到新服务器只需两分钟。这也意味着团队不再需要专门的管理员来管理服务器,这项任务外包给了云服务器提供商。

恶意软件开发人员

也许最可怕的趋势是网络攻击者很容易获得新的有效恶意软件,尽管 APT 攻击者继续将大量资金和资源投入到量身定制的恶意工具中,但网络攻击者选择了更简单、成本更低的方式,这不再包括开发自己的恶意软件或漏洞。

开源恶意软件越来越频繁地出现在暗网上,老牌网络组织免费向公众发布源代码已成为一种趋势,这使得新玩家很容易开始他们的网络犯罪活动。银行木马 Cerberus 的开发者于 2020 年 10 月发布了其恶意软件的源代码,而臭名昭著的同名勒索软件的开发者 Babuk 则于 2021 年 9 月初发布了其勒索软件代码。

更糟糕的是,随着渗透测试工具和服务的发展,黑市上出现了新的恶意工具。这些工具是为合法服务开发和使用的,例如评估客户的安全基础设施和成功网络渗透的潜力。它们旨在出售给精心挑选的客户群,这些客户群只会将它们用于合法目的。例如网络攻击者最喜欢的 CobaltStrike,它的反编译版本于 2020 年 11 月泄露,现在网络攻击者和 APT 组织都在使用它。其他包括 Bloodhound,另一个最受欢迎的网络映射网络犯罪工具,用于专门传播的 Kali 和 Commando VM,用于利用漏洞的 Core Impact 和 Metaspoit Framework,在受感染计算机上使用 netscan.exe(softPerfect Network Scanner),以及用于远程访问的合法服务,例如 TeamViewer、AnyDesk 和 RMS/LMS。最重要的是,网络攻击者利用旨在帮助系统管理员的合法服务,例如允许远程执行程序的 PSexec。随着远程工作地增加,此类工具越来越受欢迎。

如今,要了解网络攻击者使用什么样的工具,只需了解渗透测试人员在市场上部署和提供的工具就足够了。

从本质上讲,恶意软件开发市场已经非常成熟,开展网络犯罪活动比以往任何时候都容易。与此同时,对企业攻击变得更加困难。

攻击组织变得越来越小

这些结构性转变(漏洞成本上升、迁移到云服务器、已开发的高级攻击工具的可访问性)导致网络组织变得越来越小。本质上,攻击链已经优化,许多功能已经外包,团队变得更加小。

现在已经不再需要管理物理网络的系统管理员了,云服务管理是一项简单的任务。网络犯罪组织也基本上停止了开发自己的恶意软件。以前,大型网络犯罪集团会投资于自己的恶意软件,因此至少需要两名开发人员负责恶意软件的不同部分(例如客户端和服务器端),现在他们只需要一名操作人员。如果不需要开发人员,那么测试人员也不需要。

为恶意网站购买流量已经转变为购买数据,访问不同组织、账户信息等,这些服务也被外包了。

因此,一个网络犯罪组织要想在2021年成功运行,就需要管理人员、网络访问专家以及负责提取和兑现被盗资金的金融专家。

1.png

2016年和2021年的网络犯罪集团的变化情况

攻击目标的改变

2016 年,俄罗斯的银行相继遭到黑客攻击。经过这件事之后,类似攻击的网络攻击组织已经被打击的差不多了,目前这些网络组织已经转向了攻击其他行业的目标。然而,到2018年,他们意识到以组织为目标更有利可图,使用勒索软件、窃取工具或远程访问工具从网络内部窃取资金。

2020年,针对俄罗斯金融机构的案件有所下降,包括银行软件在内的事件几乎都没有发生。

网络攻击者将目标转向西方组织并非出于意识形态原因。首先,针对欧洲和美国的组织营收性更高。例如,对于国际公司,赎金从 70 万美元起,最高可达 700 万美元。

同时,攻击目标向西方转移并不意味着俄罗斯公司不再受到来自国内黑客的攻击。因为黑客仍然受语言的限制,用他们的母语准备网络钓鱼电子邮件和文档要容易得多。这是俄语黑客在攻击俄罗斯公司时的唯一优势。

就行业而言,攻击目标不再局限于金融机构。僵尸网络的出现创造了一个网络访问市场,来自各行各业的公司在没有特定目标的情况下被攻击,随后通过暗网出售对这些公司的访问权限。疫情也在推动这一趋势方面发挥了作用,企业将大部分基础设施搬到了网上,并向远程工作人员开放,导致更大的攻击面和更多的方式,攻击原本受到更好保护的网络。通常情况下,勒索软件的运营者会选择那些唾手可得的目标,另一个重点是拥有或运营加密货币的组织和用户:加密交易所、加密钱包等都是诱人的目标。

发展趋势

目前暗网上已经不再出售真正有价值的漏洞(例如 0 日漏洞),尽管如此,在暗网上仍有许多关于购买现成账户、访问登录、DDoS攻击、进入目标组织的需求,只要需要,攻击者仍然可以毫不费力地找到这些服务。