To help security teams stay on top of Log4Shell, LogRhythm Labs recently released information for detecting the vulnerability with the LogRhythm NextGen SIEM and MistNet NDR platforms.
In this blog, we’ll continue to dive deeper as we uncover more detection strategies. You will gain further insight into how MistNet NDR and LogRhythm NetMon can be used to surface traffic related to the Log4Shell exploits using either detection logic or indicators of compromise (IOCs) to identify those hosts which require further investigation.
Detecting Log4Shell with MistNet NDR
MistNet NDR by LogRhythm detects a wide variety of Log4Shell exploits in the network traffic using pattern detection to find both plain text and obfuscated versions of the exploits. Here an example of a detection with an example obfuscated payload:
Figure 1 shows us clearly that the payload has been delivered, what the source and destination of the initial attack was, as well as details of the jndi query — but the question remains, was log4j in fact running, vulnerable, and able to act on the jndi query? Or was this an ultimately harmless request that just traversed the network, but couldn’t be executed?
One of the challenges with end-to-end detection for log4j is that this attack effectively has two destinations: the original delivery destination, as well as the destination of the jndi query executed as a result of the http request, so finding that next step in the chain is an important element of investigation.
MistNet offers several ways to address this question, I’m going to discuss two of them here: the side-by-side hunt capability built into the platform, and subsequently, the Entity oriented detection approach which the MistNet platform uses to associate activities involving a discrete host.
Side-by-side Hunting with MistNet NDR
Let’s start with an incident indicating a detection of a remote code execution (RCE) attempt. We see in Figure 2 the summary details for an attempt to exploit the log4j vulnerability, and we have the targeted IP for the initial exploit displayed here.
Scroll down to the Activity details and open the AlertEvent to show all the related telemetry:
Scrolling down further, the payload_decoded field is the one of particular interest:
Now we have the destination IP address (172.16.0.60) and the destination address for the jndi query (172.16.0.63), so let’s find the next step in the attack.
At the top right of the screen there is a blue button, this launches side-by-side investigations:
This provides us an interface where we can search for the next step in the attack, using the original destination address (172.16.0.60) as the source address for the investigation, and the address from the jndi query (172.16.0.63) as the destination:
Since there was an exploitable instance of log4j present, we see the subsequent communication from the original targeted host to the server controlled by the attacker. Now we know we have a successful exploit, and from here we can pivot further to discover whether the attack has progressed.
Entity Incidents with MistNet NDR
Each discrete host on a network is identified as an “Entity” in MistNet, and activities associated with that Entity build up a picture of the overall status of that host. When activity of interest is first observed, a Case is created as a container for all types of interesting activity related to that Entity. Once the activity associated with the Entity builds up to a level where investigation is required then the Case is elevated to an Incident.
MistNet associates the results of rules-based detections, behavioral detections, threat detections, and custom search detections with Entities to build up a complete picture of activity so that an analyst can review it in one place. In the case of Log4Shell, there are multiple ways that the attacker activity could be surfaced.
In the example in Figure 7, the initial exploit attempt has been detected as a Possible Log4J RCE with obfuscation. Since the targeted host was running a vulnerable version of log4j, the jndi query that was delivered in the initial traffic flow subsequently initiated communicated with the external actor-controlled host, this was detected as an outbound LDAP request as well as a possible Log4j payload by the MistNet platform. Seeing this combination of events raised as an Incident immediately flags the successful exploit, and provides the details required to pivot further to discover what the threat actors next steps were.
Detecting Log4Shell LogRhythm NetMon
LogRhythm’s NetMon has several features which can aid in the detection of Log4Shell exploit attempts through its extensive DPI capability, plus the ability to create new rules-based detections to surface unwanted or anomalous traffic flows.
John Gress from our engineering department has developed three new Deep Packet Analytics rules which you can download from our Community site to aid in the detection of Log4Shell exploit attempts. These rules use two approaches: one is to alert on the presence of outbound ldap and rmi traffic which would typically be suspicious, and the other is to detect communication with IP addresses known to be associated with actors exploiting Log4Shell. More details follow below Figure 8.
DetectExternalLdapComms
This rule will raise an alarm when it detects ldap traffic destined for public IP address ranges. This is a good indicator for a successful exploit delivered to a vulnerable log4j server where the exploit is using ldap in the jndi query.
DetectExternalJavaRmiComms
This rule will raise an alarm when it detects RMI traffic destined for public IP address ranges. This is a good indicator for a successful exploit delivered to a vulnerable log4j server where the exploit is using RMI in the jndi query.
Note that both rules are looking for the application type discovered by the DPI engine and are agnostic to which port is being used for the traffic
DetectLog4j2IocIpAddr
This rule is populated with an extract of the known IOC IP addresses published by Microsoft and will alert on any communication with those addresses irrespective of protocol in use.
You can view an example of these rules in the NetMon UI below:
Stay tuned for more LogJ4Shell detection strategies as we continue to provide updates on LogRhythm’s blog, plus you can find more detailed information on the Community site.