topic Re: Seeing DNS Tunnel traffic to/from our Public Ranges? in Advanced Threat Prevention Discussions

Seeing DNS Tunnel traffic to/from our Public Ranges?

JoshVogel0 — Mon, 07 Apr 2025 16:38:44 GMT

Hello,

This past week I've started seeing traffic that's classified as Tunneling:isavscan.[tld] (threat type: dns-c2, ThreatID: 109001001) hitting our Outside intrazone rule where the source and destination are our public ARIN IPs (the rule is currently set to allow while I make sure I have all the traffic we need like BGP and IPSec allowed in other rules). Even more strange, the traffic always seems to be going to the next adjacent IP (so from 1.1.1.1 -> 1.1.1.2, or 1.1.1.200 -> 1.1.1.199), and it's even involving IPs that we don't currently have NATed to anything.

My only guess is some kind of reflection attack, but it's been really low volume, 84 sessions since 3/31. Has anyone seen something like this before? Any thoughts on what attack strategy could be at play, or if there's anything I should do?

Here's a sample of the threat logs:

Re: Seeing DNS Tunnel traffic to/from our Public Ranges?

OtakarKlier — Tue, 08 Apr 2025 19:24:19 GMT

Hello,

If you are not hosing any services that need an inbound NAT, I would recommend you block/drop all external traffic. I always have a DENY ALL policy as my last policy that blocks any any any traffic. This would also block the traffic you are seeing.

Hope that makes sense.

Regards,

Re: Seeing DNS Tunnel traffic to/from our Public Ranges?

JoshVogel0 — Tue, 08 Apr 2025 19:33:55 GMT

Thanks, but we do host many externally available services. I am working on blocking all unspecified Outside-Untrust to Outside-Untrust traffic which, as you say, will block this traffic too, but am making sure I do so without affecting BGP/IPSec/VPN in the process. I was more curious what this strange traffic could indicate. C2 would imply we have compromised hosts, but if that was the case the source IP would be one of our internal IPs, not external. It also doesn't account for why some of our unused external IPs were also taking part.

Re: Seeing DNS Tunnel traffic to/from our Public Ranges?

OtakarKlier — Tue, 08 Apr 2025 19:39:30 GMT

Hello,

First put into place policies that allow the traffic you want to see, BGP/IPSec/VPN (source and destination). Then once you see those policies start to be hit for the traffic you want, then put in the blocking policy.

If the traffic was sourced from external and is destination is external, then I doubt its an internal C2 since the traffic would then be sourced from inside. Looks like a scan from the threat info.

Regards,

Re: Seeing DNS Tunnel traffic to/from our Public Ranges?

gcoochey — Mon, 10 Nov 2025 12:14:46 GMT

I've seen similar traffic to/from adjacent IPs in our range, always source port 12345, destination port 53.

Have to assume it is reflection replies of some sort, we have anti-spoofing on the outside so the traffic is not spoofed source from the Internet, and checked the logs from the source IPs and they didn't source the traffic either... would be interesting to know more, but I have no answers.

Re: Seeing DNS Tunnel traffic to/from our Public Ranges?

I.Warn — Mon, 01 Dec 2025 17:18:10 GMT

We are seeing the same behaviour in our VPN site to site tunnel, same Threat ID, labelled as spyware. Further details as to why this is happening would be appreciated

Re: Seeing DNS Tunnel traffic to/from our Public Ranges?

B.Kowalkowski — Mon, 09 Feb 2026 17:53:11 GMT

Any insights from Palo Alto?

Re: Seeing DNS Tunnel traffic to/from our Public Ranges?

jharr — Thu, 19 Feb 2026 15:23:46 GMT

We've been seeing traffic like this hit our firewall. I have a theory -- this is an actor that's probing around for internal recursive DNS resolvers. And I want to be specific about "internal" -- they're not looking for open resolvers.

Let's say I'm an attacker and I want to footprint an organization.

I can setup an authoritative domain I own -- let's say example.com, and I host it on a DNS server I manage.
I start sending out spoofed DNS queries to an address range I want to inspect. Let's say I want to see if 192.0.2.80 is a DNS server, I spoof from 192.0.2.79, and I might query for a name like test-192-0-2-80.example.com. The record doesn't have to be this obvious, but it's probably unique to the probe target.
Because the spoofed source and target addresses are near to each other, it's likely that a recursive DNS server would permit that source address to perform a query. If you have a DNS server at 192.0.2.80, it's probably going to allow 192.0.2.0/24.
As an attacker, I actually don't care about the response and I'd never see it. What I'm interested in doing is causing the DNS server to take some action I CAN observe. Specifically I'm interested in whether I see a query for test-192-0-2-80.example.com on my authoritative server.
If I do see this, then I know that 192.0.2.80 is indeed a recursive resolver.

What would be neat is if someone has managed to get a payload pcap to see what the DNS query looks like.

As for what they're looking to do with this information? No clue, we haven't seen any follow-on traffic after the probes.

[Update] A coworker did some research and found a 2024 APNIC describing this as DASA Spoofing