T1595: Active Scanning
Adversaries may execute active reconnaissance scans to gather information that can be used during targeting. Active scans are those where the adversary probes victim infrastructure via network traffic, as opposed to other forms of reconnaissance that do not involve direct interaction.
Adversaries may perform different forms of active scanning depending on what information they seek to gather. These scans can also be performed in various ways, including using native features of network protocols such as ICMP.[1][2] Information from these scans may reveal opportunities for other forms of reconnaissance (ex: Search Open Websites/Domains or Search Open Technical Databases), establishing operational resources (ex: Develop Capabilities or Obtain Capabilities), and/or initial access (ex: External Remote Services or Exploit Public-Facing Application).
Security context for executives and security teams
Active Scanning is pre-compromise probing of an organization’s Internet-facing infrastructure to learn what exists, what responds, and what may be worth targeting next. For leaders, its value is not that every scan is an incident; it is that scanning often exposes whether public assets, remote services, applications, and visible technology details are creating avoidable paths toward initial access.
Executive priority
Treat this as an attack-surface and readiness issue. The supplied ATT&CK context links active scanning to follow-on reconnaissance, capability development, external remote services, and exploitation of public-facing applications. Executives should ask whether the organization can prove what is exposed externally, distinguish routine Internet noise from focused reconnaissance, and show audit-ready evidence that pre-compromise controls reduce discoverable weaknesses. Cyber-physical environments should note the relationship to the Triton Safety Instrumented System Attack campaign as a reason to validate visibility around sensitive operational and safety-related exposure, without assuming similar activity is present.
Technical view
This is a reconnaissance technique on the PRE platform with no official MITRE detection text provided. SOC and detection teams should validate coverage for direct probes against public IP space, applications, and services, including ICMP and protocol-native fingerprinting behavior referenced by ATT&CK. Use the sub-technique context to separate detection questions for IP block scanning, vulnerability scanning, and wordlist scanning. The related DET0830 detection strategy indicates ATT&CK has a detection approach for this object, but the supplied fields do not provide its logic, so local analytics must be validated against available edge and application telemetry.
Likely telemetry
- Firewall, network security device, and perimeter flow logs showing inbound probes to public IP ranges
- IDS/IPS or network detection alerts for scanning, fingerprinting, or vulnerability-probing patterns
- Web server, reverse proxy, and WAF access logs showing unusual paths, wordlist-style requests, or technology fingerprinting
- ICMP and other protocol-level telemetry where collected at the Internet edge
- Cloud or hosting provider logs for public endpoints, security groups, load balancers, and exposed services
Detection direction
- Validate that monitoring covers externally reachable assets, not only internal endpoints.
- Tune analytics to distinguish broad background scanning from repeated, targeted, or multi-protocol probing of organization-owned ranges.
- Correlate scan sources, destination breadth, port/service diversity, request paths, and timing to identify IP block scanning, vulnerability scanning, and wordlist scanning patterns.
- Maintain allowlists or context for authorized vulnerability scanners and security research traffic to reduce false positives.
- Use scanning observations to trigger exposure review and prioritization, especially for external remote services and public-facing applications referenced by ATT&CK as possible follow-on paths.
Mitigation priorities
- Apply the related M1056 Pre-compromise mitigation theme: reduce attack surface before adversaries can identify exploitable weaknesses.
- Keep an accurate inventory of public IP ranges, domains, applications, and externally reachable services.
- Remove or restrict unnecessary exposed services and remote access paths where business need does not justify exposure.
- Harden public-facing applications and services so discovered technology details or configurations do not create easy targeting opportunities.
- Use reconnaissance findings and external exposure data to prioritize vulnerability management and incident response preparation.
Additional notes and limits
The technique is broad by design: active scans may be simple protocol probes, vulnerability checks, or wordlist-driven discovery. The most useful defensive output is usually not a single alert, but a feedback loop between SOC monitoring, attack-surface management, vulnerability prioritization, and incident response triage.
MITRE’s supplied detection field is not provided, and the related detection strategy is named but not detailed in the supplied data. The campaign relationship shows this behavior has appeared in ATT&CK campaign context, including cyber-physical relevance, but it does not establish current activity, attribution, or exposure for any specific organization. Local asset inventory and telemetry are required to determine coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Active Scanning
Adversaries may execute active reconnaissance scans to gather information that can be used during targeting. Active scans are those where the adversary probes victim infrastructure via network traffic, as opposed to other forms of reconnaissance that do not involve direct interaction.
Adversaries may perform different forms of active scanning depending on what information they seek to gather. These scans can also be performed in various ways, including using native features of network protocols such as ICMP.[1][2] Information from these scans may reveal opportunities for other forms of reconnaissance (ex: Search Open Websites/Domains or Search Open Technical Databases), establishing operational resources (ex: Develop Capabilities or Obtain Capabilities), and/or initial access (ex: External Remote Services or Exploit Public-Facing Application).
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1595.003 | Wordlist ScanningSub-technique | Wordlist Scanning subtechnique of this object. |
| Enterprise | T1595.001 | Scanning IP BlocksSub-technique | Scanning IP Blocks subtechnique of this object. |
| Enterprise | T1595.002 | Vulnerability ScanningSub-technique | Vulnerability Scanning subtechnique of this object. |
Groups, software, and campaigns
C0030: Triton Safety Instrumented System Attack
Triton Safety Instrumented System Attack was a campaign employed by TEMP.Veles which leveraged the Triton malware framework against a petrochemical organization.[1] The malware and techniques used within this campaign targeted specific Triconex Safety Controllers within the environment.[2] The incident was eventually discovered due to a safety trip that occurred as a result of an issue in the malware.[3]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Imported snapshots across ATT&CK releases(1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | b7ae943a4963… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
- [1]Botnet Scan
Dainotti, A. et al. (2012). Analysis of a “/0” Stealth Scan from a Botnet. Retrieved October 20, 2020.
Open source URL - [2]OWASP Fingerprinting
OWASP Wiki. (2018, February 16). OAT-004 Fingerprinting. Retrieved October 20, 2020.
Open source URL - [3]FireEye TEMP.Veles 2018
FireEye Intelligence . (2018, October 23). TRITON Attribution: Russian Government-Owned Lab Most Likely Built Custom Intrusion Tools for TRITON Attackers. Retrieved April 16, 2019.
Open source URL - [4]Botnet Scan
Dainotti, A. et al. (2012). Analysis of a “/0” Stealth Scan from a Botnet. Retrieved October 20, 2020.
Open source URL - [5]Botnet Scan
Dainotti, A. et al. (2012). Analysis of a “/0” Stealth Scan from a Botnet. Retrieved October 20, 2020.
Open source URL - [6]OWASP Fingerprinting
OWASP Wiki. (2018, February 16). OAT-004 Fingerprinting. Retrieved October 20, 2020.
Open source URL - [7]OWASP Fingerprinting
OWASP Wiki. (2018, February 16). OAT-004 Fingerprinting. Retrieved October 20, 2020.
Open source URL - [8]mitre-attackT1595Open source URL
- [9]mitre-attackT1595Open source URL
- [10]mitre-attackT1595Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.