❗The term PoC (Proof-of-Concept) is still unclear…

❗Turn the module blueprint into steps for what I want to accomplish across my cyber security journey - namely:

• Personal Pentesting Portfolio
• Pentesting Social Media Presence
• Pentesting Writeups
• Bug Bounty Hunting
• Freelance Pentesting
• Open-Source Projects
• CTFs

❗Make sure to use “sysreptor” when creating all documentation for modules

❗Look up how the variation in approaches look like for the same box amongst different authors

---

The Pentesting Process is defined by successive steps and events performed to find a path to a predefined objective.

The process must be flexible - not every client has the same infrastructure, desires and expectations.

The stages of pentesting are independent, circular processes that all need to exist for a successful pentest:

Tactics, Techniques, and Procedures (TTPs).

Stages

Pre-Engagement

Educating the client and adjusting the contract. Includes NDAs, Goals, Scope, Time Estimation and Rules of Engagement. It consists of three essential components:

1. Scoping questionnaire
2. Pre-engagement meeting
3. Kick-off meeting

Before discussing anything in detail, an NDA (Non-Disclosure Agreement) must be signed by all parties - here are the types of NDAs:

• Unilateral NDA - only one party needs to maintain confidentiality, while the other party can share information received with third parties.
• Bilateral NDA - both parties need to maintain confidentiality, which is the most common type to protect the work of penetration testers as well.
• Multilateral NDA - a commitment to confidentiality by multiple parties (more than two).

NOTE: It is important to know who in the company is permitted to contract the pentester, as such an order cannot be accepted from anyone. Here are some common roles that hire pentesters:

• 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/Director of IT/Information Security

It is vital to determine signing authority, primary and secondary points of contact, technical support and contact for escalating issues.

Several documents must be prepared and signed before a pentest, such as:

• NDAs - after initial contact
• Scoping Questionnaire - before the pre-engagement meeting
• Scoping Document - during the pre-engagement meeting
• Pentesting Proposal (Contract/Scope of Work (SOW)) - during the pre-engagement meeting
• Rules of Engagement (RoE) - before the kick off meeting
• Contractors Agreement (for Physical Assessments) - before the kick off meeting
• Reports - during/after the pentest

NOTE: Clients 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. ALL documents should be reviewed and adapted by a lawyer after they have been prepared.

The Scoping Questionnaire clearly explains the services provided and asks to choose from the following list, under which the client can be more specific about the required assessment:

• Internal Vulnerability Assessment
• Internal Penetration Test
• Wireless Security Assessment
• Physical Security Assessment
• Red Team Assessment
• External Vulnerability Assessment
• External Penetration Test
• Application Security Assessment
• Social Engineering Assessment
• Web Application Security Assessment

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)?

Questions about information disclosure and evasiveness also need to be asked, such as the type of pentest (black box, grey box or white box) and whether the test is non-evasive, hybrid-evasive or fully evasive.

All of this information is necessary so pentesters can deliver the engagement based on client’s expectations, and also provide an accurate project timeline (for example, a Vulnerability Assessment will take considerably less time than a Red Team Assessment) and cost (an External Penetration Test against 10 IPs will cost significantly less than an Internal Penetration Test with 30 /24 networks in-scope).

All the information from the Scoping Questionnaire is put into the Scoping Document.

The Pre-Engagement meeting discusses relevant and essential components before the pentest. The data gathered here and from the Scoping Document serve as inputs to the Penetration Testing Proposal or Scope of Work (SoW).

NOTE: We may encounter clients during our career that are undergoing their first ever penetration test, or the direct client PoC is not familiar with the process. It is not uncommon to use part of the pre-engagement meeting to review the scoping questionnaire either in part or step-by-step.

Contract Checklist:

