fatekey's Blog https://blog.fatekey.icu/ 这是一个不想做菜狗的菜狗的博客 Thu, 19 Feb 2026 01:24:19 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, fatekey <![CDATA[clash-verge 本地提权漏洞复现]]> https://blog.fatekey.icu/article/clash-verge-rce https://blog.fatekey.icu/article/clash-verge-rce Mon, 28 Apr 2025 00:00:00 GMT
😀
看到网上爆出 clash-verge 存在提权漏洞，简单复现下。 https://github.com/clash-verge-rev/clash-verge-rev/issues/3428

0x00 定位漏洞

已知是提权到system的漏洞，那直接看 service 相关代码就好。
在 clash-verge-rev/src-tauri/src/core/service.rs 可以看到33211端口有 http 服务
存在 4 个 api 接口并且没有任何鉴权机制。
/start_clash 启动Clash核心，接受POST请求，需要在请求体中提供JSON格式的配置信息，包含以下参数：
core_type: 核心类型（如"verge-mihomo"） bin_path: 二进制文件路径 config_dir: 配置目录路径 config_file: 配置文件路径 log_file: 日志文件路径
一看就很有问题，文件路径是自己指定的，用powershell请求下试试
看下任务管理器，system权限的notepad进程已经启动了。
启动参数如下：
利用cmd的一些特性，可以构造如下参数执行任意命令。

0x01 进一步分析

和之前 clash 的漏洞一样，尝试使用浏览器js访问，不过不同于 clash 的api，服务的 api 受到 CORS的限制，不允许读取响应以及不允许设置Content-Type为application/json。这就导致 start_clash 这个api 不可能通过浏览器 js 利用。
💡
为啥说基本不可能利用呢，因为有些条件苛刻的方法有可能绕过CORS。 比如使用 flash，但是现在哪还有支持 flash 的浏览器，也许可以做个假的基于 flash 的登录页面来钓攻击者的鱼？
看起来这个漏洞对普通用户基本没啥危害，普通用户电脑上也没啥需要提权的低权限用户。
]]> <![CDATA[Windows 11 LTSC 刷机记录]]> https://blog.fatekey.icu/article/win11ltsc https://blog.fatekey.icu/article/win11ltsc Sat, 08 Mar 2025 00:00:00 GMT

0x00 起因

一般我很少折腾系统，买来的火影7840HS笔记本系统用了一年了没怎么管过，但最近自动升级到 win11 2024.2 之后，出现了各种奇怪的bug。
  • 浏览器经常有一块页面卡住不动
  • 虚拟机离开一会后图像就会卡住
  • 电脑锁屏后过段时间再解锁wifi会不可用
  • 间歇性极短时间花屏
更新了各种驱动也无济于事，于是决定重新安装下系统，听说 IoT 版本比较稳定，于是尝试切换到 Windows 11 IoT Enterprise LTSC。
因为从事安全工作，个人一直习惯虚拟机开发，虚拟机调试，实体机只用来开办公软件和浏览器，所以对实体机环境依赖比较少，能够稳定运行即可。如果是要在实体机开发、游戏的话，需要考虑下 IoT 版本是否阉割掉了必要的依赖。

0x01 制作启动 U 盘

镜像下载地址：Windows LTSC Download | MAS
Windows LTSC Download | MAS

Windows LTSC Download | MAS

All download links lead to genuine files only.

镜像用 rufus 写入 U 盘，全都默认配置就好。
https://rufus.ie/zh/

0x02 进入 BIOS 修改启动顺序

火影的笔记本是开机时按 F2 进入，不同主机可能会有不同。
将 USB 设为首选启动项。

0x03 安装

全程英文操作，与普通系统安装操作逻辑是一样的，选择Windows 11 IoT Enterprise LTSC版本。
安装完无法联网，安装从笔记本官网下载的驱动。

0x04 配置中文

IoT Enterprise LTSC 版本不自带中文，需要额外配置。
notion image
notion image
notion image
notion image
notion image

0x05 安装必要软件

scoop

ltsc不带微软商店，而且微软商店除了特定软件外不如scoop好用，scoop是非常方便的包管理工具，有了它就能快速安装各种软件了。
如果官方没有想安装的软件，可以添加第三方仓库（这种自动整合多个仓库的项目，总感觉有投毒的风险）。

vmware

chrome

顺便把 edge 卸载了

office

scoop 第三方仓库可以一键安装office，不过我更喜欢 office-tool-plus 。可以装各种版本的office，更新通道选择 Office 2024 企业长期版，产品选择Office LTSC 专业增强版 2024 - 批量许可证

vscode

 

其他

开发软件

0x06 激活

使用 0 和 1 分别激活windows和office

0x07 优化

光标变色

光标颜色变来变去的很容易找不到。
notion image
notion image

右键菜单

新右键菜单纯属逆天，很多时候都要点更多选项，很影响效率，使用以下命令还原经典右键菜单。
也可以用 optimizer 修改

彻底关闭虚拟化

