发生了什么事？

如果我们编写了一个定制植入物，甚至采取了预防措施来针对相同的 EDR 进行测试，那么我们可以合理地确定有效载荷已执行。关于您为什么没有收到回调的唯一解释是，出站通信必须已被阻止。你可怜的壳还活着，但它在呼救，找不到回家的路。

我们怎样才能避免这样的悲剧？

到底什么是隐身？

当涉及到网络流量时，我们可以采取的保持“隐身”的最佳方法是尝试与现有流量混入。到目前为止，HTTP（S）是信标恶意软件最流行的回调方法，原因有三个：

易于实施 — 简单、基于文本、灵活的协议，具有许多可用库
它可能是开放的出站 — 基于浏览器的工作流需要 HTTP（S）出站
现有的流量很大——我们的流量将是大海捞针

只要我们的 HTTP（S）消息的内容看起来与真实的网络流量（也称为我们的“C2 配置文件”）相似，那么我们就应该能够融入并保持“隐身”。但是，有一个问题：

“一切都是隐秘的，直到有人在寻找它。” — @tifkin_

无论您选择如何构建消息，都可能会有一些迹象在未来泄露您的特定品牌的恶意软件。如果您不编写自己的 C2 配置文件，而只使用开源配置文件，那么某些安全产品可能已经对您的恶意软件的通信风格进行了指纹识别。

除了对 C2 配置文件进行指纹识别外，网络防御者还有更多方法可以阻止大量未知的恶意流量，并让红队头疼不已：

阻止流向新域或未分类域的流量
阻止流向目标网络新网域的任何域的流量（首次访问）
仅允许流量访问开展业务所需的一小部分网站（允许列表）

绕过第一个块很容易。只需在您的域上托管一些良性内容，直到它几个月大并被分类。第二块和第三块绕过起来有点困难。让我们看一下一些选项，即使在域允许列表的情况下，这些选项可能仍然有效，并且也有些“隐蔽”。

经典：DNS

长期以来，DNS 一直是红队作为长途 C2 回调的首选。与 HTTP（S）一样，极有可能允许 DNS 流量出站。还有大量的现有流量需要融入。它只有两个注意事项：

大小限制 — 每个请求最多只能处理 253 个字符
不区分大小写 — 我们需要添加额外的字节来编码不是小写字母数字的数据

DNS 响应最多可达 512 个字节，但这仍然是一个主要限制。这意味着大多数 DNS C2 配置文件将呼叫和响应数据分解为小块，并在短时间内生成非常大量的 DNS 请求。此外，大多数 DNS C2 配置文件都设计为“高效”，并为每个请求使用所有可用字节，这与常规 DNS 查找相比，生成的请求看起来根本不正常。请记住这一点，以下是一些有关如何有效使用DNS的提示，同时保持隐蔽性：

首先，我建议只使用DNS进行签到或其他需要非常小的数据传输的通信。一般来说，尽量保持在 253 个字符的限制以下。

其次，设计需要很少输出的开发后命令。例如，一个命令可能只是检索主机名，并让您知道植入程序是否可以在该主机上加载网页。然后，另一个命令可能会指示植入物通过 HTTPS 回调到该主机。

最后，请记住，DNS缓存是一回事。确保来自植入物的每个 DNS 请求至少有一个随机或递增部分，这样您的请求就不会被缓存 DNS 服务器提前丢弃。

被忽视的：ICMP

ICMP 也经常被允许出站。即使唯一允许出站的 TCP 端口是 80 和 443，请记住 ICMP 是独立于 TCP 的自己的协议。不幸的是，每个 ICMP 数据包只能携带 32 个字节的信息，并且在隐身前线经常被忽视。如果您碰巧降落在根本不监视 ICMP 的环境中，那么大小限制应该无关紧要。

我们可以产生大量的流量，同时仍然可以在雷达下飞行。唯一的问题是，如果防御者确实设置了ICMP监控，那么标记异常请求就非常容易。这是因为正常的 ECHO 请求（PING）和 ECHO 回复消息始终具有“abcdefghijklmnopqrstuvwabcdefghi”的数据负载。为什么？我不知道。要知道，虚假消息很容易被发现，因此当用于 C2 流量时，ICMP 往往是全有或全无。

你有邮件（软件）：C2 over SMTP

我最喜欢的帮助我的植入物融入的技巧之一是使用 Microsoft 组件对象模型（COMs）来驱动合法的 Windows 二进制文件来执行我的命令;例如，创建一个隐藏的 Internet Explorer 实例，并使用它来导航到我的 C2 域，使我的 HTTPS 连接看起来像是正常的 Web 流量。

在限制通过 HTTP（S）进行出站访问的网络上，我们可以使用相同的技巧通过电子邮件（SMTP）泄露数据，而不是使用 Outlook 的 COM 接口。如果您喜欢为受感染的用户设置一些自定义电子邮件规则，您可以编写一个仅使用 SMTP 进行 C2 通信的植入物。

这种方法的一个主要优点是您根本不使用 HTTP（S）流量。无论企业网络代理如何被锁定，如果受感染的用户可以发送和接收电子邮件，那么您的植入物很可能能够打电话回家。

此外，您根本不需要将植入物植入到 Beacon.您的植入物可以坐下来等待特殊电子邮件进来，其中包含下一个指示。

这种 C2 方法的最后一个主要优点是数据是在电子邮件地址之间交换的，而不是在 C2 域之间交换的，这使得即时进行更改变得更加容易。例如，说明可能来自多个不同的电子邮件地址。可以使用电子邮件 CC 或 BCC 将输出发送到多个目标地址，以防一个电子邮件地址被阻止。如果您使用一次性地址，例如 Gmail 帐户，您甚至根本不需要购买 C2 域。

