pen test documentation

This topic contains 44 replies, has 13 voices, and was last updated by  Jamie.R 7 years, 3 months ago.

  • Author
    Posts
  • #7745
     LT72884 
    Participant

    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.

  • #48334
     ZeroOne 
    Participant
  • #48335
     LT72884 
    Participant

    @zeroone wrote:

    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

  • #48336
     cd1zz 
    Participant

    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.

  • #48337
     dynamik 
    Participant

    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.

  • #48338
     cd1zz 
    Participant

    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.

  • #48339
     LT72884 
    Participant

    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

  • #48340
     Jamie.R 
    Participant

    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.

  • #48341
     LT72884 
    Participant

    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

  • #48342
     Triban 
    Participant

    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.

  • #48343
     Jamie.R 
    Participant

    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 ?

  • #48344
     LT72884 
    Participant

    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

  • #48345
     tturner 
    Participant

    @3xban wrote:

    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.

  • #48346
     LT72884 
    Participant

    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

  • #48347
     Jamie.R 
    Participant

    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…

  • #48348
     DataDwarf 
    Participant

    Rescinded
    [s:1ow8vxec]Here is a short blog post from HackaServer that talks about writing a pentest report.

    http://blog.hackaserver.com/howto-complete-a-penetration-test-report-guideline/

    They also have an example report of a pentest against Metasploitable.

    http://blog.hackaserver.com/howto-complete-a-penetration-test-report/[/s:1ow8vxec]

  • #48349
     jjwinter 
    Participant

    Looks like my B.A. in English will have a use someday after all…

  • #48350
     LT72884 
    Participant

    Jamie, how you gonna do the report engine?

    im interested in how that is going to work.

  • #48351
     Jamie.R 
    Participant

    LT72884 its somthing I am working on not sure best way to do it yet was thinking having it as web app so mysql backend with php or somthing GUI. I am trying think best way to do it as I want it to be really flexible and grow as a project that everyone can get involed in.

  • #48352
     tturner 
    Participant

    Jamie.r This is something I’ve been working on for awhile. One of the directions I’m starting to shift more in favor of is using a wiki as the collection point and then populating report with data from the wiki. If you include the ability for team collaboration and a place to upload tool output and then have a way to reference within your reporting engine that has substantial value.

    I’d be happy to talk to you about some of the work I’ve done here if you think it might be helpful. Unfortunately my mechanisms currently are pretty ugly, generate an infopath form, copy and paste into word, customize content and then convert to protected pdf. I know some consultant firms use custom spreadsheets for this and believe it or not get some pretty amazing results out of Excel. I’m moving in a similar direction as you but I think I’m going to implement as a Rails app.

    What I’d really love to see here is some good collaboration tools and proper version control for the report. Also need to consider the sensitivity of the data and storage/encryption needs and how you plan to purge or dispose of the data once no longer needed.

    Also, if you have not looked at http://dradisframework.org/demo.html already I highly suggest you check it out. It may already meet most of your needs.

  • #48353
     Jamie.R 
    Participant

    Cool I have seen dradis before I am still trying do some ground work I know how I want it laid out it just picking the right tools for the job. As far as encryption goes and deleting data this would be down to the person using it.

    I think my plan is to have it so you download it and install it locally that way you are kinder using the tools in your own secure environment. As I say its all still idea in my head really need to get some time sit down draw up some plans of how its all gonna work just trying get some idea from the security community on if it be useful as don’t want spend time and no one uses it.

  • #48354
     tturner 
    Participant

    @datadwarf wrote:

    Here is a short blog post from HackaServer that talks about writing a pentest report.

    http://blog.hackaserver.com/howto-complete-a-penetration-test-report-guideline/

    They also have an example report of a pentest against Metasploitable.

    http://blog.hackaserver.com/howto-complete-a-penetration-test-report/

    Just checked out this sample report and it’s an excellent example…. of what NOT to do. I don’t have time to take the deep dive as I’m getting ready to hit the road, but an executive summary with technical terms is a poor executive summary. Nmap output and other tool output in the report is just bad. That stuff belongs in an appendix, far too much copy and paste here for my liking. I’ll try to take the time to followup on this with more explicit examples and recommendations in the next day or two, but this is NOT a good report.

  • #48355
     Jamie.R 
    Participant

    oh wow that report is shocking

  • #48356
     DataDwarf 
    Participant

    @tturner wrote:

    Just checked out this sample report and it’s an excellent example…. of what NOT to do. I don’t have time to take the deep dive as I’m getting ready to hit the road, but an executive summary with technical terms is a poor executive summary. Nmap output and other tool output in the report is just bad. That stuff belongs in an appendix, far too much copy and paste here for my liking. I’ll try to take the time to followup on this with more explicit examples and recommendations in the next day or two, but this is NOT a good report.

    I didn’t mean to lead anyone astray. This one from Offensive Security may be a better example:

    http://www.offensive-security.com/penetration-testing-sample-report.pdf

    also this paper from SANS on writing a report:

    http://www.sans.org/reading_room/whitepapers/bestprac/writing-penetration-testing-report_33343

  • #48357
     LT72884 
    Participant

    @jamie. i would ue the template or engine for more than just pen testing by the way. As a mechanical engineer, i will be writing reports probably weekly if not daily.

    I think a reporting engine will be awesome for more than just pen test engineers

    as for calaborating, google docs is good at that. there is also a program like google docs but can be ran privatly on a LAN for a business(thought that doesnt help you but still pretty cool)

    @ datadwarf. dude, you didnt lead us astray, just gave some awesome info of what not to do. This forums totally reminds me of a thomas edison style forum. try and try again until you suceed. I have found it is very importatnt to take notes like mr edison as well. if you get a chnace to see some of his writings, you will be impressed. he wrote everything down and i mean everything.

  • #48358
     cyber.spirit 
    Participant

    thanx great resources but u can write ur pentest report in issaf standards

  • #48359
     Jamie.R 
    Participant

    I think doing a report and getting it right is the hardest part of the job as this what the client pays for…

  • #48360
     tturner 
    Participant

    Pimping my own blog at http://sentinel24.com/blog/ where I just made a post on this topic. Plan on doing some more here as I am developing a separate wiki on pentest business issues (including scoping, reporting, insurance, customer relationships, quality management, etc)

    And jamie.R – yes it’s the hardest and the most important. I’ve always heard that the report should take more time than the test itself. It’s not just gathering data and writing a report, what the customer is really paying you for is analysis and interpretation of that data. As I’ve heard @mmurray say, they are paying you for your wisdom. (sorry if I butchered your quote Mike!  ;))

  • #48361
     Jamie.R 
    Participant

    Cool post and like you website

  • #48362
     cyber.spirit 
    Participant

    @datadwarf wrote:

    @tturner wrote:

    Just checked out this sample report and it’s an excellent example…. of what NOT to do. I don’t have time to take the deep dive as I’m getting ready to hit the road, but an executive summary with technical terms is a poor executive summary. Nmap output and other tool output in the report is just bad. That stuff belongs in an appendix, far too much copy and paste here for my liking. I’ll try to take the time to followup on this with more explicit examples and recommendations in the next day or two, but this is NOT a good report.

    I didn’t mean to lead anyone astray. This one from Offensive Security may be a better example:

    http://www.offensive-security.com/penetration-testing-sample-report.pdf

    also this paper from SANS on writing a report:

    http://www.sans.org/reading_room/whitepapers/bestprac/writing-penetration-testing-report_33343

    In Offensive Security they didnt write any info about servers like ip or port scanning result but i always did that in my reports is it wrong?

  • #48363
     tturner 
    Participant

    Most of the time it’s just not necessary. What does it add to the report? If anything, it shows laziness. There may be situations where you need a short snippet of output to help you tell your story but for the most part no it should not be in the report.

  • #48364
     Jamie.R 
    Participant

    Yes I agree dont add stuff that it not helpful to a client giving them a reprot of 450 pages you may think you show value for money but if the contents is not help it come back to bite you

  • #48365
     cyber.spirit 
    Participant

    ok so without those detail we just need to put a story about server’s vulns lol

  • #48366
     tturner 
    Participant

    What I do is I redirect all my tool output to text files and move those into an encrypted archive I retain with the report. We also require full packet capture with a filter set for anything in target scope + tester machine(s). It’s mostly a training aid for IR purposes and IPS/SIEM tuning than anything else. So yes, we are retaining a lot of other data with the report, but the key is, not IN the report.

    And yes cyber.spirit, we are telling a story. Usually the story the client wants us to tell as long as the data supports it.

  • #48367
     sh4d0wmanPP 
    Participant

    Creating a good report is one of the hardest things to do so here is the format I use.

    Executive Summary: Introduction, Summary of Results, Summary of Recommendation, Conclusion
    This part I try to write as clear as possible avoiding most tech speak. I try to add some pictures or graphs that help to explain the issues found and recommended mitigations.

    Project Scope, Rules of Engagement and Methodology
    General information about what is and is not allowed + overview of the system/ip’s we did use to conduct our audit.

    Technical Attack Narrative
    This is written for the tech guys and details any attack we carried out (succes AND failure). Discovery/enumeration is kept basic.

    Vulnerability Mitigation Techniques
    Here we calculate the risk of each vulnerability and they ways it could be mitigated. By calculating the risk we help the company to prioritize the fixes.

    Appendix A – Toolkit
    This lists all tools we have used in the audit.

    Appendix B – Cleanup
    This lists all files that were created and deleted during the test.

    I like to have a video record of my tests and archive them offsite together with a digital copy of the report (encrypted of course). This way we can always show proof of what we have done in case the customer claims any damage or misconduct.

  • #48368
     Jamie.R 
    Participant

    hmm thats intresting a video of what you doing does the client mind you doing that ? Also be intresting to know what software you use ?

  • #48369
     sh4d0wmanPP 
    Participant

    I use Camtasia Studio for this as I run most audits of my Windows box (I have backtrack in VM or just use a SSH connection).

    The client does not mind it but of course I have to store it securely and can not disclose it without their approval. Nothing beats a live demo but a recorded video also makes a lasting impression if it is a spectacular hack 😉

  • #48370
     m0wgli 
    Participant

    @sh4d0wmanpp wrote:

    Technical Attack Narrative
    This is written for the tech guys and details any attack we carried out (succes AND failure). Discovery/enumeration is kept basic.

    I’ve not heard of failed attacks being included in the main body of the report before (although if you are logging everything they will obviously be documented). Is this common practice to actually report on them?

    What is perceived benefit of this to the client? Isn’t the report supposed to highlight what is wrong with the clients security and how they can fix/mitigate it, not point out what they are doing right with their security?

  • #48371
     RoleReversal 
    Participant

    @m0wgli wrote:

    What is perceived benefit of this to the client? Isn’t the report supposed to highlight what is wrong with the clients security and how they can fix/mitigate it, not point out what they are doing right with their security?

    It depends on the client’s motives: most common is to find holes and weaknesses (or management to bash a techie….). But it’s not uncommon for a business (or IT team) to look for validation that their defenses are working as expected.

    In a well defended network a report that states the pentesters couldn’t get in is meaningless in business terms, a report that states they couldn’t get in, but they tried attacks X,Y & Z which the environment withstood has value, from both the ‘look at the benefit we’re providing from the resources utilised for defense’ and a ‘we protect your data against X’.

    It also helps prove the negative of no flaws; did the testers fail because the environment is secure? or because the testing team is incompetent?

    Reports showing holes with mitigations are/can be the most satisfying and impacting to the business, but from the otherside being able to show that you defended against the most common threats is also of value from a business politics aspect.

    There’s always more to a pentest report than missing patches and 0day.

  • #48372
     Jamie.R 
    Participant

    When I write an exec summary I tened to give the business a bit of pat on the back first before I right them a new one so:

    During testing I found that none of you server were vulnerable to x,y,z what is really good but I also found some issue that you may want to address so on

  • #48373
     m0wgli 
    Participant

    @andrew Waite wrote:

    @m0wgli wrote:

    What is perceived benefit of this to the client? Isn’t the report supposed to highlight what is wrong with the clients security and how they can fix/mitigate it, not point out what they are doing right with their security?

    It depends on the client’s motives: most common is to find holes and weaknesses (or management to bash a techie….). But it’s not uncommon for a business (or IT team) to look for validation that their defenses are working as expected.

    Thanks for the informative response. It’s a posistion I’d never really considered till now, and can now clearly see why this would be beneficial.

    What few reports and guides I’ve been able to find to try and learn report writing from, have all focused on the break it/fix it approach.

  • #48374
     sh4d0wmanPP 
    Participant

    I adopted this approach after stumbling over it while researching report writing info. Forgot the source but if I come across it, I’ll post it here. Since then I stuck with it but of course it depends always on what the customer wants.

    It is however a valuable insight if the company has spent time and money on it’s defense. By seeing that some attacks fail because of their previous investment it will also help them obtain the required budget more easy.

  • #48375
     Jamie.R 
    Participant

    You also get a lot of client who want pass things drive you made by trying get you to reduce inpack of issue or remove them all together.

  • #48376
     RoleReversal 
    Participant

    @Jamie.R wrote:

    You also get a lot of client who want pass things drive you made by trying get you to reduce inpack of issue or remove them all together.

    If done correctly I don’t really have a problem with clients asking for modification of results, they know the environment better than you (supposedly), providing they can provide sufficient reasoning to justify the request (for example a mitigation that was outside the scope of the assessment). In which case, the report will specify the original issue/impact rating, the modifications made and why and the name of the person requesting the change.

    Legitimate debates and difference in opinion will end up being reported, any unjustified massaging/hiding of evidence will quickly get forgotten once the requesters name is going to be specified in the report  😉

    From experience it can also be wise to hash and document any reports provided to clients, I’ve once been asked from senior management to justify a finding/recommendation that had been edited by an IT ream to support their business-political viewpoint.

  • #48377
     Jamie.R 
    Participant

    lol thats is crazy them making changes to the report it only come back to hit them.

You must be logged in to reply to this topic.

Copyright ©2019 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.

Sending

Sign in with Caendra

Forgot password?Sign up

Forgot your details?