Testing the external attack surface
What is reachable from the internet, recorded service by service and tested one at a time. With a rating, reproduction steps and a retest.
What is reachable from the internet
What a company makes reachable from the internet grows with every project: a portal, a VPN access, a test system for a service provider, a camera at a site. What was opened once usually stays open.
A test of the external infrastructure records which services actually answer today and examines them one at a time: state, version, configuration, authentication. At the end there is a list that separates the expected service from the open door.
What gets tested from outside
The division follows what is reachable from the internet at all. The emphasis shifts with what you run.
Reachable services
Every port that answers, with product, version and configuration. Known weaknesses are confirmed, not derived from a version number.
Portals and logins
What lies behind a login screen, how it reacts to wrong attempts, whether a second factor takes hold, and whether accounts can be tried one after another.
Remote access
VPN gateways, RDP, management interfaces of firewalls and servers. The route by which ransomware regularly arrives, and the first one we test.
Email and DNS
SPF, DKIM and DMARC, open resolvers, zone transfer, orphaned records. Without DMARC enforced, anyone can write in your name, and that is established from outside in a minute.
Certificates and encryption
Validity, issuers, the methods in use, and what the certificate transparency logs say about your environments.
The test system nobody switched off
A service on port 8080 that appears in no documentation. Behind it a test environment set up two years ago for a service provider and never switched off after the project. It asks for no password, because for testing it was not supposed to.
The data in it is a copy of production, taken the spring before. That makes the find no longer a test environment but a data leak that simply nobody has noticed. The rating follows what is reachable, not what the system is called.
Something like that gets found through the port and rated through what lies behind it. A vulnerability scanner reports a web service with no known weakness at this point, which is to say nothing.
What you already give away
Before anything is touched, what is public anyway gets gathered. That is called OSINT, open source intelligence, and in an external test it is the first step: domains and subdomains, certificate transparency logs, IP ranges and who owns them, names and addresses from the legal notice and from networks, job adverts naming the technology in use, files with metadata, credentials from past data breaches.
The reason is plain: an attacker starts the same way. What can be found in this phase determines where they go in, and therefore it determines where we go in. The first finding regularly arises here already: a forgotten test server on a subdomain, an account from somebody else's breach that still works.
The research is passive: we read what is publicly there and do not touch your systems. What comes together goes into the report, even when it is not a weakness in the narrow sense, because it can usually be stopped.
This step is bookable on its own as an OSINT analysis, if you want to know how large the surface is before it gets tested.
A version number is not yet a finding
A vulnerability scanner reads what a service says about itself and matches it against a database. The result is a list of guesses: this service names a version for which an entry exists. Whether the gap is really open in your installation, the list does not say.
We use such runs to record the surface. After that every point is reproduced by hand, and only what is confirmed goes into the report. The difference is practical: a scanner list with thirty entries occupies your team for weeks; a report with four confirmed findings and an order of work does not.
The part no tool does is the connection. A test system on an unusual port, an account from an old breach and a login without a second factor each sit low in any list. Together they are the way in.
How an external test works
Three to five days, depending on the number of reachable services. Testing follows the BSI practical guide for IS penetration tests, PTES and OSSTMM; every report goes through a second-pair-of-eyes review.
Fix the scope
Which network ranges and domains belong to you. Including the ones a service provider runs, because from the internet that is not a distinction.
Survey
Reachable services, versions, certificates, redirects. Plus the names and addresses that publicly lead to you.
Testing
By hand, service by service. Known weaknesses are confirmed, not merely derived from a version number.
Report and retest
Findings with reproduction steps, and afterwards on request the check that the fixes work.
A report your team can work from.
Every finding comes placed: with risk, effort and the route to a fix.
Management summary
The position on one page, readable for management and the board.
Technical findings
Every finding with a unique finding ID, evidence and reproduction steps.
Risk rating to BSI
A traceable rating of every find against a recognised scheme.
Prioritised recommendations
Concrete recommendations in the order in which they take effect.
Closing meeting
On request, a joint walk-through of the results with your teams.
Retest
On request, a re-examination of the fixed weaknesses, with confirmation of the state.
What we need, and what is not included
From you we need the network ranges and domains that belong to you, a contact for the duration of the test and a written release. If a service sits with a provider, we obtain their permission together with you before touching it.
Not included are attacks on people and on availability. Social engineering and phishing simulations are services of their own, and we do not carry out denial of service tests. What lies behind the login is tested by the internal test; web portals and interfaces have their own pages under web applications and APIs, because testing there follows the OWASP ASVS.
Common questions about the external test
The survey runs without load. Tests that could put load on a service are agreed beforehand and carried out in an agreed window.
Once a year as a baseline, plus after every major change to the reachable services. Between tests, continuous monitoring of the attack surface helps more than a second test.
What often goes with it
Certifications and memberships.
Talk to us.
A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.