BLACK BOX

Pentesters have no—or very little—information on audit targets.

The objective is to simulate the approach that an external malicious actor will take to target and attack the company. This approach will require the pentesters to first search for information and identify targets using passive (open-source data, etc.) or active means (port scans, DNS queries, etc.).

This approach can be interesting if the objective defined for the pentest is to analyse the general exposure of the company to external threats or during “Red Team”-type approaches (we will see the definition below).

However, as a pentest engagement is often limited in time, this phase of research and identification will necessarily be just as restricted. This is a constraint that a real attacker does not necessarily have, as they may spend weeks or months gathering relevant information before an attack. This approach is therefore not necessarily optimal if the pentest is very focused or very limited in time.

GREY BOX

In this framework, pentesters generally have the same level of knowledge as a standard user of the system.

For example, they can have access to internal accounts (preferably belonging to different user profiles) or to a PC provided by the customer with standard access rights and configurations. It is also possible to share information on internal architecture.

The objective here is to have a more targeted and therefore more optimised approach in terms of pentest time. With the information provided, pentesters can focus their efforts on targets with the highest criticality levels or spend more time on more technically complex tests.

Similarly, by providing user accounts, it is possible to simulate two types of attack scenarios:

One, where the attacker manages to compromise a legitimate account
And a second one, where a malicious internal user wants to harm the company.

WHITE BOX

Pentesters have as much technical information as possible (architecture, source code, identifiers, etc.) before starting the pentest. It is also possible to set up communication channels between the pentesters and the sys admins or development teams to analyse and exchange on technical issues.

The objective of this approach is to provide a detailed analysis of both external and internal vulnerabilities. However, it poses several challenges:

The amount of input data increases exponentially with the size and number of targets. The analysis of all this information necessarily requires more time, and the duration of the pentest will be extended.
Specific skills for this type of pentest are required, ranging from static code analysis to the mastery of best practices for network architecture or equipment hardening. AUSY, thanks to our diverse skill-pool and the expertise of our community, is able to meet this challenge.

Since the pentesters have a high level of information that external attackers will not have access to, it is possible to overlook scenarios that are based on lower levels of knowledge when studying different attack paths.

To sum up, if the objective of the pentest is to exhaustively analyse a small number of targets (e.g. a new mobile application, a new email server or a new connected watch), a “white box” approach seems the most appropriate, whereas if the objective is to simulate a realistic attack, the “black box” approach will be the closest to reality.

If the duration of the pentest allows, it is also possible to combine approaches, which allows for a better coverage of the different types of risks, starting with a black box analysis from the outside, then with the information provided to study the internal grey box attack scenarios and, finally, study the source code and configurations in a white box approach to identify the remaining vulnerabilities. This is the approach we recommend to our clients at AUSY.

PENTESTER TEAMS

You may also have heard about Red/Blue/Purple teams, a quick explanation here :

“Red Teams” : their objective is to test a company’s defences by simulating the different techniques and tactics of malicious actors in a continuous and evolving manner.
“Blue Teams” : their objective is to defend the company from attackers (both external and internal) and to adapt protection tools and systems according to their operating methods.
“Purple Team”: the objective is to ensure effective exchanges between red and blue teams within an organisation. This may not be a true team but simply regular procedures and exercises to encourage dialogue and improve the working methods of both groups.

Prepare the information:

Once the level of knowledge has been defined and the colour of the box chosen, it may be beneficial to anticipate and prepare the answers to the questions that will be asked by the provider during the first technical meeting.

Below are a few examples (list not exhaustive):

For application pentests:
- A functional description of the target (What is the purpose of the application, who uses it, how often, its level of criticality for the company, what are the key functionalities, etc.)
- A technical description of the target (How old is the application, is it updated often, what is the language/framework used for development, how does the application interface with other tools, etc.)
- An estimate of the size of the application (Number of different roles, number and type of user interactions, forms, file uplaods, number of static/dynamic screens, etc.)

