Protective DNS a Scalable, Continuous Method for Detecting Log4J Attacks
Posted by Dave Mitchell | December 21 2021
The Log4J vulnerability is easy to exploit and hard to detect instantaneously—unless you’re monitoring your DNS traffic.
Earlier this month, a critical remote code execution vulnerability was announced in the open-source Java-based library software Log4J and exploited within hours. With the cat out of the bag, every bad actor on the planet is free to use this easy exploit to attempt to gain control over affected devices. Even if a machine isn’t specifically running Log4J, it is used by innumerable software and applications around the world.
The threat is so massive in scale that Jen Easterly, director of the Cybersecurity and Infrastructure Security Agency (CISA), has called the log4j exploit “the most serious vulnerability (she) has seen in her decades-long career.” In the wake of its release, companies around the world are scrambling to react to the threat by patching their devices and attempting to get a grasp on how the exploit has and will affect their operations. However, it may be many months before we fully see the ramifications of the Log4J vulnerability. Many bad actors may already have footholds within organizations and are biding their time before they strike.
In the meantime, detecting a successful execution of this vulnerability via traditional logging techniques can prove difficult for most organizations. The log4j vulnerability has some key features that vastly increase the scale of the threat. For instance, it is extremely easy to exploit—meaning everyone from script kiddies to highly coordinated criminal groups are taking advantage of it. Delivery is also incredibly easy since the downloadable payload can be hosted anywhere. Unfortunately, this also seems to be an issue that will likely linger, as we are already seeing the exploit evolve rapidly and not everyone has completed patching affected systems.
Due to the nature of the remote code exploit, common shell variables are encoded into outbound DNS requests to attempt a remote code download over a few different protocols. This means there are likely many more mutations of the exploit to be discovered, and the vulnerabilities will likely continue to be taken advantage of for the foreseeable future.
As an example, here is one of many of the DNS requests observed by HYAS Protect from a customer network (obfuscated) showing the behavior of exploitation in real-time:
Currently, the most common User-Agent requests seen during exploitation are in the following formats, which makes their subsequent DNS requests easy to spot in a crowd.
In this instance, Interact[.]sh was a legitimate security testing tool that became a launching point for nefarious actors starting on Dec 12. Once that service was shut down, the bad actors immediately started pivoting to other domains to host their payload download. Because these attacks can originate from anywhere and be hosted anywhere—along with the exploit’s ever-changing fingerprints—DNS is the best enforcement point to identify machines under attack and block outbound DNS requests. This is the best way to weather the current storm while patching all vulnerable machines.
The emergence of the Log4J exploit is just another wake up call to the cybersecurity industry that our current approach is broken. We need to go back to a basic, foundational approach to internet security by paying attention to what and whom our devices are talking to in order to detect threats before they affect your infrastructure and customers. In this situation, DNS monitoring provides a holistic, enterprise-wide view as a key means to detect active exploitation of this vulnerability. Protective DNS is so useful for detecting these attacks that in the past few days, we have lent a hand during this crisis by contacting companies (whether they are our clients or not) to alert them that they have been affected by this exploit—situations that we become aware of simply by monitoring real-time or passive DNS transactions.
The sad truth is that this mess isn’t going away anytime soon. We have yet to see the full effects of its implementation. Even after the appropriate patches have been applied to your devices, there’s no guarantee that everything is copacetic unless you are continuously monitoring DNS, as there will always be something that will be forgotten from the manifest of machines. All signs point to this vulnerability becoming an endemic cybersecurity threat, and the easiest way to counter it is by identifying and blocking suspicious DNS traffic and by restricting outbound internet access.
