I'm not the most articulate person, especially in writing, and while I thought by the people that bothered to comment on the blog, I got my point across
other people make me think I didn't.
So, I'll try again, if this doesn't work I'll resign myself to just not being as l33t and skilled as other people in the community.
I'm not against ALL automation, by its very nature everything involved with "hacking" or penetration testing is automated but I'll try to restate. From the orginal post:
Automation is a good thing but when it comes to pentesting I really think there can be too much automation.
Too much automation leads to "fire and forget" activities and lack of TLC.
Believe me, I'm all for bash running my nmap scan and rolling IPs for me all nite rather than stay there and do the stuff myself. I'm all for automating a tool that needs to run a set of commands on a subnet or group of hosts given the appropriate scenario. Hell I'm even all for running scripts that will log into every box and "do something" (go tebo!) also given the
appropriate scenario.But what I'm not for (but I do concede there are plenty of times when the following is perfectly acceptable and maybe regarded as "good" pentest):
Rolling in and run my full port nmap scan, nessus scan, core impact rapid pent test, connect to a couple of agents, take screenshots, high five with my team mates on how l33t I am, then head out and write the report.
I'm of the opinion that for the above scenario, a couple weeks of training and a couple of licenses later any in-house shop can do that for themselves.
I will propose that there is an alternate type of pentest where my goal is not to root as many boxes and I can but its too see if I can gain access to "what makes the company money". I am unannounced, trying to not get caught is part of the test, and where the customer actually has a great patching program, an IDS, possibly and IPS, an outbound proxy, somebody actively monitoring the previous technologies, and asking them to turn all that shit off is not going to happen....
how would our above scenario fair for that pentest?
how fast would your pentest be over if you did say....
"For example, I enumerate open shares on the entire subnet, then pull down all .doc documents, then search them for interesting information from the recon phase (i.e. the name of the CFO)."
I'd give it about 2 minutes before any SOC that doesn't totally suck blocks your ass and you have to go begging for them to unblock your IP...that's never any fun.
I wont address everything from the pauldotcom show notes, because frankly I think they completely missed the point of the post (because I am not against all automation), but I will address this.
"[PaulDotCom] - While I agree, automation can have a negative effect on risk identification,
its a vital part of every penetration test. Much of the post talked about how automated tools "Don't have the love" and "you need TLC". That's all well and good, but how do you show risk when you've got a meterpreter shell on 30 hosts? What are those hosts? Do you spend 3 weeks of your time and the customer's money to demonstrate risk? No, you automate the mundane tasks and pieces and parts that can be automated. "
I guess my response would be why do I need 30 shells to demonstrate a point? how would I have gotten those shells without being really sure about what/where the host was before I launched anything that would have gotten me a shell? but if ./autohack ran on a subnet and gave me 30 shells then I guess I might find myself wondering what are all those hosts and how did I get in. As for risk identification, if I got 30 shells the risk identification is an enterprise patching problem in this scenario.
"This does not make you any less skilled or a script kiddie, in fact, it makes you more of a master."
umm how? did I have to run a nessus with credentials to find those vulnerable hosts after checking 100's of KB's and throwing tons of traffic at the hosts or did core impact throw 20 exploits at each box before I got lucky and popped a few? Or did I limit my exposure and try to enumerate what services were running and what service pack the host was and try the latest exploit at one host to see what would happen?
I'll spare you the rest, like I said I think the point of the post was completely missed.