文章总结： 本文探讨了使用网状网络技术设计弹性植入体通信架构的可能性，以提高红队操作的弹性和持久性。作者分析了传统点对点植入体通信模型的局限性，并提出使用Nebula等覆盖网络工具创建更灵活的网状网络通信架构。文章详细介绍了三种实验场景：外部托管的Lighthouse、目标DMZ上的Lighthouse以及气隙网络笔记本电脑场景。同时，作者深入讨论了网状弹性植入体的设计考量，包括执行防护栏、代理列表、路由优先级、凭证材料与认证、权限级别等关键因素。最后，文章提出为网状弹性植入体通信建立一种标准方式的建议，类似于BOFs/BOFPEs或异步BOFs，使P2P通信能够从植入体本身抽象出来，获得更大的灵活性。 综合评分： 85 文章分类： 红队,内网渗透,安全建设,网络弹性,网状网络

---

网状弹性植入体通信架构设计探索

Mac

securitainment

2025年12月13日 17:53 中国香港

阅读时间：17 分钟

本文的配套代码仓库（Claude 辅助完成）位于：https://github.com/BaffledJimmy/NebulaPOC。

如果你时间紧迫，核心观点是：能否为植入体的网状通信建立一套标准，类似于 BOFs / BOFPEs 或异步 BOFs，让我们能够将 P2P 通信从植入体本身抽象出来，获得更大的灵活性。

目录

• 引言
• 已知实现方案
• 第一部分 – 托管在互联网上的控制服务器
• Nebula
• Lighthouse
• 为什么选择 Nebula
• 中继节点
• 实验环境
• 虚拟机
• 网络弹性植入体的设计考量
• 执行防护栏
• 代理列表
• 下一跳
• 路由优先级
• 凭证材料与认证
• 权限级别
• 隐藏网络连接
• 分阶段加载
• 时间戳与路由信息
• 实验 1 – 外部托管的 Lighthouse
• 实验 2 – 目标 DMZ 上的 Lighthouse
• 实验 3 – 气隙网络笔记本电脑
• 结论
• 参考文献

引言

红队多年来一直在使用跳板植入体，甚至 Meterpreter 在 2010 年代就已经具备了多种跳板选项（而 netcat重定向技术已经存在了数十年）。然而，在商业或开源领域，植入体的本质始终是点对点（P2P）的——你有一个出口植入体向互联网发送心跳，然后目标环境内的 N 个跳板植入体都通过它进行通信。

OST、Nighthawk 和 Cobalt Strike 等商业 C2 框架都具备某种形式的 SMB 或 TCP 植入体功能。然而问题依然存在：如果你失去了出口植入体，就需要重新获取访问权限，然后重新连接到跳板植入体。如果一切顺利（!!!），植入体链或植入体集合将自动重新连接。Nighthawk 还有一个功能，当植入体无法通过主路由或代理出口时，会尝试故障转移到出口/P2P 模式（反之亦然）。

多年来的各种泄露和应急响应报告表明，复杂的植入体能够感知同一行动中的其他植入体，并在内部网络以及互联网上被入侵主机的网络之间形成自己的弹性子网络。如果通往外部环境的通信路径被中断，植入体能够使用其内置路由表确定另一条通往互联网并返回 C2 服务器的路由。这可能通过不同的代理、不同的网关/防火墙，甚至是之前横向移动到的另一台工作站来实现。

VPN 技术的最新进展催生了 CloudFlare Tunnels、TailScale 和 Nebula（最初来自 Slack，现在似乎有一家名为 Defined Networking 的公司提供商业服务）等产品。已有多人发表过演讲，讨论如何将这些技术用于初始访问，以及如何获得进入目标环境的稳定网络连接并规避 EDR 检测的某些方面。

