---

Penetration testing has developed a lot during the past few years. Testing today has many more facets than just discovering technical vulnerabilities. Applications and services must be tested in the same way cyber-criminals would exploit them, including misuse of password, technical and logical vulnerabilities in the application and custom based on the target application and technology stack. As such River Security has, via many years of experience, built a methodology to ensure vulnerabilities are discovered, led by team efforts and thoroughly and effectively communicated to our customers.

This methodology is explained in the video linked, and represented as an abstracted upside down pyramid in the picture. In the next sections we will walk through parts of what a web application penetration test would ideally contain.

The Methodology

Penetration testing should be a collaborative effort to maximize effectiveness and knowledge sharing. Collaboration fosters a richer learning environment, enhancing the overall skill set of the team.

“Pentesting is boring because it’s all just checklists going through testing.”

~Echoed by many

The methodology aims to make pentesting fun and interesting again. The checklist approach is not the best approach, as it aims to already know all vulnerabilities and items to test for. More on this later. Let’s dive in!

Discovery – Find Everything, Leave No Stone Unturned

The methodology starts with effective discovery; it is foundational to successful pentesting and identifying vulnerabilities. With an understanding of the attack surface, the methodology takes the penetration tester into into fuzzing. Fuzzing are the attempts to make the application behave differently, trying to produce elements and findings which can be used for exploitation.

Discovery involves reconaissance, scannind and anything you can imagine that helps penetration testers uncover the grounds of what to attack. Perhaps the most exciting parts of Discovery is during a hardware test. What should be tested during a hardware test? I have jokingly called hardware testing “full stack penetration testing”, because it can involve so much. Imagine when targetting hardware you can:

• Intreact with the board, find hardware weaknesses through many different means
• Communicate to it via bluetooth, nfc, ethernet and other protocols potentially
• There could be an associated mobile application you might have to reverse engineer
• The system has a built-in webserver which lets you administrate it, so web application hacking is necessary
• And perhaps during testing you find Azure IOT Hub being used, and you pivot into cloud pentesting

If the above topics is not covered, not noticed, or not considered, then you might miss out on gigantic vulnerabilities.

It is important to engaging with the application’s features and understanding its logic can uncover unique vulnerabilities. An example is for example a feature get-users. If there is a get-users, there might be a update-user, create-user and so on, which you would not find unless you go look for it.

Identifying hidden attack surfaces requires creativity and thorough exploration beyond automated tools. What if you could ask your customer for a full directory list of a web-servers files and folders, then should you? In my opinion yes, we want to arm the penetration testing team with as much knowledge and capabilities as possible.

This step is very technology and application dependant. For example testing a web application will require forced browsing by the penteser to disclose content which is not found otherwise. However, there is so much more to this than what meets the inexperienced eye. If you are targetting an application running on IIS webserver, it is likely suspectible of IIS shortname scanning, and you need to enable that as part of your methodology. The same applies to say a React SPA (Single Page Application); there is more than one page, but you have to find the endpoints and functionality in the source code. In other words, remember to not only do wide reconaissance, but also go deep.

Furthermore, it is crucial for testers to identify and differentiate between testing approaches and the application of methodologies across various platform distinctions. A platform distinction is an area of the application which is hosted by a different backend, or somehow behaves fundamentally different than the rest of the application, e.g. it is running of a different code-base.

Fuzzing – Produce Anomalies and Discrepancies

For security testing to be impactful, it’s crucial for the tester to independently identify potential bugs, anomalies, and intriguing aspects of the application. One effective method to achieve this is through fuzzing. Fuzzing is a testing technique that involves providing unexpected, random, or invalid inputs to a system, application, or component to identify potential vulnerabilities, crashes, or unexpected behavior. The goal is to uncover edge cases and weaknesses that might not be immediately apparent through conventional testing.

For testing web applications, there are several fuzzing techniques to help out finding vulnerabilities, let us explore a few your team might consider implementing in their testing routines below:

• Observe how the web application responds when provided with input ranging from every byte (00 to FF), both with and without URL encoding enabled. This approach tests the application’s input sanitization and helps identify any special or “magic” bytes that may trigger errors or reveal intriguing functionality.
• Leverage wordlists containing relevant keywords, attack patterns, and specialized strings designed to trigger application-specific, technique-specific, or vulnerability-specific functionality. These wordlists may include attacks aimed at provoking behaviors like time-intensive operations, which can reveal potential vulnerabilities. Maintaining a diverse collection of wordlists is invaluable; however, it’s essential for pentesters to understand their purpose. For instance, they should know if the wordlist requires placeholders, its intended use, and whether the entries are pre-encoded or require manual encoding by the tester. Custom word lists tailored to application context significantly improve vulnerability detection.
• Attempt to provoke any form of External Server Interaction, such as outbound communication to attacker-controlled infrastructure. This approach is highly effective in uncovering otherwise blind vulnerabilities, providing critical insight into the application’s behavior.

