I am planning on trying it again in the fall. My preparation will be simple: hack all machines in the Offensive-Security lab! It may cost me a few $$$, but in the end, I believe it's the only way to get ready for this exam. In addition, I think I will learn a lot in the lab, so the money is not wasted.

Also, I think one of Offensive-Security flaw is it is pretty difficult to know if you are ready or not for the exam, under than giving it a try...

Like H1t said, get into the labs because that is the best way to prepare. If you can get all the way into the Admin network in the PWB lab, you are ready for the exam. I actually only made it to the Dev and IT networks but got about 30ish boxes and passed. I really don't think there is a better way to prepare because there are no other labs like the one they built. Even if you build your own, you're kind of cheating yourself because you know what you installed, know what versions of software etc. etc. The only other advice I have is to be able to commit to it, work on it every day so that it stays fresh in your mind. Don't over think it, just pwn it.

Actually, I did get into the admin network (got a few hints though). But I've learned a lot during the labs and pwned a fair amount of machines. I feel I should be ready but at the same time I feel I need more practice. At this point I simply can't afford extra lab time.

Many times, after pwning something, I realize that I've indeed been over thinking it. The answer turns out to be simple, but only after pwning, which makes sense lol

I wonder if there are more VM's to download from the net that I can pwn.

Good luck guys! This link is posted somewhere on the site but I could not find it so I will just repost it. It might help. "http://code.google.com/p/pentest-bookmarks/wiki/BookmarksList". I am sure we will all be saying "Congrats" soon.

I believe I mentioned this once upon a time, but will do so again. The key to OSCP if you ask me boils down to time management. You need to attack it with a gameplan as opposed to going at it blindly.

When I did the OSCP, I programmed an entire shell script to go through all the tedious tasks. In fact, my shell script (perl + python + shell) was designed to take the test for me. It was built to perform all the recon, bruteforcing, etc., prior to me even focusing on a machine. Problem was, my exam was a curveball. Never the less, I re-tailored my program to do everything BUT compromise the machines.

For example: You know you will be running network scanners, you know for certain services you will run hydra, etc. write a script that does something to the tune of this:

if [ output_of_nmap == 21,25,80,3389 ]

then

run hydra targeting those ports

fi

Do this for specific hosts in the background while you do something else. This allows you to continue with other tasks as opposed to focusing on one thing (while time dwindles on) in which you have already targeted and started that goal.

If you're doing ONE THING at any point in time... Fail. Take a good day or even a week to create your framework:

1) I will need to run a scanner --> program that2) Once the nmap output is done, I will need to try some brute forcing --> program that3) Once the nmap output is done, I will need to need to run nikto/wikto/etc. --> program that

Right a script to take realtime nmap output and fire away the moment you get data back to you. These are three simple core tasks you will NEED to do anyway. Practice it up on a lab. Take the core tasks and script them. No one said you couldn't do so. What I also have had for a hell of a long time is an pre-prepped arsenal of local exploits on who knows how many different machines. This enables to me to find specific exploits without having to run online and find em. E.g.:Linux/Local/Kernel/{2.3.12,2.4,2.6} Windows/Local/{XP,2003,NT,2007,7}

Another thing I am a stickler for are config files. Write a program to do the recon for you. Let's say you needed to escalate permissions... What is visible to you? You may NOT need to focus on root all the time. Can you sudo, are you in a misconfigured group? Can you find and read any configuration files? E.g. find / -name "*.conf" It is always good to have a game plan.

Thanks for the detailed feedback Sil! I was hoping for a reply from you

I'm pretty good at scripting / programming, so I should put my time and effort into a game plan. Use scripts when possible. Enumerate services and versions, make a script that matches possible exploits with running services on the target. I'll have my list of exploits for different kernel versions ready.

Another thing I've come to realize. Well, I don't consider myself to be a noob with Linux. I can script and pretty much get anything up and running. Though, when it comes to config files and such, I'm not sure which are valuable. But I guess that completely depends on the target machine. I guess I should do like you said, look for all the *.conf files using a script or command.

I realize that I could have done much better at my first attempt if I managed my time better, have a game plan at least. I didn't really prepare the first time, sadly. I think I should just really put all my effort in a plan while I'll practice the tools on Backtrack.

I wonder how different the exam will be hmm, hope they don't make it harder at least

All config files are to be viewed as valuable. Let's look at an Apache configuration file. (find / -name http*.conf (sometimes its httpd, sometimes not). Inside of a webserver, they may be calling some other function on another server. For config files like on a CMS (Joomla, etc.) those files are treasures since they often contain db usernames and passwords. Everything is fair game as are bash_history, .profile, .bashrc and others. Also don't forget users and groups:

... Don't solely focus on "root" otherwise you may miss out on other things. Helps to get root, but in a real world pentest, data is king. You will not meet a client who will tell you: "So what, you didn't get root, I don't care that you popped our Oracle DB."

Sil is right on. Pillage each box for as much info as possible. In a real life situation you'll likely run into password re-use or other juicy data that you get from all these places that you will use over and over.

Another point of Sil's I would emphasize is to organize your own set of local priv escalation exploits. There are so many different sploits, each depending on different apps on the box or different kernel versions... and finding them in a pinch while "the heat is on" might be a challenging task. If you use one in the lab, make sure you label it on your own box so you can get to the pwnage factor much faster