| NDA | Non-Disclosure Agreement (NDA) refers to a secrecy contract between the client and the contractor regarding all written or verbal information concerning an order/project. The contractor agrees to treat all confidential information brought to its attention as strictly confidential, even after the order/project is completed. Furthermore, any exceptions to confidentiality, the transferability of rights and obligations, and contractual penalties shall be stipulated in the agreement. The NDA should be signed before the kick-off meeting or at the latest during the meeting before any information is discussed in detail. | | --- | --- | | Goals | Goals are milestones that must be achieved during the order/project. In this process, goal setting is started with the significant goals and continued with fine-grained and small ones. | | Scope | The individual components to be tested are discussed and defined. These may include domains, IP ranges, individual hosts, specific accounts, security systems, etc. Our customers may expect us to find out one or the other point by ourselves. However, the legal basis for testing the individual components has the highest priority here. | | Penetration Testing Type | When choosing the type of penetration test, we present the individual options and explain the advantages and disadvantages. Since we already know the goals and scope of our customers, we can and should also make a recommendation on what we advise and justify our recommendation accordingly. Which type is used in the end is the client's decision. | | Methodologies | Examples: OSSTMM, OWASP, automated and manual unauthenticated analysis of the internal and external network components, vulnerability assessments of network components and web applications, vulnerability threat vectorization, verification and exploitation, and exploit development to facilitate evasion techniques. | | Penetration Testing Locations | External: Remote (via secure VPN) and/or Internal: Internal or Remote (via secure VPN) | | Time Estimation | For the time estimation, we need the start and the end date for the penetration test. This gives us a precise time window to perform the test and helps us plan our procedure. It is also vital to explicitly ask how time windows the individual attacks (Exploitation / Post-Exploitation / Lateral Movement) are to be carried out. These can be carried out during or outside regular working hours. When testing outside regular working hours, the focus is more on the security solutions and systems that should withstand our attacks. | | Third Parties | For the third parties, it must be determined via which third-party providers our customer obtains services. These can be cloud providers, ISPs, and other hosting providers. Our client must obtain written consent from these providers describing that they agree and are aware that certain parts of their service will be subject to a simulated hacking attack. It is also highly advisable to require the contractor to forward the third-party permission sent to us so that we have actual confirmation that this permission has indeed been obtained. | | Evasive Testing | Evasive testing is the test of evading and passing security traffic and security systems in the customer's infrastructure. We look for techniques that allow us to find out information about the internal components and attack them. It depends on whether our contractor wants us to use such techniques or not. | | Risks | We must also inform our client about the risks involved in the tests and the possible consequences. Based on the risks and their potential severity, we can then set the limitations together and take certain precautions. | | Scope Limitations & Restrictions | It is also essential to determine which servers, workstations, or other network components are essential for the client's proper functioning and its customers. We will have to avoid these and must not influence them any further, as this could lead to critical technical errors that could also affect our client's customers in production. | | Information Handling | HIPAA, PCI, HITRUST, FISMA/NIST, etc. | | Contact Information | For the contact information, we need to create a list of each person's name, title, job title, e-mail address, phone number, office phone number, and an escalation priority order. | | Lines of Communication | It should also be documented which communication channels are used to exchange information between the customer and us. This may involve e-mail correspondence, telephone calls, or personal meetings. | | Reporting | Apart from the report's structure, any customer-specific requirements the report should contain are also discussed. In addition, we clarify how the reporting is to take place and whether a presentation of the results is desired. | | Payment Terms | Finally, prices and the terms of payment are explained. |

The most crucial element of this meeting is the detailed presentation of the penetration test to our client and its focus. As we already know, each piece of infrastructure is unique for the most part, and each client has particular preferences on which they place the most importance. Finding out these priorities is an essential part of this meeting.

Based on the Contract Checklist and the Scoping Document, the Penetration Testing Proposal (Contract) and the associated Rules of Engagement (RoE) are created.

Rules of Engagement - Checklist:

