OSCP-Strategy-Guide - OSCP strategy guide PDF

Preview

Summary

OSCP strategy guide...

Description

Table of Contents Introduction Documentation Folder Structure Pro-Tip: Use the Screenshots Folder! Exam Scheduling Preparation Strategy Strategy 1 - High Down Strategy 2 - Low Up My Strategy Enumeration Service Discovery Version Enumeration SearchSploit / Exploit-DB SMB Enumeration Authentication Enumeration Web Enumeration Other Web Enumeration Tools Initial Foothold Web Shells Linux Shells Windows Shells FTP Server Local Python Web Server Privilege Escalation Linux Windows Buffer Overflows Fuzz for an overflow Find the EIP offset Prove control of the EIP/ESP contents Discover bad characters Find way of jumping to ESP Generate your shellcode Smash the stack for fun and profit! Checklists Enumeration Checklist - Template Privilege Escalation Checklists Linux Template Windows Template Buffer Overflow Checklist - Template Full Example Checklist Appendix Tools and Resources Scripts Practice Machines

Introduction Hello. First, I just want to say, you made the right choice. When offensive security professionals begin our journey, we are like mad people. Scanning, throwing exploits, running code, and hammering boxes with things that might not even make any sense. Then we grow, we learn, and we develop methodologies for our attacks. Some hackers develop their own methodology from scratch, but most security professionals learn from and borrow the methodology of others. Regardless of how you gain your methodology, it is what will separate you from your peers. So congratulations on taking this crucial step on growing your offensive security mindset! Before we get into this, I want to hopefully reconfirm some new thoughts about what this guide is, and what it isn't. This guide IS just that. A guide. Take the knowledge here and make it your own, evolve this boilerplate process and run with it. This should simply be used as a starting point to guide your thought process when attacking a machine. You are in control, this guide will not solve all of your problems. This document mainly serves as a guardrail, keeping you on track, focused, and methodical when things start breaking down and you feel like picking up the kitchen sink and throwing it at a host. This guide IS NOT a one stop shop to hacking any machine out there. This guide will not replace practice, experience, or determination when learning how to become a better security professional. It is not a "cheat" guide that will allow you to know everything needed to pass a certification. This is simply a reference. Use it properly, and it will launch you to the next step in your journey. Now that we're all on the same page, I'm so excited to share with you what I believe to be a very valuable resource for those of us still struggling to refine our process. Notice that I used the pronoun us there. That is because this is a never-ending process. Your methodology will grow, evolve, and adapt the same as mine. We should never cease to continue learning. That is what makes this field so special. So again, I'm so excited you're here, and I can't wait to dive in with you, so let's get to it!

Documentation I know this is still technically the "boring" stuff, but hey, documentation is probably the MOST important part of a penetration test. That's why companies like Offensive Security put an emphasis on well-written reports as part of their exam process. If you can't effectively tell someone else how you compromised a system, then what good did you really do? This idea becomes even more amplified in the real world. When you deliver a report to a CEO who doesn't understand what all of this "cyber" stuff is about, you better be able to articulate WHY what you did is so important. Is it because you compromised the Django application and were able to pivot through the web server to gain access to a SQL database? No, the CEO doesn't care about that. The CEO cares about the fact that a hacker (or penetration tester) was able to gain access to sensitive personally identifiable information that was in possession of his/her company. That will make headlines, and that will cause the CEO a huge headache. So, that's what they care about. Knowing your audience is the first step to being able to document your projects well. The second part of being able to document your projects well is, well, documenting! Many times when a new tester is hacking away, they make the assumption that, "I will remember how I did this when it comes time to write the report". When report writing time comes, they panic because they can't quite remember why they were even enumerating where they were, or what made them try a specific trick or technique. At this point, it's too late. You don't always have time to go back and figure it out again. Documenting as you go is CRUCIAL to writing a timely and informative report. Especially when it comes to exams like the OSCP, you don't have time to waste! Having a solid documentation plan before you start is a solid way to keep you on track and keep the information gathering flowing for the entirety of an engagement.

