The OSCE3 journey: The highs, the lows, and what the future holds.

1. Background

Prior to starting the OSCE3 journey, I had a reverse-engineering (RE) background. To me, RE was the greatest puzzle - no distractions, no massive suite of tools. Just your favourite disassembler and debugger.

It started from crackmes.one challenges, to random MalwareBazaar samples. I absolutely love the mystery of tearing apart malware, and imagining the malware author to be a nerd like myself.

2. The OSED

The OSED is the first of 3 certifications I obtained. Because of my RE background, it was the safe choice. Though, I had no experience in exploit development.

2.1. Study Plan

Because of work commitments, I could only study from about 6pm-12am. This continued for about the next 2 months. Throughout these months, the burnout kept creeping. But I couldn’t bear to rest. Study progress was tracked in simple table entries. In hindsight, I definitely blazed through the material, fueled by motivation, and partly because of existing RE experience.

Regardless, I set to maintain a routine of doing a little every day, no matter how I was feeling. Some days were good, managing 30+ pages of course material; others not so much. Only when the last chapter was cleared, I booked my exam.

Below is how I tracked my progression through the OSED course material. I had tried really hard not to miss any days, but sometimes life gets in the way.

2.2. Exam

To be honest, the exam was a breeze. In just under 14 hours, I had obtained enough points to pass. It was definitely more challenging than the labs. In fact, the exam binaries were the most challenging ones I had ever exploited.

Despite so, it wasn’t that hard. Exploitation was mostly straightforward. And once a few issues were overcome, a shell followed quickly.

It took 4 long, painful days for the results to arrive. But it was a relief to hear that I passed.

Tip: get familiar with building ROP chains out of messy gadgets.

2.3. Takeaways

I greatly enjoyed the course, and personally felt that I learnt a lot. The shellcoding section was the most interesting. It’s such a useful skill when needing something precise and custom. You could always use donut, but manual shellcoding can account for size and novelty requirements.

ROP chaining into WinAPI calls is cool, as well as working with the constraints of bad bytes and a limited overflow space.

The OSED serves as a great introductory course to Windows exploit development. But there is much more to learn. The course also taught me the study method that worked best for me: consistency.

Also, you’re forced to use WinDbg, which is a great debugging tool, but not newbie-friendly in any way. I’d say one of the major difficulties of the course is getting competent with WinDbg.

2.4. Conclusion

Despite greatly enjoying the course and its challenges, the OSED may be a course you’d want to consider carefully, depending on your circumstances. The course is expensive for the content it covers.

If it’s free - why not?

If you want the elusive (and expensive) OSCE3 - why not?

If it’s for the knowledge - evaluate if it’s worth the cost.

To a complete beginner, it is an excellent guided introduction to Windows binary exploitation. Expect to struggle as there is a fair bit of fundamentals to learn (assembly, memory, etc).

It seems that as of recent, there is a new VM escape chapter, if that interests you. Unfortunately, I no longer have access to it.

3. The OSEP

The OSEP was daunting. I had spent about a month considering whether to purchase the course. Prior to the purchase, I had no OSCP, no pentesting experience, no methodology, and frankly, no interest. My interests had always lie in RE. In the end, I purchased the Learn One plan, as I knew I’d have to take my time with the material.

Despite the lack of starting motivation, I recognized this massive gap in my knowledge, and set out to fill it. Also, if I wanted the OSCE3, then it must be done.

3.1. Study Plan

Immediately after purchasing the course, I hopped into TJ Null’s OSCP Proving Grounds list, to make up for the missing chunk of my pentesting knowledge.

It was brutal.

The first month was dedicated grinding out Proving Grounds boxes. I did 1-2 boxes per day, getting cluelessly stuck, running out of patience, reading writeups, and banging my head against the wall upon realizing that I had missed something simple.

Again, work commitments pushed daily study time to after 6pm. Throughout the month, I took notes and built up my methodology, wrote a massive mindmap-style cheatsheet, and then finally started on the OSEP course material.

I spent about 4 months on the course material, built custom payloads and familiarized myself with Sliver C2. Upon completion of course material, I purchased a HackTheBox VIP+ subscription and spent the last month grinding out boxes from the LainKusanagi list.

The mindmap contains a history of commands used in past boxes. It is a compilation of my pentesting knowledge. The flow chart structure helps to identify what to try next.

At some point, I had decided that the grind must stop. Doing back-to-back boxes daily, with few breaks, wasn’t great for mental health. And honestly, I’d very much rather be gaming. Studying for the OSEP made me truly understand that an Offsec certification is a marathon, not a race.

3.2. Exam

Personally, I found the exam difficult. Only after about 30 hours in, did I obtain enough flags to pass. But honestly, the roadblocks I faced were extremely simple and were pretty much the lowest-hanging fruits. Yet, I spent hours re-running the same commands in rotation, wondering if there was a bug in the exam environment. Perhaps it was a lack of sleep, or the exam stress.