Fuzzing is an important topic which should help the testers produce interesting results which will warrant more research and understanding to exploit.

Hypotheses & Test Cases – Design Test Scenarios

As the testers work through the application, they gradually build up their competency and understanding of what the applications purpose is, any connected middleware such as databases, caches, proxies and more. Based on the fuzzing results and undrstanding of the application, the penetration testers should do their best to help build out possible test cases and hyoptheses about viable attack vectors. Note: it is perfectly fine for this to happen at the same time as while doing fuzzing, this is not a waterfall model.

Hypotheses could for example be:

• Let us see if we can password reset a different account and overwrite their password with a new one.
• Can we break free from the multi-tenant environment by impersonating, or claiming roles of other users?
• The application is running off a document storage database such as Elastic, can we inject query operator or other parameters to attempt to get access to more data?

This hypothesis-driven approach allow pentesters to leverage their experience for targeted testing. It is also useful to, based on fuzzing and discovery, leverage the expertise of more specialized and senior members of the team to help guide the testing in the right way.

I like to work with an evolving list of hypotheses during my test, and I’ll collect them in lists like these for a file upload type of function and application:

What	Why	Conclusion
Can malicious files be uploaded, such as files which will execute dynamic code?	We could potentially backdoor the system	It was not possible because files uploaded were renamed, pushed to a storage bucket and always presented for download as application/octet-stream.
The application supports PDF uploads, can they contain JavaScript which can be abused?	The PDF’s are viewed in a in-app PDF reader, it may not sanitize properly.	JavaScript was removed from the files after upload.
Polyglot upload	Can we upload a file which represents two formats in one upload, potentially causing code to run?	It was possible to hijack the system using polyglots, see finding on this issue.

Business Process, Logic Flaws – Clever Testing That Won’t Be Found By Fuzzing

Attacking the application from a technical perspective is good, but we must be sure to not forget vulnerabilities can aslo exist in process and logic of the application too, not only from a technical and fuzzing aspect. The step on business process and logic flaws aims to arm the penetration testers with ideas to help uncover such vulnerabilities.

Applications have many different flows and processes which may be attacked, for example:

• A purchasing flow. How does it behave when challenged in different parts of the flow?
• What about password resets? Is the implemention sound or may there be vulnerabilities in the implementation?

The goal of this part of the methodology is to allow the pentesters to look at the application, perhaps even via a diagram or a graph, to find potential weaknesse and flaws which are otherwise hard to fuzz and scan for.

Frameworks – Let Them Serve as Guides and Helpers

There are plenty of frameworks out there, some extremely old (but still being quoted as in use by pentesters), and others which are very complete in terms of giving testing guidelines.

The frameworks portion of the methodology aims to support the methodology with application specific frameworks, or even supporting it self on other frameworks some testing may require, such as OWASP’s WSTG or OWASP ASVG. These frameworks often try to be all-embracing frameworks, trying to map out every single “nook and cranny”, every possible vulnerability and thing to test for. This causes not only bloat, causing the frameworks to be hard to follow, but also stifle creative and research efforts in testers.

At River Security we use a testing concept called MVP (“Minimum Viable Penetration Testing”) which enables testers to take advantage of previous knowledge, or build new knowledge, on how to break into a specific application. These MVP’s help our testers to enable start engaging in documented procedures on how to break into the applicaiton stack, such as:

• Targetting middleware, e.g. attacking the reverse proxy or WAF.
• Taking advantage of weaknesses based on the type of webserver, e.g. IIS vs. Kestrel.
• Targetting the managed code or application framework.
• Finding weaknesses in other parts of the backends of an application.

Continuous documentation and improvement of methodologies help maintain high testing standards.

Tools – Useful but NOT the Star of the Show

The tools you use can be plentiful, but their relevance largely depends on the type of application you’re testing. Tools aren’t inherently bad; in fact, they can be excellent fallback options when something slips through the cracks of your methodology. However, they should never be the primary driver of your penetration testing efforts.

The choice of tool depends entirely on the target. Attacking a WordPress site? Tools like wpscan and wordpress-rest-enum can provide valuable insights. Testing platforms like Shopify, Joomla, or SharePoint? Research the available tools, experiment with them, and refine their usage to improve your process for the next engagement.

While tools can greatly enhance the pentesting process, they must never replace critical thinking. Tools often appear to work seamlessly but may overlook critical vulnerabilities or provide misleading results. That’s where skilled penetration testers shine—using their expertise to recognize when a tool fails and adapting to uncover deeper issues.

Continuity – When You are Finally Participating In The Same Sport as Threat Actors

What if a web application changes from status code 401 Unauthorized to 200 OK? What about a new change in the firewal? Or better yet, James Kettle has unvealed a new hacking technique at Defcon?! This is where continuity of testing come into play. Penetration testing should happen throughout the year, NOT once a year. How to acheive this? Check out our managed service Active Focus!