关闭windows虚拟化后能提高虚拟机的性能。
tool.bat
1.1KB
也可以用 optimizer 关闭

0x08 IOT 版本发现的bug

中文支持不完美

  • 区域和语言都是中国的情况下，部分软件（如微信）依然选择英文为默认语言，可能是因为 iot 版本默认只有英文导致的？
  • 更新后变成一半中文一半英文（严重影响使用）

0x09 切换到 LTSC

既然bug都是中文相关的，所以选择切换到有中文支持的 LTSC 版本，安装步骤与 IOT 版本相同。
切换到 LTSC 版本后没有再遇到中文的问题。
 
]]> <![CDATA[AMSI研究(1) - 基础]]> https://blog.fatekey.icu/article/AMSI1 https://blog.fatekey.icu/article/AMSI1 Tue, 11 Jun 2024 00:00:00 GMT

0x00 什么是AMSI

AMSI 全称 Antimalware Scan Interface，反恶意软件扫描接口，是微软为了对抗无文件攻击而开发的安全组件。历史上，杀毒引擎和 EDR 产品在对抗基于文件的恶意软件方面较为有效，但内存中的恶意代码一直是一个具有挑战性的盲点。在没有 AMSI 之前，安全 厂商要想检测在内存中执行的代码，需要将检测代码注入到待检测的程序中，这显然并不容易实现，并且随着系统更新需要不断对实现方式进行维护。
微软认识到需要改进内存中的检测能力，同时提供一个稳定的接口供自己和第三方供应商使用。由此产生的就是反恶意软件扫描接口（AMSI）。AMSI 实质上是一个管道，把 powershell 或者其他程序执行的代码传送给防病毒程序进行检测，微软设计的初衷是希望各种程序都可以接入 AMSI ，现在一般情况下只有微软开发的程序接入了 AMSI。
本体是 c:\\windows\\system32\\amsi.dll 它提供了通用的标准接口（COM接口、Win32 API），API是为接入 AMSI 的程序提供的，COM 接口是为防病毒厂商提供的。
可以使用以下命令获取接入了 AMSI 的 exe 及 dll 文件。
接入了 AMSI 接口的程序如下：
  • PowerShell（>2.0）：由 System.Management.Automation.dll 实现
  • VBScript：由 vbscript.dll 实现
  • JScript：由 jscript.dll、jscript9.dll 和 jscriptlegacy.dll 实现
  • Office 文档中的 VBA 宏：由 VBE7.dll 实现
  • Excel 4.0 宏：由 excel.exe 和 excelcnv.exe 实现
  • Exchange Server 2016：由 Microsoft.Exchange.HttpRequestFiltering.dll 实现
  • WMI：由 fastprox.dll 实现
  • .NET 内存中的程序集加载：在 .NET 4.8+ 中由 clr.dll 和 coreclr.dll 实现
  • 卷影复制操作：由 VSSVC.exe 和 swprv.dll 实现
  • 用户账户控制（UAC）提升：由 consent.exe 实现

0x01 AMSI 的实现

当应用程序尝试提交要由 AMSI 提供程序扫描的内容时，应用程序将 amsi.dll 加载并调用其 AmsiInitialize 和 AmsiOpenSession 函数以建立 AMSI 会话。然后通过 AmsiScanString 或  AmsiScanBuffer 函数提交要扫描的内容。
amsi api 列表：https://learn.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-functions
在 AmsiScanString 绕过方法公开后， AmsiScanBuffer取代了 AmsiScanString。（顺带一提，AmsiScanBuffer也能被绕过，但微软不再认为 AMSI 绕过是一种漏洞，修复的并不积极。）
  • 第一个参数是应用程序的名称，第二个参数是指向名为 amsiContext的上下文句柄的指针。这个名为 amsiContext的上下文句柄在每个后续 AMSI 相关函数中都会使用。
  • 对 AmsiInitialize的调用发生在我们能够调用任何 PowerShell 命令之前，这意味着我们无法以任何方式影响这个过程。
      • AmsiInitialize的第一次调用无法被干扰，但可以反射调用 AmsiUninitialize ，这会导致powershell 重新进行 AmsiInitialize ，这次调用是可以提前干扰的。
一旦 AmsiInitialize 完成并创建上下文结构，AMSI 就可以解析发出的命令。当我们执行 PowerShell 命令时，会调用 AmsiOpenSession API。
  • 其作用是使用已经初始化的amsiContext上下文句柄来创建一个新的会话句柄。amsiContext保存了 AMSI 的全局状态，而每个会话句柄则代表了一个独立的扫描会话。
随后调用 AmsiScanBuffer 对内容进行扫描。
  • 第一个参数是 AMSI 上下文句柄，后面是指向包含要扫描的内容的缓冲区的指针，以及缓冲区的长度。以下参数是输入标识符 (contentName)、会话句柄 (amsiSession)，最后是指向扫描结果存储缓冲区的指针。
  • 根据微软文档的说法，返回结果越大威胁越大大于等于32768被视为恶意软件。软件对于不同的返回结果可以自行实现如何处理，对于 powershell，判断为恶意时会对命令进行阻断。
