初始访问行动第二部分：攻击性DevOps

挑战

正如本博客第一部分所述，成熟组织中的Windows终端防御技术栈对红队初始访问行动构成了挑战。在高度检测环境中实现初始访问成功，通常需要满足以下最低工件使用标准：

• 生成的软件工件具有独特性，以规避任何静态分析检测。
• 用户模式工件执行时抑制Windows事件跟踪。
• 内核回调通知要么“不引人注意”，要么更好的是被禁用。
• 工件API使用不足以触发动态NTDLL API挂钩行为。
• 从进程树分析角度看，父子进程关系不引人注意。
• 任何进程线程创建最好由某些签名/合法的磁盘（DLL模块）工件支持。
• 沙箱执行将迫使我们的工件立即中止/终止。
• 任何内核级利用不能使用阻止列表中的驱动程序。

虽然上述内容易于书写，但实现这些目标的实际软件/恶意软件开发技术却非易事。为了完全有效，我们需要能够动态重新编译恶意软件工件，以改变工件大小和熵、使用唯一加密密钥、重新处理传入的shellcode、提供引入操作员可配置选项的能力、工件签名等。所有这些项目直接指向采用持续集成/持续开发（CI/CD）方法，为生成的工件实现一定程度的持续防御规避。我们采用了GitLab社区版的CI/CD功能集来实现这种方法。以下描述了我称之为“恶意软件即服务（MAAS）”的通用方法，并引入了一个公共存储库作为模板，您可以使用它来实现类似目标。

GitLab CI/CD流水线

GitLab CI/CD流水线由易于人类理解的YML文件语法驱动，可以通过在GitLab存储库的主目录中放置名为“.gitlab-ci.yml”的文件来启用。

• YML语法允许我们在流水线中定义构建阶段，每个阶段关联不同的作业。
• 任何单个流水线运行都可以通过存储库的“git commit”和推送或合并操作触发。
• YML语法允许我们定义触发操作，从而允许动态创建子流水线。
• 任何子流水线只是由父/全局YML配置触发的另一个YML文件。

GitLab运行器

GitLab运行器是安装在独立服务器或虚拟容器上的软件，它使用GitLab API轮询存储库以执行流水线作业。当它首次启动时，GitLab运行器将通过API注册自身，从而允许它随后处理发送给它的任何流水线作业。

运行器将处理GitLab YML文件中的指令，在大多数情况下，这将包括处理由YML内容中的脚本标签指示的脚本。该脚本通常由本机操作系统“shell”执行，在Windows的情况下，这可能是CMD.EXE，而在Linux的情况下，这可能是/bin/bash或类似。使用的“shell”是可配置的，例如，如果您想要跨平台的通用shell语法，可以设置为“pwsh.exe”或“pwsh”。

根据我们的软件编译需求，我们选择部署基于Windows的运行器和基于Linux的运行器，Windows系统上配置了PowerShell，Linux运行器上配置了默认的/bin/bash shell，我们选择在Docker容器中部署这些运行器。

使用Docker的特定架构选择主要由生成动态流水线配置信息的Python脚本集驱动。Docker本质上减轻了整个环境中的版本控制和变更控制负担。

在我们的案例中，我们确实需要完整的Microsoft编译工具链，以及基于Linux的mingw-gcc、Golang、Rust和完整的mono/.NET安装。这需要部署基于Windows和Linux的运行器架构以及共享存储。下图是我们的1.0版本架构。

精明的观察者会注意到Docker部署在Linux主机上，但未部署在Windows架构中。虽然可以在Windows平台上运行Docker，但在该架构的第一个版本时，需要在HyperV Windows容器模式或Linux容器模式之间进行选择，因此以本机O/S形式部署这些服务器变得更容易。您还会注意到整个架构包含在ESXi管理程序中，未来将扩展和复制以实现冗余。

工件生成Docker容器

在后端使用Docker swarm和共享存储允许我们部署专用的Docker容器用于动态恶意软件生成。我们目前有两种不同类型的容器，一种是基于Python的框架，用于编译C#、Golang和C/C++源代码，另一种专用于Rust语言和编译器。

作为C#/.NET框架容器系统的一部分，我们部署了模块来执行源代码混淆、各种规避技术（如ETW和AMSI绕过补丁），以及根据需要执行PE/COFF修复的代码，例如重新计算PE头校验和。

CI/CD流水线执行

下图直接从GitLab捕获，显示了流水线执行的各个阶段。列出了早期准备阶段、工件生成阶段、动态子流水线触发阶段和后处理活动。CI/CD流水线的部分执行专用任务，例如从现有恶意软件工件生成MSIX/AppX和ClickOnce包。

