So you want to break into the world of penetration testing... The following is a suggestive route I've laid out from a technical perspective. Its
purpose is to introduce you to a broad technical level of "know how". Some, even many will disagree with the methodology and structure that I've written, but my
intention here is to get you to a point where you can understand how it all comes together from the top down and vice versa.

I've received a lot of e-mails regarding a post I made on the "pentesters" mailing list so I decided to write a sort of no bs framework which should
give anyone reading this - and putting it into practice - enough information to be a versatile security professional and enough know how, in order to break into most of
the security sectors, network security, penetration testing, firewall engineering, etc.

This is perhaps the one biggest challenge I faced - trying to summarize years worth of work into a compacted framework. Attempting to dissect and
explain it all, without boring the reader. This is a two year framework, if you were looking for the easy way out, there is none, period. Security, especially when it
comes to pentesting, is an ever evolving dynamic arena. You seriously need to understand a great deal about a lot of topics, protocols, etc., With all that said, enough
rambling.

Step One - Weeks One through Six

This is an introductory eye opener. For these next few weeks, I suggest going through and understanding the OSI layer. Learn how protocols
interconnect and communicate. Learn why and how things operate with one another. Although many shun the OSI layer, some will even say it's antiquated, some may point to
the DoD model, the OSI model is still highly referenced and straight-foward. Understanding the processes and interconnections is a must.

You want to not only learn the names of the OSI layer, but you also want to understand how they all behave with one another. You must - and I repeat,
MUST - understand every single part of the OSI layer, period. In doing so, the knowledge of it comes in handy across all technical certifications, so if you're planning
on going the certification route, this will only benefit you in the long run.

Let's think about this for a second on a realistic level for a pentester. So you're in an interview and someone asks you - "At what layer of the OSI does an SQL injection
occur" you will need to know this answer. Now remember, SQL operates on the Session Layer, but is an SQL Injection attack occurring at the Session Layer or at the
Application Layer? What layers is it passing through? Understanding the core concepts of it all begins with the OSI model. Regardless if you're taking a test or sitting
in an interview, the purpose of needing to know this is - it makes it easy for you to structure an attack, perform an investigation, or perform any kind of analysis.

Rinse and repeat: The OSI layer is one of the core fundamentals you should know period. This includes studying A+ material. You may not want to take
the A+ in fact most say it's worthless, personally I wouldn't bother with the certification however, at some point in time, you will need to know BIOS information,
for say, swapping out disks or analyzing disk information (forensics/counter-forensics), you will want to understand many of the topics on the A+ level. If you're
planning on going the forensics/incidence response route, you will need to understand this.

Step Two - Weeks Seven through 19

Immerse yourself in learning networking. Learn as much as you can on how networks interconnect, how they do so, what a MAC address is, what is ARP,
RARP, how one network connects with another and why. From the LAN level all the way on through. I cannot tell you how many individuals swear they understand the
differences between a private LAN and a WAN yet they'll ask "I'm at work (public address), why can't I ping my server at home from work?! The address is 192.168.x.x".

My suggestion would be to grab some of the Cisco books, my order or preference would be as follows with an explanation following:

So why Cisco Press books, you're not studying for the Cisco exam! The listed books have a wealth of information with regards to the OSI layer (all
levels) and explain common concepts and strategies in security. Not to overlook the fact that they'll teach you an ample amount of information pertaining to routing and
switching. You will need to understand networking heavily in the security arena as computers are (drum roll) networked.

Understanding routing, routing protocols, switching, VLAN's, etc. will definitely help you in the long run whether you realize it or not. You will
need to know how a path is taken to get to a targeted machine, you will at some point find yourself wondering why you're solely seeing two servers on a network when
you know there are dozens. You will want to understand portions of a packet when doing a sniffer/network analysis. You will need to understand why one protocol might be
chosen over another. Overall without a network, there is little to be compromised. Even locally. What would be the purpose of say compromising a machine on a penetration
test only to be isolated to that machine simply because you didn't understand what an ARP address was, how to change it, how to spoof it. How to subvert VLAN's.

Again, just because you're not taking a CCxx exam from Cisco, does not mean you shouldn't pick up their books. Plenty of professional engineers have
started their careers reading Cisco material without being Cisco certified engineers.

Now the CCDA book will help you understand the concept in designing a network and while you may not care for it - you can learn plenty of information
that you can use in the real world. My suggestion is to get the books, study them frequently and understand the core of it all. I suggest checking out a store I use on
ebay called Best Bargain Books. I've purchased books for $1.00 (US) and paid about $3.50 on shipping. http://stores.ebay.com/Best-Bargain-Books Also check out the used
section at Amazon. Or simply browse Cisco's website.

