Microsoft Dev Tunnels 前置 C2、持久化及更多

Microsoft Dev Tunnels Tunnelling C2 and More

攻击者总是在寻找方法融入环境，以便在不被发现的情况下建立 C2 通道。利用合法工具进行恶意活动是他们常用的方法。

从防御者的角度来看，发现那些试图融入环境的活动可能相当具有挑战性。一个经历警报疲劳的 SOC 团队，可能会经常求助于在 VirusTotal 上检查域名或哈希值。如果是已知的域名或哈希值，特别是由微软签名或信任的，他们可能会迅速将其标记为误报并继续前进。

目录

• Microsoft Dev Tunnels
• 场景一：用于 C2
• 创建隧道
• 建立 C2
• 示例事件
• 检测 Dev Tunnel C2
• 网络与端点遥测
• 用于持久访问
• Github 设备认证
• 建立隧道
• 检测
• Dev Tunnel 二进制执行检测
• 隧道 RDP 检测
• 事件响应分类与日志记录
• 结束语
• IOCs
• 文件哈希
• 域名

Dev Tunnels 允许开发人员将本地运行的服务暴露给远程主机，通过微软基础设施在互联网上进行隧道传输。例如，假设我在我的 PC 上运行一个简单的网络服务器，我希望同事能够测试我创建的网页。我可以使用 Dev Tunnel 来暴露我主机上的 443 端口。一个 Microsoft Dev Tunnel 域名会生成 *.devtunnels.ms，我将 URL 提供给我的同事，他们可以通过微软 URL 访问我本地主机上的网络服务。

我可以通过 Dev Tunnels 暴露任何服务，包括 RDP 和 SSH。由于可以使用微软域名进行隧道传输，你可以想象为什么这对攻击者来说是一个有吸引力的概念。

有越来越多的报告显示威胁行为者在其活动中利用 Microsoft Dev Tunnels 和其他合法的远程工具。因此，让我们来看看攻击者如何滥用 Dev Tunnels 的不同方式。

场景一：用于 C2

首先，使用 Dev Tunnels 进行 C2。以下图为例。受害者的 PC 执行了一个有效负载，C2 信标被配置为连接到一个 Microsoft Dev Tunnels 域名。

在大多数环境中，由于该域名属于微软，域名将通过任何代理或防火墙。然后，微软将流量转发到攻击者的机器。

创建隧道

同时，从攻击者的角度来看，他们所需要做的只是安装 dev tunnel 二进制文件，该文件可在 Mac、Linux 和 Windows 上使用。

以下是建立隧道的一些关键细节：

• 认证：要创建隧道，你需要使用个人 GitHub 或 Microsoft 账户进行认证。显然，设置一个账户是很简单的。
• 匿名访问：你可以配置隧道以允许匿名访问，允许任何人连接到你的隧道。
• 隧道 ID：创建隧道后，会生成一个隧道 ID，用于通过隧道连接两个端点。

下面突出显示的 URL 是我们将用于 C2 信标的。

建立 C2

利用 Dev Tunnel 域名进行 C2 流量的过程在不同的 C2 框架中大致相同。以下是 Cobalt Strike 中创建监听器的示例。

1. 选择信标类型，通常是 HTTPS。
2. 定义 HTTPS 主机以进行监听，在这种情况下，它将是我们的隧道域名，8kl69l904-443.uks1.devtunnels.ms
3. 定义 HTTPS 主机（stager），即你的团队服务器的 IP。
4. 选择 HTTPS 端口，443。

示例事件

在下面显示的事件中，我们可以看到来自我们的信标进程的隧道域名连接。信标进程是一个伪造的 OneDrive 二进制文件，具有伪造的微软证书。

我们给我们的有效负载一个伪造的证书，它是签名的，但不被信任。

检测 Dev Tunnel C2

检测使用 Dev Tunnels 进行 C2 是具有挑战性的，因为目标主机上不需要存在 Dev Tunnels 二进制文件。在 EDR 或端点控制未能检测到初始有效负载的情况下，基于网络的遥测检测将是具有挑战性的。正如预期的那样，TLS 连接具有有效的证书，因为它们毕竟是合法的微软域名。

我们可以通过寻找持续时间内对 Dev Tunnel 域名的持续连接来识别 C2 流量。C2 流量

下面是用于在 TimeLion 中生成上述内容的查询：

.es(
  index='.ds-logs-network_traffic*',
  q='destination.domain: *.uks1.devtunnels.ms',
  timefield='@timestamp',
  metric='count'
).bars(),
.es(
  index='.ds-logs-network_traffic*',
  q='destination.domain: *.uks1.devtunnels.ms',
  timefield='@timestamp',
  metric='cardinality:destination.domain'
).lines(width=2, stack=false).label("Unique Domains")

我们还可以使用更通用的 C2 检测方法，寻找单个域名的高流量连接。下图显示了 24 小时内单个域名的连接次数。我们可以清楚地看到 Dev Tunnel C2 域名的异常情况，其中持续不断的连接被建立。

带有端点遥测的网络

许多 EDR 产品现在能够将域名请求与负责发出请求的进程关联起来。您通常还可以使用证书信息丰富二进制文件，寻找来自未签名或不受信任证书的 Dev Tunnel 域名连接也可以是一种检测方法。

dns.question.name : *.uks1.devtunnels.ms and process.code_signature.trusted<br>: false

然而，这对于从受信任来源运行的有效负载并没有帮助。例如，将有效负载侧载或注入到像 Outlook 这样的受信任进程中将更难检测。

如下所示，将二次有效负载加载到 Outlook 中，显示了从受信任的微软进程到受信任的微软域名的 C2 连接。

