How to Perform Threat Hunting Using Passive DNS
Reading time: 14 minutesThreat hunting is possibly the most complex piece of the cybersecurity puzzle every organization endures, often performed via a bespoke approach with an emphasis on scanning to discover assets and gaps within an organization's security policies.
Combined with the use of automated scanning tools, however, an organization can overhaul their threat hunting approach and reduce time spent detecting vulnerabilities.
But just as vulnerabilities evolve, threat hunting itself is an ever-evolving concept that now involves not only scanning the present virtual assets, but also past information such as the usage patterns of an organization's virtual assets.
Gathering historical information such as usage patterns is performed via passive DNS, which allows one to find DNS records that were held on a domain or subdomain.
How can passive DNS help threat-hunting teams?
Threat-hunting teams often rely on key information such as usage patterns and historical data. Given the nature and design of the DNS system, once a DNS record is deleted, it’s completely gone and untraceable.
Now, with newer and more resilient methods being used by cybercriminals, such as Fast Flux and DGAs (domain-generating algorithms), it’s become critical to keep a close watch on every DNS entry created or removed from your organization's domains. This is key to avoiding your organization's domains from being used by criminals to aid in their attacks and other criminal activities.
These security limitations of the DNS system are eliminated with the usage of passive DNS intelligence, in which data such as usage patterns and historical information is available for threat-hunting teams to analyze and adapt, and around which security policies can be built.
Historical DNS records such as A records, NS, and other essential information are made available to identify possible threats and insecure usage patterns.
Consider, for example, a stealthily crafted DNS hijacking attempt made on an organization's DNS server that can be only caught or detected by the usage of passive DNS. This would otherwise go undetected if the attacker changed the DNS records back to the original DNS records after finishing their phishing or hacking campaign.
Using an API is also important when you need to integrate more sources of information into your existing workflow, as this allows for your existing workflows to remain the same while providing you with a wider overview of information. Luckily, the SecurityTrails API uses passive DNS data to help security teams, including threat hunters, to detect possible threats within their organizations.
Threat hunting using a passive DNS API
Let’s look at some of the most prevalent threats that can be detected by using a passive DNS API.
Domain phishing attacks
Similarly, threat hunting via the SecurityTrails API can be leveraged by looking up domains or subdomains that attempt to appear as part of your organization, an attack practice commonly known as phishing.
For example: imagine your organization is named “XYZ LLC” with the domain XYZLLC.com, and a bad actor attempts to register XYZLLC.org with a look and feel similar to those of your current website.
Utilizing the SecurityTrails API can help you find these similar domains and subdomains quickly, and also allow your security teams to alert your organization about such domains or simply block them over the corporate VPNs as well.
Looking up similar domains or subdomains via the API can be done as follows:
Replace YOUR-DOMAIN with an existing domain you wish to get the DNS records for, and YOUR-API-KEY with your SecurityTrails API Key.
curl --request GET \
--url https://api.securitytrails.com/v1/domain/YOUR-DOMAIN/associated \
--header 'APIKEY: YOUR-API-KEY'
For example, if we look up the securitytrails.com domain, we see the following output:
{
"endpoint": "/v1/domain/securitytrails.com/associated",
"meta": {
"max_page": 1,
"page": 1,
"query": "SELECT domain.hostname,organization.name,organization.legal_name,organization_parent.name,organization_parent.legal_name,ssl.subject.organization,whois.contact.organization,whois.contact.email,whois.contact.organization_normalized FROM hosts WHERE domain.is_dropped IS NOT true AND domain.subdomain IS NULL AND domain.hostname != 'securitytrails.com' AND ((organization.legal_name IN ('SecurityTrails') OR organization.name IN ('SecurityTrails') OR organization_parent.legal_name IN ('SecurityTrails') OR organization_parent.name IN ('SecurityTrails') OR whois.contact.organization_normalized IN ('SecurityTrails') OR whois.contact.email IN ('[email protected]')) OR meta.asr_include = 'ad:securitytrails.com')",
"total_pages": 1
},
"record_count": 87,
"records": [
{
"alexa_rank": null,
"computed": {
"company_name": null
},
"host_provider": [
"RACKSPACE"
],
"hostname": "scalescale.com",
"mail_provider": [
"GoDaddy.com, LLC"
],
"whois": {
"createdDate": 1109289600,
"expiresDate": 1677283200,
"registrar": "GoDaddy.com, LLC"
}
},
{
"alexa_rank": 60561,
"computed": {
"company_name": null
},
"host_provider": [
"Cloudflare, Inc."
],
"hostname": "bgpview.io",
"mail_provider": [
"Hetzner Online GmbH"
],
"whois": {
"createdDate": 1456169675,
"expiresDate": 1708630475,
"registrar": "GoDaddy.com, LLC"
}
},
{
"alexa_rank": 192009,
"computed": {
"company_name": null
},
"host_provider": [
"RACKSPACE"
],
"hostname": "servermom.org",
"mail_provider": [
"Atlantic.net, Inc."
],
…
…
Stale DNS records-based attacks
DNS enumeration also allows organizations to look out for stale DNS records on subdomains and domain names within the organization.
Consider this example: organizations frequently make use of public cloud platforms such as AWS, Google Cloud, or Azure to host an organization's digital assets and stale DNS records. These assets and records often point to IP addresses that no longer belong to the virtual machines of that organization, which can lead employees into phishing or malware campaigns while accessing a domain or subdomain belonging to your organization.
DNS enumeration via the SecurityTrails API endpoint is as simple as the following query, which returns the last 100 DNS records for your domain of choice. The information also includes when the record was first seen, last seen, and the type of record as well (eg, A record):
curl --request GET \
--url 'https://api.securitytrails.com/v1/history/YOUR-DOMAIN/dns/a?page=1' \
--header 'APIKEY: YOUR-API-KEY' \
--header 'accept: application/json'
Replace YOUR-DOMAIN with an existing domain you wish to get the DNS records for and YOUR-API-KEY with your SecurityTrails API Key.
For example, in considering the domain “securitytrails.com”, running the API query would then result in an output similar to:
{
"endpoint": "/v1/history/securitytrails.com/dns/a",
"pages": 1,
"records": [
{
"first_seen": "2021-11-04",
"last_seen": "2022-12-20",
"organizations": [
"Cloudflare, Inc."
],
"type": "a",
"values": [
{
"ip": "172.66.41.38",
"ip_count": 1034
},
{
"ip": "172.66.42.218",
"ip_count": 1034
}
]
},
{
"first_seen": "2021-04-17",
"last_seen": "2021-11-04",
"organizations": [
"Fastly"
],
"type": "a",
"values": [
{
"ip": "151.101.130.132",
"ip_count": 6227
},
{
…
…
Looking up (potentially) malicious domains via PTR or RDNS records
Another critical source of threats such as phishing or scam emails can be detected using PTR or Reverse DNS Records.
PTR or reverse DNS records are often used to determine the authenticity of the source of origin of emails. For example, when a domain points to an IP address and the PTR record set on the IP address points to the domain itself, PTR records are often abused as well, by being set up with domains that are used for sending out phishing or fraud emails.
Looking up PTR records via the SecurityTrails API is performed as follows:
Replace YOUR-DOMAIN with an existing domain you wish to get the DNS records for, and YOUR-API-KEY with your SecurityTrails API Key.
curl --request POST \
--url https://api.securitytrails.com/v1/ips/stats \
--header 'APIKEY: YOUR-API-KEY' \
--header 'content-type: application/json' \
--data @- <<EOF
{
"query": "ptr_part = 'YOUR-DOMAIN'"
}
EOF
By querying this API call we see the following output, which lists the PTR records available for a specific domain pattern. This can help us look up any potential phishing domains or servers set up to mimic one's existing organization.
Consider if there exists a PTR/rDNS entry such as “best-amazon-deals-2023.com” you can assume the IP / PTR record would be used for malicious purposes and block it away in their corporate firewalls as a preventive measure.
Output example:
{
"endpoint": "/v1/ips/stats",
"total": {
"relation": "eq",
"value": 2
},
"ports": [],
"top_ptr_patterns": [
{
"count": 1,
"key": "kali.securitytrails.com"
},
{
"count": 1,
"key": "o#.rev-sg.securitytrails.com"
}
]
}
Expired domains: another part of the phishing puzzle
The WHOIS history of a domain is another crucial aspect to consider. Domains can often be stolen or “sniped” by the process of domain drop catching, wherein a domain is registered mere seconds after it’s expired due to non-renewal (which can happen for various reasons).
Detecting any change in WHOIS history can be integrated into your existing workflows and can alert your organization to domains being stolen or taken over by bad actors.
Looking up the WHOIS history of a domain via the SecurityTrails API is performed as follows:
Replace YOUR-DOMAIN with an existing domain you wish to get the DNS records for, and YOUR-API-KEY with your SecurityTrails API Key.
curl --request GET \
--url https://api.securitytrails.com/v1/history/LOOKUP-DOMAIN-HERE/whois \
--header 'APIKEY: YOUR-API-KEY-HERE'
If we look up the securitytrails.com domain via this API query, we see the following output which contains the domain WHOIS history, such as how many historical entries exist for this domain under the “count” key, as well as fields including contact information, address, email-id and phone numbers which were present on the domains WHOIS records at the time.
This information can help you trace back to the previous domain owner, and also whether any bad actor owned the domain before, or if there is any historical usage of the domain which might negatively impact your new project or website based on this domain name.
{
"endpoint": "/v1/history/securitytrails.com/whois",
"result": {
"count": 5,
"items": [
{
"contact": [
{
"city": "Tempe",
"country": "United States",
"email": "Select Contact Domain Holder link at https://www.godaddy.com/whois/results.aspx?domain=securitytrail",
"fax": "+1.4806242598",
"name": "Registration Private",
"organization": "Domains By Proxy, LLC",
"postalCode": "85284",
"state": "Arizona",
"telephone": "+1.4806242599",
"type": "administrativeContact"
},
{
"city": "Tempe",
"country": "United States",
"email": "Select Contact Domain Holder link at https://www.godaddy.com/whois/results.aspx?domain=securitytrail",
"fax": "+1.4806242598",
"name": "Registration Private",
"organization": "Domains By Proxy, LLC",
"postalCode": "85284",
"state": "Arizona",
"telephone": "+1.4806242599",
"type": "technicalContact"
},
{
"city": "Tempe",
"country": "United States",
"email": "Select Contact Domain Holder link at https://www.godaddy.com/whois/results.aspx?domain=securitytrail",
"fax": "+1.4806242598",
"name": "Registration Private",
……………………
Finally, taking down bad actors and their assets involves finding out where the assets are hosted. This is made possible by looking up the domain itself, and in turn, looking up who hosts the phishing or fraud pages or stolen domain.
This can be also achieved via the SecurityTrails API as follows:
Replace YOUR-DOMAIN with an existing domain you wish to get the DNS records for, and YOUR-API-KEY with your SecurityTrails API Key.
curl --request GET \
--url https://api.securitytrails.com/v1/domain/YOUR-DOMAIN \
--header 'APIKEY: YOUR-API-KEY \
--header 'accept: application/json'
For example, if we look up the securitytrails.com domain, we see the following output, which contains information such as the domain name being looked up and values for various DNS records such as A, AAA, MX, and NS setup on the domain as well as, most importantly, when the DNS records were first seen.
This information helps trace out which organization previously hosted the domain and can be used to set up alerts in case the domain is seen running outside your existing list of known organizations (such as public cloud platforms) authorized to host your domain.
{
"alexa_rank": 15285,
"apex_domain": "securitytrails.com",
"current_dns": {
"a": {
"first_seen": "2021-11-04",
"values": [
{
"h": null,
"ip": "172.66.41.38",
"ip_count": 1038,
"ip_organization": "Level 3 Parent, LLC"
},
{
"h": null,
"ip": "172.66.42.218",
"ip_count": 1038,
"ip_organization": "Level 3 Parent, LLC"
}
]
},
"aaaa": {
"first_seen": "2021-11-04",
"values": [
{
"h": null,
"ipv6": "2606:4700:3108::ac42:2926",
"ipv6_count": 978,
"ipv6_organization": null
},
{
"h": null,
"ipv6": "2606:4700:3108::ac42:2ada",
"ipv6_count": 978,
"ipv6_organization": null
}
]
},
"mx": {
"first_seen": "2020-07-03",
"values": [
{
"hostname": "aspmx3.googlemail.com",
"hostname_count": 4126741,
"hostname_organization": "Google LLC",
"priority": 10
},
{
"hostname": "aspmx2.googlemail.com",
"hostname_count": 4219340,
"hostname_organization": "Google LLC",
"priority": 10
},
{
"hostname": "alt2.aspmx.l.google.com",
"hostname_count": 14622936,
"hostname_organization": "Google LLC",
"priority": 5
},
{
"hostname": "alt1.aspmx.l.google.com",
"hostname_count": 14697498,
"hostname_organization": "Google LLC",
"priority": 5
},
{
"hostname": "aspmx.l.google.com",
"hostname_count": 14925800,
"hostname_organization": "Google LLC",
"priority": 1
}
]
},
"ns": {
"first_seen": "2021-02-20",
"values": [
{
"nameserver": "rick.ns.cloudflare.com",
"nameserver_count": 77376,
"nameserver_organization": "Cloudflare, Inc."
},
{
"nameserver": "hope.ns.cloudflare.com",
"nameserver_count": 65809,
"nameserver_organization": "Cloudflare, Inc."
}
]
},
…………
Noisy neighbors can be a threat in the virtual world
When using public cloud platforms such as AWS, Google Cloud or Azure, IP addresses are randomly assigned to instances that include virtual machines.
If your virtual machine receives an IP address that is close to an IP address belonging to a “noisy neighbor” (perhaps someone who runs a spam email operation or hosts phishing pages), your virtual machine's IP address reputation could be impacted as well. This can lead to your emails landing in your customer's junk folder, your websites being presented with a warning when visited by customers, or even being blocked by various web firewalls that block immediate subnets when such issues are detected within an IP subnet.
Knowing who your virtual neighbors are is another important step to consider when setting up your services. This can be achieved via the SecurityTrails API as follows:
Replace YOUR-IP-ADDRESS with an existing domain you wish to get the DNS records for, and YOUR-API-KEY with your SecurityTrails API Key.
curl --request GET \
--url https://api.securitytrails.com/v1/ips/nearby/YOUR-IP-ADDRESS \
--header 'APIKEY: YOUR-API-KEY'
If we look up the IP address 8.8.8.8 belonging to Google DNS, we see the following output which lists IP addresses and active hostnames on those IP addresses near your IP address input (in this example, 8.8.8.8). This output helps determine what domains and hostnames your neighbors host, in turn helping you identify possible risks alongside your server.
Consider this: if an IP address beside your IP has the hostname best-amazon-deals.com, and hosts an Amazon login phishing page, this can lead to the entire subnet’s reputation decreasing. Furthermore, if your IP is directly beside the offending IP (i.e., a few octets up or down), it can lead to severe issues with blacklisting, corporate firewalls, and AntiVirus solutions blocking your website automatically.
The previous query example would result in an output similar to:
{
"blocks": [
{
"active_egress": false,
"hostnames": [
"dafabet.best",
"dafabet.host",
"dafabet.pw",
"melodia.hitv.live",
"test.gloriamscleaning.com"
],
"ip": "8.8.8.0/32",
"ports": [],
"sites": 13
},
{
"active_egress": false,
"hostnames": [
"1.qualiaglass.com",
"auswc01.alloctest.call2.team",
"autoconfig.kathrynmcevoy.com",
"autodiscover.kathrynmcevoy.com",
"cabbccddeeff.oemdemo.com"
],
"ip": "8.8.8.1/32",
"ports": [],
"sites": 53
},
{
"active_egress": false,
"hostnames": [
"device2316454-4c98d1df-local.wd2go.com",
"mail.moocouc.net",
"panic.net.in.tum.de",
"plaskolite.bear1.cincinnati1.level3.net",
"test.alyxpattison.org"
],
"ip": "8.8.8.10/32",
"ports": [],
"sites": 30
},
{
"active_egress": false,
"hostnames": [
"endlager.net.in.tum.de",
"fortest.xbox.pt.xiaomi.com",
"test.emarketingtrend.com",
"test.prestafute.com",
"test.randivoo.com"
],
……………….
}
Suspicious IP addresses and infrastructure
The popular command-and-control (C2) servers are typically used by malware to communicate with its operator. It's important to note that these kinds of servers often use different techniques to hide from detection, so a few approaches that may help us detect such servers include:
- Gathering historical DNS records for a specific domain or IP address, as C2 servers often use dynamic DNS to evade detection. Also, looking up any unusual or unexpected changes in DNS records, such as new subdomains or changes to IP addresses.
- Checking if the domain or IP address has a history of being associated with malicious activity, such as hosting malware or phishing sites. This can be done easily, by comparing the IP information from our API.
- Using WHOIS data to identify the registrant of the domain and check for any suspicious activity or patterns associated with the registrant.
- Looking up SSL/TLS certificate information, which can give you access to useful data, as C2 servers may use encryption to protect communications.
We’ve already explored other API examples for historical DNS records, as well as WHOIS data, so now we’ll focus on how to look up SSL certificate information via the SecurityTrails API:
Replace YOUR-DOMAIN with an existing domain you wish to get the DNS records for, and YOUR-API-KEY with your SecurityTrails API Key.
curl --request GET \
--url 'https://api.securitytrails.com/v1/domain/YOUR-DOMAIN/ssl?include_subdomains=false&status=valid' \
--header 'APIKEY: YOUR-API-KEY'
In our example query, we look up only the primary domain name “SecurityTrails.com” and no subdomains, and only list the valid SSL certificates. At the same time, the API allows you to list all SSL certificates associated with the subdomains as well as expired SSL certificates, giving you complete coverage of your organization's SSL certificate history.
The above example gives us the following output:
{
"endpoint": "/v1/domain/securitytrails.com/ssl",
"meta": {
"max_page": 1,
"page": 1,
"query": {
"domain": "securitytrails.com",
"include_subdomains": "false",
"status": "valid"
},
"total_pages": 1
},
"record_count": 5,
"records": [
{
"dns_names": [
"securitytrails.com",
"*.securitytrails.com"
],
"fingerprints": {
"md5": "",
"sha1": "",
"sha256": ""
},
"id": "9/fap+zismvejhvcbpvzu6psih2vrjx29gtglwdsrsa=",
"issuer": {
"common_name": "Amazon",
"country": [
"US"
],
"organization": [
"Amazon"
],
"organizational_unit": [
"Server CA 1B"
]
},
"not_after": 1674172799,
"not_before": 1640044800,
"precert": true,
"public_key": {
"bit_length": 0,
"key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApfUtPwxcQY2A/A6bAd2uR5Bt3blGVaOZBYLrZrKGaviBppIPCfmJPe/lZCRXNaOaiWiZh05aWD6Z1dOQ8zBmoYV/TsM/x0MTMirdV3ZwazaSScnvUi46opLsshIjIZ0h6RWKLsCXVToVmWz2BUdshUxFCpo2GVQrvDw1E4vXSS3lvgprefivAW3oN81o7dqfV/F0T/IKYV4H/2FKIEX+pnmr6lXUnuV6yGX2WW7viLlu4/6Uw4BwgCo38RiSbFojG/32zag3VhEkS3ATTWOo4Miia7ZACZ07KSvceFERnkAPUvyzZl099IeOkB6hcdmehVG1JEzUk79tUCu1IiYpsQIDAQAB",
"key_type": "RSA"
},
"raw": null,
"serial_number": "11819648861052740146421238425414627483",
"subject": {
"common_name": "securitytrails.com"
},
Summary
With today’s ever-growing number of threat vectors and bad actors, vulnerability detection by scanning current assets just isn’t enough. An organization must look into the past and analyze passive DNS records, IP information, WHOIS data, and SSL certificates when trying to understand its digital footprint.
As always with cybersecurity, passive DNS visibility remains restricted to what is exposed on the public internet and accessible via public DNS servers. Newer technologies meant to aid user privacy but increasingly being misused by attackers, such as DNS over TLS and DNS over HTTPS, make this an even bigger challenge for threat hunters.
Using the SecurityTrails API makes it possible to integrate and automate passive DNS information-gathering into your existing security workflows, and as seamlessly as possible!
