《Invoke-Deobfuscation:AST-Based and Semantics-PreservingDeobfuscation for PowerShell Scripts》论文阅读

2. Invoke-Deobfuscation:AST-Based and Semantics-PreservingDeobfuscation for PowerShell Scripts

这篇文章讲了基于AST的，变量追踪的，保留语义的一个去混淆工具，是开源的

https://gitee.com/snowroll/invoke-deobfuscation?_from=gitee_search

介绍

主要工作

利用AST的可恢复节点来精确的识别模糊片段，通过Invoke函数和变量跟踪来模拟恢复过程

‍

现存方法

去混淆主要分为3步

1. 识别混淆片段
2. 去掉混淆
3. 重建脚本

识别混淆

PSEDM, PSDecode, PowerDrive, and PowerDecode 设计了一系列正则表达式去匹配混淆的片段，这些基于正则表达式的方法忽略了脚本的语法信息

Li et al.(也就是轻量级的那个论文作者) 设计了一个基于机器学习的分类器去识别模糊的脚本片段，这非常依赖训练的数据

‍

‍

去掉混淆

1. 预定义的恢复规则

   [PSDecode, PowerDrive, Powerdecode] 这种方法仅仅对一部分特别混淆技术有用，但是忽略了语法，所以经常出错

2. 覆盖函数

   [PSDecode, PowerDrive, Powerdecode] 这种方法用来处理特定函数的混淆的参数，比如Invoke-Expression，

3. 直接执行

   [Powerdecode, Li et al轻量级去混淆工具] 由于大多数混淆后的脚本片段中保存着恢复代码 + 混淆数据，所以直接执行也可以，但是这部分有个缺点，就是容易忽略掉上下文，有时候这些片段中含有变量，忽略了上下文就无法识别这个变量，即无法去混淆。

重建脚本

先有的所有的脚本重构都是上下文无关的，因此他们恢复后在语法或语义上可能存在错误

挑战

1. 精确识别混淆的片段
2. 正确恢复混淆的片段
3. 有效重建脚本，使其在语法和语义上与原始脚本保持一致

‍

我们的方法Invoke-Deobfuscation

‍

基本思路

1. 基于token和recoverable nodes of AST 识别混淆片段
2. 利用跟踪变量算法 来获取混淆片段的上下文，并且利用Invoke函数来恢复他们
3. 基于后续遍历AST的方法重构脚本，而且在合适的位置严格的替换混淆的片段，来尽可能的保持原来的语义

样本

样本 2,025,175 wild malicious samples –预处理-> 39,713 PowerShell scripts

‍

评估

从4个方面来评估 Invoke-Deobfuscation

1. 处理不同混淆技术的能力
2. 去混淆的效力和效率
3. 语义一致性
4. obfuscation mitigation(混淆减轻的能力？？)

‍

和 PSDecode， PowerDriver, PowerDecode, 和Li et al 这 4中对比

经过评估，Invoke-Deobfuscation 是表现最好的工具

1. 足够强壮，可以处理几乎所有已知的混淆
2. 有效且稳定
3. 对于恢复关键信息，IP, URL等，Invoke-Deobfuscation 恢复的数量是其他工具的两倍多（Datacon 2022比赛，，，）​
4. 恢复的结果能够与原始脚本在语义上保持一致
5. 可以显著的减轻脚本混淆

‍

‍

‍

背景和动力

PowerShell 和 PowerShell 攻击

PowerShell 是命令行shell，也是一门脚本语言，他提供了对于一个计算机内核史无前例的权限，包括对Win32API不限制的使用。它还是跨平台的，并且预装在Windows系统上，所以PowerShell已经变为了大量攻击者的喜欢的工具。

#PowerShell 非常广泛的使用在网络攻击中，比如勒索软件，钓鱼邮件，持续性威胁等等，攻击者能够利用恶意的PowerShell脚本在受害者电脑上安装木马，偷取机密信息或者获得管理员权限。PowerShell攻击不仅能从远程网址下载可执行的文件，并且可以做到不落地执行，这样就绕过了传统的基于文件的防御方法。#​

‍

针对POWERSHELL的混淆技术

Powershell有一堆混淆技术，针对其复杂性，把它分为三个等级

