作为Windows系统内置工具, Powershell脚本的功能十分强大,同时作为系统的功能组件不会被常规杀毒引擎查杀。兼具这两个有点,Powershell的恶意利用程序得到快速发展,从2012年Powershell 攻击利用工具成型化以来,互联网中的通过无文件与Powershell的攻击事件数量逐年递增。无文件攻击在感染计算机时,不需写入磁盘即可从事恶意活动,绕过那些基于签名和文件检测的传统安全软件。 如何检测这些恶意行为成了安全厂商和企业用户与个人更为关心的问题。微软在2015年中旬开始提出了针对无文件攻击和Powershell脚本攻击的检测缓解方案-AMSI。
本文以Powershell行为日志审计为切入点, 展开介绍AMSI的功能,工作机制与现有绕过方法。
Powershell作为内网渗透的利器, 在Windows环境下被广泛使用。利用Poweshell可以降低软件的查杀概率,同时也是无文件攻击的常用手段。在内网渗透中Powershell扮演着重要角色。
Powershell可以用于入侵,下载,权限维持,横向移动等攻击阶段。
Powersploit和Nishang是老牌后渗透利用框架,集成了后门,提权,信息收集,RCE等功能。
Powershell Empire和PSAttack都是不依赖于powershell.exe的PowerShell利用框架。它们分别使用python和.NET重新封装了脚本解释器,执行相关渗透脚本。
传统安全软件对Powershell的防御不甚完善,通过Powershell进行网络勒索,挖矿的恶意软件越来越多,攻击方式也越来越复杂。
本文不对Powershell语法做阐述,攻击利用的命令与代码可以参考开源工具。除了攻击利用,本文将关注点放在Powershell日志和版本上。
Event ID: 4103
路径: Microsoft > Windows > PowerShell/Operational
作用:可以为 Windows PowerShell 模块启用日志记录
使用下面命令可以获取或有可用的模块名称:
Get-Module -ListAvailable
Event ID: 800
作用:记录Powershell管道执行过程的事件简介
Event ID: 4104
路径:Microsoft-Windows-PowerShell/Operational
作用:Windows PowerShell 将记录命令、脚本块、函数和脚本的处理,无论是以交互方式调用还是通过自动方式处理
可以将 Windows PowerShell 命令的输入和输出捕获到基于文本的脚本中。
当然,开启 transcription有个bug
这四种日志功能默认不开启,需要手工开启
日志详情 | 模块日志 | 管道执行日志 | 脚本块日志 | 脚本转换日志 |
执行命令 | 有 | 有 | 有(包括脚本内容) | 有 |
上下文信息 | 有 | 有 | 无 | 有 |
参数绑定详情 | 有 | 有 | 无 | 无 |
解码/解混淆代码 | 无 | 无 | 有 | 有 |
命令输出 | 无 | 无 | 无 | 有 |
日志类型 | V2版本 | V3版本 | V4版本 | V5版本 |
模块日志 | 无 | 支持 | 支持(V3增强) | 支持 |
管道执行日志 | 支持 | 支持 | 支持 | 支持 |
脚本块日志 | 无 | 无 | 支持 | 支持(自动记录恶意命令) |
脚本转换日志 | 无 | 无 | 支持 | 支持(V4增强) |
操作系统 | 默认Powershell版本 | 可支持Powershell版本 |
Windows Server 2008(SP2) | 2.0 | 3.0 |
Windows Server 2008(SP1) | 5.1 | 5.1 |
Windows Server 2012 | 3.0 | 5.1 |
Windows Server 2012(R2) | 4.0 | 5.1 |
Windows 7(SP1) | 5.1 | 5.1 |
Windows 8 | 3.0 | 5.1 |
Windows 8.1 | 4.0 | 5.1 |
Windows 10 | 5.0 | 5.1 |
AMSI(Antimalware Scan Interface), 即反恶意软件扫描接口。在Windows Server 2016和Win10上默认安装并启用。
使用案例:通过远程URL访问,在不落地的情况下执行PS代码,但是会被AMSI检测拦截。
大家在使用Powershell脚本进行Windows环境渗透测试时,可能会遇到上图中的报错情况,比如Nishang、Empire、PowerSploit和其他比较知名的PowerShell脚本。而这一错误的产生原因即为AMSI防护的结果。
Win10 AMSI标准允许系统上安装的杀毒软件对系统进行深度的监控扫描,而且无需用户参与。允许基于AMSI接口的安全软件,通过AMSI接口扫描文件,内存、数据流等,进行内容源的URL/IP认证检查,并采用技术手段识别恶意行为。帮助用户更加方便有效地防范基于动态脚本的恶意软件和其他攻击行为。
Win10 与Windows Server 2016默认是AMSI默认杀毒软件是Windows Defender。
如果已经安装360安全卫士,请在“设置中心”-“开启Defender”中,勾选开启Windows Defender防护。
安全产品 | 支持状况 |
Microsoft Defender | 支持 |
AVG Protection 2016.7496 | 支持 |
ESET Version 10 | 支持 |
BitDefender | 支持 |
Avast | 支持 |
McAfee Endpoint Security 10.6.0 | 支持 |
Trend Micro | 支持 |
Kaspersky 2019 | 支持 |
Avira | 准备支持 |
F-Secure | 不支持 |
AMSI不是独立运行的,而是一种可交互接口。
Windows Defender ATP主要使用机器学习,通过模型发现威胁。
AMSI是与Windows Defender相对独立的模块,Windows Defender是默认的 AMSI Provider。
图中红色表示订阅AMSI事件的安全软件,也就是AMSI提供器。在脚本引擎Powershell( System.Management.Automation.dll) 和 Windows Script Host(Jscript.dll)执行内容时,他们会通过amsi.dll的导出函数把内容传给AMSI提供器。
这里曾经出现一个安全漏洞,零字符截断绕过AMSI检测,流程如下:
恶意代码evilcode由于字符串截断没有送入到ASMI Provider中进行安全检查。
PowerShell v2版不支持AMSI,作为常用手段,将目标主机中的PowerShell降级至PowerShell v2简单快捷。
虽然文章开始给的脚本经过base64编码后依然能被AMSI检测,但是增强混淆程度也是绕过AMSI的有效方法之一。
以下是绕过字符串检测,执行“被禁止”代码的3种方法:
简单地将单词分成两部分,就足以欺骗这种检测方案。我们在混淆过程中,发现了很多这样的情况。但在大多数情况下,这种方法可能会失败。
当然,也可以使用XOR来欺骗AMSI,并在运行时将字符串解码到内存中。这是更为有效的方式,因为需要更高级的技术来对其进行检测。
执行完结果
寻找优先加载并无效的COM表项,在注册表中将Provider的路径指向到无效路径。这样,Powershell中的AMSI功能将无法加载,从而失效。
劫持之后的效果
当然这个漏洞在2017年5月份的16232已经修复了,不过还可以通过DLL劫持绕过AMSI。
首先,我们先看下应用程序导入DLL优先级(Windows XP SP2以后版本)
可以看到第一条,与应用程序同级的目录的dll会被优先加载。利用这一点。我们在C:\Windows\System32\WindowsPowerShell\v1.0下放置一个伪造AMSI.dll,就可以实现DLL劫持,而不会调用系统的amsi.dll(C:\Windows\System32\asmi.dll, 如下)。
系统AMSI.dll路径,如下:
https://www.anquanke.com/post/id/107097
https://www.anquanke.com/post/id/84618
打赏我,让我更有动力~
© 2016 - 2024 掌控者 All Rights Reserved.