剖析 JA4H 以改进 Sliver C2 检测

背景

2024 年 11 月 18 日，Palo Alto Networks 宣布在其防火墙设备的操作系统中发现两个严重漏洞 CVE-2024-0012 和 CVE-2024-9474。第二天，watchTowr 发布了一份报告，详细说明了如何将这些漏洞串联起来以实现远程代码执行。 

watchTowr 报告发布后不久，Arctic Wolf Labs 检测到一系列针对 Palo Alto Networks 设备的入侵。他们的发现于 11 月 22 日发表在一篇题为“ Arctic Wolf 观察到针对 Palo Alto Networks 防火墙设备的威胁活动”的博客文章中。 

昨天，FoxIO的John Althouse报告称，Arctic Wolf 报告的几个 IoC 可以用以下 JA4H 指纹代替：po11cn050000_bb52516416a2_eb49a3237520_*。基于此指纹，我们能够确认 Arctic Wolf 报告的活动的几个受害者，从而支持其有效性和JA4+ 套件的强度。 

这篇博文剖析了 John Althouse 提供的指纹，并展示了 Arctic Wolf 描述的活动集群中观察到的另外两个 JA4H 指纹。它还得出结论，更通用的指纹po11cn050000_bb52516416a2_*可以以可接受的误报率发现相同的活动。

了解 JA4H

2024 年 11 月 26 日，John Althouse 在推文中分享了价值为 的 JA4H 指纹po11cn050000_bb52516416a2_eb49a3237520_*：

图 1，参考https://twitter.com/4A4133/status/1861482744334725435

在 JA4+ 指纹系列中，JA4H 负责对 HTTP 进行指纹识别 - 特别是发送请求的客户端。它会检查每个 HTTP 请求中的请求方法、标头名称、cookie、cookie 值和其他变量，以创建人机均可读取的指纹。

JA4H由a、b、c、d四部分组成： 

• JA4H_a专注于高级内容，例如 HTTP 方法、HTTP 版本、是否存在 cookie、是否有 referrer 标头以及标头的数量。 

• JAH4_b更具体地关注请求中观察到的标头，不包括 Cookie 和 Referrer。它是按标头出现的顺序截断的 SHa256 值。 

• JA4H_c是 cookie 字段的指纹，对于每个访问的网站都会有所不同，但对于该网站或应用程序来说是相同的。 

• JA4H_d是最复杂的，因为它包含 cookie 字段及其值。

从检测和威胁搜寻的角度来看，这种结构使 JA4H 指纹具有高度动态性。随着从部分 _a 移动到 _d，它会变得越来越具体，再加上重要的请求工件在部分 _a 中是人性化的，这使得它灵活且易于动态修改。 

下面是图 1 中 JA4H 的细分：

本文的分析表明，只要读取指纹并了解指纹的生成方式，我们就可以了解很多有关底层请求的信息，并开始尝试自定义检测。例如，我们可以查找具有不同标头数量的类似请求 ( po11cn*0000_*_eb49a3237520_*)，也可以查找未设置任何 Cookie 的类似请求 ( po11nn050000_bb52516416a2_*)。 

JA4H 指纹的最后三个部分 JA4H _b、_c 和 _d 更难复制，因为它们不是人类可读的。与所有其他加密哈希一样，我们不能只修改某些值或使用通配符来包含或排除我们选择的元素。

为了重现 Althouse 和 共享的指纹中的 JA4H_b 和 JA4H_c 部分，bb52516416a2我们eb49a3237520必须知道恶意软件设置了哪些标头。在这种情况下，恶意软件通过 HTTP 到达其 C2，因此我们无需在逆向工程方面做任何艰苦的工作来发现标头： 

图 3：Arctic Wolf 报告的植入程序捕获的请求（A3092BFA4199DEF7FC525465895EE3784C6FCF55F0A7E9C8436C027E0F41CB4B）

上图显示了恶意软件发送的请求（红色）和它从 C2 服务器收到的响应（蓝色）。由此，我们可以确认恶意软件确实设置了 5 个标头（不包括 Cookies 和 Referer）：Host、User-Agent、Content-Length、Upgrade-Insecure-Requests和Accept-Encoding，如 JA4H 哈希的第一部分所示，po11cn050000。使用此 CyberChef 配方，我们现在可以重现 JA4H_b：

