oswe vs oscp
OSCP is a beginner-friendly course, compared to that of the OSWE, that focuses more on the breadth of knowledge rather than depth. While OSWE is more specialized and advanced.
With OSCP, the goal was to find a vulnerable service, look for a public exploit of that service, tweak the exploit a bit, and repeat until you get root. The process involved a lot of google searches for public exploits on discovered versions of services. While with OSWE, the goal was to discover the vulnerable functionality with the help of the source code, build an exploit for it based on how the source code processes the input, and script the entire exploit chain to gain a reverse shell.
Since I’ve got an extensive background in Software Development and have played tons of CTFs with Source Code Review based challenges, I found OSWE easier than OSCP. I believe the general opinion is otherwise. This may have been because OSCP was my first certification, and I did not have enough exposure to HackTheBox (etc) before starting the course. While with OSWE, I had quite a bit of relevant experience.
However, in terms of knowledge and things I took back home, I would give OSWE the points here, as the skills gained were more practical and much more applicable in a real-world scenario compared to what I learned in OSCP.
OSWE vs OSCP is a common discussion – let’s take a quick look over a Reddit discussion:
Amongst the top upvoted responses were as follows, take from it what you will:
OSWE is an “expert” level certificate. If you compare it to HTB boxes, it will definitely be around Hard/Insane difficulty, while OSCP/PWK would be around Easy/Medium difficulty.
It is not required to have the OSCP certification in order to attempt the OSWE. However, it is recommended to go for the OSCP first, as it would inevitably give you a strong base for your pentest skills. Think of the OSWE as a specialization in Web Applications.
Ever since I completed the OSCP, I feared I’d miss the thrill of Offsec Certifications; which is why I decided that the OSWE would be a good course to re-live the thrill of learning and trying harder all over again!
Now that I’ve completed the OSWE Certification in the first exam attempt, I decided to write a semi-technical guide for the AWAE Course by Offensive Security. Thus, in this blog, I’ll be going over the certification, my approach, and some tips that hopefully help you in cracking the OSWE Exam!
P.S. Some parts of this blog may be vague – to not disclose excessive details about the course.
As per Offensive Security, the OSWE Certification (AWAE Course) is described as:
Advanced Web Attacks and Exploitation (WEB-300) is an advanced web application security review course. We teach the skills needed to conduct white box web app penetration tests.
On earning the certification, you would have a clear and practical understanding of white box web application assessment and security. You’d have proven your ability to review advanced source code in web apps, identify vulnerabilities, and exploit them. You would also be able to assist web development teams in creating and maintaining web apps that are secure by design.
Back when I registered for the course in Sept’21, the course was being offered for 1299$ with 60 days of lab time, and 1499$ for 90 days of lab time. I had opted for the 60 days lab version, which I believe is ideal for those who work or study full-time. Offensive Security has now launched a subscription-based model, and more information on that can be obtained here.
Just like any other Offensive Security course, I was given a Course Manual, and accompanying video lessons as the preparation material for the course. The material was really important, as it allowed me to build a methodology to tackle the exam labs, taught many new and creative attack vectors, and highlighted the importance of debugging & logging.
I was also given access to a lab environment that had 2 types of labs:
These labs were fairly doable in the 60 days timeframe considering that I had a full-time job on the side. However, now with the new subscription model, I believe time would not be an issue.
Offensive Security doesn’t impose any mandatory pre-requisites for this course, however, from a technical standpoint, the course would be much more manageable if you have prior experience in programming (specifically using any MVC based Web Framework), scripting, and Web Security concepts.
If you’re new to Web Development, it would take you additional time to understand the architecture of a web application, and it may be overwhelming to do so during the course due to the wide range of programming languages and frameworks that are covered. Thus, before starting the course, I would recommend you to take up a small project of building a Full-Stack Web Application using an MVC Framework. Some examples of such frameworks are mentioned below:
Scripting wise, from the perspective of this course, you should be able to mimic GET/POST/Websocket requests, and workflows right from your script. The aim of the course is not only to discover vulnerabilities but also to automate the entire exploitation process (from Authentication Bypass to RCE) with a single script that requires no manual interaction. A few important Python libraries that you’d be using throughout the course:
If you’re a Cyber Security Professional looking to get a jump start into White Box Assessments of Web Applications; or if you’re a Software Engineer looking to expand your horizon on Web Security, this course is for you!
Since this is a fairly new course, the industry-wide recognition of this course doesn’t match that of the OSCP. I’ve seen many Job Descriptions mentioning OSWE as an optional requirement, but never as a mandatory requirement. However, the presence of this badge on your profile will have a good impression on a technical recruiter since this is an advanced-level course. But it may not always be the “wow” factor.
For Software Engineers, this certification would be a very unique add-on, and recruiters would appreciate and acknowledge your ability to write secure code.
I signed up for the course solely for the learning (and also the thrill!).
I began the 60 days of lab access on 12th September and spent the first day reading the introductory portion of the course manual. I jumped right into the labs the following day as the introductory material was straightforward, and mostly comprised of topics that security professionals are generally aware of.
On weekdays, I spent around 4-5 hours on labs, while on weekends, around 6-7 hours. This pace was enough for me to complete the guided labs, their extra miles, and my notes by 9th October. I had to end up pausing my preparation until 18th October, as I got sick. The timing couldn’t have been any worse, right? Luckily, I had enough time remaining for the un-guided labs, so I decided to rest well before getting back to work!
After a short, but seemingly long break, I was back at it, and completed the un-guided labs on 23rd October. I registered for my exam for 29th October as I estimated that I would be done with the revision, notes refining, and a little rest by then. I booked the date quite close to when I completed the course, as I was told that the un-guided labs are very close to what the actual exam format is, thus, having completed those labs, I was ready for the exam.
You’re given 48 hours to complete the machines given in the exam, and an additional 24 hours to complete the report where you describe your methodology, exploit, PoC script (that replicates the entire exploit chain), and screenshots to prove that you actually pwned the machines!
I booked my exam for 10 AM, as I was accustomed to waking up at around 9:15 AM. It is ideal that you get a good night’s sleep and preferably set the exam at a time when you can wake up without an alarm. Some people do prefer starting the exam late at night due to the peace and quiet in and around their household. However, I had a headphone on me at all times, so that wasn’t a requirement.
Before the exam, you need to make sure you have these ready:
The proctored session requires you to provide an ID proof via the webcam, which is why a good quality webcam is required. In my case, the ID wasn’t clearly visible on the webcam, so I had to show a scanned copy of the ID via my shared screen. The verification process starts 15 minutes prior to the exam start, so keep everything ready well in advance!
During the exam, be sure to take breaks whenever you’re stuck, and sleep if required. Don’t hesitate to take breaks because you feel you’ve taken many. I took a break roughly after 2 hours to freshen up, and get a small bite to eat. That helped me come back with a new perspective, allowing me to question my thinking better. This is really important because sometimes, you keep re-iterating the same thought and never question your thought process on why you came to a conclusion.
I had faced something similar during the exam: I was going over the source code for one of the machines, and I had skipped over the actually vulnerable function twice just because I thought “nah, that wouldn’t be it“. The third time, just after I had gotten back from a short break, I questioned my assumption instantly and got through!
Also, don’t forget to take a screenshot of every step you take once you’ve found the intended exploit chain. Once you have all the screenshots, and code snippets all compiled, you can use the additional 24 hours provided to format your report with the information you’ve jotted down during the exam. I kept updating a rough version of the report during the exam itself and kept the formatting for later.
I had submitted the last flag with 15 hours left on the clock; that’s when I took a nice and long break to get into the reporting mode. The report in total took around 10 hours to complete, and I submitted it an hour after my exam ended. The paranoia kept forcing me to re-read the 50 page report until I couldn’t bother reading anymore.
In total, I slept for around 9 hours during the exam and managed to submit the final report in 49 hours from the exam start. The machines in the exam were similar to the labs, and covering all of the material in the course manual should be more than enough to be ready for the exam. All that remains is that you have a clear head, a good night’s sleep, and some patience to read through a lot of code!
Shifting gears to how I managed to clear the OSWE Exam from a technical standpoint, a good transition to this blog will be to go over my note taking process.
I used Obsidian as my notes app. This was my first time using the app, but I really loved the way it linked different aspects of my notes together. It is also equipped with a powerful search functionality, due to which I would definitely recommend using this as your primary notes app.
It is also important to keep a backup of your notes, and I used git for this purpose. Every few days, I’d just push the updated notes onto GitHub to have a backup, and a way to go back to old versions, if required.
I divided my notes into the following sections:
<ProgrammingLanguage> (<ExploitChain: SQL Injection to Deserialization to RCE>) <MachineName> - <IPAddress>
. This allowed me to quickly get a glance at the type of vulnerabilities covered for each programming language during the exam. This helps in prioritizing what vulnerabilities you should look for when you attack a target. This does not necessarily reduce the sample space, because there is no guarantee that the exploit chain for the programming language would be similar to what you’ve done in the labs, but it’s always a good place to start!readObject
& ObjectInputStream
– Deserialization (<Reference to a lab that covers this>).These sections were more than enough for me to revise, and refer to during the exam. I did not feel that anything was missing from the notes, and found the Nudges & Scripts sections the most helpful, as I mostly only opened my notes when I was stuck during the exam to make sure that I didn’t skip over any steps during my initial reconnaissance and discovery phases.
The course covered a wide variety of vulnerabilities from the OWASP Top 10 list, and in various web frameworks. We also went over various logical vulnerabilities that required creative exploit vectors, and were fun to discover!
Even though most of the vulnerabilities present in the labs/exam are conventional OWASP Top 10 based, the discovery phase is not that straightforward for them. In the next few bullet points, I’ll briefly go over my methodology, keeping in mind that I can’t disclose too much about the same. I will keep it simple because as you progress through the labs, you will start to develop a methodology of your own, and you won’t end up needing assistance! And this methodology can be carried over to actual White Box Assessments!
Although this course was really informative and well structured, I believe that some aspects of this course could have been slightly better. These are minor concerns that would not affect the preparation in any way, but would have made things slightly smoother in the entirety.
Regardless of these minor issues, which I’m sure will fade away as the course matures, the overall experience of the labs and the exam was very positive. The proctors were super friendly and responded instantly to any query that I had.
In general, the OSCP exam is well known for its difficulty, and it’s not the exam systems but rather the 24-hours time limit, which makes it challenging. Due to the continuous enumeration and exploitation of machines, the constant debugging of issues, the fatigue quickly builds up, which causes one’s concentration and efficiency to suffer. These eventually lead to more problems later on. To break this circle, the best advice I can give is to have a thorough plan to ensure you’ll always know what to do next, how much time you are willing to sink into a single problem, and document everything you need to do for compromising a host. The exam machines itself were up-to-date systems so that you couldn’t take the easy kernel exploit path like in the case of some of the lab machines. Difficulty-wise, I found that the exam machines were more difficult than the ones in the lab, but not by much. In the end, I managed to complete all the objectives and gain administrative shell access on all target machines. My final exam report was 38 pages long, and the lab report I submitted had 122 pages.
Even with its current shortcomings, I can safely recommend the AWAE/OSWE course. If you are willing to sink in the time, then anything the course explains in-depth, it does it exceptionally. It introduces techniques and chains of exploits, that open up new ways to look at vulnerabilities and makes that ticking in the back of your head asking how could this be used later on in unexpected ways. As for the problems I have with the course, I hope future updates to the course will address them. Until then, there are other courses available out there that nicely complement the AWAE course, although in a bit steeper price range. Consider this course as the start of a journey rather than the final goal.
Few closing words for people who are thinking about trying to get OSCP certified. While Offsec advertises its course as not beginner-friendly, I have to disagree. I think the most value of this certification is for people who want to break into InfoSec, like CS students or IT personnel at the beginning of their NetSec career, rather than seasoned pentesters. Definitely, don’t allow yourselves to become disheartened by the fame OSCP has and dive into the deep end. At the end of the day, the course is a test of discipline and determination above all else.
Return to Cybersecurity Academy
Read the latest Cybersecurity News Articles
parts of this article are sourced from theaveragenz.com
This post was last modified on 4 October 2022 6:10 PM
British high street chain WH Smith has recently revealed that it was hit by a…
As banks worldwide roll out Voice ID as a means of user authentication over the…
In the era of digital transformation, cybersecurity has become a major concern for businesses. When…
In today's digital age, cybersecurity threats have become a significant concern for businesses of all…
The RIG Exploit Kit is currently in the midst of its most productive phase, attempting…
One of the most transformational technologies of our time, artificial intelligence (AI), has quickly come…
Leave a Comment