Vulnerability Scanning (T1595.002) is a sub-technique of Active Scanning, filed under the reconnaissance tactic in MITRE ATT&CK. Its platform is PRE, meaning it takes place before any access to your environment.
The idea is simple. Someone checks whether a host or application is configured, or running a version, that lines up with a specific exploit they already want to use. If it does, the scan has saved them a lot of guessing.
This is the same activity your own security team does with a scanner. The difference is who gets the results first.
How attackers use it
MITRE says adversaries scan victims for vulnerabilities by checking whether the configuration of a target host or application, such as its software and version, potentially aligns with the target of a specific exploit.
These scans may also be broader, with attempts to gather victim host information that can identify commonly known, exploitable vulnerabilities. To do that, scans typically harvest running software and version numbers from server banners, listening ports or other network artifacts.
Notice what that means. The scan does not need to break anything. It reads what your systems volunteer: a banner that names the product and version, a port that is open, a response that differs between releases.
MITRE notes where the output leads: further reconnaissance such as searching open websites or technical databases, establishing operational resources by developing or obtaining capabilities, and initial access through Exploit Public-Facing Application.
How to detect it
MITRE's detection analytic has three parts.
- Monitor and analyze traffic patterns and packet contents for protocols that do not follow expected standards and flows. Examples are extra packets that do not belong to established flows, gratuitous or anomalous traffic, and odd syntax or structure.
- Correlate network activity with process monitoring and command lines, to catch anomalous processes and arguments tied to those traffic patterns. This includes files that do not normally initiate connections for that protocol.
- Monitor network data for uncommon data flows, and treat processes that use the network without normally doing so, or that were never seen before, as suspicious.
The data sources this implies are network traffic content, network flow, and process and command execution telemetry.
A realistic approach for a small team:
- Alert on a single source sending a rapid sequence of requests that look like probes for different products. A burst of requests for unrelated product paths from one client is a common pattern.
- Look at inbound requests that cause protocol errors. Scanners often send malformed or unusual requests to see how the server reacts.
- Track which assets get probed most. If scanners keep hitting one product, you learn what is attractive about it.
The false positive and noise problem is real. You will see scanning every day. Detection helps most when you connect a probe to a later event on the same system.
How to reduce the risk
MITRE's mitigation for this sub-technique is Pre-compromise. It says the technique cannot be easily mitigated with preventive controls because the behavior sits outside enterprise defenses, and that effort should go to minimizing the amount and sensitivity of data available to external parties.
For vulnerability scanning, that points at a few things you control:
- Reduce what banners reveal. Where a product lets you hide exact versions, hide them.
- Patch internet-facing software promptly, starting with whatever a scanner would find first.
- Remove services that do not need to be public.
- Know your components. A scan matches versions to exploits, so you need your own list of versions and a way to match them to known issues before someone else does.
That last point is the one teams skip. Application dependencies are part of what a scanner effectively fingerprints through behavior and responses. A free in-browser check can help here. The Safeguard dependency scan runs without a login, keeps your file on your machine, and covers up to 100 dependencies. It will not replace a full inventory, but it gives you a first look at known-vulnerable packages in a manifest.
Check your own environment
Run these only on systems you own.
List listening services (Linux, iproute2):
ss -tulpn
See what a web server says about itself (curl, any OS):
curl -sI https://your-domain.example
Read the Server header and any version strings.
Then ask:
- Can you list every internet-facing service and its exact version in under an hour?
- Do you know which of those versions has a public fix you have not applied?
- Is the version string visible to people who should not need it?
- Would you notice one client probing five different products?
Try it yourself
Knowing a version is vulnerable is not the same as knowing it is reachable and exploitable. This demo walks through that distinction.
Click through it at your own pace, or open it full screen.
Quick check
What does a vulnerability scan usually collect to decide if a target matches an exploit?
Running software and version numbers, taken from server banners, listening ports and other network artifacts.
Why does MITRE focus its mitigation on limiting data available to external parties?
Because the scan is performed outside your defenses, so preventive controls cannot easily stop it. You can only control how much useful information it returns.
