return
From an attacker's point of view, our infrastructure is the space where his piece of malware will be executed, surely with different objectives (from incorporating our devices to a Botnet, hijacking our data, collecting information of interest, to the most ingenious cases). That small piece of code needs to use some of our resources in order to accomplish its goals.
DNS Sinkhole is a well-known technique where manipulated results are provided to queries from domains considered malicious. This then allows the attacker to be redirected to a different target system (controlled by us).
Traditionally, the various services that integrate connectivity protection offered (and offer) the possibility of preventive blocking of these queries. With this technique we can go a step further and take that simple DNS request made by our infected device and use it to our advantage.
As we have been exploring in previous posts, this is just one of a variety of techniques focused on Active Defense (HoneyPots, Beaconing). Specifically, we can place DNS Sinkholing in the context of the MITRE Engage Framework and ATT&CK as a technique where we manipulate our network, clearly with the objective of preventing the attacker from advancing with his operations, but also to damage ongoing operations such as data leakage.
There comes a point in the execution cycle of any piece of malware where it makes contact with the outside, either to report an activation status, to send data, or to seek new commands (of course each scenario is different, if we may generalize). It is at this point that the malware is exposed on our network.
On the other hand, typically, DNS queries are performed over a complex network, so detecting the IP from which the malicious domain query has been performed is not easy from the point of view of our NGFWs. The DNS Sinkholing technique provokes the infected computer to communicate directly to our detection IP or IP Sinkholing, and that is where we capture the address of our compromised device to begin remediation tasks.
Before moving on, it is important to note that this task is not always effective because it only yields results in cases where the domains used by the adversaries are already detected by the blocklist providers. In addition, there are lots of alternatives as simple as using a fixed IP (which would completely nullify our measure). Other ingenious techniques are also used, such as the use of reputable domains for external communication or the random generation of new domains, although "lucky for us", a single action registered by our technique is enough to detect an infected computer in our environment and start mitigation tasks.
There are many open source and commercial products that allow us to block DNS queries made to infected site names. Some services that we can use for this protection are: Cloudfare, OpenDNS, AmazonRoute53, Checkpoint, y Fortinet. However, this only results in half of the benefit we can get from this technique. Some providers have natively provided the option to offer a response for that malicious query with an altered result (as in the case of Palo Alto). We will share in this case a small implementation on Amazon AWS.
Its configuration is presented quite simply through a series of "Group Rules" within the VPCs. In this way, all DNS queries are processed according to the defined rules:
This implementation stands out for its ease of configuration and integration with the infrastructure already deployed in the cloud. With these rules, all DNS queries that are detected in the assigned VPC and correspond to malicious domains will be overwritten with our Sinkhole IP.
For Open Source lovers we find Pi-Hole, a micro OS that we can integrate with our DNS servers already deployed (from Microsoft DNS on premise to Google Cloud DNS) and offer an extension of the current functionalities to protect us with this technique.
Pi-Hole can be used as a DNS forwarder to intercept external queries and respond based on configurations. Unlike the previous implementation, where we only had AWS malware lists, in this case we can integrate with a number of DNS providers we already have:
After some simple configurations on the device blocking mode, we are ready to redirect requests from malicious domains:
Once Pi-Hole is running, it allows us to visualize each query to obtain some details. In this case we took some of the domains listed as malicious to perform a series of tests:
Of course, this scenario only shows us half of the story. To complete it we should use some service that allows constant monitoring, for example, for HTTP and HTTPS requests, which are typically used for communication with C2s.
You can find references for the implementation of a HoneyPot here.