供应商的 AMSI 提供程序 DLL 接收AmsiScanBuffer提交的内容并进行分析。供应商可以使用其关联的 COM GUID 值在 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers 注册表项中注册多个 AMSI 提供程序。
  • 对于多个 AMSI 提供程序，有一个认为恶意，那 AMSI 就会认为恶意，并且不再送给接下来的提供程序扫描。
在 Windows 10 上注册AMSI 提供程序的方法 （具体实现见第二章 ）：
  • 在键中 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers ，有一个子键，其名称为 {2781761E-28E0-4109-99FE-B9D127C57AFE}
  • 若要确定与该 GUID 值关联的相应 AMSI 提供程序 DLL，可以查看如下键  HKEY_CLASSES_ROOT\CLSID\{2781761E-28E0-4109-99FE-B9D127C57AFE}\InprocServer32 - (default) .该注册表值的内容为 %ProgramData%\Microsoft\Windows Defender\Platform\4.18.2110.6-0\MpOav.dll 。因此，MpOav.dll 是特定供应商（在本例中为 Microsoft）的 AMSI 提供程序 DLL，负责接收和处理应用程序传递给它的内容。

0x02 分析 Powershell AMSI 扫描的实现

2.1 源码分析

powershell是开源的，可以对源码直接进行分析，要分析的代码主要在 PowerShell/src/System.Management.Automation/security/SecuritySupport.cs 和PowerShell/src/System.Management.Automation/engine/runtime/CompiledScriptBlock.cs 。
前者实现了 AmsiUtils 类，后者调用 AmsiUtils 类的方法进行扫描。
在 CompiledScriptBlock.cs 的 PerformSecurityChecks 函数调用 ScanContent 进行扫描。
ScanContent 只是调用了WinScanContent ，实际的扫描逻辑都是在WinScanContent 里。
不少文章 都是这么写的，但这只是开源的跨平台 powershell 7.x 才有的设计，在 windows 自带的 powershell 5.x 中，扫描逻辑位于 ScanContent 。
PSEtwLog.LogAmsiUtilStateEvent 这个也是7.x新增的，windows自带的 powershell 没有，有了这个，安全产品检测 AMSI 绕过就容易多了（这个也能绕过）。

2.2 汇编分析

notion image
使用 API Monitor 看下api 调用。
AmsiInitialize 调用发生在powershell初始化时，执行语句时，先 AmsiOpenSession 打开会话 ，然后用 AmsiScanBuffer 扫描，再用AmsiCloseSession 关闭会话。
这里只分析 AmsiOpenSession 的调用，其他函数的调用与之类似 。

AmsiOpenSession

使用 windbg 设置断点。
bp amsi!AmsiOpenSession
查看调用栈。
最近的3处调用如下，内存的权限均为 PAGE_EXECUTE_READ ，不修改内存权限的情况下只有 call rax 这个有可能用于绕过，别的 都是写死的。

0x03 分析  [System.Reflection.Assembly]::Load() AMSI 扫描的实现

notion image
[System.Reflection.Assembly]::Load() 可以加载C#程序集，在powershell中也可以调用，其也会调用 AMSI ，扫描不通过时会产生上述报错。
使用 dnSpy 分析 Load方法的实现。
跟进 nLoadImage 。
标记为 [MethodImpl(MethodImplOptions.InternalCall)]，这意味着它是通过内部调用实现的，而不是用托管代码（C#）实现。
使用 windbg 进行调试
反汇编结果如下
使用 mdToken 检索 nLoadImage 方法的 MethodDesc
列出了 MethodDesc 的信息。这将提供实现 nLoadImage 的对象的方法表的地址。
方法表 (Method Table) 是一种数据结构，用于描述类型的所有方法，并提供访问这些方法的机制。
列出方法表并找到 nLoadImage
因此，nLoadImage 的本机地址是 0x00007fffffc24c70
clr!AssemblyNative::LoadImage 调用 clr!AmsiScan 的调用栈为
可以用 IDA 分析 clr.dll 研究 AmsiScan 具体实现。
CLRLoadLibraryEx 是对 LoadLibraryExW 的封装，因为没有启动新进程，当前进程还是 powershell进程，LoadLibraryExW 会返回已经加载的 amsi.dll 模块的句柄，并增加其引用计数。这意味着在powershell 中对 amsi.dll 进行的修改，在 [System.Reflection.Assembly]::Load() 也会生效。
在 AmsiScan 中，调用 AmsiInitialize 建立了新的 amsiContext ，着意味着对 powershell amsiContext 的修改不会影响到Load() 的 AMSI 检测。
随后调用 AmsiScanBuffer 进行扫描（这里并没有使用 AmsiOpenSession 建立会话），根据扫描结果决定是否进行阻断。

0x04 分析 fastprox.dll AMSI 扫描的实现

