Hiding in the Tunnel: How Encrypted Traffic Became Cybercrime's Favorite Getaway Car

There's a quiet assumption baked into how most people think about antivirus software: that it sees everything. Every file download, every suspicious connection, every weird ping to a server in some datacenter you've never heard of. The AV is watching, right?

Not exactly. And the gap in that coverage is a lot bigger than most vendors want to admit.

Over the past decade, the internet made a sweeping shift toward encryption. Today, somewhere north of 90% of all web traffic travels over HTTPS. Add in VPN tunnels, end-to-end encrypted messaging apps, and encrypted DNS, and you're looking at a massive slice of daily digital activity that your antivirus software essentially cannot read. It sees the envelope. It has no idea what's inside.

Cybercriminals noticed.

The Padlock Problem

When your browser shows that little padlock icon, it means the connection between you and the website is encrypted using TLS (Transport Layer Security). That's genuinely good for your privacy — it means your ISP, your coffee shop's router, and random snoopers on the network can't read what you're sending and receiving.

But here's the uncomfortable flip side: neither can your antivirus.

Traditional AV tools were built around inspecting content — scanning files, checking URLs against known-bad lists, analyzing the actual payload of network traffic for malware signatures. Encryption doesn't care whether it's protecting your online banking session or a malware dropper phoning home to a command-and-control server. It scrambles both with equal enthusiasm.

This isn't a new problem, technically speaking. Security researchers have been flagging it for years. What's changed is the scale. When only a fraction of traffic was encrypted, the blind spot was manageable. Now that encryption is the default, that blind spot has grown into something closer to a canyon.

How Attackers Are Using This

The exploitation playbook here isn't particularly complicated, which is part of what makes it so effective.

Malware distribution through HTTPS has become routine. Attackers host malicious payloads on legitimate-looking sites — or, increasingly, on actual legitimate infrastructure like Google Drive, Dropbox, or GitHub — and deliver them over encrypted connections. Because the traffic looks identical to normal HTTPS activity, most endpoint AV solutions flag nothing.

Encrypted command-and-control (C2) communication is another major vector. Once malware is on a machine, it needs to check in with its operators. Doing that over encrypted channels — sometimes even mimicking legitimate HTTPS traffic patterns — makes it dramatically harder for security tools to detect the beaconing behavior that would otherwise be a red flag.

Then there's the rise of malware-as-a-service tools that specifically advertise their ability to route communications through encrypted protocols. This isn't underground knowledge anymore. It's a selling point.

End-to-end encrypted messaging platforms have also entered the picture. Researchers have documented cases where threat actors use platforms like Telegram as C2 infrastructure, precisely because the encrypted nature of the traffic makes it nearly invisible to conventional security monitoring.

The SSL Inspection 'Solution' — And Why It's Complicated

The most commonly proposed fix for this problem is SSL/TLS inspection, sometimes called SSL interception or a "man-in-the-middle" proxy. The basic idea: your organization's security appliance (or your endpoint security software) decrypts the traffic, inspects it, then re-encrypts it before passing it along. Problem solved, right?

Not quite.

First, the technical implementation is genuinely messy. To pull this off, the inspection tool has to insert its own certificate into the trust chain — essentially impersonating the destination server to your browser. This requires either installing a trusted root certificate on every device you want to inspect, or using a security appliance that sits between users and the internet at the network level.

Second, and this is the part that should give everyone pause: you're deliberately breaking the encryption model that HTTPS was designed to provide. You're creating a controlled man-in-the-middle attack on your own traffic. When done correctly, within a properly managed enterprise environment, security teams can make a reasonable argument that this is a worthwhile tradeoff. But "done correctly" is doing a lot of heavy lifting in that sentence.

Research has repeatedly shown that SSL inspection implementations — particularly in consumer-grade products and some enterprise tools — introduce their own vulnerabilities. Older TLS versions, weak cipher suites, improper certificate validation. In some documented cases, the SSL inspection layer actually made the connection less secure than if it had been left alone.

For home users, the picture is even murkier. Some consumer AV products do perform a form of HTTPS inspection, often without being especially upfront about it. You're trusting that the vendor's implementation is solid — which, given the research track record on this stuff, isn't always a safe assumption.

What About Encrypted DNS?

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) are worth flagging separately because they've created a specific headache for security tools that rely on DNS monitoring as a detection layer.

A lot of endpoint security products use DNS inspection as a lightweight way to catch malicious activity — if your machine tries to resolve a known-bad domain, that's a signal. Encrypted DNS makes that approach significantly less effective, because the DNS queries are now hidden inside encrypted tunnels.

Browsers like Chrome and Firefox have been pushing DoH adoption aggressively, which means this is increasingly the default for a lot of users, not something that requires any special configuration. Security teams at organizations across the country have had to scramble to account for this shift.

So Where Does That Leave You?

Honestly? In a position that requires more layered thinking than "I have antivirus, I'm covered."

For individual users, the practical takeaways are a bit sobering. Your AV is not inspecting most of your web traffic in any meaningful content-aware way. It's working with metadata, behavioral signals, and what it can see at the file system level after something has already landed on your machine. That's still valuable — but it's a narrower coverage window than the marketing materials tend to suggest.

For IT folks and small business owners, this is an argument for defense-in-depth that goes beyond endpoint AV: network-level monitoring, DNS filtering through services that can handle encrypted queries, endpoint detection and response (EDR) tools that focus on behavioral analysis rather than traffic inspection, and user education about what phishing and malicious downloads actually look like in practice.

The encryption problem also underscores something the community here at NoDAVG has been circling around for a while: the gap between what AV vendors claim their products do and what they can actually accomplish in a modern threat environment is real, and it's growing. Encryption is a net positive for the internet — but it's also permanently altered the battlefield in ways that legacy security architectures weren't built to handle.

The padlock icon means your connection is private. It doesn't mean it's safe.