Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

What order do typical open-source penetration tests operate? Which tools are run first, second, third -- and how do you control them?

Does one simply use Metasploit RC files? A network vulnerability scanner in a special way? A command-line, custom, or headless web application security scanner?

Any other ways (or even ideas) to speed up penetration-tests that you would be willing to share?

Are there open-source projects to help with this process (besides Metasploit RC files or the `save' command under the MSF console)?

share|improve this question

put on hold as off-topic by Jens Erat, raz, Iszi, Xander, Eric G yesterday

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

5 Answers 5

I have a few anecdotes I’d like to share pertaining to the “A network vulnerability scanner in a special way?” question above.

Before jumping in though I’d like to note that for most scanning tools speed is the antithesis of accuracy. Speed kills.

speed kills

Port scanning:

Tweaking nmap for balls out speed (a la –min-hostgroup, --min-parallelism, and friends) is awesome for watching the packet counters on iptraf go blurry, but you can be assured accuracy will suffer.

My typical hedge on going fast is to run multiple rounds of nmap scans: Preferably on different days and at different times. This helps to minimize accuracy-killing hazards like scheduled backups that saturate bandwidth.

For really big scans try unicornscan. It has been awhile, but I took notes that last time I did a respectably large Internet based port scan:

To recap: We performed a sweep of 400,000+ public IPs across multiple continents by configuring the scans to do a full TCP port scan of each IP, sustained ~55 Mbits/s using between 3 and 5 systems, and completed it in a matter of days.

This is pretty good considering by sending two SYN probes per port it meant sending ~52.5 billion packets and producing some 3 Terabytes of data.

Vulnerability scanning:

This may not be true so much today, but a few years back popular commercial vuln. scanners would optimize their scans out of the box for speed. Marketing and sales pushed for it because customers tie quality to how fast they get scan results.

So as a vendor (disclosure: I used to work for one) the game was to reduce the number of checks in favor of speed. Full TCP or UDP scans? No way. Individual vulnerability checks that take time? Bury them.

You can see where this is going - if you want accuracy then spend a few minutes and customize your preferred vulnerability scanner(s) for accuracy (and coverage). If you want speed then know you are sacrificing those properties.

Combining the above:

I’m bored with how often port scan results differ from tool to tool on the same engagements. I hate it when I pay for a per IP vulnerability scan (e.g. Qualys) and the tool repeatedly misses open ports that I verified to be open. I like to take the results from my port scans (see above) and customize every vulnerability scan tool I’m using to only hit those ports my custom scans discovered to be open. This can save TONs of time.

Cloud boosting:

For Internet based scans I now almost exclusively use cloud VMs. My favorite is linode.com. Linode’s AUP so far doesn’t forbid port scanning (Amazon’s does). Spinning up 30 VMs to distribute scanning efforts across non-regional data centers can put the fun back into port scanning. It’s easier to get aggressive with tuning as well given the favorable latency and bandwidth conditions. My point here is cloud VMs are awesome for boosting scanning capacity.

share|improve this answer
    
I use iftop instead of iptraf. Which is better? As for 'Re:per-IP vuln scans', I think that identifying reliable open ports and what's running on them (what specific app version in a specific environment) is extremely important, and then run OpenVAS/Nessus on the specific vulns on that specific port that you think that they affect. You forgot to mention how you do brute-forcing! –  atdre Nov 18 '10 at 10:32
1  
All great information, but I don't see where you actually hit on automation. –  Ormis Apr 11 '11 at 13:49
    
@Ormis as i mentioned in my first sentence, i was attempting to add value around dre's "A network vulnerability scanner in a special way?" part of the question. actually, my answer is probably the opposite of automation, it mostly implies more human work :) –  Tate Hansen Apr 11 '11 at 14:00

Try SET from Social-Engineer.org. Whole site is a great resource.

share|improve this answer
    
Very nice comment, I knew about SET but not this wiki page! –  atdre Nov 17 '10 at 22:52
    
Need to work on my set_config skills! Any updates on using SET or similar tools? What is new and innovative in this space? –  atdre yesterday

Some thoughts I had while reading this question...

Penetration Testing is very dependent on the circumstances. Yes, there are automated tools, but even if they help, they cannot do everything. From my experience, automation gets in the way unless applied to a specific step in the pen-testing/auditing process.

I actually just got interested in OpenVAS. It's not technically a penetration-testing tool, but it's very helpful with reconnaissance. And if you look it up, keep in mind that a new version (3.2.3) released this morning.

This isn't open source, but another tool to investigate is CoreInsight. I'm in the process of getting a chance to play with it and, though i understand that it won't have the maneuverability of Core Impact, it should be a very interesting and helpful tool.

Though i have my doubts about automation in pen-test, i'm interested in what others have to say.... (+1 to you, sir)

share|improve this answer
1  
Huh. Core Insight fell off my radar, or I didn't know about it (obviously know about Core Impact). It appears that Trustwave wants to get into this product space with their PenTest Manager as well -- hostingpublicity.com/2011/03/… –  atdre Apr 11 '11 at 17:52
    
@atdre that's interesting, i'll have to look more into trustwave's pen testing application, especially if there's a scheduler built in. –  Ormis Apr 11 '11 at 20:01
    
@atdre actually, it seems that product is simply a dynamic deliverable from their external auditors/tests.... That's what i got out of a quick glance, I'll look into it later too. Thanks for the lead. –  Ormis Apr 11 '11 at 20:07

If you need to bruteforce a website and act like a real browser with javascript you could write a couple of lines in http://zombie.labnotes.org/. I used it for user-enumeration, wordlist-generation out of userinfos and bruteforcing at the same time.

var zombie = require("zombie"); var assert = require("assert");

// Load the page from localhost zombie.visit("http://localhost:3000/", function (err, browser, status) {

  // Fill email, password and submit form   browser.
    fill("email", "zombie@underworld.dead").
    fill("password", "eat-the-living").
    pressButton("Sign Me Up!", function(err, browser, status) {

      // Form submitted, new page loaded.
      assert.equal(browser.text("title"), "Welcome To Brains Depot");

    })

});

Without the Javascript-feature i use ruby - mechanize.

share|improve this answer
    
This looks really cool! It's probably an excellent way to defeat Roboo -- ecl-labs.org/2011/03/17/roboo-http-mitigator.html –  atdre Apr 11 '11 at 17:57

The Metasploit Framework is my go-to tool for pentest automation still to this day, however, I do like what I've seen of CORE INSIGHT and Immunity Security SWARM. There are a few tools such as mana-toolkit and Responder.py that must be run outside of the Metasploit framework, but so many things can be done inside msfconsole these days (`use kiwi' comes to mind).

Much of the early work in network penetration testing is done with either nmap or unicornscan, although zmap and masscan have gained a lot of ground in recent years. In particular, dnmap is a sleek approach.

One of the reasons why nmap/dnmap have little competition is because of their solid inputs and outputs, and of course, as Tate Hansen mentions above, speed. In other ways, nmap is just a simple way of expressing what needs to be done.

Here are a few flags I enjoy with regards to nmap:

Slow scan (but not too slow), evades IDS, and gives the reason why the packets didn't make their destinations. Best performed one port at a time with data-length or string set when the destination protocol or port isn't known by nmap:

-T1 --max-retries 0 --randomize-hosts --reason -n -Pn -sT

If I've found HTTP or TLS targets with the default ports, I like to SYN scan them first before scanning other HTTP/TLS targets on non-default ports.

-T1 --max-retries 0 --randomize-hosts --reason -n -Pn -r -p 80,443

-T1 --max-retries 0 --randomize-hosts --reason -n -Pn -p 902,2375,3000,3010,3128,3790,4567,4848,5986,7001,8008,8040,8080-8091,8140,8200,8400,8443,8500,8776,8880,8834,8980,8999,9060,9080,9084,9191,9292,9443,9990

If everything in in order, switch to faster scans and check for IDS/IPS

-T2 --scan-delay 4 --max-retries 0 --randomize-hosts --reason -n -Pn

-T2 --scan-delay 1 --max-retries 0 --randomize-hosts --reason -n -Pn

-T2 --max-retries 0 --randomize-hosts --reason -n -Pn

This is the next level of scanning (default speed, no randomizing because of the qscan latency checks), giving you lots of detail and potential for movement

--script qscan --max-retries 1 -v -O --osscan-guess --max-os-tries 1 --reason -n -Pn --version-intensity 0 -sTV

--script qscan --max-retries 1 --badsum -v -O --osscan-guess --max-os-tries 1 --reason -n -Pn --version-intensity 0 -sTV

Now is the time to run any last-minute anti-IDS or IDS/IPS/WAF detection checks. Finally, go for it! No sense in scanning a single port or small set of ports at this point.

--script banner-plus --min-rate 450 --min-parallelism 20 --max-retries 9 --defeat-rst-ratelimit -n -Pn -p-

unicornscan 10.0.0.0/24:a -D -L 20 -r 450 -Iv -mU -w udp.pcap

The above rates (--min-rate in nmap and -r in unicornscan) are measured in packets-per second (pps) and can be modified up to 10000 when on a local network or other ideal conditions. There are patches to change nmap's scan rate dynamically (interactively) here. Some other suggestions involve using nping on the type of traffic you are targeting and setting a -T4 scan with twice the --initial-rtt-timeout and four times the –max-rtt-timeout based on some sort of average round-trip time result you see in nping.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.