topic Re: Badbox malware in General Topics

Badbox malware

JamesHodge — Wed, 25 Feb 2026 11:52:23 GMT

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

Re: Badbox malware

kiwi — Wed, 25 Feb 2026 12:39:22 GMT

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.

Re: Badbox malware

Brandon_Wertz — Wed, 25 Feb 2026 13:40:59 GMT

@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.