Alright, so from time to time I make some long (sometimes rambling) posts on why I am not (yet I am too) a fan of pentesting tools. Its of my opinion during a pentest that less is sometimes better. For instance, in the scanning techniques post [1] I used examples of substituting hping for NMAP, using ping to find addresses via ARP when possible and using CURL for a "on-the-go" web directory bruteforcer. Why go through the punishment you ask?

Think about the following situation for a moment. You're called in to perform a pentest on the fly without tools. How do you proceed? What about if you compromised a machine at say 3AM and you're unsure whether or not some system administrator is running something like MRTG, NTOP or some other network monitoring system. Think about that for a moment, while they may not monitor security per-se, they may see a spike in traffic to a particular host because you decided to upload a tool to perform a task you could normally do without your specific tool of choice. Keep off the radar and use what's available McGuyver style.

This is where I stated time and time again that it's important to understand operating systems on an administrator level when it comes to penetration testing. The more you know, the easier things become as time goes on. Useful sites: CommandLineFu and CommandLineKungfu.They have some interesting examples however, I suggest learning awk and sed on your own as opposed to relying on anyone else's examples.

So, without further rambling, hopefully we can all make a continuous thread on alternatives to tools. We could post alternative command line solutions for a variety of reasons, to learn about existing tools, what has and hasn't worked for you, or some nifty little "WTH does that command line"

NOTE: the "do echo curl" is one line up until "|sh" I didn't enter the code tags to make the chars, bold. Anyhow, they all do the same thing... I used "megabeast.txt" from the wfuzz tool - which is an excellent brute-forcing tool however, it's noisy as heck - as are most web based scanners. So have a brainstorm with yourself... Can you scape a webserver, then check that same webserver with your findings WITHOUT a webapplication scanner? Sure you can. It's a matter of trial, error and patience.

So, we've seen a brief intro into alternative methods to pentesting tools. Now some again, would wonder: "Why bother" and the answer as I've already stated is, creating your own tools allows you control what is occurring. There are often times that one may find the perfect tool, only to find out it's too noisy, or it will crash an application and so on.

This is evident for pentesters who have to do SCADA based systems. Most of the times you will NOT be able to run security tools against some of these machines and the answer is simple, doing so (running tools) can crash mission critical applications. So what's your next best bet? NMAP on -T0 what about contained environments where you don't have NMAP, what would you do, how would you proceed.

Many have heard me repeat the term "versatility" ad-nauseum and I will always refer to being able to understand how to do certain tasks in different ways. Doing so helps you understand what is happening when you tamper with protocols. It allows you to be flexible in the long run being more "well-rounded" and more "capable" without being referred to as a "script kiddie" or "tool monkey." Sure you're still using tools, but your skillset will not rely on them.

Sil, that's a great write up. I completely understand where you are coming from. Reliance solely on tools is never a good idea. They miss so much, identify so many false positives. Most of all, they are noisy (in general). Even if you do use a decent tool, you end up spending quite a bit of time in Wireshark trying to figure out exactly what's going on.

Still, it's difficult to avoid using tools. If someone has already coded something that will save X number of hours on an engagement, you almost have to use it. Time limits and budgets have way too much say in this.

Not only do I agree with all of your points, sil and Ketchup, but reliance on precanned tools and frameworks also gets someone into bad habits. I know a guy (don't think he's a member here, so shouldn't offend him, but if he is, he's alreday acknowledged to me that he knows this, so he should be OK) who relies on Core Impact, for nearly everything. He's managed to work out a partnership with Core, and they've been letting him use their product, free of charge, for a little while now. Problem is, he doesn't look PAST Core, during his testing. While Core is a GREAT tool, he lacks the knowledge of the underlying processes, ports and services that it's testing against / performing, and he's never truly learned how to use simpler tools to achieve the task at hand. He's a CEH, and understands the concepts, but I think he's realized that the concepts, alone, aren't enough, and I'm afraid for him, as one of these days, he's going to get contracted to do some testing, and won't have Core, for whatever reason. He's going to very quickly lose all faith from the client, if he can't perform in that situation..

A good pentester must absolutely understand the fundamental protocols and services being tested / attacked, and has to know what sorts of responses and info he / she might receive, based on the types of scans and attacks they're performing. I can tell you, for instance, that if my friend were to even attempt OSCP, right now, that he'd very likely fail it, on the sheer fact that he's become too complacent. He might come up to speed, somewhat, but I think even in OSCP, he might try to rely too much on Metasploit, for instance, where, on the final exam, that reliance would easily cost him the exam.

