Why JA4 t13d1011h2 Is Not Sliver C2

TL;DR

The JA4 fingerprint t13d1011h2_61a7ad8aa9b6_3fcd1a44f3e3 is labelled "Sliver Agent" in FoxIO's ja4db. But it's actually Go's default crypto/tls ClientHello — produced by every Go application that doesn't customize TLS settings: ClaudeBot, GPTBot, Kubernetes controllers, Prometheus, Terraform, AND Sliver. JA4H (HTTP fingerprint) is required to distinguish Sliver from legitimate Go traffic.

The Problem

Project Lanterna runs three honeypot domains designed to attract AI agent traffic. Within the first hour of operation, our pcap-to-JA4 extraction pipeline flagged multiple connections matching a signature labelled "Sliver Agent" in FoxIO's ja4db.

Alert: Sliver C2 Agent Detected?

t13d1011h2_61a7ad8aa9b6_3fcd1a44f3e3

ja4db label: "Sliver Agent" — a known command-and-control implant used in red team operations and by threat actors.

This looked alarming. Sliver is an open-source adversary emulation framework — finding it beaconing to our honeypots would be a significant security event.

But something didn't add up. When we correlated the JA4 fingerprint against our access logs by source IP, the connections came from:

Source	User-Agent	JA4
Anthropic	ClaudeBot/1.0	`t13d1011h2_61a7ad8aa9b6_3fcd1a44f3e3`
OpenAI	GPTBot/1.3	`t13d1011h2_61a7ad8aa9b6_3fcd1a44f3e3`
Various	Go-http-client/2.0	`t13d1011h2_61a7ad8aa9b6_3fcd1a44f3e3`

ClaudeBot and GPTBot are not Sliver implants. They're legitimate AI web crawlers built in Go. The same JA4 fingerprint matched because they all use Go's default TLS stack.

Root Cause: Go's Default `crypto/tls`

Go's standard library crypto/tls produces a predictable TLS ClientHello when no custom configuration is provided. This is the default for every Go HTTP client:

// This is all it takes to produce the "Sliver" JA4:
package main

import "net/http"

func main() {
    // Default Go HTTP client — no TLS customization
    resp, _ := http.Get("https://example.com")
    // This produces JA4: t13d1011h2_61a7ad8aa9b6_3fcd1a44f3e3
    // ... which ja4db labels "Sliver Agent"
}
        

The resulting ClientHello has:

TLS 1.3 with 1.2 fallback
10 cipher suites in Go's default order
11 extensions including ALPN (h2)
Standard SNI, supported versions, key share, signature algorithms

This combination hashes to t13d1011h2_61a7ad8aa9b6_3fcd1a44f3e3 — and it's identical whether the application is ClaudeBot, GPTBot, Sliver, Prometheus, Terraform, Kubernetes, or a weekend hobby project written in Go.

Who Shares This Fingerprint

Any Go application using the default HTTP client. This includes:

Application	Category	Threat Level
ClaudeBot (Anthropic)	AI Crawler	Benign
GPTBot (OpenAI)	AI Crawler	Benign
Go-http-client (generic)	HTTP Library	Context-dependent
Prometheus	Monitoring	Benign
Terraform	Infrastructure	Benign
Kubernetes controllers	Orchestration	Benign
Consul, Vault, Nomad	HashiCorp tools	Benign
Sliver C2 implant	Red team / C2	Malicious
Any custom Go service	Varies	Varies

Go is one of the most popular languages for cloud infrastructure. Labelling its default TLS fingerprint as "Sliver" creates an enormous false positive surface.

How to Actually Detect Sliver

Webscout published research in 2024 demonstrating that JA4H (the HTTP fingerprint) is the discriminator, not JA4 (the TLS fingerprint).

Real Sliver Detection Requires JA4H

Sliver's HTTP C2 profile produces a distinctive JA4H fingerprint:

po11cn050000_bb52516416a2_*

This captures Sliver's specific HTTP header ordering, cookie behaviour, and content negotiation — which are unique to the Sliver implant and NOT shared with legitimate Go applications.

