Last week we posted about the Log4j vulnerability, advised all organizations to continue patching, and shared that Ordr was not impacted. We also provided an overview of Ordr features that you can use to detect and protect against attacks leveraging Log4j.

In this blog, we will dive into the details of how attackers are taking advantage of this vulnerability. The Russia-based Conti ransomware gang, for example, is exploiting Log4j via vulnerable VMware networks that have not yet been patched. We will look closely at the details of how you can use the Ordr System Control Engine’s (SCE) existing functionality and newly released enhancements to detect and protect against the Log4j vulnerability.

First, here’s a summary of how Log4j attacks progress in a network:

1. An attacker sends a simple HTTP GET request, or a well-crafted protocol message, to the target server. The request is a “User-Agent” header which includes a URL for a JNDI lookup, or a message with the exact string, JNDI for non-web protocols.
2. The request is passed to the Log4j library for logging.
3. The Log4j library attempts a JNDI lookup as directed by the URL. The URL directs this request to an LDAP server that is under the attacker’s control.
4. The LDAP server responds with directory information with a protocol header that includes a Java class to execute. The JNDI library instantiates and executes the class, which has the same system-level privileges as the server software that included the Log4j/JNDI libraries.
5. The successfully injected malware can then do whatever the attacker wants.  Risks include ransomware, exfiltration of sensitive data, and any other malware function.

What can Ordr do for you?

Identifying vulnerable targets

Ordr uses multiple methods to detect targets for Log4j. These include monitoring of SPAN or network traffic to detect attacks or probing a device with active scans to identify vulnerable devices. These are logged in the Ordr Security Dashboard Threat Card as a “special category” created to track Log4j attacks.

IDS based attack detection

The Ordr platform includes an integrated intrusion detection engine that monitors traffic to detect malware and attack attempts. Ordr sensors continuously monitor both North-South and East-West traffic for signs of malicious activity or violations of security policies.  This provides real-time visibility into instances of potential network compromises and insights into any lateral movement attempts made by an attacker.

Anomaly detection

The Ordr platform also includes a machine learning-based behavioral analytics engine. This method is used to confirm a possibility of attack, not a confirmation of an attack. It is recommended this information be analyzed, along with other potential events Ordr has added, for Log4j detection. Ordr SCE analyzes and baselines the traffic based on expected behavior, and any deviation from this normal traffic is marked as anomalous on the system. This model works well for all devices that have predictable traffic patterns. For example, a medical device running limited traffic patterns that suddenly displays new communication patterns should be considered potentially anomalous and be investigated.

Vulnerability probing

Ordr has introduced new vulnerability detection software for Log4Shell. This new scanner takes advantage of Ordr SCE’s knowledge of the devices being scanned. IoT and medical devices require special consideration to avoid interfering in their operation.  This capability is not available in most vulnerability scanning products which will aggressively probe all ports in the ranges of IP addresses they are configured to scan. This type of heavy-duty scanning could be detrimental to the operation of the medical devices that could be providing patient care or IoT automation functions.

Unlike typical IT scenarios where security teams can run a set of scripts to see what kind of Log4j version is built into the server, healthcare operations do not have the privilege to run scripts directly on heavy iron, like CT/X-ray equipment, as well as patient monitoring devices. With Ordr’s scanner, you can select only specific devices to be scanned at a time. It is also typical that a hospital standardizes on a specific make/model, and all that is required is to run this test on only one of them to understand the software decomposition. Ordr generates a report after the scan to show a list of devices that are vulnerable to Log4j.

How does the Ordr scanner work?

• Devices are selected by IP, device type, or various search mechanisms.
• The Ordr scanner runs on Ordr sensor, and does not need full credential access.​
• The Ordr scanner injects a string in the packet that triggers a call back to the sensor if a vulnerability is present.
• The Ordr scanner performs scans on open ports of HTTP, FTP, telnet, and Syslog; It generates a report after the scan is run.

Detecting callbacks to C&C sites

The Ordr platform includes the ability to track and visualize communications to malicious attacker domains; in this case, Log4j attacker domains.

Tracking malicious communications

The Ordr platform subscribes to reputable threat intelligence feeds and is available to every customer today. These feeds detect many of the callbacks to Log4j IPs and domains, but do not associate the family with that. To overcome this problem, Ordr has built a mechanism to scout the internet for all callbacks available for Log4j domains and Ips, and has built a mechanism to update the callbacks dynamically at each customer deployment. The feature provides a two-fold advantage: it covers more callbacks than any of the subscribed threat feeds cover, and it associates the Log4j family to these IP addresses for easy tracking.

Ability to track communications on malicious ports

Another feature available in the Ordr product is tracking communications to the internet based on ports and protocols. As most of the studies have suggested, most of the callbacks for Log4j uses 1389, 2202, and 39536 ports. A simple rule available in Ordr SCE will track every communication to Public IP addresses not owned by the enterprise and mark it as malicious if it matches the rule. All these communications can be viewed on individual devices or under “Blocked Port” on the security page.

Visibility to Log4j traffic patterns

Traffic analysis engine

Ordr SCE provides the ability to visualize problematic traffic centrally in the Group Traffic Analysis tool.   This screen features a constellation plot that shows the recognized groups and individual bubbles.  To make tracking of Log4j easy, Ordr has created a new bubble specific to Log4j, and all communications from inside the enterprise can be viewed with a single click.

In the example below, the operator clicked on the Log4jRCE Sites bubble. The only traffic lines plotted were to the Workstations and Medical Devices group.  This means that other groups such as Servers are not yet active with Log4Shell traffic.

Policy profiles to track communications

Users are given an option to create a policy profile to track communications from a discrete set of devices. In the case of Log4j, it is recommended to create a new policy profile to track devices that are potentially vulnerable to Log4j. In this case, start with servers and expand it to other potential devices.  After creating the policy profile, Ordr SCE evaluates every flow from these devices as a base and marks new communication as malicious. These are color coded based on the risk of the communication.

Highlighting infected devices using a risk score

Ordr assigns a risk score for every device in the network based on the events detected for that device. Each event described above will change the risk score of the device based on the criticality of the event. In the case of Log4j, devices with attributes such as a vulnerable system, where an exploit is identified or if the device is communicating to Log4j callback will have a risk score of critical. The risk score gets adjusted based on the events detected and the criticality of the device.

Ordr has deep integration with firewalls and NAC vendors. Users will have an option to quarantine connected devices based on their risk level, or if they detect a Log4j security event or behavior anomaly. They all point to a possibility of an attack in the enterprise.

In summary, Ordr has one of the most comprehensive features to detect the Log4j vulnerability and protect against exploitation. For more information, please reach out to us at info@ordr.net or request a demo here.

---