InlineExecute-Assembly

InlineExecute-Assembly 是一个概念验证的信标对象文件 (BOF)，允许安全专业人员以进程内 .NET 程序集执行的方式，替代 Cobalt Strike 传统的 fork-and-run execute-assembly 模块。InlineExecute-Assembly 将执行任何入口点为 Main(string[] args) 或 Main() 的程序集。这应允许您运行大多数已发布的工具，而无需事先进行任何修改。

BOF 会自动确定执行程序集前需加载到进程中的公共语言运行时 (CLR) 版本（v2.0.50727 或 v4.0.30319），并且在大多数情况下，如果出现问题，应能优雅退出。BOF 还支持多个标志，允许操作员在 .NET 执行前指定多种行为，包括通过内存补丁禁用 AMSI、禁用和恢复 ETW、自定义要创建的 CLR 应用程序域名称、是否创建并将程序集的控制台输出定向到命名管道或邮槽，以及允许操作员将默认入口点从 Main(string[] args) 切换为 Main()。有关用法、用例和可能检测的更多详情，请参阅下文及 https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/。

最后，在与信标植入程序相同的进程中执行 .NET 程序集的优势在于，我们避免了 Cobalt Strike 的 execute-assembly 模块的默认行为——该行为会创建一个新进程来加载/注入 CLR/.NET 程序集。然而，其他 OPSEC 考量仍然存在，例如，我们执行所在的进程通常是否加载 CLR，或者我们执行的 .NET 程序集是否有任何已知签名？因此，缺点是如果某些东西被检测到并杀死（例如被 AMSI 杀死），你的信标也会被杀死。

参考资料

如果没有利用安全社区成员已发布的优秀研究、工具和代码，此工具将无法存在。因此，感谢大家。最后，如果您认为以下列表中遗漏了任何人，请告知我，我将确保添加他们。

• HostingCLR - 这里 - CLR/程序集执行逻辑
• Dotnet-Loader-Shellcode - (by @modexpblog) - 这里 - 包括在 C 中执行 .NET 的 COM 接口在内的全面优秀研究 -> 真正的 MVP
• Donut - (by @TheRealWover 和 @modexpblog) - 这里 - COM 接口头文件
• Memory Patching AMSI Bypass - (by @_RastaMouse) - 这里 - AMSI 内存补丁研究
• Metasploit-Execute-Assembly - (by @b4rtik) - 这里 - 修改的 AMSI 补丁，使用了查找 .NET 版本函数
• ExecuteAssembly - (by @med0x2e) - 这里 - 修改的 aggressor 脚本
• Hiding Your .NET ETW - (by @xpn) - 这里 - 优秀的 ETW 研究
• ETW BOF - (by @ajpc500) - 这里 - 修改的 ETW 补丁
• ExecuteAssembly_Mailslot - (by @N4k3dTurtl3) - 这里 - 使用邮槽进行控制台重定向的修改
• @freefirex2 - 慷慨地分享了一些 BOF 内部工作原理和注意事项。

开始使用

1. 将 inlineExecute-Assembly 文件夹及其所有内容复制到计划通过 Cobalt Strike GUI 应用程序连接的系统。
2. 加载 inlineExecute-Assembly.cna Aggressor 脚本
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        程序集的目录路径 **必需**
--assemblyargs          传递给程序集的参数
--appdomain             更改发送的 AppDomain 的默认名称（默认值为 totesLegit，通过包含的 aggressor 脚本设置）*域始终被卸载*
--amsi                  尝试通过内存补丁禁用 AMSI（如果成功，AMSI 将在进程的整个生命周期内被禁用）
--etw                   尝试通过内存补丁禁用 ETW（如果成功，ETW 将在进程的整个生命周期内被禁用，除非恢复）
--revertetw             尝试通过内存补丁禁用 ETW，然后重新打补丁恢复原始状态
--pipe                  更改命名管道的默认名称（默认值为 totesLegit，通过包含的 aggressor 脚本设置）
--mailslot              切换到使用邮槽重定向控制台输出。更改邮槽的默认名称（如果留空，默认值为 totesLegit，通过包含的 aggressor 脚本设置）
--main                  将入口点更改为 Main()（默认值为 Main(string[] args)）

用例

执行 .NET 程序集

语法

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe

用例

执行带参数的 .NET 程序集

语法

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker

用例

执行带参数的 .NET 程序集并禁用 AMSI

语法

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi

用例

执行带参数的 .NET 程序集并禁用 ETW

语法

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --etw

用例

执行带参数的 .NET 程序集，并通过邮槽（而非默认的命名管道）重定向输出

语法

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --mailslot

用例

执行带参数的 .NET 程序集，并更改 aggressor 脚本中设置的默认命名管道名称

语法

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --pipe forRealLegit

用例

执行 .NET 程序集，并更改 aggressor 脚本中设置的默认应用程序域

语法

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --appdomain forRealLegit

用例

执行入口点为 Main()（而非默认的 Main(string[] args)）的 .NET 程序集

语法

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. 尽管我已经尽力使其尽可能稳定，但无法保证程序不会崩溃或信标不会死亡。我们没有 fork-and-run 的额外优势，即如果出错，信标仍能存活。这是 BOF 的权衡。话虽如此，我强调提前测试你的程序集以确保它们能与此工具正常工作是至关重要的。
2. 由于 BOF 在进程内执行并在运行时接管信标，因此在用于长时间运行的程序集之前应考虑到这一点。如果你选择运行需要很长时间才能返回结果的任务，信标将不会活跃执行更多命令，直到结果返回且程序集运行完毕。这也不会遵循 sleep set。例如，如果你的 sleep 设置为 10 分钟，运行 BOF 后，你会立即在 BOF 执行完毕后获得结果。
3. 除非修改了那些在内存中加载 PE 的工具（例如 SafetyKatz），否则这些工具很可能会杀死你的信标。许多此类工具在 execute-assembly 下工作良好，因为它们能够在退出前从牺牲进程中发送控制台输出。当它们通过我们的进程内 BOF 退出时，会杀死我们的进程，从而杀死我们的信标。这些工具可以修改后工作，但我建议通过 execute-assembly 运行这类程序集，因为其他不符合 OPSEC 的东西可能会加载到你的进程中且无法移除。
4. 如果你的程序集使用了 Environment.Exit，需要将其移除，因为它会杀死进程和信标。
5. 命名管道和邮槽必须是唯一的。如果你没有收到返回数据且信标仍存活，问题很可能在于你需要选择不同的命名管道或邮槽名称。

检测方法

可用于检测和缓解的一些策略：

1. 在 AMSI 和 ETW 内存补丁时使用 PAGE_EXECUTE_READWRITE。这是故意为之，因为很少有程序具有 PAGE_EXECUTE_READWRITE 内存保护的内存区域，这应被视为一个危险信号。
2. 创建的命名管道默认名称为 totesLegit。这是故意为之，可使用签名检测来标记。
3. 创建的邮槽默认名称为 totesLegit。这是故意为之，可使用签名检测来标记。
4. 加载的 AppDomain 默认名称为 totesLegit。这是故意为之，可使用签名检测来标记。
5. 关于检测恶意使用 .NET 的好技巧：这里（by @bohops），这里 和 这里（by F-Secure）
6. 寻找 .NET CLR 加载到可疑进程中的情况，例如绝不应该加载 CLR 的非托管进程。
7. 事件跟踪 这里
8. 寻找其他已知的 Cobalt Strike 信标 IOC 或 C2 出口/通信 IOC。