Ethical hacking - tested methodologies and step-by-step practices

Most people imagine a pentester as someone who breaks into systems intuitively, without a plan. That's a mistake. Professional ethical hacking is built on strictly defined methodological frameworks that dictate every stage of work, from the first reconnaissance step to the final client report. Without that structure, a security audit becomes a random set of scans and attempts that easily miss critical vulnerabilities. In this article you'll see which standards govern the industry and what each stage of a professional pentest looks like.

Table of contents

• Why is methodology in ethical hacking essential?

• Key process stages according to NIST SP 800-115

• Web application testing methodology: OWASP Testing Guide

• Testing model specifics: black box, white box, grey box

• Security assessment metrics - PTES, OSSTMM and practice

• Our perspective on ethical hacking methodology

• Professional equipment for every test scenario

• Frequently asked questions

Key takeaways

Why is methodology in ethical hacking essential?

A pentest without methodology is like a medical diagnosis without a testing protocol. You may find something, but it's just as easy to miss the most important problems. Without a formal plan of action, different areas of the tested system are covered unevenly. Some assets are checked repeatedly while others are skipped entirely.

A standardised approach solves this problem directly. NIST SP 800-115 divides a pentest into 4 phases: Planning, Discovery, Attack and Reporting. Each phase has clearly defined goals, input and output. A pentester working within this structure doesn't need to improvise the order of actions, because the methodology does it for them.

Methodology also has a legal dimension. Every pentester action must have a documented basis. Written consent from the system owner, the scope of testing and the work schedule are elements indispensable for conducting an audit lawfully. Without these documents even the most ethically minded specialist exposes themselves to criminal liability for unauthorised access.

Below are the most important reasons why methodology is the foundation of every pentester's work:

• Prevents critical areas of the system from being missed

• Guarantees repeatability and comparability of results between audits

• Delivers a transparent report to the client with a documented action trail

• Legally protects both the pentester and the client

• Facilitates teamwork on large projects

"An effective pentester not only knows how to attack. They also know when to stop and how to document every step so that the results bring value to the client and are legally safe."

It's also worth remembering that methodology covers non-standard areas as well. For example, social engineering attacks in pentests require separate consent procedures and documentation, since they breach not only technical systems but also the privacy of the tested organisation's employees.

Pro tip: Before every project draft a Rules of Engagement document. Include the IP scope, testing methods, time windows and contact details for incident escalation. It's the document that protects both sides throughout the entire audit.

Key process stages according to NIST SP 800-115

NIST SP 800-115 is one of the most widely applied standards in the pentesting industry. Its popularity stems from precision. Every phase has concrete tasks and measurable outcomes. The standard was published in 2008 by the National Institute of Standards and Technology, is publicly available and despite its age remains a foundational reference document, regularly cited in more detailed frameworks.

According to this standard, the four phases of a pentest are Planning, Discovery, Attack and Reporting. Below is a step-by-step description of each.

1. Planning - Preliminary phase. The audit goal, scope of activities, testing model and legal requirements are defined. Contracts and consent documents are signed. Required human and hardware resources are also determined.

2. Discovery - Two-step reconnaissance. The first part is passive gathering of information about the target, such as subdomains, WHOIS data, email addresses and server technologies. The second part is active scanning: detecting open ports, service versions, operating systems and potential vulnerabilities. This is where tools like Nmap, Shodan and Nessus come in.

3. Attack - Exploitation of detected vulnerabilities. The pentester tries to gain unauthorised access, escalate privileges, move laterally across the network and collect data. Every action is documented in real time. This phase confirms the reality of threats found during Discovery.

4. Reporting - Delivering results to the client. The report contains a description of the methodology, a list of detected vulnerabilities with risk ratings, evidence of exploitation and remediation recommendations. A good report separates technical findings from an executive summary.

The Discovery phase deserves special attention because mistakes made here propagate through the rest of the audit. If a pentester misses an entire subnet during scanning, the Attack phase will never touch it. The accuracy of reconnaissance decides the quality of final results.

Pro tip: During the Discovery phase apply both active scanning and passive techniques. You'll find a lot of valuable information about the target's infrastructure in publicly available code repositories like GitHub, without generating any network traffic. Checking commit history for API key and password leaks is especially helpful. Similar techniques also apply to application fuzzing, where knowing the architecture before starting a test lets you direct fuzzing at the riskiest endpoints.

Web application testing methodology: OWASP Testing Guide