Folder Structure The plan that I used during my OSCP, OSCE, SLAE, and many real-world engagements, is a flexible folder structure to document as I go. This allows me to have specific places that I expect data to exist if I have already performed some action. If it doesn't exist there, it's just a reminder that I haven't completed that task yet. The folder structure has to be flexible enough to adapt, while still rigid enough to serve as part of your overall methodology. The simple structure I've used time and time again is shown below.

assessment/ ├── 10.10.1.100/ │ ├── enumeration/ │ │ ├── 443/ │ │ ├── 445/ │ │ ├── 80/ │ │ └── scans/ │ ├── loot/ │ ├── notes.md │ ├── post-exploitation/ │ └── screenshots/ └── 10.10.1.115 ├── enumeration/ │ ├── 10000/ │ ├── 8080/ │ └── scans/ ├── loot/ ├── notes.md ├── post-exploitation/ └── screenshots/

# # # #

A folder to hold everything for a particular enagement Each host has it's own folder Every piece of enumeration will go here Break enumeration down by port

# # # # #

All port scans go here Holds any loot obtained from the host Notes for your sanity :) Any exploits or documents pertaining to post-exploitation activity (privesc) A million screenshots!!

Using a structure like this, you are better equipped to answer the question of, "Did I run that scan?" You will always know where to expect what data, and it's flexible enough to adapt to most hosts well. Try implementing this today, and just see how it feels. It may feel tedious at first, but break out those bash skills and write a quick script to set up folders for new hosts :) From there, you are beginning to build your own methodology!

Pro-Tip: Use the Screenshots Folder!

Those screenshots folders aren't there to just look pretty. USE THEM! Seriously, even if all you did was see a new interesting parameter on a web page, screenshot it right then! Don't wait until later. The tendency is to not screenshot anything until you have the whole box compromised. That is a bad move. You never know how much time will pass between the initial discovery of something and a full compromise. Screenshot frequently, and screenshot often. This will give you peace of mind when your engagement is coming up on time to quit.

Exam Up until this point, all of the advice given can be applied to any type of offensive engagements. Now, we're going to focus specifically on the OSCP exam. Remember, this is not a silver bullet, and this is not a way to skip the hours of practice and preparation needed to pass the exam. This is simply a strategy. Ideally, you will have a week or more to practice this methodology before your exam. Don't just show up and try it, you will likely get confused and it could become burdensome. This should be a part of your toolkit, but do not rely on this to be your golden ticket!

Scheduling A lot of people ask what times are best to schedule the exam. Honestly, it depends on your daily rhythms. When I took my Offensive Security exams, I scheduled them to start at 8am. That's because I knew I would be working well into the night, and I wanted to go to bed (or not) knowing where I stood with the exam. Some people schedule it close to 8pm, get a start on it, go to sleep, and then wake up and finish the next day. Some people start it at night with plans on not sleeping. What I've seen work best is when people use their normal waking hours to accomplish as much of the exam as possible, and usually people are too excited or nervous to go to sleep during the exam. My ultimate advice, is to schedule it to start as early as you normally would wake up, and see how far you can get before needing to sleep.

Preparation You're going to want to prepare in multiple ways. I previously mentioned the fact that you should practice using these strategies and tools discussed here well before entering the exam. With that being said, there are some resources that you can use to practice outside of the PWK lab machines in the appendix. But of course, if you've been in the PWK labs for long enough, you likely have either already practiced a ton, or you're just ready for the exam. So, how do you continue to prepare? On the day before your exam, make sure you have all your notes, and then just relax. Seriously, eat some good food, get outside, enjoy yourself, and don't sweat the exam. You'll be dealing with it for a full 24 hours tomorrow. Let your brain recover for a day before it starts.

Strategy When your test arrives, you'll want a plan of attack. I'm sure you've read enough online reviews by this point to know that there are five boxes on the exam. With a passing grade being based on the number of points you acquire over the 24-hour period, you'll want to focus on a strategy that provides you the best opportunity to obtain the most points possible in the shortest amount of time. There are a few strategies you can take.

Strategy 1 - High Down In this strategy, you attack the boxes with the highest points first. For example, if there are two 25-point boxes, two 20-point boxes, and a 10-point box, then you will try to compromise the boxes in that order. If done successfully, this strategy allows you to accumulate points in a way that can build confidence for the remaining boxes. It also allows you to be able to gauge what type of time commitment you're looking at. If you already have 50 points after the first 4 hours, then you'll be feeling really good! However, be warned that if you stumble, it can also bring your confidence down and you can be left wondering how on earth you're going to be able to pass an exam where you struggle so much with the first few boxes.