Introduction	Description of this document.
Contractor	Company name, contractor full name, job title.
Penetration Testers	Company name, pentesters full name.
Contact Information	Mailing addresses, e-mail addresses, and phone numbers of all client parties and penetration testers.
Purpose	Description of the purpose for the conducted penetration test.
Goals	Description of the goals that should be achieved with the penetration test.
Scope	All IPs, domain names, URLs, or CIDR ranges.
Lines of Communication	Online conferences or phone calls or face-to-face meetings, or via e-mail.
Time Estimation	Start and end dates.
Time of the Day to Test	Times of the day to test.
Penetration Testing Type	External/Internal Penetration Test/Vulnerability Assessments/Social Engineering.
Penetration Testing Locations	Description of how the connection to the client network is established.
Methodologies	OSSTMM, PTES, OWASP, and others.
Objectives / Flags	Users, specific files, specific information, and others.
Evidence Handling	Encryption, secure protocols
System Backups	Configuration files, databases, and others.
Information Handling	Strong data encryption
Incident Handling and Reporting	Cases for contact, pentest interruptions, type of reports
Status Meetings	Frequency of meetings, dates, times, included parties
Reporting	Type, target readers, focus
Retesting	Start and end dates
Disclaimers and Limitation of Liability	System damage, data loss
Permission to Test	Signed contract, contractors agreement

The Kick Off Meeting happens in-person after signing all the contractual documents. It includes PoC’s, client technical support staff and the pentesting team, even some other roles like a Project Manager or the like. The purpose of the meeting is to go over the nature of the pentest and how it will take place. Usually DoS doesn’t take place. In the case of a critical vulnerability being identified, activity will be paused and a notification report will be generated, after which emergency contacts will be contacted (this is usually during external pentests). The purpose of the notification is for the client to assess the risk internally to see if it warrants an emergency fix. Usually Internal Pentests are only stopped if the system becomes unresponsive, or evidence of illegal activity is found or the presence of an external threat actor in the network or a prior breach.

Pentests have many risks that must be informed to the customers. This includes leaving log entries and alarms, as well as locking users due to brute force attacks. Customers must immediately contact us if the pentesting is negatively impacting their network.

A Contractors Agreement is usually for physical testing as different laws apply here. If employees aren’t informed about the tests and find us doing something illegal, they may call the police or get us in trouble, and so the agreement is like a “get out of jail free” card in that case.

Contractors Agreement - checklist for Physical Assessments:

Introduction
Contractor
Purpose
Goal
Penetration Testers
Contact Information
Physical Addresses
Building Name
Floors
Physical Room Identifications
Physical Components
Timeline
Notarization
Permission to Test

Information Gathering

How information is obtained about the necessary components, to find potential security gaps that can be leveraged for a foothold/exploitation.

All the steps we take to exploit the vulnerabilities are based on the information we enumerate about our targets. This phase can be considered the cornerstone of any penetration test.

Information can be gathered in many ways, here’s how we can divide them:

• Open-Source Intelligence (OSINT)
• Infrastructure Enumeration
• Service Enumeration
• Host Enumeration

All four categories should and must be performed for EACH penetration test.

OSINT is a process for finding publicly available information on a target company or individuals that allows the identification of events, dependencies and connections. The idea is to use public (Open-Source) information from freely available sources to obtain the desired results.

Publicly published passwords or SSH keys represent a critical security gap if they have not already been removed or changed. Therefore, our client's administrator must review this information before we proceed.

NOTE: Developers often share whole sections of code on StackOverflow to show other developers a better overview of how their code works to help them solve their problems.

Infrastructure Enumeration aims to overview the company’s position on the internet (and intranet) using OSINT and first active scans. DNS is used to map a client’s servers and hosts to develop an understanding of how their infrastructure is structured. The list of hosts and their IP addresses can be listed and compared to the scope to see if they’re included and listed. Company security measures can also be determined here, where the more precise the information is the easier it will be to disguise attacks (Evasive Testing).

Enumeration from inside a network gives a good overview of hosts and servers that can be used as targets for a Password Spraying attack, where one password is used to attempt to authenticate with as many different user names as possible.

Service Enumeration is the identification of services that allow interaction with the host/server over the network. It’s critical to find out about the service, its version, what information it gives us and the reason for its use.

NOTE: Many services have a version history that allows us to identify whether the installed version on the host or server is actually up to date or not. This will also help us find security vulnerabilities that remain with older versions in most cases. Many administrators are afraid to change applications that work, as it could harm the entire infrastructure. Therefore, administrators often prefer to accept the risk of leaving one or more vulnerabilities open and maintaining the functionality instead of closing the security gaps.

