Introduction

Most red team tooling lives and dies on TCP. Cobalt Strike beacons over HTTPS, Sliver wraps its traffic in mTLS, Havoc does much the same. The entire enterprise detection ecosystem has had years to tune against TCP-based command and control: JA3 fingerprinting, Suricata signatures, EDR callstack hooks on socket syscalls. It's a mature arms race and defenders are increasingly well-equipped.

QUIC changes the terrain entirely.

I recently built QUICLash, a Go-based orchestration framework using gRPC-style control messages over QUIC transport; primarily as a research exercise in understanding where enterprise detection stacks have blind spots. What I found during the build is worth documenting for both red and blue teams.

What Is QUIC and Why Does It Matter for Security?

QUIC is a transport protocol developed by Google and standardized by the IETF (RFC 9000). It runs over UDP and mandates TLS 1.3 there is no negotiating down. At a high level it was designed to solve latency problems in HTTP/2: head-of-line blocking, slow TCP handshakes, and poor connection migration behavior across network changes.

From a security research perspective those same properties have interesting implications:

It runs over UDP. The majority of enterprise network inspection tooling is deeply tuned for TCP stream reassembly. Deep packet inspection engines, IDS signatures, and network behavior analytics all have years of TCP-specific logic baked in. QUIC traffic traversing the same network often passes through uninspected or simply logged as "UDP noise."

TLS 1.3 is mandatory and the encryption boundary is earlier. In traditional TLS over TCP, the server certificate and several handshake fields are visible in plaintext before encryption kicks in. QUIC encrypts far more of the handshake, leaving less metadata for passive observers to work with.

0-RTT session resumption. A reconnecting QUIC client can send application data in the very first packet, no round trip required. For a beacon-style agent checking in at regular intervals, this compounds into measurable latency advantages.

Connection migration is native. QUIC connections are identified by Connection IDs, not IP:port tuples. An agent can migrate across networks without dropping and re-establishing its connection. From a network forensics standpoint, correlation across IP changes becomes harder.

QUIC fingerprinting tooling is immature. JA3/JA4 fingerprinting for TLS over TCP is well understood, widely deployed in commercial products, and has extensive signature databases. The QUIC equivalent, fingerprinting based on transport parameter values, CRYPTO frame structure, and ClientHello construction, exists in research but is not widely deployed in enterprise stacks at the time of writing.

Building QUICLash: Architecture Decisions

QUICLash is built around a few core design choices that are worth explaining in context.

Go as the Foundation

Go was the obvious choice. The quic-go library provides a mature QUIC implementation with enough low-level access to control connection behavior meaningfully. Go's static compilation model means agents are single self-contained binaries with no runtime dependencies, clean to deploy, nothing to install. The goroutine concurrency model handles many simultaneous agent connections without the complexity of manual thread management.

Crucially, Go's crypto/tls and quic-go both allow enough configuration surface to control fingerprinting behavior meaningfully: transport parameter values, ALPN strings, and connection ID generation can all be tuned.

Protobuf Control Plane

Control messages between server and agents are defined in protobuf and exchanged over QUIC streams. This gives the framework a typed, versioned control protocol that's efficient on the wire and easy to extend. The agent.proto definition covers registration, heartbeats, bidirectional commands (Ping, RunInfo, RunShell), and module lifecycle management.

Using gRPC-style messaging over QUIC rather than raw HTTP/2-based gRPC was a deliberate choice, it avoids the HTTP/2 framing overhead and keeps the transport layer tightly controlled.

Hot-Swappable Module System

One of the more operationally useful features is the module manager. Agents maintain a long-lived QUIC connection and can receive module sync, start, stop, and execution commands from the server without reconnecting. Modules are built as separate OS/architecture-specific binaries and pushed through the server's module management interface.

The practical implication: new capability can be deployed to connected agents without dropping connections or rebuilding agent binaries. From a detection perspective this means the initial agent binary has a minimal footprint and capability is added dynamically post-compromise.

Embedded CA at Build Time

The agent build pipeline allows embedding a CA certificate directly into the agent binary at compile time via the Agent Builds interface. This means agents can verify the server's certificate without having a CA file present on disk, no filesystem artifact, no registry write, no dropped file to detect. Certificate verification happens entirely from memory using material baked into the binary.

Data Layer

QUICLash uses a tiered data architecture:

Redis handles the hot operational layer: session state keyed on QUIC Connection IDs, task queues, and real-time operator notifications via pub/sub
PostgreSQL provides durable cold storage for agent registry and command history with async write-through from Redis
The server also supports a Redis/Postgres-free in-memory mode for lightweight or air-gapped deployments

The Redis layer is specifically well-suited to QUIC's connection model. Connection IDs are used as natural keys for agent session state, and Redis sub-millisecond reads mean the server can fulfill task lookups before QUIC 0-RTT resumption completes keeping the hot path genuinely fast.

What This Looks Like on the Wire

From a network visibility standpoint, QUICLash traffic has some characteristics worth understanding:

It looks like UDP to most inspection tools. Without QUIC-aware inspection, the traffic appears as UDP flows on port 4433 (configurable). No TCP handshake, no stream reassembly, no HTTP headers to inspect.

