Historically, Infoblox intelligence, like that of most security vendors, focused on validated threats. Through a wide range of sources and analytics, we curated DNS-relevant indicators of compromise associated with known malware, phishing, and other malicious activity. Over the last several months, though, we have quietly introduced a collection of suspicious domains to our Threat Intelligence Data Exchange (TIDE) and made available a new set of Response Policy Zones (RPZs) based on this work. In this article, we discuss the motivation for, and importance of, this new data.
Intelligence derived from observed threats, such as those associated with malware, is powerful, but it is inherently reactive in nature; by the time threats are observed, they may already have caused significant damage. Perhaps the most significant example of this in recent years is the Solarwinds supply chain attack discovered in December 2020.1 In that case, the attacker was able to exfiltrate data from victims for over six months before detection. In hindsight, the command and control domains were suspicious well before they were known to be a valid threat.
Our suspicious indicator collection aims to identify domains like these as early as possible. By blocking the resolution of the domains, customers can disrupt the delivery of malware with little risk of interference to their own network operations. To make this possible, we have introduced a number of different analytics, including ones based on the reputation algorithms Infoblox published earlier this year.2 Additionally, we consider the query behavior of the domain, registration characteristics, association with known malicious indicators, and the domain name itself.
Suspicious domains and IP addresses may have ties to known malicious activity, but they are not manually validated and the ties are not strong enough for us to associate them with any specific type of malicious activity. These indicators may later be associated with malware, phishing, or some other threat, and by making them available as soon as they are detected, we can provide the greatest protection for our customers.
As an example of the power of this approach, Nozomi Networks, an IoT security company, published an article on the resurgence of the Glupteba malware in December 2022.3 Glupteba is a trojan that was disrupted in late 2021 and has the ability to load various modules, including ones that target IoT devices. Included in their list of indicators collected since July 2022 were multiple domains identified by Infoblox as suspicious. In retrospect, these suspicious domains were used by the Glupteba actor to distribute malware and blocking their resolution would prevent the malware from being deployed. By blocking connections to the suspicious domain, customers would be able to avoid infection with Glupteba in this campaign.
In some cases, suspicious domains are part of an elaborate malicious advertising network used for malware delivery. These huge networks are difficult to analyze and aren’t directly observed in the malware; as a result, they are often unrecognized as a threat in the Infosec community. By identifying these domains first as suspicious, we protect users against malware while the full extent of the threat is being investigated. The Infoblox Threat Intelligence group has published in-depth research on two such networks, Vextrio and Omnatuor.4 The Vextrio network was the delivery system for Glupteba malware campaigns reported by Nozomi, while a handful of other unaffiliated suspicious domains were contained in the distributed list of indicators of compromise.
Emergent domains are a specific type of suspicious domain that we have introduced in an attempt to defend against the variety of timelines on which actors deploy malicious infrastructure. While some may use a domain immediately after registration, it is fairly common now for cybercriminals to wait days, weeks, or even months before using a domain in a campaign. This behavior is referred to as strategic aging. In other cases, they may attempt to trick security vendors by creating a low-volume of traffic for some time, first using the domain to host benign content, or using decoy parking to avoid detection. Our emergent domains are recently observed domains with multiple suspicious characteristics. While many of these domains are newly registered, the creation date is only one factor, and the underlying analytics are looking for a change that represents a domain ‘emerging’ from an idle state. This allows us to identify domains that are not brand new but have been aged by the malicious actor.
Identifying suspicious indicators that are reliable enough for a blocking DNS policy is significantly harder than identifying indicators from known malware, phishing, or other threats. It requires a significant amount of infrastructure, robust analytics utilizing a wide range of features, and domain expertise in DNS and how threats manifest within DNS. We also leverage our Smartlisting system, a Bayesian inference machine learning model for building allow lists for DNS published in 2019, to reduce the likelihood of inadvertently including legitimate resources in our list.5 This investment in our intelligence production now gives our customers early protection and better security than ever before. This “low-regret” methodology, as coined by Johns Hopkins Advanced Physics Lab (APL) and shared by the US Cybersecurity and Infrastructure Security Agency (CISA), provides for an optimal security approach.6
Infoblox customers have access to the suspicious indicators, both domains and IP addresses, via the TIDE API, Dossier, and for BloxOne Threat Defense Advanced customers, three RPZs: one for emergent domains, one for lookalike domains, and one for the remaining types of suspicious indicators. Each indicator is annotated with notes from the Infoblox Threat Intelligence Group describing the reason it was identified as suspicious. B1TD Advanced customers who used the previous version of the Suspicious Domains RPZ should enable all three of the new feeds.
We strive to move the research and development in RPZ crafting forward in significant ways. By offering the ability to block DNS queries to what are likely to be tomorrow’s confirmed threat locations, Infoblox is providing a fully integrated, high-confidence component that is highly usable and highly relevant. Below are answers to anticipated questions about using these indicators in a DNS policy.
What makes a domain or IP suspicious? Infoblox is running a number of analytics built on our expertise in DNS intelligence and we expect these analytics to continue to grow. They are built in part on reputation scores, query pattern behavior, domain name characteristics, registration information, and associations with malicious activity. Each indicator is annotated, as shown in Figure 1, with information about the specific suspicious characteristics.
Figure 1. An example of notes available to customers via our TIDE or Dossier product on every Infoblox indicator.
Do the suspicious RPZs contain false positives? All of the indicators in our suspicious threat class are suspicious, and in that sense there are no false positives. A legitimate domain could be included if it has suspicious characteristics. We make every effort to ensure that this is a rare occurrence.
Why would a legitimate domain be found suspicious? There are a number of reasons a legitimate domain could be deemed suspicious. A common example would be the registration of a domain that was very similar to an established legitimate domain, using anonymous registration, highly abused registrars and TLDs, and the use of free SSL certificates like those available via Let’s Encrypt. No single characteristic will make a domain suspicious.
How do I report a legitimate domain? Dossier has a feedback button or you can open a support ticket. For immediate results in their own networks, customers can add a record to the superseding allow list in their policies.
Is it safe to block suspicious domains? We have refined our analytics to identify suspicious domains with the intention of a blocking policy, but all policy decisions should be made based on the risk tolerance of the network owner.
Why does a single domain have different suspicious properties? There are multiple independent analytics operating in the background, and a single domain may be detected by different algorithms at different times. In each case, the detection contains annotation.
What is an emergent domain? Emergent domains are part of a special subset of the suspicious data; they are domains that we have observed to have new activity, are often registered within the previous 90 days, and have multiple suspicious characteristics. These domains are potentially emerging as an active threat and may be reported multiple times if they resurface. The emergent domains are available in their own RPZ (“Suspicious Emergent Domains”) and have the threat property Suspicious_EmergentDomain.
What other types of suspicious activity do you identify? The “Suspicious” RPZ includes indicators related to phishing, nameservers, registration, spam, and several other features and types of behavior. The “Suspicious-Lookalikes” RPZ includes indicators that imitate legitimate domains but have features or exhibit behavior that we deem suspicious and worth blocking. This feed does not include benign or legitimate lookalike domains.
- https://www.sans.org/blog/what-you-need-to-know-about-the-solarwinds-supply-chain-attack/
- https://blogs.infoblox.com/cyber-threat-intelligence/reliable-reputation-scoring/
- https://www.nozominetworks.com/blog/tracking-malicious-glupteba-activity-through-the-blockchain/
- https://blogs.infoblox.com/cyber-threat-intelligence/cyber-threat-advisory/vextrio-ddga-domains-spread-adware-spyware-and-scam-web-forms/,
https://blogs.infoblox.com/cyber-threat-intelligence/cyber-threat-advisory/vast-malvertising-network-hijacks-browser-settings-to-spread-riskware/ - https://blogs.infoblox.com/security/going-beyond-whitelists-smartlisting-is-required-for-the-modern-enterprise/
- https://www.cisa.gov/sites/default/files/publications/Low%20Regret%20Methodology%20for%20CTI%20Triage_508c.pdf