Host Enumeration is when every host listed in the scoping document is examined, once we have a detailed list of customer infrastructure. The OS and its services are identified, the versions of the services, and more. We try to identify the role a host/server plays and what network components it communicates with. We must also identify which services it uses for this purpose and on which ports they are located.

During Internal Host Enumeration, which often happens after the successful exploitation of one or more vulnerabilities, we also examine the host or server from the inside by looking for sensitive files, local services, scripts, applications, information, and other things that could be stored on the host. This is also an essential part of the Post-Exploitation phase.

NOTE: From the internal perspective, we will find services that are often not accessible from the outside. Therefore, many administrators become careless and often consider these services "secure" because they are not directly accessible from the internet. Thus, many misconfigurations are often discovered here due to these assumptions or lax practices.

After Post-Exploitation, Pillaging is the process of collecting sensitive information located on the already exploited host. This is used to show the impact of a potential attack and used for further steps to escalate privileges or move laterally further into the network.

Vulnerability Assessment

Analyze the results in the Information Gathering stage to look for known system vulnerabilities, to then discover potential attack vectors - both manually and through automated means.

It is an analytical process based on the findings of the Information Gathering phase. There are 4 kinds of analysis:

Descriptive	Descriptive analysis is essential in any data analysis. On the one hand, it describes a data set based on individual characteristics. It helps to detect possible errors in data collection or outliers in the data set.
Diagnostic	Diagnostic analysis clarifies conditions' causes, effects, and
interactions. Doing so provides insights that are obtained through
correlations and interpretation. We must take a backward-looking view, similar to descriptive analysis, with the subtle difference that we try to find reasons for events and developments.
Predictive	By evaluating historical and current data, predictive analysis
creates a predictive model for future probabilities. Based on the
results of descriptive and diagnostic analyses, this method of data analysis makes it possible to identify trends, detect deviations from expected values at an early stage, and predict future occurrences as
accurately as possible.
Prescriptive	Prescriptive analytics aims to narrow down what actions to take to eliminate or prevent a future problem or trigger a specific activity or process.

It is essential to ask precise questions and remember what we know and what we don’t know.

Note: There are many standard ports and services which administrators often try to disguise using “easy to remember” alternatives (a “2121” port can just be a port “21”, an FTP server).

Information Gathering and Vulnerability Research can both be considered a part of descriptive analysis. If there is an identified version of a service or application, and there is also a Common Vulnerabilities and Exposures (CVE), it is likely that the vulnerability is still present.

Vulnerability disclosures can be found for components using tools like CVEdetails, ExploitDB, Vulners, Packet Storm Security, NIST and others.

Then, Diagnostic/Predictive Analysis is used to determine what causes the vulnerability. It is important to understand the PoC (Proof-of-Concept) as best as possible here, that is often customized, hence we will need to also adapt it to ours in most cases.

Vulnerability Assessment also includes the actual testing of the vulnerability, which is part of Predictive Analysis.

There is often back and forth movement between Information Gathering and Vulnerability Assessments.

In a CTF, speed is more important than quality. The goal is to capture flags on the target machine with the highest privileges as fast as possible instead of exposing all weaknesses of the system. Hence, a real Pentest is not a CTF. In a real pentest, quality and intensity take utmost priority.

Exploitation

Use the vulnerability assessment results to test attacks against the potential vectors to gain initial access to those systems.

The prioritization of potential vulnerabilities is done according to the following factors:

• Probability of Success - can be calculated using CVSS Scoring and the NVD Calculator
• Complexity - the time, effort and research required to execute the attack on the system successfully
• Probability of Damage - we must avoid damage to the target systems

NOTE: A personal point system can be used to ensure the evaluation is more accurately calculated based on skills and knowledge.

In the case that there is no known working PoC exploit code, it may be necessary to reconstruct the exploit locally using a VM representing the target host to figure out what needs to be adapted and changed. Once this is done, the exploit can be prepared by following the entire pentesting procedure from the start on the VM, to test whether it works and whether it causes significant damage. In other situations, common misconfigurations and vulnerabilities can be seen to know which tool/exploit to use and whether it is “safe” or will cause instability.