Strategy 2 - Low Up This is the strategy that I see a lot of people take when they fail. Now, I'm not saying this strategy causes people to fail, I think it's more of a confidence issue. People who take this strategy GENERALLY are more uncomfortable with how the test will go. So, they line up the lowest point box first assuming it will be the easiest, and they try to work up to the hardest boxes. The problem with this is, if you spend 8 hours on a lower point box, then you are in a much worse off spot than if you spent 8 hours

on the highest point box (assuming you get it after 8 hours). However, it can be a huge confident boost if the lower point boxes do wind up being easier. They can help knock off the nerves so that you have focus by the time you escalate.

My Strategy When I took the exam I went with the High Down strategy, but with a caveat. I knew going in that I wanted to crush it, and my thought process was that if I couldn't get the highest point boxes, then I would be in danger either way. BUT, here's where practice pays off. I knew that if I stared at a box for too long making no progress, that I would eventually miss something small (it happened enough times in the labs). So, I had a hard rule. If I made zero progress after 3.5 hours on a box, I would move on to the next in the list, and come back to this one fresh later. This kept a fresh mindset up, and I didn't feel pressure to solve each box because I knew that if I really got stuck, I would just move to the next one. Again, there are situations that can happen to make this back fire (such as making no progress on all boxes), but if that happens then you probably aren't ready for the test. If that happened to you, that's okay! We've all been in situations where we weren't really ready. The trick is to never give up. If you have failed an exam, hopefully you took good notes! Look back at them, what parts did you do well in? Which parts did you struggle the most? Recon? Initial access? Privilege escalation? Assuming you have those takeaways at hand, you can begin preparing for your next (and hopefully last) attempt using the next few sections!

Enumeration Enumeration is THE most important part of attacking anything! Seriously, if you didn't know it before, adopt it as absolute truth right now. You'll continue to learn this in more depth the more experience you get, but I'm trying to save you a hard lesson learned :) While I was going through the OSCP, I hung around the IRC rooms, and I wouldn't constantly see responses such as, "You missed something. Enumerate, enumerate, enumerate!" And many times when I felt stuck, it turned out that I had not fully enumerated everything, and further enumeration made what felt like a hard problem extremely easy! With any new attack surface such as a new box, a new domain, a new service discovered, the enumeration process will start over and you'll want to fully enumerate the newly discovered asset. Different types of assets will have different enumeration processes, but the important part is that you have a process for each type of asset you will encounter. If you encounter an asset you don't have a process for, create one immediately! The more experience you gain with that type of asset, the more you can mature your enumeration process for it. But at least the next time you run into that type of device or service, you'll have a starting ground. In this guide we're going to cover the most basic types of assets you'll need to enumerate: unknown hosts, web services, and smb services. We'll also get into enumerating linux machines and windows machines, but that will come later in the privilege escalation section. Any further processes for enumeration will be an exercise for the reader!

Service Discovery When you're beginning to attempt to hack a machine, you'll always start with basic service discovery. The goal of this stage is to learn what services are running on the device so that you can begin to understand which potential avenues exist to exploit. The main tool you will use in this phase is nmap. My personal favorite way of doing this phase involves two scans. One quick TCP port scan, and one quick UDP port scan. The nmap commands I use for this can be seen below: Quick TCP Nmap Scan

nmap -Pn -sS --stats-every 3m --max-retries 1 --max-scan-delay 20 \ --defeat-rst-ratelimit -T4 -p1-65535 -oA tcp-quick 10.1.1.100

Quick UDP Nmap Scan

nmap -Pn --top-ports 1000 -sU --stats-every 3m --max-retries 1 -T3 \ -oA udp-quick 10.1.1.100

From here, we should have most information we need to continue attacking the host. If we truly want to build this into our enumeration process, we can write quick bash scripts to run these commands for us so that we aren't constantly having to copy and paste these long commands. nmap-tcp-quick.sh

#!/bin/bash if [ $# -ne 2 ]; then echo "Usage: nmap-tcp-quick.sh " exit 1 fi

