While much of the world was celebrating holidays over the last week or more, much of the world’s security industry was busy defending against and investigating log4shell attacks based on the recently disclosed vulnerability in the Apache library log4j. As we collectively move from responding to threats from actors who were quick to take advantage of the weakness we can begin reflecting on what happened. It will be some time before thorough analyses are complete and widely available, but some clear patterns have emerged. Like the rest of the intelligence community, Infoblox is analyzing the timeline of events from many perspectives and thus far our findings are consistent with the community as a whole. In this blog, we’ll discuss some of the early results as well as explain some of the policy decisions we made in our response to the attacks to protect our customer base.
As described in our earlier Cyber Campaign Brief, we realized that failed log4shell attacks often generated invalid DNS queries. By creating an analytic to look for and parse these queries, we were able to identify attacker infrastructure. The invalid queries proved to be a valuable mechanism for identifying a wide range of attacks. While these particular queries were invalid, successful attempts to exploit the log4j vulnerability were visible as resolved queries. As a result, we were able to both validate trends reported by other security vendors, but also identify attacks that were more targeted in nature. A sampling of the most common domains we have observed related to this vulnerability are seen in the figure below.
 |
| A selection of some of the most common domain names seen associated to log4shell activity. |
Our retrospective analysis confirms a number of conclusions reported by other intelligence groups:
- We see no widespread attempts to exploit the vulnerability prior to December 9th,
- Cryptomining actors were quick to use the vulnerability with several actors launching attacks within a few hours of the disclosure,
- In particular, Team TNT coin miner, m8220 mining bot, and the Mushtik mining bot were active before many security teams were able to respond,
- Security researchers and red teams jumped on the news quickly and a dramatic rise in vulnerability testing suites and scanners coincided with the initial mining attacks,
- Attackers leveraged Tor heavily and services such as to2web[.]su, onion[.]ly, and onion[.]ws to transmit traffic between the Internet and Tor, and
- Twitter users quickly produced and distributed proof-of-concept attacks against various applications, making it easy for attackers and defenders alike to scan for vulnerable endpoints,
In addition, we noted that several of the crypto-mining bots had either reduced or no activity for several hours on the 9th, including a period that appears prior to the disclosure. This may indicate that they had early word through illegal channels and reduced operations to update their software for a log4shell attack. Even when the log4j vulnerability is exploited to create a call back to the attacker infrastructure, the system will not be compromised if it is not susceptible to the malware that is downloaded. At this point, we are able to identify trends in attacks and susceptibility of systems to the log4j exploit, but the industry does not have a full grasp on the impact.
While the log4j library isn’t commonplace knowledge, and even developers may be unaware of its use in their systems, the evidence of possible attack surfaces is clear. The exploit of Minecraft servers via the chat system was widely reported on.¹ Websites were widely targeted. As shown in the images below by the strings that include “{jndi”, we observed targeting of everything from cryptocurrency exchanges to crisis center websites. But the vulnerability exists in many other applications which utilize the log4j library under the hood; the National Security Agency’s Cyber Security Director noted that even the reverse engineering software GHIDRA was initially susceptible to the exploit.²
 |
| Figure. Targeting of Cryptocurrency exchanges in the US. |
 |
| Figure. Log4shell targeting of a rape crisis center website. |
This event may be best remembered for the sheer volume of vulnerability scanners and dns trackers used. While red teams sought to test their networks, security vendors, researchers, and attackers alike leveraged the same software to identify exploitable systems. In these cases, in response to the exploit, the vulnerable system sends a DNS request to the scanner domain, which then records the IP address of the system. Some of the exploit strings additionally try to do an LDAP lookup on the host and username of the device. This allows the domain owner to obtain a list of vulnerable IP addresses, and possibly host information, for tracking and possibly later attacks. Individuals obtained free subdomains from a variety of web services, including interact[.]sh, dnslog[.]cn, canarytokens[.]org, and xn--9tr[.]com. While some vendors, like Huntress and Kryptos Logic, used clearly identifiable domain names, allowing them to be easily eliminated as bad actors, others used suspicious domains that forced analysts to spend significant time investigating the activity; psc4fuel[.]com is one such example. While dnslog[.]cn has a history of use for vulnerability testing, its use surged after the announcement. We also saw a large number of scans made through domains obtained via xn--9tr[.]com, also known as dig[.]pm, as subdomains of 1433[.]eu[.]org, dns3[.]cf, and others. The widespread use of the same infrastructure by both attackers and defenders hinders analysis and can make early intelligence faulty.
At Infoblox, we chose an aggressive approach log4shell activity and have classified all related domains and IP addresses as malware for the time being. This allows us to ensure that all customers have the most comprehensive set of indicators in their firewall policies at a time of massive scale attacks. We include known vulnerability scanners and security vendors in this list for a few reasons. First, we do not want customer vulnerabilities disclosed to be used by third parties, whether their intentions are malicious or not. Second, the reuse of software by both good and bad actors, forces us to be particularly cautious. Our customers who use these services for their red teams are able to set custom allow lists for their own networks without impacting others. Customers with security events triggered by queries to vulnerability scanners and DNS tracking services should identify the source; these queries do not imply a compromise and could be due to a number of different causes. Prolonged and numerous unexpected queries to such domains, however, could indicate a vulnerable system within their network.
Endnotes
¹https://www.sportskeeda.com/minecraft/minecraft-log4j-exploit-everything-known-far
²https://twitter.com/NSA_CSDirector/status/1469305071116636167
