图1 在Pow erShell中执行命令
即使用户依然将“命令提示符”作为默认的命令行环境，也同样可以调用PowerShell来执行脚本文件和命令。例如：（1）可以通过临时修改“执行策略”的方式运行脚本文件；（2）可以将图1在PowerShell中执行命令经过Base64编码后的命令直接解码执行；（3）可以从网络直接下载脚本文件并执行；（4）经过内容混淆的命令依然可以执行。上述事例分别如图2的①~④所示。
图2 在传统的“命令提示符”中执行Pow erShell命令
此外，PowerShell的很多安全机制需要3.0或更高的版本才能支持。然而，由于兼容性等原因，系统中可能同时存在多个版本的PowerShell。在高、低版本共存的环境下，即使默认使用的是高版本，攻击者也可能通过命令行参数调用低版本PowerShell，发起“降级攻击”，从而绕过某些安全机制。
需要说明的是，PowerShell脚本的执行权限和当前用户的权限是一致的。如当前用户具有系统管理员权限，且未通过Windows内的用户账户控制（UserAccountControl，UAC）进行必要的防护，则以该用户权限执行的PowerShell脚本就可能对系统造成非常大的危害。但是，即使当前用户是普通用户，通过PowerShell脚本也能够窃取该用户有权访问的所有文件，包括其工作文件和私人文件等。
四、 PowerShell攻击的检测
从上面的介绍可以看出，PowerShell脚本文件可以通过编码、混淆、网络下载、转换为命令行命令等多种方式执行。如果将这些方式复合起来，可以仅用一条命令就从网络下载经编码和混淆的脚本文件并在本地运行。这使得PowerShell攻击不仅难以被发现，还可能因为不落盘存储等原因难以被追踪。但是，攻击事件依然可能会在终端系统中留下一些痕迹，这为我们检测攻击事件提供了可能。下面介绍几种检测方法。
查看系统日志是最有效的检测方法之一。Windows系统默认会记录包括PowerShell引擎启动事件等在内的一些基础日志。在系统的管理工具中找到“事件查看器”的图标，或在命令行中运行eventvwr.msc，打开“事件查看器”。然后在左侧依次展开“应用程序和服务日志―Windows PowerShell”，即可查看关于PowerShell的日志，如图3所示。
图3 查看Pow erShell的事件日志
在系统日志中，事件ID为400的事件表示引擎启动成功，403则表示引擎停止。用户主动打开PowerShell命令行，命令行加载时会生成400事件。如用户通过命令行调用PowerShell执行脚本文件，则会在脚本执行开始时生成400事件，在脚本执行完成时生成403事件。根据事件的时间，结合其他异常情况，可以对是否发生过PowerShell攻击做出一定的判断。此外，其他类型的事件日志也可以提供相应的辅助参考。
系统默认记录的PowerShell事件类型是有限的，可通过修改系统策略的方法补充其他需记录的事件类型。具体方法是：首先在系统的管理工具中找到“编辑组策略”的图标，或在命令行中运行gpedit.msc，打开“组策略编辑器”；然后依次展开“本地计算机策略―计算机配置―管理模板―Windows组件―WindowsPowerShell”，在右侧选择“启用模块日志记录”，设置为“已启用” ，并根据需要将相应模块名称添加到列表中，如“Microsoft.PowerShell.* ”等；最后再在右侧选择“打开PowerShell脚本块日志记录”，设置为“已启用”，并勾选下方的“记录脚本块调用启动/停止日志”。这些操作将进一步丰富PowerShell日志的内容，为分析后续可能发生的攻击事件提供支持。
除了系统日志外，PowerShell攻击还可能留下其他一些蛛丝马迹。例如，有的PowerShell攻击脚本需周期性执行，或在终端开机时自动运行，那么系统的计划任务列表和启动项中可能会保留有相应的记录，可通过相应的管理工具或微软提供的autoruns等工具进行检查。
此外，对于一些落盘存储和执行的PowerShell脚本，攻击者为确保攻击成功，通常会使用绝对路径。因此，一些权限较低的目录很可能成为恶意脚本文件临时存储的地方，特别是用户的数据目录（如C:\Users\用户名\AppData下的各个子目录）等。可以检查相应目录中是否存在异常的脚本文件，特别是以ps1、psc1和psm1等为扩展名的PowerShell脚本文件。必要时，还可以通过数据恢复工具检查相关目录中是否存在被删除的脚本文件。