Best practices for Log4Shell Enumeration, Mitigation, and Attack Detection Tool

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 in the next sections.

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).

Monitoring

If you would like to receive alerts when a device shows potential signs of a compromise or a vulnerability, perform the following steps:

1. 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.
2. To the policy, add a File/Folder Size monitor. Configure it as follows:
   1. File: C:\ProgramData\CentraStage\L4Jdetections.txt

   NOTE  NB: In some cases, the system drive may not be C:\.

   2. Criteria: Is over / 0 MB.
3. 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.

Filtering

If you would like to filter on devices registering as affected by Log4Shell (or devices that aren’t), perform the following steps:

1. Create a new site-level or global filter. Refer to Device Filters. Call it Log4J detections.
2. Give it the following parameters:
   1. User-defined field XYZ : Contains : L4JBAD
3. 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.

Once the tool has run, you can filter against devices that are showing issues using the UDF and the filters you configured. If you wish to run the tool regularly, you will need to set up a Scheduled Job. Refer to Scheduled jobs.