1-1: Note-taking

There's a lot to be said about how to take good notes, and while I could attempt to get deep into that, for the sake of this project I'll keep it more high level for how I, in particular, like to take notes for these labs.

First, using the word notes here can be misleading if you're thinking of jotting down notes while you're taking a course or listening to a lecture. When I would take lecture notes they would be focused on key takeaways and specific pieces of information I had a feeling I would need to recall later. Those notes also tended to be quite short. The notes on these labs are not those kinds of notes.

Instead I think of the note taking process as I'm doing a lab as more of a log what I'm thinking and doing, with copious screenshots mixed in to provide visual references to come back to (and use in the walkthrough later). I'm already a verbose person and these notes tend to be even more verbose than my average.

A lesson I took from my time working in film was that it it's better to have it and not use it than to need it and not have it.

Philosophy

I err on the side of inclusion. I used to work in film/TV and the philosophy there was it's always better to have more coverage than you think you need, as you can't come back later to get more. That's not as strictly true here, but having to repeat the lab to fix missed notes or screenshots adds a lot of time to the process.

This is most noticeable with screenshots. It wouldn't be incorrect to take screenshots of exactly what you need, already annotated, while preparing a pentest report. In my case, again going to that film background, is to capture the raw information without any modifications at this stage, and only modify it once it's time to prep the walkthrough.

The downside is that this does make for more work in the editing process, but it also allows for more flexibility.

Organization

I think this is an area where there is lots of room for personal preference. For me I currently build out my notes linearly with the progression of the lab, with the minimum top level sections being for the initial reconaissance phase, testing for exploits to gain a foothold, recon on the system once a foothold has been gained, and then the exploitation to escalate privileges.

Within each top level section I liberally split the writing into sub sections with the use of the H3-H6 tags. As an example in the recon/enumeration phase will almost always have subheadings for web network enumeration, enumeration, and directory/host fuzzing. If I find a particular service or app that I need to research, that process will get its own subhead.

For the moment none of the labs I've done have been so massive that a single document wasn't manageable for it, but for larger network labs I forsee splitting them out per host to keep the line count down.

Technical Setup

I prefer to have few dependencies to work with when taking notes. The basic, somewhat tech/platform agnostic, setup is: 1) a text editor that understands markdown; 2) text files stored on disk; 3) a Git repository for change tracking. Plus its backed up both to a remote repo and a separate cloud backup.

I take these notes on my primary machine, not the Kali VM, in order to keep things all in one place and reduce the odds of losing work.

Technical details

• Text editor: I use VSCodium.
  • Plugins: for this setup all I need is the Paste Image extension. I tweaked the settings so that it saves the images into a subdirectory instead of the current working directory.
• Screenshots: Flameshot
• Logging: As a backup I also save all terminal session output. Currently I use Terminator's logging plugin to handle this.

I don't record video of all my sessions currently, but if I did I would use OBS Studio to do it, and editing would be done in DaVinci Resolve.