我认为探索一下能否使用一些现成的技术来复制智能植入体的网状网络特性会很有趣，同时也考虑一些不同的设计思路。实际上，我们是在为植入体通信提供一条独立于主操作系统网络栈的网络路径，从概念上讲，植入体拥有自己的网络栈，可以（在需要时）自动发现新的对等节点。这个想法要么允许在新植入体或出口路由可用时远程更新植入体内部的路由表，要么将两者完全分离，使植入体之间的网络连接仅仅成为一种可以隧道传输额外功能的机制（或许可以称为一个增强版的 SOCKS 代理网格！）。

考虑一下在网状感知架构中，前面的场景会有什么不同：

在网状感知模型中，域控制器上的植入体 D 知道它可以通过植入体 A（经由 B 和 C）或通过植入体 E（经由 F，如果可达）到达互联网。如果 A 变得不可用，D 可以查询其路由表，确定 E 提供了一条替代路径，并通过该路由建立连接。

这要求植入体 D 知道植入体 E 的存在和能力——这是传统点对点架构中无法获得的信息。网状网络必须共享关于哪些节点可以到达哪些网络的状态信息。

Sliver 可以在许多操作系统上无需提升权限即可建立 WireGuard 接口。WireGuard 的用户空间实现（wireguard-go）可以在支持非特权用户命名空间的平台上使用标准用户权限创建 TUN 接口。这意味着低权限植入体可以通过隧道路由流量而无需管理员或 root 权限。

然而，Sliver 的 WireGuard 实现仍然是基于点对点的。每个隧道将一个植入体连接到 Sliver 服务器或另一个植入体。没有网状发现功能。如果植入体的隧道端点变得不可用，它不会自动通过其他被入侵主机寻找替代路径。

已知实现方案

这里的所有内容都来源于开源知识或情报。

据报道，FSB 的 Snake 恶意软件网络具有 forward命令，允许全球 P2P 网络简单地转发操作员命令，直到最终目标植入体接收到为止。CISA 发布的公开咨询详细剖析了该植入体，堪称 10 分满分的佳作，其中提到了所使用的对等寻址方法，允许操作员在需要时手动定制网状网络。它还有一个内核模块用于拦截 TCP 会话——这在本文中不会涉及，但专业级植入体应该能够实现。在实验中，我们只是监听一个空闲端口！

Cobra 植入体（可以使用 Snake 进行通信）和 Regin 植入体（由 Kaspersky 披露）也明确提到了植入体组成网状网络，在 Regin 的案例中还使用了 GSM 基站。下图包含了文章中最相关的部分，完整文章可在文末参考文献中找到。

中国也有使用这些技术的实例，如 APT41、APT10 和 PlushDaemon 所示。盘古实验室在分析据称属于 NSA 的 Bvp47 植入体时也提到了网状网络。

显然，各国机构拥有更长的行动周期、更多的零日漏洞、更大的预算、更强的能力以及全球规模/法律豁免——但我们可以使用一个简化版本来让我们的小型红队对遏制和跨平台攻击更具弹性。

第一部分 – 托管在互联网上的控制服务器

我在这里强调的是设计未来工具的原则，而不是建议任何人开始在客户环境中运行 ./my_nebula_implant。但这个系列确实对如何以及在哪里放置主机注册，以及所需的固定不可变配置或植入体安全级别提出了一些不同的观点。

Nebula

Lighthouse

Nebula 有一些不错的文档，可以在这里和这里进行更广泛的阅读。最重要的组件（除了 CA 之外）是 Lighthouse，它了解所有主机的信息——在主机注册时需要能够连接到 Lighthouse，并了解可以中继的主机。

据我理解，在这种 Nebula 部署方式中，如果不在每个配置中硬编码主机和 IP（以及所需的证书），就无法避免这一点。Nebula 的一个很酷的功能是自动发现新连接的主机，或者你可以使用 static_host_map在每个配置中硬编码每个主机和 IP——费力但也暴露了比我们可能需要的更多信息。

Slack 的 Nebula 是一个开源的覆盖网络工具，可以在任意底层基础设施上创建加密的网状网络。我并不是将 Nebula 本身作为植入体提出（尽管它确实可以…）。我使用 Nebula 来演示可以为植入体架构设计提供参考的网状网络概念。