Do not - repeat - do not skimp on understanding the network. This includes reading RFC's. You should have a keen concept of say RFC1918 and why it's
important to understand private and public networks. You should also have a thorough understanding of the different types of IP packets, their codes, errors and
structures not to forget you will need a firm grasp on subnetting. The differences between a Class A, B and C network, and no a Class C is not a slash twenty four (/24).
If that came as a surprise to you, then you seriously need to go back and read. Understanding subnetting is important as you will need to understand your boundaries when
performing say, network assessments.

Step Three - Weeks 19 through 26

You've begun to understand networking and have an understanding of the OSI, now it's time to learn a thing or two about systems... Suggestion... Pick
up any distro of Linux or BSD. Head over to distrowatch and select one you think would suit you. Remember, your goal is to understand an operating system and the best
way is to do so hands on.

My suggestion would be a variant of Redhat, either Fedora or CentOS. "But Debian so rox0rs!@", "duod my Slackware pwned you!" Distribution zealotry
aside, the majority of corporations stick with primarily Redhat followed by SuSE on the Linux end, Free followed by Open on the BSD end, and Fortune xxx corporations
tend to go with a mixture of Solaris, HPUX, z/OS, Redhat, etc. based on my experience. No you probably won't be pentesting a Slackware box, nor Ubuntu machine. If you're
doing a high level corporate test, you will be testing against those mentioned, I highly doubt you will see Slackware, Puppy Linux or any other of the thousand variants
of Linux on the enterprise circuit.

Tinkering with different operating systems will give you hands experience on those operating systems however, this is not real world experience on the
corporate side of things. Corporations each differ. Many different technologies are in place, all performing different functions. So why don't I recommend you learn
say, JAVA or Assembly here? It's irrelevant for now. Right now, you will want to dive in to operating systems in general. Learn about them from an administrator level.
Eventually you WILL also want to learn some form of programming language even at its basic level. Which poison you pick will be up to you. PERL, Python, Ruby, ASM, they
all have their roles, pros and cons.

Programming will definitely help you in the pentester (Tiger Team) role and you may not always find an exploit made readily available for something
particular. You may be familiar with a program running that you've perhaps seen crash before, act strange, but there is no guarantee you will be able to visit say
milw0rm, PacketStorm or other sites and find an available exploit. You may want to whip out a dissassembler, gdb, IDA pro and debug what's going on with that program
you have an eye on though. What made the program crash, does it have the potential to have commands written (buffer, stack, heap) via an overflow?

I wouldn't focus so much on tools or even programming right now. I wouldn't even make them a priority at this point as you won't always be in an
environment to run certain tools anyway. You're merely familiarizing yourself with the operating system. My personal suggestion, learn the common tools for that system
as well as Perl or Python period. If you're working on say a Solaris box, you shouldn't have to wonder what svcadm is. You shouldn't be puzzled at /var/adm and why you
never saw it on say Ubuntu. Understand the differences in operating systems and their structures.

The purpose for me conveying to you the need to learn the common core of a system is because it gives you a lot of flexibility at the end of the day.
For example:

They all perform the same task, but which would you use on what system and at what time? I might use perl on a large file however what happens if I'm
on a system without perl - those horrid legacy systems where one update or upgrade will break something, then I'd move on to awk or sed. It all boils down to
versatility for me. Put me on any system and I'm good to go. If the system has a command line structure, I can get by. Can you perform the same functions as say nikto
without PERL? I can using LWP or CURL and awk. Does this make sense? I hope it does.

Step Four - Weeks 27 through 38

During this time period, I suggest setting up lab based environments, meaning - creating an environment to compromise. Download VMWare or compile XEN
and load up a couple of different operating systems with different programs/daemons under different configurations. E.g., Windows 2k running say IIS with no MS patches.
Cleanly installed version of say CentOS, Solaris, etc.

Once you have your VMWare images installed, you can then head over to milw0rm, Bugtraq, etc., and find the vulnerabilities associated with your
operating systems and configure the operating systems accordingly. Meaning - if you see that say Program X version Y is vulnerable to attack Z via an advisory, then
configure program X version Y so you could actually compromise it.

This where the fun should begin. At this point you should be able to determine what programs are running as daemons and if you're wondering "what's
a daemon" at this point, I suggest you go back through step 2. Your first tasks during this timeframe should be to try local exploits followed by remote exploits.