When the audit target is a web application, the general NIST SP 800-115 methodology needs to be supplemented with a specialised framework. This is where the OWASP Web Security Testing Guide (WSTG, formerly OWASP Testing Guide) comes in, the de facto standard for this area.

OWASP Testing Guide contains 11 main test categories: Information Gathering, Configuration and Deployment Management, Identity Management, Authentication, Authorization, Session Management, Input Validation, Error Handling, Cryptography, Business Logic and Client-Side Testing. Each category contains detailed test vectors describing the technique, tools and expected results.

The practical value of the OWASP Testing Guide lies in the fact that it's not merely a list of threats. Each test is described at a technical level. The pentester gets a ready recipe: what to look for, how to check it and how to evaluate the result.

Below is an overview of selected categories from the OWASP Testing Guide:

• Information Gathering - collecting data about the framework, server, backend technologies and URL structure

• Configuration Management - checking server configuration, HTTPS, security headers, TLS configuration

• Authentication Testing - tests of password policy, lockout mechanisms, multi-factor authentication, brute-force vulnerabilities

• Session Management Testing - analysis of session tokens, cookie security, session fixation and CSRF vulnerabilities

• Authorization Testing - verification of access control, privilege escalation tests, insecure direct object reference

• Input Validation Testing - SQL Injection, XSS, Command Injection, Path Traversal, XML Injection

• Business Logic Testing - detection of business logic errors that are hard to identify automatically

• Client-Side Testing - analysis of JavaScript, DOM-based XSS, HTML Injection, WebSocket security

Systematic documentation of results during testing is just as important as the tests themselves. Every attack vector found should be recorded immediately with proof: a screenshot, an HTTP request log or tool output. Reconstructing traces after the audit ends is difficult and time-consuming. Practical guidance on structuring the testing phase can be found in the detailed fuzzing guide, which also describes how to organise automatic scan results.

Pro tip: Always treat the Business Logic Testing category as a manual test, not an automated one. No automated tool understands an application's business logic the way a human does. Check the flows of purchase processes, coupon systems and account limits by hand, step by step, because that's where the vulnerabilities missed by automated scanners are hidden.

Testing model specifics: black box, white box, grey box

Choosing a testing model is one of the first decisions made during audit planning. Each model assumes a different level of prior knowledge about the tested system. The decision affects the realism of the test, the project duration and the scope of possible results.

Black box, white box and grey box are the three basic approaches to penetration testing. Each of them requires written consent from the system owner without exception.

Black box is most often chosen by companies that want to see what an external attacker sees before reaching credentials. The pentester starts with no information beyond the target address. It's the most time-consuming approach but gives the most realistic picture of an organisation's external exposure.

White box gives the pentester full access to source code, architecture documentation, server configurations and network diagrams. As a result the tester can analyse application logic and infrastructure at a level impossible in black box. This approach is especially effective when auditing code security before a production deployment.

Grey box is the compromise most often used in practice. The pentester receives, for example, a user account with basic privileges and knowledge of network segmentation, but no access to source code. This focuses test time on real attack vectors while keeping a partial external intruder perspective.

Key principles when choosing a model:

• The audit goal determines the model. An audit before application deployment is best covered by white box. Verifying defensive maturity against external attacks calls for black box or grey box.

• Time and budget matter. Black box is the most expensive in terms of time. White box is the most expensive in terms of required analytical knowledge.

• Written consent from the system owner is required regardless of the model. Without consent the audit is illegal, even if conducted by passive reconnaissance methods.

• The geographical scope of testing and time windows must be defined separately for each model.

"No testing model replaces another. Mature security organisations regularly combine approaches, running black box once a year and white box for every significant system change."

Security assessment metrics - PTES, OSSTMM and practice

Finding vulnerabilities is one thing. Describing them in a way that is measurable and understandable to the client is a completely different skill. The methodological frameworks PTES (Penetration Testing Execution Standard) and OSSTMM (Open Source Security Testing Methodology Manual) answer this challenge with concrete measurement tools.

PTES and OSSTMM offer metrics such as RAV (Risk Assessment Value), which allow you to empirically measure a system's security state. RAV is a balance metric calculated from three components: Operational Security, Controls and Limitations. Operational Security is measured through Porosity, which consists of three elements: Visibility (visibility of assets), Access (system access points) and Trust (level of trust between components). The final result gives a quantified risk assessment on a scale relative to 100.

In industry practice the use of such metrics is still a minority. Most pentest reports contain lists of vulnerabilities with a CVSS (Common Vulnerability Scoring System) rating, but don't provide a holistic metric of system security state. That's the gap OSSTMM tries to fill.