逆向 fastprox.dll ，对象初始化函数如下
检查注册表，如果 AmsiEnable 值被设置为0后续就不进行 AMSI 扫描，这块和 JScript.dll 处理差不多，早期 win10 版本可以修改 HKCU 注册表绕过，现在的版本都是检查 HKLM 了。
在 JAmsiInitialize 函数中，加载 amsi 前进行了一些判断。g_Amsi 是前文检查的注册表项，JAmsiIsCurrentProcessWmiprvse 则是比对当前文件的路径是否为系统目录下的\wbem\wmiprvse.exe ，如果是的话则不进行检测。
💡
经常干蓝队的肯定知道，wmi 操作时会先由 svchost.exe 调用 WmiPrvSE.exe 然后由 WmiPrvSE 调用指定的程序。他这不检测 WmiPrvSE.exe ，那这个基本对 wmi 远程攻击没啥检测能力了。 目前只有本机用 wmic、powershell 等程序操作 wmi 的时候才能触发检测，并且本地操作也不是全触发检测，还要判断hash，搞不懂微软这么设计图啥，搞得这块的检测非常容易绕过。
在 JAmsi::JAmsiProcessor 中进行扫描前，还进行了一个判断，判断需不需要进行扫描。
JAmsiIsScannerNeeded 会对对象及方法进行判断，比如执行
wmic Process Call Create "cmd /c whoami" 时
会依次对以下对象及方法进行hash（hash算法为CRC32，此处不展开说明）。
对象
方法
MSFT_CliAlias.FriendlyName='Process'
GetObject
MSFT_LocalizablePropertyValue.ObjectLocator="",PropertyName="Description",RelPath="MSFT_CliAlias.FriendlyName=\"Process\""
GetObject
MSFT_CliAlias.FriendlyName='Process'
GetObject
Win32_Process
GetObject
SetPropValue
CommandLine
当有 hash 等于以下的内置hash时，启动 AMSI 检测。
SetPropValueCommandLine hash得到的结果为 c0b29b3d，故进行AMSI检测。
WMI 检测的 hash 没太大爆破的价值，jscript 和 vba 的检测 hash 如下文所示。 https://github.com/synacktiv/AMSI-Bypass/tree/master

0x05 分析AMSI.dll 的实现

AMSI.dll 不开源，只能通过逆向的方法分析，并且不同版本之间存在一定的差异，以下分析以windows 11 为准，与旧版本的差异会指出一部分，

5.1 AmsiInitialize

首先会创建 COM 对象，在早期版本调用 CoCreateInstance 实现，其会通过注册表CLSID查找和定位COM服务器，由于其会先在注册表 HKCU 项查询，故普通用户也可以对其进行劫持。微软为了修复这个问题将代码改为直接调用更底层的 DllGetClassObject 创建 COM 类工厂。
在 win11 上，此处被替换为调用 AtlComModuleGetClassObject ，网上并未找到分析为什么替换的文章。
调试 AtlComModuleGetClassObject 查看参数。
随后使用 类工厂对象创建 COM对象，ATL::CComClassFactory::CreateInstance 是 ATL 类工厂的一部分，用于创建 COM 对象的实例。创建了 CAmsiAntimalware 对象。 amsi!ATL::CComCreator<ATL::CComObject<CAmsiAntimalware> >::CreateInstance函数负责实际的对象创建过程。CAmsiAntimalware 是 AMSI 的一个具体实现类。
AmsiComCreateProviders 负责创建和初始化 IAntimalwareProvider 接口的实际实例。
AmsiComCreateProviders 调用栈如下。
AmsiComCreateProviders 函数中调用 RegOpenKeyExW 和 RegQueryInfoKeyW 获取
"Software\\Microsoft\\AMSI\\Providers" 的信息，并使用 RegEnumKeyExW 枚举其子项，获取已注册的 AMSI 提供程序的类标识符。随后将提供程序的类标识符传递给 AmsiComSecureLoadInProcServer ，用 RegGetValueW() 查询与 AMSI 提供程序对应的 InProcServer32 值。
然后，AmsiComSecureLoadInProcServer 会调用 amsi!CheckTrustLevel() 读取SOFTWARE\Microsoft\AMSI\FeatureBits 的值，这个键包含一个 DWORD 值，可以是 1（默认值）或 2，用于禁用或启用对提供程序的 Authenticode 签名检查。
随后会调用 LoadLibraryExW 以加载 AMSI 提供程序的 DLL。通过以下方法调试可以看到加载了 MpOav.dll
加载 dll 成功后会调用 dll 的DllGetClassObject函数创建一个类对象，并调用调用 IClassFactory::CreateInstance 获取请求的接口指针。

5.2 AmsiOpenSession

需要重点关注的内容如下
检查输入参数是否有效。如果 amsiSession 或 amsiContext 为 NULL，或者 amsiContext 的第二和第三个 _QWORD 为0，则返回错误代码 -2147024809（通常表示无效参数）。
在 win10 上，这个判断逻辑为
在 win10 中还会额外判断 amsiContext 的第一个 DWORD 值是否为 1230196033 （对应16进制数据0x49534D41，对应字符串 ISMA ，因为小端序的原因，实际匹配的字符串是 AMSI），可能是因为有相当的多的文章修改这个字符串绕过 AMSI，微软在 win11 移除了这个判断逻辑。不过这样治标不治本，攻击者还可以修改另外几处判断。