If in doubt, always check with the client.

Post-Exploitation

At this stage we already have access to the machine. We ensure that access remains even if modifications and changes are made - privilege escalation may be tried to obtain the highest possible rights and hunt for sensitive data such as credentials (pillaging). Sometimes post-exploitation is done to demonstrate the impact of our access. Sometimes its to move on to the lateral movement process.

Evasive Testing may or may not be utilized at this stage.

The Post-Exploitation stage includes evasive/non-evasive testing, more information gathering and vulnerability assessment, pillaging, escalating privileges, data exfiltration and persistence. Basically the entire lifecycle again because internally, it is a completely new environment.

Testing can be Evasive, Hybrid Evasive or Non-Evasive.

Investigating (by say, enumerating) the local network and services is calling Pillaging. This is useful to examine the role of a host on a corporate network, which gives us an understanding of the role of the system we are on.

After getting an overview of the system, it is important to maintain access to an exploited host so that even if the connection is interrupted, access still remains. This is essential and often done before Information Gathering and Pillaging during the Post-Exploitation phase.

Maintaining access to the system and getting a good overview are precursors to repeat the Vulnerability Assessment stage from inside the system.

Privilege Escalation is not always locally on our system. Stored credentials obtained from other higher privileged users, and using them to log in as another user also counts.

Data Exfiltration means transferring critical information from the target system to our own. Data Loss Prevention (DLP) and Endpoint Detection and Response (EDR) systems help detect and prevent this. Encryption on hard drives is also used.

Lateral Movement

Describes movement within an internal network to access additional hosts at the same or higher privilege level. It is an iterative process combined with post-exploitation until the goal is reached.

The goal is to test what an attacker can do within the entire network by say, getting access to sensitive data or finding all the ways to render the network unusable. A great example is ransomware.

During Lateral Movement activity, several phases will be run through:

• Pivoting:
  • In most cases, the system being used doesn’t have the tools to enumerate the internal network efficiently, meaning that we have to use the exploited host as a proxy and perform the attacks from our machine. This is called Pivoting or Tunneling.
• Evasive Testing
  • There are many ways to avoid lateral movement including (micro) segmentation, threat monitoring, IPS/IDS, EDR and more - understanding them can help avoid them.
• Information Gathering
• Vulnerability Assessment
  • Internally, assignment groups and rights to system components often play an essential role.
• (Privilege) Exploitation
  • Cracking passwords and hashes, using existing credentials on other systems, and similar actions are all exploits that can be done internally while doing lateral movement.
• Post-Exploitation

Sometimes there may not be direct ways to escalate privileges on the target system itself, but rather there is a necessity to move around the network. This is where Lateral Movement comes into play, as depicted in the graph where this stage can be moved to directly from Exploitation and Post-Exploitation stages.

Existing data and information can be versatile and often used in many ways.

Proof-of-Concept

Document, step by step, how the compromise took place. The goal is to paint a picture of how weaknesses can be chained together so that the picture is clearer on how each vulnerability fits in. They are then prioritized and remediation efforts can take place.

Also called Proof of Principle, it is a project management term that serves as the proof that a project is feasible in principle. The criteria can be both technical or business related.

In the case of pentesting, it serves as a decision-making basis for further course of action, and enables risks to be identified and minimized. It proves vulnerabilities, that a security problem exists so that they can be validated, reproduced visualized and remediated. It assesses the probability of success of system access from actual exploitation.

This step is often integrated into the development process for new application software or security solutions.

One of the most common examples used to prove vulnerabilities is executing the calculator app on Windows.

Documentation can constitute a PoC, although the more practical version is a script or code that automatically exploits the vulnerabilities found. This demonstrates flawless exploitation of the vulnerabilities and is straightforward for the admin/developer. Often when they receive such a script, they “fight” against the script by changing things around so it no longer works. However the script is only one way of exploiting a given vulnerability, and so it is important to actually work with the script to modify and secure the systems probably so that the script no longer works, and the information obtained from the script can no longer be obtained in any other way.

