开发者工具 · Base64 编码器和解码器
如何在不运行的情况下解码可疑的 Base64 PowerShell 命令
· 为什么它很重要
base64 安全
攻击者使用 Base64 隐藏脚本以防止随意检查。这篇文章展示了如何解码 -EncodedCommand 有效负载而不执行它，为什么输出在 UTF-8 解码器中看起来很奇怪，以及要寻找什么。
带有 2,000 字符参数的计划任务 — 编码命令出现的位置以及为什么它们是危险信号
系统管理员发现计划任务带有看起来可疑的 2,000-character -EncodedCommand 参数。该任务在具有高权限的服务帐户下运行。
将命令粘贴到 PowerShell 中并运行它以查看其功能的诱惑是危险的；如果该命令是恶意的，执行它会危及系统。更安全的方法是在本地解码 Base64 并以文本形式读取输出，然后再决定是否运行任何内容。这篇文章解释了如何安全地解码 PowerShell 命令而不执行它们，为什么输出在标准 UTF-8 解码器中可能看起来乱码，以及如何寻找来评估命令是安全还是可疑。
解码，从不执行 - 确保分析安全的规则，以及为什么仅浏览器解码器非常适合
关键的见解是 PowerShell 对 -EncodedCommand 使用 UTF-16LE 编码，而不是 UTF-8，因此每隔一个字节都是零，标准工具将其解释为空终止符。分析任何可疑代码的规则很简单：解码，从不执行。这适用于 Base64 编码的命令、压缩脚本、来自不受信任来源的脚本以及不熟悉的编码链中的任何内容。执行脚本就没有回头路了；一旦它运行，系统就会发生变化，访问权限就会被授予，数据也会被泄露。
将脚本解码并读取为文本，可以让您在不可逆步骤之前对其进行评估。第二条规则是使用本地运行且不发出网络请求的工具。基于浏览器的解码器是理想的选择，因为它是便携式的，不需要额外的软件，并且可以将可疑的有效负载保留在您的设备上，而无需将其上传到任何服务器。如果该工具是发布到远程解码器服务的工具，请不要使用它；然后将有效负载暴露给该服务。 PowerShell -EncodedCommand 参数接受 Base64 字符串，该字符串在解码后包含 PowerShell 脚本。
为什么解码后的字节看起来与 UTF-8 文本不同 - 检查十六进制的 UTF-16LE 字节模式，而不是要求此 UTF-8 文本工具来解释它
但是，PowerShell 不为此使用 UTF-8 编码；它使用 UTF-16LE（小端 UTF-16）。在 UTF-16 中，每个 ASCII 字符都表示为两个字节：字符代码后跟一个零字节。字母 A 的十六进制形式为 41 00。字母 B 是 42 00。像 Hello 这样的字符串在 UTF-16LE 字节中显示为 48 00 65 00 6C 00 6C 00 6F 00 。当这是 Base64 编码时，结果包含所有这些字节的编码形式，包括所有零。使用标准 UTF-8 解码器进行解码会产生乱码文本或在第一个零字节处截断，因为 UTF-8 将空字节视为字符串终止符。
输出看起来像 H e l o 而不是 Hello，具有看似随机的字符或缺失文本。一个有效的例子展示了问题和解决方案。假设 PowerShell 命令对简单字符串 Write-Host Hello 进行编码。 PowerShell UTF-16LE 将此字节编码为包括所有零的字节，Base64 编码字节并生成一个长字符串，如 VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA。将此字符串复制到浏览器中的 Base64 编码器和解码器中，然后单击“解码”。默认解码器将尝试将结果解释为 UTF-8 文本，并由于嵌入的零而产生损坏或截断的输出。
工作示例：解码无害的示例编码命令 - 读取交错零字节之后的文本
解决方案是使用十六进制视图。切换到十六进制视图，您会看到字节： 57 00 72 00 69 00 74 00 65 00 2D 00 4B 00 6F 00 73 00 68 00 20 00 22 00 48 00 65 00 6C 00 6C 00 6F 00 22 00。将这些字节作为 UTF-16LE 对读取会产生 W-r-i-t-e---K-o-s-h---H-e-l-l-o-。凭借经验，您可以直接读取 UTF-16LE 十六进制，也可以将字节写入文件并使用本地运行的 PowerShell 或 Python 脚本对其进行解码。
实用方法是记下该模式并记住 PowerShell 使用 UTF-16LE。当您在浏览器中解码 PowerShell -EncodedCommand 并且输出看起来错误时，请查看十六进制视图而不是文本视图。十六进制视图单独显示每个字节。每个 ASCII 字符均显示为两个字节，中间有一个零。如果这些字节拼出恶意命令，例如 New-AdminAccount、反向 DNS 查找或导出安全凭证，则该命令是可疑的。如果这些字节拼出一些无害的内容，例如目录列表或简单脚本，则该命令可能是良性的。
嵌套编码和压缩 - Base64 内的 Base64，以及无法作为文本读取的 gzip 流
十六进制视图比纯文本更难阅读，但它比从损坏的 UTF-8 输出中猜测更安全。嵌套编码和压缩增加了恶意软件分析的复杂性。 PowerShell 命令可能会对另一个 Base64 字符串进行 Base64 编码，或者使用 gzip 压缩脚本，然后对结果进行 Base64 编码。在嵌套场景中，您解码外部 Base64，读取结果并发现它本身就是 Base64。也对其进行解码并继续，直到找到可读文本或无法解释的二进制格式。 Gzip 和其他压缩格式以十六进制视图中可见的魔术字节（gzip 为 1F 8B）开头。
如果解码 Base64 并且十六进制视图以 1F 8B 开头，则字节是需要解压缩的压缩流。 Base64 编码器和解码器向您显示十六进制，帮助您识别这些模式而不执行任何操作。压缩或进一步编码的有效负载是可疑的，因为它们添加了混淆层。
事件报告要记录的内容 - 解码文本、源和哈希值，而不是有效负载本身
合法命令很少需要多个编码步骤。记录事件报告的结果需要纪律和准确性。记下您分析的确切 Base64 字符串、找到它的位置和时间。如果您对其进行解码并发现可疑命令，请描述这些命令，但不要在报告中包含完整的脚本；脚本可能很复杂或很长。
包含已解码脚本的哈希值 (SHA-256)，以便可以验证和跟踪结果。如果该命令明显是恶意的或使用已知的利用技术，请在采取任何行动之前让事件响应和安全团队参与。切勿亲自执行该命令来查看它的作用。如果事件响应人员需要执行它进行测试，他们会在包含任何损坏的沙盒环境中执行此操作。您的工作是在安全距离内解码和评估风险。本文不涵盖恶意软件分析、沙箱环境或攻击归因的全部范围。
这不包括沙箱执行、恶意软件分析工具和归因
这些是安全专业人员和事件响应团队的主题。这里的范围主要集中于安全地解码编码的 PowerShell 命令而不执行它，因此您可以阅读该脚本并评估它是否值得进一步研究。 Base64 编码是混淆，而不是保护。任何拥有编码和解码器的人都可以提取脚本。攻击者使用 Base64 来逃避基本检测并防止随意检查，而不是隐藏其意图以防止分析。获取并执行远程脚本的已解码 PowerShell 命令是恶意的，无论您自己解码还是安全工具解码。
解码可疑命令后实际的下一步是将其报告给适当的团队。如果是您自己的系统，请确定该任务是否是有意创建的以及由谁创建的。检查创建日期和安排它的帐户。如果该任务未经授权，请将其禁用，保留详细信息以供取证，并调查攻击者如何获得创建它的权限。如果该命令包含网络请求或持久性机制（例如注册表更改或计划任务创建），则几乎可以肯定它是恶意的。
要点：Base64 是混淆，而不是保护 — Base64 编码器和解码器如何在本地解码有效负载，而无需离开您的机器
如果它执行合法的管理功能并且创建详细信息正常，则它可能是合法的管理脚本，恰好由于与安全策略或与更大的自动化工具集成相关的原因而被编码。无论哪种方式都不要执行；让您对解码文本的评估告知您的决定。可疑 Base64 PowerShell 命令的安全解码遵循一个简单的过程。使用 Base64 编码器和解码器来解码字符串，而无需上传或执行任何操作。查看十六进制视图以了解字节代表什么。
如果您看到 UTF-16LE 模式（交错零字节），请记住 PowerShell 使用 UTF-16LE 并进行相应读取。识别任何可疑模式，例如网络请求、特权提升或持久性机制。准确记录事件报告的详细信息，包括原始 Base64 字符串及其哈希值。切勿自行执行该命令；将其留给受控环境中的事件响应人员。相信您的本地解码和对明文的评估，并让它指导您的下一步行动。