5.3 AmsiScanBuffer

首先会检测各个参数。
随后通过指针调用了一个函数，用 windbg 看下调用的函数是 amsi!CAmsiAntimalware::Scan 。
CAmsiAntimalware::Scan 会遍历每个已注册的 AMSI 提供程序，调用供应商实现的IAntimalwareProvider::Scan() 函数，如果各个 AMSI 提供程序都没有发现恶意软件，则将结果设置为AMSI_RESULT_NOT_DETECTE 。

参考文章

https://redcanary.com/blog/threat-detection/better-know-a-data-source/amsi/
https://gustavshen.medium.com/bypass-amsi-on-windows-11-75d231b2cac6
https://i.blackhat.com/Asia-22/Friday-Materials/AS-22-Korkos-AMSI-and-Bypass.pdf
https://posts.specterops.io/antimalware-scan-interface-detection-optics-analysis-methodology-858c37c38383
]]> <![CDATA[AMSI研究(3) - 绕过及检测 ]]> https://blog.fatekey.icu/article/AMSI3 https://blog.fatekey.icu/article/AMSI3 Wed, 26 Jun 2024 00:00:00 GMT

0x00 混淆代码

对于 powershell 绕过 AMSI 来说，混淆代码是绕过 AMSI 最基础的步骤，因为大部分绕过方法还是要执行 AMSI 语句，这个用来绕过的语句本身也是要被 AMSI 检测的，所以要对这个绕过语句进行混淆处理。
这块严格来说不是绕过 AMSI，而是绕过 AMSI 对接的安全产品的规则，自带的 windows defender 的规则非常容易绕过。

攻击姿势

经过简单的分割测试，可以确定有如下规则
  • 字符串 'AmsiUtils'
  • 字符串'amsiInitFailed'
  • 同时出现 [Ref].Assembly.GetType GetField SetValue($null,$true)
powershell 语法极为灵活，下面简单列举几种绕过的方法。
使用 like 避免出现完整字符串 + 拆分成多条语句避免同时出现关键字
对方法名进行字符串拼接
拆分成变量
除了手动混淆，也可以使用专门的混淆工具，如：https://github.com/danielbohannon/Invoke-Obfuscation
不过要注意，一些混淆手法是对命令进行加密，再利用Invoke-Expression 执行解密的命令，这样是无法绕过 AMSI 的，因为Invoke-Expression 执行的命令将会被 AMSI 检测，效果如下：
notion image

检测方法

对于分割绕过，可以将同一 powershell 进程执行的多条命令合并后进行检测。
因为 AMSI 需要快速响应，所以很难使用高级检测方案，我的想法是阻断规则和告警规则可以分开，阻断规则就是高性能的正则表达式或者关键字，检测完成后直接返回给 AMSI，避免程序卡死，然后再进行相对耗时的高级检测，将检测结果发往服务端。
  • 使用语法树判断 powershell 代码是否混淆，正常业务一般不会混淆 powershell 代码，所以检测到混淆行为就可以直接告警个低危。（也许需要对一些业务混淆加白）
  • 静态反混淆
      • https://github.com/pan-unit42/public_tools/tree/master/powershellprofiler
  • 动态反混淆 - powershell 沙箱
      • 静态反混淆容易被一些动态特性击败，可以对 powershell 进行二开，做成 powershell 沙箱，真正的获取语句执行的操作。

0x01 降级攻击

降级PowerShell版本到 2.0 可以绕过 AMSI，因为这个版本的 powershell 还没有引入 AMSI 机制。
PowerShell 2.0 基于.NET CLR 2.0，对应的 .NET 版本是 2/3/3.5，这在现在的系统上预装的并不多，可以用以下命令查看安装的 .NET 版本。
早期的部分 win10 预装了 .NET 3.5

攻击姿势

使用 powershell.exe -version 2 改变版本。
在脚本开头加入 #requires -version 2 ，可以指定脚本使用 PowerShell 2.0 执行。

检测方法

检测进程启动事件是否有 -version 2 参数。
检测 powershell 脚本中是否有 #requires -version 2。
感觉只要有这种行为，就可以给个中低危告警了，现在正常业务用 powershell 2 的情况太少了。

0x02 修改注册表

对于 powershell、.NET 之外的 AMSI 检测，不少可以被注册表配置影响，比如 Jscript 对应的 Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable ，wmi 对应的 Software\\Microsoft\\WBEM\\AmsiEnable 。
需要注意的是，这块微软做过多次修改，能不能生效要针对具体的windows版本来分析。
需要注意的是，在早期 win10 中，读取的是 HKEY_CURRENT_USER ，现在读取的是HKEY_LOCAL_MACHINE ，修改相关的注册表需要管理员权限。
此外，还可以直接删除注册表中注册的 Providers来影响 AMSI 正常运作。
HKLM:\SOFTWARE\Microsoft\AMSI\Providers

