A penetration test (pentest) is a method used to audit the security of an application, system or a computer network.
To do this, an auditor (pentester) will, at the request of the owner of a computer system (website, server, workstations ...), put himself in the place of a hacker and try to hack it, all using the same techniques as a real attacker.
This allows to detect security flaws and to correct them before they are exploited by a real attacker. However, unlike a real attacker who will usually stop once the system is compromised, the pentester will try to find as many vulnerabilities as possible in the time allotted to it, following a strict and efficient methodology.
Following the penetration test, a detailed report allowing to understand and correct the vulnerabilities is given to the customer.
This discipline is called "Ethical Hacking", the goal being to work closely with the customer in order to bring him solutions allowing him to reinforce his computer security.
When you wish to carry out a pentest, the first step will be to define together your target and your needs and which approach will be the best for you (Blackbox, Greybox, Whitebox...), while taking into account your budget.
Once these elements are defined, we will sign together a contract and a test mandate, which authorize us to perform intrusion tests on a specific target, for a specific time and date.
We will then perform the actual penetration test following our methodology. Once the tests are completed, we will write an audit report detailing the vulnerabilities discovered and the solutions to correct the vulnerabilities.
Finally, this audit report will be presented to you in a videoconference by the pentester responsible for the project and will then be sent to you in a secure manner.
A validation phase of the corrections you have implemented may also be planned.
In order to carry out a security audit that is as reliable and accurate as possible, we rely on industry standards, and in particular on the recommendations and methodologies of the OWASP. We perform many manual tests, and we also use many specialized security tools that allow us to automate and deepen certain tasks.
This methodology is based on a series of four major steps carried out in a cyclical manner:
During our reconnaissance, we look for public information about our client and our target. This allows us to understand our target and its environment. It also allows us to check if sensitive data related to our client is present on the internet and/or on the darknet. For example, if data has been stolen and published somewhere, we can inform him.
During this phase, we will study in detail the functioning of the target application or system and its environment. We will precisely list the different functionalities and services that are accessible and that are part of what we have to audit. This allows us to have an overall vision so that we can allocate the time we have for our audit in order to be able to cover everything that is necessary.
It is during this phase that we will really start looking for vulnerabilities on the target application or system. However, we will not necessarily exploit in depth the discovered vulnerabilities, as this could be time-consuming, and we could run out of time to discover other vulnerabilities. We will therefore identify as many vulnerabilities as possible and perform the exploitation in the next phase.
It is during this phase that we will really exploit the vulnerabilities we discovered during the previous phase. This allows us to evaluate the impact they may have in order to advise our client in the best possible way. It can also allow us to discover other vulnerabilities.
When performing an intrusion test, there are generally three approaches:
For an audit carried out in Blackbox, no particular information is provided to us by the client other than our target. We are therefore as close as possible to the context in which a real attacker would find himself.
This approach can be interesting for a first security audit, because it allows to evaluate the security level at a precise moment and in real conditions. However, some parts of the application or the system may not be audited, such as the administration parts.
For an audit performed in Greybox, the customer provides us with specific user accesses that a real attacker would not have directly, such as administrator accesses. The client can also provide us with documentation that allows us to better map and understand an application or a system. Moreover, with this approach, technical exchanges with the customer are possible, allowing us to go even deeper into certain aspects.
This approach allows us to go much further than with Blackbox. For example, on a Web application for which an administrator account has been provided, it is possible for us to precisely evaluate the impact of a vulnerability exploited by a classic user and targeting an administrator.
The Whitebox approach has all the advantages of a Greybox audit but the client provides us with all the elements we need to understand in depth how an application or a system works. For example, we can have access to the source code of an application or to an administrator account of a production server.
Here, we will use the elements provided (source code, various accesses) in addition as a support for our penetration test. We will not perform a source code audit here (this is another type of service that we also offer) but it will allow us to remove doubts much more easily or to discover vulnerabilities that would have been very difficult to detect by more conventional means.
At the end of any penetration test, we will provide you with a report listing the various vulnerabilities discovered, sorted by criticality, as well as the elements discovered during the reconnaissance phase.
For each vulnerability, you will find a description of the type of vulnerability and what it involves. You will then find technical details allowing you to understand and reproduce the discovered vulnerability. Finally, for each element, we will suggest ways to correct it.