挖掘隧道 - 猎捕对抗性 Cloudflared 实例

《挖掘隧道 - 猎捕对抗性Cloudflared实例》这篇文章发布于2025年5月28日，主要讲了一个网络安全隐患：一些黑客（比如勒索软件团伙）利用Cloudflare的合法工具Cloudflared偷偷潜入网络，躲过安全检测，长期控制受害者的系统。

Cloudflared本来是用来安全连接远程设备的，但黑客用它建秘密通道，还会把程序伪装成正常名字，比如“svchost.exe”，来掩人耳目。文章教大家如何揪出这些坏家伙：通过解码Cloudflared的令牌、检查程序名字是不是被给我们提供了实用方法，比如看看它是不是被可疑地多人使用。

作者还分享了具体查询方法，帮大家快速找到可疑活动，同时提醒要小心别把正常情况误判成威胁。总之，这是一篇超实用的指南，教你怎么发现和应对网络安全威胁！

1. 攻击者如何滥用Cloudflared？

文章指出，勒索软件团伙（如BlackSuit、Royal、Akira等）利用Cloudflared来进行恶意活动。他们的典型操作流程是：

• 初始访问：通过VPN漏洞、远程桌面协议（RDP）或其他方式入侵目标网络。

• 部署Cloudflared：在被入侵的设备上安装恶意的Cloudflared实例，创建一个隧道。

• 持久访问：通过这个隧道，攻击者可以像在本地网络一样操作，绕过传统的网络防御机制。

• 横向移动：利用这个“桥头堡”在网络中进一步扩散，窃取数据或部署勒索软件。

例如，攻击者可能会将Cloudflared重命名为一些看似无害的程序（如svchost.exe或LogMeInUpdater.exe），以逃避检测。

2. Cloudflared的工作原理（技术细节）

Cloudflared通过令牌（token）来建立和管理隧道。这些令牌是一个Base64编码的JSON字符串，包含以下关键字段：

• account_id（账户ID）：标识创建隧道的Cloudflared账户。

• tunnel_id（隧道ID）：标识特定的隧道。

• secret（密钥）：用于验证客户端身份。

攻击者通常不会频繁更换account_id，这就成了一个可以追踪的“指纹”。通过解码这些令牌并分析account_id，防御者可以发现恶意的Cloudflared实例。

3. 检测方法

文章提出了几种检测Cloudflared滥用的方法，主要集中在以下几个方面：

• 重命名检测：攻击者常将Cloudflared重命名为其他程序名（如svchost.exe或AdobeUpdater.exe）。通过识别这些重命名的实例，可以发现潜在的威胁。

• 共享账户ID检测：一个account_id通常只应在一个组织内使用。如果发现同一个account_id跨越多个不相关的组织（例如多个MSP，管理服务提供商），这可能是一个异常信号。

• 令牌解码：通过解码Cloudflared的令牌，提取account_id，并将其与已知的恶意account_id列表对比，可以提前发现威胁。

4. 使用ES|QL进行查询

文章还提供了一些使用ES|QL（Elastic Search Query Language）来检测和分析Cloudflared滥用的具体查询方法：

• 提取令牌组件：从进程的命令行中提取Cloudflared的令牌，解码Base64，解析JSON，得到account_id、tunnel_id和secret。

• 检测共享账户ID：统计某个account_id关联的不同组织数量。如果一个account_id出现在多个组织中，可能表明存在异常。

• 调查异常账户ID：一旦发现可疑的account_id，可以用它进一步查询相关日志，获取更详细的信息。

5. 分析中的注意事项（避免误判）

尽管这些检测方法很强大，但也可能产生误判。文章提到了一些需要注意的情况：

• SaaS Cloudflared实例：一些合法的软件供应商（例如制药行业的软件）可能会在产品中嵌入Cloudflared，这种情况可能满足检测条件，但不一定是恶意的。

• 合法重命名：有些组织可能会故意重命名Cloudflared，或者安装过程中会自动重命名（如cloudflared-windows-amd64.exe）。

• 组织变更：如果一个组织更换了MSP，旧的Cloudflared隧道可能仍然存在，导致看起来像是异常。

什么是 Cloudflared？

为了更全面地理解 Cloudflared，我们首先必须讨论隧道技术。隧道技术是一种允许两台（或多台）主机通过互联网（通常通过不受信任的网络）相互通信的技术。隧道技术本身是虚拟专用网络 (VPN) 常用的一种技术。

