With news breaking re: Log4Shell (CVE-2021-44228) and exploitation attempts becoming widespread, MSPs and IT teams have been working nonstop to scope their exposure, scan for potential IoCs, apply mitigations, and patch.
The problem is, since this vulnerability affects so many applications — and because not every vendor has been able to provide clear advisory on whether their products are affected or not (note: NinjaOne is not) — determining what systems are potentially vulnerable is a big challenge.
That problem has led quite a few security researchers and community members to create scripts and tools that can be used to scan environments for potentially vulnerable Log4j files and signs of IoCs.
Examples include:
- Huntress Log4Shell Vulnerability Tester
- Kelvin Tegelaar’s Detecting Log4j Files script
- Jan Scholte’s Ninja-Log4shell-Scanner
- get-log4jrcevulnerability.ps1 by Prejay Shah
- Datto Log4Shell Enumeration, Mitigation, and Attack Detection Tool
- Log4j/Log4Shell PowerShell Scan designed for use with Ninja from AshtonSolutions
- Rob Fuller’s CVE-2021-44228-Log4Shell-Hashes
- Florian Roth’s log4shell-detector (which detects exploitation attempts NOT vulnerable applications
Deciding to utilize any of the available scripts out there is entirely up to you (always test and perform appropriate due diligence first, of course), but if you do find a script that you want to try this post will walk you through an example of how to deploy it across your network by leveraging custom fields in NinjaOne.
Before we dive in, if you’re looking to get up to speed on Log4Shell, the following are great resources:
- Fantastic explanation of Log4Shell by John Strand at Black Hills Information Security
- Good overview of Log4Shell with regular updates from Huntress
- Log4j vulnerability guidance from CISA
Example of how to monitor for Log4j files using NinjaOne
To setup a custom monitor that detects the presence of Log4J library files on endpoints in Ninja, you’ll need:
- A custom field
- A script to collect and store the data (example below, or you can refer to other examples cited above)
- A custom condition to create an alert
- A method for deploying the detection script
Setting up the custom field
The custom field will be used to store data returned by the detection script.
1) Add a new custom field. Since we’ll be monitoring the result of the script on all endpoints, we’ll create a global custom field.
2) The custom field will be named log4j and will be set to type Multi-line. We use multi-line as each endpoint may have multiple files with vulnerabilities. Multi-line will make this information more readable.
3) We then need to configure the custom field. We will set script Script Access to Read / Write.
Note: if script access is not set to ‘Write’ or ‘Read / Write’, you will not be able to write to this field from a script.
This is all that is required to setup the custom field if we are setting up a global custom field.
Creating a script to pull data
For illustrative purposes, we’ll use an example script below fashioned off Kelvin Tegelaar’s script provided on CyberDrain and in the NinjaOne Community Dojo. The primary difference with Kelvin’s script is that it uses an external tool called “Everything” that can make it faster to run.
Please note that there are additional scripts circulating that you can also refer to and customize including:
These may provide faster, more efficient results.
*** Disclaimer: Use of any of these scripts in Ninja is done at your own discretion and risk. ***
$array = @() $Drives = Get-PSDrive -PSProvider 'FileSystem'
foreach($Drive in $Drives) {
$drivePath = $Drive.name + “:”,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
$array += gci $drivePath -rec -force -include *.jar -ea 0 | foreach {select-string “”JndiLookup.class”” $_} | select -exp Path”
