local-log4j-vuln-scanner VS incidentresponse

The last scanner type is looking for the classes. Carnegie Mellon’s CERTCC released one that is referenced by CISA: https://github.com/CERTCC/CVE-2021-44228_scanner that look for class names and some fingerprints. Then there is a scanner written in Go that checks for the vulnerable class files and their hashes (inside JARs, WARs,EARs, and zips). https://github.com/hillu/local-log4j-vuln-scanner

I have been scanning with https://github.com/hillu/local-log4j-vuln-scanner and that problem was resolved in there.

If you want to scan your system for vulnerable log4j instances, https://github.com/hillu/local-log4j-vuln-scanner has binaries and is constantly updated

We are using this local log4j scanner: https://github.com/hillu/local-log4j-vuln-scanner/

https://github.com/hillu/local-log4j-vuln-scanner - Nope

Log4j may be included in other jars, so a recursive ps scan like https://github.com/hillu/local-log4j-vuln-scanner may come to rescue

The scanner provided by https://github.com/hillu/local-log4j-vuln-scanner gives us the following output when using "/opt/qradar/" as directory.

Use https://github.com/sp4ir/incidentresponse/blob/main/Get-Log4shellVuln.ps1 to find any jars with the JNDI look up.

For now, I've setup two different scanners in PDQ. One of the PDQ example, and one of another I found, and running both to be safe. Here is the 2nd one I'm using, I modified it though so it wasn't trying to write direct to the C drive, as that may fail (but it does have to go to a folder that exists). https://github.com/sp4ir/incidentresponse/blob/35a2faae8512884bcd753f0de3fa1adc6ec326ed/Get-Log4shellVuln.ps1