Last month I passed the Offensive Security Web Expert (OSWE) exam with full points after failing with zero points the month prior. I wanted to share my thoughts and experience from this journey to help others gauge their readiness.

What is the AWAE/OSWE?

Advanced Web Attacks and Exploitation (WEB-300) is Offensive Security’s advanced web application penetration testing course. The Offensive Security Web Expert (OSWE) is the certification earned upon successfully passing a grueling (and proctored) 48 hour practical exam with strict reporting requirements.

The AWAE course is focused on learning and applying white-box style methodologies, where students are provided full admin access to a target application’s operating system and codebase. White-box pentesting is heavily focused on source code review (with decompiling and debugging fully in-scope) to discover and exploit vulnerabilities that may not be as apparent through typical black-box style approaches, where limited or no information/access is provided to testers.

Important Prerequisites Before Registering

The AWAE/OSWE is an advanced level pentesting endeavor and should not be underestimated. Offsec lists several course prerequisites on the course page with their course syllabus going into more depth. As security enthusiasts come from a wide gamut of technical (and non-technical) backgrounds, your mileage may vary. 😄 Here are some of my recommendations:

  • Consider taking the Offensive Security Certified Professional (OSCP) course/exam first if you’re new to Offensive Security or not familiar with their “Try Harder” approach. This course/exam provides an excellent foundation across the broader scope of pentesting, although more focused on network/infrastructure with a light touch on webapps. I earned the OSCP in 2019 (pre-update) which really helped mentally prepare me for what to expect with the OSWE.
  • Be comfortable working with code because that’s the fun of this course. No, you don’t need to be a developer, however that experience is helpful. 😆 Source code review is arguably a standard practice for white-box pentesting and should not be a neglected skillset. Consider familiarizing yourself with PHP and Javascript for web, C# and Java for general purpose and Python for scripting. The last one is especially important as Python is used exclusively throughout the course to automate exploitation scenarios, with significant usage of the requests library.
    • Debugging experience is a bonus since this course takes a white-box perspective. Understanding how to analyze a value being passed and manipulated through different function calls is an imperative skillset for the course. Check out Visual Studio Code and focus on the basics like setting breakpoints, stepping through code blocks, and jumping into different functions.
  • Know how to use Burp Suite as an effective web proxy and “HTTP request tinkering tool”. The OWASP Zed Attack Proxy (ZAP) is a viable alternative however Burp Suite (Community) is used abundantly throughout the course. Focus on the basics like configuring your browser to proxy traffic, intercepting/modifying requests, encoding/decoding, and using the repeater tool.
  • Have experience with Kali Linux as this course is highly tailored to that environment for pentesting applications and developing exploits. It is an OffSec course after all and they’re not shy in using their own products. 😄 Kali also includes a few tools for this course by default, like Burp Suite.
  • Understand the basics of common web attack vectors and how they are leveraged from an attacker perspective. The OWASP Top 10 is a great resource to start from at a high level. Consider how these vulnerabilities and attack paths are used in different scenarios to disclose information and gain unauthorized access.
    • Another resource - the Web Security Academy by PortSwigger (Burp Suite devs) is a great learning platform to practice these techniques in a safe environment using Burp Suite. To note, The Web Application Hackers Handbook is often considered the de-facto guide for web application pentesting, however it has aged and is static in nature. As such, the Web Security Academy is considered Volume 3 or the spiritual successor, which is continuously updated, and in a modern format (online). Best of all, it’s free!

What’s Included in the Course?

As described on the course page, the provided materials include a 400+ page PDF, 10+ hours of video, and a private lab environment with several virtual machines to practice on, separated into ten modules. Each module is a guided experience, where the videos and PDF walk through different white-box scenarios, generally flowing from vulnerability discovery, to gaining admin access, ending in remote code execution (RCE). Virtual machines are configured in the lab environment for each module to practice on while following the PDF and videos. Each module also includes several “extra miles” which are optional exercises that expand on the module’s content by focusing on exploratory, unguided learning. There’s also a few extra lab machines that follow the “extra mile” mentality which are unguided as well.