nmap -Pn -sS --stats-every 3m --max-retries 1 --max-scan-delay 20 \ --defeat-rst-ratelimit -T4 -p1-65535 -oA $2 $1

nmap-udp-quick.sh

#!/bin/bash if [ $# -ne 2 ]; then echo "Usage: nmap-udp-quick.sh " exit 1 fi nmap -Pn --top-ports 1000 -sU --stats-every 3m --max-retries 1 -T3 \ -oA $2 $1

Adding these scripts somewhere in our $PATH will allow us to run them from anywhere. Remembering our referenced directory structure above, the results of these scans would be saved in the assessment/10.1.1.100/enumeration/scans/ folder.

Version Enumeration In the version enumeration portion, you are ready to start digging deeper into the results of our quick port scans done in the previous step. The goal of this step is to discover the actual service running on any open ports discovered, and to determine as much detail as possible about the service in general. We can, again, use nmap to accomplish this using the following command. Full TCP Nmap Scan

nmap -nvv -Pn -sSV -T1 -p$(cat tcp-quick-results.xml | grep portid | grep protocol=\"tcp\" | \ cut -d'"' -f4 | paste -sd "," -) --version-intensity 9 -A -oA tcp-full 10.1.1.100

For this scan, you will need the output from the previous scan stored in a file called tcp-quick-results.xml. This basically allows you to only trigger full version scans on already discovered open ports. If you've found nothing juicy so far, it may rarely be beneficial to run a full UDP port scan. This is very rarely necessary, but it is worth noting. Full UDP Nmap Scan

nmap -Pn -p1-65535 -sU --stats-every 3m --max-retries 1 -T3 -oA udp-full 10.1.1.100

Converting the commands into scripts, we get the following files: nmap-tcp-full.sh

#!/bin/bash if [ "$#" -ne 3 ]; then echo "Usage: nmap-tcp-full.sh " exit 1 fi nmap -nvv -Pn -sSV -T1 -p$(cat $1 | grep portid | grep protocol=\"tcp\" | \ cut -d'"' -f4 | paste -sd "," -) --version-intensity 9 -A -oA $3 $2

nmap-udp-full.sh

#!/bin/bash if [ $# -ne 2 ]; then echo "Usage: nmap-udp-full.sh " exit 1 fi nmap -Pn -p1-65535 -sU --stats-every 3m --max-retries 1 -T3 -oA $2 $1

Exploit Search At this point, you have services running and hopefully their versions. This is a great time to use the searchsploit tool or Exploit-DB.com to search for exploits relevant to the versions running. If you see versions that have exact matches, you know you've found something worth digging into!

SMB Enumeration Server Message Block (SMB) services will always be a hotspot for enumeration. If you see it, you'll want to check it for vulnerabilities, and then check for general information. I use the following commands: SMB Vuln Scan

nmap -p 445 --script smb-vuln* 10.1.1.100

SMB Share Enumeration

smbclient -L 10.1.1.100 enum4linux 10.1.1.100 smbclient \\\\10.1.1.100\shareName

Authentication Enumeration Any authentication portal you see should be something you check quickly at the very least. I hesitate to say, at least for OSCP, that you'll need any hardcore brute forcing, my advice would be to always perform the following simple checks, adding any usernames or passwords that are main titles of the page/application: Username:Password Combos

admin:admin admin:password administrator:administrator administrator:password

Web Enumeration When confronted with a web service, there are always four things you want to do, and they mostly revolve around discovering unknown portions of the website being served. The easiest way to do that is to browse to the /robots.txt path of the website to check and see if any directories or files are hidden from search engines.

The next two things to do are tools to run to increase visibility. nikto is the first tool, and you will generally get very basic information from this tool. Nikto

nikto -host 10.1.1.100

The next thing you want to run is a tool called gobuster. It is a very fast version of dirbuster, which you were probably introduced to in the labs. You will want to use with several wordlists. However, my top three wordlists are listed below in the gobuster setup instructions.

GoBuster

# If you don't already have GoLang installed apt-get install golang echo 'export GOPATH=/root/go-workspace' >> ~/.bashrc echo 'export PATH=$PATH:$GOPATH/bin' >> ~/.bashrc source ~/.bashrc # Installing gobuster go get github.com/OJ/gobuste...