This chapter (Ethical Hacking General Methodology) aims to present the stages in Ethical hacking. Each step will be presented individually. This documentation has been made using The Cyber Mentor PEH course, HTB Academy Penetration Testing job skill path and XSSrat Pentesting 101 ultimate guide from start to finish. I recommend all these courses as they really cover very important topics of pentest and also offer the possibility to practice these skills. Also they offer the possibility to get certified with an exam. PNPT for TCM, HTB CPTS and XSSrat for CNWPP

Ethical hacking methodology

When working for any company, make sure that you have a copy of the signed scope of work/contract and a formal document listing the scope of testing (URLs, individual IP addresses, CIDR network ranges, wireless SSIDs, facilities for a physical assessment, or lists of email or phone numbers for social engineering engagements), also signed by the client. When in doubt, request additional approvals and documentation before beginning any testing. While performing testing, stay within the scope of testing. Do not stray from the scope if you notice other IP addresses or subdomains that look more interesting. Again, if in doubt, reach out. Perhaps the client forgot to add certain hosts to the scoping sheet. It does not hurt to reach out and ask if other hosts you notice should be included, but, again, make sure this is in writing and not just given on a phone call. We must work with the guiding principle of do no harm and strive to perform all testing activities in a careful and measured way. Just because we can run a certain tool, should we? Could a particular exploit PoC potentially crash one or more servers? If in doubt about anything during an assessment, run it by your manager and the client and gain explicit consent in writing before proceeding.

Source: Practical Ethical Hacking - TCM Security

Source: Hackethebox Academy

Precautionary Measure during Pentests

In addition, we should also be aware that some countries have additional regulations that apply to specific cases, and we should either inform ourselves or ask our lawyer.

Source HackTheBox Academy

Source: Practical Ethical Hacking - TCM Security

Source HTB Academy

Note: Our client may provide a separate scoping document listing in-scope IP addresses/ranges/URLs and any necessary credentials but this information should also be documented as an appendix in the RoE document. Important Note: These documents should be reviewed and adapted by a lawyer after they have been prepared.


The pre-engagement stage is where the main commitments, tasks, scope, limitations, and related agreements are documented in writing. During this stage, contractual documents are drawn up, and essential information is exchanged that is relevant for penetration testers and the client, depending on the type of assessment. Arrengements are made for:

  • Non-Disclosure Agreement

  • Goals

  • Scope

  • Time Estimation

  • Rules of Engagement

The entire pre-engagement process consists of three essential components:

  1. Scoping questionnaire

  2. Pre-engagement meeting

  3. Kick-off meeting

Before any of these can be discussed in detail, a Non-Disclosure Agreement (NDA) must be signed by all parties. There are several types of NDAs:

It is essential to know who in the company is permitted to contract us for a penetration test. Because we cannot accept such an order from everyone. Imagine, for example, that a company employee hires us with the pretext of checking the corporate network's security. However, after we finished the assessment, it turned out that this employee wanted to harm their own company and had no authorization to have the company tested. This would put us in a critical situation from a legal point of view.

Non exhaustive list of company members who may be authorized to hire us for penetration testing:

  • Chief Executive Officer (CEO)

  • Chief Technical Officer (CTO)

  • Chief Information Security Officer (CISO)

  • Chief Security Officer (CSO)

  • Chief Risk Officer (CRO)

  • Chief Information Officer (CIO)

  • VP of Internal Audit

  • Audit Manager

  • VP or Director of IT/Information Security

Scoping Questionnaire

After initial contact is made with the client, we typically send them a Scoping Questionnaire to better understand the services they are seeking. This scoping questionnaire should clearly explain our services and may typically ask them to choose one or more from the following list:

  • Internal Vulnerability Assessment

  • External Vulnerability Assessment

  • Internal Penetration Test

  • External Penetration Test

  • Wireless Security Assessment

  • Application Security Assessment

  • Physical Security Assessment

  • Social Engineering Assessment

  • Red Team Assessment

  • Web Application Security Assessment

Under each of these, the questionnaire should allow the client to be more specific about the required assessment. Aside from the assessment type, client name, address, and key personnel contact information, some other critical pieces of information include:

  • How many expected live hosts?

  • How many IPs/CIDR ranges in scope?

  • How many Domains/Subdomains are in scope?

  • How many wireless SSIDs in scope?

  • How many web/mobile applications? If testing is authenticated, how many roles (standard user, admin, etc.)?

  • For a phishing assessment, how many users will be targeted? Will the client provide a list, or we will be required to gather this list via OSINT?

  • If the client is requesting a Physical Assessment, how many locations? If multiple sites are in-scope, are they geographically dispersed?

  • What is the objective of the Red Team Assessment? Are any activities (such as phishing or physical security attacks) out of scope?

  • Is a separate Active Directory Security Assessment desired?

  • Will network testing be conducted from an anonymous user on the network or a standard domain user?

  • Do we need to bypass Network Access Control (NAC)?

