when documenting your findings for a pen test, is it a good idea to briefly explain what the tool is doing and the basics of how it works? For example should i state why nmap found what it found and how it does that? Here is a small excerpt from my documentation as i scan the de-ice disk.

-----------------

Output and displays of various mapping tools used against targets 192.168.1.100 and 1.110:

First tool used is ping:

root@bt:~# ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
^C
--- 192.168.1.100 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7026ms

root@bt:~# ping 192.168.1.110
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
^C
--- 192.168.1.100 ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 7084ms

As you can see, no targets were identified. Either they are un-responsive to ICMP requests or they are physically down. I assume the first. For more information on ICMP, please refer to the man pages.

Next i will use a series of namp switches to see what information i can pull from the target. Nmap by default(nmap x.x.x.x) will create a tcp connection to open ports and establish the 3 way handshake which is very detectable by firewalls and IDS's. Imagine your a firewall, and all of a sudden, 8 ports on your machine just had a complete tcp connection on them. wouldnt you be suspicious? hmm? Thats where stealth scans come in. more on this later:

root@bt:~# nmap 192.168.1.100 (nmap -sT 192.168.1.100 does the exact same method)

Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-08-01 17:57 EDT
Nmap scan report for 192.168.1.100
Host is up (0.00027s latency).
Not shown: 992 filtered ports
PORT    STATE  SERVICE
20/tcp  closed ftp-data
21/tcp  open   ftp
22/tcp  open   ssh
25/tcp  closed smtp
80/tcp  open   http
110/tcp open   pop3
143/tcp open   imap
443/tcp closed https
MAC Address: 00:0C:29:9A:56:D7 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 17.73 seconds

As you can see, the target has 6 or so ports open. Why is this important you say? Well, think of it this way, you just made a CONNECTION using tcp to an oen port... What happens if you know a username and a possible passwod???

Using the ping sweep switch -sP will send a ICMP packet and a TCP syn packet to the system as well since most targets are set up to drop ICMP:

Thats just my documentation of the hands on portion. i will be suing this info for a final report. Am i supposed to explain what the commands are doing and why in the final report?

thanks guys so much for the last few weeks of help and answers.

first one has a dead link in it and it looked like a good read. haha. I have read the other ones before but i did not find what i was looking for.  I know the format using APA and what not. im just wondering if im supposed to explain what i did as if i was talking to a begineer in the networking world.

ill read the second links agan and see if i an find some more info.

thanks

Matt

I'll tailor my reports to the client. Just in the last few weeks, my tests have ranged from networks consisting of a couple VLANs to 135. The technical knowledge of my contacts will obviously range significantly as well.

If I feel that a lot of the concepts are foreign to them, I'll mention the tool I used and add a couple sentences on how it generally works. I'm not going to write paragraphs on how something like nmap works though. Like cd1zz said, that's not the point of the engagement. I want to make sure they're able to understand and adequately follow along with how the attack progressed, but I'm not providing training documentation. I'll gladly take follow-up calls/emails if something isn't clear, but it's not worthwhile or feasible to put in that level of detail up-front.

On the other hand, sometimes my contact will check-in halfway through the engagement, and when he finds that I was able to exploit some obscure service, he gets excited and says he's going to go try it himself. I don't do any hand-holding on those reports. I'm not going to waste my time adding unnecessary information, and I'm not going to waste his time by having him read it. I'll just cut to the chase on those.

PERFECT. ok thats what i was thinking. The above was originally going to be from my hands on exp portion as i follow along the movie for my actual pen test.

But after reading my notes, i felt like it was a tutorial rather than an actual document.

I have actually never written a technical report for anything haha so this will be new to me.

However, i can use part of the notes i ahve for the final report i bet.

thansk guys

yeah i didnt think about that part. haha. yeah i have decideto use hose as my notes for research and then actually write a completly different report for the pen test. i figure in order for me to learn, i must document how the tools work for my sake and then perform te test and document the findings in a real report.

thanks

ok on this subject I had idea for kinder security tool just wanted to get some feedback.

I was thinking of making an open source report enging for the security community of course people can get involved with it.

The plan is to have a reporting engine where professional can make entry for everyone to use this would be great for OSCP and other course where you need to write reports but also small pen testing companies that are currently using word.

The idea is to try and get a good standard so reprots looks professional.

What do people think is it good idea ? or do you see problems ? what technology would you use ?

I will agree with this but the executive summary is the LAST part you write, even if it comes first. In a recent report writing course I took at BsidesLV with Mike Murray and Josh Sokoly it was recommended to make things a bit more granular with CEO executive summary on page 1, page 2 and 3 targeted at Technology executives like CIO and CISO, then technical mgmt and lastly the IT Ops guys actually fixing things. They actually suggested those heat maps on page 2-3. They also suggested keeping the report as short as possible and expending a lot of effort in reducing the word count. Much of the data we find in reports like scans, and tool output really belongs in an appendix or possibly an archive attachment external to the report.

Avoid technical terms on that first page and try to address things like meta-issues over specific vulnerabilities. ("There does not appear to be a standard process for updating system files" vs 5 pages of "server x was missing patch ms08-067") Also try to identify impacts a CEO might care about like shareholder value, SEC reportable findings, findings that might carry compliance fines, brand damage, etc.

Also on the topic of using templates for this, I've created Infopath forms for my own report needs for common findings and recommendations but you need to be really careful here because it's easy to get lazy. Make sure you take the time to document the specifics around the finding and determine if your canned recommendation makes sense within the context of the system environment in question. For instance, I might recommend AV on a Linux box that hosts a Samba share for Windows clients, but not on another Linux server that has iptables configured in such a way that only other Linux servers are communicating, has no access to internet or any other client facing technologies.

The structure I tened to follow is this:

Exec summary - Bit bout the job, bighest issue found, Fixes for biggest issue and conclusion


Scope of work - What was covered and not covered

Issue found - Title, Description, Port number,Ip address, and Impact

Issue impact - What could this cause if exploited

Issue Recommendation - How to fix it with maybe useful links to OWASP

FInal conclusion - Explain how to fix all the issue and a time frame when they should be done.

all my reprots pretty much following this method be only happy to help more if you need it...