Old Dog， New Transport：基于 TLS 和 HTTPS（DoT 和 DoH）的 DNS

DNS协议不支持加密，这意味着您的所有DNS请求“都可以被网络，ISP或任何能够监控传输的人读取”。为了解决这个问题，基于 TLS 的 DNS （DoT）和基于 HTTPS 的 DNS （DoH）现在是传统 DNS 的常见替代方案。如今，大多数 Web 浏览器都使用 DoH 作为一项额外的安全功能（或实施排他性访问权限来监控您）。这意味着大多数网络将有相当数量的合法 DoH 流量供我们融入。DoT 是一个不错的选择，但需要额外的提升才能在植入物中实施。DoT 还使用端口 853 而不是传统的 53，该端口可能会在限制性网络上被阻止出站。另一方面，DoH 仅使用端口 443/TCP。它是作为 Web API 公开的 DNS。下面有几个示例：

https://dns.google/resolve?name=example.com

curl -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=example.com&type=A"

即使我们的目标网络正在使用域允许列表，“dns.google”或“cloudflare-dns.com”或两者都在列表中的几率有多大？我会说相当高。我们仍然有 DNS 大小限制需要处理，但与传统的 DNS 回调相比，我们可以获得一些主要优势。首先，我们的请求是加密的。我们可以安全地返回生成极其异常的 253 字节 DNS 查询。其次，我们的植入物不再发送原始 DNS 请求。相对而言，HTTPS看起来会更正常。最后，我们可以在不需要 DNS 库的情况下实现 DNS 回调。DNS 协议很复杂，但这些 DoH API 非常简单。

很多选择：靠受信任的网站生活

说到可能在公司允许名单上的站点，我们可能能够利用大量的“受信任站点”来在我们的植入物和我们的 C2 服务器之间代理消息。这种技术被称为“靠受信任的站点生存”，简称 LOTS。这个想法是，有些网站被企业如此普遍地使用，以至于阻止它们对大多数组织来说都是令人望而却步的。其中许多相同的站点允许用户以某种身份发布或存储数据，然后可以检索这些数据。因此，您可以利用这些站点的声誉将数据传入和传出目标网络。以下是 @mrd0x 策划的一份很棒的清单：

https://lots-project.com/

您可以使用“C&C”过滤器来查找特别适合用作 C2 消息代理的站点。您可能还会找到一些托管静态网络钓鱼站点或提供有效负载的好地方！

逆流而上：STUN 和 TURN

如果您从未听说过 NAT 会话遍历实用程序（STUN）或围绕 NAT 使用中继遍历（TURN），那么您并不孤单。没有多少红队成员需要与这些协议进行交互，甚至不需要知道它们是什么。这些协议是大多数基于 Web 的音频和视频流服务的支柱。想想 Discord、GoToMeeting、Facebook Messenger 和 Google Hangouts 等等。所有这些服务都有一个共同的挑战：我们如何连接两个（或更多）设备，以便在它们都位于防火墙后面时可以在彼此之间传输数据？这就是 STUN 和 TURN 发挥作用的地方。请注意，它们的名称中都有“遍历”和“NAT”（又名防火墙）。这些协议允许设备设置对等连接，即使它们位于防火墙后面。这有点像在防火墙上戳一个小洞，这样我们就可以与其他人有效地交谈，而其他人也在他们的防火墙上戳了一个洞。

从本质上讲，所有反向 shell 都做同样的事情。我们不能使用绑定 shell，因为有一个防火墙会阻止我们的入站连接。因此，植入物需要向出站发送请求以启动连接，然后根据 NAT 规则允许任何后续响应数据。STUN 和 TURN 只是一种更强大的穿越防火墙的方式。可能使 STUN 和 TURN 对 C2 有用的一些好处是，它们通常是允许的、基于 UDP 的并且高度复杂。所有这些因素使它们成为许多组织的潜在盲点。

像水一样流动：混合回调

我喜欢把 C2 通信想象成有点像在小学时分享笔记。一个音符可能从 A 到 B 走很多路径;也许在共同的朋友或共同的朋友之间。也许您使用商定的投递箱位置（可能是多个），或者实现自己的特殊代码。在任何情况下，只要音符（数据）从 A 到 B 然后再返回，它就无关紧要。因此，当我将这种观点应用于 C2 通信时，我更愿意将问题分解为两个问题：

如何从外部将数据导入组织？
如何将数据从组织内部发送到外部？

每个问题的答案不需要匹配。它们只需要是单独有效的答案。您可以从共享的 Google 文档接收说明，并将输出发布到私有 GitHub 存储库。您可以通过 SMTP 执行初始签入，通过 DNS 发送定期后续签入，通过 DoH 拉取指令，并通过 STUN 使用“视频源”泄露输出。您甚至可以对任何一个步骤混合使用多种方法，可以并行使用，也可以以循环方式进行。你只是受到你的创造力的限制。

警告：我实际上并不是建议你编写一个像这样的复杂系统。我只是想打破你对 C2 通道是什么的概念。一般来说，最好根据需要坚持一两种方法。

我认为至少，在植入代码中模块化这些单独的操作中的每一个并为每个操作提供至少几个选项是有用的。这样，我们就可以轻松地调整有效载荷，以更好地适应我们的目标环境。当然，不要将自己局限于标准的 HTTPS 回调。