为什么选择 Nebula

• 证书

  – Nebula 网络中的每个节点都有一个由证书颁发机构签发的加密身份。节点可以验证对等方身份并根据证书属性限制通信。

• 自动发现

  – 节点可以通过维护节点位置注册表的 Lighthouse 服务器相互发现。这提供了无需静态配置每个对等方的对等发现功能。

• 中继

  – 无法直接通信的节点（由于 NAT 或防火墙）可以通过具有更广泛连接性的中继节点路由流量。

• 无需 root

  – Nebula 可以在有或没有 TUN 接口的情况下运行。如果不需要在本地路由 IP 流量，Lighthouse 或中继节点可以在没有 root 权限的情况下运行。

中继节点

中继节点可以为位于不同子网的主机提供一种桥接回主 Nebula 网状网络的方式。从概念上讲，这可以是一台具有两个网卡的机器，为操作员提供一种通过 Nebula 网络进入隔离环境的方式，中继机器作为桥梁。

实验环境

对于这个 POC，我们有各种 EC2 实例。这些都可以使用配套仓库中的脚本进行部署，其中设置了适当的 AWS 安全组来演示 Nebula 的各种功能。

虚拟机

• lighthouse1

  – 顾名思义。为了高可用性，通常最好有两个，但作为 POC，一个也完全可以。

• opsbox1

  – 一个简单的 Ubuntu 服务器，作为攻击者机器，你可以从这里投递其他后渗透插件，或作为进入 Nebula 网络的入口点。

• relayvm

  – 这个作为 Nebula 中继，代表网络边界上的一个被入侵设备——它在公共互联网和目标环境之间架起桥梁。

• isolated1

  和 isolated2– 这些虚拟机没有互联网访问权限，也无法直接访问。它们之间也无法相互通信。

• secret1

  – 这个主机不由 Nebula 管理（在这个场景中，它没有被直接入侵），但以 nginx 默认页面的形式托管我们的 $target_webapp。这个虚拟机除了从 isolated1之外无法从任何地方访问。

通过 Claude 大叔的神奇能力和提供的 Terraform 源码，我们能够如下文所示可视化基础设施。

网络弹性植入体的设计考量

执行防护栏

Shellcode 和加载器已经根据各种环境特定变量进行了密钥绑定，加密密钥可能存储在外部。这一点指的是确保网络只能在特定 CIDR 范围内建立通信。这有助于防御沙箱环境中进行的任何分析，因为在网络层极不可能匹配，或者当用户将其笔记本电脑（或类似设备）带入超出范围的环境时。如果红队获得额外访问权限时，新允许的子网能够自动或手动分发到所有（或部分）植入体，那将是极好的。

代理列表

组织过去常常限制 VPN 协议的出口流量，并强制所有流量通过 L7 防火墙或其他类似设备。自从 COVID 以来，这种情况变得不那么常见了，尤其是随着 TLS VPN 技术的普及。然而，Web 流量仍然可能通过某个设备出口，或通过 ZScaler 或类似服务。重要的是，网络流量、端口和协议要尽可能接近”真实情况”，允许流量通过常见端口或类似方式出口。由于组织强制要求返回办公室，但仍然使用他们在 COVID 期间建立的 BYOD/云基础设施，这种情况被允许的可能性大大增加。无论哪个植入体作为最终出口点（为 N 个内部跳板植入体服务），它都应该能够尝试各种 C2 地址、协议，以及一系列硬编码的代理地址。如果这个最终出口选项列表能够以类似 Nighthawk 植入体配置的方式远程更新而无需生成新的 shellcode，那就更好了。

下一跳

乍一看，让每个植入体拥有一份动态更新的行动中所有植入体的完整列表（或某种像 Lighthouse 这样维护全局感知的代理）可能更快更简单。然而，在逆向工程或其他沙箱分析过程中，这可能导致防御者获得环境中所有植入体的列表，这将导致你很快被遏制和清除。加密和其他恶意软件编写技术可以提供帮助，但最终功能很可能会被揭示。