The detection chain should be:

JA4: t13d1011h2_61a7ad8aa9b6_3fcd1a44f3e3
↓
Is this Go default TLS? YES (shared by hundreds of Go apps)
↓
Check JA4H: po11cn050000_bb52516416a2_*
↓
Match? → Sliver C2 confirmed
No match? → Legitimate Go traffic (ClaudeBot, GPTBot, Terraform, etc.)

John Althouse, the creator of JA4+, has acknowledged this collision. The broader JA4 community recognises that single-layer TLS fingerprinting has limitations when a language's standard library dominates the fingerprint.

Impact on SOC Teams

Any organisation using JA4-based detection rules (Suricata, Zeek, Arkime, etc.) and referencing ja4db will generate false alerts on this fingerprint. The blast radius is significant:

AI crawlers: ClaudeBot and GPTBot are now hitting most public websites. Any SOC monitoring outbound JA4 will see this fingerprint frequently
Internal Go services: Microservices, monitoring agents, CI/CD pipelines — all produce this JA4 when making outbound HTTPS calls
Cloud infrastructure: Terraform plans, Kubernetes API calls, Vault token renewals — all trigger the "Sliver" label
Alert fatigue: If every Go HTTP call triggers a Sliver alert, analysts will tune out the rule entirely — missing real Sliver traffic when it does appear

Recommendations

For ja4db

Relabel t13d1011h2_61a7ad8aa9b6_3fcd1a44f3e3 from "Sliver Agent" to "Go default crypto/tls (includes Sliver C2)"
Add a note that JA4H correlation is required for Sliver confirmation
Consider adding the JA4H fingerprint po11cn050000_bb52516416a2_* as the authoritative Sliver indicator

For Detection Engineers

Do not alert on JA4 t13d1011h2_61a7ad8aa9b6_3fcd1a44f3e3 alone
Do correlate JA4 + JA4H for Sliver detection
Do use this JA4 as a "Go application" classifier, then discriminate by HTTP-layer behaviour
Consider user-agent validation: ClaudeBot, GPTBot, Prometheus, Terraform all self-identify correctly

For the Broader Community

This finding applies to any language with a dominant default TLS configuration — Python's urllib3, Node's https, and Java's default SSLContext will have similar collision issues
JA4 is powerful for fingerprinting but should always be combined with JA4H (HTTP), JA4S (server), or JA4X (certificate) for threat attribution
Single-layer fingerprinting creates false confidence. Multi-layer correlation is essential.

Evidence from Project Lanterna

Our honeypot captured this fingerprint from 3 distinct application categories across dozens of source IPs over a 31-hour capture window:

Application	Source IPs	HTTP Version	Requests	Behaviour
ClaudeBot	Multiple (Anthropic ASN)	HTTP/2	robots.txt → pages	Polite crawler, respects robots.txt
GPTBot	Multiple (OpenAI ASN)	HTTP/2	robots.txt → pages	Polite crawler, respects robots.txt
Go-http-client	Various	HTTP/1.1, HTTP/2	Mixed paths	Generic Go applications, varied behaviour

None exhibited C2 beacon patterns (periodic callbacks, jitter timing, staged payloads). All were consistent with web crawling or API consumption.

References

FoxIO JA4+ — github.com/FoxIO-LLC/ja4
FoxIO ja4db — ja4db.com
Webscout — JA4H analysis of Sliver C2 HTTP profiles (2024)
John Althouse — JA4+ Technical Specification
BishopFox Sliver — github.com/BishopFox/sliver
Go crypto/tls source — pkg.go.dev/crypto/tls

About Project Lanterna

Project Lanterna operates honeypot infrastructure to detect, fingerprint, and catalogue TLS signatures from AI agents and autonomous software. We maintain the largest open database of AI agent JA4 fingerprints. Named for the Lanterna di Genova — the ancient lighthouse at the port of Genoa.

Domains: counteragent.io · gptplugins.io · projectlanterna.com

Why JA4 Fingerprint t13d1011h2 Is Not Sliver C2