黑客在C2服务器设置中的错误使得通过JA4H指纹分析找到他们成为可能，这大大简化了其他相关威胁的检测。

了解 JA4H

2024 年 11 月 26 日，Jon Altaus发布了一条推文，分享了 JA4H 指纹：po11cn050000_bb52516416a2_eb49a3237520_*。

在JA4+指纹家族中，JA4H技术负责识别发出请求的HTTP客户端。它分析每个 HTTP 请求的请求方法、标头、cookie、它们的值以及其他变量，创建人类和机器可读的指纹。

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

• JA4H_a 描述了主要方面：HTTP 方法、协议版本、cookie 的存在、Referrer 标头和标头数量。
• JA4H_b 是标头按出现顺序截断的 SHA256 值，不包括 Cookie 和 Referrer。
• JA4H_c 创建 cookie 字段的指纹，该指纹对于一个站点或应用程序来说是相同的。
• JA4H_d 涵盖了 cookie 字段及其值，使其成为最细粒度的部分。

这种结构使得 JA4H 指纹在威胁检测和狩猎方面具有动态性。指纹的特异性从a部分增加到d部分，而a部分中的重要查询工件仍然可读，从而使指纹灵活且易于修改。

此分析表明，了解指纹形成的原理，您可以尝试自定义检测规则。例如，您可以搜索具有不同标头数量的类似请求 (po11cn0000_eb49a3237520) 或未安装 cookie 的请求 (po11nn050000_bb52516416a2_)。

JA4H 指纹的最后三个部分（_b、_c 和 _d）更难以复制，因为它们不是人类可读的。与任何加密哈希一样，它们不能简单地修改或通配符来包含或排除元素。

要从 Althaus 指纹（bb52516416a2 和 eb49a3237520）重现 JA4H_b 和 JA4H_c，您需要知道恶意软件使用哪些标头。在这种情况下，由于软件通过 HTTP 与其 C2 通信，因此不需要逆向工程。

根据这些数据，可以确认该恶意软件设置了 5 个标头：Host、User-Agent、Content-Length、Upgrade-Insecure-Requests 和 Accept-Encoding。这与 JA4H 指纹的第一部分相匹配：po11cn050000。

使用以下 CyberChef 脚本，您可以重现 JA4H_b：

使用 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 脚本

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

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

如果我们怀疑病毒可能使用不同的标头或标头顺序，我们还可以使用 CyberChef 脚本传递其他恶意软件签名。我们对恶意软件及其在线行为了解得越多，我们就能更好地调整 JA4H 的指纹，以进行更强大、更精细的检测。

在本例中，黑客使用了流行的开源C2框架Sliver。此类开源框架提供了独特的发现功能——我们不需要样本，也不需要成为经验丰富的逆向工程师。尽管许多此类框架提供开箱即用的混淆功能，但攻击者通常不会更改默认配置。例如，Sliver HTTP 管理服务器默认使用以下响应标头：

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

值得注意的是，这段代码中的Cache-Control值 与Arctic Fox分析的样本中包含的值相同。这个巧合本身就是一个发现的机会。

检测额外的 C2 服务器

Rjvgfybz Webscout 使用一套全面的来源来收集元数据，以大规模丰富 IP 地址并使其上下文化，其中之一是 JA4+ 指纹集。 在对收集的 JA4H 指纹的各种变体进行分类时，专家们在 Arctic Wolf 报告的同一活动集群中发现了几名受害者和其他 C2。

使用 JA4H 指纹的扩展变体，我们能够识别与所描述的活动相关的几个更活跃的 C2 服务器：

IP地址：172.232.195[.] 234、194.182.164 [.]149 这两个地址都是明显的 Sliver 控制服务器，因为

1. 他们打开TCP端口31337；

2. SSL证书颁发者值：CN=operators；

3. SSL证书主体值：CN=multiplayer。

JA4H 指纹 po11cn050000_bb52516416a2_e1eae9e373ba_913d7ea84b88和po11cn050000_bb52516416a2_a9f2370d1a00_3e59a4bec10d

假设植入程序默认只设置一个 cookie，如 JA4H_b 播放示例所示。然后，快速搜索 cookie 名称会发现两个以前未观察到的新 JA4H_c 指纹。

cookies = [] #  常见的 cookie 名称长列表： 
    hash = hashlib.sha256(cookie.encode()).hexdigest()[:12] # JA4H_c 
    if hash == "e1eae9e373ba" or hash == "a9f2370d1a00": 
        print(f"{hash}:{cookie}") 
> e1eae9e373ba:refreshToken 
> a9f2370d1a00:csrf-state

两个指纹都是 Sliver HTTP 服务器配置中默认使用的 cookie 名称池的一部分，如在此处的 源代码中所示。

使用单个 JA4H 识别多个其他恶意服务器且对底层恶意软件了解最少的能力突出了 JA4+ 套件的一个关键优势：它能够使用细微的更改、cookie、标头和其他 HTTP 请求工件来检测恶意指纹邻居。

为什么会发生这种情况？ 攻击者继续使用标准 C2 服务器配置，使他们容易受到检测。恶意软件开发人员竭尽全力隐藏他们的工具，但操作员未配置这些设置的错误提供了暴露它们的机会。例如，Sliver 可以通过随机化 TLS 密码套件来动态更改其 JARM 指纹。

随机化密码的示例代码：

// 随机化密码套件

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 忽略密码顺序。这种随机顺序允许您选择一组随机密码。

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]

然而，如果操作员不使用反检测功能，那么反检测功能就毫无用处。从隐蔽性和可检测性的角度来看，安全系统的强度取决于其最薄弱的环节——在本例中，即攻击者本人。

另一个重要的一点是许多恶意框架中继续使用未加密的流量。为什么攻击者会这样做？由于大多数组织仅捕获 NetFlow 数据，这些数据包含有关 IP 地址、端口、会话长度和传输数据量的高级信息，但很少包含第 7 层（OSI 应用层）详细信息，导致检测方法毫无用处。

在组织开始分析数据包内容之前，未加密的恶意流量将继续未被检测到。由于缺乏数据包级可见性，攻击者可以利用开放的通信通道，而几乎没有或根本没有被检测的风险，从而获得不公平的优势。

结论

JA4H 指纹的使用已被证明可以有效地检测和分析恶意活动，特别是在利用 Palo Alto Networks 防火墙漏洞的情况下。对 John Altaus (po11cn050000_bb52516416a2_eb49a3237520_*) 提供的指纹进行分析和理解，识别出其他控制服务器并确认了 Arctic Wolf 所描述的活动。