一个替代方案是每个植入体只知道在环境中出口所需的下一跳，而不是完整列表。这引入了其自身的复杂性，需要验证下一跳是否仍然活跃和正常运行，并在发现其不可用或不可路由时提供备选方案。

路由优先级

操作员应该能够根据使用场景（每周一次签到与 SOCKS 代理）配置和更改植入体发送心跳的路由。这可能包括根据延迟、来源国、稳定性、容量或”融入度”来更改路由。时间对通信频率和抖动的影响等因素也是需要设计进去并能够即时配置的。

为了能够向操作员展示这些信息以便他们做出决策，也隐含地需要收集和分析大量与植入体无关的遥测数据。

凭证材料/认证

Nebula 按主机使用证书，这是加入网状网络的认证方式。显然，这些材料的机密性至关重要。在设计植入体 PKI 基础设施时，行动特定的根密钥应离线存储，使用签发密钥为每个植入体或被入侵主机生成认证。

对于 Nebula，这意味着要为植入体通信建立新的网络路由，你需要将植入体和证书推送到文件系统并适当隐藏。实验环境中使用 systemd-creds对此进行了简单演示，但它肯定还不能用于生产。在研究过程中，我从未听说过 systemd-creds，它在基于主机的加密密钥方面似乎与 DPAPI 大致相似。解密加入网状网络或签署 C2 消息所需的证书应该只能在正确的上下文中进行——主机名、用户上下文或时间限制。

同样重要的是，能够在植入体超出范围或正在被防御者调试时将其从网状网络中切断。这可以与额外的植入体设计决策相结合，例如当看到某些进程（windbg、wireshark、ghidra 等）在主机上运行时不运行，或者如果主机看起来像一个性能不足的虚拟机（沙箱）。

终止一个无响应植入体的方法是将其配置为在 X 时间段内没有网络连接时干净退出。通过将其从网状网络中切断，它将没有网络连接，然后按要求干净退出。不过，在考虑正确的时间段时应该考虑到服务器会因维护而离线、用户会因假期而合上笔记本电脑等情况。

Nebula 可以吊销机器的证书，然后分发给所有其他节点，”丢失”的节点将被阻止重新加入。在我们的 POC 环境中，能够恢复和理解 Nebula 证书的防御者将能够看到寻址方案、可访问的网段、时间和网络流量指纹。

权限级别

并非每个植入体都以 root 后门运行。Nebula 有一定的灵活性，可以在低权限级别（tun.disabled: true）下运行，但某些功能不可用。这可以在实验 2 中看到，其中 DMZ Lighthouse 是低权限的。没有 tun接口的主机可以充当中继或 Lighthouse，但不能在网状网络内发送流量。

网状网络应该能够作为中继/下一跳和”路由表分发点”在多平台植入体之间运行，无论权限级别如何。一个简单的用例是：跳板服务器上的低权限植入体可能需要作为出口路由（返回到端点上的另一个低权限用户 shell），为隔离的 Tier 0 服务器上的 SYSTEM 植入体服务。

低权限网状植入体的功能可能较少，但充当中继的能力是必不可少的——没有提升的权限，这将发生在应用层而不是纯网络层。

隐藏网络连接

本实验中的所有 POC 概念都使用正常的网络栈并创建新接口（如适用）。然而在现实中，我们希望对 netstat和其他工具隐藏新接口和活动连接。实现这一点肯定超出了本文的范围，但当你在植入体网状网络中实现自己的网络栈时，你可能已经能够想出办法了！

分阶段加载

如果我们希望在目标服务器上植入植入体而不仅仅是对其进行网络访问，就需要将植入体 shellcode 暂存在跳板植入体上，由在新目标服务器上运行的 Stage 0 或加载器检索。这是因为植入体在那时可能还没有完全了解更广泛的网状网络（这将在首次签到时推送到植入体，以防止将所有信息硬编码进去并在执行时暴露给分析）。需要一个小型桩来以类似于 LiquidSnake（shellcode 从命名管道检索完整植入体）或其他工具的方式将其托管在跳板服务器上。例如，RastaMouse 在原始 CRTO 教学大纲中轻微涉及了这个话题，在被入侵的出口 beacon 上使用 rportfwds，允许隔离的 beacon 在回连到 egresshost.domain.local:8080时检索暂存的 shellcode。

