有关Windows防恶意软件扫描接口（Antimalware Scan Interface，AMSI）的介绍，请参阅Antimalware Scan Interface (AMSI)。

作为应用程序开发人员，您可以积极参与恶意软件防御。具体而言，您可以帮助保护您的客户免受基于动态脚本的恶意软件和非传统网络攻击的威胁。

举个例子，假设您的应用程序支持脚本化：它接受任意脚本，并通过脚本引擎执行。在准备将脚本提供给脚本引擎执行时，您的应用程序可以调用Windows AMSI API来请求对内容进行扫描。这样，您可以在决定是否执行脚本之前，安全地确定脚本是否是恶意的。

即使脚本是在运行时生成的，这一点仍然适用。脚本（无论是恶意的还是其他类型的）可能经过多次解混淆的过程。但最终，您需要向脚本引擎提供明文、未混淆的代码。这就是您调用AMSI API的时机。

下面是AMSI架构的示例，其中您自己的应用程序被表示为其中一个“Other Application”框。

Windows的AMSI接口是开放的，这意味着任何应用程序都可以调用它，任何注册的防恶意软件引擎都可以处理提交给它的内容。

我们不需要将讨论局限于脚本引擎。也许您的应用程序是一款通信应用程序，在向客户显示即时消息之前会对其进行病毒扫描。或者您的软件是一款游戏，在安装插件之前会对其进行验证。使用AMSI有很多机会和场景可供使用。

AMSI应用

让我们来看看AMSI的实际运行情况。在这个例子中，Windows Defender是调用AMSI API的应用程序。但您也可以从自己的应用程序中调用相同的API。

下面是一个使用异或编码技术隐藏意图的脚本示例（无论这个意图是良性的还是恶意的）。为了说明，我们可以假设这个脚本是从互联网上下载的。

为了增加趣味性，我们可以在命令行中手动输入这个脚本，这样就没有实际的文件可供监视。这反映了所谓的“无文件威胁”。这不像简单地扫描磁盘上的文件那样简单。这种威胁可能是一种仅存在于计算机内存中的后门。

下面是在Windows PowerShell中运行该脚本的结果。您将看到，仅通过使用标准的AMSI测试样本签名，Windows Defender就能够在这种复杂的情况下检测到AMSI测试样本。

AMSI 与 JavaScript/VBA 集成

下面的示例描述了另一个示例的端到端流程，其中我们展示了AMSI与Microsoft Office中宏执行的集成。

◆用户收到一个包含（恶意）宏的文档，该宏通过使用混淆、密码保护文件或其他技术来规避静态防病毒软件的扫描。

◆然后，用户打开包含（恶意）宏的文档。如果文档在受保护视图中打开，则用户点击“启用编辑”以退出受保护视图。

◆用户点击“启用宏”以允许宏运行。

◆当宏运行时，VBA运行时使用循环缓冲区来记录与调用Win32、COM和VBA API相关的数据和参数。

◆当观察到特定的被认为是高风险的Win32或COM API（也称为触发器）[2]时，宏执行被停止，并且循环缓冲区的内容被传递给AMSI。

◆注册的AMSI反恶意软件服务提供商会回复一个判决，以指示宏行为是否恶意。

◆如果行为是非恶意的，则宏继续执行。

◆否则，如果行为是恶意的，则Microsoft Office会响应警报[3]并关闭会话，而防病毒软件可以对文件进行隔离处理。

这对你来说意味着什么？

对于Windows用户来说，任何使用混淆和规避技术的恶意软件都会在Windows 10内置的脚本宿主中被自动进行比以往更深入的检查，提供额外的保护层级。

作为应用程序开发人员，如果您希望从（并保护您的客户免受）潜在恶意内容的额外扫描和分析中受益，请考虑让您的应用程序调用Windows AMSI接口。

作为防病毒软件供应商，您可以考虑实现对AMSI接口的支持。这样做可以让您的引擎对应用程序（包括Windows 10内置的脚本宿主）认为可能是恶意的数据有更深入的了解。

有关无文件落地威胁的更多背景信息

您可能对Windows AMSI旨在帮助您防御的无文件威胁类型的更多背景信息感兴趣。在本节中，我们将看一下在恶意软件生态系统中所发生的传统猫鼠游戏。

我们将以PowerShell为例。但是，您可以利用我们将演示的相同技术和流程来处理任何动态语言，比如VBScript、Perl、Python、Ruby等。

这是一个恶意的PowerShell脚本示例。

虽然这个脚本只是在屏幕上显示一条消息，但恶意软件通常更加恶毒。但是，您可以轻松编写一个签名来检测这个脚本。例如，该签名可以在用户打开的任何文件中搜索字符串"Write-Host 'pwnd!'"。太好了，我们已经检测到了我们的第一个恶意软件！

然而，在被我们的第一个签名检测到之后，恶意软件的作者会做出回应。他们会创建像这个示例一样的动态脚本来应对检测。

在这种情况下，恶意软件作者创建一个表示要运行的PowerShell脚本的字符串。但是，他们使用简单的字符串连接技术来破解我们之前的签名。如果您查看一个充满广告的网页的源代码，您会看到许多这种技术的实例，用于避开广告拦截软件。

最后，恶意软件作者将这个连接后的字符串传递给Invoke-Expression命令，这是PowerShell在运行时评估组合或创建的脚本的机制。

作为回应，反恶意软件软件开始进行基本的语言仿真。例如，如果我们看到两个字符串被连接起来，那么我们会模拟这两个字符串的连接，然后在结果上运行我们的签名。不幸的是，这种方法相当脆弱，因为语言往往有许多表示和连接字符串的方式。

因此，在被这个签名捕捉到之后，恶意软件作者会采用更复杂的方法，例如在下面的示例中将脚本内容进行Base64编码。

为了应对这种情况，大多数反恶意软件引擎也实现了Base64解码仿真。因此，既然我们也实现了Base64解码仿真，我们在一段时间内领先一步。

作为回应，恶意软件作者会采用算法混淆，例如在他们运行的脚本中使用简单的异或编码机制。

到了这个阶段，我们通常已经超过了反病毒引擎所能仿真或检测的范围，所以我们不一定能检测到这个脚本在做什么。然而，我们可以开始编写针对混淆和编码技术的签名。实际上，这是针对基于脚本的恶意软件的绝大多数签名的原因。

但是，如果混淆器非常简单，看起来像许多行为良好的脚本怎么办？对它进行签名将产生不可接受的大量误报。这是一个样本分阶段脚本，单独来看它是无害的，无法被检测出来。

在这个示例中，我们正在下载一个网页，并调用其中的一些内容。以下是Visual Basic脚本中的等效代码示例。

这两个示例中更糟糕的是，反病毒引擎检查用户打开的文件。如果恶意内容仅存在于内存中，那么攻击有可能不被检测到。

本节展示了使用传统签名进行检测的局限性。但是，虽然恶意脚本可能经历了多次解混淆的过程，但最终它需要向脚本引擎提供明文、未混淆的代码。在这一点上，正如我们在上面的第一节中所描述的那样，Windows 10内置的脚本宿主调用AMSI API请求扫描这些未受保护的内容。您的应用程序也可以做同样的事情。

球分享

球点赞

球在看