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

AN2000: Analytic 2000

Monitor for suspicious network traffic that could be indicative of scanning, such as large quantities originating from a single source (especially if the source is known to be associated with an adversary/botnet).

EnterpriseAN2000AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

AN2000 is a detection analytic for identifying possible scanning activity by looking for unusually large volumes of network traffic from a single source, especially when that source is already associated with adversary or botnet infrastructure. For leaders, the value is early warning: scanning may be a precursor to targeting, vulnerability probing, or broader exposure discovery, so the decision question is whether the organization can reliably see and triage this activity before it becomes an incident.

Executive priority

Prioritize this analytic as part of external attack surface awareness and SOC readiness. It supports risk decisions around exposed services, vulnerability management urgency, and incident intake triage. Executives should ask whether perimeter and cloud-facing telemetry is retained, whether known-bad source context is available to analysts, and whether repeated scanning against critical systems triggers review of exposure and patch priorities.

Technical view

SOC and detection teams should validate whether network telemetry can identify high-volume traffic patterns from a single source toward monitored assets. Because ATT&CK provides no specific detection logic beyond the description, teams should define local baselines for normal inbound volume, distinguish benign internet scanning or approved testing from suspicious activity, and enrich source IPs or infrastructure with available threat intelligence where appropriate. The object lists platform PRE and no tactic context, so implementation should remain behavior-focused rather than tied to a specific intrusion phase.

Likely telemetry

  • Network flow records showing source, destination, ports, protocol, timestamps, and connection counts
  • Firewall, IDS/IPS, WAF, or edge security logs capturing repeated inbound connection attempts
  • Cloud or perimeter load balancer and access logs for internet-facing services
  • Threat intelligence or reputation context for source infrastructure when available
  • Asset inventory or exposure data to identify whether scanned destinations are business-critical

Detection direction

  • Establish thresholds for large quantities of traffic from a single source, tuned to the organization’s normal internet exposure and service patterns.
  • Correlate repeated connection attempts across many ports, hosts, or services with source reputation when available, without treating reputation alone as proof of malicious activity.
  • Account for false positives such as approved vulnerability scans, uptime monitoring, partner integrations, search engine crawlers, and broad background internet noise.
  • Prioritize alerts involving critical, externally exposed, or vulnerable assets, because the same scanning volume has different business significance depending on target context.
  • Validate logging coverage at network edges and cloud ingress points; blind spots in unmanaged cloud assets or third-party-hosted services can materially reduce usefulness.

Mitigation priorities

  • Maintain an accurate inventory of internet-facing systems so scanning alerts can be mapped to business ownership and criticality.
  • Ensure approved scanning, monitoring, and partner traffic is documented and allowlisted carefully to reduce avoidable SOC noise.
  • Use exposure and vulnerability management processes to prioritize remediation when scanning targets high-risk or unpatched services.
  • Apply network access controls, rate limiting, and service hardening where appropriate for exposed services.
  • Retain sufficient network and edge logs to support triage, incident response, and compliance evidence around monitoring of external-facing infrastructure.
Analyst notes and limits

This is a sparse ATT&CK analytic object: it provides a high-level monitoring concept but no formal detection query, tactic mapping, relationships, or technique linkage in the supplied fields. Treat it as a detection design prompt rather than a ready-to-deploy rule.

The supplied official fields do not support claims about specific adversaries, active exploitation, affected products, guaranteed detection, or impact. Local baselines, asset context, approved scanner inventories, and telemetry availability are required to operationalize the analytic.

Official MITRE ATT&CK definition

Analytic 2000

Monitor for suspicious network traffic that could be indicative of scanning, such as large quantities originating from a single source (especially if the source is known to be associated with an adversary/botnet).

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

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