The report should help them see the entire picture, focus on broader issues, and provide clear remediation advice as well as an attack chain walk-through. In the event of a domain compromise during an internal, it is a great way to show how multiple flaws can be combined and how fixing one flaw will break the chain, but the other flaws will still exist.

High quality stands for high standards; this should be repeatedly emphasized through our remediation recommendations.

Post-Engagement

Documentation is prepared for admins and management to understand the severity of vulnerabilities found. All traces of host and server action are cleaned up - deliverables are created, a report walk-through meeting is held, and executive presentations are delivered. Lastly, testing data is archived as per contractual obligation and company policy - typically retained for a set period of time by the pentester until a post-remediation assessment is performed or a set period of time to test the client’s fixes.

Many activities need to be performed (often contractually binding) after all the work is done:

• Cleanup
  • deleting tools and scripts, reverting configuration changes, etc. Our notes should mark any cleanup activities. If systems where things need to be deleted are inaccessible, the client should be alerted and these issues should be listed in the report appendices.
• Documentation and Reporting
  • before completing the assessment and disconnecting entirely (or sending “stop” notification emails to signal the end of testing), adequate documentation must exist for all findings that will be included in the report. This includes command output, screenshots, a list of affected hosts, etc.
  • Personal Identifiable Information (PII), potentially incriminating info or other sensitive data should not be kept.
  • The report deliverable should consist of the following:
    • An attack chain (in the event of full internal compromise or external to internal access) detailing steps taken to achieve compromise
    • A strong executive summary that a non-technical audience can understand
    • Detailed findings specific to the client's environment that include a risk rating, finding impact, remediation recommendations, and high-quality external references related to the issue
    • Adequate steps to reproduce each finding so the team responsible for remediation can understand and test the issue while putting fixes in place
    • Near, medium, and long-term recommendations specific to the environment
    • Appendices which include information such as the target scope, OSINT data (if relevant to the engagement), password cracking analysis (if relevant), discovered ports/services, compromised hosts, compromised accounts, files transferred to client-owned systems, any account creation/system modifications, an Active Directory security analysis (if relevant), relevant scan data/supplementary documentation, and any other information necessary to explain a specific finding or recommendation further
• Report Review Meeting
• Deliverable Acceptance
  • The Scope of Work (SoW) should clearly define the acceptance of project deliverables.
  • The first version of the report is the DRAFT report, from where comments, clarification/modifications ensue.
  • The new version is marked FINAL.
• Post-Remediation Testing
  • Remediation documentation is reviewed. The target environment is re-accessed, where each issue is tested to ensure it was appropriately remediated. Finally, a post-remediation report is issued to show the state of the environment before and after post-remediation testing.
  • A penetration test is essentially an audit, so we must remain impartial third parties and not perform remediation on our findings or even give precise remediation advice. This maintains the assessments integrity and doesn’t introduce any potential conflict of interest into the process.
• Data Retention
  • Procedures should be outlined in the Scope of Work and Rules of Engagement.
  • Evidence should be retained for some time in case questions arise about specific findings, or assistance for retesting “closed/remediated” findings is required.
  • Retained assessment data should be encrypted and stored securely. Data should be wiped from a tester’s system at the end of an assessment, and a new virtual machine specific to the client should be created for post-remediation testing or investigation of findings related to client inquiries.
• Close Out
  • After delivering the report, assisting with questions and post-remediation testing/reporting, the project is closed.
  • Any systems used to connect to client systems or process data should be wiped and destroyed, and any leftover artifacts should be stored securely (encrypted) as per firm policy and contractual obligations to the client.
  • Final steps include invoicing the client and collecting payment for services. It is a good idea to follow up with post-assessment client satisfaction surveys.
  • NOTE: As we continually grow our technical skill set, we should always look for ways to improve our soft skills and become more well-rounded professional consultants. In the end, the client will usually remember interactions during the assessment, communication, and how they were treated/valued by the firm they engage, not the fancy exploit chain the pentester pulled off to pwn their systems.

It is important to keep detailed time-stamped logs of scanning and exploitation attempts in an outage or incident in which the client needs information about our activities.