Penetration Testing Methodology

Our Penetration Testing Methodology

Our penetration testing methodology is a unique hybridised approach using OWASP and PTES as base. It is important to remember that our testing methodology is a framework for our testing test to ensure the highest quality of test output. For every test, we will adjust the methodology necessary to fit within your timescales, scope and key requirements. For all tests, other than black box testing the first step, Reconnaissance and Enumeration, can be ignored.

Our CREST Approved Penetration Testing Methodology

Our Penetration Testing Methodology follows the following structure:

Pre-Engagement Analysis: This stage of the penetration testing methodology is all about gathering information about the design, architecture and interfaces. This includes a review of technical documentation available and platform demonstration;

Intelligence Gathering: This stage of the penetration testing methodology is all about the initial analysis of the system architecture, data flow, infrastructure and concept. Review of documentation that can be found from open-source pathways. Where appropriate, a deep dive mining of information from the Dark Web. Where Open-Source Intelligence Gathering is included within the scope of the testing, that phase is passed to our highly skilled intelligence analysts to perform in-depth analysis. An example of the minimum level of data reviewed is shown below.

Reconnaissance: This stage of the penetration testing methodology is all about the process of refining the target list produced during the passive reconnaissance phase by using more intrusive methods such as port scanning, service and OS fingerprinting, and vulnerability scanning. The goal of this aspect of the assessment is to obtain visibility into the network; determine which devices are targets and enumerate possible threats to the network. We will then use a combination of automated and manual testing processes to find and assess vulnerabilities within your infrastructure or web applications.

Vulnerability Analysis: This stage of the penetration testing methodology is all about is performing high-level digital reconnaissance against the target systems and/or applications to identify potential vulnerabilities in the present security model. Vulnerability Scanning is often sold by less than honest testing firms as a Penetration Test in its own right, however, this would not meet the challenge of a Defensible Penetration Test under the CREST scheme. Vulnerability Scanning is included within every penetration test to enable mass coverage of more than 147,000 known vulnerabilities against all targets within scope. At Hedgehog we use our own technology for performing vulnerability scans which includes the commercial products Nessus, NeXpose, OpenVAS and Burp as well as Nikto and Nmap.