At the time of this blog post (August 2021), the course materials were last updated in July 2020 when Offsec added 50% more content to include many new modern attack techniques. Keep this in mind when reviewing other AWAE/OSWE articles as many are before July 2020 and may not comprehensively reflect the updated content.

What is Required to Pass the OSWE Exam?

The OSWE exam includes a practical 48 hour challenge, requiring students to exploit two separate systems using white-box style pentesting in a virtual lab environment. The exam objectives are similar to the course methodology, focusing on gaining admin access through an authentication bypass, followed by remote code execution. The 48 hour challenge is also a proctored experience, requiring students to share their screens and be monitored during those 48 hours. You’re encouraged to take breaks, eat, drink, sleep, go for walks, etc. You can still live your life, but you need to let the proctor know every time you need to step away from your computer, like using the restroom. 😆

Students must achieve 85/100 points to pass, awarded through partial or full completion of the exam objectives. If enough points are gathered during the practical challenge, then there is an additional 24 hour period where students are required to document their findings in the form of an official pentest report. The OSWE reporting requirements are very strict and should not be taken lightly. Failing to follow these requirements can result in a complete failure of the exam.

Ultimately, the OSWE exam is a 72+ hour endeavor. OffSec provides an OSWE Exam FAQ and OSWE Exam Guide which are great resources to learn more.

The Journey Begins…

I signed up for 90 days of lab time and started working through the course materials around the middle of March 2021. I studied for about 2-6 hours almost everyday, usually spending a week on each module. My general workflow would be to watch the videos for an exercise, then read the PDF content, then do the exercise, respectively.

With help from the OffSec forums, I finished all the extra miles and two of the extra lab machines. I took meticulous notes and tried to “templatize” all the scripts throughout the course, during each iteration of an exercise. At the end of the 90 days, I thought surely I was ready… 😆

OSWE Exam Attempt #1 (Failed)

For some background context, I passed the OSCP exam on the first try in 2019 (pre-update) and hold many industry certs and a few IT/cybersecurity degrees. At the time of this exam attempt, I had been working professionally in cybersecurity for the past 6 years with about 2-3 years of sysadmin and a little software development experience prior. Over the past 8 months, I had been in a pentesting/appsec role with some code review work.

Despite my recent studies and background, I finished the exam unable to exploit anything on either of the machines. I knew it was going to be a challenge, but I didn’t realize how difficult the experience would be without the guided learning and hand-holding we get from the course content and helpful forum posts. It made me realize I went into the exam with a false sense of confidence, as I had just finished studying for 3+ months and thought I had a good methodology and library of scripts that followed the course material. Overall I ended up feeling like I saw several “potential” doors, but couldn’t get any of them to budge in my favor.

Now I’m no stranger to the Offsec experience. I know that there can be rabbit holes and red herrings. I understand the “try harder” mentality, but it was all too easy for me to misinterpret when was time to shift focus to another avenue. With the first machine, I recognized an auth-bypass vulnerability very early on which I recalled from the course material. This was very exciting however, there was an extra layer of complexity which led me to believe I was looking in the wrong spot. But since I was unable to find any other feasible paths, I convinced myself that this must be the way, even though I was probably beating a dead horse. I refused to look at the other machine until the next day since I felt so close on the first auth-bypass and knew I had to exploit it to pass the exam. For the other machine, I was unable to find a solid auth-bypass route which left me doing more black-box style testing, despite reading practically every line of source code. I had many hunches here and recognized a few potential doors, but nothing worked out. Ironically, after all the source code review on both machines, I feel that I identified the RCE routes I would need to take but was unable to even get to that stage to start testing since I couldn’t get past the auth-bypass. 😞

The Studying Resumes…

