Playbook of the Week: Swallow Traffic to Malicious Domains with DNS Sinkholes

What is a DNS Sinkhole?

When you hear about sinkholes, it’s not necessarily a good thing. However, in the cybersecurity realm, DNS sinkholing is a technique used to redirect DNS queries for malicious domains to a controlled IP address, known as a sinkhole.

It is commonly employed as a security measure to protect networks from accessing or communicating with known malicious domains. By capturing and redirecting DNS traffic to a sinkhole, organizations can gain visibility into potential threats, prevent malware infections, and disrupt malicious activities.

When Should DNS Sinkholing Be Used?

DNS sinkholing enables the identification of infected hosts on a protected network by leveraging DNS traffic.The redirected traffic can be captured and analyzed by security analysts.

In scenarios where the firewall is unable to directly observe the originator of DNS queries, such as when it is positioned north of the local DNS server, traditional threat logs may only identify the local DNS resolver as the traffic source, obscuring the actual infected host.

However, by employing DNS sinkholing, forged responses are generated in response to client queries targeting malicious domains. Consequently, when clients attempt to connect to these malicious domains, they are redirected to a designated sinkhole IP address.

By analyzing the traffic logs, administrators can readily pinpoint the infected hosts attempting to connect to the sinkhole IP, enabling prompt detection and remediation of compromised systems. DNS sinkholing thus provides a valuable solution to overcome network traffic visibility challenges and enhance network security by effectively identifying and addressing infected hosts.

The following image demonstrates the process:

• Botnet on client host 192.168.2.10 sends DNS query for Hacker Server (malicious domain).
• The internal DNS server relays the request through the firewall to the public DNS server.
• The firewall queries the configured DNS signature source and detects the malicious domain request and instead of forwarding the request to the public DNS server, it forges a DNS reply with the sinkhole IP addresses (1Pv4 and 1Pv6).
• Botnet then attempts to communicate with Hacker Server, but sends traffic to the sinkhole IP address instead.
• Session goes through the firewall from the user to the sinkhole address.
• The SOC team can then identify all client hosts trying to communicate with the sinkhole IP address by searching for communication to the sinkhole FQDN in the traffic logs.
• The SOC team then eradicates the botnet from all infected hosts.

Note: The client hosts and sinkhole IP must be in different zones, so sessions pass through the firewall. The sinkhole IP address does not have to be an active host, just an unused IP address.

Our Playbook

Our PAN-OS - Configure DNS Sinkhole playbook automatically finds the security rule that allows outgoing traffic from the internal DNS server/s to the public DNS server on the internet. It then edits that rule and adds an anti-spyware security profile to it. The profile scans the allowed traffic for communication with the malicious domains found in the DNS signature source, and sinkholes the requests.

Verifying the sinkhole is working can be done easily by running “nslookup” on one of the endpoints with the domain we are sinkholing:

Additionally, new threat logs will be generated when an endpoint is trying to resolve a sinkholed domain, showing requests from the internal DNS servers to the external DNS server:

After the requests are sinkholed, the playbook creates an Address Object for the sinkhole’s fully qualified domain name (FQDN): sinkhole.paloaltonetworks.com. It then creates a deny rule to the new address object, preceding the rule that allows the DNS traffic.

Once the infected systems reach out to their command-and-control servers, they will resolve to the sinkhole address. The systems will then attempt to communicate with the sinkhole address. That communication will get denied, producing new traffic logs where the source is the infected system and the destination is the IP address resolving for the FQDN sinkhole.paloaltonetworks.com:

After the sinkhole has been configured, the PAN-OS - Extract IPs From Traffic Logs To Sinkhole can be used to find the IP addresses of the systems that communicated with the fictitious sinkhole address.

The playbooks aim to make as few modifications as possible in the firewall by tagging rules, and reusing existing security profiles, rules and address objects where possible. Additionally, users can easily configure the playbooks to determine:

• Whether to create a new rule to allow DNS traffic if it’s not currently allowed (in order to create the sinkhole)
• What to do if an anti-spyware profile is already applied to the allow rule
• How long to wait for the systems to generate malicious traffic before returning the logs
• Whether to output full logs of the generated traffic to the sinkhole, or only the detected source IP addresses

The PAN-OS - Configure DNS Sinkhole playbook can be used as a sub-playbook for remediation in malware playbooks, or run manually.

The PAN-OS - Extract IPs From Traffic Logs To Sinkhole playbook can be used as a sub-playbook when the sinkhole is already configured, as a form of enrichment or hunting. It can be leveraged when one system is infected and there’s a need to map other infected systems, or it can be run as a job when new malicious domains are ingested from a feed or added in a PAN-OS signature update.

If you’re interested in sinkholing specific domains specified in an External Dynamic List, we recommend using the PAN-OS - Configure DNS Sinkhole playbook in conjunction with the Generic Export Indicators Service, which can be used to automatically export domains to an EDL.

Don't have Cortex XSOAR, download our free trial here.