图 3：使用 CyberChef 复现 JA4H_b（https://gchq.github.io/CyberChef /）

Find_/_Replace({'option':'Regex','string':'(Cookie\\:.+|Referer\\:.+)\\r\\n'},'',true,false,true,true)

Find_/_Replace({'option':'Regex','string':'(POST|PUT|GET|HEAD).+\\r\\n'},'',true,false,true,false)

Find_/_Replace({'option':'Regex','string':'\\:.+'},'',true,false,true,false)

Find_/_Replace({'option':'Regex','string':'\\r?\\n'},',',true,false,true,false)

SHA2('256',64,160)

Regular_expression('User defined','^.{0,12}',true,true,false,false,false,false,'List matches')

CyberChef Recipe 预先制作指纹

我们还可以重现 JA4H_c，它只是恶意软件设置的唯一 cookie 的截断的 SHA256 “SSID”，：

import hashlib
hashlib.sha256("SSID".encode()).hexdigest()[:12]
# eb49a3237520

serverHeaders := []*clientpb.HTTPC2Header{
  {
    Method: "GET",
    Name: "Cache-Control",
    Value: "no-store, no-cache, must-revalidate",
    Probability: 100,
  },
}

注意到之前图 3 中的这段代码片段有什么熟悉的地方了吗？这些是Cache-Control我们从 Arctic Fox 分析的样本中观察到的确切标头值。这本身就是一个检测机会。 

转向发现更多 C2

Webscout 利用一套全面的来源来收集我们用来大规模丰富和情境化 IP 地址的元数据，其中之一就是 JA4+ 指纹套件（https://blog.webscout.io/introducing-ja4-support-in-webscout-elevating-threat-detection-with-advanced-network-fingerprinting/）。 

我们决定在我们新实施的收集中尝试 JA4H 指纹的不同变体，最终在 Arctic Wolf 报告的同一活动集群中发现了几个受害者和其他 C2。 

通过扩展通配符以丢弃最初报告的指纹中的 JA4H_c 部分，我们发现了另外两个活跃的 C2，它们的时间与 WatchTowr 演示如何将两个 Palo Alto CVE 链接在一起以实现 RCE 的时间大致相同： 

172.232.195[.]234
194.182.164[.]149

以下两者都明显是 Sliver C2：

• 它们暴露了 TCP 端口 31337

• SSL 证书颁发者值为CN=operators

• SSL 证书主题值为CN=multiplayer

我们观察到与这些 C2 相关的以下两个 JA4H 哈希： 

po11cn050000_bb52516416a2_e1eae9e373ba_913d7ea84b88
po11cn050000_bb52516416a2_a9f2370d1a00_3e59a4bec10d

cookies = [] # long ahh list of common cookie names
for cookie in cookies:
    hash = hashlib.sha256(cookie.encode()).hexdigest()[:12] # JA4H_c
    if hash == "e1eae9e373ba" or hash == "a9f2370d1a00":
        print(f"{hash}:{cookie}")
> e1eae9e373ba:refreshToken
> a9f2370d1a00:csrf-state

这两者都位于 Slivers 默认 HTTP C2 配置使用的 cookie 名称池中，可以从此处的源代码中看到。

能够从单个 JA4H 开始并在对底层恶意软件知之甚少的情况下识别出其他几个恶意服务器，这凸显了 JA4+ 套件的一个主要优势：它能够通过细微的变化、cookie、标头和其他 HTTP 请求工件检测恶意的“指纹邻居”。

反思

攻击者仍然使用默认的 C2 配置，这让他们很容易被发现。恶意软件开发人员不遗余力地掩盖他们的框架，但粗心的攻击者却没有自定义这些设置，从而为攻击者提供了检测的机会。例如，本文研究的恶意软件 Sliver 可以通过随机化 TLS 密码套件来主动操纵其 JARM 指纹：

