Petya 新型勒索病毒的加密原理分析

作者:刘钊

简介

此次席卷乌克兰等全球多个国家的勒索病毒,与之前的 Petya 病毒极为相似,二者都会修改受害者电脑的 MBR,并且在电脑重启后,展示虚假的磁盘扫描界面,同时对磁盘 MFT 进行加密操作,在加密完毕后向受害者展示敲诈信息,勒索赎金。然而,有安全厂商仍然审慎地表示,此次病毒并非 Petya 勒索软件的变种。

腾讯安全反病毒实验室对样本的加密代码部分进行了分析,着重留意了代码与原始 Petya 勒索病毒的异同。

一、文件加密逻辑

之前的 Petya 勒索病毒的加密重点在于磁盘数据,在写完恶意 MBR 之后,会使系统强制重启,直接进入 MBR 引导模式;只有在写 MBR 失败的情况下,病毒才会使用备用方案,利用 Mischa 勒索病毒加密磁盘文件。

而此次爆发的勒索病毒,会使用计划任务执行重启操作,在电脑尚未重启之前,病毒还会开启一个线程执行文件加密操作:

而在文件加密的过程中,只会对文件的前 1MB 字节进行加密,以此提升加密的速度:

二、磁盘加密逻辑

1.磁盘加密整体流程

2.修改磁盘引导扇区

勒索病毒样本在写入磁盘时,分为四个部分写入不同的扇区。

首先是恶意 MBR 代码部分,从扇区 0 开始一共写入了 19 个扇区,这部分包含伪装磁盘扫描界面、加密 MFT、显示勒索文字、接受用户输入密码并尝试解密等完整功能:

其后,病毒又写入了 0x20、0x21、0x22 三个扇区的内容:

从后往前看,三个扇区的功能分别如下:

0x22 扇区存放的是病毒一开始从磁盘中读取的原始 MBR 内容,与 0x07 进行 XOR 操作的结果:

0x21 扇区存放的是长度为 0x200 字节的 0x07 的内容:

在加密过程中,此扇区也会使用与 MFT 相同的密钥进行加密,用于在用户输入密钥之后进行解密验证:

0x20 扇区存放的是加密流程中用到的一些配置内容,比如加密密钥等。在之前的 Petya 敲诈病毒中,此扇区结构如下:

(参考:Petya: the two-in-one trojan

而此次病毒写入内容的格式也基本一致:

所不同的只是显示的暗网地址被换成了比特币地址。

3.MBR 加载与勒索

MBR 启动后,通过 int13 AH=42 将 1 到 21 扇区的内容拷贝到内存 0x8000 处,并在随后执行。

在经过标志位(0x20 扇区中的 state)的比较,判断当前磁盘是否已经被加密,如果被加密则直接显示敲诈信息,否则则展示虚假的磁盘检查信息

随后,程序会调用 salsa20 算法对 MFT 进行对称加密,key 是 32byte 大小的 salsa_key,iv 是 8byte 大小的 salsa_iv。

病毒作者还对 salsa 算法的初始化参数做了修改,由原始算法的"expand 32-byte k"变成了如下字符串:

通过此算法,最终会把 MFT 逐个字节的进行对称加密。加密完成后,密钥会从磁盘中删除,防止加密数据被还原。

而 ec_data 被展示在敲诈界面上,作为受害者个人标识:

4.可疑的 ec_data

引起我们注意的即是这个 ec_data。在之前的 Petya 敲诈病毒中,此数据是使用密钥经过 ECDH、SHA、AES 等多次运算后得到的一个 Base58 字符串,目的是使用此数据与病毒作者手中的私钥一起可以计算出加密 MFT 使用的密钥,即前面被置空的 salsa_key 部分。

然而,在此次的敲诈病毒代码中,我们发现,病毒在生成随机数据之后,直接使用此数据生成了 Base58 字符串,并没有使用什么复杂的算法,也没有与加密密钥产生任何关联:

这就意味着,即使此次病毒作者在公布的邮箱中获取了受害者的标识,也无法将其与受害者的加密密钥对应起来。很有可能,此次病毒的始作俑者并不想帮受害者解密 MBR 部分。

结论

通过前面的分析可以看出,此次勒索病毒的作者使用了与之前 Petya 病毒类似的代码,通过 MBR 中代码、数据格式、加密流程等多处的高度一致性可以判定,这次的新型 Petya 病毒与之前的 Petya 病毒有着千丝万缕的联系。同时也可以注意到,与 Petya 病毒前几个版本不同的是,新型 Petya 病毒一方面使用了其它逻辑加密磁盘文件,另一方面并没有想要为受害者解密磁盘。我们猜测,此次勒索病毒的作者可能并非 Petya 勒索病毒的原始作者。

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

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

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Kubernetes

Kubernetes如何通过Devi

Device Plugins Device Pulgins在Kubernetes 1.10中是beta特性,开始于Kubernetes 1.8,用来给第三方设备...

4048
来自专栏运维一切

marathon错误记录 原

这个问题是这个样子,如果你的zookeeper集群不稳定,而且此前有部署过marathon集群,这下就经常会出现这种问题。marathon如果开启集群模式(--...

783
来自专栏FreeBuf

为什么要用BLAKE2替换SHA-1?| 密码学分析

当哈希碰撞成为现实 如果你在过去的十二年里不是生活在原始森林的话,那么你一定知道密码学哈希函数SHA-1是存在问题的,简而言之,SHA-1没有我们想象中的那么...

2036
来自专栏Netkiller

PPTP VPN 服务器

本文节选自《Netkiller Linux 手札》 作者:netkiller 地址:www.netkiller.cn/linux/ 38.2. pptpd 38...

5754
来自专栏Kubernetes

Docker容器内的监控命令数据修正思路

思路概述:编写linux c代码,生成对应的动态链接库(so文件),通过LDPRELOAD实现对/proc文件系统访问的劫持。劫持之后,实现容器内正确的数据计算...

3398
来自专栏数据和云

Oracle 12.2新特性 | 基于权重的节点驱逐

前言 在Oracle Clusterware需要从集群中逐出特定节点或一组节点的情况时,基于服务器权重的节点驱逐可充当断裂机制,通过服务器上的负载附加信息来识别...

3508
来自专栏我是东东强

记一次完整的网络通信过程

写完前面几篇对网络硬件设备以及对应工作机制的介绍之后,我觉得有必要再多有一篇博文对网络中的端到端通信过程进行完整的解析,本文对同一网段内、跨网段主机通信两种情形...

952
来自专栏FreeBuf

CTF中RSA题型解题思路及技巧

0x01 RSA算法简介 为了方便小白咀嚼后文,这里先对RSA密钥体制做个简略介绍(简略因为这不是本文讨论的重点) 选择两个大素数p和q,计算出模数N = p ...

7496
来自专栏FreeBuf

Petya及Notpetya的核心差异分析

这段时间针对恶意软件NotPetya的分析文章已经出了很多了,这篇文章的内容相当于只是对目前已存在内容的一次补充,而本文所要讨论的重点就是Petya和Notpe...

3444
来自专栏我的博客

apache禁止恶意解析

1.apache配置加载的时候把ip放在最前面即可 <VirtualHost *:80> DocumentRoot /var/www/ ServerName...

2835

扫码关注云+社区