Best practices for Log4Shell Enumeration, Mitigation, and Attack Detection Tool
On December 10, 2021, news of the active exploitation of a previously unknown zero-day vulnerability (CVE-2021-44228) in a common component of Java-based software (Log4j) became widely known. The extent to which this software package is integrated into the world's technologies and platforms is still being discovered, but given the ease by which software containing this component can be exploited on devices reachable from the open internet (for example, servers), this Log4j vulnerability, dubbed Log4Shell, is being treated as extremely severe. All stakeholders in the technology community are strongly advised to check their environments and take appropriate security measures.
Datto has released a tool, both for RMM partners via the ComStore and publicly via GitHub, to automate the process of scanning Windows devices for signs of this vulnerability and any compromise that may have occurred. This document is for Datto RMM users who have downloaded the tool and wish to ensure they are using it properly.
The tool performs a variety of actions, foremost being a device scan of the following:
- Java Archives (JAR files) containing the vulnerable Log4j component. A successful detection is not necessarily an indicator of compromise, but something to be aware of. Should any compromised files be found in a search, the tool ensures the parent software program is of the latest version and is using a non-vulnerable version of the component.
- Signs of an attempted attack in log files via the YARA file scanner. All .txt and .log files on the device are searched for indicators of attempted compromise by a malicious third party.
These file searches can be configured to search within the device’s home drive, all drives attached to the device, or all drives known to the device (the latter including things like network drives). Note that any additional scan paths will naturally add to the scanning time.
In addition to scanning files, the tool also attempts to mitigate against the vulnerability by setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. This variable is set via a .NET function allowing it to persist across reboots. Various sources note this as an effective workaround.
Finally, the tool records its findings in three ways: first, the StdOut stream of an individual job run can be parsed to view the records in full. Second, a UDF can be configured to sort devices into groups of those which are vulnerable or have had attempts made on them, and those that are unaffected. Third, the tool can be configured in such a way that alerts can be raised following a detection. These latter two methods are explained below.
The tool is written in PowerShell for Windows. It has not been written or tested for PowerShell on any other operating system. It should function on PowerShell 2.0 onwards.
YARA requires the Visual C++ redistributable, which can be installed using the Microsoft Visual C++ Redistributable (2015-2019) component also available from the ComStore.
NOTE Linux users are advised to use the Fenrir Scan component available from the ComStore. Fenrir is a command-line tool by Florian Roth that scans for multiple vulnerabilities and signs of compromise, making it a useful tool in general; it also uses Roth’s Log4j research to detect the same things the Windows Component accomplishes (although it does not apply mitigation strategies).
If you would like to receive alerts when a device shows potential signs of a compromise or a vulnerability, perform the following steps:
- Configure a Monitoring Policy targeting the servers you wish to check with the tool. You may alternatively bind the monitor to individual devices via the device-level monitoring configuration. Refer to Monitoring policy in the New UI or Create a Monitoring policy in the legacy UI.
- To the policy, add a File/Folder Size monitor. Configure it as follows:
- File: C:\ProgramData\CentraStage\L4Jdetections.txt
- Criteria: Is over / 0 MB.
NOTE NB: In some cases, the system drive may not be C:\.
- Push the policy or save the monitoring configuration for the device.
NOTE The tool only creates the L4JDetections.txt file if something is found. As such, the existence of the file will trigger the monitor, producing an alert.
If you would like to filter on devices registering as affected by Log4Shell (or devices that aren’t), perform the following steps:
- Create a new site or global-level filter. Refer to Device Filters - New UI in the New UI or Filters in the legacy UI. Call it Log4J detections.
- Give it the following parameters:
- User-defined field XYZ : Contains : L4JBAD
- XYZ is used as a wildcard here. In practice, running the tool will entail picking a UDF to populate, which should be the same number you choose here.
NOTE If you want a count of the devices that have instead passed the check, use L4JGOOD instead of L4JBAD in your filter parameters. You can assign both to filters for full visibility.
Download the Log4Shell Enumeration, Mitigation and Attack Detection Tool [WIN] tool from the ComStore. From here, mark it as a favorite (legacy UI only) and run it against any Windows device you would like to scan.
There are four variables to configure:
- usrScanScope: Determines how much of the system is scanned. You can scan just the home drive (typically C:\), all fixed and removable drives, or all drives, with the latter option including Network Drives. The latter two options will add time to the scan; scanning just the home drive takes around twenty minutes.
- usrMitigate: Determines whether to mitigate attacks against the device by setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. There is no harm in setting this multiple times; therefore, it is recommended to leave this enabled.
- usrUpdateDefs: Determines whether the tool should download the latest YARA definitions for recognizing Log4Shell from Florian Roth’s GitHub repository. All files are attached to the tool component in case of networking issues, but the latest definitions can still be downloaded and used in case Roth has expanded upon them since the tool’s release. It is recommended to leave this as true.
- usrUDF: Which user-defined field, if any, to write results of the scan to.
NOTE Earlier versions of the component may not show this option even after updating. If this happens, delete the component and re-add it from the ComStore.