原始样本：

L1:

这种混淆技术只具有视觉上的混淆性

比如，加入空白空格，随机大小写，反引号，别名

L2:

这种级别的混淆技术可以修改原始脚本的词法特性 和AST的层次结构，但是仍然保留着原始脚本的字符级别的信息

L3:

相比L2，去除掉字符级别的信息

比如：Base64， ASCII等编码都属于这种混淆技术

‍

混淆对恶意检测的有效性

混淆后的PowerShell脚本能够隐藏掉原始脚本的意图，并且很容易的避开反病毒软件的检测。

当前的恶意检测模型主要取决于字符集的特点或者AST特征，然而这些都能很容易的被混淆完全的改变（这里的模型我感觉说的应该是人工智能方面的模型）

‍

方法论

Invoke-Deobfuscation 框架

‍

主要分为3个阶段

1. 令牌解析
2. 基于AST的变量跟踪和恢复
3. 重命名+格式化代码

令牌解析

令牌解析使用脚本的词汇信息来恢复混淆，大多数的在L1级别的混淆技术都与令牌相关。

用微软的官方库System.Management.Automation.PSParser​去tokenize， 每个令牌都有许多属性，比如内容，开始位置，长度等，我们利用这些属性去恢复原始的token，并将他们组合来形成去混淆的脚本。

‍

图3表示一个简易的令牌解析的过程

逆序的处理顺序允许我们在不解析新脚本的情况下识别未处理的令牌。最终能够得到一个在令牌级别没有混淆的脚本。

‍

基于AST的恢复

不管这个混淆后的脚本多么复杂，他都是原始脚本在经过一系列变化后得到的。混淆后的脚本片段通常包括 混淆的数据以及它的恢复算法，我们称之为可恢复的脚本片段（Recoverable Pieces）

去混淆的关键就是在混淆后的脚本中识别这些Recoerable Pieces​

‍

识别可恢复的片段

我们使用Powershell AST上特定类型的节点 的内容来识别可恢复的脚本片段。

1. PowerShell AST上的每一个节点都是语法上有效的，其中包括Recoverable pieces。
2. 我们能够获得原始的片段通过执行这个Recoverable pieces. 例如，’he’ + ‘llo’ –> ‘hello’

因此，我们分析了所有的PowerShell的AST节点的类型，发现这些类型的节点的内容通过执行后可以获得字符串。^(怎么发现的？？？这个地方感觉可以优化一下。)^

我们叫这些类型的节点为Recoverable nodes

1. PipelineAst
2. UnaryExpressionAst
3. BinaryExpressionAst
4. ConvertExpressionAst
5. InvokeMemberExpressionAst
6. SubExpressionAst

我们提取了这个可恢复节点的内容作为Recoverable Pieces. 基于可恢复的节点，我们不仅能识别已知的混淆技术，还可以识别未知的混淆技术。

‍

基于Invoke的恢复

把Recoverable Pieces转为Script Block，然后利用成员函数Invoke去执行他本身, 比如

$a = {'{0}{1}{2}' -f "i", "e", 'x'}
$a.invoke()

# iex

对于不同类型的执行结果，我们将它们转换为相应的字符串形式作为恢复结果，以保留它们的语义。比如得到结果是123，如果他的类型是字符串，则结果为’123’，如果是数字，则是123

如果执行结果不能以字符串的形式表示，比如是Object，那么我们保留可恢复的脚本片段。

‍

对于可恢复的脚本片段可能包含很多与恢复过程不相关的命令，比如Restart-Computer​, Start-Sleep​等。因此，我们创建了这些命令的阻止列表，以加快去混淆的速度。如果可恢复的脚本片段中含有这些不相关的命令，我们不去执行他们，为了安全，我们的工具应该运行在独立的沙盒中。

‍

变量追踪

由于上下文的缺乏，我们不能直接执行这些含有变量的Recoverable pieces

为了克服这个挑战，我们使用符号表来记录脚本中出现的变量的范围和值，伪代码1显示了变量^（这个算法，不能修改循环中的遍历 \）^​追踪^（这个算法，不能修改循环中和条件表达式中的变量）^​的算法。^(这个算法，不能修改循环中的遍历 )^

