Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: Reporting

Getting your message across: Screenshots

Since I’ve finally started doing something with pentestreports.com I thought it was time to write-up some interesting content. Seeing as this one has been bugging me for a while, I thought it would make an interesting starting point. As always, comments are welcomed and encouraged!

Getting the message across in a penetration testing report isn’t always the easiest thing. Explain in 500 words or less, to somebody who may or may not know what TCP is, how you used a forged HTTP request header to inject falsified log requests into their database and perform stored cross-site scripting on administrators… yeah, it’s not easy. So, a picture is worth a thousand words, and we’re going to need to use all the options available to us to convey the issue at hand.

The problem is… people don’t always spend as much time thinking about that picture as they would writing 500 words! and they should! Here’s a few of the screenshot-crimes I’ve seen over the last 10 years or so in technology. These aren’t restricted to Penetration Testing… so should be applicable for any graphical representation!

The lazyboy

Well I guess it gets the message across… but I’m not really sure what that message really is! A screenshot is designed to help get a message across and prove that something was achieved. This kind of screenshot does nothing more than show that you can press a few keys and take a screenshot. Did I perform an XSS in your website, was it reflective? stored? second-order? Who knows…

This screenshot shows nothing.


Is that bigfoot? Nope, it’s hard to see, but that’s actually a screenshot! Crop people… no, don’t think, just crop. At least you’re getting more of the message across than the lazyboy, but you’re not helping yourself here. Make sure that when you take a screenshot everything you NEED to show is in a small area that will be easily visible and readable when the screenshot is cropped. A full screen capture is fine for note taking, but the final version needs to be cropped and annotated if needed.


OMG where do I look first! 3 screenshots layered one on top of the other… does it tell a story? without any annotation or further information then it’s just a jumbled mess of text. This is a perfect candidate for multiple screenshots, or at the very least a few boxes to focus the reader in on the places where the REAL information is!

Side-note: Screenshots of code are mostly a waste of time… copy/paste the effected code and highlight the section effected.

Click Happy

You may think I’ve gone off the deep-end on this one… but I’m afraid not. Some people actually think that photos are a replacement for a good, well-formed screenshot! Sometimes you just can’t avoid a photo, but think carefully. Easy to do badly! Hard to pull off.

Exceptions to this last one are obvious really. Physical security tests/results, or anything that can’t be screenshotted. Just remember, if you can use a screenshot, it’s going to look a whole lot better than a photo.

Note: If you NEED to do photos… don’t use your phone! Buy a digital camera and learn how to use it!


Take time to think out your screenshots. Not only if you need one, but how you can best show the issue(s) and how a reader will view it. The viewer may not have your technical knowledge, and may not know what the issue really is. Make that screenshot count!

Behind enemy lines

I’ve come to realize over the past few weeks that I’ve made a fundamental flaw in how I handle penetration tests. It all started to become clear at the SANS Amsterdam when the topic of arranging Penetration Tests was raised. I’ve never really taken the time to think how the people on the other side of the fence feel. After all, if the people you are dealing with to arrange the tests aren’t the ones who asked for it, then it’s easy to get the wrong idea. After all we as Penetration Testers arrive and ask for information on the environment, security measures and systems and then tear it all apart. Once we’re done we write a nice report to the boss and leave in the knowledge of another job well done. The technical team at the customer though has to then deal with the boss, who now thinks his security team is a joke. Is this the kind of thing you’d want to happen after you leave site and move onto the next test? of course not.


Working together with the security or technical team at a customer may seem like more hassle than it’s worth. However I’d much rather leave site knowing that the security of the customer will be improved and the technical team will know how to accomplish the task. Maybe the technical team will be the ones to suggest a follow-up inspecting in 6 or 12 months just because it wasn’t a negative experience like they had imagined. The technical team of today could be the CTO of tomorrow, and the sour taste we leave behind now could mean our industry crumbles in 10 years time. There is already talk amongst security industry figureheads saying that Penetration tests are pointless. Bruce Schneier post an article on this back in May 2007. Recently Marcus Ranum from Tenable Security also talked openly on the Risky Business podcast about how Penetration tests are ineffective and have a negative impact on employee morale.

I for one will be thinking about how my client feels next time we engage in a penetration test. That’s not to say that I won’t do my job and expose the gaps in security. However when I do, I’ll be working alongside the clients technical team to make sure they know the why and how of the problem as well.