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

DET0817: Detection of Scanning IP Blocks

DET0817 is a detection strategy for recognizing reconnaissance where an adversary scans an organization’s public IP blocks. For executives and security lea...

EnterpriseDET0817Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0817 is a detection strategy for recognizing reconnaissance where an adversary scans an organization’s public IP blocks. For executives and security leaders, the value is not simply “seeing scans”; it is confirming whether the organization can distinguish routine internet noise from reconnaissance against its own address space early enough to inform exposure management, SOC triage, and incident readiness.

Executive priority

Prioritize this as an external visibility and resilience question: do security teams know which public IP ranges belong to the organization, are those ranges monitored, and can scanning activity be turned into useful risk decisions? Coverage can support vulnerability prioritization, incident scoping, and audit evidence that externally reachable assets are being watched. Because the ATT&CK object provides no official detection logic or platforms, leadership should ask for evidence of local implementation rather than assume coverage from the ATT&CK entry alone.

Technical view

This detection strategy is linked to ATT&CK technique T1595.001, Scanning IP Blocks, under reconnaissance on PRE platforms. SOC and detection engineering teams should validate visibility over inbound activity targeting organization-owned public IP ranges, especially patterns that touch many sequential or related addresses. Incident responders should treat detections as context for external reconnaissance and correlate with asset inventory, exposed services, and vulnerability management data before escalating. The supplied ATT&CK object does not define specific analytics, thresholds, or data sources, so tuning must be environment-specific.

Likely telemetry

  • Public IP address ownership and allocation inventory
  • Perimeter firewall, router, or network security logs showing inbound connection attempts
  • IDS/IPS or network detection events for scanning-like behavior
  • Cloud or hosted perimeter network flow logs where public IP blocks are used
  • Web, VPN, remote access, and other internet-facing service logs

Detection direction

  • Validate that detections are scoped to IP ranges the organization actually owns or operates; stale IP inventories can create major blind spots.
  • Look for activity distributed across many addresses in a block rather than only repeated attempts against a single host.
  • Correlate scan-like activity with known exposed services and vulnerability data to support prioritization rather than generating low-value alerts.
  • Tune for common false positives such as benign internet scanning, security research, third-party monitoring, or internal assessment activity where authorized.
  • Because ATT&CK provides no official detection text for DET0817, require local documentation of analytic logic, thresholds, exclusions, and triage workflow.

Mitigation priorities

  • Maintain an authoritative inventory of public IP blocks and externally exposed assets.
  • Ensure perimeter and cloud network telemetry is retained and searchable for organization-owned public address space.
  • Reduce unnecessary exposure on public IP ranges and prioritize remediation of externally reachable vulnerable services.
  • Document authorized scanning and monitoring sources so SOC teams can suppress or contextualize expected activity.
  • Use detections as reconnaissance context for incident response and vulnerability management, not as proof of compromise by themselves.
Analyst notes and limits

The strongest decision value of DET0817 is in connecting external reconnaissance visibility to asset ownership, exposure management, and SOC triage. The related ATT&CK technique describes adversaries scanning victim IP blocks to identify active addresses and host details, but the detection strategy entry itself is sparse and does not provide official analytics.

Official description, official detection text, platforms, and tactics are not specified for the detection strategy object. The only supplied relationship is that DET0817 detects T1595.001, Scanning IP Blocks. Any concrete thresholds, data source mappings, platform assumptions, or coverage claims require local environment evidence.

Official MITRE ATT&CK definition

Detection of Scanning IP Blocks

No official description is available in the imported ATT&CK source object.

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

Techniques used

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1595.001 Scanning IP Blocks Sub-technique This object detects Scanning IP Blocks.
Relationship explorer

All related ATT&CK context

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
22e2d940b31ca9c9...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 22e2d940b31c…
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.

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]
    mitre-attack DET0817
    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.