This document is intended as a resource for those who want to conduct white-box pen-testing engagement or who’re preparing for Offensive Security Web Expert (OSWE) exam. After reading this recipe you should understand what is required to be successful at the white-box pen-testing process and to hopefully pass OSWE exam.


The intent of a white-box attacker in many cases, is to identify potential points of weakness by sifting through massive amount of codes, making it the most time-consuming type of penetration testing. White-box pen-testing perhaps the most accurate and efficient internal pen-testing type would the organization do since white-box penetration testers are able to perform static code analysis, making familiarity with source code analyzers, debuggers and similar tools important for this type of testing and to fill in for the significant blind spots where automated scanners simply cannot check. However, dynamic analysis tools and techniques are also important for white-box testers since static analysis can miss vulnerabilities introduced by misconfiguration of target systems.

What is OSWE?

Advanced Web Attacks and Exploitation (AWAE) is the premier web application security and pen-testing training, upon successful completion of the course and certification exam, you will officially become an Offensive Security Web Expert (OSWE), which demonstrates you have mastered the art of exploiting front-facing web applications.

Offensive Security AWAE Labs

The course serves three main purposes, analyzing the source code, reverse engineering for closed application (decompiling and debugging) and improving thinking to achieve expanded view of standard vectors. you’ll be provided with a PDF & videos & lab access. My method was to read the section on the PDF, then watch the corresponding video, and then implement it in lab environment to get a shell. I progressed through the entire thing in about a week.

Regarding the AWAE syllabus, the course covers the following topics in detail:

  • Tools & Methodologies.
  • Persistent Cross-Site Scripting
  • Blind SQL Injection.
  • Type Juggling.
  • Authentication Bypass.
  • Cross-Site Request Forgery.
  • Data Exfiltration.
  • Bypassing File Upload Restrictions.
  • Bypassing REGEX restrictions.
  • .NET Deserialization.
  • Session Hijacking.
  • Source Code Recovery.

Calling out specific types of vulnerabilities in the course can actually add to the realism of certain assessments while mitigating some of the professionalism, and can provide valuable results to the pen-tester in the real life scenarios.

The concept of the source code review is pretty straightforward: An attacker wants to sift every single line of code, to perform an action that enables further compromise of the target, and that’s what you’ll find it in the course. Whether attempting to target a website by persistent cross-site scripting, session hijacking, cross-site request forgery or bypassing REGEX restrictions, the complicating factor is to get a shell in the labs.

Best Practices

When hackers stray from being ethically appropriate, they can damage any benefits or findings by affecting the professional image of the pen-tester. Being a hacker who has the right to break into other organization’s assets is a great thing. However, it’s really important to the professionalism that ethics are being made throughout the whole engagement and avoiding immature practice such as messing with the databases through troll strings or images, which could undermine the entire efforts that has been done.

White-box pen-testers are often fall to the temptation of rabbit holes, which are time sinks that can distract them away from the potential weaknesses. Tracking potential weaknesses is similar to tracking a rabbit hole, both take a significant effort to explore and may consume lots of time of the overall engagement or exam. Hence, being too cautious or too slow is something with which even expert hackers can struggle in.

The Exam

My exam started at 19:00 PST Sunday, after 30 hours of intensive working I got nothing, not even a single point. The challenge of not being able to get any point of these challenges/systems can draw hackers into trying to defeat the challenge, instead of moving on to machines that are bit easier to access and that may contain potential weakness; I’ve faced that a lot in bug bounty life as well. It can be extremely difficult to keep your conciseness need of the getting a shell in your mind when facing many rabbit holes or challenges (CTF stuff) of each target encountered while the tremendously import this is to prioritize your attack based on the exam points.

I wasn’t involved into any kind of stress as my previous OSCE & OSCP exams since I’ve managed to take some rest every 2 hours, take a nap, take a walk, eat healthy food or anything that’s not related to technology at all.

12:00 PM PST on Thursday which is 6 hours and 45 minutes before ends of the exam I’ve got it and finished the exam.


The audience in general may vary from security analysts to business-oriented owners and the report needs to enable the totality for the audience to understand the importance of the finding in it. However, in OSWE exam case the audience is technically savvy security stuff which is something good to deal with since you’ll be comfortable in the terminology part.

Technical vulnerabilities, non-technical vulnerabilities, non-exploited vulnerabilities yet aren’t in Offensive Security team’s scope but these vulnerabilities can be just a serious or even more impactful to the target so keep those in your mind while your conducting white-box pen-testing engagement.

During the reporting phase, as the business owners of the organization might not buy off on engagement activity, the vendor may not be contracted again. Similarly, in OSWE exam the Offensive Security team might not buy off your exam report if you didn’t follow the exam rules of engagement.


B1twis3 | Hamid Mahmoud