I ended up purchasing another 30 days of lab time and went through all the course material again. This time I watched all the videos for each module first, from start to finish, to get the “full picture” before diving into that specific lab module. This really helped me put the pieces together and not be as fragmented on methodology. From my experience, OffSec doesn’t go into as much detail on vulnerability discovery as they do on exploitation in the course materials. For the discovery portions in the exercises, I tried to spend more time poking around without the course guide to see if I could come to a similar conclusion and identify where some pitfalls might be in my recon. Overall, I really tried to focus more on the methodology going through the course material again to drill that into my brain. This was after realizing how many notes I had on what to do after a vulnerability is discovered, but not as much on the before.

I also challenged myself to rewrite all the scripts and PoCs throughout the course in Python 3 (when applicable). As Offsec updated the course content in 2020, much of the legacy scripts were in Python 2. This provided a good exploratory learning opportunity to improve on scripting skills. I particularly focused on implementing new functionalities like argparse and f-strings to help streamline the I/O of data as it gets passed around.

For some supplementary material, I checked out a few other AWAE/OSWE resources and blog posts with curated content which I included below. Walking through additional exploitation scenarios was especially helpful to see the logical thought process of vulnerability discovery and building an exploit chain.

OSWE Exam Attempt #2 (Passed)

I scheduled the second attempt roughly 6 weeks after the first one and also made sure to choose an earlier start time (7:00 AM) since that worked better for my sleep schedule and I could start first thing in the morning. Although 48 hours is an adequate amount of time for this exam, managing that time effectively is imperative, especially if you find yourself going down rabbit holes like I did (again).

Day #1

Speaking of rabbits, this time I chased one for about 17 hours before I had a breakthrough and achieved the auth-bypass on the first machine. Ironically, this discovery was nearly accidental, and I had a glorious facepalm moment. 😑 At about 1:30 AM, I retrieved the local.txt flag.

This was a good stopping point for me to get some sleep as I was practically working non-stop since 7:00 AM in near-desperation. 😆 I was already a bit worried given how long it took to get to this point. Although I took several 15 minute breaks throughout the first day and was staying hydrated, I had a little too much caffeine, as my brain was racing for another hour or two before I actually fell asleep.

Day #2

With about 3 hours of sleep and a long way to go on the exam, I knew this was going to be a fun day… I resumed the exam around 6:15 AM and continued to plug away at the first machine, now focusing on the RCE. Thankfully, I was able to narrow in on the vulnerability relatively quickly, and didn’t fall into any rabbit holes this time. After about 3 hours of testing, I retrieved the proof.txt flag. This was a nice boost of energy! 😄

I started on the second machine at about 11:30 AM on the second day. Again, I chased another rabbit for several hours before I got back on track. I was nervous given the ticking clock but with all the adrenaline and caffeine, my focus was still strong. Nearly 12 hours later, I achieved the auth-bypass and retrieved the local.txt flag. At about 1:30 AM with 6.5 hours to go, I had to make a decision whether it would be worth pursuing the RCE or call it quits and focus on the screenshots and notes, given the remaining time and my current level of exhaustion. Although I had enough points to pass the exam at this point, I wanted to give myself some extra buffer if possible.

Luckily, I already had a good hunch where the RCE vulnerability was based on some discoveries made while investigating the auth-bypass. After another 1.5 hours, I achieved the RCE and retrieved the proof.txt flag, at about 3:00 AM. With 4 hours to go in sheer adrenaline, I spent the next 1.5 hours making sure I had all my screenshots and notes in order, and triple checked my PoCs before I signed off at about 4:30 AM. 😵

Day #3 (Reporting)

Now running on fumes with around 8 hours of combined sleep over the past few nights, I started writing the exam report at about 9:00 AM. I recalled the strict reporting requirements for when I did the OSCP in 2019, and the OSWE reporting was no different, if not more strict. This was nerve racking because it’s entirely possible to fail your exam from a bad report even if you completed all the exam objectives.

