Every encrypted session starts with a handshake, and every handshake starts with an introduction. Before a VPN tunnel, a WebRTC video call, or a voice-over-IP stream gets to hide its contents behind encryption, the two sides briefly show each other identification — a certificate. That exchange happens in the clear. It has to. And it turns out that a piece of identification can say a great deal about who is holding it, long before anyone tries to read what they are actually saying to each other.
The protocol behind that handshake, in a growing number of cases, is DTLS — Datagram Transport Layer Security, the UDP-native cousin of the TLS that protects most web traffic. DTLS secures encrypted voice and video calls, WebRTC sessions, and a range of VPN and remote-access tools built on UDP rather than TCP. It was designed to bring TLS-grade security to real-time, latency-sensitive traffic that cannot tolerate TCP overhead. That is exactly why it has also become attractive to people trying to hide something. UDP traffic tends to draw less scrutiny than TCP, DTLS sessions look identical to legitimate video calls and VPN tunnels at a glance, and the payload is encrypted the moment the handshake finishes. For a defender watching only for suspicious content, DTLS traffic is a dead end. For a defender watching the handshake itself, it is a goldmine.
The Certificate That Does Not Belong
Picture a carrier security team, or a defense network operations center, watching a segment of infrastructure that carries an enormous volume of encrypted UDP sessions every day, voice calls, video conferencing, VPN traffic from remote users and connected devices. Buried in that volume is a session that, on the surface, looks unremarkable: a handshake, a negotiated cipher, a certificate exchange, and then encrypted traffic that trickles along quietly for hours.
Nothing about the payload raises an alarm, because nothing about the payload is visible. But the certificate presented during the handshake tells a different story. It was not issued by a recognized certificate authority, it was signed by whoever created it, for the sole purpose of standing in that handshake. Its validity window is strange: generated only minutes before the session began, or stamped to expire decades in the future, patterns that legitimate infrastructure essentially never produces. And when analysts check whether that same certificate has appeared anywhere else, they find it: the identical certificate, presented by dozens of other endpoints scattered across different networks and geographies, all talking to infrastructure that has no obvious business reason to exist.
None of this required decrypting a single packet, just watching what the handshake gave away for free.
The certificate itself, metadata exchanged before encryption ever begins, was enough to separate a routine encrypted session from something that looks a lot like shared, adversary-operated infrastructure reused across an entire campaign.
How The Attack Works
Building infrastructure that can pass as legitimate encrypted traffic takes real effort, and adversaries running covert operations at scale tend to cut corners in predictable ways. Standing up certificates through a recognized certificate authority means audit trails, paperwork, and cost, so covert DTLS servers are far more likely to self-sign their own certificates or issue them from an ad hoc authority that exists only to support the operation. Rather than provisioning infrastructure carefully in advance, tooling often generates a certificate automatically, on the spot, moments before it is needed — which shows up as a certificate whose issue time sits suspiciously close to the moment a session actually starts. And because standing up new certificate infrastructure for every target is expensive, the same certificate frequently gets reused across many different sessions, devices, and even unrelated campaigns, creating a thread that ties otherwise-disconnected activity back to a single actor.
Layered on top of that, the handshake itself carries a second signal: the specific way a client or server negotiates the session forms a distinctive pattern that behaves almost like a fingerprint. Legitimate applications produce a narrow, well-known set of these patterns. Purpose-built malware and custom implants tend to produce ones that are rare, or that have never been seen before, because they were not written by the same engineering teams that build commercial VPN clients and video conferencing software. Adversaries also increasingly favor DTLS specifically because it slides past inspection tuned for TCP, and because tunneling it over non-standard ports lets it hide inside the ordinary background noise of a busy network.
This kind of infrastructure-blending tradecraft — quietly hiding operational infrastructure inside protocols and traffic patterns that look identical to ordinary encrypted communications — is broadly consistent with the operational posture attributed to sophisticated state-sponsored actors like Salt Typhoon, even where no specific DTLS-based campaign has been publicly confirmed.
CA-issued
Recognized certificate authority
Stable fingerprint
Matches known application baseline
Used once
Tied to a single service
Self-signed
No recognized CA
Odd validity window
Issued minutes before use
Reused widely
Across many unrelated endpoints
Surfaced in handshake metadata
No decryption required
How The Detection Works
None of this depends on breaking DTLS encryption or performing man-in-the-middle interception. It depends entirely on watching what is visible by design: the handshake and the certificate metadata exchanged before encryption ever begins. A single session showing one odd trait, an unfamiliar fingerprint, an unusual validity window might just be a misconfiguration. The signal gets much stronger once those traits are tracked across a population of sessions over time: the same certificate turning up on far more endpoints than any legitimate service would touch, or a fingerprint that never matches the narrow set produced by known, well-behaved applications.
That kind of pattern is invisible to any tool looking at a single flow in isolation, but becomes obvious once handshake and certificate metadata is captured continuously, at scale, across an entire network. It is a reminder that as encrypted, real-time protocols become more central to how networks operate, the handshake in front of that encryption stays one of the last places a defender can watch without needing to see inside the traffic at all.
Where NetworkLens Fits
This is precisely the blind spot NetworkLens was built to close. By generating structured, wire-speed metadata from every DTLS session, without decrypting traffic or requiring costly full packet capture, NetworkLens gives carrier security operations, defense and intelligence analysts, and AI-driven threat hunting teams the certificate, handshake, and session-behavior context they need to separate a routine encrypted call from adversary-operated infrastructure hiding in plain sight.