检测方法

监控修改相关注册表的行为。

0x03 反射

攻击姿势

PowerShell 将有关 AMSI 的信息存储在 System.Management.Automation.AmsiUtils 类内。通过反射与其进行交互。
前面几篇分析过，powershell 在进行 AMSI 扫描时会对 amsiInitFailed 进行判断，如果为 true 则直接跳过扫描。那么可以使用反射访问 AmsiUtils 类中的amsiInitFailed ，将其直接设置为 true。
混淆后
前文还提到 AmsiOpenSession 的参数检查，如果 amsiSession 的指针或 amsiContext 为 NULL，或者 amsiContext 的第二和第三个 _QWORD 为0，则返回错误代码 -2147024809。
那么就可以通过反射获取amsiContext 的地址进行修改，将第二_QWORD 修改为0。
在 win10上，还有个判断验证的是 amsiContext 的第一个 DWORD 值是否为 'AMSI'，这个判断在 win11上被去除了。
在 win10 可以对amsiSession 赋值为 NULL 进行绕过， 在 win11 上并不可以，使用 dnspy 分析代码可以发现 win11 上每次的 amsiSession 都是从新从 amsiContext 中取出的。

检测方法

  • 使用反混淆分析语句
  • hook SetValue，检测设置 amsiInitFailed 值的行为。

0x04 修补

从内存中修补 Amsi.dll 也是常用的绕过的手法。

AmsiInitialize

AmsiInitialize 在执行命令前就已经执行，但可以修补后执行 AmsiUninitialize 重新触发 AmsiInitialize 。
AmsiInitialize 较为复杂且版本差异大，攻击者一般不会考虑修补这个函数的逻辑来绕过，以下仅为研究使用。 （实战要修补的话应该也是修补为强制失败，见后文）
AmsiInitialize 存在如下汇编，可以通过修补满足两个跳转条件，强制跳转返回 80070057h 。
以下脚本内容为获取内存地址、修改内存权限、修补对应内存
触发重新初始化，完成绕过
更通用的绕过脚本，强制返回错误代码

AmsiOpenSession

这是一个比较好的修补对象，在win10和win11上的变化很小，且逻辑较为简单，只要满足第一个跳转条件就可以直接返回报错。
将 test rdx,rdx 修补为 xor rax,rax
脚本如下

AmsiScanBuffer

逻辑比较复杂，可以将函数开头修补为以下内容，以强制其返回错误代码，稍微混淆了下避免特征被匹配。
 

检测方法

  • 去混淆后识别攻击代码特征
  • 扫描 Amsi.dll 中特定地址
      • 性能比扫描整个 Amsi.dll 好点，不过攻击者能修改的位置是非常多的，比较容易被绕过。
  • 内存完整性检查
    • 对 Amsi.dll 的代码部分进行哈希处理，而不是对整个Amsi.dll模块进行哈希处理，与硬盘上 Amsi.dll 的代码部分进行比较。
    • 考虑到性能问题，扫描频率不可能太高，攻击者有可能在完成攻击后将 amsi 修改回去（仅对短时间就能完成目的的攻击有效）。
    • 瞬间修改 Amsi.dll 造成永久失效 （在win10上修改后再改回来可以永久失效，但 win11上不行，win11 每次执行时发现AMSI失败会重新初始化。
        • 经过研究，只要修补AmsiInitialize保证初始化成功但没有执行加载杀毒软件的dll，还是可以在win11瞬间修改造成永久失效的，但这样修补不仅复杂且很容易受 amsi.dll 版本影响。
  • api监控，检测修改 Amsi.dll 内存权限、内存内容的调用。

0x05 ScriptBlock Shaulling

攻击姿势

详见 https://bc-security.org/scriptblock-smuggling
简单来说，就是 PowerShell 中的所有的安全功能都只传递 ScriptBlock 的 Extent ，但实际上还可以通过 BeginBlock 和 EndBlock 执行代码。
可以用以下方法来创建 BeginBlock 或 EndBlock 和 Extent 不一致的代码块
利用方式
可以看到 AMSI 接收的结果和实际执行的命令并不一致
notion image
虽然这样也需要传入恶意命令，但与混淆那里的绕过不同的是，这里传入的恶意命令是字符串，不需要基于 powershell 语法混淆，可以随意进行混淆，解密后的代码不是通过 Invoke-Expression 执行的，也就不用担心

检测方法

检测操控 ScriptBlockAst 的行为，正常业务程序几乎不可能用到这个特性。

0x06 硬件断点

攻击姿势

参考文章：
https://cloud.tencent.com/developer/article/2225484

检测方法（待验证）

参考文章：
https://bbs.kanxue.com/thread-181720.htm

0x07 修补其他程序

因为对 amsi.dll 的修改检测比较严格，所以出现了这种绕过思路。
修补杀毒软件的 amsi 提供程序对应的 dll。
修补调用 amsi.dll 的程序。
比如修补powershell：
https://practicalsecurityanalytics.com/new-amsi-bypass-using-clr-hooking/
https://www.offsec.com/blog/amsi-write-raid-0day-vulnerability/