时间戳与路由信息

大多数 C2（尽管有几个商业 C2 不这样做…）会记录操作员从 UI 发送命令的时间戳、C2 服务器接收命令的时间、植入体接收命令的时间以及任务完成和响应发送回来的时间。这依赖于网络通信和互联网会”正常工作”的普遍假设；根本不收集基于网络的计时遥测数据。

有了网状网络，我们需要关注另一层网络遥测，尤其是当我们有多条出飞地的路由，需要知道哪些路由可行哪些不可行时。这对于端点跨越互联网连接/企业网络和气隙/IoT 网络的网络通信也是相关的。

重要的是要汇总网状网络整体的上线/下线状态、节点的签到时间（在我们的 Nebula 示例中在 Lighthouse 上）、气隙机器命令放入队列的时间戳，以及它们被分发到气隙网络的时间，例如当系统管理员在环境之间移动其笔记本电脑时。此外，我们需要收集（以机器可读格式）流量所走的网络路径以及它可能走的路由。这使我们能够提前识别备用路由，以便在主路由失败时配置其他植入体（或自动故障转移）。

让我们深入几个用例，以便了解网络弹性植入体的不同部署选项以及存在的任何权衡。

用例如下：

• 实验 1 – 外部托管的 Lighthouse – 控制服务器托管在 $cloud_provider的攻击者基础设施上。
• 实验 2 – Lighthouse 托管在 DMZ 上，模拟被入侵的 Web 服务器或 VPN 设备。
• 实验 3 – 演示一个简单的存储和推送机制如何工作，用于排队任务，允许主机在连接到气隙网络时离开网状网络，执行任务（或者更可能在这种场景中，从另一个植入体检索 C2 输出），然后重新加入网状网络并分发输出。

每个实验都有一些绝对不是 Claude 生成的 Terraform、Ansible 和一个测试脚本，用于展示 Nebula 正在进行路由，其中有一些预期失败的测试和一些预期通过的测试。

实验 1 – 外部托管的 Lighthouse

在这个实验中，Lighthouse（控制服务器）托管在攻击者基础设施上，权限级别为 root。一个 opsbox 作为攻击者虚拟机，可以利用 Nebula 访问其他节点。在这种构造中，Lighthouse 没有 TUN 接口，因此无法参与流量传输，它只是充当代理。由于这台机器在我们的示例中包含根证书，它对敌对目标基础设施不可用是一件好事。这将所有”关键材料”保留在攻击者手中，尽管它有一些缺点，可以在本节后面看到，特别是与 relayVM的流量中继相关。

然而，此设置使用 static_host_map，因此没有动态主机发现。这种模型使得在植入体部署时添加新主机变得繁琐，因为需要在整个集群中更新。以安全方式做到这一点的工程工作量可能相当大，而且会导致很多”为什么我无法访问特定目标”的问题。网状拓扑的目的是

注意：在下图中，TCP/22允许入站到所有子网，只是为了让 Ansible 能够轻松运行和进行故障排除，避免 SSH -J等的复杂性和麻烦。

• lighthouse1: 10.50.10.5
• opsbox1: 10.50.10.6
• relay: 10.50.10.10
• isolated1: 10.50.10.20
• isolated2: 10.50.10.21
• secret1: 192.168.100.30（通过 isolated1 的 unsafe_routes）

此设置的唯一问题（更多是 Nebula 的限制）是 relayVM（作为 isolated1和 isolated2的跳转点）需要一个 socat管道将 UDP Nebula 流量隧道回外部 Lighthouse，因为它们位于私有、不可路由的子网中，无法绑定到低端口。relayVM不以 root 运行，代表一台你拥有用户级访问权限（如笔记本电脑或跳板服务器）但没有 SYSTEM或 root的被入侵机器。