After obtaining the 10th flag, I started on the report a little and called it a day. The OSEP seemed notorious for discrediting flags due to insufficient documentation. I spent another 24h (including breaks) on the report alone, grabbing screenshots and capturing command outputs, before finally feeling confident enough to submit.

I found that the difficulty of the exam lay in its OSCP components, rather than the evasion and AD components of the course.

3.3. Takeaways

I have now, a newfound love for red-team tooling and techniques. Windows internals are riddled with subtle, abusable features that, for someone like me, has infinite avenues for Cybersecurity research.

You can find some of my research into ETW in my blog - A Stealthier Reflective Loading - where I discuss a novel technique to patch ETW and AMSI, without modifying memory protections.

3.4. Conclusion

The OSEP, naturally, is a continuation of the OSCP. Expect to see OSCP components, along with a focus on C2, evasion, and AD technologies.

Learners are encouraged to develop custom tools and phishing payloads, because common ones may be flagged by the AV.

However, the OSEP is, as stated, a pentesting certification. It barely scratches the surface of red-team techniques, and official released exam sets have shown the need to be noisy (port scanning, credential spraying, etc).

4. The OSWE

This certification was sponsored by The Digital and Intelligence Service, my current employer, and I am grateful that I didn’t have to fork out more of my own $$$.

4.1. Rant

Unfortunately, at this point, I was already burnt out of the certification grind. Though, I could not rest yet. The OSWE was the last remaining hurdle. And there’s a reason I left it for last - I kinda hate web.

I find web frameworks confusing. They are layers of abstraction, on top of stacks of security mitigations. These exist on the frontend as well (CORS, SameSite, …). As opposed to lower-level reversing, strange behaviours are easier explained by simply - reversing.

Take this potentially vulnerable code as example. If an attacker controls xmlInput, an XXE injection could be possible.

XmlDocument xmlDoc = new XmlDocument();
xmlDoc.LoadXml(xmlInput);

However, with these settings applied beforehand, the XXE injection is no longer possible.

var settings = new XmlReaderSettings
{
    DtdProcessing = DtdProcessing.Prohibit,
    XmlResolver = null
};

It’s just a whole lot of knowledge required to identify vulnerable code, without necessarily understanding the underlying reason as to why it is vulnerable. The above is just a simple example.

4.2. Study Plan

Due to a lack of motivation, I skimmed through most of the content, skipping labs and exercises. The module contents were basically case studies of past CVEs, and I genuinely found them to be extremely complex.

It was a terrible study plan. Actually, there wasn’t a plan at all… But I had a trip due in April, and I had really wanted to get the OSCE3 grind done with. In a moment of YOLO, I booked the exam for March, knowing that I had a second attempt if I failed.

4.3. Exam

My god, it was the toughest exam I’ve taken. I found it much harder than the OSED and OSEP, due to myriad of factors:

• Laggy RDP
• Lack of practice
• Debugging issues
• The sheer volume of code to analyze

As others have put it, the OSWE exam was like finding a needle in the haystack. It was not straightforward, unlike the OSED where at every stage of the exploit, the objective was clear.

Despite the difficulty, I managed to obtain full points in about 28 hours, with about 5 hours of rest. Some of the vulnerabilities I had never even encountered before, but somehow I managed.

I then took a fat 5 hour nap and started on the report. Up till the last few minutes to lab expiry, I was still frantically grabbing screenshots and re-running my PoC scripts.

One tip for future OSWE exam takers is that there will be formatting errors when copying and pasting code from and into the report. You are allowed to base64-encode the PoC code and submit it in the report to avoid these errors. This could save you some stress.

4.4. Takeaways

I’m now less afraid of web-related security stuff. And I found some chapters especially interesting.

Websocket analysis was briefly covered, but it’s incredibly powerful and allows one to scrape real-time data without an API, which feels kinda illegal.

4.5. Conclusion

The course material is quite complex and learners that wish to follow through should expect a lot of headache. Or maybe that’s just me, because web is really not my thing.

All elements of the OWASP Top 10 are covered, in depth, and in multiple frameworks and languages. Specific niches and exploitation opportunities of each framework are also covered.

Also, Offsec needs to update their OSWE content more regularly. Especially for the price it costs. Although, I understand that their golden child is the OSCP.

5. The Future

It is sad to say that LLMs have surpassed humans in this field. The human effort required in Cybersecurity research is diminishing. Bug bounty and CVE findings have been accelerated to an inhuman pace. And CTFs have somehow become P2W. Technical work is handled autonomously by AI at 100x the productivity of a human. The disparity between human and AI will be unimaginable as the technology further develops.

Cybersecurity students and practitioners should consider carefully their prospects in this field. Quite frankly, I don’t know what the future holds.

6. Displate

As a personal celebration, I printed a custom Displate (metal poster) to put up in my room, next to my taxidermied insects. It required some light editing (whitespace padding and border stretching) to fit the Displate dimensions.

So that it isn’t done manually again, I wrote a tool - offsec_to_displate.py - to convert an Offsec certification screenshot into the required dimensions and aspect ratio for Displate.

7. Cat

Me when Claude takes my job and tells me “It’s normal to feel that way”.