Download and compile some of the exploits associated with the system you're working on and try figuring out how these exploits work the way they do.
Take a minute or two to look through someone's code, try to understand it. This still does not mean you should pick up Stevens' TCP/IP Illustrated. Just browse through
the code, take a look at portions of the code and try to gain a sense of what it's doing. In doing so, you become a little more familiarized with certain structures of
system calls, ports, connections, etc., without even knowing the programming language (if you didn't already know or learn a specific language). It's good to know the
process an exploit goes through during an attack, it helps to develop strong skills in re-writing code whenever necessary that might suit your needs.

Try to gain enough understanding to perform say an lsof or netstat to see what is open on the port side of things. Remember you're starting off
with local attacks, so with this information you can move on to say Now LAN level network compromises. Leave sniffers running to see the connections, try to analyze what
you see. What DO YOU see? Can you leverage it? Are you familiar enough to know what are the first programs you would want to look for - if say port 445 was open? Are you
familiar enough with the most vulnerable daemons and programs for most operating systems? Can you name the top exploits for the top rated open ports?

During the "learning networking" steps, you should have become familiar with the differences between UDP and TCP. Do you know what and how to look for
opened ports effectively without using a scanner? How about writing your own scanner ;) It's actually a lot simpler than some may think.

This is a learning phase for you, so you should not be disheartened if you fail during your first attempts, no one is born "thirteen thirty seven"
period (except TQBF and Shawn ;)). I'd suggest before you focus on becoming familiar with nmap, you familiar yourself with say telnet. Can you write a shell script to
connect to a slash 24 for banner grabbing with nothing but bash and telnet? What happens if you just don't have access to a scanner? Do you call it a day? Think outside
the box. Versatility.

"Why the hell would I do that?" you ask. The answer is simple, so you could take a look at the entire scope of things from different layers and
angles to see and hopefully understand what occurs during the compromise phase. Familiarize yourself with as many processes involved on all layers and levels, don't
strictly depend on tools, a monkey can be taught to run a tool. See what occurs at the network level, check what occurs at the server level - understand what is getting
logged - if it is, where it is. Fiddle around, you may want to invest in the man pages of a system, certain available tools already on a system. tcpdump, snoop, lsof.

You can also load up Wireshark if you have it installed or your sniffer of choice, compile any known exploits for the vulnerable programs and servers
you've installed, and attack then in parallel to your sniffer running. Understand what packets pulled off the compromise at what layer. If you're serious about doing say
network analysis, I suggest taking a look at Laura Chappell's excellent Wireshark University offerings. Laura is a pretty cool and knowledgeable expert when it comes to
the packet level. In fact, I'd seriously hate to become her enemy. Luckily she not only ultra smart when it comes to packets, she is an extremely wonderful person
(INSERT brownie_points WHERE NICK LIKE sil) ;)

Now many peers will disagree with the approach I've written here or even take an altogether different approach than I have so far - many will choose
to skimp on the networking portions of it and focus on say the application side of things or programming aspects. This is not an incorrect approach it's a matter of
preference. Personally for the application attackers doing a pentest on my network, I'd modify things on the fly if I saw them since I can be anal like that. E.g., if I
saw they were launching attacks on a Linux machine in my network, I might change the host's responses to that of an Irix machine for kicks and giggles, I might reverse
proxy an IIS machine to POST to an Apache Server. That's just me though, but I'm sure the experienced individuals will be able to determine what I've done. How so?
Perhaps packet signatures, server settings being returned, it all depends, it's all for you to discover.

Which brings me to a major rule of thumb, don't always rely on fingerprint when doing enumeration, it isn't always 100% - at least for me it isn't.
This is why you'd want to understand some of the network portions, packet signatures, methods of delivery, etc., as checksums are more difficult to change then it is to
change a daemon's listening port or a server's signature: mod_pimp anyone? Cross compare different results with different tests, then verify.

It's easier to gauge what something *really* is, on the network layer as opposed to relying on "banner grabbing". Besides, I still use modified
portsentry on my honeypots along with a modified version of Fred Baker's Deception ToolKit. What can I say, I'm retro like that. During this timeframe, you should become
familiar with certain methodologies and frameworks when it comes to penetration testing. For this I recommend heading over to ISECOM and picking up the " Open Source
Security Testing Methodology Manual" (OSSTMM) and familiarize yourself with it.

Step Five - Weeks 39 through 52

This is going to be an odd guide/course/step to follow on this phase because there is no "one size fits all" model. It boils down to trial and error
if you ask me. The tool stage. By now you should be seriously comfortable with understanding ports, systems, what to look for; "knock knock". During this phase you
want to become more familiar with security tools, what tools do what, where, why, how and when is the best time to use them.

