The ThreatSTOP Security Research Team began to notice the use of illegitimate 2-letter TLDs \u2013 why would someone try to access a site that does not, and cannot, exist? What we ended up discovering was a fountainhead of threat intelligence.<\/strong> <\/span><\/p>\n To get a better understanding of this form of threat-hunting, we will begin with a brief technical explanation of the various components.<\/p>\n Why are only some TLDs legitimate?<\/strong> When you search for a website, the DNS (Domain Name System) Root Servers are the first to receive the query; they are responsible for directing your request to the IP address of the appropriate top-level domain (TLD) servers. Therefore, the Root Servers are \u201cauthoritative\u201d (contain IP Address Records) for all TLDs. If the TLD does not appear in the Address Records, it is illegitimate.<\/p>\n What happens when a Root Server is given a top-level domain that doesn\u2019t exist?<\/strong> The answer is simple: the domain will not route. The Root Server will look through its Address Records, and will return a failure (NXDOMAIN) when it doesn\u2019t find a result. <\/span><\/p>\n Where does the \u201caddress book\u201d of TLD IP addresses come from?<\/strong> The \u201caddress book\u201d is provided to Root Servers by IANA, the Internet Assigned Numbers Authority. If a TLD is not sanctioned by IANA, its \u201ccontact information\u201d will not appear in the Root Server\u2019s \u201caddress book,\u201d and the query cannot be directed to the correct server. <\/span><\/p>\n <\/span>Why would an attacker use an illegitimate TLD?<\/strong> DNS tunneling (for example) requires attackers to enter a fully qualified domain name (FQDN) into DNS query responses, but these FQDNs are not required to resolve to an IP address. Therefore, attackers can respond to DNS queries (from an infected computer to their malicious server) with a fictitious encoded domain name that fits the FQDN format. For example, if the attacker needs to pass an instruction to an infected computer, the infected computer can contact the attacker\u2019s server using a legitimate DNS query, and can receive a response containing an encoded and illegitimate domain name. For instance, APT groups like Hafnium, involved in the Microsoft Exchange server attacks, have utilized similar methods for long-term infiltration and data exfiltration. Meanwhile, malware networks such as TrickBot and Emotet have exploited DNS tunneling for command and control communications.<\/span><\/p>\n Why would attackers use a 2-letter TLD specifically?<\/strong> One answer is that attackers can fit one more character of encoded information into their message. Otherwise, they could be randomly chosen. Attackers often use legitimate TLDs, such as \u2018.com\u2019 or \u2018.us\u2019. <\/p>\n Why are illegitimate 2-letter TLDs easier to spot?<\/strong> Two-letter TLDs are conspicuous. By filtering Passive DNS records by illegitimate TLDs, researchers can find instances of their use rather quickly. Since there is no legitimate reason to use these unregistered TLDs, the Passive DNS or “PDNS” records are unlikely to show legitimate activity. If they are used by accident, the user is sure to quickly realize their request is failing, so errors tend to have a low number of PDNS hits. <\/span><\/p>\n In summary, this highlights the importance of country code Top-Level Domains (ccTLDs) and unveils the curious case of illegitimate 2-letter TLDs discovered by ThreatSTOP researchers. This discovery has paved the way for a novel approach to cybersecurity, prompting a deeper dive into the mechanics and implications of these anomalous domains in the realm of threat intelligence.<\/span><\/p>\n <\/span>If you already have an understanding of DNS Tunneling and Passive DNS, feel free to skip to the examples in the next section. Otherwise, here is a quick explanation to provide the necessary context. <\/span><\/p>\n <\/span>DNS Tunneling <\/strong>can <\/strong>occur when an attacker infects a machine within a network, and uses DNS functions to communicate with this machine. In this situation, information is passed back and forth between a compromised machine and the attacker\u2019s Command and Control (C2) server using DNS queries. <\/span><\/p>\n Imagine if every time you sent a letter through the postal service, it had to go through a specific sorting center to reach its final destination. Now, picture that someone has figured out a way to send secret messages by hiding them inside regular letters. To the sorting center and anyone watching, these look like ordinary mail, but hidden within are messages meant for someone else entirely. This is similar to what happens in DNS tunneling. The internet sends data back and forth like a postal service, and DNS is like the sorting center directing where that data should go. In DNS tunneling, hackers hide malicious data within normal internet traffic. To an untrained eye (or standard security measures), this traffic looks normal, but it actually contains hidden information or commands that can be used to harm networks or steal data.<\/span><\/p>\n For instance, consider a scenario where an attacker controls a server associated with ‘baddomain.com’. The attacker dispatches a phishing email to numerous computers. Once a user clicks on the link within the email, the malware installed by the attacker prompts the user’s computer to issue a DNS request for ‘xyz.baddomain.com’. Upon receiving this request, the malicious server is then able to send back data to the compromised computer. Specifically, if the malware initiates a ‘TXT’ (text) DNS request, the server operated by the attacker can return a message containing hidden commands. This small piece of text data can then instruct the infected machine to perform unauthorized actions, essentially allowing remote control over the device.<\/span><\/p>\n This type of traffic is usually difficult to catch and block unless you are continuously monitoring your DNS records, since it uses built-in functions of DNS to transfer data. It also occurs on DNS port 53, which must be open to outside traffic in order for computers within a network to reach the internet. Therefore, this type of communication can evade existing network security measures.<\/p>\n Passive DNS<\/span> (PDNS) acts like a digital historian, capturing the ebb and flow of DNS traffic. This effort isn’t solitary; it’s a collaborative orchestra involving giants like ICANN, dedicated security alliances, and the unsung heroes of our online community. Together, they paint a global picture of DNS activity, allowing us to track how domain names and IP addresses evolve over time\u2014a critical task for peeling back the layers of the internet’s ever-changing identity.<\/p>\n Think of DNS records as the internet\u2019s address book, but with more than just street names and numbers. There\u2019s ‘MX’ for directing your emails, ‘TXT’ for those all-important digital footnotes, ‘NS’ for pointing out the domain\u2019s go-to authority, and ‘CNAME’ for when web addresses decide to wear a disguise, redirecting one domain to another. Delving into PDNS records is like detective work; by studying the patterns and shifts in domain queries, we unlock insights into website popularity and spot anomalies that could spell trouble.<\/p>\n Now, onto the intriguing world of DNS tunneling\u2014it\u2019s like the secret passages of cyber threats, allowing attackers to pass hidden messages within legitimate-looking DNS traffic. But it’s not without its limitations. The main characters here are ‘TXT’, ‘CNAME’, and ‘NULL’ queries, each playing a different role in the tunneling saga. While ‘A’ records typically stay out of the espionage game due to their direct nature, ‘TXT’ records often become the cloak and dagger, disguising malicious data in plain sight. Yet, despite its craftiness, DNS tunneling is no match for more direct communication methods, hemmed in by the DNS structure’s own tight constraints and the tiny payloads they carry.<\/p>\n Now, let\u2019s get into a few examples of DNS tunneling revealed in PDNS records. We were able to sort the results by illegitimate two-letter TLD in order to narrow down our search to strictly illegitimate uses of DNS functions.<\/p>\n PTR Records:<\/p>\n In this example, it appears that an attacker and an infected machine may be communicating through PTR (Pointer) records. Since these records require a FQDN in the resource record, the attacker may have chosen the \u201caa\u201d TLD randomly or as part of their encoded message. <\/span><\/p>\n MX Records:<\/p>\n Here, attackers may be using MX (mail server) requests to exchange information and\/or instructions with infected computers. <\/span><\/p>\n MX Records:<\/p>\n Through MX (mail server) requests, it appears that an attacker is exfiltrating data. <\/span><\/p>\n CNAME Records:<\/p>\n Attackers can use CNAME queries to pass information and commands back and forth between the infected client\u2019s machine and the attacker\u2019s machine. <\/span><\/p>\n SRV Records:<\/p>\n In this image, it appears that an attacker is trying to exfiltrate data using SRV (Service) Records. The attack stands out to us because of the .aa TLD present in the resource record data. <\/span><\/p>\n At ThreatSTOP, we\u2019re more than just a service; we\u2019re your ally in the ever-complicated world of cyber safety. Our platform isn\u2019t just about identifying the bad actors in the form of malicious IP addresses and domains. It\u2019s about diving deeper, beyond the surface, to give you a clearer picture of what\u2019s happening within your network. While we understand that not all battles can be fought within the confines of a client\u2019s Response Policy Zone, we equip you with the means to confront these challenges head-on.<\/p>\n Consider the enigma of illegitimate two-letter TLDs\u2014a puzzle we help you solve. Our strategy isn’t just about pointing out the problems; it\u2019s about empowering you with the knowledge to spot and understand the clandestine communications between servers and compromised devices. With Passive DNS (PDNS) records as your lens, the invisible becomes visible. These records are more than data; they are the breadcrumbs leading to potential threats hidden in your network\u2019s nooks and crannies.<\/p>\n Imagine turning these insights into action. When you start sorting through PDNS records, identifying anomalies such as the peculiar *.aa TLDs, you\u2019re not just observing\u2014you\u2019re engaging in proactive defense. This isn\u2019t about chasing shadows; it\u2019s about shining a light on the infrastructures that attackers all too often reuse. It\u2019s about transforming what might seem like cryptic data into a clear roadmap for neutralizing threats. At ThreatSTOP, we\u2019re committed to guiding you through this journey, helping you decipher the signs and strategize your countermeasures, ensuring your network remains a fortress against the ever-evolving landscape of cyber threats.<\/p>\n <\/span>ThreatSTOP researchers have also noticed the use of illegitimate IP addresses within DNS resource records. By searching for A records of reserved (and\/or unusable) IP addresses in PDNS records, we can find examples of DNS tunneling using similar methods to the illegitimate 2-letter TLDs. In these cases, where it is clear that the IP address won\u2019t resolve, the A record data (which can only be an IP address) could be a code or signal. <\/span><\/p>\n Consider the following refined scenario: An attacker, after taking control of a server, breaches a computer within a targeted network. The compromised computer tries to communicate with the attacker’s server by sending a request for a DNS A record, typically used to obtain an IP address for establishing a network connection. However, in this situation, the attacker’s objective is to extract data from the network and send back commands. Therefore, the IP address in the A record could represent an encoded message. This message might appear valid but must conform to the IP address format.<\/p>\n If the attacker’s goal is not to send back specific instructions, they might assign a random IP address to the A record. This randomness could lead to the insertion of a non-standard IP, such as one starting with 255\u2014a clear deviation from legitimate practices. Such anomalies, especially when the IP address is part of an encoded subdomain linked to the compromised computer, signal a mistake on the attacker\u2019s part. This misstep provides a tangible lead for security researchers examining Passive DNS (PDNS) records.<\/p>\n By analyzing these irregular requests, researchers can delve deeper into the attacker’s methods and infrastructure, aiming to neutralize the threat. Although an attacker might occasionally use an invalid IP address, tracking becomes more challenging when legitimate addresses are employed. However, an unexpected domain name or IP in the DNS request can serve as a crucial clue, enabling experts to uncover associated indicators of compromise (IOCs) and disrupt the ongoing attack.<\/p>\n <\/span>Looking through records for \u2018illegitimate\u2019 behavior has proven to be an amazing and largely untapped resource for IOCs. While we have explained the opportunities posed by illegitimate top-level domain and IP address use in DNS tunneling, these are not the only methods for catching attackers hiding in the endless expanse of internet traffic logs. <\/span><\/p>\n <\/span>When we come across records which conform to the standards of their record type, but are unexpected, undefined, or don\u2019t work from a practical standpoint, we can dig deeper to potentially find evidence of an attacker. These small hints can lead to larger discoveries and, ultimately, greater network security. All in all, ThreatSTOP\u2019s recent research has demonstrated that uncovering patterns of commonly perpetrated illegitimate behavior can point us toward new and rewarding avenues of threat intelligence research.<\/p>\n At ThreatSTOP, we understand the importance of robust cybersecurity measures. Our suite of products, crafted by the dedicated ThreatSTOP Security, Intelligence, and Research team, provides comprehensive protection against a myriad of digital threats.<\/p>\n DNS Defense Cloud:<\/strong> This product offers DNS protection via our cloud-based servers. It’s designed for businesses seeking a streamlined, cloud-based approach to safeguard against malicious domains, ensuring your network remains secure without the need for on-premises hardware.<\/p>\n<\/li>\n DNS Defense:<\/strong> For organizations preferring to leverage their existing infrastructure, DNS Defense integrates ThreatSTOP\u2019s intelligence directly onto customer-owned DNS servers. This setup enhances your network’s resilience against cyber threats while utilizing your current assets.<\/p>\n<\/li>\n IP Defense:<\/strong> Our versatile solution caters to a variety of platforms, from traditional routers and firewalls to modern cloud-based applications like AWS WAF. IP Defense allows you to manage and enforce blocklists, effectively shielding your network from command and control communications, invalid traffic, peer-to-peer communication threats, and more.<\/p>\n<\/li>\n<\/ol>\n Each product is meticulously developed to counteract a range of cyber threats, including but not limited to command and control attacks, data exfiltration, phishing, SPAM, and DDoS activity. Our solutions are tailored to disconnect your network from risks while enabling you to connect confidently with your customers.<\/p>\n Our approach focuses not just on detection but on proactive prevention. By integrating ThreatSTOP’s protections, like those within DNS Defense Cloud and DNS Defense, users can preemptively block communications from suspicious or malicious domains. This is particularly beneficial when dealing with the sophisticated tactics employed by entities such as APT groups or malware like TrickBot<\/span> and Emotet<\/span>, as previously discussed. Our insights allow users to identify threats such as those posed by the <\/span>Sea Turtle<\/strong> campaign, which manipulated DNS systems for traffic redirection, showcasing the depth of potential DNS abuses.<\/span><\/p>\n Furthermore, IP Defense’s flexible blocklist management translates into enhanced control over your network’s traffic, enabling you to swiftly respond to emerging threats and suspicious patterns. This aligns seamlessly with our findings on illegitimate TLDs and IP addresses, offering a robust defense mechanism against the exploitation of these vulnerabilities.<\/p>\n By equipping your network with our DNS and IP defense solutions, you ensure a safer, more secure digital environment for your business and your customers. Embrace the power of proactive protection with ThreatSTOP and step into a future where your connections are secure and your risks are mitigated.<\/p>\n Connect with Customers, Disconnect from Risks.<\/p>\n Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" by: Zoe Wallace & Joel Esler<\/p>\n","protected":false},"author":9,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[30,62,215,216,61,1173,49],"tags":[1177,57],"class_list":["post-2750","post","type-post","status-publish","format-standard","hentry","category-dns","category-dns-security","category-passive-dns","category-pdns","category-protective-dns","category-threat-hunting","category-threat-intelligence","tag-threat-hunting","tag-threat-intelligence"],"featured_image_urls":{"full":"","thumbnail":"","medium":"","medium_large":"","large":"","1536x1536":"","2048x2048":"","chromenews-featured":"","chromenews-large":"","chromenews-medium":""},"author_info":{"display_name":"Threat Stop","author_link":"https:\/\/ddi.mohflo.net\/index.php\/author\/threatstop\/"},"category_info":"DNS<\/a> DNS Security<\/a> Passive DNS<\/a> PDNS<\/a> Protective DNS<\/a> Threat hunting<\/a> Threat Intelligence<\/a>","tag_info":"Threat Intelligence","comment_count":"0","jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/posts\/2750","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/comments?post=2750"}],"version-history":[{"count":0,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/posts\/2750\/revisions"}],"wp:attachment":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/media?parent=2750"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/categories?post=2750"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/tags?post=2750"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}DNS Tunneling and Passive DNS<\/strong><\/h2>\n
Tunneling and TLDs: Examples<\/strong><\/h3>\n
![](\"https:\/\/i0.wp.com\/ddi.mohflo.net\/wp-content\/uploads\/2024\/03\/decoding-the-unseen-unraveling-cyber-threats-through-illegitimate-tlds-and-ip-addresses.png?resize=640%2C75&ssl=1\")
<\/p>\n![](\"https:\/\/i0.wp.com\/www.threatstop.com\/hs-fs\/hubfs\/image-png-Mar-18-2024-05-03-29-3181-PM.png?resize=640%2C271&ssl=1\")
<\/p>\n![](\"https:\/\/i0.wp.com\/ddi.mohflo.net\/wp-content\/uploads\/2024\/03\/decoding-the-unseen-unraveling-cyber-threats-through-illegitimate-tlds-and-ip-addresses-2.png?resize=640%2C199&ssl=1\")
<\/p>\n![](\"https:\/\/i0.wp.com\/www.threatstop.com\/hs-fs\/hubfs\/image-png-Mar-18-2024-05-04-02-1958-PM.png?resize=640%2C288&ssl=1\")
<\/p>\n![](\"https:\/\/i0.wp.com\/ddi.mohflo.net\/wp-content\/uploads\/2024\/03\/decoding-the-unseen-unraveling-cyber-threats-through-illegitimate-tlds-and-ip-addresses-5.png?resize=640%2C216&ssl=1\")
<\/p>\nWhat this Reveals<\/strong><\/h2>\n
Expanding on the Theory: \u201cIllegal\u201d IP Addresses<\/strong><\/h2>\n
A Pattern Emerges<\/strong><\/h2>\n
Introducing ThreatSTOP\u2019s Product Suite: Your Shield Against Cyber Threats<\/strong><\/h2>\n
\n
Leveraging ThreatSTOP\u2019s Innovations in Real-World Scenarios<\/strong><\/h3>\n