The practical application of RAV metrics looks as follows:

• Visibility - how many points of contact with the system are publicly accessible? Every open port, public API endpoint or subdomain increases this indicator.

• Access - what is the actual exposure level of discovered assets? CVSS-weighted vulnerability scan results feed into this value.

• Trust - do system components trust each other excessively? Unlimited trust relations between network segments drastically raise the risk of an attacker moving laterally.

It's also worth knowing that PTES defines seven stages of pentesting: Pre-engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post Exploitation and Reporting. This is a more detailed split than the four NIST SP 800-115 phases, which makes PTES a useful complement, especially in large corporate projects.

Pro tip: In reports for business clients translate the technical description of vulnerabilities into the language of financial and operational risk. Instead of writing "SQL Injection detected in the ID parameter", write "an attacker could gain access to the entire customer database, exposing the company to GDPR fines up to 20 million euro and loss of reputation." Same threat, but far more readable for decision-makers.

Using standardised metrics also raises the comparability of audits over time. A client commissioning pentests on a regular cycle can track changes in the RAV indicator between projects and objectively evaluate whether their security investments deliver measurable results. Without such metrics every report is assessed subjectively, which makes risk management at the organisational level more difficult.

Our perspective on ethical hacking methodology

The pentest market has a problem that's rarely discussed openly. Many companies commissioning security audits treat methodology as a formality. They care about the final certificate, not the quality of the process. This leads to situations where an audit performed "according to methodology" is in reality a cursory scan of a few ports and a report generated by an automated scanner.

Methodology is a tool, not an end in itself. NIST SP 800-115, OWASP Testing Guide, PTES, OSSTMM. Each of these standards provides structure, but audit quality depends on the pentester applying it. A tool in the hands of someone who doesn't understand why they're performing a given step gives worse results than an experienced specialist working without a formal standard.

From the long-term perspective of building expertise in this industry, it's worth reversing the typical educational approach. Instead of learning tools and only then looking for a place for them within the methodology, it's better to start with understanding the goal of each phase. When you know what you're looking for in the Discovery phase, reaching for the right tools becomes natural. When you know the goal of the Attack phase, you see which exploits are worth attention and which are a waste of time.

A second often overlooked issue is the difference between a pentest and a security assessment. A pentest is an attempt to exploit specific vulnerabilities. A security assessment is a broader review of architecture, policies and procedures. The methodologies described in this article mostly cover pentests, but a professional security advisor should know both approaches and know when to apply each. A client often asks for a "penetration test" when their real problem requires a review of security policies or infrastructure configuration.

Finally, the matter of hardware. The best methodology in the world will do nothing if a tester uses gear poorly matched to specific test scenarios. Wireless network testing requires different network cards than web application testing. Physical security testing requires RFID/NFC gear. Coherence between methodology, software tools and hardware defines a professional toolkit.

Professional equipment for every test scenario

Well-chosen methodology requires matching equipment. At Sapsan we offer specialised devices for pentesters working in the field and in the lab.

In our store you'll find tools for Wi-Fi network testing, RFID/NFC devices for physical security audits, SDR equipment for radio testing, BadUSB accessories and complete kits for Flipper Zero. Every product is selected for pentest use, not general consumer use. Sapsan delivers equipment to professionals across Europe and the USA with fast order fulfilment. Whether you're running a black box audit of a corporate network or testing web applications, we have the hardware to complement your methodological toolkit.

Frequently asked questions

Does one audit always require applying all NIST SP 800-115 stages?

Not every phase has to be applied 100%, but a full cycle significantly increases the detection rate of vulnerabilities and the quality of the report. The four phases of NIST SP 800-115 can be adapted to project scope, but skipping the Discovery or Reporting phase lowers the value of the whole audit.

Can methodologies be combined (e.g. OWASP with NIST) during one pentest?

Yes, methodologies are often combined, especially for complex systems requiring diverse tools and approaches. The OWASP Testing Guide with its 12 categories perfectly complements the general NIST SP 800-115 framework for audits covering web applications.

How to choose the testing model: black box, white box or grey box?

The decision is made based on the project goal, available information and strict consent from the system owner. As stated, written consent from the system owner is required regardless of the chosen model, and the choice between black, white and grey box stems from the priority of realism versus depth of analysis.

Why use RAV-type metrics in pentest practice?

Metrics make it easier to communicate risk and progress in protections, and clients gain a measurable picture of system state. RAV from the OSSTMM framework lets you compare results between recurring audits and objectively evaluate the effectiveness of implemented safeguards over time.