As Patrowl is CERT, we monitor continuously using our custom Threat-Intelligence, all CVEs, all exploitation code or exploitation techniques published. We also track for any changes or any news that could indicate a vulnerability will be or is being used and exploited by attackers.

This monitoring is fully automated, and continuously supported by our cybersecurity experts. Every new security event will then be analyzed using our own algorithms, and filtered regarding its context, its exploitability, and the likelihood of being used and exploited by attackers (is the vulnerability “wormable”, which means it could be integrated in massive exploitation campaigns by attackers).

Then, if the CVE (or the security event) could have an impact on an external attack surface, you will receive an email and an alert on the dashboard indicating that we are currently checking all your external surface.

Patrowl will then use all the information they have to be the most accurate regarding the exploitability of this vulnerability on your external attack surface, always to avoid false positive and useless work for your teams.

All this information could be found in Threats / Trending Attacks menu.

It is important to differentiate between two very specific uses-cases depending on the status of your assets.

When the Pentested mod is activated on an asset, it allows Patrowl to use the full capabilities of the product and our Pentest automation.

It means that we will be able to detect, with the highest accuracy you can get, if your Pentested assets are vulnerable to an exploitable vulnerabilities. Basically, we will perform the exact same operations that worldwide attacker will perform.

To have a better understanding, let’s take a basic example. Let’s work on the https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42013, a Path traversal found in Apache Server in 2021.

Regarding MITRE, here is how to exploit the vulnerability:

“An attacker could use a path traversal attack to map URLs to files outside the directories configured by Alias-like directives. If files outside of these directories are not protected by the usual default configuration "require all denied", these requests can succeed”.

The vulnerability is promising, and could allow an attacker to reach system or applicative files, causing potential important data leak or even remote code execution in worst case scenario. Apache is widely used especially on external attack surface that is why this is pretty interesting.

Now, how to detect if an asset is vulnerable or not ? Hardly all basics scanners or EASM solution will base their results on the version printed, sometimes by the Apache server on Headers.

A quick look on Shodan searching for a vulnerable version (focus on Apache 2.4.49):

https://www.shodan.io/search?query=Apache/2.4.49, we found a potential vulnerable asset :

And, surprise, our CVE is lost in 55 “potential others vulnerabilities”, with basically similar CVSS core and other with critical CVSS Score.

First of all, let’s discuss about the accuracy of that type of control.

The header used by this kind of tool to detect if the version is vulnerable or not could be very easily changed by a System Administrator in configurations : https://unix.stackexchange.com/questions/124137/change-apache-httpd-server-http-header, and in many cases, the application that will use Apache System will automatically hide or replace this header by a simple “Apache” string (90% of server on Shodan print this basic string):

On the 15,580,253M Apache server referenced by Shodan, can you guess how many could be really exploited by an attacker? The only way to have this key information is of course to use Patrowl 🦉

The CVE-2021-42013 is a very good example of how Patrowl works. The exploitation of the vulnerability requires knowing and discovering specific paths of the application, and it also required a very specific configuration applied on the server’s side (Alias-like redirection). This configuration is in fact pretty rare. Having a “potential vulnerable version” hardly never indicate that you have an exploitable service.

Using our automation, we collect continuously a very large number of metada regarding your assets. This will include injectable path, information on services, strange behavior etc. Using this information, we will be able to check with very high level of confidence and efficacy the exploitation code on your Pentested asset.

For the CVE-2021-42013, we are able to check on all continuously gathered webpage of all pentested asset, if it exists an Alias-Like redirection, and if this redirection could be exploited.

If the vulnerability has been released but has no valid exploitation code is available nor working, it will also be classified as “Potential impacted” assets.

For assets which are not Pentested, we do not have the authorization of performing offensive operation on it. Metadata collected will be less accurate, and we can’t check if the vulnerability could be exploited or not.

But, to be sure we cover all your external attack surface, we will use passive metadata collected to detect potential vulnerable non-pentested asset in the most accurate way.

You will then have a notification for the “Potentially impacted” (or Warning assets) non-pentested assets, indicating that we have clues about the product, but no ability to test exploitation code.

You can also find this information directly in the Trending Attacks, Warning assets.

As the vulnerability could not be exploited, no “qualified vulnerabilities” are created, but you can export the list directly in the menu.

Then, if we do not find any valid exploitation path, nor any clues about the product being used on your external attack, you will have the notification : You are not impacted. The best notification you can receive from a CyberSecurity product.