Keeping notes during a pentest/security assessment/code review

June 13, 2018 No comments

Keeping notes is one of the key aspects of penetration testing. In this article I’m going to share some information on how I keep notes during a test.

I personally use vim to keep notes. It’s easy and it works for me. The important part is to find a tool that makes you as efficient as possible. It could be Evernote, OneNote, emacs…

You will see a lot of {{ and }} in the content. It’s due to the usage of vim folding:

set foldmethod=marker
set foldmarker={{,}}

I keep all my notes in a file named NOTES. So I end up having one directory per test, with all my notes in the same format. This allows me to do things like:

$ find . -name NOTES -exec grep 'weird bug' {} \;

to find all the pentests with a ‘weird bug’. It’s really handy when you forgot about what test you found a weird behaviour in Weblogic for example…
Having notes in a text file allow you to use all your favorite tools and even use Version Controls Systems.

I obviously don’t recreate the file from scratch every time, I have a template that I just copy over every time I start a new test.

The template is only one file composed of the following (I splat it in multiple section for clarity):

                           Project’s name
Start date: XX/XX/XXXX
Finish date: XX/XX/XXXX

It’s always handy to know what IP address you were attacking from or the DNS servers you were using. That’s why I try to keep as much network related information as possible:

{{ Network information
{{ Day1
$ifconfig
[...]
$ cat /etc/resolv.conf
[...]
$ route -n
[...]
}}
}}

If you spend your time looking up emails or asking the client/PM: “What was the password again?”, you’re wasting time. That’s why you should keep this information in hand:

{{ Info/Credentials
- Application1
test/test123
admin/password
- Application2
[still waiting]
}}

Sometime, you have ideas that you can’t explore right now, that’s why I always keep them in a list:

{{ Todos
- double check for XSS in the login form in Application2
- weird behaviour in Application1 /showUser.jsp?id=1'
}}

Finally, the list of issues, with as much details as possible and key information:

  • authenticated vs unauthenticated
  • screenshot
  • URL
  • …
{{ Issues
[ ] Login form over HTTP for Application1
{{
 ...
}}
[ ] Cookies without Secure flag
{{
}}

[ ] SQL injection in Application2
{{
http://application2.client/index.do?id=1' union select 1,2,3,@@version
screenshot -> application2_sqli_version.png
pre-auth
}}
}}

The little box near the issue’s tittle is used to know the state of the issue:

  • [ ]: new. The issue has not been communicated.
  • [-]: communicated. The issue has been communicated to the client/project/…
  • [X]: reported. The issue is in the report.

Keeping clear notes will increase your productivity and the quality of your work. You will know exactly where to look for information and gain velocity.

If two testers have the same skill set, the fastest will find more bugs over the same period of time…

Finally, it’s likely that keeping precise notes will help you during meeting to answer questions or provide more details on an issue.

Keeping notes during a pentest/security assessment/code review was originally published in PentesterLab on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source

https://blog.pentesterlab.com/keeping-notes-during-a-pentest-security-assessment-code-review-7e6db8091a66