I spent about 10 hours writing the report, and submitted it about 7:30 PM that evening. It took longer than I expected but I tried to be as verbose as possible to not take any chances. I was so exhausted that I freaked myself out later that evening when I realized I did a “Print to PDF” rather than “Save as PDF”, which has a slight affect on image quality. For the next 24 hours I was in a panic state because some of the screenshots looked a tad blurry although still legible. I look back now at how silly that was, but that was the state of mind I was in after 72 hours of mental (and physical) chaos.

I submitted the exam report on a Saturday evening and received the official passing email about 24 hours later! OffSec was extremely fast in providing results and I was surprised as the results came in on a Sunday evening.

OSWE Achievement Unlocked! 😎

Offensive Security Web Expert (OSWE) badge

Course Takeaways

  • Do the extra miles and the extra lab machines. Aside from the actual exam, the exploratory learning for this course was by far the best opportunity to understand skill gaps and make improvements. Consider it standard practice to go through this material for the complete experience. I should have spent more time on these exercises to really understand the concepts.

  • Consider working on the lab machines without the course guide. Starting from square one. When I signed up for another 30 days of lab time after the first fail, I focused on doing this myself. Spending more time on vulnerability discovery and poking around without the guided learning was a great opportunity to tinker and explore. The lab machines are much more difficult without the PDF. 😄

  • Consider supplementing your learning with extra material. Even though the course materials provide everything needed for the exam experience, going through other material helped me better understand the concepts taught in the course. Especially reading other webapp vulnerability reports, focusing on discovery and building an exploit chain. Also using other vulnerable examples in practice labs to demonstrate the same concepts and not getting tunnel vision on one scenario.

  • Signup for as much lab time as you can and don’t rush through it. There’s a lot of course content, especially when you start digging into the extra miles which can take quite a bit of time depending on your experience. It’s imperative to be able to study a couple hours a night to keep the momentum going. This was challenging for me with a full time job and family responsibilities. 90+ days is recommended. Make sure you have your affairs in order and support from those close to you in this endeavor.

Exam Takeaways

  • Building on my methodology was key to success. I strongly encourage others struggling with this to try taking step back from the details and look at the targets holistically. Thinking about potential exploit scenarios that “make sense” and follow what’s taught in the course content will help you focus.

  • Tunnel vision is no joke. I agree with what others experience on the rabbit holes - these are there to test your methodology and your ability to avoid distractions. A vulnerability may exist but if it’s not accessible or the stars don’t align, look elsewhere.

  • Be comfortable with navigating through the unknown. “Try harder”, don’t give up, but give yourself the time you need to learn the concepts. The exam provides adequate time to find and exploit the vulnerabilities given a solid methodology and understanding of what’s presented to you.

  • Don’t put the cart before the horse. Be sure to approach a problem/vulnerability holistically and have an overall exploitation scenario in mind before you start digging in. Don’t focus on an RCE vulnerability if the access isn’t there. Make sure you have a solid methodology based on the indicators you see.

  • Be confident with your scripting abilities. It’s very frustrating to be in the middle of automating an exploit when you get stuck on trivial syntax issues or elementary programming principles. In the context of OSWE, scripting is just as important as finding and exploiting the vulnerabilities. For Python, the usage of the requests library, regex, hashlib, itertools, and threading are some good ones to understand.

  • Be confident with your debugging abilities. Understand setting up and working with both local and remote debugging environments as taught in the course materials. Being able to see how a value is passed and manipulated through different function calls is imperative for a whitebox assessment. Same goes for logging, be sure to know how to turn it on and where logs are stored. Use the whitebox access to your advantage and utilize all the information available.

Conclusion

Overall, this was another amazing experience from Offensive Security. The content was awesome and the exam was challenging. I absolutely recommend this course for security enthusiasts interested in web application security, white-box assessments and penetration testing. Looking forward to the next OffSec challenge with their recently added course for Evasion Techniques and Breaching Defenses. 😎