反恶意软件扫描接口 (AMSI) 如何帮助你抵御恶意软件
有关 Windows 反恶意软件扫描接口 (AMSI) 的简介，请参阅反恶意软件扫描接口 (AMSI)。
作为应用程序开发人员，你可以积极参与恶意软件防御。 具体来说，你可以帮助保护客户免受基于动态脚本的恶意软件和非传统网络攻击途径的攻击。
举个例子，假设应用程序可编写脚本：它接受任意脚本，并通过脚本引擎执行。 当脚本准备好提供给脚本引擎时，应用程序可以调用 Windows AMSI API 来请求扫描内容。 这样，在决定继续执行脚本之前，你可以安全地确定脚本是否是恶意的。
即使脚本是在运行时生成的，也是如此。 脚本（恶意或其他）可能经过多次反模糊处理。 但你最终需要为脚本引擎提供简单、不模糊的代码。 这就是调用 AMSI API 的地方。
以下是 AMSI 体系结构的示例，其中你自己的应用程序由其中一个“其他应用程序”框表示。
Windows AMSI 接口已打开。 这意味着任何应用程序都可以调用它；并且任何注册的反恶意软件引擎都可以处理提交给它的内容。
我们也不必将讨论局限于脚本引擎。 也许应用程序是一个通信应用，它会扫描即时消息中的病毒，然后再将其显示给客户。 或者，软件可能是在安装插件之前验证插件的游戏。 有很多使用 AMSI 的机会和场景。
AMSI 正常工作
让我们来看看 AMSI 的实际应用。 在本例中，Windows Defender 是调用 AMSI API 的应用程序。 但是你可以从自己的应用程序中调用相同的 API。
以下是一个脚本示例，该脚本使用 XOR 编码技术来隐藏其意图（无论该意图是善意的还是恶意的）。 对于这个例子，我们可以想象这个脚本是从 Internet 上下载的。
为了让事情变得更有趣，我们可以在命令行手动输入这个脚本，这样就没有实际的文件要监视了。 这反映了所谓的“无文件威胁”。 这并不像扫描磁盘上的文件那么简单。 这种威胁可能是一个只存在于机器内存中的后门。
下面，我们将看到在 Windows PowerShell 中运行脚本的结果。 你将看到，Windows Defender 能够在这种复杂的情况下检测 AMSI 测试样本，只需使用标准 AMSI 测试样本签名。
AMSI 与 JavaScript/VBA 的集成
下面所示的工作流程描述了另一个示例的端到端流程，其中演示了 AMSI 与 Microsoft Office 中的宏执行的集成。
- 用户收到包含（恶意）宏的文档，该宏通过使用模糊处理、受密码保护文件或其他技术来逃避静态防病毒软件扫描。
- 然后，用户打开包含（恶意）宏的文档。 如果文档在受保护的视图中打开，则用户单击启用编辑退出受保护的视图。
- 用户单击启用宏以允许宏运行。
- 在宏运行时，VBA 运行时使用循环缓冲区记录与对 Win32、COM 和 VBA API 的调用相关的 [1] 数据和参数。
- 当观察到特定的 Win32 或 COM API 被认为是高风险（也称为触发器）[2] 时，宏执行被停止，循环缓冲区的内容被传递给 AMSI。
- 已注册的 AMSI 反恶意软件服务提供商响应一个判定，以指示宏行为是否为恶意行为。
- 如果行为是非恶意行为，则宏执行将继续执行。
- 否则，如果行为是恶意行为，则 Microsoft Office 会关闭会话以响应警报 [3]，AV 可以隔离文件。
这是什么意思呢？
对于 Windows 用户来说，任何在 Windows 内置脚本主机上使用模糊和规避技术的恶意软件都会在比以往任何时候都更深入的层面上被自动检查，从而提供额外的保护。
对于作为应用程序开发人员的您来说，如果你希望从对潜在恶意内容的额外扫描和分析中获益（并保护客户)，请考虑让应用程序调用 Windows AMSI 接口。
作为防病毒软件供应商，可以考虑实现对 AMSI 接口的支持。 当这样做时，你的引擎将对应用程序（包括 Windows 的内置脚本主机）认为是潜在恶意的数据有更深入的了解。
有关无文件威胁的详细信息
你可能对有关 Windows AMSI 旨在帮助防范的无文件威胁类型的更多背景信息感到好奇。 在本节中，我们将介绍在恶意软件生态系统中发挥作用的传统猫捉老鼠游戏。
我们将使用 PowerShell 作为示例。 但是，你可以使用任何动态语言（VBScript、Perl、Python、Ruby 等）演示的相同技术和过程。
以下是恶意 PowerShell 脚本示例。
这个脚本只是在屏幕上写一条消息，而恶意软件通常更邪恶。 但是你可以很容易地写一个签名来进行检测。 例如，签名可以在用户打开的任何文件中搜索字符串“Write-Host 'pwnd!'”。 太好了：我们检测到了第一个恶意软件！
不过，在我们第一个签名检测到后，恶意软件作者将做出响应。 他们通过创建动态脚本（如本例）来响应。
在这种情况下，恶意软件作者会创建一个字符串，表示要运行的 PowerShell 脚本。 但他们使用了一种简单的字符串连接技术来破坏我们之前的签名。 如果你曾经看过一个充满广告的网页的来源，你会看到许多使用这种技术来避免广告屏蔽软件的例子。
最后，恶意软件作者将此串联字符串传递给 Invoke-Expression cmdlet，即 PowerShell 的机制，用于评估在运行时编写或创建的脚本。
作为回应，反恶意软件开始执行基本语言模拟。 例如，如果我们看到两个字符串正在连接，那么我们模拟这两个字符串的连接，然后在结果上运行我们的签名。 遗憾的是，这是一种相当脆弱的方法，因为语言往往有很多方法来表示和连接字符串。
因此，在被这个签名捕获后，恶意软件作者将转向更复杂的东西。例如，在 Base64 中编码脚本内容，如下例所示。
由于资源丰富，大多数反恶意软件引擎也实现 Base64 解码模拟。 因此，由于我们还实现了 Base64 解码模拟，因此我们领先了一段时间。
作为回应，恶意软件作者转向算法模糊处理，比如在他们运行的脚本中使用简单的 XOR 编码机制。
此时，我们通常已经超出了防病毒引擎将模拟或检测的范围，因此我们不一定会检测到该脚本正在做什么。 但是，我们可以开始针对模糊处理和编码技术编写签名。 事实上，这就是基于脚本的恶意软件的绝大多数签名的原因。
但是，如果模糊处理程序如此琐碎，以至于看起来像许多行为良好的脚本，该怎么办？ 它的签名将生成不可接受的误报数。 下面是一个示例暂存器脚本，该脚本太良性，无法自行检测。
在此示例中，我们将下载网页，并从中调用某些内容。 下面是 Visual Basic 脚本中的等效代码。
在这两个例子中，更糟糕的是防病毒引擎检查用户打开的文件。 如果恶意内容只存在于内存中，那么攻击可能无法被检测到。
本部分显示了使用传统签名进行检测的局限性。 但是，尽管恶意脚本可能会经过几次去模糊处理，但它最终需要为脚本引擎提供简单、无模糊的代码。 在这一点上，正如我们在上面的第一节中所介绍的，Windows 的内置脚本主机调用 AMSI API 来请求扫描这些未受保护的内容。 你的应用程序也可以做同样的事情。