Reporting For Pentesters

Source: Antisyphon Training

Bonus: Try reporting templates by Julio on Github.

I. Facts and Opinions in Analysis

What is a fact?

• Something that is objectively true
• Something that has actually happened
• Something with a verifiable existence

Which is better?

• “The file shares had weak permissions”
  • “The file share at //fs01 allowed any authenticated user to read and write files to it.”
• “The server was running an unsupported version of Nginx”
  • “The HTTP response headers indicated an unsupported version of Nginx.”

Facts first

• Make it obvious which systems or components were involved and when.
  • Timestamp, hostname, source IP, target IP, current username, current privilege level, URL, parameter name, HTTP method etc.
• If an action was detected, blocked, or otherwise interfered with, say so.
  • State it when your customer is doing something right. Help them keep doing it!
• Always validate the answers that you are uncertain of.
  • Does “cache-control:no-cache” mean the user agent won’t cache? (spoiler: the response can be stored in cache!)

Expert analysis second!

• “The “Domain Users” group should not have write permission on network file shares” (says who?)
  • “Overly-permissive file share permissions can present an attack vector”
• “This old web server needs to be patched” (says who?)
  • “Outdated systems pose greater risk because they are more likely to include publicly-known vulnerabilities that a low-skilled attacker can exploit.”

Beware of using passive recommendations!

• It is recommended that SSLv3 be disabled.
  • PCI-DSS prohibits use of SSLv3.
• It is recommended to upgrade to the current version
  • The vendor recommends upgrading to the current version.
• It is recommended to disable SMBv1
  • Microsoft has recommended disabling SMBv1 since 2016.

II. Screenshot Rule

• Establish facts by including screenshots - “Pics or it didn’t happen”
• Use screenshots as if you are defending this evidence in court.
• Add plain boxes and arrows to direct attention.
• Keep text in screenshot about the same size as text around it.

III. Text Rule

• Add color or bold or highlighting - something to direct attention
• Use a different font than the report’s body text so it stands out

IV. Clarity

Audience = Your Readers

• Never lose sight of who your audience is.
  • Technical users: These are the people who will be fixing the problems you report. Assume they want to learn a little about how you do your thing and instead let them know how to fix it.
  • Management/business users: These people decide whether to hire you again. They need to know how the technical stuff affects the business and which managerial levers they can leverage on to help.
    • Is it a technical fix like installing software updates regularly?
    • Is it a policy or process fix like strengthening password requirements?
    • Is it a system baseline fix like changing weak defaults?
    • Is it a personnel fix like training in secure development or resisting phishing?

Strategic Guidance

• It is recommended [says who?] that the organization carefully manage the membership of the local administrators group and avoid adding domain users to this group unless absolutely necessary [what would be a good justification for doing it?]. Routine audits of local administrator groups should also be performed [who should do that? Passive voice can be a no no.].