后打败了大约一个月前，彼佳带着新把戏回来了。现在，不是作为一个人ransomware，但与另一个恶意负载- Mischa捆绑在一起。都是以卫星命名的《黄金眼》在内的邦德系列电影。

它们在系统的不同层上部署攻击，并作为替代方案使用。这就是为什么我们决定用不止一篇文章来阐述这一现象。欢迎来到第一部分!该分析的主要焦点是Petya (Green版本)。

第二部分(关于米沙)你可以读到在这里．

更新:改进版的绿色Petya已经出来了。新文章中给出了更多细节．

让我们从一些背景信息开始。

这一次，作者还部署了一个页面，为他们的“勒索软件即服务”的潜在客户提供信息:

janus_info_page

就像幻想，作者使用比特信息与犯罪合作的新成员进行沟通:

bitmessage

和发布阿霉素威胁，也来自幻想：

dox_threat

分析样品

8 a241cfcc23dc740e1fadc7f2df3965e–主可执行文件

f7596666d8080922d786f5892dd70742-主要可执行文件(来自不同的战役)

执行流程

行为分析

就像之前的版本一样，它是通过云存储分发的，假装是一个工作申请:
再一次

可执行文件再次打包了一个PDF文件的图标:

sample_petyas

部署后，它可以丢弃两个有效载荷中的一个——Petya——其工作原理与前面描述的版本类似，或者说Misha——具有典型勒索软件的功能。部署哪种负载取决于样本运行的权限，这意味着可以访问MBR。如果无法编写，作者决定不错过感染系统的机会，并使用Misha部署更典型的用户区攻击。

从用户的角度来看，您对UAC弹出框所做的决定将导致部署两个有效负载中的一个。如果你选择“不”，你会得到米莎。如果你选择“是”，你会得到Petya。

uac_popup

彼佳

感染过程看起来和Petya的上一个版本．用户帐户控制通知会弹出，如果用户接受它，Petya将自己安装到MBR中并使系统崩溃。第二阶段的感染看起来也几乎一样。首先，它运行的是伪造的CHKDSK，实际上是加密光盘。然后，用户可以看到带有闪烁的头骨和赎金纸条的ASCII图像。只是颜色主题改变了——我们有一个黑色背景和绿色文本，而不是红色:

green_petya

mischa2

这个主题与完整的勒索软件是一致的——我们可以在受害者的页面上找到相同的颜色，以及在Mischa丢弃的勒索信的HTML上。

受害者页面:

petya_site1

内部

新版本的Petya使用完全相同的引导加载程序–它再次从扇区34加载32个扇区到0x8000处的内存，然后跳到那里。

内核启动:

kernel_bgn

同样，使用保存在扇区54开头的一个字节标志来检查数据是否已经加密。如果该标志未设置(第一个字节的值为0)，程序将继续进行假CHKDSK扫描。否则(如果字节的值是1)，它将显示主绿色屏幕。

check_infected

用于加密的密钥再次由滴管生成并存储在二进制文件中。这就是为什么如果我们在第一阶段抓住Petya -在假CHKDSK运行和删除它之前，恢复系统仍然很容易。支持第1阶段密钥恢复的实时CD已经发布(在这里)．

主要验证

密钥验证步骤如下:

  1. 输入(关键)从用户读取。
    • 接受的字符集:123456789 abcdefghijkmnopqrstuvwxabcdefghjklmnpqrstuvwx-如果出现该字符集之外的字符，则跳过该字符集。
    • 只有第一个16字节存储
  2. 扇区55(512字节)的数据被读入内存//它将被表示为验证缓冲
  3. 存储在物理地址0x6c21(就在Tor地址之前)的值被读入内存。这是一个8字节长的数组，对于特定的感染是唯一的。//它将被表示为现时标志
  4. 的验证缓冲是加密的Salsa20长度为16字节关键和现时标志
  5. 如果由于申请程序的结果，验证缓冲是否充满0x7 -这意味着供应关键是正确的。

新的Petya发生了什么变化?

存储萨尔萨舞钥匙（第1阶段）

这一次，密钥的保存方式有所不同，没有乱码。也许作者意识到加扰并不能提供任何保护，所以他们完全放弃了这个想法:

petya_key

Salsa key的长度

在Red Petya中，作者使用了16字节长的密钥——然而，他们对其进行了打乱，并用它生成了一个32位长的密钥。现在他们放弃了，只使用16字节长的密钥。这就是为什么，不是函数expand32我们将在新的Petya中看到这个函数expand16：

expand_green

莎莎的实现

这一次,也Salsa20在Petya的代码中用于多个地方——用于加密、解密和密钥验证。见下图:

execution_flow

我们对已经找到的Salsa实现片段进行了比较在以前的实现中易受攻击．

salsa20_rol

见下文最初的版本这个函数的Salsa20实现:

Static uint32_t rol (uint32_t value, int shift) {return (value << shift) | (value >> (32 - shift));｝

代码比较-旧的和新的:

初级萨尔萨20与次级萨尔萨9698secondary_salsa20_rol vs sub_9698

这就是Red Petya是如何实现的:

green_rol

这个函数的旧版本有2个参数，它几乎是原始函数的克隆——唯一的区别是它使用了16位变量。代码重构:

静态uint16_t rotl（uint16_t value，int16_t shift）{return（value<>（32-shift））}

来自Green Petya的新版本:

green_rotl
新版本更加复杂——它接受3个参数，并调用额外的帮助函数。为了实现移动DWORD的功能，使用了两个word大小的参数(一个表示DWORD的较低部分，另一个表示较高部分):

静态uint16_t rotl（uint16_t value_word1，uint16_t value_word2，int16_t shift）{return（shr（value_word1，value_word2，（32-shift））| shl（value_word1，value_word2，shift））}

s20_hash

原始版本:https://github.com/alexwebr/salsa20/blob/master/salsa20.c#L59

代码比较-旧的和新的:

primary_s20_hash vs sub_9862secondary_s20_hash vs sub_9862

第一个更改的片段对应于这原始Salsa20实施的一部分：

For (i = 0;我< 16;z + + i) x[我]=[我]= s20_littleendian (seq + (4 *));

这就是Red Petya是如何实现的:
petya_red_hash_l1

还有来自绿色Petya的新版本

petya_green_hash_l1

s20_littleendian也改变了，但非常轻微-一个bit扩展已添加:

位扩展

第二个改变的片段对应于这原始Salsa20实施的一部分：

For (i = 0;我< 16;++i) {z[i] += x[i];S20_rev_littleendian (seq + (4 * i)， z[i]);｝

这就是Red Petya是如何实现的:
petya_red_hash_l2

来自Green Petya的新版本:

petya_green_hash_l2

该函数的完全重构和实现比较:https://gist.github.com/hasherezade/f59939f5d20ebdfd36343dfcae66bfa9

新的Petya，新的漏洞

正如我们所看到的，作者试图修复在需要32位长单位的情况下使用16位长单位的错误。萨尔萨的新实现看起来几乎然而，由于只有一只虫子，它仍然只需要密钥的8个有效字符，16个!

错误在于函数的无效实现s20_littleendian．这就是这个函数在原始Salsa20中的样子:

Static uint32_t s20_littleendian(uint8_t *b) {return b[0] + (b[1] << 8) + (b[2] << 16) + (b[3] << 24);｝

这就是Petya版本的外观：

Static int16_t s20_littleendian(uint8_t *b) {return b[0] + (b[1] << 8);｝

在之前，Red Petya每秒的密钥字符对加密/解密没有任何重要性。该模式是:c c c c c ? ? ? ? ? c ? c ? c ?——c表示有效的字符和？表示集合中的任意随机字符。

有效的关键,hpLehdbjdcVaMDGj(在第1阶段由Antipetya Live CD）

stage1_red

接受的关键hxLxhxbxdxVxMxGx：

decrypting_red

在当前的情况下，模式有点不同(而且更难利用):cc ? ? cc ? ? cc ? ? cc ? ?．请参见下面的例子:

有效的关键,sHbGrSTkpCrhoKRt(在第1阶段由Antipetya Live CD）

stage1_key

接受的关键,sHxxrSxxpCxxoKxx：

decrypting_petya_green

验证缓冲区

与之前的版本类似，使用验证缓冲区来检查提供的密钥是否有效。但是，验证缓冲区中预期的值发生了变化。在绿色Petya中，如果验证缓冲区被ASCII字符' 7 '(即字节0x37)填充，则传递一个密钥为有效的。现在，字节0x7已经被使用。

检查验证缓冲区的字符:

  • 红色的彼佳:

check_red

  • 绿色的彼佳

check_green

稳定

在红色Petya，中断假CHKDSK造成了真正的问题。因为Petya没有检查哪些扇区被加密了，哪些扇区没有被加密，并且对所有的扇区都重新应用了Salsa。在绿色版中，作者改进了它。

然而，一些Petya的受害者向我们报告，他们遇到了这样的情况，他们买了一个有效的密钥，但磁盘仍然没有被正确解密。这就是为什么我们建议在发现自己感染了Petya之后(在尝试任何解密方法之前)转储整个磁盘的原因。

受害者和袭击者之间的对话片段。到目前为止，用户既没有取回数据，也没有取回比特币:

petya_communication

结论

新的Petya有显著的改进。作者意识到了这个弱点，并试图在代码中进行适当的修复。然而，他们留下了另一个漏洞，削弱了加密。不幸的是,前一种方法，基于遗传算法这次将不会工作-由于不同的细节生成的输出。剩下的解决方案似乎只有8个角色的野蛮力量。关于编写解密器的可能性的进一步研究正在进行中。

将两种完全不同的勒索软件捆绑在一起的想法是新颖和有创意的。发布这款游戏的网络犯罪集团似乎为了在黑市上获得客户而不择手段。可能是同一个组织之前发布过其他勒索软件:幻想和Rokku．他们使用的主要传播方法是通过有针对性的恶意电子邮件活动。所以我们建议对收到的附件要多加注意，要非常谨慎。我们可以期待，他们会在未来带来一些新的想法。

附录

http://www.bleepingcomputer.com/news/security/petya-is-back-and-with-a-friend-named-mischa-ransomware/-哔哔的电脑关于米沙

关于Petya的前一个(红色)版本:

https://blog.必威平台APPmalwarebytes.org/threat-analysis/2016/04/petya-ransomware/