编辑：如果所有证书都预先部署在所有主机上，看起来可能可以移除 socat 要求——这将允许你新入侵的主机在网状网络内通信，而无需首先与 Lighthouse 建立直接握手通信。这使得我们的 POC 和场景更加”现实”。

这之所以可能，是因为 Lighthouse 提供以下功能：

• 动态对等发现
• 物理地址解析
• NAT 打洞

然而，如果证书都预先部署在所有主机上，它们已经包含 Nebula IP、组成员资格和 ACL、可路由子网和 CA 链。中继将在对等方连接时了解对等方地址。我在实验中确认了这一点，但中继功能不起作用——所以如果你不想要任何外部 Lighthouse 功能，你可以在 static_host_map中硬编码所有地址，只要主机之间可以相互访问，它就会工作。

回到实验 1….

查看实验 1 的 Terraform，我们可以看到有 AWS 安全组强制执行 isolated1虚拟机和 relayVM之间的隔离。

# Secret1 安全组 - 仅接受来自 isolated1 ENI 的 HTTP
resource "aws_security_group" "secret" {
  name        = "${local.name_prefix}-sg-secret"
  description = "Secret1 - HTTP only from isolated1 ENI"
  vpc_id      = aws_vpc.main.id

  # 仅来自 isolated1 secret-subnet ENI 的 HTTP
  ingress {
    description = "HTTP from isolated1 ENI"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["10.0.3.10/32"]  # isolated1 的 ENI IP
  }

如果查看部署和配置所有虚拟机的 Ansible，你会看到 secret1没有安装 Nebula，因此不是网状网络的一部分。它实际上在一个 192.168.x.xIP 地址上。你可以使用 Nebula 的 unsafe_routes参数允许机器从 Nebula 出口到非托管或未被入侵的子网。

在这种情况下，我们可以看到 opsbox1能够 ping 通 isolated1和 isolated2，以及访问 secret1的 TCP/80，因为流量从 isolated1 出口网状网络并到达 secret1上的目标 Web 服务器。

实验 2 – 目标 DMZ 上的 Lighthouse

这种部署模型将 Lighthouse 功能推送到目标基础设施中的一台被入侵机器上，带来了所有静态凭证材料的缺点。静态密钥的加密和混淆变得更加关键。要使这种部署模型工作，需要更高级的网状或植入体拓扑来隐藏这些认证材料。然而，它确实减少了需要出口环境的心跳流量，可能适合更长期的行动。

主要优势（尽管并非直接与 Lighthouse 的物理位置相关，只是为了展示两种选项——static_host_map与自动发现）是我们不需要提前管理哪些主机可以加入网状网络。想象一下，如果在大型植入体网络中每个植入体都需要生成和推送配置，那将是多么令人头疼。使用这种模型，你仍然需要生成证书并将其分发到新入侵的主机，但与手动管理配置相比，这只是 5% 的工作量。

流量流向如下图所示，relayVM同时充当 Lighthouse 和中继（因此不需要 socat）。

实验 3 – 气隙网络笔记本电脑

这个场景代表一个用户在不知情被入侵后，将其笔记本电脑在离线环境和企业环境之间移动。

目的是展示出口植入体能够向被入侵机器传递命令的重要性，然后这些命令被部署到离线或 IoT 环境中的其他目标。这可能涉及暂存一些利用工具包、shellcode 或仅仅是一个端口扫描模块。被入侵笔记本电脑上的植入体在连接到离线子网时进行端口扫描，缓存响应，然后当目标再次拥有正常连接时，他的笔记本电脑重新加入弹性网状网络并将输出返回给操作员。

在这种情况下，实验中有一个 iptables规则会切断返回网状网络的主连接，允许笔记本电脑向离线机器推送”C2″（通过 SSH 到气隙机器并检索一个简单文件来模拟），然后在 iptables规则被删除后重新建立网状网络连接。

流程如下：

这种连接模型对于任何将处理间歇性或零星网络连接的植入体网状网络来说都是相当重要的。引入的一个复杂性是企业网络和气隙网络可能使用非常不同的 IP 寻址子网，这使得植入体使用自己的下一跳知识方案并且不受被入侵笔记本电脑侧从 10.x.x.x 到 192.168.x.x 变化的影响变得至关重要。

可以在实验 3 的输出中看到这个机制：

1. 已连接

   ：验证 opsbox 可以通过 Nebula ping 通 mobile-node

2. 排队

   ：将命令写入 /c2/pending/mission-001.cmd

3. 断开连接

   （模拟移动到另一个子网）：iptables -A OUTPUT -p udp --dport 8443 -j DROP

4. 执行

   ：Mobile-node SSH 到 airgap-target，运行 /secret/gather-intel.sh，保存到 /c2/results/（模拟从植入体接收任务输出）

5. 重新连接

   ：移除 iptables 规则（重新连接到企业 LAN），重启 Nebula

6. 检索

   ：Opsbox 获取包含密码（Alpha、Bravo、Charlie）的结果

结论

随着某些红队转向更长期的、几乎是”托管服务”风格的红队或持续保障，弹性和网状网络的想法变得更具吸引力。虽然商业部门不会入侵第三方服务器来充当代理或重定向器（希望如此），但这里讨论的许多概念与网络内持久化相关。

这也为防御者开辟了全新的检测面，因为检测内部 RPC（顶级植入体可能不使用 SMB 进行通信）或 VPN（Nebula）流量可能要困难得多，直到工具跟上为止。

也许我们可以为网状弹性植入体通信提出一种标准方式，一种行业标准，同时仍然允许灵活性和定制——类似于 BOFs/BOFPEs 或 Async BOFs 能够在各种植入体中使用。

参考文献

• 主要来源
• CISA Advisory AA23-129A – “Hunting Russian Intelligence ‘Snake’ Malware”（2023 年 5 月）— https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-129a
• Slack Nebula Documentation – https://nebula.defined.net/docs/
• Nebula GitHub Repository – https://github.com/slackhq/nebula
• systemd Credentials Documentation – https://systemd.io/CREDENTIALS/
• 俄罗斯行动
• G-Data – “Uroburos: Highly complex espionage software with Russian roots”（2014 年 2 月）
• BAE Systems – “The Snake Campaign”（2014）
• Kaspersky GReAT – “The Epic Turla Operation”（2014 年 8 月）— https://securelist.com/the-epic-turla-operation/65545/
• CIRCL.LU – “TR-25 Analysis – Turla / Pfinet / Snake / Uroburos”
• 西方归因
• Kaspersky GReAT – “Regin: nation-state ownage of GSM networks”（2014 年 11 月）— https://securelist.com/regin-nation-state-ownage-of-gsm-networks/67741/
• Pangu Lab – “Bvp47: A Top-tier Backdoor of US NSA Equation Group”（2022 年 2 月）
• Microsoft Security Blog – “Analyzing Solorigate: The compromised DLL file that started a sophisticated cyberattack”（2020 年 12 月）
• Mandiant – “Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims”（2020 年 12 月）
• 中国行动
• FireEye/Mandiant – “APT41: A Dual Espionage and Cyber Crime Operation”（2019 年 8 月）
• PwC/BAE Systems – “Operation Cloud Hopper”（2017 年 4 月）
• ESET WeLiveSecurity – “PlushDaemon compromises network devices for adversary-in-the-middle attacks”（2025 年 1 月）
• IoT/路由器目标
• Cisco Talos – “VPNFilter: New Router Malware with Destructive Capabilities”（2018 年 5 月）— https://blog.talosintelligence.com/vpnfilter/
• 红队工具参考
• Nettitude Labs（Doug McLeod）：”Operational Security with PoshC2 Framework” — 域密钥和 sec.log 分析

---

Ideas for Meshed and Resilient Implant Communications

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

---

查看原文：《网状弹性植入体通信架构设计探索》