Actionable threat intel in the cloud
DNS Sinkholing & Alerting
Defenders are constantly seeking new ways to identify indicators of compromise within their environments through various data points in order to protect their respective organizations. Enrichment of network data, host telemetry and external threat intelligence can create strong detection rules if integrated into traditional security controls. Typically, this includes items such as SIEMs, firewalls, EDR collection, etc…but migrating to cloud environments presents new challenges for defenders on how to collect and use aforementioned data sources. In this blog post, Lacework Labs will explore how to make actionable use of threat intelligence in an AWS environment through a “crawl, walk, run” approach that won’t overwhelm security engineering teams with new tasks.
Here are the technical details:
Crawl – Sinkholing Malicious Domains
Per AWS’ documentation about their DNS firewall,
“DNS Firewall lets you control access to sites and block DNS-level threats for DNS queries going out from your VPC through the Route 53 Resolver. With DNS Firewall, you define domain name filtering rules in rule groups that you associate with your VPCs. You can specify lists of domain names to allow or block, and you can customize the responses for the DNS queries that you block.” – How Route 53 Resolver DNS Firewall Works, AWS
With this in mind, it’s relatively easy to create block lists for a subset of DNS domains. The DNS Firewall configuration panel is accessible from the VPC page within the AWS console.
Figure 1 – AWS DNS Firewall VPC Experience
The “Domain Lists” settings allows end-users to specify custom domains to filter out with either a single domain per-newline or via a file stored in an S3 bucket (by selecting “switch to bulk upload”). For this example, we’ll demonstrate domain sinkholing with a single domain of “example.com”, but later in this blog we’ll look at bulk loading malicious domains. If you don’t want to curate your own list of malicious domains, AWS also offers a curated DNS blocking list for both malware and botnet traffic.
Figure 2 – Adding Domain List for Blocking DNS
Figure 3 – AWS Managed Domain List
When creating a rule group that enforces the blocking of the domains in a given list, the end user can influence how the response to the domain request will be delivered. Figure 3 below shows the configurations available. For now, we’ll simply block our target domain via responding with an NXDOMAIN, but in the next section we’ll look at how we can use this feature for compromise notification.
Figure 4 – Configuring DNS Responses
Next, you can adjust the rule priority in how the domain rule list will be processed. Then, associating the rule group with a VPC will allow for the DNS blocking to take effect via the DNS firewall. A critical requirement for this to work is using AWS’ VPC DNS and not an external third party DNS for your EC2 workloads. After attaching a rule group to a VPC, AWS’ DNS firewall is associated with the VPC which finally can block DNS requests from curated lists.
Figure 5 – Associated VPC w/ Firewall Rules
Now that our DNS example block list has been configured let’s test it! Switching to a test host within the appropriate VPC for our DNS Firewall we can leverage nslookup or dig to query our target domains. As expected, the image below shows that the domain example.com was responded with an NXDOMAIN record.
Figure 6 – Responding with Static: NXDOMAIN
While this was an isolated example to a single VPC, it can quickly be expanded on with AWS Firewall Manager which allows for centralized firewall management across AWS accounts. For scaling a deployment like this, please reference the latest documentation for AWS Firewall Manager available here.
Walk – Automating Malicious Domain Collection
Expanding on our previous example of leveraging the AWS DNS Firewall, adding domains manually is far too tedious and does not scale with how quickly threat intelligence grows stale. As previously discussed it’s possible to point to a file in an S3 bucket that can be regularly updated. This portion of the blog will look at building cloud native infrastructure to regularly collect and update an S3 bucket of malicious domains for the DNS firewall.
To begin, let’s create a Lambda function to fetch a URL feed of malicious domains. For this example, we’ll leverage abuse.ch’s urlhaus feed which lists domains associated with malware hosting. The DNS Response Policy Zone (RPZ) feed is updated every five minutes and contains a list of malicious domains. The urlhause project has different endpoints for different threat content. So, if your needs expand beyond domain sinkholing, you may choose a different threat feed. Though, be sure to respect the API limitations put in place by abuse.ch to prevent from being blocked. The image below shows a snippet of the raw text content hosted at the urlhaus RPZ threat feed.The feed has a header that once removed results in a malicious domain per line with a description of why it’s on the malicious list.
Figure 7 – URLHaus Feed Example
This data can be easily parsed and created into a Lambda function. The snippet of code below fetches the threat feed, parses it and then writes the data to a file within the S3 bucket called “urlhaus-domains.txt”. The way the lambda function below is currently architected will simply overwrite the file within the s3 bucket every time the lambda function is invoked. Depending on your needs, this function may need to be modified. Additionally, the underlying role associated with this Lambda function will need to have a policy which enables the functionality of the S3 “PutObject” action at a bare minimum.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
import json
import boto3
import urllib3
def log_to_bucket(bucketName, bucketPath, data):
'''
take a list of domains, convert it into a string w/ 1
entry per line and
write to s3 bucket
'''
s3 = boto3.client("s3")
return s3.put_object(Bucket=bucketName,
Key=bucketPath,
Body="\n".join(data))
def lambda_handler(event, context):
'''
Function to run when lambda is invoked
'''
threat_feed = "https://urlhaus.abuse.ch/downloads/rpz/"
bucket = "research-c2-lists"
bucket_path = "urlhaus-domains.txt"
malware_domains = []
http = urllib3.PoolManager()
resp = http.request('GET', threat_feed)
raw_data = resp.data.splitlines()
# skip initial header of feed
for line in raw_data[12:]:
try:
malware_domains.append(line.decode().split(" CNAME")[0])
except:
pass
status = log_to_bucket(bucket, bucket_path, malware_domains)
return {
'statusCode': 200,
'body': status
}Figure 8 – Example Lambda Function to Download Threat Feeds
Now that a Lambda function has been created, there needs to be a way to trigger it. While there are numerous ways to trigger a Lambda function, this example will use an Eventbridge cronjob which will execute on a fixed time schedule.
Figure 9 – Example Lambda Function to Download Threat Feeds
After setting up the event bridge with a target Lambda function, the lambda function itself should look like something in the image below. There is no destination to the right as the lambda function itself simply writes data to an S3 bucket. It’s possible to expand on this example architecture and write data to a SNS queue for further processing if you so chose. Additionally, you could have a webhook be queried to notify a slack channel that the threat intel feed was recently updated.
Figure 10 – Lambda Function Overview
Once configured, the automated threat intel collection architecture will look something like the image below.
Figure 11 – Automating Threat intel for DNS Sinkholing Architecture
Run – Building Notifications for Malicious Domain Lists
In the previous examples it was demonstrated how to sinkhole known malicious domains, but we’re not aware if/when these malicious domains are queried. While query logging exists within AWS Route 53 resolver, this is yet another data stream to ingest, write queries for and monitor. However, by leveraging the AWS custom DNS response in conjunction with Canarytoken’s DNS tokens, a single alerting mechanism for numerous DNS records stored in a rule list can be implemented. Figure 12 below shows the subdomain generated by Canarytokens that when queried will alert an e-mail address specified during token registration. Notably, the DNS tokens were readily used.
Figure 12 -Canary Token for DNS
Figure 13 – Custom DNS Action for a Rule Group
Revisiting the target host, the domain will resolve triggering the canary token subdomain, but the IP resolved will be to canary token DNS servers and not upstream malicious servers. It’s important to understand that the custom record value provided will respond with a “NOERROR” DNS query response to the application making the request. Depending on the TTL specified during the custom DNS action configuration will also influence the cache time on the underlying host.
Figure 14 – Custom DNS Action for a Rule Group
Finally, the domain being contacted results in the canary token being triggered and email being sent with some information that can be used to begin incident response procedures. Figure 15 below shows an example of the data that will be sent to the end user when configuring a DNS token with canarytokens.org.
Figure 15 – Custom DNS Action for a Rule Group
Conclusion
Keeping up to date with the countless techniques adversaries are using for initial access and post compromise activities is nearly impossible. By leveraging DevOps principles and “shifting left” with detection technologies, defenders can begin to automatically merge indicators of threat activity into their production environments for early detection and remediation. Prior to implementing any of the techniques previously discussed, please be aware that the DNS Firewall, along with Lambda and S3 come with additional costs for an AWS account. Refer to the following documentation to understand pricing. For content like this and more, be sure to follow us on LinkedIn and Twitter!
Categories
Suggested for you
