anthemtotheego/InlineExecute-Assembly

# InlineExecute-Assembly InlineExecute-Assembly 是一个概念验证 Beacon Object File (BOF)，允许安全专业人员将进程内 .NET assembly 执行作为 Cobalt Strike 传统 fork and run execute-assembly 模块的替代方案。InlineExecute-Assembly 将执行任何入口点为 ```Main(string[] args)``` 或 ```Main()``` 的 assembly。这应该允许你在无需任何事先修改的情况下运行大多数已发布的工具。 该 BOF 将在执行前自动确定需要将哪个 Common Language Runtime (CLR) 加载到你的 assembly 进程中（v2.0.50727 或 v4.0.30319），并且在大多数情况下，如果出现任何问题，它会优雅地退出。该 BOF 还支持多个标志，允许操作员在 .NET 执行前指定多种行为，包括通过内存修补禁用 AMSI、通过内存修补禁用和恢复 ETW、自定义要创建的 CLR App Domain 名称、是否创建 assembly 的控制台输出并将其定向到命名管道或 mailslot，以及允许操作员将默认入口点从 Main(string[] args) 切换到 Main()。有关用法、用例和可能的检测的更多详细信息，请参阅下文以及 https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/。 最后，在与 beacon implant 相同的进程中执行我们的 .NET assemblies 的优势在于，我们避免了 Cobalt Strike 的 execute-assembly 模块的默认行为，即创建一个新进程来加载/注入 CLR/.NET assembly。然而，其他的操作安全 (opsec) 考虑因素仍然存在，例如，我们正在其中执行的进程通常会加载 CLR 吗？或者我们正在执行的 .NET assembly 有任何已知的签名吗？因此，缺点是如果确实有东西被检测到并被终止（例如被 AMSI），你的 beacon 也会被终止。 # 主题参考 如果没有安全社区成员已经发布的一些非常棒的研究、工具和代码作为基础，这个工具就不会存在。非常感谢。最后，如果你觉得下面遗漏了任何人，请告诉我，我一定会把他们加上。 - HostingCLR - [此处](https://github.com/etormadiv/HostingCLR) - CLR/Executing assembly 逻辑 - Dotnet-Loader-Shellcode - (作者 [@modexpblog](https://twitter.com/modexpblog)) - [此处](https://modexp.wordpress.com/2019/05/10/dotnet-loader-shellcode/) - 总体上非常棒的研究，包括关于用于在 C 中执行 .NET 的 COM 接口 -> 真正的 MVP - Donut - (作者 [@TheRealWover](https://twitter.com/TheRealWover) 和 [@modexpblog](https://twitter.com/modexpblog)) - [此处](https://github.com/TheWover/donut) - COM 接口头文件 - Memory Patching AMSI Bypass - (作者 [@_RastaMouse](https://twitter.com/_RastaMouse)) - [此处](https://rastamouse.me/memory-patching-amsi-bypass/) - AMSI 内存修补研究 - Metasploit-Execute-Assembly - (作者 [@b4rtik](https://twitter.com/b4rtik)) - [此处](https://github.com/b4rtik/metasploit-execute-assembly) - 修改后的 AMSI 修补并使用了查找 .NET 版本功能 - ExecuteAssembly - (作者 [@med0x2e](https://twitter.com/med0x2e))- [此处](https://github.com/med0x2e/ExecuteAssembly) - 修改后的 aggressor script - Hiding Your .NET ETW - (作者 [@_xpn_](https://twitter.com/_xpn_)) - [此处](https://www.mdsec.co.uk/2020/03/hiding-your-net-etw/) - 非常棒的 ETW 研究 - ETW BOF - (作者 [@ajpc500](https://twitter.com/ajpc500))- [此处](https://github.com/ajpc500/BOFs/tree/main/ETW) - 修改后的 ETW 修补 - ExecuteAssembly_Mailslot - (作者 [@N4k3dTurtl3](https://twitter.com/N4k3dTurtl3))- [此处](https://github.com/N4kedTurtle/ExecuteAssembly_Mailslot) - 修改后使用 mailslots 进行控制台重定向 - [@freefirex2](https://twitter.com/freefirex2) - 非常慷慨地分享了一些关于 BOF 内部工作原理和陷阱的知识。 ## 入门指南 1. 将 inlineExecute-Assembly 文件夹及其所有内容复制到你计划通过 Cobalt Strike GUI 应用程序连接的系统上。 2. 加载 inlineExecute-Assembly.cna Aggressor script 3. 运行 inlineExecute-Assembly --dotnetassembly /path/to/assembly.exe 以进行最基本的执行（有关特定标签示例，请参阅下文的用例） ### 自行构建 在 src 目录下通过 x64 Native Tools Command Prompt for VS 2019 运行以下命令 ``` cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx64.o ``` 在 src 目录下通过 x86 Native Tools Command Prompt for VS 2019 运行以下命令 ``` cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx86.o ``` ### 标志 ``` --dotnetassembly Directory path to your assembly **required** --assemblyargs Assembly arguments to pass --appdomain Change default name of AppDomain sent (default value is totesLegit and is set via the included aggressor script) *Domain always unloaded* --amsi Attempts to disable AMSI via in memory patching (If successful AMSI will be disabled for the entire life of process) --etw Attempts to disable ETW via in memory patching (If successful ETW will be disabled for the entire life of process unless reverted) --revertetw Attempts to disable ETW via in memory patching and then repatches it back to original state --pipe Change default name of named pipe (default value is totesLegit and is set via the included aggressor script) --mailslot Switches to using mailslots to redirect console output. Changes default name of mailslot (If left blank, default value is totesLegit and is set via the included aggressor script) --main Changes entry point to Main() (default value is Main(string[] args)) ``` ### 用例 ### 语法 ``` beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe ``` ### 用例 ### 语法 ``` beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker ``` ### 用例 ### 语法 ``` beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi ``` ### 用例 ### 语法 ``` beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --etw ``` ### 用例 ### 语法 ``` beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --mailslot ``` ### 用例 ### 语法 ``` beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --pipe forRealLegit ``` ### 用例 ### 语法 ``` beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --appdomain forRealLegit ``` ### 用例 ### 语法 ``` beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/simpleMain.exe --main ``` ### 用例 ### 语法 ``` beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi --etw --appdomain forRealLegit --mailslot forRealLegit ``` ## 注意事项 1. 虽然我已经尽力使其尽可能稳定，但无法保证永远不会崩溃或 beacon 不会死亡。我们没有 fork and run 那样的额外保障（如果出现问题，我们的 beacon 还能存活）。这是 BOF 的权衡之处。话虽如此，我必须强调事先测试你的 assemblies 以确保它们能与该工具正常工作是何等重要。 2. 由于 BOF 是在进程内执行的并接管运行中的 beacon，在将其用于长时间运行的 assemblies 之前应考虑到这一点。如果你选择运行需要很长时间才能返回结果的东西，在结果返回且 assembly 完成运行之前，你的 beacon 将无法处于活动状态以运行更多命令。这也不遵守 sleep 设置。例如，如果你的 sleep 设置为 10 分钟并且你运行了该 BOF，你将在 BOF 完成执行后立即获得结果。 3. 除非对在内存中加载 PE 的工具（例如 SafetyKatz）进行修改，否则这些工具很可能会杀死你的 beacon。许多此类工具在 execute-assembly 下工作正常，因为它们能够在退出前从牺牲进程发送其控制台输出。当它们通过我们的进程内 BOF 退出时，它们会杀死我们的进程，从而杀死我们的 beacon。这些可以被修改以正常工作，但我建议通过 execute-assembly 运行这些类型的 assemblies，因为其他非 OPSEC 友好的东西可能会被加载到你的进程中且不会被移除。 4. 如果你的 assembly 使用了 Environment.Exit，则需要将其移除，因为它会杀死进程和 beacon。 5. 命名管道和 mail slot 需要是唯一的。如果你没有收到返回数据且 beacon 仍然存活，问题很可能是你需要选择一个不同的命名管道或 mail slot 名称。 ## 检测 一些可能被使用的检测和缓解策略： 1. 在执行 AMSI 和 ETW 内存修补时使用 PAGE_EXECUTE_READWRITE。这是故意为之的，应该是一个危险信号，因为很少有程序的内存范围具有 PAGE_EXECUTE_READWRITE 的内存保护属性。 2. 创建的命名管道的默认名称是 totesLegit。这是故意为之的，可以使用签名检测来标记它。 3. 创建的 mailslot 的默认名称是 totesLegit。这是故意为之的，可以使用签名检测来标记它。 4. 加载的 AppDomain 的默认名称是 totesLegit。这是故意为之的，可以使用签名检测来标记它。 5. 关于检测恶意使用 .NET 的好建议 (作者 [@bohops](https://twitter.com/bohops)) [此处](https://bohops.com/2021/03/16/investigating-net-clr-usage-log-tampering-techniques-for-edr-evasion/)，(作者 F-Secure) [此处](https://blog.f-secure.com/detecting-malicious-use-of-net-part-1/)，以及 [此处](https://blog.f-secure.com/detecting-malicious-use-of-net-part-2/) 6. 寻找加载到可疑进程中的 .NET CLR，例如永远不应加载 CLR 的非托管进程。 7. 事件追踪 [此处](https://docs.microsoft.com/en-us/windows/win32/etw/about-event-tracing) 8. 寻找其他已知的 Cobalt Strike Beacon IOC 或 C2 出口/通信 IOC。

标签：AMSI 旁路, BOF, CLR 加载, Cobalt Strike, DAST, ETW 修补, QEMU, SCP, TGT, Waymore结果处理, 代码执行, 免杀技术, 内存修补, 内联执行, 反取证, 反向工程, 安全评估, 客户端加密, 客户端加密, 恶意软件分析, 攻击诱捕, 攻防演练, 数据展示, 暴力破解检测, 欺骗防御, 端点可见性, 红队, 网络安全, 进程内执行, 隐私保护