// Randomize the cipher suites
allCipherSuites := []uint16{
  tls.TLS_RSA_WITH_RC4_128_SHA, //uint16 = 0x0005 1
  tls.TLS_RSA_WITH_3DES_EDE_CBC_SHA, //uint16 = 0x000a 2
  tls.TLS_RSA_WITH_AES_128_CBC_SHA, //uint16 = 0x002f 3
  tls.TLS_RSA_WITH_AES_256_CBC_SHA, //uint16 = 0x0035 4
  tls.TLS_RSA_WITH_AES_128_CBC_SHA256, //uint16 = 0x003c 5
  tls.TLS_RSA_WITH_AES_128_GCM_SHA256, //uint16 = 0x009c 6
  tls.TLS_RSA_WITH_AES_256_GCM_SHA384, //uint16 = 0x009d 7
  tls.TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, //uint16 = 0xc007 8
  tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, //uint16 = 0xc009 9
  tls.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, //uint16 = 0xc00a 10
  tls.TLS_ECDHE_RSA_WITH_RC4_128_SHA, //uint16 = 0xc011 11
  tls.TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, //uint16 = 0xc012 12
  tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, //uint16 = 0xc013 13
  tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, //uint16 = 0xc014 14
  tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, //uint16 = 0xc023 15
  tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, //uint16 = 0xc027 16
  tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, //uint16 = 0xc02f 17
  tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, //uint16 = 0xc02b 18
  tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, //uint16 = 0xc030 19
  tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, //uint16 = 0xc02c 20
  tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, //uint16 = 0xcca8 21
  tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, //uint16 = 0xcca9 22
}
// CipherSuites ignores the order of the ciphers, this random shuffle
// is truncated resulting in a random selection from all ciphers
insecureRand.Shuffle(len(allCipherSuites), func(i, j int) {
  allCipherSuites[i], allCipherSuites[j] = allCipherSuites[j], allCipherSuites[i]
})
nCiphers := insecureRand.Intn(len(allCipherSuites)-8) + 8
tlsConfig.CipherSuites = allCipherSuites[:nCiphers]

然而，如果操作员不利用这些反检测功能，它们就毫无价值。就可检测性和隐身性而言，链条的强度取决于其最薄弱的环节——在本例中，就是对手。

检测工程是一场猫捉老鼠的游戏。过去如此，将来也如此。诸如 JA4+ 套件之类的方法通过直观的理解和操作，为蓝队提供了高度的灵活性，可以制作出强大的签名，从而将权力交还给蓝队。对手及其工具越先进，将单个薄弱的枢轴点串联成强大的组合指纹就越重要。这正是 JA4+ 套件的优势所在。

另一点需要注意的是恶意软件框架中继续使用未加密的流量。威胁行为者如何逃脱惩罚？因为大多数组织只记录 NetFlow 数据。NetFlow 数据包含有关 IP 地址、端口、会话长度和字节大小的高级信息，但很少包含任何第 7 层流量详细信息。这使得 JA4+ 套件等检测技术变得毫无用处。只要组织不检查数据包的实际内容，未加密的恶意流量就会继续不被察觉地溜走。这种数据包级可见性的缺乏使攻击者能够以最小的检测风险利用明文通信渠道，从而获得他们本不应拥有的优势。

结论

事实证明，使用 JA4H 指纹是一种检测和分析恶意活动的有效方法，尤其是在最近利用 Palo Alto Networks 防火墙漏洞的情况下。通过分析和理解 John Althouse 分享的指纹，po11cn050000_bb52516416a2_eb49a3237520_*我们能够发现其他命令和控制服务器并验证 Arctic Wolf 报告的威胁活动。

JA4+ 套件使研究人员和分析师能够根据已知指标发现相关恶意活动。本文演示了如何根据已知恶意软件行为对现有指纹进行细微更改，从而找到恶意 JA4H“指纹邻居”。

IoC

Sliver C2 IP： 

172.232.195[.]234
194.182.164[.]149

JA4H指纹

po11cn050000_bb52516416a2_e1eae9e373ba_913d7ea84b88
po11cn050000_bb52516416a2_a9f2370d1a00_3e59a4bec10d

参考

• https://labs.watchtowr.com/pots-and-pans-aka-an-sslvpn-palo-alto-pan-os-cve-2024-0012-and-cve-2024-9474/

• https://arcticwolf.com/resources/blog/arctic-wolf-observes-threat-campaign-targeting-palo-alto-networks-firewall-devices/

• https://x.com/4A4133/status/1861482744334725435