Pentester Admin – How to Plan & Track Tests

This topic contains 3 replies, has 4 voices, and was last updated by  impelse 5 years, 2 months ago.

  • Author
    Posts
  • #8727
     lexuscan 
    Participant

    Hello All,

    I have been searching around but have not found some good answers. Basically I was wanting to know about the how pentesters organize their work while at an engagement. Note that I am not asking what a pentesting is on a technical level, or how to use burp, or even about the stages, or phases of attacks [reconnaissance, Enumeration, …, … covering tracks]. Basically I would like to get inputs from pentesters that have different methodologies to perform the test in a timely manner. How do testers ensure that they are not missing things out or retesting what has already been tested?

    What I am interested in is: how much preparation is required before starting the actual testing? Do testers sit for a few minutes before and go: “right, there are 20 pages and 100 input fields. What I am going to tackle first?”, or something like “okay, I have a list of 21 attacking vectors I want to test against; I’ll start with A, B and then move to C”, or is it more like “meh, there are something like 21 attacking vectors, I’ll start with the ones that come to mind first and then will take note as I go along”?

    Also, during a pentest, what does the tester do to keep track what has been tested, what needs tested, evidence gathering and correlation. How do they tackle all the ideas and keep them organized? Do they use just a One Note and paste everything in there.

  • #53896
     azmatt 
    Participant

    Some great questions there. I can’t speak to a lot of them but on the tracking front I know Dradis is a popular option.

  • #53897
     dynamik 
    Participant

    @lexuscan wrote:

    How do testers ensure that they are not missing things out or retesting what has already been tested?

    I think you would have to be *really* disorganized to start retesting things you’ve already done. It’s also very rare for you to be given time to inspect every service on every system. Things are going to be missed unless you have an extremely tiny scope or have been given a ridiculous amount of time. A better question is how to be the most efficient, so you can make the best use of your time.

    @lexuscan wrote:

    how much preparation is required before starting the actual testing? Do testers sit for a few minutes before and go: “right, there are 20 pages and 100 input fields. What I am going to tackle first?”, or something like “okay, I have a list of 21 attacking vectors I want to test against; I’ll start with A, B and then move to C”, or is it more like “meh, there are something like 21 attacking vectors, I’ll start with the ones that come to mind first and then will take note as I go along”?

    Recon / info gathering is part of the test, which you start immediately. Are you asking about exploitation? i.e. how much do you learn before you move forward?

    I think a lot of the answers to these questions are going to vary based on personal experience and intuition. I typically follow a path as soon as I discover it and pick up where I left off if it doesn’t pan out. Additionally, you can have scans, etc. running in the background while you’re manually looking at something. It’s a huge waste to do something like wait for a large scan to finish before you start diving into it yourself.

    It’s going to vary based on the engagement as well. Maybe you’re doing an external engagement and know you’ll be encountering a lot of web servers. Do a quick scan across the ranges for only 80 and 443, then do a larger scan that includes thousands of ports, all the fancy script checks, etc. while you’re manually reviewing the websites.

    It’d be rare for your system to legitimately need to be sitting idle a majority of the time. You can also start with a scan of 21, 22, and 23, and have hydra or something doing password guessing while you’re onto something else. You may come back to valid credentials when you’re done with whatever else you were working on.

    I typically spend the majority of my time on post-exploitation activities, so the sooner I can establish a foothold and start digging deeper, the better. These aren’t vulnerability assessments, and it’s not my job to comprehensively identify and verify vulnerabilities across the network. I strive for as much breadth as time allows, but I’m really there to demonstrate the overall impact of their security deficiencies. That might be gaining access to sensitive information, obtaining domain admin privileges, etc. I’m not going to set the main objective aside just to validate a large number of miscellaneous vulnerabilities that have little-to-no-chance of leading anywhere substantial.

    @lexuscan wrote:

    Also, during a pentest, what does the tester do to keep track what has been tested, what needs tested, evidence gathering and correlation. How do they tackle all the ideas and keep them organized? Do they use just a One Note and paste everything in there.

    Again, this is going to vary a lot just based on personal preferences. I’d just try different things until you find what works for you. A guy I really respect is an absolute ninja with Emacs’ Org Mode and probably the most organized person I’ve ever seen.

    I typically paste windowed screenshots directly into the Word document, possibly pasting into GIMP first to do any obfuscation or other edits. I’ll just save them off separately if I know they’re only for evidence and won’t be reported on. I do the same thing for text output. I get what I think will be relevant for the report into Word and leave full text files in my evidence archive.

    I try to get as much into the report as I go though. It’s really tedious to try to sort back through everything after the end of the engagement. What’s easier, going through 300 pages of MSF logs to find the few lines you want to show, or just copy/pasting the text while it’s in front of you?

    Try to save as much as you can as a fail-safe in case you miss something. For example, you can use the script command in terminal, log within screen, MSF’s spool command, and so on. PCAPs are handy since you can retrieve an enormous amount of information from them (and having them is a good CYA policy in case you get blamed for something you didn’t do).

    Experience helps here too. After writing a large number of reports, you have a pretty good idea what you want to keep and what you should just keep in the evidence archive in case anyone questions your findings at a later date. You also find your groove and write scripts and little tools to help you sort and organize your information. For example, I wrote a short script that’ll create greppable Nessus output from the Nessus XML files (like NMap’s gnmap files). I might decide to focus on a certain group of vulnerabilities, then grep -v them from my working file, and repeat until the working file is empty.

    I know people that work exclusively with text files, general note-taking software Evernote/One Note, and specialized pentesting apps (Dradis, Lair). I personally use text files and Word. If it’s a team engagement, I’ll just throw up a new MediaWiki install. Spend some time experimenting with the various options that are available and see what works for you.

  • #53898
     impelse 
    Participant

    Good dynamic.

    I prefer to focus in one target at the time (sure I am scanning for other targets at the same time). Check all the possible open ports and trying to get more info each time you scan and rescan and then more enumeration – If you notice I repeat a lot the process of enumeration, after you get the info then you can plan your surface attack (preferable the easies first).

    With the documentation I have two at once:

    One document by target and with the scan reports and a lot of info about that target.

    A second document with the vulnerability I found and the screenshots, the screenshot is the option of the attack and result, at the same time I copied the options of the exploit and result and pasted in the document, why two times because some IT techs wants to run the exploit themselves.

    How I avoid to miss some details? Read my own documents and recheck the scan results, sometimes with different tools, takes time and some time you think that it is too much info to check but then when you are writing the final report you feel that you missed more data, LOL

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?