For infrastructure pentests:
- The number of active IPs in the test scope.
- The types of environment present (user workstations, Linux servers, industrial equipment, etc.)
- Presence of atypical/legacy equipment (MainFrames, AS400, etc.)
- Security measures in place (FW / IPS / SOC Team, etc.)

For the conditions of the pentest:
- Is there a possibility to use test environments?
- Is there a possibility to access applications/infrastructures remotely?
- What inputs are provided by the customer?
- Will internal security teams be notified?
- What types of tests are allowed/prohibited?
- What are the limits of the scope or depth of the pentest?
- Is there a possibility to consult and validate any previous pentest reports ?

For the organisation of the pentest:
- What are the possible start dates for the test?
- What are the specific constraints on working hours/days?
- What are the constraints from business teams?
- What are the agreements of third-party suppliers, if any?

Depending on the targets and the level of knowledge defined, the exchange can become quite technical, so it is important to involve both business and back-office players in order to provide the most precise answers possible.

At AUSY, we offer our clients forms and questionnaires that can help you prepare for these initial technical interviews while saving time.

How the pentest will work:

Each pentest and customer context is specific, so it is important to adopt a fairly generic working methodology for the majority of cases. One of the references in the field is the Penetration Testing Execution Standard (PTES).

WHAT IS THE PTES?

The PTES is a generic set of good practices that establish the fundamental principles for properly conducting a penetration test. The word “generic” is important here because the PTES can be applied to a mobile application pentest as well as to an intrusion test on a company’s premises.

The PTES breaks down each pentest into 7 main steps:

1 - Interactions before the pentest

This phase includes all the exchanges described above, contractual and financial agreements, the establishment of secure communication channels and the preparation of the pentest.

The objective is to establish a legal, technical and organisational framework, approved by the client and the service provider and thus guarantee a fulfilment that meets the expectations of both parties.

At AUSY, we offer our clients a well-organised preparation process and a complete set of contractual documents:

Agreements that govern the pentest service with the commitments, limits and responsibilities of each party.
Confidentiality agreements.
Business agreements according to the type of assignment (TA / Fixed price, etc.).

2 - Information collection

This is a very important phase for each pentest because it allows us to identify potential targets, gather useful information for the later stages, and identify possible angles of attack from the outset.

We often talk about two types of reconnaissance:

Passive reconnaissance:
OSINT (Open Source Intelligence) - publicly available data. The “OSINT Framework” (https://osintframework.com/) provides a good overview of the type of data that can be used.
Data available through normal use (by browsing the application, analysing network traffic and web headers, for example, or via specific Google searches).
Active reconnaissance using dedicated tools:
Port scans.
DNS and SMTP Enumeration.
Exposed services (email server, ssh, web, etc.)
Accessible or hidden documents and files...

At AUSY, and if the service so requires, our pentesters also take advantage of this phase to check various public sources or the darkweb to identify any sensitive client data (accessible documents, compromised user accounts, known sub-domains, etc.) and provide a condensed report.

3 - Threat modelling

The objective of this phase is to identify the main targets within a company (both in terms of assets and processes) and the most likely sources of threats (their origin and technical capabilities).

The process is generally divided into 4 steps:

Collect information (architecture diagrams, internal organisation diagrams, employees, customer data, etc.)
Identify main and secondary assets (ERP software, corporate website, customer database, etc.)
Identify threat sources (hacktivists, state organisations, organised crime groups, internal employees, etc.)
Map threats to the identified assets.

Let’s take the example of a company working in the petrochemical industry:

Its most critical assets may be industrial production tools and related technical information, patents and R&D, employees personal data, financial information and the showcase site.
And as vectors of threats: state organisations, organised crime and hacktivists seem most likely.

The first two have the technical knowledge and means to target the most sensitive assets; hacktivists will instead use publicly available tools to try to deface the showcase website for example.

Although applicable for all types of approaches, the conclusions of this phase will be most relevant when the pentest is conducted in “white box” mode as the analysis will be more accurate with the internal information provided.

4 - Vulnerability Analysis

Although the techniques used may vary greatly depending on the type of targets in the pentest, the main objective of this phase remains the identification and validation of exploitable vulnerabilities.

Techniques, both active (vulnerability scans, directory enumeration, headers grabbing, etc.) and passive (network traffic analysis, metadata analysis), automated or manual, are used. The information collected is then correlated and validated.

For example, the pentesters will search for known flaws in the detected software versions, look for default credentials or analyse the most common configuration errors on the targeted systems.

All this information will help to create attack trees (a list of possible attacks depending on the target and the information collected) for the operations phase.

At AUSY, our pentesters have dedicated tools and software at their disposal and are encouraged within the internal cyber/pentest community to stay informed of new techniques and vulnerabilities so that they can then apply them within the framework of our services.

5 - Exploitation

The operating scenarios can vary greatly. They depend on the type of pentest and the targets, and can range from attacks on human actors (phishing, identity theft) to searching for “0 day” vulnerabilities if all other methods have failed, through reverse engineering, query manipulation, setting up “Man in the Middle” scenarios or fuzzing (injections of erroneous data). All this while trying to avoid the protection and detection measures in place if the conditions of the pentest require it.

The pentester must always check that the operating techniques used correspond to the scope and conditions of the agreement with the customer.

During this phase, our pentesters can rely on the pool of technical skills of the AUSY pentest community.

6 - Post-Exploitation

This phase (sometimes optional), which is only applicable if the previous step was successful, has several objectives:

Establishing malicious and permanent access channels (persistence in English),
Identifying accessible sensitive information,
Retrieving evidence of the success of the pentest for the final report (usually screenshots),
Retrieving additional access and user accounts, allowing other elements of the information system to be compromised.

The rules of engagement approved during the technical meeting at the start of the project are very important here:

Are they allowed to access personal information and files?
Are they allowed to disable the protective measures in place?
Are they allowed/required to hide actions performed by deleting logs?
How should they react if a past or ongoing real attack is discovered?
What sensitive information should be included in the report and in what form?
How will sensitive information that is identified be stored and transmitted?

All these rules aim to protect both the customer and the pentester and guarantee data security and the legal compliance of the actions carried out.

7- Reports

The final stage of the pentest consists of writing and submitting reports, usually in three different formats:

A restitution presentation: This presentation, often in PowerPoint format, is more or less technical depending on the audience present and recalls the context and objectives of the pentest. It then presents the general stance towards security risks and the main vulnerabilities identified with the associated corrections. This presentation is often followed by a Q&A session between the client and the pentesters.
A report for management: A summary that recalls the context and the objectives, briefly describes the course of the pentest, presents the results in the form of numerical or graphical indicators (summary tables, graphs, etc.), the risk and impact analysis of the different vulnerabilities identified with the associated corrections and a suggested schedule for applying them according to their priority.
A detailed technical report: This report includes the information presented in the report to management, while providing additional technical information. Thus, for each vulnerability, the following can be provided: OWASP & CWE references, indicators of risk and impact and ease of exploitation, a detailed explanation of the vulnerability and exploitation path, the tools used, advice for correction, and finally, the related evidence.

All this information should allow the customer to analyse and understand the vulnerabilities, reproduce them if necessary and then apply the appropriate patches and present them to management or auditors if necessary.

The project should not stop once the pentest report has been submitted. It is important to ensure the support of management to approve the schedule as well as the technical resources necessary to implement the corrective measures.

If they are complex or require extensive modifications, it may also be appropriate to add additional time to the pentesting project to retest and validate their effectiveness.

Conclusion:

In conclusion, a pentest is a method of assessing a company’s IT security that can help a company improve its security posture. However, to be effective, the pentest must be prepared, monitored and, if possible, conducted regularly.

Therefore, choosing a service provider capable of accompanying you from the first exchanges until after the delivery of the reports and beyond plays a very important role.

Our experts rely on the know-how and skills of the AUSY community to support you from A to Z throughout the duration of your pentest project and help you improve your security posture.

categories

topic