public-pentesting-reports VS log4shell-tools

You might find https://github.com/juliocesarfort/public-pentesting-reports repository useful if you need to see how reports are generally structured and written.

As for templates, to be honest, I haven't come across many templates floating around. You could look through public pentest reports (https://github.com/juliocesarfort/public-pentesting-reports) and borrow the bits that you prefer and drop them into TCM's template and make it your own.

I know of this site https://redteam.guide/docs/Templates/report_template/ which for me is down but maybe that is temporary, otherwise seek the cached or wayback version. There are also these https://github.com/juliocesarfort/public-pentesting-reports which are pentesting reports but you may find a number that are more about red teaming or have elements of red teaming which you can refer to.

A repository of pentest reports. Writing reports is the most important component of pentesting and redteaming. A pentester who cannot explain what they did, what they found and what the recipient should do to fix their issues is of limited value.

If you're anything like me, examples help tremendously and so: https://github.com/juliocesarfort/public-pentesting-reports

For good examples, look here. I'd do a test with most of the firms on that list.

I'd say don't let yourself be discouraged by GP. Just look into a company before you apply. Many have public reports you could look at or security research they publish, both of which you could use as indicators.

Here's a repo with lots of public audit reports by various companies, you could use that as a starting point: https://github.com/juliocesarfort/public-pentesting-reports

I'm seeing this as well. While the amount of traffic has certainly decreased compared to the first couple of days after the CVE was announced, https://log4shell.tools is still being used by people every day.

e.g. from log4j. Taken from https://log4shell.tools/

I run tests with https://log4shell.tools, and it seems I'm vulnerable on client side, but my server is safe, which makes sense as I compiled the .jar 2 weeks ago with BuildTools as indicated here https://www.spigotmc.org/threads/spigot-security-releases-%E2%80%94-1-8-8%E2%80%931-18.537204/

You're right, but this has always been the trade off with tools like this. You put some trust in the tool's authors and gain some insight in return. Remember the services that tested for Heartbleed (e.g. https://filippo.io/Heartbleed/)? Fairly similar trade-off, but still these tools were widely used.

If you really don't trust me and have some technical know-how, you can self host the service. It's open source: https://github.com/alexbakker/log4shell-tools.

I can't say I'm feeling the same. Still lots of people testing over at https://log4shell.tools almost a week after this vulnerability became widely known. Plenty of people still discovering they're vulnerable as well. I think it's likely that these are just the people who know they're using log4j. If you're running a black box product from a vendor you'll have no clue you're vulnerable until it's too late.

I have a feeling this vulnerability is going to be with us for years. Shameless plug: I built a tool that assists in detecting whether you're vulnerable to this or the previous CVE: https://log4shell.tools. Just enter the JNDI URI it gives you anywhere you suspect it ends up causing a message lookup in log4j. If log4j does so much as a DNS lookup, this tool will tell you about it.

Done! https://github.com/alexbakker/log4shell-tools