EH-Net

I wanted to take some time to give those taking the OSCP and similar exams, a bit of food for thought when taking these exams. The food will come via taking time to create a repeatable framework in order to perform necessary objectives on the road to "owning the box." Be it Windows, Linux, BSD, the flavor is irrelevant. I urge anyone taking the exam to go over the PTES (Penetration Testing Execution Standard) as it more detailed than what you will see here.

The OSCP exam seems to eat up a lot of time for a lot of individuals taking the exam. Time is crucial in this exam as you are going to be allotted 24 hours. In the real world, your SOW will also have a cut off time. So how can you maximize your time without having your work all over the place. The answer is to create
yourself a framework.

In the following mindmap (http://www.infiltrated.net/mgz/oscp.jpeg (http://www.infiltrated.net/mgz/oscp.jpeg)), I have a target and the tasks I would take in trying to exploit the target. In the enumeration/identification step, I will begin with, but not rely on, NMAP. I try to use p0f whenever possible since it offers a better mechanism of identifying a target.

I try to use p0f especially when identifying webservers, since I can use a proxy server to connect without triggering anything out of the ordinary. In the following snippet, I will connect from my desktop (FreeBSD 9.0) to a forensic workstation I created using Ubuntu, on port 80.


NMAP states this is Ubuntu, what does p0f state?


We can validate whether or not out nmap output is accurate but we can assess how long the server has been running and get an idea of the patch level of a machine. Now, in order to minimize time, I might sweep a subnet for specifics: HTTP, SMTP, POP and so forth. The reasoning for this, is that when under time constraints, it allows me to focus specific attacks and probes against those specific targets that I know are running the service. This allows me to spend time elsewhere (running other nmap sweeps, etc)

For example, I can sweep a /24 for ONLY port 80, begin launching more probes in the background, while I launch other scans and other probes at another service.


In any event, if you're doing ONE thing and ONE THING only on the OSCP exam, you're wasting time. There is nothing stopping you from opening a terminal and creating your own little framework for doing this exam:


Get the picture?

1) Make relevant directories (way beforehand)
2) Enter a target
3) Go check if the target is running anything on port 80
4) If it is, then run nikto against it
5) When done write it everywhere in case I am on 50 different terminals

You can continue something like this to fire off dozens of tests, probes, and so on. What you do with your time is always going to be critical since time is irreplaceable. Same applies when performing real world testing. You may be in a bind for time, if you're waiting on the output of one tool, you're wasting time. Moving back to the mindmap, take some time to think about a structured way to attack this exam. There is no reason you cannot fork off processes way before you even get started. Practice in your own environment:


Same applies in the real world. When performing tests, it is critical that not only you perform necessary testing, but it is also critical you manage your time while doing so. (Time is money) Creativity goes a long way in this field (pentesting) however, it makes no sense to throw paint on a canvas and once done, determine you are now going to start painting the Mona Lisa. Planning goes a long way

Food for though

++1

Multitasking is essential, both in real-world pentesting, and in these courses.  You WILL NOT complete the exams in OSCP, if you remain single-threaded...

sil's advice is spot on.

Very nice write-up.

Real world is funny and sometimes fool around with the admins watching me perform my tests thinking they're going to do something stupid like stop me. Before I even start most tests, I fire off dozens of decoys (sometimes including their IP space) so they don't turn around and block me. Once I'm running though, I usually blend right since people will be so confused by the amount of stuff they're seeing.

great post, i remember someone saying that pentesting consists for the most part of waiting. This is only true if you truly master the skill, and by that i mean automate, automate and automate...let the computer do the work for you and use the fact it can multitask like no other...

some other tips:
try to separate automated scans. Sometimes tools get in eachother way. An example from my experience is that nmap and nessus can be working against each other during UDP-scans.

Talking about nikto, sometimes tools provide you with false positives (which is perfectly shown in the ubuntu/freebsd example) so NEVER trust the output of tools blind, always perform a manual check or use a second/third tool to confirm.

This is a great post, last night I was enumerating users in a smtp service, during that time I was thinking how can I increase the performance or do something else with this? and I remember your post.

Another thing I do to cut time, is distributed password cracking. I fortunately have access to quite a few machines. What I do is parse out my word lists and split it between machines. For example:



I will split this into about 16 files, and send them to 8 different machines. Since they're sorted alphanumerically, it becomes a divide and conquer. Where as if I had one machine starting at say A, it would take N amount of time to reach Z. If each file consisted of say 3.5 of the alphabet, my time is shortened. (File 1 = A - Ch, File 2 = Ch - Fa, File 3....). My wordlists are created using a buckload of words, iterations on those words and contain the MD5 and SHA1's of each instance. So I can just grep a word or a hash and see one another:


Rather than wait until the last second, these are little things anyone can lay out beforehand. Before I even go the cracking route though I will try out some stuff online so I waste even less time: http://www.md5decrypter.co.uk/

Quick question - I've read several OSCP reviews where the person states something to the effect: "I would have cracked that first box in half the time had I not [made a programming error]."

This confuses me. Are the programs you create for the test the kind where you don't get any feedback (i.e. find out you made a mistake) until they're finished running?

If you're writing your own tool, its up to you to direct how the output appears to you. Think about that for a moment... YOU are the one writing the program, what is it you want you're program to do. How should it connect, what should it do when it connects, what should it do if successful, if it fails.

Sil, in thouse examples above, are those examples of scripting?

Some are, some aren't. Scripting is nothing more than running successive commands. For example, I need to check if there is a shadow or master.passwd file on this machine, and if so, I since I may not have privileges to copy or view it, let me see who in the sudoers group may have access to do what I need done (this helps since I can also attack that account as opposed to targeting root) and also who from the passwd file may have privs


As explained, scripting is nothing more than successive commands. I would run something like this as it gives me more targets to aim for as opposed to aiming for the holy grail. I wouldn't need to as I can also target the account "sil" who is in group wheel, who has sudo privs without a password.

This is actually an excellent use of OffSec lab time as well. Instead of solely focusing on compromising systems, spend some time developing a game plan and attack methodology for the actual exam.

I'm a fan of running smaller, quicker scans, so I can obtain information to start working with expeditiously.

The following one-line script takes a start number, end number, and tcp/udp input, and returns a comma-separated list of ports from the nmap services file based on popularity


For example, the following command scans the top ten TCP ports (note: the start/end numbers are popularity rankings, not actual port numbers).


Reviewing the scan.nmap file shows the actual command that was run: nmap -p80,23,443,21,22,25,3389,110,445,139 -oA scan 192.168.1.1

You could do the same thing with --top-ports 10 for this specific scan, but if you performed subsequent scans of 20, 30, etc., you'd be rescanning the same ports over and over instead of being able to increment by 10 (or whatever amount). Starting with popular ports will typically give you the most information in the shortest amount of time. Once you have enough to keep you busy for awhile, you can expand the range and do 50, 100, etc. ports at a time.

Much more functionality could obviously be included. For example, the nmap command could be included in the script and add -sU if UDP was chosen, the ports could be included in the output file name so you don't accidentally overwrite previous scans, and so on.

Would never work in BSD or Solaris :P


In action via FreeBSD:

By the way, the reasoning for the mixture in awk, perl and ruby in my example, is to get you guys to see other variations across different languages. Improvisation

I knew I was setting myself to get schooled, yet I posted anyway... :o

Nah no way, not schooling at all, offering the same in an alternative form ;)

I don't really use oA at all with nmap, here is how I would do it if using nmap with your one liners based off the crap in my office:


My scans tend to stay in SYN land ;) and I always (without fail) go deep in versioning when possible.