Have removed any trace of .jar according to the proof column, searched and verified it several times in endpoint, no trace found.
Despite all of this, it still shows up as having a vulnerability.
Seems to be doing this a lot.
Anyone else having similar issues. Kindly guide me thanks.
The ‘Proof’ will show exactly why it was flagged, after it was fixed, and your still getting it, what does the proof show now?
It still shows the same results, despite performing a manual scan.
It mentions the file residing in the recycle bin, which we have searched manually, its not a hidden file as well.
Have you tried throwing out the trash in the recycle bin. Log4J is such a bad vuln, that its still considered vulnerable even in the recycle bin as it could easily be restored from there.
You most likely need LAPS credentials to log into the machine. After that it will be visible in the recycle bin. Another test you can run is the orphan test, remove the device from rapid7 (Use the garbage can symbol) then pick it up in discovery and re-scan to get a fresh look. Sometimes rapid7 orphans’ vulnerabilities, meaning it was picked up at one point in a device’s lifetime, and for whatever reason it has gotten left behind.
I have done this and rechecked.
Yet it still exist according to proof column.
Yeap i have deleted the asset which resulted with zero vulnerabilities shown.
While it seems this has solved the problem, i have now notice, every day it scans it reflect with zero vulnerabilities, when before this it had 5 which were not related to log4j. And those vulnerabilities have not been patched.
I have raised a ticket with support. Let see how it goes.
Hi esingh, is there any information about this issue, did you get a response from rapid7 support?
Best regards
Have you run a full authenticated scan on the asset to see if the 5 vulnerabilities re-appear ? There are certain vulnerabilities that will only show following an authenticated scan such as insecure ciphers. I had the same problem regarding obsolete log4j.jar files but I wasn’t willing to remove the asset from the platform and lose historical data. I was just about to get round to running the orphaned script when it just disappeared from view the weekend before. Never did get to the bottom it.
I know this is an old case, but perhaps it can help other users. If you encounter these vulnerabilities in the recycle bin, even though the recycle bin appears empty, simply run rd /s c:$Recycle.Bin in an elevated command prompt, replacing the drive letter as needed for each affected drive.
In our environment, I regularly have to create tickets for the responsible asset owners to clear their recycle bins and provide them with this information. Most of them needed to delete the bin on drive d:.