Vulnerability scanning can be like a black box at the best of times. You put your targets in, run a scan, and your results come out. But what happen in-between “what are we actually testing your systems for?"

With so many vulnerabilities out there, it's impossible to list them all, but this article should give you an understanding of the different types of weaknesses we can detect, and how we do it.

Common mistakes & configuration weaknesses

You'd be surprised at how easy it is to take a piece of ‘secure’ software or hardware (like a web-server, or an office router), and inadvertently configure it in such a way that it becomes vulnerable to attack.

Some of the most damaging breaches over the last few years have come about because of simple mistakes such as leaving code repositories or databases full of customer info exposed to the internet.

It may sound like a tall order but hardening your systems against the perils of the internet needn’t be a major cause for concern – especially if you’re using a scanner like Intruder. We have thousands of checks for these kinds of mistakes and specifically tailor the results to focus on high-risk issues affecting internet-facing systems – giving you visibility of the issues that need to be fixed asap and reducing the likelihood that an attacker will find them first.

Missing patches

Patch management is a fundamental part of keeping your digital estate secure and applies to all companies, no matter the size. The infamous Equifax breach was a result of not applying patches quickly enough.

Intruder’s scanning engines can detect frameworks, hardware devices and the version of software components into the thousands, using various methods such as ‘banner grabbing’ (where software reports its own version) or ‘fingerprinting’ (which looks for certain behaviours).

Our Pro subscription takes this one step further with agent-based scanning, which is even better at determining which versions of software are being run on internal devices.

Application bugs

Application bugs have been known about for decades, but still account for a large proportion of breaches. One type of application weakness (known as SQL Injection) was the cause of the famous Talk Talk breach.

The types of application weakness that Intruder checks for includes, but isn’t limited to: SQL Injection, Cross-Site Scripting, XML Injection. Attackers can use these weaknesses to gain access to your systems and information and then modify them to cause maximum damage.

For those with Authentication licenses, we also check for vulnerabilities behind the login page (the authenticated layers of a web-app) – covering the majority of the CWE Top 25 and all but one of the OWASP Top 10 vulnerabilities. For a full list of the checks that we run as part of Authenticated web application scanning, please head to this article.

Attack surface reduction

Less obvious than the other categories, but still important is attack surface reduction. In short, this exercise is about finding unnecessary services that your systems expose to the internet and removing them in an effort to curb what a hacker could potentially exploit.

A perfect example of this would be the WannaCry ransomware, which became infamous for its exploitation of a seemingly innocuous piece of software. A Microsoft Windows service designed for file sharing and printers on local networks was accidentally exposed to the internet, resulting in a virulent spread across the internet and untold damage.

Encryption weaknesses

The internet relies on encryption for almost everything to do with security, without it there would be no online banking for example; but encryption isn't flawless and frequently weaknesses are discovered in algorithms previously thought secure.

It’s for that reason that Intruder checks for all the latest known encryption weaknesses, including SSL/TLS and VPN encryption weaknesses.

See and search all checks

If you've signed up for a free trial or you're currently a customer and your first assessment has been completed, you can access and search the full list of external infrastructure checks we perform by clicking on any of the buttons in the checks section on your dashboard.

Do all checks get executed all the time?

All checks are enabled, but this does not mean that all checks will be executed against every service that your systems has listening on the internet. Instead, vulnerability scanners will 'fingerprint' the service running on that port and execute checks for that service only (there’s little value in executing a check for a different type of service other than the one that’s listening on your system).

Did this answer your question?