这是通过将数据封装在只有隧道能够理解或保持解密能力的附加协议中来实现的。因此，隧道技术提供了一种在远程端点之间创建可信网络的安全方法。

隧道技术还可用于部署测试和生产 Web 应用程序，而不存在外部暴露的风险；应用程序可以通过隧道转发到外部服务器/服务，其中外部服务器充当代理，接受并将流量转发到 Web 应用程序。

Cloudflared 就是这样一款应用。Cloudflared（原名“Argo”）已在实际应用中取得了广泛成功，已部署在众多生产系统中，系统管理员可以利用其功能远程访问主机、部署 Web 应用程序并与管理员工具进行交互，而无需将其暴露在广阔的互联网中。

图 1.Cloudflared 管理面板

对抗活动

长期以来，攻击者和勒索软件从业者一直利用可信隧道、VPN 和远程访问软件来获取并维持受感染环境中的访问权限。Cloudflared 再次展现出一个令人担忧的趋势：可信网络软件被滥用于此目的。

Bushido 的勒索软件工具矩阵维护着一份由各种勒索软件团体及其关联组织使用的攻击工具列表。该列表显示，BlackSuit、Royal、Akira、Scattered Spider 和 Medusa 均使用 Cloudflared 隧道作为持续访问和入侵的一种形式。

此外，之前的调查表明，Hunters International 已经使用了上述 Cloudflared 隧道，尽管有关该组织的入侵指标和更广泛的情报有限。

对手将通过各种方式（VPN 入侵、RDP 等）获得对环境的初始访问权限，并将恶意 Cloudflared 实例掺杂到环境或关键基础设施中。

图 2. Cloudflared 滥用生命周期

有了这些 Cloudflared 隧道，对手基本上就可以访问本地网络，并可以利用这些机器作为滩头阵地在整个网络中横向移动。

令牌解码

Cloudflared 隧道需要连接参数。这些连接参数可以通过配置文件提供，或者更常见的是通过命令行参数提供。此命令行参数显示为tunnel run --token <cloudflared_tunnel>。

图 3.Cloudflared 隧道运行命令行。

Cloudflared 隧道令牌是 Base64 编码的 JSON 数据，包含：

{"a":"account_id","t":"tunnel_id","s":"secret"}

该account_id参数对于生成 Cloudflared 令牌的帐户是唯一的 - 具体来说是正在使用的 Cloudflared 帐户。

该tunnel_id参数用于标识正在生成的唯一隧道。该参数在每个隧道上应该是唯一的。

图 4.Cloudflared 隧道 ID

该secret参数就是客户端可以安全地向 Cloudflared 基础设施/隧道证明身份的秘密。

我们感兴趣的是account_id参数，它a是Cloudflared令牌中的参数。攻击者要么没有意识到这是一个可追踪的参数，要么根本就不关心——因为这些勒索软件组织轮换account_id的频率相当低。

这本身就是一个很好的妥协指标——通过解码 Cloudflared 令牌并根据已知恶意语料库对其进行检查account_id，我们能够预先检测到对抗性 Cloudflared 实例的安装。

指标网络

但这并不是我们检测 Cloudflared 滥用的唯一启发式方法——事实上，它构成了一个检测特征网络，我们可以应用它来根除这些恶意隧道。

恶意重命名

默认情况下，Cloudflared 会将服务安装为cloudflared.exe。一个潜在的危害指标可能是将 Cloudflared 重命名为另一个潜在的良性应用程序。

事实上，这是正确的——对手倾向于坚持类似的命名约定：

Medusa

• svchost.exe

• servicehost.exe

BlackSuit

• WGUpdater.exe

• LogMeInUpdater.exe

• AdobeUpdater.exe

• MozillaUpdater.exe

• IntuitUpdater.exe

通过检测这些重命名的 Cloudflared 令牌实例，我们立即获得了可操作的攻击指标。然后，我们可以解码 Base64 编码的 Cloudflared 令牌，并利用此指标在遥测数据中搜寻更多 Cloudflared 令牌account_id。

共享帐户 ID