通过下面这个例子更容易理解上面的算法

# PowerShell代码如下  
$a = 1
Write-Host $a
# 解析为AST并可视化后为

[NamedBlockAst]: $a = 1
    Write-Host $a  
--[AssignmentStatementAst]: $a = 1
----[VariableExpressionAst]: $a   
----[CommandExpressionAst]: 1   
------[ConstantExpressionAst]: 1
--[PipelineAst]: Write-Host $a  
----[CommandAst]: Write-Host $a
------[StringConstantExpressionAst]: Write-Host
------[VariableExpressionAst]: $a

我们通过AST的结构来记录出现在脚本中的每一个变量的范围。我们把变量分为3类，局部变量，全局变量，环境变量，我们仅仅需要记录局部变量的范围。

‍

我们后序遍历AST，并记录当前访问节点的范围​。

仅仅访问6种类型的节点的时候，当前节点的范围深度会增加或降低。变化取决于遍历的方向，从父级到子级或者反过^（这里暂时不明白）^

1. NamedBlockAst
2. IfStatementAst
3. WhileStatementAst
4. ForStatementAst
5. ForEachStatementAst
6. StatementBlockAst

我们通过执行分配表达式来记录变量在符号表中的值​

通过AssignmentStatementAst​，我们能够识别变量和他们的分配表达式。当这个分配表达式含有未知的变量，并且这个变量是不在符号表里的时候，我们不执行这个变量表达式，而且放弃记录这个变量。

对于环境变量，我们能够使用 Get-Variable 来获得他们正确的值

我们当前的变量跟踪仍然后许多限制^（确实。。）^

‍

Invoke-Expression和PowerShell

复杂的混淆脚经常包含多层混淆​，比如Invoke-Expression 就可以把后面的字符串作为脚本去执行，而字符串中可能还含有Invoke-Expression等。

‍

处理多层混淆的关键就是识别Invoke-Expression​和PowerShell​，然而攻击者经常使用不同的方法来混淆这些命令，例如，.($pshome[4] + $pshome[30] + 'x')​就等同于 Invoke-Expression​, 可以通过变量跟踪将其恢复为.('iex')​, iex是Invoke-Expression的别名，. 是可以把后面的字符串作为命令，其他的Invoke-Expression的形式为

iex
'xxx' | iex
&'iex'

我们能够通过基于AST的变量追踪和恢复来识别Invoke-Expression的不同格式。

‍

PowerShell能够执行Base64-encoded命令，通过-EncodedCommand​，这个参数也有各种形式，比如-e​, -eNc​等

我们转变参数为小写，并且使用'-encodedcommand'.StartsWith($param)​去决定是否这个参数是 -EncodedCommand​，比如'-encodedcommand'.StartsWith('-enc')​为True

‍

为了处理多层混淆，我们转换Invoke-Expression和PowerShell的参数，而且去混淆。

重复这个过程，，直到脚本的恢复过程不再发生转换，通过这种方式，我们可以从多层混淆的脚本片段中恢复出原始的脚本片段

‍

脚本重建

通过后序遍历的方法去进行脚本重建，当访问一个节点的时候，用它的孩子节点的内容去替换它

如果内容是混淆的，则用它的恢复结果去替换它

最终，我们能够得到完整的去混淆的脚本，通过遍历这个AST的根节点。

我们在合适的位置替换混淆脚本片段，以使去混淆的脚本 与 混淆的脚本 语义保持一致

这个图是一个例子

最终，访问AST的根节点就可以得到最终的去混淆的脚本。

‍

重命名和格式化

重命名那些随机命名的变量和函数以及重新格式化代码可以使分析人员共容易分析脚本。

我们根据元音和特殊字符的比例来确定字符串是否是随机的。

Hayden[29]指出，在普通美式英语中，元音的比例约为37.4%，因此我们假设当英语字符中元音的比例不在32%到42%之间时，字符串是随机的。当一个字符串中的英文字母的比例小于10%时，字符串是随机的，然后用var{num}​ 和 func{num}​去重命名随机的变量

最后，我们通过删除随机空白字符并用标准格式缩进来重新格式化代码。如图7所示，随机变量名被替换，随机空白字符被删除，此外，这个模块是可以扩展的。

‍