在这些情况下，需要对 Dev Tunnel 域名进行异常 C2 检测。分析师需要关注周围和上下文活动，例如寻找请求进程中的异常加载或注入。

用于持久访问

Dev Tunnels 不仅仅可以用于 C2。正如我们之前所说，任何端口都可以暴露用于远程使用。因此，RDP 和 SSH 是很好的候选者，允许威胁行为者建立持久的远程访问。

理想情况下，我们希望有一种脚本化的方法，通过 Dev Tunnels 建立和维护远程访问。

我创建了一个简单的 PowerShell 脚本，在受害者主机上执行以下操作。

• 下载 Dev Tunnels 的副本并将其放置在 Windows 启动位置。
• 下载地址：https://aka.ms/TunnelsCliDownload/win-x64
• 放置位置：C:UserspaulAppDataRoamingMicrosoftWindowsStart MenuProgramsStartup
• 将 Dev Tunnel 进程认证到一个账户。
• 详细信息在下文中。
• 设置一个隧道，暴露端口 3389 以允许匿名访问。

Github 设备认证

首次在设备上使用 Dev Tunnels 时，必须进行认证。为了以脚本化方式实现这一点，我们可以使用 GitHub 设备认证：

devtunnel user login -g -d“使用 GitHub 账户进行设备代码登录，如果无法进行本地交互式浏览器登录”

运行此命令时，设备登录代码会写入终端。使用我们的 PowerShell 脚本，我们可以通过将其写入 .txt 文件来捕获此代码。然后我们可以从文件中提取字符串，并发送给自己。

我们可以使用 interactsh 接收登录代码，但通过 PowerShell 脚本向我们的 OAST 域发送 POST 请求。

然后我们可以使用设备代码通过 https://github.com/login/device 认证到我们的攻击者 GitHub 账户。

建立隧道

现在我们已经认证，我们的 PowerShell 脚本可以继续，通过设置一个隧道。

这就像运行下面这样的命令一样简单。端口 3389 被暴露并允许匿名登录。

.devtunnel.exe host -p 3389 -allow-anonymous

现在隧道已设置，我们可以从攻击者机器认证到相同的 GitHub 账户。

我们可以列出在我们账户中运行的隧道，并通过指定隧道 ID 连接到在受害者设备上暴露 RDP 的隧道。

为了通过 RDP 连接，我们需要认证到设备上的一个用户。如果我们还没有一个被攻陷的用户，我们可以通过隧道暴力破解 RDP。

流量从本地主机通过隧道转发到受害者主机的 3389 端口。因此，为了暴力破解，我们将本地主机指定为目标，并能够在受害者主机上暴力破解 RDP。

一旦我们有一个可用的账户，我们可以使用 RDP 客户端进行连接。再次指定本地主机地址作为远程主机，并使用我们攻陷的用户进行认证。

这意味着理论上你可以通过一个 PowerShell 脚本远程暴露一个主机，使其成为网络钓鱼的候选者。这可以是一种绕过网络上 RDP 限制的方法，远程暴露内部主机。

检测

我正在使用 Elastic SIEM 和 Endpoint agent 收集遥测数据并构建自定义检测。

Dev Tunnel 二进制执行检测

在攻击者将 Dev Tunnel 二进制文件带到磁盘的情况下，你可以通过一个简单的方式抓住他们：

Process.Name:devtunnel.exe OR File.Name:devtunnel.exe

但是任何一个合格的操作员都会将进程重命名为其他名称。

你可以通过 PowerShell 或 WinGet 查找初始下载

CommandLine= "*winget install Microsoft.devtunnel*"
OR
URL= "*https://aka.ms/TunnelsCliDownload/win-x64*"

但是，这些方法很容易被绕过，攻击者可能会从他们自己的基础设施中下载工具。

一种更可靠的检测方法是查找隧道操作所需的特定 DLL。查看模块加载事件时，devtunnel.exe 会加载各种 DLL，但有一个 DLL 特别容易检测，就是 devtunnel.dll。

event.action: "load" and dll.name: "devtunnel.dll"

该 DLL 从执行时创建的临时.net 目录中加载。这是一种攻击者无法操控的行为。

隧道 RDP 检测

您会注意到，此活动的日志中源 IP 显示为::1，这是主机的回环地址，或 127.0.0.1。由于我们正在从攻击者机器的本地主机转发流量到受害者机器，这就是显示的地址。

有趣的是，登录类型被捕获为类型 3，而不是类型 10。下面的查询将显示来自回环地址的成功和失败的登录。将其放入检测中可能会产生大量噪音和误报。

event.provider: "Microsoft-Windows-Security-Auditing" and event.code: 4625 or event.code : 4624 and (source.ip : "::1" or source.ip : 127.0.0.1)

相反，我们可以使用阈值检测来尝试检测来自回环地址的可疑暴力破解行为。

事件响应分级与日志记录

不幸的是，Dev Tunnels 的日志记录非常少。与 Microsoft VSCode 远程隧道 不同，后者是相同底层隧道功能的不同实现（关于它们如何被滥用的更多信息将在其他时间讨论），Dev Tunnels 没有专门的使用日志记录。

如果您正在响应涉及使用 Dev Tunnels 的事件，并且没有主机或网络遥测数据，那么最好的选择是转储 Dev Tunnel 进程。我们可以从进程转储中获取所有关键信息。

包括隧道认证使用的用户名。

结论

如所示，Dev Tunnels 提供了强大的功能，可以（并且确实）被威胁行为者滥用，使得蓝队的检测更加困难。最好的选择是在整个环境中彻底阻止隧道的使用，这可以通过阻止下列 Dev Tunnel 域名来实现。

IOC（指标）

文件哈希

域名