Exploitation: This is, for the testing team, where they earn their money in Penetration Testing methodology. We will attempt to exploit all of the identified vulnerabilities in order to achieve exploitation. Once this has been exhausted, we will move on to intercepting all network and application traffic using a series of listeners and proxies and manually review the requests and responses to identify vulnerabilities and will perform at a minimum, testing of the following points:

  1. Access Control / Authorisation: This phase of the assessment is focused on testing the business logic of applications. Access control testing includes the following:
    1. Parameter Analysis: The goal of Parameter Analysis is to ensure that the application enforces its access control model by ensuring that any parameters available to an attacker would not afford additional service.
    2. Authorisation Testing: The goal of Authorisation Testing is to ensure that resources that require authorisation perform adequate authorisation checks before being sent to a user.
    3. Authorisation Parameter Manipulation: The goal of Authorisation Parameter Manipulation is to ensure that once a valid user has logged in, it is not possible to change the session ID’s parameter to reflect another user account.
    4. Authorised pages/functions: The goal of Authorised pages/functions is to check if it is possible to access pages or functions that require logon but can be bypassed.
    5. Application Workflow: The goal of Application Workflow is to ensure that in situations that the application requires the user to perform actions in a specific sequence, that the sequence is enforced.
  2. Authentication: This phase of the assessment is focused on gaining unauthorised access to aspects of the web application. Authorisation testing includes the following:
    1. Authentication endpoints requests should use encrypted channels: The goal of this phase of the assessment is to ensure that users are only asked to submit authentication credentials on pages that are secured with some form of an encrypted channel.
    2. Authentication Bypass: The goal of this phase of the assessment is to ensure that the authentication process cannot be bypassed
    3. Credentials transport over an encrypted channel: The goal of this phase of the assessment is to ensure that usernames and passwords are sent over an encrypted channel
    4. Default Accounts: The goal of this phase of the assessment is to check for default account names and passwords in use.
    5. Username: The goal of this phase of the assessment is to ensure that the username is not public information such as e-mail or
    6. Password Quality: The goal of this phase of the assessment is to ensure that the password complexity makes guessing passwords difficult.
    7. Password Reset: The goal of this phase of the assessment is to ensure that someone other than the user cannot intercept the password during the reset process
    8. Password Lockout: The goal of this phase of the assessment is to ensure that the user’s account is locked out for a period of time when an incorrect password is entered more than a specific number of times
    9. Password Structure: The goal of this phase of the assessment is to ensure that special Meta characters cannot be used within the password
    10. Blank Passwords: The goal of this phase of the assessment is to ensure that passwords cannot be blank
  3. Session Management: This phase of the assessment is focused on testing the session management implemented within the web application. Session Management testing includes the following:
    1. Session Token Length: The goal of this phase of the assessment is to ensure that the session token is of adequate length to provide protection from session hijacking attack
    2. Session Timeout: The goal of this phase of the assessment is to ensure that the session tokens are only valid for a predetermined period after the last request by the use
    3. Session Reuse: The goal of this phase of the assessment is to that session tokens are changed when a user moves from an SSL-protected resource to a non-SSL-protected resource.
    4. Session Deletion: The goal of this phase of the assessment is to ensure that the session token is invalidated when the user logs out.
    5. Session Token Format: The goal of this phase of the assessment is to ensure that the session token is non-persistent and is never written to the browser’s history or cache.
    6. Configuration Management / Web Application Architecture Review: This phase of the assessment is focused on testing the configuration of the web application Configuration Management testing includes the following:
      1. HTTP Methods: The goal of this phase of the assessment is to ensure that the web server does not support the ability to manipulate resources from the Internet.
      2. Web Site Debugging: The goal of this phase of the assessment is to ensure that the web server debugging methods are disabled for production website
      3. Virtual Hosts: The goal of this phase of the assessment is to try to determine if the site is a virtual host.
      4. Web Server: The goal of this phase of the assessment is to try to ensure that the Web Server is free from known vulnerabilities and have all security patches applie
  4. Configuration Management & Architecture Review: Back-up Files: The goal of this phase of the assessment is to try to ensure that no backup files of source code are accessible on the publicly accessible part of the web serve
    1. Web Server Configuration: The goal of this phase of the assessment is to try to ensure that common configuration issues such as directory listing and sample files have been addresse
    2. Web Server Components: The goal of this phase of the assessment is to try to ensure that web server components (ASP, PHP, WebDAV, Apache Modules, et) do not introduce any security vulnerabilities.
    3. Common Paths: The goal of this phase of the assessment is to try to check for existence of common directories within the application root.
    4. Language/Application Defaults: The goal of this phase of the assessment is to ensure that quirks of any application or language used do not introduce any security hole
    5. Infrastructure Admin Interfaces: Ensure that administrative interfaces to infrastructure, such as web servers and application servers, are not accessible from the Internet.
    6. Application Admin Interfaces: Ensure that administrative interfaces to application are not accessible from the Internet.
  5. Error Handling: This phase of the assessment is focused on testing the error handling of the web application. Error handling testing includes the following:
    1. Application Error Messages: The goal of this phase of the assessment is to ensure that the application does not present error messages from the application (such as stack traces or database errors) that could be used in an attack.
    2. User Error Messages: The goal of this phase of the assessment is to ensure that the application does not present user error messages from the application (such as “User does not exist” or “User Correct, Password Incorrect”) that could be used in an attack.
  6. Data Protection: This phase of the assessment is focused on protecting the data within the web application. Data Protection testing includes the following:
    1. Sensitive Data in HTML: The goal of this phase of the assessment is to ensure that there is no sensitive data in the HTML (cached browser history) that could assist and attacke
    2. Data Storage: The goal of this phase of the assessment is to verify that data is protected to ensure its confidentiality and integrity, where require
    3. SSL Version: The goal of this phase of the assessment is to ensure that supported SSL versions do not have cryptographic weaknesse
    4. SSL Key Exchange Methods: The goal of this phase of the assessment is to ensure that the web server does not allow anonymous key exchange metho
    5. SSL Algorithms: The goal of this phase of the assessment is to ensure that weak algorithms are not available.
    6. SSL Key Lengths: The goal of this phase of the assessment is to ensure the web site uses an appropriate key lengt
    7. Digital Certificate Validity: The goal of this phase of the assessment is to ensure the application uses a valid digital certificate.
  7. Input Validation: This phase of the assessment is focused on testing the input validation of the web application. Input Validation testing includes the following:
    1. Script Injection: The goal of this phase of the assessment is to ensure that any part of the application that allows user input does not process scripts as part of the input.
    2. SQL Injection: The goal of this phase of the assessment is to ensure the application will not process SQL commands from the use
    3. OS Command Injection: The goal of this phase of the assessment is to ensure the application will not process operating system commands from the use
    4. LDAP Injection: The goal of this phase of the assessment is to ensure the application will not process LDAP commands from the use
    5. Cross Site Scripting: The goal of this phase of the assessment is to ensure that the application will not store or reflect malicious script code.

Exploitation: This stage of the penetration testing methodology is all about performing security testing of the platform, based on a Top-Down analysis of vulnerable system components identified in the previous stage. This will include performing manual checks, automated tests and various reviews to uncover security vulnerabilities.

The exploitation phase consumes the single largest amount of time and is down to the tester’s skill, knowledge and gut feel.

Often, we will come across services that require authentication. Services with authenticated logins are tested against a username and password list created in previous phases. Medusa, Ophcrack and Inguma are typically used. The goal of this aspect of the assessment is to obtain access to services and devices that is not available through configuration error and vulnerability exploitation.

Our testers will use a variety of tools and call on the collective experience of the teams to perform the manual testing phase.

For testing web applications, we will intercept all HTTP traffic using a web proxy and manually review the requests and responses to identify vulnerabilities.

For testing of network applications, we will intercept all IP traffic using a traffic monitor and manually review the requests and responses to identify vulnerabilities.

At the bear minimum the tester will cover is shown below:

Penetration Testing Methodology

Documentation: This stage of the penetration testing methodology is all about the analysis of the gathered data and the results of the various reviews. The analysis includes categorising the detected vulnerabilities and prioritising them per the business and technical context.

The Hedgehog Security methodology includes a systematic Security Risk Analysis & Evaluation process though-out the life of the testing. Much of the testing performed is done in a loop, revisiting the tested system over and over again as more is learned about the target.