Five High findings, zero way in
An automated scan flagged five High findings and nineteen Medium. It reads like a call to go put out a fire. We checked each one by hand, and not one of them let us into the network from the internet.
The client's employee accounts were still genuinely exposed, just in a place the scanner never showed at all.
This is the difference between a scan and a test, told through one project, with a mapping to MITRE ATT&CK.
Context
The client gave us a narrow, precise scope: a dozen or so public addresses exposed to the internet, a classic perimeter. The question was just as simple. Can someone on the outside get in this way?
The environment had grown over years and it showed. A few Linux servers running web services and SSH, a handful of network switches, a time server, DNS, SNMP, admin panels open to the world. Some hosts looked freshly maintained, others remembered days we would rather not write about in the present tense.
Challenge
At first glance it looked bad. An automated scan counted five High findings and nineteen Medium, mostly on outdated versions of OpenSSH and nginx. One of the servers announced itself with an SSH banner a decade old:
$ nc klient.example 22 SSH-2.0-OpenSSH_6.0p1 ...
To a scanner, a banner like that is a ready-made CVE list. It attaches them automatically because it sees a version number; it does not check whether the flaw can actually be used. And that is where the real work starts.
Because the other side looked different from what the list suggested. The perimeter was not careless. Mail sat behind an external security gateway, web traffic behind an anti-DDoS service, the SPF record was correct, and there were no vendor default passwords anywhere. Someone here thought about security, just unevenly. A credible report has to say that before it makes its case.
What we did
We started with full recon: a scan of every TCP port and the thousand most common UDP ports, no ping, to catch hosts that ignore echo requests but still listen. Then fingerprinting of every service, so we knew what we were dealing with, not just which version number it claimed.
In parallel we ran open-source recon. A Grey Box approach: minimal interaction with the system, maximum use of what the world already knows about the client: subdomains, DNS configuration, public data breaches.
We tested initial access along two tracks. Brute force against services with a login, including admin panels and the VPN. And an attempt to use what we found in the breaches as real login credentials.
The whole thing maps to MITRE ATT&CK like this:
The most important part of this test is not the CVE table. It is the manual verification of every item in it. We checked the conditions for exploitation one by one: whether the required module is even enabled, whether the attack only works over a reverse connection, whether it can be chained with anything else into a sensible vector. The answer came back much the same every time. Not from here.
Result
None of the vulnerabilities found on the perimeter let us into the network from outside. Zero CRITICAL. The five High and nineteen Medium were genuinely outdated versions, but the conditions to exploit them were not met: modules were not enabled, some attacks only worked over reverse connections, and none chained together. There were no vendor default credentials either. The brute force attempts failed.
If the report ended here, it would be pleasant and useless. Because the real risk sat outside the “severity” column.
First, in public breaches we found working pairs: an employee's email address and a password for accounts on the client's domain. Not from their network, but from other people's databases that leaked years ago. The perimeter was tight, and the spare keys were sitting at the neighbor's.
Second, the age of the software said something on its own. A server running decade-old SSH is not dangerous today, but it is proof there is no process for rolling out patches automatically. What is harmless today gets a public exploit tomorrow, and nobody notices, because nobody is looking.
We set the recommendations by priority:
- Put in place an automated patching process and bring outdated services up to supported versions, starting with the hosts exposed to the internet.
- Force a password reset for the accounts that showed up in breaches, and turn on multi-factor authentication where it is not yet in place.
- Wire in continuous breach monitoring, so the next login-and-password match gets caught before someone else catches it.
- Clean up the certificate configuration and trust chain on internet-facing services, and cut the excess version disclosure in headers and error pages.
- Disable weak MAC algorithms and CBC ciphers on SSH, and close the Terrapin vulnerability with a strict key exchange.
An external network test that ends with a bare CVE list answers the wrong question. “Which old versions do you run” is not the same as “can someone get in through them,” and those two questions lead to completely different budget decisions.
If your last test was a list of vulnerabilities without a single line on whether any of them can actually be exploited, you got a scan, not a test. When did someone last check whether your accounts are already sitting in someone else's breach?
Book a call with a consultant. Together we will go over the scope of an external network test, the risks, and what such a test could look like for you.
All case studies are anonymized by sector, without names, dates or any data that could identify the client, in line with confidentiality. We never publish real vulnerabilities or client technical data.