此外，我们可能还会检查安装异常。Cloudflared 特性对于每个帐户都是唯一的。这意味着，除非这些特性account_id来自同一个人，否则它们绝不应在两个不同的组织之间共享。这或许是有道理的——如果我生成了 10 个 Cloudflared 隧道令牌，它们都应该表明它们是从我的帐户创建的。

虽然许多托管服务提供商 (MSP) 会从同一帐户生成 Cloudflared 令牌，但 MSP 与与其组织无关的系统进行交互的情况并不常见。例如，虽然一个 MSP 下的三个组织可能维护相同的帐户 ID，但该帐户为不同的 MSP创建隧道的情况并不常见。这正是我们下一个检测特征的关键：Cloudflared account_id应该只跨越一个 MSP。

总结一下我们如何围绕此遥测进行检测和调查：

• 检查并提取以前入侵的危害指标。

• 分析 Cloudflared 安装的历史数据并构建“已知不良”Cloudflared 帐户 ID 语料库。

• 识别 Cloudflared 已重命名的实例。

• 将恶意实例反向传播到现有的遥测中，以发现更多危害。

• 识别在不同系统之间共享 Cloudflared 令牌的实例。

• 浮出水面并分析这些实例是否存在恶意/意外访问。

妥协查询

使用 ES|QL，我们可以生成一个查询，尝试解码并“解决”这个问题。首先，让我们生成一个查询，以可用的方式提供这些字段。我们将使用包含 token 的几个列以及a t和s 参数来方便查询。

提取令牌组件

from logs| WHERE process.command_line LIKE "*tunnel run*" AND process.command_line LIKE "*--token*" -- Identify commandline arguments that may indicate Cloudflared usage. We avoid using the executable name here, as it can be renamed.| DISSECT process.command_line "%{cfPath} --token %{cf.token.array}" -- Destructure our commandlineargumentto extract our token parameter.| EVAL FROM_BASE64(cf.token.array) -- Convert this string from Base64 into JSON.| RENAME `FROM_BASE64(cf.token.array)` AS cf.token.array -- Helper functiontoincreaseclarity, renameourcolumn.| DISSECT cf.token.array "{"a":"%{cf.token.a}","t":"%{cf.token.t}","s":"%{cf.token.s}"}" -- Use DISECT to parse the JSON and produce our columns.| keep @timestamp, host.name, account.name, cf.token.a, cf.token.t, cf.token.s -- Keep fields of interest.

此 ES|QL 查询应向我们的数据集引入四个新列。这些字段将是cf.token.array、cf.token.a t和s值。

检测共享帐户 ID

现在，我们可以简单地利用这些字段来搜索已知的入侵指标。例如，如果我们知道 Akira 使用某个帐户 ID，我们只需在 中搜索该 ID 即可cf.token.a。然而，我们失去了发现新入侵或未知隧道的细微差别。这时，我们可以引入聚合和分组功能，以帮助简化这一过程。

现在，ES|QL 在聚合信息的能力方面有点有限，所以我们需要采取一种相当复杂的方法来解决这个问题。

FROM logs| WHERE process.command_line LIKE "*tunnel run*" AND process.command_line LIKE "*--token*"| DISSECT process.command_line "%{cfPath} --token %{cf.token.array}"| WHERE cf.token.array IS NOT NULL AND LENGTH(cf.token.array) == 184 -- Ensure no nulls are included and the payload isas expected-- which isa184 character long string. | EVAL FROM_BASE64(cf.token.array) | RENAME `FROM_BASE64(cf.token.array)` AS cf.token.array | DISSECT cf.token.array "{"a":"%{cf.token.a}","t":"%{cf.token.t}","s":"%{cf.token.s}"}"| WHERE cf.token.a IS NOT NULL AND cf.token.t IS NOT NULL AND cf.token.s IS NOT NULL -- Once again, ensure no nulls are being passed down for aggregation.| KEEP @timestamp, host.name, account.name, cf.token.a, cf.token.t, cf.token.s | STATS unique_accounts = count_distinct(account.name) by cf.token.a -- Count the number of distinct account names associated with a given Cloudflared account.| WHERE unique_accounts > 1 -- Surface any instances where a Cloudflared account ID is used across more than one organization.| SORT unique_accounts DESC -- Sort this numerically descending. With a large enough corpus of data, adversaries whom have abused the same Cloudflared account will install it on multiple different environments.