‍

实施和评估

在这一节中，首先介绍Invoke-Deobfuscation的实施，然后再与其他4个工具进行比较，PowerDrive [17], PSDecode [16], PowerDecode [18], Li et al. [19]

‍

[16] “Psdecode - powershell script for deobfuscating encoded powershell scripts,” https://github.com/R3MRUM/PSDecode.
[17] D. Ugarte, D. Maiorca, F. Cara, and G. Giacinto, “Powerdrive: Accurate de-obfuscation and analysis of powershell malware,” in Springer DIMVA, 2019.
[18] G. M. Malandrone, G. Virdis, G. Giacinto, and D. Maiorca, “Powerdecode: a powershell script decoder dedicated to malware analysis,” in ITASEC, 2021.
[19] Z. Li, Q. A. Chen, C. Xiong, Y . Chen, T. Zhu, and H. Yang, “Effective and light-weight deobfuscation and semantic-aware attack detection for powershell scripts,” in ACM CCS, 2019.

主要从4个方面进行比较

1. 处理常见混淆方法的能力
2. 去混淆的效力和效率
3. 行为一致性
4. obfuscation mitigation

实施

Invoke-Deobfuscation用PowerShell编写，源码2500行，而且工具跨平台。

Invoke-Deobfuscation 主要包含3个模块，每个模块独立使用^（在Datacon的比赛中应该只用去混淆的那个就行）^

为了避免出现语法错误，在去混淆的过程中，每个步骤之后都要检查结果的语法，如果有语法错误，则跳过deobfuscation步骤

‍

评估方法

数据收集

在奇安信的帮助下，我们收集了2025175个恶意样本，根据来源，分为2类，第一类是由反病毒软件标记为powershell的样本，第二类是由TrID或文标记为powershell的样本。

我们利用样本的语法信息和文本特性删除了无效的或重复的PowerShell样本。然后我们得到了1127349个PowerShell脚本。

我们发现同一家族中许多恶意脚本的结构高度相似，所以有去除了这些结构相似的样本。

经过预处理，最终得到了39713个样本，以前的数据集只包含少数类型的混淆技术[30]，甚至来自手动生成[19]。与之前的数据集相比，我们数据集中的脚本的混淆技术、恶意功能和内容结构更加多样

[30] J. White, “Pulling back the curtains on encodedcommand powershell attacks,” https://unit42.paloaltonetworks.com/unit42-pulling-back-the-curtains-on-encodedcommand-powershell-attacks

这些脚本的文件大小从8字节到26 MB，数据集的总大小为7.75 GB。

‍

混淆的量化

我们通过对已知的混淆进行评分，进而来量化样本的混淆。比如，在前面的时候，将混淆分为3个等级，L1,L2,L3，比如L1就1分，我们为每个脚本中出现的每种类型的混淆只打分1次，以获得脚本的最终混淆分数。

‍

评估结果

混淆能力

去混淆的能力取决于它的精确的识别混淆 + 准确的去除混淆

我们利用已知的混淆技术去混淆命令 write-host hello​并把混淆后的片段放在3个不同的位置

1. 单独一行
2. 分配表达式
3. 管道

比如假如混淆后的片段是'a'+'b'​ 则分为'a'+'b'​, $tmp='a'+'b'​, 'a'+'b' | out-null​

对于某种特定的混淆技术，如果一个工具能够恢复出这3个位置的混淆片段（当然，这3个位置的混淆片段肯定是由这种特定的混淆技术去混淆的，不能是其他的），则说明这个工具 针对这种混淆技术 有完全的去混淆能力。

为了比较，对之前的工具做了点稍稍的改动，比如

PSDecode、PowerDrive和PowerDecode使用不同的层来存储不同阶段的混淆结果，我们仅仅保留最后一层作为最终结果。

Li 等人使用分类器来识别AST混淆的子树，但是它这个模型未公开，此外，Li 等人只处理源代码中类型为PipelineAst的子树，因此我们删除了分类模块，并使其工具遍历所有根为PipelineAst的子树，这只会影响一点点运行时间。

‍

这个图是不同工具的去混淆能力的比较结果