The ALPN string is visible during the handshake. QUICLash uses quiclash as its ALPN identifier, in a real operational deployment you would want this to mimic a legitimate protocol (h3 for HTTP/3, for instance). This is a tuning point, not a fundamental limitation.

Connection IDs rotate. QUIC Connection IDs are not fixed they can be rotated during a session, complicating correlation across packet captures.

Heartbeat timing is configurable. Beacon interval is adjustable from the operator console, allowing jitter to be introduced to avoid periodic traffic signatures.

The Detection Opportunity

This section is deliberately included because the purpose of building QUICLash was research, and research has to be honest about what defenders can do.

Network layer:

Anomalous UDP flows on non-standard ports to external IPs are detectable most enterprise environments have very little legitimate long-lived UDP traffic outside of DNS and DTLS for video conferencing
QUIC to unknown external IPs on non-443 ports should be high-confidence alert material
Even QUIC on port 443 to destinations not associated with known CDN or cloud provider IP ranges warrants investigation
Network flow analysis can identify long-lived UDP sessions with consistent inter-packet timing, beacon jitter helps but doesn't eliminate this signal

Endpoint layer:

The agent process making outbound UDP connections is visible to EDR
Module execution spawns child processes, this is the highest-fidelity detection point regardless of transport. While this can be adjusted to run modules in memory to make detections harder, the act of a process reserving executable memory is often scrutinized by EDR deployments
Binary execution from unusual paths, unsigned binaries, and parent-child process anomalies all remain valid regardless of how the C2 channel is tunneled

TLS Metadata:

QUIC handshakes still expose some metadata, the server certificate (if using a self-signed cert with no cover story) is a strong indicator
Certificate transparency logs will contain your server cert if you use a publicly signed certificate, operational infrastructure should account for this

The honest summary: QUIC buys meaningful evasion at the network inspection layer in environments without QUIC-aware DPI. It does not meaningfully change the endpoint detection story. A well-instrumented EDR stack will catch this on behavior regardless of transport.

Implications for Blue Teams

If your network security monitoring strategy is entirely dependent on TCP stream inspection and HTTP/S proxy visibility, you have a gap. Specifically:

Audit your DPI and NGFW capabilities for QUIC inspection support, most vendors have added it but it's often not enabled by default
Consider DNS-based detection: agents need to resolve C2 infrastructure. Long-lived UDP sessions to IPs with no prior DNS resolution are anomalous.
QUIC can be blocked at the perimeter in environments where it isn't required, this forces attackers back to TCP/TLS where your existing tooling is mature
Review whether your EDR platform logs UDP socket activity and outbound connections from non-browser processes using QUIC

Where This Sits in the Threat Landscape

To be direct: purpose-built QUIC-based C2 is not a commodity threat. The realistic threat population for most organizations is using cracked Cobalt Strike, commodity RATs, and freely available frameworks; all of which are heavily signatured.

The value of research like QUICLash isn't to suggest organizations face this threat imminently. It's to identify where the detection gap exists before threat actors close the gap themselves. The broader trend of encrypted protocol abuse and legitimate protocol blending is well documented; DNS over HTTPS C2, cloud storage as dead drops, ICMP tunneling. QUIC is the natural next step in that progression and the detection ecosystem is currently behind.

Building ahead of the threat is what separates detection engineering from detection archaeology.

Conclusion

QUICLash started as a question: how much does transport choice matter in a post-TCP-inspection world? The answer is: more than most enterprise networks are currently prepared for, and less than a complete solution requires.

The transport layer evasion is real and the detection tooling gap is real. The endpoint behavior story hasn't changed. The most effective defensive posture is depth; network controls that account for UDP-based protocols, endpoint instrumentation that doesn't depend on transport visibility, and certificate/DNS telemetry that provides coverage regardless of what protocol the payload rides on.

The code is intentionally documented as a research baseline.

If you're running a blue team and want to test your QUIC visibility, this is the kind of exercise worth running. If you find nothing fires, that's the finding.

As for the QUIClash project. I still have some additions I want to make before releasing it into the wild. When it finally released you can expect another blogpost about all of the features.

Helpful References

QUIC Protocol Fundamentals
RFC 9000 — https://www.rfc-editor.org/rfc/rfc9000
RFC 9001 — https://www.rfc-editor.org/rfc/rfc9001
Cloudflare's QUIC explainer — https://blog.cloudflare.com/the-road-to-quic/
Fingerprinting Research
quic-go project — https://github.com/quic-go/quic-go
uTLS project — https://github.com/refraction-networking/utls
Salesforce JA3 original writeup — https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/
Threat Intel / Detection Gap Context
Deepwatch Intel Brief — https://www.deepwatch.com/labs/cyber-intel-brief-september-21-27-2023/
Defensive / Blue Team
Zeek QUIC analyzer — https://github.com/corelight/zeek-quic
SANS reading room on QUIC Firewall Evasion— https://www.sans.org/white-papers/quictun-quic-firewall-evasion

QUICLash is a research framework built for authorized red team and detection engineering use. All testing described was performed in controlled lab environments.

Down with the QUICkness: QUIC, C2, and the Detection Gap Nobody’s Talking About

Introduction

What Is QUIC and Why Does It Matter for Security?