T1595.001: Scanning IP Blocks
Adversaries may scan victim IP blocks to gather information that can be used during targeting. Public IP addresses may be allocated to organizations by block, or a range of sequential addresses.
Adversaries may scan IP blocks in order to Gather Victim Network Information, such as which IP addresses are actively in use as well as more detailed information about hosts assigned these addresses. Scans may range from simple pings (ICMP requests and responses) to more nuanced scans that may reveal host software/versions via server banners or other network artifacts.[1] 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).
Analyst context for executives and security teams
Scanning IP Blocks is pre-compromise reconnaissance: an adversary probes public IP ranges to learn which systems exist, what responds, and sometimes what software or services are exposed. For leaders, the risk is not the scan itself but what it enables next: better targeting, follow-on reconnaissance, capability preparation, or attempts against exposed remote services.
Executive priority
Treat this as an external attack-surface governance issue. Security leaders should ask whether the organization knows its public IP ranges, which assets respond from the internet, whether unexpected services are exposed, and whether SOC teams can distinguish routine internet noise from targeted reconnaissance. This technique supports prioritization for external exposure management, vulnerability management, incident triage, and compliance evidence showing that public-facing assets are inventoried and monitored.
Technical view
This is an enterprise ATT&CK reconnaissance sub-technique under Active Scanning on the PRE platform. MITRE does not provide official detection text for this object, but the relationship to DET0817 indicates a detection strategy exists for scanning IP blocks. SOC and detection teams should validate visibility into inbound probing across owned public IP space, including ICMP, connection attempts, service/banner requests, and unusual sequential or range-based access patterns. IR teams should correlate scan activity with later events such as searches against exposed domains, technical database exposure, capability staging indicators, or attempts against external remote services, without assuming the scan alone proves compromise.
Likely telemetry
- Perimeter firewall and router logs for inbound connection attempts across public IP ranges
- IDS/IPS or network detection logs showing scan patterns, ICMP activity, and service probes
- Load balancer, reverse proxy, VPN, and external remote service logs
- Cloud security group, network ACL, VPC flow, and internet-facing asset logs where applicable
- External attack-surface inventory and exposure management findings
Detection direction
- Validate whether monitoring covers the full set of organization-owned or allocated public IP blocks, not only known production assets.
- Look for distributed or sequential probing across many addresses, ports, or protocols, while accounting for benign internet-wide scanners and research traffic.
- Tune detections around context: newly exposed hosts, sensitive remote access services, unexpected banners, and scan activity followed by more specific access attempts.
- Use relationship context carefully: ATT&CK links this behavior to groups and a campaign, but local attribution should not be inferred from scanning alone.
- Because MITRE provides no official detection text in the supplied object, detection engineering should rely on local telemetry quality, baseline internet noise, and the related DET0817 strategy where available.
Mitigation priorities
- Prioritize pre-compromise controls: reduce unnecessary public exposure and limit information that scanning can reveal.
- Maintain an accurate inventory of public IP ranges, internet-facing systems, and externally visible services.
- Close or restrict unnecessary services, especially remote access paths, and ensure exposed services are covered by vulnerability management.
- Review public banners and network artifacts that disclose software or version details where reduction is feasible.
- Establish recurring external exposure reviews so newly allocated or cloud-hosted assets are not missed.
Analyst notes and limits
ATT&CK explicitly connects IP block scanning to gathering victim network information and possible follow-on reconnaissance, resource development, capability acquisition, or initial access through external remote services. Relationship context includes a detection strategy, a pre-compromise mitigation, the parent technique Active Scanning, and use by C0062, TeamTNT, and Ember Bear; these relationships provide threat context but are not sufficient for attribution in an individual environment.
The supplied ATT&CK object has no official detection guidance and only lists the PRE platform. Any assessment of exposure, detection coverage, business impact, or incident severity requires local evidence such as owned IP ranges, asset inventory, perimeter logs, cloud networking records, and observed follow-on activity.
Scanning IP Blocks
Adversaries may scan victim IP blocks to gather information that can be used during targeting. Public IP addresses may be allocated to organizations by block, or a range of sequential addresses.
Adversaries may scan IP blocks in order to Gather Victim Network Information, such as which IP addresses are actively in use as well as more detailed information about hosts assigned these addresses. Scans may range from simple pings (ICMP requests and responses) to more nuanced scans that may reveal host software/versions via server banners or other network artifacts.[1] 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).
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 | Active Scanning | This object subtechnique of Active Scanning. |
Groups, software, and campaigns
G1003: Ember Bear
Ember Bear is a Russian state-sponsored cyber espionage group that has been active since at least 2020, linked to Russia's General Staff Main Intelligence Directorate (GRU) 161st Specialist Training Center (Unit 29155).[1] Ember Bear has primarily focused operations against Ukrainian government and telecommunication entities, but has also operated against critical infrastructure entities in Europe and the Americas.[2] Ember Bear conducted the WhisperGate destructive wiper attacks against Ukraine in early 2022.[3][4][1] There is some confusion as to whether Ember Bear overlaps with another Russian-linked entity referred to as Saint Bear. At present available evidence strongly suggests these are distinct activities with different behavioral profiles.[2][5]
G0139: TeamTNT
TeamTNT is a threat group that has primarily targeted cloud and containerized environments. The group as been active since at least October 2019 and has mainly focused its efforts on leveraging cloud and container resources to deploy cryptocurrency miners in victim environments.[1][2][3][4][5][6][7][8][9]
C0062: Anthropic AI-orchestrated Campaign
The Anthropic AI-orchestrated Campaign was conducted in September 2025 by a likely China nexus espionage actor identified as GTG-1002. The Anthropic AI-orchestrated Campaign was a highly coordinated operation that manipulated Claude Code to perform reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting, data analysis, and exfiltration operations at approximately 30 entities in the technology, financial, chemical, and government sectors. During the Anthropic AI-orchestrated Campaign, human operators used Claude Code agents and Model Context Protocol (MCP) tools to automate cyber operations. Operators broke attacks into discrete tasks, used crafted prompts, and established personas to bypass AI guardrails, enabling the agents to execute the operations with minimal human involvement.[1][2]
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.1 | Current bundle | c50d93470bbf… |
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]
mitre-attack T1595.001Open 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.