LAST UPDATED March 9, 2022
Security pros are having a week. “No rest for the weary” would be an understatement at this point. After losing an entire weekend and a lot of sleep, security teams aren’t escaping the Log4j2 saga anytime soon. (But there’s always Twitter to add some hilarity to the mix.)
There is a lot of guidance, advice, and “steps to take” out there. CISA recently summed it up in three seemingly simple immediate steps:
- Enumerate any external facing devices that have log4j installed.
- Make sure that your security operations center is actioning every single alert on the devices that fall into the category above.
- Install a web application firewall (WAF) with rules that automatically update so that your SOC is able to concentrate on fewer alerts.
But… easier said than done. As an AP article recently stated, “Simply identifying which systems use the utility is a prodigious challenge; it is often hidden under layers of other software.” We’ve seen in our own customer base that organizations that are Java shops have Log4j integrated into almost every project they have. There are often many inter-related dependencies that make patching a difficult and time-consuming process. Another issue with patching software is a lack of human resources. Plus, the IT team is not rewarded for being on top of patching and, in fact, is oftentimes penalized for causing availability issues on the network.
Our Experience with Detecting and Blocking Log4j
When the Log4j2 vulnerability was reported, ThreatX immediately began testing and implementing common behavior rules to block CVE-2021-44228 attacks. Since there are no agents to update, all customers received updates that were applied immediately. As new variants were discovered across our customer base, all customers benefitted from the shared threat intel. At this point, we feel we have a very robust common rule set in place. However, detecting every possible combination of the attack can result in a performance penalty. Therefore, we are working with each of our customers individually to ensure appropriate levels of protection are in place, giving them the peace of mind and time to patch their systems against this threat. As always, we continue to monitor Log4j2 and other attack vectors, continuously evolving our protection schemes. The ThreatX platform itself does not use Log4j and is not at risk.
Here’s a look at our solution in action, blocking Log4j attacks:
The image below shows several entities attempting to exfiltrate data using the Log4j2 vulnerability and highlights the increase in malicious activity since the publication of this vulnerability:
The image below takes a closer look at our data on a specific entity attempting to exploit the Log4j2 vulnerability.
Why Attacker-Centric Behavioral Analytics Matter
For ThreatX customers, our Attacker-Centric Behavioral Analytics is a critical part of mitigating the Log4j2 threat. Since this attack can be launched in a variety of ways, signature-based defenses will fall short. By monitoring and detecting suspicious behavior over time, ThreatX has identified many versions of the attack and enabled our customers to defend potentially vulnerable servers.
Additional Steps
Apache has documented the Log4j2 vulnerability and published further mitigation strategies. To fully mitigate CVE-2021-44228, update log4j to version 2.16. If you are unable to update to the newest version, you can alternatively remove the JndiLookup java class or set the log4j2.formatMsgNoLookups value to True.
In addition, ThreatX recommends all companies perform regular vulnerability scanning and monitor for suspicious behavior that might point to a compromise.
How We Can Help
In the interest of helping the weary security community (not quite as much help as the tweets above, but close), ThreatX is offering free 30-day licenses of our Web Application & API protection platform to provide teams with advanced detection and blocking capabilities against Log4j. In addition to the platform, ThreatX is delivered via our 24/7 managed SOC, which works as an extension of your team to assist with IR, ops monitoring, virtual patching, and custom counter measure development. Our customers get up and running within 30 minutes and can immediately receive an extended layer of protection against this evolving threat while they address the underlying application vulnerabilities. Due to the unique nature of the ThreatX platform, the solution dynamically baselines application and user behaviors, meaning you can take advantage of the full suite of blocking capabilities within 24-48 hours. We like to call our solution your AppSec “best first step.” Today, that seems especially accurate. Request your free 30-day license here.
