It’s been a busy week for organizations scrambling to understand the implications of Log4j vulnerability CVE-2021-44228 (also known as Log4Shell). They are likely asking themselves the following types of questions:
- Is Log4j running in our environment?
- If so, are our Java applications vulnerable?
- Are any of our applications being exploited?
It isn’t just you, it’s all of us
Almost all organizations have Log4j running in their environment. It is an integral part of a very large number of Java applications. Secureworks® Counter Threat Unit™ (CTU) researchers observed extensive scanning activity across the Secureworks customer base beginning around December 9, 2021. Some of that scanning was by security vendors, but a lot of it was not. Threat actors were quick to begin looking for vulnerable systems. CloudFlare observed limited testing of the vulnerability as early as December 1.
Notably, as of this publication the number of systems that have been compromised is small compared to the number of systems that were scanned. Secureworks incident responders are dealing with only a handful of engagements despite the widespread nature of the vulnerability. That proportion could change as threat actors incorporate this vulnerability into their playbooks.
It’s not too late to patch
There are a few reasons why there might be fewer compromises than expected:
- Many threat actors may have not yet begun to exploit the flaw. If that is the case, the situation is likely to change quite quickly. CTU™ researchers have already observed post-exploitation activity that can be attributed to known government-sponsored threat groups.
- Post-exploitation activity could be difficult to detect. It’s always possible that exploitation is happening when or where there isn’t visibility. Secureworks researchers are observing high volumes of detections for scan traffic, and the countermeasure and Taegis™ VDR teams are generating new countermeasures daily based on the evolving understanding of the vulnerability from the Secureworks Adversary Group. Importantly, countermeasures already in place to detect post-exploitation activity (e.g., cryptocurrency miners, web shells, Cobalt Strike) remain effective. In the limited number of identified compromises, Secureworks incident responders detected follow-on activity. Despite the somewhat novel delivery method (although it was being talked about in 2016), the malware being dropped on compromised systems is common.
- It is possible that remote code execution is proving harder for attackers than initially thought. Confirming that a system is vulnerable is not the same as being able to run additional code on it. Successful exploitation relies on multiple variables, including the version of Java running, how verbose the logging is, which input elements are being logged, and whether traffic is allowed to egress from vulnerable servers. This would not be the first time that exploits that run relatively easily in testing or against honeypots are less reliable when pointed at complex enterprise environments that have different configurations and system dependencies.
Know your attack surface
If you’re running the vulnerable code (and most organizations are), identifying where the vulnerable code is running is the first step. Organizations are quickly realizing the inconvenient truth that understanding dependencies in their own systems is extremely challenging. The potential for threat actors to leverage this vulnerability for lateral movement once inside a network means that you also need to secure non-internet facing systems. Knowing what infrastructure you are protecting is always key, but never more so than this week. Regardless of any impact from exploitation of this vulnerability, just the act of attempting to mitigate the risk of vulnerable applications will likely consume enormous amounts of time for IT and security teams.
Bottom line
Organizations that are struggling to respond to this situation should focus on three actions:
- Identify systems with vulnerable versions of Log4j, prioritizing those that are internet-facing. Authenticated scanners are the most straightforward way to perform this check if you have that capability.
- Patch vulnerable systems. If you can’t patch, apply the mitigations provided by Apache.
- Investigate for evidence of compromise on potentially impacted systems. Review server logs, analyze network and host telemetry, and review file systems for indications of new and suspicious file creation. Also monitor alerts from countermeasures that could indicate follow-on activity.
For more information about this vulnerability, visit our FAQ.
If you have an incident and need urgent assistance, contact the Secureworks Incident Response team.
If you have other questions on how we can help, contact us.