Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

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).

EnterpriseT1595TechniqueObject v1.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

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.
Analyst 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.

Official MITRE ATT&CK definition

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).

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

3 rows
Domain ID Name Relationship / procedure
Enterprise T1595.003 Wordlist Scanning Sub-technique Wordlist Scanning subtechnique of this object.
Enterprise T1595.001 Scanning IP Blocks Sub-technique Scanning IP Blocks subtechnique of this object.
Enterprise T1595.002 Vulnerability Scanning Sub-technique Vulnerability Scanning subtechnique of this object.
Associated objects

Groups, software, and campaigns

Campaign Enterprise

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]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1056: Pre-compromise Enterprise detects · Detection Strategy DET0830: Detection of Active Scanning Enterprise subtechnique of · Technique T1595.003: Wordlist Scanning Enterprise subtechnique of · Technique T1595.001: Scanning IP Blocks Enterprise subtechnique of · Technique T1595.002: Vulnerability Scanning Enterprise uses · Campaign C0030: Triton Safety Instrumented System Attack Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1056: Pre-compromise

Pre-compromise mitigations involve proactive measures and defenses implemented to prevent adversaries from successfully identifying and exploiting weaknesses during the Reconnaissance and Resource Development phases of an attack. These activities focus on reducing an organization's attack surface, identify adversarial preparation efforts, and increase the difficulty for attackers to conduct successful operations. This mitigation can be implemented through the following measures:

Limit Information Exposure:

- Regularly audit and sanitize publicly available data, including job posts, websites, and social media. - Use tools like OSINT monitoring platforms (e.g., SpiderFoot, Recon-ng) to identify leaked information.

Protect Domain and DNS Infrastructure:

- Enable DNSSEC and use WHOIS privacy protection. - Monitor for domain hijacking or lookalike domains using services like RiskIQ or DomainTools.

External Monitoring:

- Use tools like Shodan, Censys to monitor your external attack surface. - Deploy external vulnerability scanners to proactively address weaknesses.

Threat Intelligence:

- Leverage platforms like MISP, Recorded Future, or Anomali to track adversarial infrastructure, tools, and activity.

Content and Email Protections:

- Use email security solutions like Proofpoint, Microsoft Defender for Office 365, or Mimecast. - Enforce SPF/DKIM/DMARC policies to protect against email spoofing.

Training and Awareness:

- Educate employees on identifying phishing attempts, securing their social media, and avoiding information leaks.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
b7ae943a49632aac...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle b7ae943a4963…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [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. [2]
    OWASP Fingerprinting

    OWASP Wiki. (2018, February 16). OAT-004 Fingerprinting. Retrieved October 20, 2020.

    Open source URL
  3. [3]
    mitre-attack T1595
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use