这将返回一个实例表，其中cf.token.a(Cloudflare account_id) 与多个帐户名关联——在本例中是 MSP 帐户。您可以随意调整参数以适应您的环境。

调查异常账户ID

然后，我们可以将这些“异常的 Cloudflared account_id”应用到我们的初始搜索中。

from logs| WHERE process.command_line LIKE "*tunnel run*" AND process.command_line LIKE "*--token*"| DISSECT process.command_line "%{cfPath} --token %{cf.token.array}"| EVAL FROM_BASE64(cf.token.array)| RENAME `FROM_BASE64(cf.token.array)` AS cf.token.array | DISSECT cf.token.array "{"a":"%{cf.token.a}","t":"%{cf.token.t}","s":"%{cf.token.s}"}"| WHERE cf.token.a == "<ANOMALOUS ACCOUNT ID>"| KEEP @timestamp, host.name, account.name, cf.token.a, cf.token.t, cf.token.s

这将产生更细粒度的遥测数据，并且可以随意保存字段以满足调查需要。

分析陷阱

SaaS Cloudflared 实例

值得注意的是，在超过 300 万台主机的语料库上进行操作时，出现了一些有趣的模式，这些模式本身并不表明存在入侵，尽管它们满足了我们上面指定的标准。例如，在对这些 Cloudflared 隧道进行分析时，我们注意到一家制药软件供应商将 Cloudflared 隧道作为其软件产品的一部分进行分发。撇开安全问题不谈，account_id只要该 Cloudflared 隧道属于制药行业的组织，其本身并没有什么特别异常。

良性重命名

此外，重命名的 Cloudflared 隧道可能是该组织故意添加的，也可能是安装过程中的某个操作。例如，cloudflared-windows-amd64.exe可能会出现，但除非伴随上述迹象，否则本身并不代表异常。

此外，带有.rbf扩展名（由 Windows 安装程序创建的回滚文件）的安装程序可能会执行，并包含 Cloudflared 执行的其他指标。这些安装程序应作为标准cloudflared.exe安装程序进行检查。

配置文件

配置文件本身也可能被传递给 Cloudflared，如果没有对这些配置文件的任意读取权限，我们就无法描绘与该隧道关联的 Cloudflared 基础设施/帐户。这可能会给无法收集这些文件的调查带来一些小麻烦。然而，一旦描绘出与配置文件相关的恶意行为，就可以利用其中包含的信息进行进一步的追踪。

最后，分析中值得注意的是，一家 MSP 可以在某个组织内签约并安装遥测技术，随后由另一家 MSP 收购该组织。通常，Cloudflared 隧道在服务提供商转换后可能会长期存在，这可能会导致一些异常行为。

最佳安全做法是移除这些实例，但如果您也坚持按 MSP 帐户构建查询和调查，它们会在遥测中显示为异常。在我的日常工作中，这通常表现为一家组织从其 MSP 切换到一家也使用我们 EDR 的事件响应公司。因此，该主机将出现在 Cloudflared 的“两个帐户”下 account_id，但这本身是良性的。（尽管 Cloudflared 实例本身可能是恶意的。）

概括

Cloudflared 虽然是一款合法的安全隧道和远程访问工具，但却被勒索软件联盟广泛利用，以便在受感染的环境中保持持久性。BlackSuit、Akira、Royal、Scattered Spider、Medusa 等组织都曾使用 Cloudflared 隧道来混淆访问并规避传统的检测机制。

通过解码 Cloudflared 令牌（包含 account_id、tunnel_id 和 secret 的 Base64 编码 JSON 字符串），防御者可以提取有价值的攻击指标。特别是，account_id 字段在不同安装中提供了一致的指纹，并且很少被攻击者轮换用于检测和关联。

本文讨论的检测策略包括：

识别 Cloudflared 的重命名实例（例如 svchost.exe、LogMeInUpdater.exe），

解码并跟踪不同组织之间共享或重复使用的 account_id，

利用 ES|QL 查询来发现异常令牌使用情况并揭示隐藏的持久性机制。

虽然这些技术功能强大，但必须谨慎考虑可能模仿恶意模式的极端情况，例如合法的 MSP 行为、软件供应商捆绑 Cloudflared 或组织架构变更。如果谨慎且大规模地应用这些方法，可以显著增强威胁搜寻工作，并在对抗性 Cloudflared 隧道进一步实施之前将其发现。