由于变量追踪的局限性，我们无法处理经常有循环语句的空白编码混淆^（所以这种编码是啥玩意，，，暂时看不懂）^，然而，这种空白编码混淆仅占数据集的0.1%

‍

作为比较

PSDecode, PowerDrive和PowerDecode仅仅能处理一些混淆技术，因为它们使用正则表达式​来匹配特定的混淆技术，而忽略了脚本的语法。此外，正则表达式需要设计不同的模式来匹配不同的混淆技术，这是不健壮的，无法识别复杂的混淆脚本片段

‍

Li 等人只处理PipelineAst节点上的混淆，该节点是粗粒度​的，将会错过许多混淆处理的脚本片段。

它们无法处理识别和处理最后2个位置的混淆，即上面的 分配表达式 和 管道

此外，由于缺乏上下文，它们无法处理带有变量的混淆技术。

‍

由于这四种工具都没有分析脚本的token，所以它们无法处理在token级别的混淆。

‍

去混淆的效果和效率

我们比较不同工具去混淆的效果​，通过不同工具去混淆后的脚本中保留的关键信息的数目

同时，我们记录这些工具的去混淆时间来作为效率​的评估

‍

我们抽样了100个大小介于97byte - 2KB之间的混淆后的PowerShell代码，挑选了4中关键信息

1. .ps1 文件（通常表示恶意脚本路径）
2. PowerShell命令
3. URL
4. IP

这4种类型的信息对于恶意样本分析来说都是有意义的

‍

为了更好的比较，我们采用手动的去混淆的结果作为基准，然后我们分别提取了这4种类型的关键信息。除此之外，还有12个多层混淆的样本，因此我们比较不同的工具处理多层混淆的能力。

‍

​

‍

先看图5（Effectiveness）

Invoke-Deobfuscation相比其他工具恢复了更多的关键信息，并且平均96.8%的结果是跟手动处理相同的。这是因为 Invoke-Deobfuscation可以基于AST可恢复节点能够识别和恢复更多的混淆片段。

再看图6 （Efficiency）

Invoke-Deobfuscation表现的最有效率和稳定。他的平均处理时间是1.04秒，是所有工具平均时间最少的一个，而且其他的工具处理时间波动比较大，甚至超过了10秒，由于其他工具可能执行了与恢复不想关的命令，比如network connect等， 由于Invoke-Deobfuscation能够通过他的内置的阻止列表，来阻止这些不相关的命令的执行，所以它处理混淆的速度很快。

‍

​

‍

再看表三（处理多层混淆的能力）

因为多层混淆脚本经常需要调用invoke-Expression 和 PowerShell， 所以Invoke-Obfuscation能够处理。

PSDecode、PowerDrive和PowerDecode利用overriding function^(这里overriding function是啥玩意，由于没看这3篇对应的论文，所以我也不知道是啥。。。等之后看了再回来弄吧)^获得未混淆的脚本，但是overriding function只能处理单层混淆。

PowerDecode设计了Unary Syntax Tree Model来处理多层混淆，所以他的效果要较好一点，但是如上面的Table II，他只能处理一部分混淆技术的混淆

Li 等人不能处理多层混淆。

‍

行为一致性

为了量化分析，我们使用了行为一致性来代替语义的一致性。

为了简化分析，我们只比较了原始样本和去混淆后的样本的网络行为，比如DNS查询和TCP连接

使用TianQiong 沙盒来收集网络行为。

​

减轻混淆

为了评估不同工具减轻复杂脚本上的混淆的能力，我们统计并比较原始样本和去混淆样本​中已知混淆技术的比例

选了3346个高混淆分数的样本，并且限制所有的工具，每个样本去混淆的时间为4分钟。

基于AST的可恢复节点和正则表达式，我们可以精确地识别每种已知的混淆技术

‍

​

‍

案例研究

为了直观的比较和分析不同工具的去混淆效果，用不同工具去处理同一个样本，这个样本带有L1, L2, L3级别的混淆。

讨论

语义一致性

现有工具的去混淆结果在语义上通常与其对应的混淆脚本不一致

正则表达式经常标识语法无效的脚本片段[16]-[18]，基于机器学习的分类器严重依赖于训练数据的质量[19]，预定义的恢复规则[16]–[18]和重写函数[16]，[18]只能处理一些特定的混淆。由于缺乏上下文，直接执行[18]、[19]可能会得到错误的恢复结果。

