pen test documentation

[LT72884]

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.

[ZeroOne]

refer http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,5456.msg28488/topicseen,1/

also http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,4295.0/

[LT72884]

refer http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,5456.msg28488/topicseen,1/

also http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,4295.0/

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

[cd1zz]

If this is for a corporate pen test then no, you don't have to walk through using NMAP. They're not paying you for a tutorial on nmap. They want to know where their risk is by way of exploitation and gaining access to sensitive information etc.

There should be something in your report in regards to scanning/discovery/enumeration but simply listing the targets and ports will suffice. However, when you get to the exploitation part of the report,  you should walk through your steps. This may be a chained set of attacks that got you domain admin or got you access to their databases etc... Remember, the client is paying you for that part of the report, not a list of hosts and open ports. You're supposed to be the expert in exploitation, not them.

[ajohnson]

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.

[cd1zz]

I agree. In my experience, the ability to "tell the story" of total domination often helps the client understand why a medium vuln should be taken seriously for example. Totally depends on the situation but that works for me.

[LT72884]

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

[Jamie.R]

Hmm in all the pen test I have done I have never explained how the tools works I dont see that as part of the job. I am there to identify an issue and advise them on that issue not to teach them how to use the tools.

I think doing so could lead to problems where client will say oh I get how they done that I dont need to pay x amount for a pentest I can do it myself.

If they trying to recreate the issue they can call me and I can help.

[LT72884]

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

[3xban]

You will want to start off the report with an executive summary.  Don't go too flashy.  It should cover a brief overview of the scope and objective of the test, the summary of the vulnerable systems using like a heat map or something.  Again, nothing too detailed.  Then the outcome of the test.  What were you able to do.  Then you can move to the details as to how you accomplished the goals.  The CIO types will want to be able to read the first 2-3 pages and understand how at risk they are.  The technical guys like myself, will want to know how you did it and how we prevent it from happening again.

[Jamie.R]

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 ?

[LT72884]

Thanks for the info on the executive summery. My problem is i am a very detailed write so flashy is my type. Now to learn how not to be flashy in the right moments.

@jamie.

That would be awesome. I have downloaded so many pdf's on how to write a technical report, it aint funny. haha. It seems that apa style is the norm.

you could have a wiki page or google docs that only certain people can edit.

for standard sakes i think apa is great. but my biggest concern i have seen is un-organized screen shots of attacks and command line stuff.

In my mechanical engineering class, we were taught "that in order to make your ceo happy, show lots of organized pictures. big bosses in business love pictures. they are pretty and fun to look at. Makes you feel special" so i think there should be a standard of how a body of pictures should be placed in the report AND easy to understand. IE proper names of x and y axis on graphs. I have seen some pen test reports where the x axis was the percentage but the y axis was just numbers from 0 - 20 with no title so people had no idea what the 75% at 11 ment. Was it that 11 of the scans showed 75% high risk or was it that it found 11 high risk cases and that that made up 75% of the total?

The hardest part, every professional out there including you and i, think we are the best at writing a report. So colaberating and effectivly communicating our ideas without stepping on toes, thats the hard part... oh and my spelling sux. haha

[tturner]

You will want to start off the report with an executive summary.  Don't go too flashy.  It should cover a brief overview of the scope and objective of the test, the summary of the vulnerable systems using like a heat map or something.  Again, nothing too detailed.  Then the outcome of the test.  What were you able to do.  Then you can move to the details as to how you accomplished the goals.  The CIO types will want to be able to read the first 2-3 pages and understand how at risk they are.  The technical guys like myself, will want to know how you did it and how we prevent it from happening again.

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.

[LT72884]

that four letter word LAZY is the death of a lot of things in the business/work field. I am very guilty of this at times.  I struggle with not getting bord. I have to be active all the time. i can focus like mad but i get stuff done and if it bores me, then i dont want to do it. hhaha.

awesome info above. thanks for htat

[Jamie.R]

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...