What is this blog about? Well dear reader, if you’re a bright-eyed penetration tester like me who has seen all the cool exploits being dropped on Twitter and want in on some of that action, then you’ve probably heard of and wanted to try the Full Stack Web Attack (FSWA) course.
The price of the course is steep which is a harsh reality, so I hope that this blog can give you some idea of what to expect before committing to taking it. Before proceeding of course, check out the official proposal.
Difficulty
Disclaimer: My experiences are that of a penetration tester. I didn’t have any of the following:
- An Application Security (AppSec) background
- Experience in source code review/0-day hunting/N-day PoC creating
- Industry experience working with codebases or large coding projects
- First-hand experience with the topics covered in the course
Considering your own background, the course might come off as similar to, easier or harder than what I experienced during my time.
However, don’t let this stop you from taking it. When I attended the course there was a varied spectrum of people ranging from security engineers to people who already had background in offensive security research. There was something for everyone.
Focus
I agree with the proposal that the hybrid model of training works extremely well in a time-constrained setting. It’s amazing how much was covered in just 4 days. That does have some drawbacks though: the proposal is not lying when it says one of the prerequisites is an open mind that is ready to focus.
The hybrid model in question basically played out like this:
- Steven covers a topic in the module, explaining how it works/why this works a certain way, etc.
- He then does a quick demo of not exactly the same thing as the exercise (or sometimes no demo)
- You are then given time to try the exercise yourself and ask an instructor for help if stuck
- Time is up, Steven then goes through the solution
- Rinse and repeat until scheduled break time
There were a couple of times where I would lose focus or get side-tracked while reading the fascinating course handbook, only to find out the class had already moved on and I would be struggling to play catch-up while also learning what was being presented at the very moment.
This has an adverse effect where missing something in step 1 or step 2 could mean jeopardising the learning process of that topic all the way till step 4, leaving gaps in one’s knowledge. I found that the only time where I could catch my breath was between step 3 and 4 if I had finished the exercises early.
This isn’t meant to be a dig at the course – far from it, but it is meant to serve as a warning to maintain focus or suffer the consequences.
Preparation/Prerequisite Knowledge
I definitely recommend doing the rceme challenge and getting a feel for how difficult you thought it was. For context, I found it quite challenging but rewarding at the end once I solved it.
Other preparations I did included mostly finding and reading everything I could within the syllabus. I made a top-down checklist and googled for advisories/blog posts/whitepapers/talks on the subjects and ingested them as much as I could. I will say that after a certain amount, this method offers diminishing returns…
When asked, Steven also sent me some advisories in the wild as preparation examples for Root Cause Analysis as well as Patch Bypasses.
In addition I found the following helpful too:
- Eldar’s Source Code Review series, just to understand how others do it and to debunk the romanticised process of source code review
Takeaways
Overall, I found the course to be of very high quality and opened my eyes to just how deep the rabbit hole of server-side offensive security research can go. The amount of layered knowledge spanning frameworks, language-specific pitfalls, software/runtime environments etc. can frankly be quite overwhelming!
As Steven mentioned, it’s more of a marathon than a sprint, getting stuck on an exploit chain and completing it the next year isn’t out of the question in this journey.
I leave feeling exhausted and head overflowing with knowledge, but more confident that finding a bug is just a matter of time and persistence.
My Recommendations
TL;DR: Hack as much as you can before the course, hack as much as you can AFTER the course as well.
Our brains being flesh-computers means that we can cache things but they expire quickly. Long term understanding and storing of this knowledge requires “doing” as well as repetition. There’s a reason why people say: Use it or lose it.
I highly recommend that right after the course, you book in some time (maybe a week or so) to then hammer home all the concepts and teachings that were crammed into your noggin during the course.
Furthermore, to keep the proverbial knife that is your shell-popping skill sharpened, I also recommend taking at least a bit of time each week to either revise the course material or go in the wild and poke at an n-day to keep that part of the brain stimulated. Not even joking, I regret not doing this.
On the bright-side, Steven has kindly offered past-students of the course support so they can ping him if they get stuck. This isn’t something to abuse of course! But it’s good to know that he’s willing to help if you’re really struggling with the concepts even post-training.
Kah Wing Ho
Senior Security Consultant, Sekuro
Ka Wing is a seasoned Senior Consultant within Sekuro RED, our talented Offensive Security Team. He specialises in attack surface reconnaissance, phishing simulation assessments, and web application penetration testing. At Sekuro, Ka Wing delivers projects and presents outcomes and findings to key stakeholders, ranging from C-suite executives and application owners to end developers. Some of Ka Wing's certifications include OSCP, CRTO and CRT.
More Articles
Facing post-tech stack consolidation blues head on
Selling the Strategic Imperative of Zero Trust to Your Board
