PowerShell静态分析（Part I）

本文分为三个部分，主要介绍了一种实用的powershell脚本静态分析方法，并基于独立于平台python脚本来执行此任务。

文章将讨论行为分析方法，介绍在powershell脚本中隐藏数据的常见混淆方法，以及如何构建一个评分系统来评估脚本的风险。

简介

在我们深入研究前，需要搞清楚研究的目的。首先，我们希望完成什么？这种静态分析方法的实际情况是什么？这种方法适用于整个安全生态系统的哪个部分？我们如何更好地了解利用它？在这里简要介绍每一个问题。

第一个问题相对简单。我们希望完成什么？在查看了很多powershell脚本，在任何时间都有数千个文件需要评估和分析风险。手动检查它们是非常耗时的，根据经验，动态分析会由于各种原因失败，无法产生准确的结果。因此希望找到一种方法，尽可能多地自动化那些重复繁重的工作。

第二个问题，“这种做法的实际情况如何？“。当你想到静态分析和动态分析时，每种分析都有各自独特的优点和缺点。有些人可能会说一种分析比另一种分析好，但我觉得两者都同样重要且互补。深入研究powershell脚本时：没有上下文的行为在静态分析上几乎毫无意义。也就是说，非恶意脚本和恶意脚本经常表现出相同的行为和功能，因此如果没有上下文或元数据，很难从表面上看出它们的意图。

最后，一个分析powershell脚本中的行为的工具怎样适合安全生态系统。因为每个人都有独特的需求和资源，但脚本分析是对现有能力的增强，并且是一种可以加速分析规模的方法，这样就可以将时间花在构建防御上。

接下来开始深入探讨静态分析的一些核心概念以及这种方法的优缺点。

在powershell中定义行为

在我们讨论设计和概念之前，我们需要定义这个上下文中的“行为”，powershell是一种Microsoft脚本语言，powershell还解释和执行本机Windows命令行、dotnet代码。例如，powershell脚本中的以下三行都会产生相同的输出，即使它们是三个不同的调用方法。

Get-Date # PowerShell cmdlet
date # Command-line native Windows application
[System.DateTime]::Now # dotNET

这种灵活性使得分析变得更加困难，因为我们需要解释多种表达相同事物的方式。

当描述一个行为时，不一定是任何命令或命令的变体。举例来说，“get-date” cmdlet可能会是“枚举”行为，因为它正在检索运行脚本主机系统相关的数据。类似地，也可以将dotnet类“new object system.net.webclient.downloadfile”分组为“downloader”行为，因为它将用于远程检索文件。

动态与静态分析

脚本行为需要明确识别，但有时它们还不足以确定脚本是良性的还是恶意的。这些行为如何利用是决定的关键因素。那么我们如何推断意图呢？下面两个示例，它们在表面上看起来很相似，并且表现出相同的以下行为：“downloader”、“sleeps”、“enumeration”和“one liner”。

在动态恶意软件分析进入视野之前，静态查看文件是确定样本是否存在恶意行为的主要方法。随着时间的推移和动态分析的发展，越来越多的行业转向工具环境、产品和防御响应策略，围绕恶意文件的动态特性而不是静态属性。动态分析提供了大量的信息，在这个过程中投入的资源、技术和时间大大减少，因此行为分析成为主导力量。

如果一个powershell脚本，该脚本下载并执行另一个脚本，枚举系统信息，使用压缩和大量base64，分析人员第一个想法可能是它是恶意的，因为这些是动态分析恶意软件的日常行为。但在下图示例中，它只是一个powershell脚本，用于显示动画。

确定意图

为了确定意图，需要建立一个“基本事实”，并对脚本进行评分。为此，需要手动分析现实环境中的数千个良性和恶意powershell脚本，分别标记它们良性或恶意。当一个已知的恶意脚本低于设定的阈值时，需要把精力集中在提高其余样本的准确性上。手动分类的过程可以接触到所有可以想象到的脚本——各种各样的管理脚本和引导脚本。

在对样本集进行分类之后，能够更加完美地解决意图问题。在查看脚本并开始分析行为的过程中，还需要考虑行为的权重以及它和脚本的总体意图的关系。

例如，只下载和执行可执行文件的脚本与相同行为但使用模糊处理且完全包含在一行的脚本相比，当它同时生成日志或代码结构良好时，就不太可能是恶意的。类似地，一旦一个行为被识别出来，就可以观察它在良性和恶意脚本中的分布。还需要观察脚本中某些“罕见性”行为，并相应地调整评分权重。

识别重要的行为并找出如何对它们进行适当的评分是这个分析的核心。一旦行为被创建并分配分数，就可以创建一个风险梯度标度，我们可以将每个样本映射到其中，并找到一个“最佳点”，开始进行更精细的调整。下面一个图表描述了powershell脚本中用作静态评分风险的准则等级。

将恶意脚本的得分设定在6.0左右，低于这个临界值，风险会降低。

需要考虑的事情

最后，需要考虑以下几点：

PowerShell是一种非常灵活的语言。它提供了多种方法来调用相同的功能，最终无法静态地捕获所有内容，特别是在恶意脚本作者试图规避检测的情况下。有时会错过一些识别行为指标，在这些情况下，策略上选择了谨慎处理，允许这些恶意脚本得分低于阈值，而不是过分重视某些行为导致良性脚本得分过高。

在分析过程中的另一个现象是良性脚本通常是独立的，因为它们是完全独立的，可以在没有参数或依赖关系的情况下运行；恶意脚本通常是一个大的难题中的一小部分，在拼图中占有较小的一块。

无论在尝试构建行为时脚本行为有多大或多小，当仅基于函数的行为失败时，我仍然可以使用上下文（“invoke dllinjection”）关键字或元数据（如字符频率分析）作为自己的行为模型来影响评分。

此外还需要考虑隐藏行为。因此，如果可以清楚地看到脚本内容中的恶意url，但无法识别它是如何从url下载负载的，那么仍然可以推断该脚本有一个未知的下载行为。这些推断的行为对于进一步的搜索和分析是一个很好的基础。

总结

简要回顾上面介绍的一些概念和想法。

PowerShell是一种极其丰富的脚本语言，PowerShell中的行为不限于单个或简单函数调用，需要灵活地识别它们。因此，要分析行为，我们需要对内容进行去模糊、分解和规范化，以便我们可以将类似的概念和从动态分析中应用到静态分析中。

当静态分析powershell脚本时，应思考如何根据上下文提示和加权评分来确定行为的意图。

在下一篇文章中，将从一个更技术的角度切入，开始研究常见的混淆技术和方法，以便在powershell中发现隐藏数据。此外，将介绍在分析脚本中观察到的行为，以及它们如何影响脚本的总体评分。

*参考来源： unit42 ，由Kriston编译，转载请注明来自FreeBuf.COM