AN1949: Analytic 1949
Monitoring the content of network traffic can help detect patterns associated with active scanning activities. This can include identifying repeated connection attempts, unusual scanning behaviors, or probing activity targeting multiple IP addresses across a network. Monitor network data for uncommon data flows. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.
Analyst context for executives and security teams
This analytic is about using network traffic content and flow patterns to spot active scanning or probing behavior before it becomes a larger incident. For leaders, the practical value is confirming whether the organization can see repeated connection attempts, unusual network behavior, and systems communicating in ways they normally do not. That visibility supports faster triage, better incident scoping, and stronger evidence for control coverage.
Executive priority
Prioritize this as a visibility and readiness question: can the SOC prove it collects and reviews enough network evidence to identify scanning-like activity across the environment? The business risk is not the scan alone, but the possibility that early reconnaissance or abnormal internal traffic goes unnoticed, delaying containment and increasing uncertainty during an incident. This is also useful audit evidence for monitoring, detection engineering, and incident response preparedness.
Technical view
The supplied ATT&CK analytic describes monitoring network traffic content for repeated connection attempts, unusual scanning behaviors, probing across multiple IP addresses, uncommon data flows, and processes using the network when they normally do not. SOC and detection teams should validate whether network telemetry can show source, destination, frequency, protocol, and content or flow characteristics sufficient to distinguish normal service discovery and administrative activity from abnormal probing. The listed platform is PRE, and no ATT&CK tactic or relationship context was supplied, so implementation should be grounded in local network baselines rather than assumed technique mappings.
Likely telemetry
- Network traffic content where available, including protocol-level indicators of probing or repeated connection attempts
- Network flow records showing source, destination, ports, protocols, connection counts, and timing
- Firewall, proxy, IDS, IPS, or network sensor logs that capture denied and allowed connection attempts
- Endpoint or process-to-network telemetry showing processes that initiate network communication
- Asset and service inventory data to identify expected versus uncommon network data flows
Detection direction
- Validate that sensors cover the network segments where scanning or probing would be meaningful, including internal-to-internal traffic where available.
- Tune analytics around repeated connection attempts, many destinations from one source, unusual port or protocol patterns, and probing across multiple IP addresses.
- Compare process network activity against known-good behavior so that processes with new or uncommon network communication are reviewable.
- Account for false positives from authorized vulnerability scanners, asset discovery tools, monitoring systems, administrative scripts, and normal service discovery.
- Require baselining by asset role and network zone; the same connection pattern may be expected for a scanner or management server but suspicious for a user workstation.
Mitigation priorities
- Maintain an accurate inventory of approved scanners, discovery tools, management systems, and expected network paths.
- Improve network monitoring coverage before tuning detections; this analytic depends on visibility into traffic content or flow behavior.
- Segment networks and restrict unnecessary east-west communication so abnormal probing is easier to identify and less likely to spread unchecked.
- Define incident response playbooks for suspected scanning activity, including asset ownership lookup, source validation, and containment decision points.
- Review exceptions regularly so authorized scanning does not create alert fatigue or hide unauthorized probing.
Analyst notes and limits
This is a detection analytic object, not a technique or intrusion report. The official description supports defensive monitoring for active scanning-like patterns and uncommon network data flows. No relationships, tactics, aliases, labels, or official detection logic were supplied, so the take focuses on validation questions and telemetry requirements rather than specific adversary behavior.
The source object provides a short description and external reference but no formal detection logic, relationship context, ATT&CK tactic mapping, or affected production platforms beyond PRE. Local environment baselines, sensor placement, and approved scanning activity are required to determine practical detection value and alert fidelity.
Analytic 1949
Monitoring the content of network traffic can help detect patterns associated with active scanning activities. This can include identifying repeated connection attempts, unusual scanning behaviors, or probing activity targeting multiple IP addresses across a network. Monitor network data for uncommon data flows. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 787b14e3acd8… |
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]
mitre-attack AN1949Open 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.