Same applies in customer environments. Many frameworks are noisy / chatty, and many ids / ips and other tools spot their activity very quickly. The pentester needs to be able to perform the same tasks, in more covert ways, in order to avoid detection, and to continue to progress, else he or she is not going to go far with their activities, before being spotted. This makes the tester look less capable and / or makes the company paying for the test / services feel more of a false positive for the security of their environment, meaning the tester has done them more harm than good, by lulling them into a false sense of security / doing things as they should be.

Great points, sil, and I look forward to more from this thread! (I'll contribute, as well, as time permits.)

Last edited by hayabusa on Sat Jul 31, 2010 8:24 pm, edited 1 time in total.

~ hayabusa ~

"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." - Sun Tzu, 'The Art of War'

I had a discussion with someone recently about some other pen testing company dinging them on a bunch of things on their network but not providing details, screen shots, or even basic guidance for remediation. I'm sure some places like to keep their methods secret (which I don't agree with) or use some proprietary tools (even if you don't show screen shots, show what data you obtained and explain the underlying processes), but I really question whether they simply omitted that type of that information because they genuinely didn't understand what was actually going on behind-the-scenes.

Sil, this is amazing! I'll admit that I'm a noob when it comes to security, but here is my noob take on this: look at what a tool is doing (in a lab of course), then figure out how to replicate the desired result only better.

mallaigh wrote:look at what a tool is doing (in a lab of course), then figure out how to replicate the desired result only better.

Yes and no and yes and no and yes and no. The purpose was to give an alternative to tools in the event you're stuck on doing something and don't have a tool. E.g., they throw you into a NOC right now with NO outbound connectivity. There is no way for you to get to the outside world. They DON'T allow you to use your own tools... What do you do?

So you jump on a Linux box WITHOUT say nmap, what are your workarounds? Do you have any? It's to make someone understand a little more that there is no perfect tool to be honest. There are tools that may make things easier for some, but more difficult for others. You don't always have to rely on one tool and you shouldn't. If you're into "hacking" (whatever this means for some), you're supposed to be thinking outside of the norm.

In my time in this arena, I know some severely scary pentesters who were good at coding say buffer/heap overflows, horrible at networking and vice versa. I personally feel its better to be versatile and learn as much as you can from ALL angles. (systems, networking, programming, etc.)

Now unless you're a glutton for eye punishment (reading code), I don't suggest getting into coding unless you want to be a programmer of some type period. Be advised though, that In order to reverse engineer, you HAVE TO understand some programming (the more you know, the better off you are). To be honest though, from my perspective, in order to pentest on a day to day, it's rare you will come across this (reverse engineering) unless you're doing code auditing. You don't necessarily NEED to know how its coded to understand the protocols and intercommunications though, and this would be a higher risk (from my perspective... intercommunications) then someone getting access and doing some RCE.

Think about costs from now (anyone reading this). Even if you're not getting paid and performing a test in a lab, start associating a financial cost with what you're doing. Now think about this for a moment... As a pentester which is more cost effective for you... Auditing/pentesting from a network/system "hacker" perspective or reverse engineering and doing binary analysis... At what price? Clients nowadays in this economy aren't going to fork out say $200 per hour per 80 hours on a binary analysis... They want to know RIGHT NOW, what can an attacker leverage...

1) What's immediately at risk2) What's the likelihood of that threat being exploited3) What's vulnerable AFTER someone has exploited the system4) How much are we exposed

Side note to dynamikdynamik you may have had to deal with this under the CISA or CISSP if not you WILL encounter it on the CISM:

Puke time...

Code:

Threats -> exploit -> Vulnerabilities -> which results in -> Exposure -> which is risk -> which is mitigated by safeguards -> Which protect assets -> which are endangered by Threats (start all over again)

/ end side note

This is thought process from ISM's (infosecmanagers) who are on TIME which means, monies are a wasting... They want to know they're getting their infosec monies worth which means, unless you've gotten RCE down to a science, you'll end up with so much scope creep on an assignment, the job is worthless. You let your money go out the door.

So rather than focus on "a tool" or mindset, the goal is to always have a back-up plan ready to go. Alternatives in the event that hey... There is this thing called Murphy's Law. Rather than fight it, think about the optional routes beforehand Will save you time, a headache and money in the end

I have a cheatsheet for command line scripts and workarounds that i use often. Most of them are from Ed Skoudis and other pentesters who trade 'em around. When you first show them to people they lol... and then they cry when they cant use nmap.