My suggestion, head over to Insecure.org and check out the top tools for each segment of security. Download them all, try them all and try to
understand them all. What they do, how they do it, which might be better in which scenario and why. Which makes less noise on the network. Obscurity!

Now let's take a step back to reality. A tool is a tool is a tool ad-nauseaum. It's "what is the tool doing" that's important moreover, can you
explain what a tool does if I was having a conversation with you about it. Or would you give me a generic answer. Do you know the difference between a webapp scanner and
a network scanner? Can you interchange between the two? Are you sure?

Tools can be fun but understanding what they're used for as well as what they do, is more important than actually using them sometimes. Besides many
tools are just streamlined commands already on a system. You might find it easier to make your own tools at one point, or you might find nifty shortcuts and dual uses
for your tools. For example, I sometimes use nemesis as a replacement for nmap ;). I sometimes use LWP's POST instead of a browser. Sometimes I browse pages a-la wget
-qO - thispage.com or links -dump thatpage.com imagine that for a second:

A friend of mine I shall named Minga is perhaps one of the best pentesters I know period, his favorite tools to use ... None! He chooses to use his
own stuff 99% of the time. While some (specifically me) think he's a glutton for punishment (particularly me) I think he's perhaps the most clever and dangerous
pentester I know simply because of his versatility. You see, tools can leave a fingerprint . so with him, it's hard to detect his presence let alone defend against
someone like him. Since he's my friend, I know I can just bribe him with beer and not worry about my network, you however, you won't get that in the real world. In order
to think about offense you need to understand defense and vice versa. Hence me pointing out opening logfiles and understanding what you are seeing.

In understanding the layers, you'd understand when and where to use a sniffer, a packet injection tool, a "web application" scanner, a network
scanner, etc. Make sense now? So when you began you probably thought you'd fired up nmap, Nessus, HP Webinspect, Core Impact or some other scanner, launch it against a
network, call it a pentest, collect the money and call it a day.

If you have performed a pentest or are currently performing them in this method (using ranDumb tools), I created a title for it a long time ago for
you - scriptkiddiot. I don't care if you're certified to the core. If that's the meat and bones of your arsenal and knowledge - point and click - to me you're still a
scriptkiddiot. Sorry but it's the truth.

Hopefully you will understand why it doesn't always work as simple as just looking for and using SuperHackerTool X. What about the firewalls, the
IDS/IPS devices that will almost always block you, how can you skate around that, can you even skate around that. Can you blind spoof and sniff the
responses if any? Do you even understand what the purpose of blind spoofing is? Can you compromise a machine via blind spoofing and reverse a shell back to you? What
about a covert channel say through http or ICMP. What about firewalking? There is a lot more than meets the eye. The more you know and understand, the more creative you
can get, the better you will be.

Anyway, hopefully by now you will will see the importance of being that creative, that versatile, that flexible. Enough to think about
how to avoid and perhaps even evade certain security devices and applications. "How can you muck around a little bit more stealthily." Can you change your packet
settings to say Unicode? Can you do so with say libpcap without downloading someone else's tool? What about netsed? Do you even know what these tools are? Suggestion:
Break your tools down into their respective categories, webscanners with webscanners, network scanners with network scanners and don't (repeat) don't skimp on
investigating existing tools on a machine.

So you now have the experience with the layers, networks, operating system, now it's time to formulate a CTF (Capture The Flag) game plan. Configuring
a network/system on a realistic level. Imagine that you needed to set up a SoHo environment. A mail server, webserver and a database for a 20 user network. Go create it
- virtualized or not - this is your preference. Configure it as if you were starting your business. After it's done, analyze it. Find out what you would need to do in
order to compromise that network. Are they running a webserver - if so which - what version, rinse and repeat. Re-do this network and now lock it down as if you're life
depended on it, rinse and repeat the attack process. What do you observe?

This recon phase should give you a sense of how to seriously perform information gathering. There is a twist to it. At the same time you're gathering
information, have those servers open to you as an administrator watching logs. Who is connecting to this server, where are they coming from, what are they trying to see.
Is anything out of the ordinary? This dual purpose teaches you strong defense tactics ;) Understanding the administration of a server is priceless from a defensive
posture. Understanding it is priceless from an offensive posture! ;) There are always two sides, offense and defense.

Anyhow, depending on the reaction and response, I will probably update this when I can.

I'll try to add more as time goes on however, I'm quite busy with work, life, (anti)social networking, etc., so bear with me. I hope to write
more updates maybe once a month again, depending on whether or not I perceive people as understanding it, or if my peers start hating my guts (won't be the first time
for that one though) so stay tuned.