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 risk
2) What's the likelihood of that threat being exploited
3) What's vulnerable AFTER someone has exploited the system
4) How much are we exposed
Side note to dynamik
dynamik you may have had to deal with this under the CISA or CISSP if not you WILL encounter it on the CISM:
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