参考文章

https://mp.weixin.qq.com/s/Sg0LK8emSWP1m-yds4VGrQ
https://blog.f-secure.com/hunting-for-amsi-bypasses/
https://ethicalchaos.dev/2022/04/17/in-process-patchless-amsi-bypass/
]]> <![CDATA[AMSI研究(2) - 实现检测]]> https://blog.fatekey.icu/article/AMSI2 https://blog.fatekey.icu/article/AMSI2 Wed, 19 Jun 2024 00:00:00 GMT
 

0x00 基础

参考项目：https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/AmsiProvider
分析源代码发现 SampleAmsiProvider 类实现了 IAntimalwareProvider 接口。
  • Scan 方法实现了扫描逻辑。
  • CloseSession 方法用于关闭会话。
  • DisplayName 方法返回提供者的显示名称。
Scan 接收IAmsiStream 作为参数，其有两个方法：GetAttribute() 和 Read()。
GetAttribute() 方法获取有关待扫描内容的元数据。开发人员通过传递一个 AMSI_ATTRIBUTE 值来请求这些属性，该值指示他们希望检索的信息。
  • APP_NAME
    • 提交要扫描的内容的应用程序的名称
  • CONTENT_NAME
    • 如果内容源自磁盘上的文件，则该 contentname 为文件的完整路径。如果内容源自内存，则此字段将为空。
  • AMSI_ATTRIBUTE_CONTENT_SIZE、AMSI_ATTRIBUTE_CONTENT_ADDRESS
    • 待扫描内容的地址和大小，可以通过这两个值取出待扫描内容。
    • 一般需要检测的只有 DotNet 和 VSS 事件是二进制数据。
      • coreclr 也是二进制数据，但我感觉 EDR 没有检测的必要。
只有当内容已经完全加载到内存中时才会返回 AMSI_ATTRIBUTE_CONTENT_ADDRESS ，大多数情况下，数据是作为流提供的，在这种情况下，可以使用 Read() 方法来逐块读取缓冲区中的数据。
当 Scan()方法返回时，它必须将 HRESULT 和 AMSI_RESULT 传递给调用方。
可以在 dll 中直接实现检测逻辑，不过我想实现更接近 EDR 的检测流程：dll 获取检测信息，传递给agent，agent 进行判断后再返回给 dll。
💡
需要特别注意的是，执行操作时会等待 Scan() 方法给出扫描结果，并且没有超时机制，所以此处不能用太复杂的扫描逻辑，不然会严重影响相关程序的执行速度。个人感觉可以先文本正则+二进制yara，并且自己实现超时机制。 如果有复杂的检测逻辑，也许可以先用正则和二进制进行检测，返回结果后客户端再进行复杂的检测，如果检出就上报服务器。如果这时还想阻断，可以考虑不借助 AMSI ，直接杀进程。 此外，前文分析 AMSI 实现时发现，AMSI 得到一个恶意结果后，就会退出循环不再调用其余提供者的扫描函数，如果 EDR 要集成 AMSI 的话，是不是把自己的顺序提到 windows definder 前面会更好？

0x01 实现dll

采用JSON协议进行跨语言RPC，将数据传输给 agent 。
主要代码逻辑如下：
代码还有很多优化的空间，如
  • 引入错误处理及超时机制，以免在运行出错、超时的情况下影响 powershell 等程序的运行。
  • 优化通信机制，使用更高效的传输方法。

0x02 实现 agent 接收数据

agent 接收数据比较简单，因为前面的数据就是使用的 go 的 net/rpc/jsonrpc 包规定的格式。

0x03 实现规则检测

对于普通的文本数据，使用正则表达式规则来检测，对于二进制数据，使用 YARA 规则来进行检测。（具体代码不贴了，简单的调用库罢了。）
对不同应用的待检测数据进行分析。
 

powershell

单条命令执行时
执行脚本文件时
告警时，对于得到的脚本文件路径，应该去获取脚本文件的创建、 修改时间、所属用户等信息，对于已经检测过的脚本，可以不再重发触发扫描。

WMI

执行命令产生的数据如下，可以用正则匹配，不过如果做成产品的话也许加入语法解析会更好。
WMIC 执行 cmd 命令
WMIC Process Call Create "cmd /c whoami"
powershell 执行 cmd命令

VSS

 

参考资料

https://learn.microsoft.com/en-us/windows/win32/amsi/dev-audience
https://github.com/cparmn/SoYouWannaBeAnAMSIProvider
 
]]> <![CDATA[wannamine 分析]]> https://blog.fatekey.icu/article/wannamine https://blog.fatekey.icu/article/wannamine Wed, 19 Jan 2022 00:00:00 GMT

0x00 简单分析

notion image
未加壳,c++开发
微步沙箱分析
notion image
微步说可能被加壳?应该是微步误报了吧
火绒剑分析行为
添加过滤
  • 进程过滤-挖矿进程
  • 动作过滤-创建文件\写入文件
