Author: Brent Eskridge
On January 10, 2024 Ivanti announced that their Connect Secure VPN devices, formerly known as Pulse Connect Secure and Ivanti Policy Secure gateways, were compromised by attackers exploiting two zero-days. Given the wide usage of Ivanti devices, the response to the attacks has been understandably swift. Organizations are frantically patching their devices and searching for any indications that they may have been a victim. Some of the earliest reporting, such as the reports from Mandiant (1, 2) and Cybereason, provided important details on the attacks and included multiple Indicators of Compromise (IoCs). These IoCs can be invaluable for defenders as they begin to hunt through their networks, but only if used properly.
After reading reports like these, Infoblox customers often ask us if we are blocking the domains listed as IoCs. While it is a legitimate and important question to ask, the reality is it is more complex than simply adding domains from a list of IoCs to a blocklist. Blocking domains using DNS is a powerful tool in defending networks and managing risk, but can easily create more problems than it solves if not done thoughtfully. This situation is a perfect illustration of the challenges we face in attacks such as these. Incident responders face the challenge of providing accurate and timely information in a rapidly developing situation and defenders face the challenge of effectively using that information to protect their networks. Using the IoCs from the Ivanti attacks as examples, we will show some of the factors that defenders need to consider when evaluating whether or not domains should be blocked.
| Domains discovered during incident response are meant for incident response, not blocking. |
Not All Domains Should be Treated Equally
Domains discovered during incident response are meant for incident response, not blocking. More research is needed before any action can be considered. Given the fast paced environment of incident response, there often isn’t much time for an in-depth analysis of 3rd-party domains, which can result in false positives being included in initial reports. Even if all the domains listed are actual indicators of compromise (IoCs), that doesn’t mean the domains can or should be blocked. Often these domains are technically indicators of activity (IoA) rather than compromise.
Without evidence, each domain listed as an IoC should be critically analyzed. Defenders understand that even though www.google[.]com might be discovered as relevant in an incident response, blocking it could cause more problems than it solves. In the articles describing the Ivanti attacks, Infoblox Threat Intel has found three categories of domains that should not be blocked, despite their presence on the IoC list.
- The IoC domain appears to be legitimate and without more evidence, blocking it could negatively impact our customers. For example, the site or some of its content (e.g., a JavaScript library) could have been compromised and since remediated. Blocking the domain wouldn’t provide any protection and would simply inconvenience customers.
- The IoC domain is actually a sub-domain of a dynamic DNS provider. Blocking the domain of the provider would block the suspicious subdomain, but it would also block every other subdomain used by the provider. This is one of the reasons that dynamic DNS is appealing to threat actors. It is easy to hide inside dynamic DNS and the business case for blocking it is challenging to make.
- The IoC domain isn’t a valid domain. There are two “domains” listed as an IoC in various reports that aren’t registered domains. Adding these to a blocklist wouldn’t provide any benefit and would only serve to add noise. Infoblox systems do not allow the addition of this type of indicator.
The table below shows the results of our analysis on the domains listed as IoCs. The majority have either not been observed in customer DNS or had minimal DNS resolutions, meaning adding them to a blocklist would have little to no customer impact. However, there are two domains that had we blindly blocked after reading news reports, could have negatively impacted customers, without much benefit.
| IoC | Valid | Customer Impact | Create Date | Notes |
|---|---|---|---|---|
| api.d-n-s[.]name | ✓ | Moderate | 2004-09-04 | Dynamic DNS provider Other subdomains observed in customer DNS, but not this subdomain |
| ehangmun[.]com | ✓ | None | 2007-11-01 | Appears to be a legitimate site |
| entraide-internationale[.]fr | ✓ | Low | 2010-08-27 | Appears to be a legitimate site |
| miltonhouse[.]nl | ✓ | Moderate | 2010-12-21 | Well-established and legitimate site |
| cpanel.netbar[.]org | ✓ | Low | 2019-12-18 | Other subdomains observed in customer DNS, but not this subdomain |
| areekaweb[.]com | ✓ | Low | 2021-03-12 | Appears to be a legitimate site |
| symantke[.]com | ✓ | Low | 2022-08-21 | |
| secure-cama[.]com | ✓ | None | 2023-05-30 | |
| line-api[.]com | ✓ | Low | 2023-08-30 | |
| clickcom[.]click | ✓ | None | 2024-01-21 | |
| clicko[.]click | ✓ | Low | 2024-01-21 | |
| duorhytm[.]fun | ✓ | None | 2024-01-21 | |
| logclear[.]pl | Not a valid / registered domain | |||
| request[.]data | Not a valid / registered domain |
Infoblox Understands DNS
Each of these issues highlight the fact that effective DNS security is much more than simply adding domains to a blocklist. A deep understanding of DNS is needed when using threat intelligence for blocking. Blocklists are a powerful tool in defending networks, but it can wreak more havoc than it prevents if done incorrectly. Infoblox Threat Intel constantly attempts to balance the need to protect customer networks from potentially harmful content and the reality that one wrong blocked domain can shut down those same customer networks.
For Additional Information
Infoblox Threat Intel provides fast access to accurate, contextual threat alerts and reports sourced from our own real-time research teams. Suspicious Domains feeds were introduced as an Infoblox proprietary product on November 10, 2022 and, since then, have successfully provided many thousands of customers with the advanced information to block domains which ultimately become malicious long before most other threat intelligence sources identify them as malicious. Infoblox allows your team to leverage the high value of suspicious domain threat intelligence while ensuring unified security policy across your entire security infrastructure. Infoblox threat data minimizes false positives, so you can be confident in what you are blocking.
To learn more about suspicious domains and DNS early detection: https://www.infoblox.com/threat-intel/
To learn more about BloxOne Threat Defense:
https://www.infoblox.com/products/bloxone-threat-defense/
To learn more about the National Security Agency (NSA) and Cybersecurity & Infrastructure Security Agency (CISA) guidance on Protective DNS:
https://media.defense.gov/2021/Mar/03/2002593055/-1/-1/0/CSI_PROTECTIVE%20DNS_UOO117652-21.PDF