[16] “Psdecode - powershell script for deobfuscating encoded powershell scripts,” https://github.com/R3MRUM/PSDecode.
[17] D. Ugarte, D. Maiorca, F. Cara, and G. Giacinto, “Powerdrive: Accurate de-obfuscation and analysis of powershell malware,” in Springer DIMVA, 2019.
[18] G. M. Malandrone, G. Virdis, G. Giacinto, and D. Maiorca, “Powerdecode: a powershell script decoder dedicated to malware analysis,” in ITASEC, 2021.
[19] Z. Li, Q. A. Chen, C. Xiong, Y . Chen, T. Zhu, and H. Yang, “Effective and light-weight deobfuscation and semantic-aware attack detection for powershell scripts,” in ACM CCS, 2019.

Invoke-Deobfuscation利用令牌解析和AST的可恢复的节点，能够精确的识别混淆的片段，此外，在这个变量追踪的帮助下，Invoke-Deobfuscation能够以上下文感知的方法去恢复正确的结果。此外，Invoke Deobfuscation严格替换已混淆的脚本片段，以保持Deobfuscation脚本的语义一致。

与AMSI比较

AMSI是 Windows反恶意软件扫描接口 (AMSI)

‍

ASMI是一个多功能的接口，它允许文件，内存，流扫描，URL/IP信誉检测和其他的检测[14]

[14] “Antimalware scan interface (amsi),” https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal

在提交给脚本引擎之前，这个脚本可能会经过若干层的去混淆。AMSI能够获得最终的提供给脚本引擎的脚本。

然而，此方法只能处理需要由InvokeExpression或PowerShell调用的特定类型的混淆

当这个混淆的脚本片段不需要被调用的时候，AMSI不能获得去混淆的片段，例如，AmsiUtils被AMSI对待为一个恶意的字符串，我们可以很容易的去绕过检测，比如”Amsi” + ‘Utils’

‍

尽管AMSI在处理许多混淆脚本上是很强大的，但是由于固有的机制，不同的混淆技术很容易绕过他

我们在虚拟机上运行前面IV-C2提到的100个PowerShell样本，并分析AMSI捕获的最终脚本，我们的分析标明，如第III-B4节所述，Invoke-Deobfuscation鱼油与AMSI相似的去混淆能力，除此之外，Invoke Deobfusion足够强大，可以处理不同的混淆技术

‍

限制

变量追踪

放弃记录条件语句中的变量和循环语句中的变量

‍

复杂混淆

大多数的混淆数据和他们的相应的恢复算法都在相同的混淆片段里面，因此识别这些混淆片段并且执行就能够恢复原始的脚本片段。即使他们在不同的位置，我们也能够处理用变量追踪的方法去处理他们。

然而，如果攻击者把这个恢复算法放进了函数里，然后利用函数去恢复数据，则本文方法很难追踪这个混淆的链，甚至攻击者能够使用函数嵌套来反分析。

‍

相关的工作

检测恶意脚本

最近，许多基于机器学习或者深度学习的恶意脚本检测模型已经提出来了，这些模型基于不同的特征对恶意样本进行分类，如文本[8]、[26]、[27]、令牌和AST节点特征[9]、[10]。

[8] D. Hendler, S. Kels, and A. Rubin, “Detecting malicious powershell commands using deep neural networks,” in ASIACCS, 2018.

[9] G. Rusak, A. Al-Dujaili, and U.-M. O’Reilly, “Ast-based deep learning for detecting alicious powershell,” in ACM CCS, 2018.
[10] Y . Fang, X. Zhou, and C. Huang, “Effective method for detecting malicious powershell scripts based on hybrid features,” Neurocomputing, 2021.

[26] Choi, Sunoh, “Malicious powershell detection using attention against adversarial attacks,” Electronics, 2020.
[27] S. Choi, “Malicious powershell detection using graph convolution network,” Applied Sciences, 2021.

因为混淆很容易改变这些特征，许多研究者提议检测混淆的样本