流水线作业并行化通过GitLab运行器配置选项和整体架构中的多个Docker容器注册来实现。其中一个专用容器使用资源脚本消耗的概念，这允许我们按架构和编译语言拆分编译作业。当然，还有其他方法可以并行化运行器执行作业，具体取决于动态子流水线YML配置的生成方式。

GitLab运行器YML文件和Python生成脚本

主/父流水线脚本包含在存储库根目录的“.gitlab-ci.yml”文件中。在此文件中，定义了动态子流水线触发器，这些触发器调用用于为下游阶段流水线作业执行生成更多YML配置的Python脚本。这些生成的YML文件工件从流水线执行的早期阶段传递到后期阶段。

下图是主“.gitlab-ci.yml”文件的快照，显示了众多方面，包括流水线阶段、全局流水线触发操作的工作流规则以及初始准备阶段，该阶段动态生成一些用于下游阶段的YML。

为了完整起见，我还包含了一个配置部分的截图，显示了作为流水线“BakingMalware”阶段一部分执行的动态触发器依赖关系。

如何操作恶意软件工件生成流水线

红队操作员可能需要提供许多潜在输入。这些可能是任何东西，从提供shellcode本身、配置各种规避开关、IP地址信息、URL等。

我们亲切地将我们的内部流水线称为Payload或Malware Buffet，因此，我提供了一个名为“BuffetConfig.yml”的配置文件，操作员必须编辑该文件，然后推送更改并触发流水线执行。这个特定的YML文件由流水线执行中的各种脚本处理，并且与驱动流水线本身的YML内容明显不同。

为了进一步增强和标准化我们的配置，此“BuffetConfig.yml”文件的默认参数现在使用Python“pydantic”模型在Python类中表示。这一步使我们能够进一步朝着由我们组织中的其他操作部署软件自动触发此流水线的方向迈进。在我们的路线图中，还计划直接提供一个用于配置目的的Web界面。

此图是此“BuffetConfig.yml”文件部分内容的示例。请注意，“Zulu Foxtrot”是对恶意软件工件生成容器的引用。

流水线执行的预期结果

当流水线被触发并且所有阶段都已执行时，我们在后处理阶段生成包含生成工件的ZIP文件，供红队操作员使用。将有多个ZIP文件，包含诸如原始工件本身（EXE、DLL、反射DLL、XLL和其他所需文件）、清单信息、MSIX/AppX、ClickOnce和其他打包方法等项目。

使用仅配置一个工件生成容器的适度配置，示例结果如下：

• 57个二进制工件和基于HTML的MANIFEST
• 19个EXE，包括Windows托管（.NET）和本机非托管变体
• 26个DLL，包括托管和非托管
• 4个RDLL（反射本机/非托管）
• 6个XLL（Excel DLL）
• 9个MSIX/AppX包
• 9个Click Once包
• 在适度的20Mb工件膨胀（熵减少器）配置下，产生超过1GB的总数据内容

指标和跟踪

流水线的最后一个后处理阶段之一使用Python脚本计算生成工件的各种哈希值（MD5、SHA1和SHA256），并将结果写入SQLITE数据库，其中包含日期/时间戳信息用于跟踪目的。

这些数据允许我们做许多事情，包括以图形形式生成随时间推移的工件生成摘要。下图显示了2023年9月期间流水线的一些工件生成统计数据。

CI/CD方法的优势

结合Docker容器框架，我们可以在每次流水线运行时实现自动化的唯一二进制工件生成交付。这包括多种工件类型，具有用于任何嵌入工件的唯一加密密钥生成和唯一源代码混淆技术。

整体流水线方法使我们能够灵活地以系统方式添加或修改新的恶意软件开发技术，并使其快速提供给红队操作员。流水线还为不同形式的预处理和后处理打开了机会，无论是进一步的嵌入shellcode编码，还是后工件重新打包的形式。毫无疑问，这种方法使我们能够提供轻松规避静态工件分析阶段的防御绕过技术，而是将负担上移/提高标准到工件执行中的行为分析。

CI/CD方法的劣势

流水线配置和执行具有显著的复杂性。存在许多软件依赖关系，形式为多种语言编译器、多种不同工具以及GitLab运行器上的版本控制问题。

此外，CI/CD流水线故障排除的速度是一个挑战，平均流水线运行需要3到10分钟。当前架构对配置输入中的简单语法错误过于敏感，Python脚本膨胀水平不断增加以驱动动态元素。

使用“git”本身并不是理想的操作员用户界面，向