- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-25-2026 03:52 AM
Hi,
Our ISP keeps alerting us that we have a malware infection with something called android.badbox somewhere on our network but the source as they see it is our DNS server. They've provided the DNS query which they're seeing (for an A record) but we don't have the facility to log client queries on our DNS system. We've searched the paloalto threat log but can't see anything matching the DNS query. Does anyone have a suggestion on how we could track down the responsible internal system please?
Thanks
James
02-25-2026 04:39 AM
Hi @JamesHodge ,
This is a visibility gap when internal DNS servers are used.
Because the client asks the internal DNS server, and the server asks the internet, the Palo Alto only sees the DNS server's IP as the source.
To find the infected device without logging on the DNS server itself, you could use DNS sinkholing:
use-dns-queries-to-identify-infected-hosts-on-the-network - configure-dns-sinkholing
If you can't use Sinkholing, you can try a Packet Capture (PCAP) on the firewall, but this is a "needle in a haystack" approach:
Set a Packet Filter for port 53 and the IP of your DNS server.
Run the capture.
Open the PCAP in Wireshark and filter by the malicious domain name: dns.qry.name contains "badboxdomain".
But even then, if the DNS server is the one making the query to the internet, the PCAP will likely still show the DNS server's IP.
If you have the appropriate licenses, sinkholing is the only reliable way to catch the client "in the act" as it tries to reach out to the fake IP.
Hope this helps,
Kim.
02-25-2026 05:38 AM - edited 02-25-2026 05:40 AM
@JamesHodge @kiwi is correct about the DNS sinkhole tracking, but there's a catch to this working. You will need to have a firewall inline between the client and DNS lookup request for the bad domain.
Just to be clear, the process goes like this:
A: Client (requests lookup for malicious domain) --> B: Request sent to internal DNS --> C: Request sent to internal root forwards (for external domain lookup, usually in your DMZ) --> D : Internet DNS responds to root forwarders
In order for you to be able to identify the actual source of the lookup you need to have the Palo firewall in-between steps A & B. If your firewall is anywhere after that the Palo will just say the server in step B or C is the "source" of the malware, because from the firewall's perspective that's the server that's actually asking for the domain info. And if this is the case you'd need to turn on logging on your DNS servers to see the IP client (source) that's requesting that bad domain.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!