notion image
  • 进程过滤-挖矿进程
  • 动作过滤-设置\创建\删除注册表
notion image
  • 进程过滤-挖矿进程
  • 动作过滤-网络连接
notion image
ip 查询
notion image
通过查看对挖矿进程创建 cmd 进程的参数分析执行的命令
notion image
?删除自身可以理解,为什么要 ping 127.0.0.1 呢?
创建服务.服务名应该是随机的,但是看着还挺像正常服务的,应该是有一个随机字典
notion image

0x01 IDA分析

notion image
跟进到 404FF0
notion image
跟进到 4050E0
notion image
notion image
判断Software\\Microsoft\\Windows NT\\CurrentVersion\\NetworkPlatform\\Location Awareness 是否存在.
返回 404FF0 ,以上注册表不存在则调用 404880.这里应该是为了判断病毒是否是第一次运行.
notion image
跟进 404880
发现生成随机服务名,由 3 个部分拼接而成
notion image
生成用到的字典,拼接起来真的有系统服务那味了
notion image
notion image
生成随机服务名.dll
具体生成流程 获取 system 文件夹路径 创建随机文件名文件 删除随机服务名.dll 估计是为了防止生成的 dll 和某些 dll 重名 创建写入随机服务名.dll
创建用于判断是否第一次运行的注册表,通过判断这个注册表是否存在,也就能判断是否感染过这个挖矿病毒了
notion image
404FF0 如果不是第一次运行则进入 4041E0,具体功能为查询服务状态
notion image
再回到 main 函数,进入405330
notion image
notion image
再回到 main 函数,进入405390
notion image
装载后返回了资源在内存中的开始指针
进入 4052D0
notion image
根据之前知道的长度和内存指针,取出内容,创建并写入文件
返回 main 函数
进入 4054F0
notion image
notion image
进入 403F80
notion image
进入 403EA0
notion image
打开并读取之前写入内容那个随机文件名文件
返回 4054F0
notion image
进入 4052D0
notion image
将读取出的内容写入服务名.dll
再再再返回 main 函数
notion image
跟进 4051A0
notion image
读取\设置svchost.exe的创建、访问及上次修改时间
返回主函数,进入 406110
notion image
notion image
进入 405F40
notion image
打开注册表SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost
查询netsvcs 的值
⭐
一般来说，Svchost.exe 总是根据 HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Svchost 下面的键值分组管理DLL 申请的服务，这里的每一键值对应一个独立的Svchost.exe进程，也就是说这里的键值就是在任务管理器中我们看到的Svchost.exe进程。 当然，由于这里的键值并不是一次性全部加载，而是根据需要才加载，因此这里的键值数要多于在任务管理器中看到的Svchost.exe进程数，而每个Svchost.exe进程所包含的服务名、参数值和DLL则来自HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Service 这个键值。
notion image
建立一个连接到服务控制管理器并打开它的数据库
创建一个服务对象，并将其添加到指定的服务控制管理器数据库
这一步创建了随机命名的恶意服务
跟进 405CA0
notion image
设置注册表 SYSTEM\CurrentControlSet\Services\%s 的Description 值
返回 405F40
notion image
再次调用 405CA0设置注册表 SYSTEM\CurrentControlSet\Services\%s\Parameters 的 ServiceDll 值为随机服务名.dll
返回 406110
notion image
建立一个连接到服务控制管理器并打开它的数据库
开启恶意服务,运行恶意服务
该服务释放了挖矿模块dllhostex.exe
返回 main
进入 4041E0
notion image
notion image
notion image
检测恶意服务状态
返回 main,进入4058E0
如果安装成功,传入的是Install_Done,安装失败传入Error_%d
notion image
notion image
得到主机名和系统版本
notion image
拼接请求参数
系统版本,主机名,还有上一步传入的安装结果
进入405670
notion image
获得请求的目标 185.128.24.101:80 与火绒剑记录的一致
返回 4058E0 进入 405720
notion image
发起 http 请求,请求方式为 get, UA 为Mozilla/4.0 (compatible; MSIE 6.1; Windows NT)
返回 main 函数,进入 405570
notion image
notion image
获取病毒文件路径
不开窗口执行命令 cmd.exe /c ping 127.0.0.1 -n 5 & cmd.exe /c del /a
完成病毒自杀

0x02 dll 分析

做了一定的伪装
notion image
主要进行了 2 个操作
创建注册表Software\Microsoft\Windows NT\CurrentVersion\NetworkPlatform\

横向移动 - searchindexer.exe

notion image
写入C:\Windows\NetworkDistribution\ MS17-010永恒之蓝利用工具
notion image
攻击
notion image
是获取内网 ip 选择网段扫描,不是内置网段扫描
会多次扫描

挖矿 - dllhostex.exe

notion image
notion image
看了下,应该就是稍微修改的开源挖矿程序.
⭐
骚操作:系统任务管理器启动时, 挖矿进程会自动退出.任务管理器关闭后, 挖矿进程又会重新启动.
]]>