Monitoring with PowerShell: Detecting Log4J files

Hey all, so this is a pretty quick one, to add onto the already many scripts released for this. In this script we’re trying to get all the files that could suffer from the Log4J issue in CVE-2021-44228. I’m saying could, because the script detects a class that is also used in other products, Hence it might end up with some minor false positives.

The script uses “Everything” by Voidtools which is a rapid search tool that can index all files on Windows much faster than anything else. I suggest you host the portable version somewhere yourself so you are able to control exactly which version get’s installed, and you can do your due diligence on there.

As always, I assume you are executing this script as system, from your RMM tooling.

$PortableEverythingURL = ""

Set-PSRepository -Name 'PSGallery' -InstallationPolicy Trusted
Invoke-WebRequest -UseBasicParsing -Uri $PortableEverythingURL -OutFile "$($ENV:TEMP)\" 
Expand-Archive "$($ENV:TEMP)\" -DestinationPath $($ENV:Temp) -Force
if (!(Get-Service "Everything Client" -ErrorAction SilentlyContinue)) {
   & "$($ENV:TEMP)\everything.exe" -install-client-service
   & "$($ENV:TEMP)\everything.exe" -reindex
    start-sleep 3
    Install-Module PSEverything
else {
       & "$($ENV:TEMP)\everything.exe" -reindex
    Install-Module PSEverything

$ScanResults = search-everything -global -extension jar
if ($ScanResults) {
    Write-Host "Potential vulnerable JAR files found. Please investigate:"
    Write-Host "all Results:"
    Write-Host "All Results with vulnerable class:"
($ScanResults | ForEach-Object { Select-String "JndiLookup.class" $_ }).path
else {
    Write-Host "Did not find any vulnerable files."

you can easily implement this script in most RMM systems, and get a quick overview of places you might have log4j active. This is just one of many solutions, Also check out some other solutions by one of my friends, Prejay Shah here. This one uses Search-Everything, but fails back to get-childitem if that is not working.

As always, Happy PowerShelling,.


    1. Kelvin Tegelaar December 15, 2021 at 8:26 pm

      No clue, maybe a file that was there was touched by get-childitem, and triggered the AV?:)

      1. jdb December 16, 2021 at 4:28 pm

        the script has a lot of fluff. i think it is because the script uses robocopy, which is an .exe a script that triggers running .exe or making connections to other domains usually triggers windows defender.

        this oneliner is all u need really. it wont trigger anything.

        gci ‘C:\’ -rec -force -include *.jar -ea 0 | foreach {select-string “JndiLookup.class” $_ -ErrorAction SilentlyContinue} | select -exp Path

        1. Kelvin Tegelaar December 16, 2021 at 8:23 pm

          There’s no “fluff” at all, if you have systems with a lot of files or a high IO load, your script will run for ages;

          on 100GB of data:
          My script: 140MS
          your script: 17 minutes and 12 seconds.

          Now extrapolate that to terabytes/petabytes and your will be running for hours or days, and mine still in less than a second, which is the entire point of the script. If you want a Get-childitem version, check out the version by Prejay in the bottom of the blog, his version uses native Windows Robocopy and is still 50% faster than standard get-childitem.

        2. MattD December 18, 2021 at 11:14 am

          I tried this oneliner on all my servers and it took 4 of out 100 SQL servers down, had to kill the script and restart SQL to get it back up.

  1. chris December 14, 2021 at 4:28 pm

    very cool script. I read Java (Log4j) use zip files. Is it posible to search also zip files with select string ?

  2. Wil Kothlow December 14, 2021 at 5:43 pm

    Just a quick FYI for you, I found that line 7 should be “install-service” instead of “install-client-service”. Installing just the client service resulted in a IPC error when calling the search.

    Other than that, thank you for the awesome work you do!

    1. Kelvin Tegelaar December 15, 2021 at 8:27 pm

      Just the client service is enough, if you run the index first, but yeah otherwise you can run install-service instead. 🙂

  3. Matt December 14, 2021 at 8:59 pm

    Thank you much!!

  4. Ryan December 15, 2021 at 9:27 pm

    Just wondering if I might pick your brain about this error I’m getting. Whenever running the script I get an error after Everything opens stating “The term ‘search-everything’ is not recognized'”. What am I missing?

    1. Kelvin Tegelaar December 15, 2021 at 9:42 pm

      That means you don’t have the Search-Everything PowerShell module installed. It tries to download it automatically but especially older PowerShell versions don’t support it. The easiest way to get it supported is upgrading to PowerShell 5.0 🙂

      1. Ryan December 15, 2021 at 10:23 pm

        I appreciate your response and getting back to me so quickly. It’s interesting because PSVersionsTable tells me I have PowerShell 5.0, and I’ve actually manually installed PSEverything. The error persists, it’s quite strange.

        1. RYAN December 16, 2021 at 4:41 pm

          Just wanted to provide an update in case you were wondering. The issue I was having was resolved by updating PowerShell to the latest version, from 5.0 to 5.1. The script runs great now, thank you very much for providing this.

      2. TM December 17, 2021 at 1:30 am

        For those of us who just can’t deploy major PS version changes at short notice on older OSes, PSEverything v1.3.5 supports PS 3.0. I haven’t personally tested with this script, but perhaps worth a try.

  5. Prakash Patil January 1, 2022 at 12:49 am

    i was trying to add a rename-item to rename the jar files to some thing else / but seems like powersehll locks the files in the stored array. Any suggestions?

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.