In this article, we will go through four major penetration testing frameworks

NIST Technical Guide to Information Security Testing and Assessment

The National Institute of Standards and Technology (NIST) publishes a number of Special Publications (SPs) on cybersecurity and the Risk Management Framework (RMF).

The SP 800 series, in particular, is devoted to public-sector computer security instructions and recommendations.

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (https://csrc.nist.gov/publications/detail/sp/800-115/final) defines and describes penetration testing.

If you want to work in cybersecurity for the US government, you should familiarise yourself with the NIST SP 800 series right away, notably the Risk Management Framework.

The RMF is frequently used in the public sector and seeks to include security and risk assessment throughout the whole system development life cycle.

More information on the RMF may be found at https://csrc.nist.gov/projects/risk-management/risk-management-framework-(RMF)-Overview.

The following are the goals of penetration testing, according to NIST SP 800-115:

Assess how effectively a system can withstand real-world threats.

Determine how educated an attacker must be in order to exploit a flaw.

Check to see whether there are any counter-measures in place in the event of an assault.

Determine the capacity of a defense to recognize and react to a given danger.

NIST’s process is significantly different from PTES in that it only contains four phases:

Planning

This corresponds to the PTES Pre-engagement phase.

Discovery

This phase incorporates the PTES stages of Intelligence Gathering, Threat Modeling, and Vulnerability Analysis.

Attack

PTES’s Exploitation and Post-Exploitation stages are combined in this phase. Additional discovery procedures may be required after the Attack phase has begun. Gaining Access, Escalating Privileges, System Browsing, and Installing Additional Tools are the four subphases of the Attack phase.

Reporting

Reporting This phase corresponds to the PTES Reporting phase.

Framework for Penetration Testing

The Penetration Testing Framework (www.vulnerabilityassessment.co.uk/Penetration%20Test.html), created by Kevin Orrey as a free resource for entry-level pentesters, has been around for a while and is a great resource for links to web pages, tools, and applications that can help you with specific pentesting tasks as well as testing specific technologies.

Instead of being organised into specific testing phases, this framework takes a hybrid approach and presents categories of testing, such as Network Footprinting (Reconnaissance), Enumeration, Vulnerability Assessment, Cisco-Specific Testing, Wireless Penetration, and Physical Security, with each category organised into subcategories of tools and techniques that can be used for pentesting in that.

Pentesting tools and approaches may fall into more than one category with this hybrid approach. For example, wireless pentesting tools and methods that appear in the Wireless Penetration category may also appear in the Network Footprinting (Reconnaissance), Enumeration, and Cisco-Specific Testing categories.

While this framework varies from most others in terms of structure, it nevertheless covers the two most significant pentesting phases: the Pre-Inspection Visit (Pre-Engagement) and the Final Report.

The framework is also a wonderful place to go for technical, technology-specific materials, tips, and tool suggestions.

It has whole sections dedicated to things like Bluetooth testing, VoIP testing, Cisco testing, and password cracking, for example.

Methodology for Open Source Security Testing

The Open Source Security Testing Methodology Manual (OSSTMM) was created by Pete Herzog and developed by the Institute for Security and Open Methodologies (ISECOM) to measure the security of systems through penetration testing and security analysis.

The current version of the OSSTMM can be found at https://www.isecom.org/OSSTMM.3.pdf. The core emphasis of the OSSTMM is operational security and monitoring how a security programme is performing rather than how it should work—in other words, results-driven testing.

This corresponds to pentesting, which is concerned with real effect rather than potential impact.

Three classes and five channels make up the OSSTMM technique. The Human and Physical security channels make up the Physical Security class.

Wireless is the only channel in the Spectrum Security class, whereas Telecommunications and Data Networks are the only channels in the Communications Security class.

The OSSTMM process is highly complicated, and in order to finish it effectively, the tester must be well-versed in this specific testing technique.

The testing process is divided into four key phases:

Induction

It entails determining how your target behaves in its surroundings. What is the extent of the testing you’re doing?

Inquest

The target is being investigated. What can you learn about your target by analysing its signals and passively observing it?

Interaction

Engage your intended audience. When you actively interact with your target, how does it react?

Intervention

Interactions are changed. What can you achieve by altering your interactions with your target? Are you able to influence people’s reactions or responses?

While this is an oversimplification of how OSSTMM works, following the framework will result in a thorough knowledge of an organization’s operational security, including how relationships between people, systems, and software influence that system’s security.

OWASP Web Security Testing Guide

The Open Online Application Security Project, or OWASP (https://owasp.org), is an excellent resource for not just penetration testing but also other sorts of testing, such as web and mobile app analysis.

The Open Web Application Security Project (OWASP) has been operational for over 15 years and has made significant contributions to the disciplines of information security, application security, and cybersecurity.

OWASP is a worldwide organisation with a fully functional board that follows tight criteria and a code of conduct that explicitly expresses its commitment to staying vendor-agnostic.

The major emphasis of OWASP is application security throughout the Software Development Lifecycle (SDLC). However, since online applications may be subject to penetration testing, knowing the OWASP Web Application Penetration Testing Methodology might be the difference between a successful campaign and a failed test.

While it’s crucial to understand that the OWASP Web Application Penetration Testing Methodology includes activities like information collecting and server fingerprinting, you don’t need to recall which activities belong to which phase.

Insofar as penetration testing happens after the time to bake security into the SDLC has passed, OWASP is critical of it. Pentesting, on the other hand, is considerably more cost-effective than human code evaluation, according to OWASP. Pentesting also does not need the same level of knowledge as code reviews.

When it comes to analysing online apps, the OWASP Web Application Pentesting Methodology may be used as a complete checklist and methodology. The sections that follow emphasise some of the most crucial aspects of the procedure. Except in the case of reporting.

A vast number of elements should be examined according to the OWASP Web Application Penetration Testing Methodology. While some of these tests can be automated, it’s best to double-check the findings manually to avoid false positives.

Obtaining information

A web application pentest, like other penetration testing, starts with this key stage. The following are examples of information collection activities.

• Looking for evidence of information leaks
• Fingerprinting of web servers
• Enumeration and fingerprinting of web applications

Testing of Configuration and Deployment Management

Configuration and deployment management testing include ensuring that the web application’s platform has been thoroughly examined for things such as:

• Network and infrastructure setup that is correct
• Configuration and hardening of the platform (server)
• Improper management of backup files, file extensions, or file permissions might result in information leakage.
• Security protocols, such as TLS, must be configured correctly.

Management of Identity Testing

Authorized users are frequently required to login to the application before access is granted. As a result, identity management is an essential component of every programme. In this field, specific tests include:

• Testing for usernames and passwords that are weak or readily guessable
• The complete user registration process, including how users enrol and how usernames are provided or allocated, is being tested.
• Checking for adequate account separation based on user roles

Testing for Authentication

The challenge of verifying user credentials via the Internet is very difficult to solve. By undertaking operations such as the following, authentication testing helps to reduce the likelihood of incorrect credential use:

• Ensure that user credentials are appropriately encrypted during transmission (i.e., TLS is used between the server and client)
• Weak password policies and security questions/answers are being tested.
• Attempting to go around authentication
• Policies for account lockout and password reset are being tested.
• Default accounts and passwords are being tested.

Even during internal pentests, default accounts are still one of the most prevalent methods to get access to a system. To circumvent this issue, software developers have started imposing policies that require administrators to specify a login and/or password upon installation in recent years.

Testing for Authorization

A user’s access to an application does not imply that he or she is permitted to perform anything inside that programme. Authorisation testing aims to guarantee that user authorization systems work properly by doing the following:

• Privilege escalation is being tested.
• Attacks against directory traversal are being tested.
• File inclusion attacks are being tested.
• Insecure direct object reference (IDOR) attacks are being tested.

When an attacker tries to get access to an object by changing input, this is known as an IDOR attack. An attacker who can edit the “Id” argument in the URL hxxps:/foo.bar/image?Id=1234, for example, may be able to circumvent permission constraints.

Testing for Session Management

HTTP is a “sessionless” protocol, which means that it doesn’t keep track of sessions from one connection to the next. Using “cookies,” or little pieces of information kept on a user’s computer that follow the user’s journey through the programme, is one technique to solve this issue. Whether a user tried to log in to hxxps:/mybank.com/login without session management, the application would have no means of knowing if the user had supplied a valid username and password or if they could access a specific page. Testing for the following aspects inside an application may help guarantee effective session management:

• Cookie properties are being tested (e.g., HttpOnly)
• Timeouts in sessions are being tested.
• Checking that the session is properly terminated when the user logs out.
• Cross-site request forgery testing
• Attempting to get around session management

Validation of Input Testing

In today’s e-commerce environment, web apps that consumers can’t engage with offer little to no function. This implies that both attackers and ordinary users have control over the sorts of data transmitted to and processed by the programme. This is one of the most significant attack surfaces in any contemporary online application, as well as one of the most challenging and time-consuming to test. Pentesters are particularly interested in the following areas:

• SQL injection, code injection, command injection, LDAP injection, XML injection, and other sorts of injection assaults are all examples of injection testing.
• Cross-site scripting testing
• Vulnerabilities in file inclusion testing
• Overflow (buffer, heap) vulnerabilities are being tested.
• Testing of databases (e.g., MySQL/MariaDB, Oracle, Postgres, Microsoft SQL Server, and so on).

Error Detection and Handling Testing

Breakdowns occur in applications. Developers must figure out what is causing the problems. They do so by recording faults or gathering debugging data. An attacker might utilise this information to collect sensitive information if it is not handled appropriately. The following tests may assist guarantee that sensitive information is not leaked:

• Error codes for the server, application, and database
• Inspection of the stack trace

Weak Cryptography Testing

Cryptography is basically the lifeblood of the e-commerce industry. There would be no way to safeguard sensitive user information in transit or at rest without TLS and its predecessors. While the vast majority of cryptography flaws are identified in implementation rather than the math itself, the following forms of testing will aid in the protection of client data:

• Weak cyphers are being tested.
• Algorithms or crypto libraries are tested for correct implementation.
• Oracle padding vulnerabilities are being tested.

Business Logic Testing

The application workflow is basically business logic inside an application. It’s all about how users (and attackers) engage with the programme and go from point A to point B. Attackers won’t be able to get around security checks or make the programme do something it wasn’t planned to do if the processes are tested for correct operation. This is checked by testers using a variety of methods, including

• Unknown and harmful file upload capabilities are being tested.
• Business logic verification
• Ensure that workflows cannot be bypassed
• Verifying the integrity of data sent between the client and the server

Testing on the client’s end

Administrators and developers have improved their platform and application security over the last several years. As a result, attackers have had to adapt and adjust their tactics.

As a strategy to build a foothold in an environment, they’ve started assaulting clients (web browsers). Application security also includes ensuring that an application does not jeopardise the client’s security. This is done by looking for the following things:

• JavaScript execution on the client side and HTML injection
• Attacks on clickjacking
• Resource sharing across countries of origin (CORS)
• Modification of client-side resources and files

Reporting

The OWASP Web Security Testing Guide, aptly titled “Reporting,” lays out the basic structure of a report, highlighting three key sections: an executive summary, a section outlining the test parameters, and a section for findings, which provides a clear and concise technical description of any vulnerabilities discovered as well as solutions for resolving them.

MITRE ATT&CK

The MITRE Corporation’s ATT&CK has been around since 2013 and has become a prominent standard in assisting in the identification and tracking of hostile activity in a particular environment.

Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) is an acronym for Adversarial Tactics, Techniques, and Common Knowledge. MITRE set out to design a tool to imitate hostile tactics, methods, and procedures (TTPs) and to enable defensive teams quantify performance as well as the maturity of their security posture, based on the premise that offensive drives defence.

While ATT&CK was designed to aid defenders in detecting, mitigating, and recovering from assaults, adopting an offensive approach to the tool may assist pentesters plan and conduct penetration testing more effectively.

It also has the additional advantage of providing a standard language for pentesters and clients to communicate strategies, methodologies, and processes in a form that both parties can understand. The ATT&CK Company.

MITRE ATT&CK Enterprise Tactics
ID	Tactic	Description
TA0001	Initial Access	Trying to gain access to a target network
TA0002	Execution	Trying to run malicious code on a target network
TA0003	Persistence	Trying to maintain access on the target network
TA0004	Privilege Escalation	Trying to gain elevated privileges on the target network
TA0005	Defense Evasion	Trying to avoid detection
TA0006	Credential Access	Trying to gain access to account usernames and passwords
TA0007	Discovery	Trying to map the internal target network
TA0008	Lateral Movement	Trying to move or pivot within the target network
TA0009	Collection	Trying to gather information or data from the target network to help achieve the attacker’s goal(s)
TA0010	Command and Control	Trying to control compromised systems via a communications channel
TA0011	Exfiltration	Trying to steal data from the target
TA0040	Impact	Trying to cause harm to systems or data through manipulation or destruction

There are too many processes for each of these techniques to describe here, but you may study them at the ATT&CK Enterprise Matrix page: https://attack.mitre.org/matrices/enterprise/.

Except for pre-engagement, which does not exist in ATT&CK, we have attempted to group information under each step of ATT&CK.

Actual attackers aren’t concerned with things like remaining within the scope of the assault or following the rules of engagement.

MITRE has also created a PRE-ATT&CK matrix (https://attack.mitre.org/matrices/pre/) that shows how real-world adversaries could perform the preparatory phases of an operation.

The genuine dangers, on the other hand, will not care whether your server is “out of scope” for testing.

CAPEC

CAPEC (https://capec.mitre.org) stands for Common Attack Pattern Enumeration and Classification.

The US Department of Homeland Security (DHS) created it as a mechanism to discover and exchange attack trends throughout the world in order to get a better knowledge of how attackers work.

In the same way that TTPs help describe how attackers target and exploit vulnerabilities, attack patterns do the same.

Attack patterns, on the other hand, go a step farther by sketching out potential impediments or defensive responses that an attacker could encounter. In CAPEC, most attack patterns may be classified into two categories:

Attacking Mechanisms

Subverting access restrictions or introducing unexpected objects are examples of how an attacker could exploit a particular vulnerability.

Attacking domains

Software or hardware are examples of broad categories that indicate a particular target area. In terms of what is being assaulted, domains of attack might be conceived of.

MITRE is presently in charge of the CAPEC database, and both CAPEC and ATT&CK may be used to discover attack patterns and methodologies.

They are employed for various reasons, despite their similarities. CAPEC is a threat modelling, education and training, and penetration testing tool that focuses on application security.

ATT&CK is a network security tool that was created to assist with tasks like simulating adversary behaviour and looking for new threats.

CAPEC and ATT&CK may be utilised together to create specialised adversarial activity abuse instances.

CAPEC may define the target technology as well as how an adversary would exploit a flaw, while ATT&CK can identify the tool(s) that an attacker might utilise.