[34] D. Bohannon and L. Holmes, “Revoke-obfuscation - powershell obfuscation detection framework,” https://github.com/danielbohannon/Revoke-Obfuscation.
[35] S. Aebersold, K. Kryszczuk, S. Paganoni, B. Tellenbach, and T. Trowbridge, “Detecting obfuscated javascripts using machine learning,” in ICIMP, 2016.
[36] M. Jodavi, M. Abadi, and E. Parhizkar, “Jsobfusdetector: A binary pso-based one-class classifier ensemble to detect obfuscated javascript code,”in IEEE AISP, 2015.

但是混淆的样本和恶意的样本之间并没有直接的联系，所以，已经存在的检测方法去正确的检测混淆的恶意的PowerShell样本是非常困难的。

混淆技术

二进制混淆

攻击者经常使用实时的加壳技术来混淆恶意代码并阻止静态分析。

‍

脚本混淆

各种混淆技术可以帮助恶意脚本逃避防病毒软件的检测[40]，[41]。Wang等人[42]提出了一种基于控制流转换的JavaScript代码混淆技术。有许多流行的混淆工具，例如Invoke Obfusion[12]、PowerSploit[43]、Empire[44]等，它们提供了丰富的混淆技术，如第II-B节所述。

[40] W. Xu, F. Zhang, and S. Zhu, “The power of obfuscation techniques in malicious javascript code: A measurement study,” in IEEE MALWARE,2012.
[41] A. Balakrishnan and C. Schulze, “Code obfuscation literature survey,”CS701 Construction of compilers, 2005.
[42] Z. Y . Wang and W. M. Wu, “Technique of javascript code obfuscation based on control flow tansformations,” in AMM, 2014.
[43] “Powersploit - a powershell post-exploitation framework,” https://github.com/PowerShellMafia/PowerSploit.
[44] “Empire - a powershell and python post-exploitation agent,” https://github.com/EmpireProject/Empire.

[12] D. Bohannon, “Invoke-obfuscation - powershell obfuscator,” https://github.com/danielbohannon/Invoke-Obfuscation.

‍

去混淆技术

‍

常见的去混淆技术分为2种，动态分析和静态分析，动态分析通常在隔离环境中执行样本，并检测其行为[45]-[47]。它只能从脚本的行为推断脚本的意图，并且代码覆盖率很低

[45] G. Lu, K. Coogan, and S. Debray, “Automatic simplification of obfus-
cated javascript code,” in IEEE ICISTM, 2012.
[46] B. Feinstein, D. Peck, and I. SecureWorks, “Caffeine monkey: Auto-
mated collection, detection and analysis of malicious javascript,” Black
Hat USA, 2007.
[47] U. Bayer, A. Moser, C. Kruegel, and E. Kirda, “Dynamic analysis of
malicious code,” Journal in Computer Virology, 2006

静态分析需要识别混淆的数据和相应的恢复算法，这通常非常困难。

基于正则表达的工具，比如PSDecode [16], PowerDrive[17], PowerDecode [18]，他忽略了脚本片段的语法以至于他们不能精确的识别混淆片段。

Li等人[19] 利用基于机器学习的分类器和AST特征来识别混淆的脚本片段，然而，由于缺乏上下文环境和错误的替换，他们的工具方法经常遭遇语法错误和语义不一致， Invoke Deobfusion利用AST上的可恢复节点来识别混淆的片段，并实现变量跟踪以减轻上述挑战

‍

总结

在本文中，我们提出了Invoke Deobfusion，这是第一个基于AST的、具有变量跟踪功能的保留语义的PowerShell脚本Deobfuscation工具。

Invoke-Deobfuscation使用AST的令牌和可恢复的节点来精确的识别模糊脚本片段，跟踪变量的值和范围，并模拟脚本片段的执行，以获得正确的恢复结果。

为了保持脚本的原始语义，Invoke Deobfusion严格处理替换。

我们的评估表明，Invoke Deobfusion在处理各种混淆技术、消除混淆有效性、保持脚本语义以及减轻野生样本混淆方面优于最先进的工具。

InvokeDeobfusion恢复的关键信息量是其他工具的两倍多，并且InvokeDeoBfusion的100%的Deobfuscation结果具有与原始样本相同的行为。

此外，Invoke-Deobfuscation能够减少野生样本混淆分数46%

‍

‍