Active Scanning (T1595) is a reconnaissance technique. The adversary sends traffic to your infrastructure to learn about it, instead of reading about you in public sources. MITRE files it under the reconnaissance tactic, and because it happens before anyone is inside your network, the platform is listed as PRE.
If you run anything on the public internet, you are being scanned right now. That is not a guess about your company in particular. It is the baseline condition of an internet address. The useful question is what a scan can learn and what you do when the answer is more than you intended.
How attackers use it
MITRE describes active scans as probing victim infrastructure through network traffic, as opposed to reconnaissance that never touches the target. The probes can use native features of network protocols such as ICMP.
What the adversary wants depends on the goal. MITRE splits the technique into three sub-techniques:
- Scanning IP Blocks (T1595.001): finding which addresses in an allocated range are alive and what runs on them.
- Vulnerability Scanning (T1595.002): checking whether software and versions line up with a specific exploit.
- Wordlist Scanning (T1595.003): guessing page names, directories and cloud storage names to find content you did not mean to expose.
The results feed later steps. MITRE says scan output can point to other reconnaissance, such as searching open websites or technical databases, to building or buying capabilities, and to initial access through External Remote Services or Exploit Public-Facing Application. In other words, a scan is rarely the goal. It is a shopping trip.
How to detect it
The MITRE detection analytic for this technique is short and practical. Watch network data for uncommon data flows, and for traffic that does not follow expected protocol standards. Examples MITRE gives are extra packets that do not belong to established flows, odd traffic patterns, and anomalous syntax or structure.
It also suggests correlating network activity with process monitoring and command lines, which matters for scanning that starts from a host you already own. A process that never normally opens network connections and suddenly does is suspicious.
For the wordlist variant, MITRE adds one more signal: large quantities of requests from a single source.
Put that into practice with the logs you probably already have:
- Firewall and flow logs: one source touching many destination addresses or many ports in a short window.
- Web server and WAF logs: a burst of requests for paths that do not exist, from one client, returning mostly 404 responses.
- Internal sensors: any internal host that starts probing its neighbors. External scanning is background noise. Internal scanning is a finding.
Be honest about the limits. Scan traffic is high volume and mostly harmless, so alerting on every probe will bury your team. A better use of the data is trend and correlation. Did a scan come from the same source that later tried a login on your VPN? Did the probing focus on one product you happen to run?
How to reduce the risk
MITRE is blunt here. Its mitigation entry, labeled Pre-compromise, says this technique cannot be easily mitigated with preventive controls because it is performed outside the scope of enterprise defenses. The advice is to minimize the amount and sensitivity of data available to external parties.
That reframes the job. You cannot stop the scan. You can make the answer boring.
- Know what is exposed. Keep a current inventory of public addresses, hostnames and open ports, and compare it with what you think you expose.
- Close what is not needed. For the wordlist sub-technique MITRE lists Disable or Remove Feature or Program: remove or disable access to systems, resources and infrastructure that are not explicitly required to be available externally.
- Trim banners and version strings where the product lets you, since scans harvest software and version numbers from them.
- Patch what must stay public, starting with the services an attacker would pick first.
- Keep management interfaces off the public internet.
Check your own environment
Run these against infrastructure you own and are authorized to test.
Listing what a host exposes (Linux, ss from iproute2):
ss -tulpn
Checking what a web server answers about itself (any OS with curl):
curl -sI https://your-domain.example
Look at the Server and X-Powered-By headers. If they name exact versions you do not want public, that is a configuration item to fix.
Then review:
- Does every internet-facing port have an owner and a reason?
- Do you alert on one source hitting many ports or many paths?
- When a scan finds a new service, does anyone get told?
Try it yourself
Continuous monitoring is the habit that turns a one-time exposure review into something that notices change.
Click through it at your own pace, or open it full screen.
Quick check
Can you prevent active scanning with a firewall rule?
Not in a way that matters. MITRE says the technique is performed outside the scope of enterprise defenses, so the realistic goal is to limit what a scan can learn and to watch for follow-on activity.
Which detection signal does MITRE call out for wordlist scanning?
Large quantities of requests originating from a single source.
