I know that in real life it’s a requirement to write a proof of concept or a report when performing pentesting, and it’s not really a habit of mine.
Is there a specific order to organise the stuff you write?
How do you know what to screenshot or include and what not?
Is there a methodology or some tips to writing reports?
How to get into the habit of taking screenshots and taking organized notes?
Start by screen capturing something important. (enum result? anything trigger ur next step?)
Left a message in the forums says “I am willing to help for this box/challenge”
Friends will ask u some boxes u solved >1 month ago
Yes, you will forget the detail of that box
Use the screen capture to recall ur memory and help them
You will start to capture/write down sth everyone asking/ critical point in ur notes. You will also write it in an organized way if u will read it again.
I hate writing reports, and I’m not organized at all so I would either forget I hacked something or start writing the report and realize I don’t have a screenshot of something and have to go back and do everything all over again.
so when I start doing HTB I forced myself to take better notes
Use cherry tree to take notes of how each machine was hacked. I also have a node for useful linux commands and windows.
try to write a tutorial for machines you hack. read other tutorials and see how they are written, likes/dislikes and try that with your tutorial. write it as you go like if you find a user hash take a screenshot and put it in your report, don’t wait until you root the machine and then write the report.
I also started using notion.so it’s nice if you want to have your notes anywhere and if you want to share them.
When it comes to notetaking stuff I actually do pretty much what ippsec does in his videos (probably like 99% of people) but to the Nth degree.
I also use Cherrytree, and organise notes hierarchically, e.g I have the box name with sub-nodes that, usually, reflect notes, credentials and anything else I consider Interesting. The use of the sub-nodes keeps everything neat. I try and keep the “interesting” things separate from my main set notes as that, eventually, will depict the path I took to root minus all the fluff encountered along the way. That way, when I’m done, I essentially have a full walk-though for reference.
When it comes to what you should note: in this subject area, imo, everything is interesting until you prove that it isn’t and I usually note it as such.
I don’t use screenshots as much as I should - although, to be fair, I think as long as you have the relevant information, be it in a screenshot or text form, that’s all you really need. One thing I didn’t consider: I’d imagine there’s a difference between stuff you notate for yourself and stuff you’d notate for clients in a professional setting. Including things like screenshots is probably good practice for the IRL stuff, as it acts as a visual aid to data you may present, and who doesn’t like a good screenshot?
As for making it into a habit; like with anything, practice makes perfect. We’re creatures of habit, so it should be natural given a bit of time.
At the time, I usually write very quick shorthand notes; enough that I can understand when I look back a few minutes later, but nothing expansive (especially if it’s a new box). When I write-up my boxes fully, I come at it from the perspective of someone who knows nothing about the box, and write each step in order, with a short explanation.
Hi! It’s great that you’re looking to improve your reporting skills in penetration testing. A well-structured report typically includes an executive summary, the scope of testing, your methodology, detailed findings categorized by severity, and recommendations for remediation. It’s also beneficial to include appendices for additional information, like screenshots and logs.
As you conduct your tests, try to document your process continuously by noting steps taken and observations, including potential vulnerabilities. To develop a habit of taking screenshots, set specific intervals or milestones during your testing to pause and capture evidence, or consider using tools that automatically take screenshots based on certain actions.
Familiarizing yourself with common frameworks like OWASP and PTES can guide both your testing and reporting. Lastly, practice by reporting on internal tests or hypothetical scenarios, and seek feedback from peers to refine your approach. By consistently following these practices, you’ll become more comfortable with the reporting process and enhance the quality of your documentation over time. Good luck, and keep practicing!