A recently discovered vulnerability in the Java logging utility Log4J (CVE-2021-44228)1 enables remote code execution exploits in a variety of common software. This happens through the download and execution of malicious code embedded in the Java utility, sometimes nested in such a way making it difficult to identify.
Compared to a more directed malware campaign, this vulnerability has many potential exploits. However, Microsoft is maintaining a list of IPs believed to be taking advantage of this vulnerability as detected in their Azure service. Keep in mind, though, that because these bad actors are also scanning systems that are not vulnerable, we should be careful to examine positive indicators closely. The scanners are looking for vulnerable systems, and so receiving an incoming communication from them is not as conclusive as an outgoing communication would be.
Because this vulnerability can affect so many systems, it’s very important to examine network history immediately. We can use Riverbed NetProfiler to identify flows and hosts affected by this threat both now and in the past, and Riverbed AppResponse to analyze web application traffic to identify the vulnerability in action.
Log4J Threat Hunting with NetProfiler
Using NetProfiler with the Advanced Security Module, we can go back in time to verify exposure to the Log4J vulnerability. NetProfiler uses a frequently updated threat feed as its source for vulnerability information including the specific criteria to run against newly captured and stored flow data.
In the graphic below, notice that we can select Log4Shell Known Exploits from the threat feed and run a report to see if we are impacted when it first appeared on the network, and which hosts are affected.
Notice in the graphic below that we’re running a report for the last week.
Some experts believe this vulnerability first appeared around December 1, so we can extend our search further back in time. In the graphic below we’re searching back to December 1.
Log4J Threat Hunting with AppResponse
The Web Transaction Analyzer module, or WTA, within AppResponse 11 allows us to search for the Log4J vulnerability from an application perspective using byte patterns to search the HTTP header and payload.
In the graphic below, notice that within WTA we can use some custom variables to search within the body, URL, and header of application traffic and report back if any of the conditions are true. Here we’re looking specifically for the JNDI lookup since it’s a key part of the exploit mechanism used by the vulnerability. These conditions could be extended to exclude certain source IPs that are legitimately running vulnerability scans as part of your security posture.
Mitigation Steps
After a thorough scan using NetProfiler and AppResponse, also consider these steps to protect systems from the Log4J vulnerability.
- Enable application layer firewalls such as AWS WAF which would significantly reduce the risk by protecting cloud-based and some SaaS applications
- Block outbound LDAP to the public internet
- For log4j versions greater or equal to 2.10 set log4j2.formatMsgNoLookups to true
- And of course, always remember to install the latest patches in both internet-facing and internal systems.
The old tech adage “you can’t secure what you can’t see” has never been more poignant than now. Visibility is the cornerstone of network security, and by using powerful visibility tools such as Riverbed NetProfiler and AppResponse, we can gain a deep and wide awareness of everything going on in our network both in real-time and historically.
1https://www.cisa.gov/news/2021/12/11/statement-cisa-director-easterly-log4j-vulnerability