一、前言

大概是25号传出chrome在野漏洞利用的恶意样本，当即收到任务让分析一下，看看能不能复现到利用链，尽管我不太会这玩意，但没办法，只能硬着头皮逝一世了。

二、样本还原

样本拖回来看一眼先

可以看到对<script>部分进行了加密处理，粗略扫了一眼，先把这部分拖出来url解码一下，处理完后大概长这样：

嗯，看得出不够美观，拖过去格式化一下（ https://tool.chinaz.com/tools/jsformat.aspx ）

映入眼帘的一大片16进制，两千多行代码粗略过了一遍，第一遍没怎么看得懂，大概就是在疯狂的各种自定义和混淆，然后看到一个EXP字符串，兴奋了起来，编码不多，手动挨着16进制解一下贴回去，处理完后：

然后跟一下这些字符串，看看是怎么定义的

等我照着全部捋完的时候，传来噩耗（我属实是个s*，为啥不先去百度下字符串）

没关系，再来，直接撸个脚本批量正则匹配hex内容并解码替换
（在这儿贴一份代码，如果有需要的师傅自取（代码写的丑，勿喷））

import re
import binascii

def unhex(s):
    str = s.replace('\\x','').replace(' ','').replace('\n','').replace('  ','')
    str_1 = binascii.unhexlify(str)
    return str_1.decode('utf-8')

f = open(r'F:\1.txt','r+')
ff = open(r'F:\2.txt','w+')
lines = f.readlines()
for line in lines:
    hex = re.findall(r"'(.*?)'",line)
    for i in range(len(hex)):
        line = line.replace(hex[i],unhex(hex[i]))
    ff.write(line)

进制全部处理完后发现还是有很多莫名其妙的字符串：
（其实这样做可能会误处理一些东西，但管不了这么多了，只想大概看看情况先）

说实话，很眼熟，看样子是某种混淆，一时间想不起来，后来经过多方查证发现是obfuscator混淆，好，跑github去处理一下（https://github.com/jscck/crack.js）

三、样本分析与结论

现在大部分代码已经比较清晰了，让我们看看到底在干嘛，还是先粗略扫一遍，发现两处有意思的地方。

最关心的当然是RCE，先跟一下这个字符串

在全文中就出现了两次，跟到这个位置看一下在干嘛，734行定义生成样式，rce字符串就在这里传入，然后在737行看到一个fetch请求（混淆的参数我在后面注释标注了）

跟进到_0x1fdaef，好家伙，就是这个url
（这行下面那个_0x51b全文就在这里出现了这一次，所以未作讨论，咱也不清楚为啥莫名其妙重新定义一次。。。）

再回过头去看，没有什么发现，下面又是一些混淆，到这里有点疑惑，感觉是在根据请求url来进行什么操作，而且名字叫about.asp，访问一下

emmm，这是没了吗。。。不急，再多看一下，

发现从180行开始，定义了一些信息，chrome version、target os，看起来是在收集目标信息，再联想到之前那个about.asp，大部分代码都是在请求此网站响应，于是通篇定位关键词、全局查找被混淆参数，最后分别定位到如下几处：

1. 操作indexedDB数据库（1908-2081）

2.收集浏览器信息（2226-2381）

3.收集主机信息 （2385-2622）

（其实不仅是这些地方，这中间会跳各种混淆函数，但主体大致是集中在这些片段里）

然后结合这些代码再跟进到各个片段的混淆参数进行分析替换，尝试捋出代码逻辑。经过这些操作之后，其实到此我已经感觉这个样本应该是没有包含chrome rce的完整利用链，仅仅是在根据目标的各类信息来判断是否满足利用规则，如果匹配成功则通过漏洞利用的服务器再进行攻击。恶意载荷或许托管在请求的url中（举例）：

后来在网上发现一位国外的师傅也与我的观点大致相同：

结语

当然，也可能是我自身学艺不精导致，本身确实对js不熟（加上混淆真的太严重了，一个混淆参数要跳好几个函数），或许确实存在利用链，只是我没有捋得出来，只能在此给各位师傅分享一下大致过程，含泪下播，溜了溜了。