Report Writing 101: Notes
Write, right?
Hello all. We are once again exploring the wonderful world of report writing.
Before You Read
It is recommended to read these related posts before reading this one, so that you don’t get lost during the discussion of the concepts:
What
We’ve already discussed scope, and the next part of a report is doing the actual report. That could be another post for another time, but a big part of doing a report is recording your progress.
Odds are, if you’re in the infosec/IT field, the company you work for has a ticket system. If you don’t know what a ticket system is, it’s essentially a large database that contains issues and projects and their progress tracking which are dubbed “tickets”.
In the previous post’s project, the “Freaky Foresters Lightbulb Thingy”, there would presumably be a ticket for it. In the ticket would be the scope and you would presumably be in charge of creating the tickets for the issues you find within the project. If you aren’t directly responsible, you at least will have the details among the process of how to reproduce the issue.
Keep in mind the format of all of this is from the viewpoint of a red-teamer. If you’re a software engineer or something of the sort, you probably won’t be trying to break a program and your reports will be more based on what you’ve created, rather than what you’ve destroyed. Penetration testers, exploit developers, and generalized infosec may get more out of this post than others.
Anyways, you should definitely be writing down notes on:
What problem you found (what?)
What the severity of the problem is and what detrimental effects can come of it (why?)
If applicable, where the issue is located; e.g. what file(s), segment(s), server(s) (where?)
How to reproduce the issue (how?)
Feasibility of reproduction (who? Just kidding, there’s no who)
If you think about it, this is awfully similar to Quality Assurance (QA) testing; at least, in the case of red-teaming. I don’t think QA team members are trying to reverse engineer programs.
Why
Be honest, you can’t remember every single detail on your assessment. If you can do that without writing anything down, I’ll be very impressed with that feat. But, you can’t.
The notes you take while doing an assessment lead into ticket writing, but I’ll save tickets for part 3 of this report writing series.
How
There are 2 “methods” to recording the material for a report.
You can either:
Create your tickets as you go through your scope in the assessment. OR
Create all of your tickets at the end of the assessment while you write your report summary.
I opt for the second option. This is mostly because I’m lazy, but also because it’s hard to stop what you’re doing and shift gears to write up an issue. The difficult part about going with the second option is that you have to take really good notes as you do the assessment. Let me tell you that it sucks having to rewrite a program solely because you forgot how you performed a hack/exploit on a program. You don’t want to do that, especially if you’re pressed for time at the end of the dedicated assessment time. That would be hard to explain to your boss.
From my experience, there are a couple of ways to take notes.
The Text File
Yep, we’re going old school, new (2).txt style. I do this towards the beginning of my assessment, especially when I run through a program “as-is” without any modifications or exploits running; basically in QA mode.
This is where you can toss some new or corollary ideas alongside your scope. I often write up my scope during this process too, but thinking ahead will prompt a few attack ideas to add to the scope sections.
OneNote
I don’t use this, but some of my team members do. OneNote syncs up your notes into OneDrive in case you end up having to use multiple devices and need to access your notes. We have 3 different machines provided to us for work (laptop, desktop, and tablet), so something like OneNote is super useful.
Your Code
Yep, comments are for more than just explaining what code is doing. This is my preferred note-taking method. I usually have my hack/exploit in one big file and order it from top to bottom. By order, I mean my exploit attempts are chronologically ordered from top to bottom. This can be flawed if you append to an earlier code segment with some additional features as that might throw off the original reproduction process.
Excel/Google Sheet
Excel sheets are very useful for notes, especially if you’re good at formatting and colors and all that extra stuff. I do this towards the end the assessment when I’m summing everything up.
Substack doesn’t like formatting Excel sheets so I’ll try my best to explain what I write in them.
Essentially, this is where I place dangerous/manipulatable functions, unprotected/unobfuscated structures and their fields, logic errors, malicious Remote Procedure Calls (RPCs), and anything else that is both significant and can be organized into an Excel sheet.
Alongside these entries I also place columns for a severity reading and reproduction feasibility. I also put a section for notes/comments as well in case there’s some extra information that needs to be passed along.
Conditional formatting is a great addition, especially in the severity and reproduction columns. If you’re able to, adding a nice Excel table into a ticket or series of tickets is a nice touch. Your boss will love it!
The TLDR of this post is basically don’t forget how you broke something. It’s pretty important. You’re a QA tester on steroids, so make sure your blue team knows about how poorly their code was written. It’s a fun thing to show them up about.
Thanks for reading, as always.
Go!
-BowTiedCrawfish