Finally, we will want to ask about information disclosure and evasiveness (if applicable to the assessment type):

  • Is the Penetration Test black box (no information provided), grey box (only IP address/CIDR ranges/URLs provided), white box (detailed information provided)

  • Would they like us to test from a non-evasive, hybrid-evasive (start quiet and gradually become "louder" to assess at what level the client's security personnel detect our activities), or fully evasive.

Based on the information we received from the scoping questionnaire, we create an overview and summarize all information in the Scoping Document.

Pre-Engagement Meeting

Once we have an initial idea of the client's project requirements, we can move on to the pre-engagement meeting. This meeting discusses all relevant and essential components with the customer before the penetration test, explaining them to our customer. The information we gather during this phase, along with the data collected from the scoping questionnaire, will serve as inputs to the Penetration Testing Proposal, also known as the Contract or Scope of Work (SoW).

Contract - Checklist

Based on the Contract checklist and the input information shared in scoping, the Penetration Testing Proposal (Contract) and the associated Rules of Engagement (RoE) are created.

Rules of Engagement - Checklist

Contractors Agreement

If the penetration test also includes physical testing, then an additional contractor's agreement is required. Since it is not only a virtual environment but also a physical intrusion, completely different laws apply here. It is also possible that many of the employees have not been informed about the test. Suppose we encounter employees with a very high-security awareness during the physical attack and social engineering attempts, and we get caught. In that case, the employees will, in most cases, contact the police. This additional contractor's agreement is our "get out of jail free card" in this case.

Contractors Agreement - Checklist for Physical Assessments

Source Hackthebox Academy

Types of Pentests

Source HTB Academy

Types of Testing Environmments

  • Network

  • Web App

  • Mobile

  • API

  • Thick Clients

  • IoT

  • Cloud

  • Source Code

  • Physical Security

  • Employees

  • Hosts

  • Server

  • Security Policies

  • Firewalls


It is important to note that these categories can often be mixed. All listed test components may be included depending on the type of test to be performed Source HTB Academy


Asset Management

When an organization of any kind, in any industry, and of any size needs to plan their cybersecurity strategy, they should start by creating an inventory of their data assets. If you want to protect something, you must first know what you are protecting! Once assets have been inventoried, then you can start the process of asset management. This is a key concept in defensive security.

Asset Inventory

Asset inventory is a critical component of vulnerability management. An organization needs to understand what assets are in its network to provide the proper protection and set up appropriate defenses. The asset inventory should include information technology, operational technology, physical, software, mobile, and development assets. Organizations can utilize asset management tools to keep track of assets. The assets should have data classifications to ensure adequate security and access controls.

Application and System Inventory

An organization should create a thorough and complete inventory of data assets for proper asset management for defensive security. Data assets include:

  • All data stored on-premises. HDDs and SSDs in endpoints (PCs and mobile devices), HDDs & SSDs in servers, external drives in the local network, optical media (DVDs, Blu-ray discs, CDs), flash media (USB sticks, SD cards). Legacy technology may include floppy disks, ZIP drives (a relic from the 1990s), and tape drives.

  • All of the data storage that their cloud provider possesses. Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure are some of the most popular cloud providers, but there are many more. Sometimes corporate networks are "multi-cloud," meaning they have more than one cloud provider. A company's cloud provider will provide tools that can be used to inventory all of the data stored by that particular cloud provider.

  • All data stored within various Software-as-a-Service (SaaS) applications. This data is also "in the cloud" but might not all be within the scope of a corporate cloud provider account. These are often consumer services or the "business" version of those services. Think of online services such as Google Drive, Dropbox, Microsoft Teams, Apple iCloud, Adobe Creative Suite, Microsoft Office 365, Google Docs, and the list goes on.

  • All of the applications a company needs to use to conduct their usual operation and business. Including applications that are deployed locally and applications that are deployed through the cloud or are otherwise Software-as-a-Service.

  • All of a company's on-premises computer networking devices. These include but aren't limited to routers, firewalls, hubs, switches, dedicated intrusion detection and prevention systems (IDS/IPS), data loss prevention (DLP) systems, and so on.

All of these assets are very important. A threat actor or any other sort of risk to any of these assets can do significant damage to a company's information security and ability to operate day by day. An organization needs to take its time to assess everything and be careful not to miss a single data asset, or they won't be able to protect it.

Organizations frequently add or remove computers, data storage, cloud server capacity, or other data assets. Whenever data assets are added or removed, this must be thoroughly noted in the data asset inventory.

Compliance Standards


The Payment Card Industry Data Security Standard (PCI DSS) is a commonly known standard in information security that implements requirements for organizations that handle credit cards. As per government regulations, organizations that store, process, or transmit cardholder data must implement PCI DSS guidelines. This would include banks or online stores that handle their own payment solutions (e.g., Amazon).

PCI DSS requirements include internal and external scanning of assets. For example, any credit card data that is being processed or transmitted must be done in a Cardholder Data Environment (CDE). The CDE environment must be adequately segmented from normal assets. CDE environments are segmented off from an organization's regular environment to protect any cardholder data from being compromised during an attack and limit internal access to data.

Image Source: Adktechs

Health Insurance Portability and Accountability Act (HIPAA)

HIPAA is the Health Insurance Portability and Accountability Act, which is used to protect patients' data. HIPAA does not necessarily require vulnerability scans or assessments; however, a risk assessment and vulnerability identification are required to maintain HIPAA accreditation.

Federal Information Security Management Act (FISMA)

The Federal Information Security Management Act (FISMA) is a set of standards and guidelines used to safeguard government operations and information. The act requires an organization to provide documentation and proof of a vulnerability management program to maintain information technology systems' proper availability, confidentiality, and integrity.

ISO 27001

ISO 27001 is a standard used worldwide to manage information security. ISO 27001 requires organizations to perform quarterly external and internal scans.

Although compliance is essential, it should not drive a vulnerability management program. Vulnerability management should consider the uniqueness of an environment and the associated risk appetite to an organization.

The International Organization for Standardization (ISO) maintains technical standards for pretty much anything you can imagine. The ISO 27001 standard deals with information security. ISO 27001 compliance depends upon maintaining an effective Information Security Management System. To ensure compliance, organizations must perform penetration tests in a carefully designed way.

Penetration Testing Standards

Penetration tests should not be performed without any rules or guidelines. There must always be a specifically defined scope for a pentest, and the owner of a network must have a signed legal contract with pentesters outlining what they're allowed to do and what they're not allowed to do. Pentesting should also be conducted in such a way that minimal harm is done to a company's computers and networks. Penetration testers should avoid making changes wherever possible (such as changing an account password) and limit the amount of data removed from a client's network. For example, instead of removing sensitive documents from a file share, a screenshot of the folder names should suffice to prove the risk.

In addition to scope and legalities, there are also various pentesting standards, depending on what kind of computer system is being assessed. Here are some of the more common standards you may use as a pentester.


The Penetration Testing Execution Standard (PTES) can be applied to all types of penetration tests. It outlines the phases of a penetration test and how they should be conducted. These are the sections in the PTES:

  • Pre-engagement Interactions

  • Intelligence Gathering

  • Threat Modeling

  • Vulnerability Analysis

  • Exploitation

  • Post Exploitation

  • Reporting


OSSTMM is the Open Source Security Testing Methodology Manual, another set of guidelines pentesters can use to ensure they're doing their jobs properly. It can be used alongside other pentest standards.

OSSTMM is divided into five different channels for five different areas of pentesting:

  1. Human Security (human beings are subject to social engineering exploits)

  2. Physical Security

  3. Wireless Communications (including but not limited to technologies like WiFi and Bluetooth)

  4. Telecommunications

  5. Data Networks


The NIST (National Institute of Standards and Technology) is well known for their NIST Cybersecurity Framework, a system for designing incident response policies and procedures. NIST also has a Penetration Testing Framework. The phases of the NIST framework include:

  • Planning

  • Discovery

  • Attack

  • Reporting


OWASP stands for the Open Web Application Security Project. They're typically the go-to organization for defining testing standards and classifying risks to web applications.

OWASP maintains a few different standards and helpful guides for assessment various technologies:


  • Here is a great methodology with plenty of resources

  • HTB Machines search on engine for practice on specific topics

  • This search engine will help you find HTB Academy modules according to specific goals you have for HTB platform. For instance if you want to work on dante prolab you will have suggestions of HTB Academy modules according to the topics of Dante:

Last updated