CompilerParameters compilerParams = new CompilerParameters();
compilerParams.GenerateExecutable = false;
compilerParams.OutputAssembly = ""; // 设置为空字符串
compilerParams.GenerateInMemory = true; // 启用内存生成
compilerParams.ReferencedAssemblies.Add("System.Web.dll"); // 引用必要库
// ... 添加其他所需引用

CSharpCodeProvider provider = new CSharpCodeProvider();
CompilerResults results = provider.CompileAssemblyFromSource(compilerParams, maliciousCSharpCode);

if (results.Errors.HasErrors) {
    // 处理编译错误
    return;
}

Assembly compiledAssembly = results.CompiledAssembly;
// 通过反射执行编译后的恶意代码，例如：
// Type evilType = compiledAssembly.GetType("MyNamespace.WebShell");
// object instance = Activator.CreateInstance(evilType);

基于 CSharpCodeProvider 的 WebService 内存马 (Memshell) 利用与检测分析 1. 核心组件：CSharpCodeProvider 与 CompilerParameters CSharpCodeProvider CSharpCodeProvider 是 .NET Framework 中的一个类（位于 Microsoft.CSharp 命名空间），它提供了编译和执行 C# 源代码的能力。攻击者可以利用它动态编译恶意的 C# 代码，并将其加载到当前应用程序域中，从而实现无文件攻击。 CompilerParameters CompilerParameters 对象用于控制编译过程的关键参数，其重要属性如下： | 参数名 | 作用 | 攻击利用中的意义 | | :--- | :--- | :--- | | GenerateExecutable | True 生成 EXE， False 生成 DLL | 必须设为 False 以生成 .NET 库文件 | | OutputAssembly | 指定输出程序集的物理路径 | 关键 ：控制文件是否落地。若为空且启用 GenerateInMemory ，则只内存加载 | | GenerateInMemory | True 则在内存中生成，不写文件 | 核心 ：实现无文件攻击的关键，使 DLL 仅驻留于内存 | | ReferencedAssemblies | StringCollection 类型，需添加代码引用的程序集 | 必须正确引用目标环境中的依赖（如 System.Web.dll ） | | IncludeDebugInformation | 是否生成调试信息（PDB） | 通常设为 False ，避免增加特征 | | CompilerOptions | 设置编译器参数（如 /optimize ） | 可用于优化代码或规避检测 | 关键配置示例（C#）： 2. 编译方法：CompileAssemblyFromSource CSharpCodeProvider.CompileAssemblyFromSource 方法接收 CompilerParameters 和源代码字符串，编译后返回 CompilerResults 对象。 CompilerResults.CompiledAssembly : 包含了编译成功后在内存中加载的 Assembly 对象。通过反射即可调用其中的类和方法。 CompilerResults.Errors : 检查编译错误。 基础利用代码示例： 3. 利用方式分析 尝试1：文件落地 - 替换/添加 WebService (.asmx) 方法 ：将 OutputAssembly 路径设置为 Web 应用程序的 bin 目录（如 C:inetpubwwwrootbinsp.dll ），并编写一个对应的 .asmx 文件指向该 DLL 中的类。 原理 ：.NET Framework 检测到 bin 目录变更后会重启应用域，从而使 WebShell 生效。 优点 ：稳定，像正常 WebService 一样工作。 缺点 ： 文件落地 。DLL 和 .asmx 文件都会写入磁盘，容易被文件监控系统发现和清除。 尝试2：文件落地 - 覆盖现有业务 DLL 方法 ：将 OutputAssembly 路径设置为一个现有的业务 DLL（如 binusiness.dll ），在反编译该 DLL 后植入恶意代码，再编译覆盖。 优点 ：隐蔽性较高，重启后仍存在。 缺点 ： 破坏性 ：极易导致正常业务逻辑异常，造成服务中断。 文件落地 ：覆盖操作会被检测到。 不可逆 ：难以恢复原状。 工具 ：文中提到了工具 SpawnDllExp （作者声明谨慎使用）。 尝试3：纯内存马 - 初始失败的尝试 方法 ：设置 GenerateInMemory = true 且 OutputAssembly = "" ，期望编译后的 Assembly 能像普通 WebService 一样通过 URL 访问。 结果 ： 失败 。即使 DLL 已加载到内存，访问对应的 .asmx 路径仍会报错“未能创建类型”。 原因 ：IIS/ASP.NET 路由机制并非从当前已加载的所有内存程序集中查找 WebService 类型，而是通过另一套 编译和缓存机制 来定位。 4. 原理探索：ASP.NET WebService 路由机制 失败的根本原因在于 IIS 处理 .asmx 请求的流程。其核心步骤如下： 请求处理程序 (Handler) ： .asmx 请求由 WebServiceHandlerFactory 处理。 虚拟路径编译 (VirtualPath Compilation) ： 工厂类会根据请求的 URL 虚拟路径（VirtualPath）调用 GetVPathBuildResultInternal 方法。 该方法首先检查 缓存 中是否已有编译结果。 如果缓存未命中，则会启动编译流程 CompileWebFile 。 编译流程 ： 系统会创建一个 WebServiceBuildProvider 。 该 Provider 会解析站点的 配置文件 （ web.config 和 machine.config ），获取 system.web/compilation/assemblies 节点中配置的 引用程序集列表 ( ReferencedAssemblies )。 关键点 ：这个引用列表通常只包含 System.Web.dll 等系统库和 Web 应用程序 bin 目录下的所有 DLL（通过 * 通配符指定）。 它不会包含通过 CSharpCodeProvider 动态加载到内存中的未知程序集 。 最终， WebServiceBuildProvider 会从其配置的引用程序集中查找 .asmx 文件中 WebService 指令所指定的类。由于我们的恶意程序集不在这个列表里，因此查找失败。 结论 ：IIS 路由 WebService 时依赖一套 独立的、基于配置和物理文件的编译系统 ，而非当前 AppDomain 中的所有内存程序集。这是尝试3失败的根源。 5. 升级利用：操纵缓存注入内存马 既然正常路由流程走不通，作者发现了 绕过编译流程、直接向缓存投毒 的方法。 攻击点 ：在 GetVPathBuildResultInternal 方法中，首先会查询一个缓存字典（ _buildResultCache ）。如果能找到以 VirtualPath 为 Key 的缓存项，就会直接使用缓存中的结果，而 跳过后续所有编译步骤 。 攻击思路 ：如果我们能伪造一个合法的 BuildResult （包含我们恶意内存程序集中的类型），并以目标 URL 的 VirtualPath 为 Key，将其注入到这个缓存字典中，那么当请求该 URL 时，IIS 就会直接使用我们缓存的恶意类型，从而执行我们的内存马。 实现步骤 ： 使用 CSharpCodeProvider 将恶意代码编译到内存程序集（ CompilerResults.CompiledAssembly ）中。 通过反射创建 WebServiceBuildProvider 或类似的 BuildProvider。 伪造关键字段：将 _sourceString 设为一个非空字符串（如 " " ）以使 HasInlineCode 为 True ，将 _typeName 设置为恶意类的完整名称。 将 CompilerResults 赋值给 BuildProvider 的相关字段，使其 GetBuildResult 方法能返回从我们内存程序集中获取的类型。 通过反射获取到 _buildResultCache 字典，并将目标 VirtualPath 和伪造的 BuildResult 添加到缓存中。 结果 ： 无需创建任何 .asmx 文件 。只要缓存成功注入，访问对应的 URL 路径即可触发内存马。 真正实现了无文件、无触碰 Web 目录的 WebService 内存马 。 6. 检测与防御建议 检测 内存扫描 ：监控当前 AppDomain 中所有已加载的程序集，识别可疑的、动态生成的程序集（如名称随机、无物理路径）。 缓存监控 ：通过反射定期检查 _buildResultCache 等内部缓存结构，查找是否存在与已知业务无关的 VirtualPath 和类型。 行为监控 ：检测 CSharpCodeProvider 的创建和使用，尤其是在 Web 应用程序中。 流量分析 ：检测异常的、类似 WebService 的 POST/SOAP 请求。 防御 权限控制 ：在服务器上严格限制 .NET 代码的编译权限，考虑移除 Microsoft.CSharp 程序集或限制其访问。 配置加固 ：检查 web.config ，确保 compilation 配置的严谨性，避免不必要的程序集引用。 监控预警 ：部署完善的文件、进程和网络监控系统，对可疑行为及时报警。 应用白名单 ：如果可行，考虑使用应用程序白名单机制，禁止未知程序集的加载和执行。 7. 总结 本文详细分析了一种高级的 .NET WebService 内存马技术。其核心突破在于： 利用 CSharpCodeProvider 实现代码的 内存编译与加载 。 通过深入研究 IIS ASP.NET 路由机制，发现了其 对缓存机制的依赖 。 通过 反射操纵内部缓存 ，成功将内存中的恶意类型注册为可路由的 WebService Handler。 最终实现了 无需文件落地、无需重启、无需修改现有业务文件 的隐蔽内存马，具备很高的实战利用价值和隐蔽性。 相应的防御需要深入到运行时内存和框架内部机制进行检测，难度较大，对防御者的技术深度提出了挑战。