Every internet-facing VPN portal, single sign-on page and API endpoint you run is scanned constantly, and the hard part is not seeing the scans but telling the background noise from the probe that precedes an intrusion. MITRE ATT&CK T1595 Active Scanning (tactic Reconnaissance, TA0043) covers adversaries probing your infrastructure over the network: scanning IP blocks, scanning for vulnerabilities and wordlist scanning for content, directories and cloud storage. Unlike most reconnaissance it touches your systems, so it leaves logs, but alerting on every scan is detection theatre. This guide frames T1595 as exposure reduction and triage: what to take off the internet, how to triage scan telemetry for identity edges (VPN, SSO, MFA and exposed API endpoints, including probes for leaked keys), how to separate mass scanning from targeted reconnaissance, and how to measure and test it. It is for SOC analysts, detection engineers, network and identity platform owners. For the continuous external inventory itself, see the Attack Surface Management Guide; this page stays on the scanning technique.
Key takeaways
- Exposure decides the outcome. ATT&CK's mitigations are M1056 Pre-compromise and, for wordlist scanning, M1042 Disable or Remove Feature or Program: remove anything not explicitly required to be reachable from outside.
- Scanning to exploitation can take a day. After the Ivanti Connect Secure disclosure on 10 January 2024, Volexity reported mass exploitation from 11 January and compromise evidence on over 1,700 devices by 14 January.
- Identity edges are the priority. VPN gateways, SSO portals, MFA and token endpoints and management interfaces are where a successful probe turns into credentials and sessions.
- Triage by intent, not volume. Internet-wide scanners hit IP addresses with generic checks; targeted reconnaissance uses your hostnames, product-specific paths and follows up with authentication attempts.
- Scan yourself first. Knowing what an attacker's scan returns, and fixing it before they run it, is the most reliable control for T1595.
What ATT&CK v20 says T1595 covers
ATT&CK defines active scans as those where the adversary probes victim infrastructure via network traffic, as opposed to reconnaissance that involves no direct interaction. Results reveal opportunities for further reconnaissance (T1593 Search Open Websites/Domains, T1596 Search Open Technical Databases), resource development and initial access such as T1190 Exploit Public-Facing Application and T1133 External Remote Services. The platform is PRE.
| Sub-technique (v20) | What it is | v20 mitigations | Data components (detection strategy) |
|---|---|---|---|
| T1595.001 Scanning IP Blocks | Scanning public address ranges allocated to the victim, from simple ICMP to banner and version collection | M1056 | DC0078 Network Traffic Flow, DC0085 Network Traffic Content (DET0817) |
| T1595.002 Vulnerability Scanning | Checking whether a host's software, version or configuration matches a specific exploit, usually via banners, listening ports or other network artefacts | M1056 | DC0078, DC0085 (DET0867) |
| T1595.003 Wordlist Scanning | Iterative brute-force and crawling to find content and infrastructure (pages, directories, admin portals, subdomains, cloud storage buckets), not credentials | M1042, M1056 | DC0085 (DET0868) |
MITRE's analytics advise monitoring for uncommon data flows, traffic that does not follow expected protocol standards, and large quantities of traffic from a single source, especially one known to be associated with an adversary or botnet. Wordlist scanning is distinct from T1110 Brute Force: the goal is finding things to attack, not valid passwords. The AI system equivalent is covered in AML.T0006 Active Scanning.
How adversaries use it: cases
- VPN appliances after disclosure: during the Cutting Edge campaign (C0029), ATT&CK records threat actors using the publicly available Interactsh tool to identify Ivanti Connect Secure VPNs vulnerable to CVE-2024-21893. The Ivanti Connect Secure Exploitation 2024 analysis shows what followed: harvested user credentials, and CISA's advice to assume service account credentials stored on affected appliances were compromised.
- Government and critical infrastructure ranges (Ember Bear, G1003): ATT&CK records the group targeting IP ranges for vulnerability scanning and using publicly available tools such as MASSCAN and Acunetix against public-facing infrastructure.
- Mass vulnerability sweeps (Magic Hound, G0059): ATT&CK records widespread scanning for public-facing systems vulnerable to Log4j CVE-2021-44228 and the ProxyShell Exchange vulnerabilities.
- Container and cloud services (TeamTNT, G0139): ATT&CK records scanning specific lists of target IP addresses and scanning for exposed resources such as the Docker API.
- Collaboration servers (C0058): during the SharePoint ToolShell exploitation, ATT&CK records threat actors scanning for SharePoint servers vulnerable to CVE-2025-53770.
- Directory and subdomain discovery (Volatile Cedar, G0123; APT41, G0096): ATT&CK records wordlist tooling used to brute-force web directories and DNS subdomains.
- AI-orchestrated scanning (C0062): ATT&CK v20 records an adversary using an AI coding agent to scan infrastructure across a target's IP ranges and to identify vulnerabilities and enumerate services and endpoints, which compresses the time from scan to exploitation.
The pattern for defenders: the scans that matter look for one product and one flaw, and they arrive in the days after a public advisory.
Triage of scan telemetry at identity edges
Focus on the edges where a successful probe yields credentials, sessions or tokens. The table describes what scanning looks like at each and what should raise its priority (NHI Mgmt Group recommendations, built on the ATT&CK analytics above).
| Identity edge | Scan telemetry to collect | Raise priority when | First response |
|---|---|---|---|
| Remote access VPN and SSL VPN portals | Appliance web logs, firewall flow logs, failed and unusual URL requests | Requests for product-specific paths or version files matching a recent advisory; requests that use your VPN hostname rather than the IP | Check patch and mitigation status the same day; run the vendor integrity check; watch for new admin or config changes |
| SSO and identity provider login pages | Identity provider sign-in logs, reverse proxy and WAF logs | Scanning followed within hours by username enumeration or spray from the same source or ASN | Block or challenge the source; review sign-in risk; confirm phishing-resistant MFA coverage |
| MFA, password reset and device enrolment endpoints | Identity provider audit logs, WAF logs | Repeated probing of reset or enrolment flows without completion | Rate-limit; confirm reset flows reveal nothing about account existence or registered methods |
| Exposed APIs and OAuth token endpoints | API gateway logs, WAF logs | Wordlist scanning for undocumented versions, debug or admin routes, and bursts of malformed token requests | Remove unlisted routes; check that every route requires authentication; see the API Security Guide |
| Endpoints that accept API keys | Provider audit logs, API gateway logs | Requests presenting keys you have revoked, or keys never issued to that client, especially soon after a secret leak | Treat as leaked secret validation: rotate, then trace the leak source; see the Leaked Secret Validation Detection guide |
| Management interfaces (appliance admin, hypervisor, remote desktop) | Firewall flow logs, cloud network flow logs | Any internet traffic at all | Remove internet exposure; CISA advises not exposing systems or management interfaces when not necessary |
Edge appliances also hold machine credentials: directory bind accounts, service account passwords, API keys and certificates. When a scan of a VPN or gateway is followed by exploitation, those non-human identities are in scope for rotation, as the Ivanti case showed. See the VPN and Firewall Log Detection Guide for the log sources.
Mass scanning or targeted reconnaissance?
Most scan traffic is internet background noise from research projects, search engines and botnets. Use these features to sort it.
| Feature | Mass scanning (usually lower priority) | Targeted reconnaissance (escalate) |
|---|---|---|
| Addressing | Hits IP addresses across whole ranges, including unused ones | Uses your hostnames (HTTP Host header or TLS SNI), including recently created ones |
| Content | Generic ports, banners and common paths | Paths specific to the product you run, or to a flaw published in the last few days |
| Breadth elsewhere | The same source is seen scanning large parts of the internet | The source is rarely seen elsewhere, or is new infrastructure |
| Reputation | Identified research or search engine scanner with an opt-out | Reputation shows malicious tags, or none at all |
| Follow-up | No further interaction | Authentication attempts, enumeration or exploit traffic from the same source or ASN |
| Timing | Steady background rate | Spike after a vendor advisory, or aligned with your business hours or change windows |
Commercial internet-noise datasets help with the "breadth elsewhere" and "reputation" rows. For example, GreyNoise documents a classification of scanning IPs as benign (a legitimate, identified actor with opt-out functionality), malicious (at least one observed malicious tag and not benign), suspicious (systematic probing that is neither clearly benign nor malicious) and unknown. Use any such source as context for triage, not as a block list on its own.
Cloud scan findings
Cloud providers raise findings from flow data. In AWS, Amazon GuardDuty documents Recon:EC2/PortProbeUnprotectedPort (an unprotected port probed by a known malicious host; low severity, high if the port is 9200 or 9300), Recon:EC2/PortProbeEMRUnprotectedPort (high) and Recon:EC2/Portscan (medium; your instance scanning outbound, which may be a compromised workload or an authorised scanner). GuardDuty does not raise the port probe finding for ports 80 and 443. Treat the first two as exposure findings: close the port or restrict the source range, and suppress only for deliberate exposure such as a bastion host.
Exposure reduction
- Remove what does not need to be public: ATT&CK's M1042 guidance for wordlist scanning is to remove or disable access to anything not explicitly required externally. That includes old application versions, test sites and storage buckets.
- No management interfaces on the internet: CISA's Volt Typhoon advisory AA24-038A recommends not exposing systems or management interfaces when not necessary, keeping an up-to-date asset inventory and using attack surface management to validate exposure.
- Put identity edges behind something: where you can, place VPN and admin access behind a zero trust access broker so scanners see the broker, not the appliance. See the Secure Remote Access Beyond VPN Guide.
- Patch exposed edges first: vulnerability scanning is looking for exactly the version you have not yet patched.
- Unpredictable names do not replace access control: wordlists include target-specific terms, and ATT&CK notes bucket enumeration tools built on them.
Measures that show it is working
- Exposed management interfaces: count of admin, hypervisor and remote desktop services reachable from the internet (target zero).
- Edge patch latency: hours from vendor advisory to mitigation on internet-facing identity edges.
- Self-scan coverage: percentage of public IP ranges and hostnames scanned by your own authorised scanner in the last 7 days.
- Escalated scan alerts: number of targeted-reconnaissance escalations per month and the share that led to a confirmed finding; tune if it is near zero.
- Scan-to-auth correlation: share of edge scan events automatically correlated with identity provider sign-in attempts from the same source within 24 hours.
How to implement and test
- Inventory the edges: list every public IP range, hostname and cloud endpoint, and mark identity edges (VPN, SSO, MFA, token and key-accepting APIs, management interfaces).
- Scan yourself: run an authorised external scan from outside your network and compare it with the inventory. Every surprise is a finding.
- Collect the right telemetry: flow logs and web or WAF logs from each identity edge into the SIEM, with Host header and SNI fields retained.
- Build the triage enrichment: add reputation and internet-noise context, and the correlation rule from scan to authentication attempts. Run it in report-only mode for two to four weeks to set baselines.
- Add the advisory trigger: when a vendor publishes a critical advisory for an edge product you run, raise the priority of scans matching that product for 30 days.
- Test detection: have your authorised scanner run product-specific checks against one edge from an unlisted source and confirm the escalation fires; disable the test source afterwards.
- Roll back safely: if blocking scanners breaks partner or monitoring traffic, move the rule back to alert-only and add explicit allow entries, rather than removing enrichment.
Small organisations should start with steps 1, 2 and the removal of management interfaces; that removes most of what scanning can find. Large organisations need step 4 to keep analyst workload manageable, because raw scan alerts will otherwise run to thousands a day.
Common failure patterns
- Alerting on every scan: analysts learn to ignore the queue and miss the targeted probe that follows an advisory.
- Edge patching on the normal cycle: the Ivanti Connect Secure Exploitation 2024 timeline shows mass exploitation one day after disclosure.
- Forgetting appliance secrets: patching the scanned appliance without rotating the service account passwords, API keys and certificates stored on it.
- Management interfaces left reachable "for the vendor": vendor access belongs behind a broker or VPN with phishing-resistant MFA.
- Dropping Host header and SNI from logs: without them you cannot tell hostname-targeted scans from range sweeps.
- Treating obscure paths as protection: wordlist scanning exists to find hidden admin portals and buckets.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK v20 | T1595, T1595.001 to T1595.003; M1056, M1042 | Technique definition, procedures, analytics and data components |
| MITRE ATLAS | AML.T0006 Active Scanning | Scanning of AI systems and services |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; CM-7 Least Functionality | Limit what is reachable and running at the edge |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring; SI-4(4) Inbound and Outbound Communications Traffic | Scan telemetry and triage |
| NIST SP 800-53 Rev. 5 | RA-5 Vulnerability Monitoring and Scanning; CM-8 System Component Inventory | Scan yourself first; know your edges |
| NIST CSF 2.0 | ID.AM-03, DE.CM-01, DE.AE-02, ID.RA-01 | Network flows, monitoring, analysis of adverse events, vulnerability identification |
Practitioner checklist
- Take every management interface off the internet.
- Run an authorised external scan of all public ranges and hostnames at least weekly.
- Collect flow and web logs from each identity edge with Host header and SNI fields.
- Enrich scan sources with reputation and internet-noise context before alerting.
- Correlate edge scans with authentication attempts from the same source or ASN.
- Raise scan priority for 30 days after an advisory for an edge product you run.
- Rotate secrets stored on any edge appliance that was exploited, not only patch it.
- Treat requests presenting revoked or unissued API keys as leaked secret validation.
- Review cloud recon findings and close or restrict probed ports.
Standards and references
- MITRE ATT&CK: T1595 Active Scanning
- MITRE ATT&CK: T1595.002 Vulnerability Scanning
- MITRE ATT&CK: T1595.003 Wordlist Scanning
- MITRE ATLAS: AML.T0006 Active Scanning
- CISA: AA24-038A PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure
- AWS: GuardDuty EC2 finding types
- GreyNoise: Understanding GreyNoise classifications
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Attack Surface Management Guide, VPN Security Guide, Edge Device Exploitation by Threat Actors Guide, OSINT and Reconnaissance Guide.