An intruder who lands inside a network does not know where anything is, and the failed connections made while finding out are one of the earliest reliable signs of an active compromise. MITRE D3FEND names this detection Connection Attempt Analysis (D3-CAA), with the synonym Network Scan Detection, and defines it as "Analyzing failed connections in a network to detect unauthorized activity." It sits under the Detect tactic as a child of Network Traffic Analysis, and its digital artefact is Intranet Network Traffic, meaning traffic that stays inside the network's boundaries. This card covers the two methods D3FEND describes, the ATT&CK techniques D3FEND relates to D3-CAA, the log fields that carry failed connections, how to verify detection and where it falls short. It is for detection engineers and SOC teams; the wider context is in the Lateral Movement Guide.
Key takeaways
- Failures are the signal. Legitimate hosts mostly connect to services that exist. Connection attempts that get no reply, a reset or a firewall block, especially to many destinations, point to discovery or worm-like spread.
- D3FEND describes two methods. Watching for connections to unallocated IP space (a darknet inside your own network), and pattern matching on traffic that looks like sequential probing for hosts.
- D3FEND relates it to lateral movement. Through the Intranet Network Traffic artefact, D3FEND links D3-CAA to T1021 Remote Services, T1090.001 Internal Proxy, T1199 Trusted Relationship and T1210 Exploitation of Remote Services.
- The address inventory decides accuracy. D3FEND's considerations say the unallocated space inventory must be kept current, or decommissioned hosts and stale configuration produce false positives.
- IPv6 is a gap to plan for. D3FEND warns that IPv6 traffic can bypass IPv4-specific firewalls and IDS, so a CAA deployment that only watches IPv4 leaves a path open.
D3-CAA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-CAA (d3f:ConnectionAttemptAnalysis) |
| Synonym | Network Scan Detection |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis |
| Digital artefact | Intranet Network Traffic (D3FEND relation: analyzes) |
| D3FEND reference | Vectra Networks patent US20150264078A1, "Detecting network reconnaissance by tracking intranet dark-net communications" |
| Typical data sources | Network sensor connection logs, firewall deny logs, host firewall events, cloud flow logs |
| Effort | Low to start with firewall and flow logs; medium for a maintained internal darknet |
| Main limitation | Misses targeted movement to known hosts, which produces successful connections, not failures |
How it works
Method 1: connections to unallocated address space
D3FEND describes capturing network traffic to map the network, identifying both the assets in use and the address space that is unallocated, then using that map to spot connection attempts to the unallocated space. Nothing legitimate should talk to an address where no host lives, so each attempt is suspicious. The Vectra patent D3FEND cites calls these "ghost assets", including addresses that were never assigned and devices that are temporarily disabled. MITRE's analysis of the patent gives an example threshold: a host contacting four ghost assets in less than seven minutes raises an alert. Treat that as an example from the reference, not a recommended setting.
Method 2: sequential probing patterns
The second method passively inspects traffic with protocol analysers, looking at packet volumes, TCP session attributes and connection information between hosts (start time, source and destination, services), then pattern matching for traffic that appears to probe for hosts. In practice the patterns are:
- Horizontal sweep: one source, one port, many destinations, most with no reply. Typical of searching for a service such as SMB or RDP.
- Vertical scan: one source, one destination, many ports.
- Rejected bursts: many connection attempts that end in a reset or a firewall block in a short window.
- Half-open connections: SYN sent, no handshake completed, repeated across hosts.
Log fields that show a failed connection
| Source | Field and value | Meaning |
|---|---|---|
| Zeek conn.log | conn_state S0 | Connection attempt seen, no reply |
| Zeek conn.log | conn_state REJ | Connection attempt rejected |
| Zeek conn.log | conn_state RSTOS0 | Originator sent a SYN then a RST, with no SYN-ACK from the responder |
| Zeek conn.log | conn_state SH | Originator sent a SYN then a FIN, with no SYN-ACK seen |
| Zeek conn.log | history field letters (uppercase originator, lowercase responder), for example "S" with no "h" | A SYN with no SYN-ACK in reply |
| Windows Security log | Event 5157, "The Windows Filtering Platform has blocked a connection" (subcategory Audit Filtering Platform Connection) | Host firewall block, with Direction, SourceAddress, DestAddress, DestPort, Protocol and the blocking FilterRTID |
| AWS VPC Flow Logs | action REJECT; tcp-flags 2 (SYN) without 18 (SYN-ACK) | Traffic not allowed by security groups or network ACLs; SYN with no handshake |
| Suricata EVE flow events | state and reason fields, with pkts_toclient at zero | Flows that never received a reply |
Microsoft's monitoring guidance for event 5157 includes alerting on destination addresses that should never communicate with the host and on unexpected destination ports, which are the host-level form of D3-CAA. Event 5157 volume can be very high, so collect it from servers and sensitive segments first rather than everywhere.
ATT&CK techniques D3FEND relates to D3-CAA
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-CAA. The rows below are inferred through the shared Intranet Network Traffic artefact: D3-CAA analyzes it, and each technique produces it (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via Intranet Network Traffic) | What failed connection analysis can notice |
|---|---|---|---|
| T1021 | Remote Services | Technique produces Intranet Network Traffic | A host trying RDP, SMB, SSH or WinRM on many internal systems, most refusing |
| T1090.001 | Internal Proxy | Technique produces Intranet Network Traffic | A compromised host attempting to relay to internal addresses it has no reason to reach |
| T1199 | Trusted Relationship | Technique produces Intranet Network Traffic | A partner or supplier connection probing beyond the systems it is meant to reach |
| T1210 | Exploitation of Remote Services | Technique produces Intranet Network Traffic | Sweeps for a vulnerable service ahead of exploitation, the pattern of self-spreading malware |
Through the same artefact D3FEND also infers three ATT&CK for ICS relations: T0866 Exploitation of Remote Services, T0884 Connection Proxy and T0886 Remote Services. The D3FEND site also shows further experimental relations, for example T1110.003 Password Spraying and T1557.001 Name Resolution Poisoning and SMB Relay. Discovery techniques such as T1046 Network Service Discovery and T1018 Remote System Discovery are the most common cause of failed connection bursts in practice, even though D3FEND relates them to the parent Network Traffic artefact rather than to D3-CAA directly. Deeper defensive guidance for the four related techniques is in T1021 Remote Services, T1090 Proxy Defensive Guide, MITRE ATT&CK T1199 Trusted Relationship Guide and MITRE ATT&CK T1210 Exploitation of Remote Services.
Where it is implemented
Tools are named as examples of a class, listed alphabetically, not as recommendations.
| Implementation class | What it provides | Fits when |
|---|---|---|
| Cloud flow logs plus queries | REJECT records and SYN-only flows per source across a VPC | Cloud workloads where you cannot place a sensor |
| Deception and internal darknet | Unused addresses, or decoy hosts on them, that alert on any contact; see the Deception Technology Guide | You want the unallocated-space method with almost no false positives |
| Host firewall logging | Windows event 5157 or Linux firewall log entries for blocked inbound attempts on each server | Flat networks without internal sensors, or to cover segments sensors cannot see |
| Network detection and response platforms | Maintained reconnaissance and scan detections with asset context; see the NDR Guide | Large estates that want packaged detections |
| Network sensors (Suricata, Zeek) plus a SIEM | Connection logs with connection states, and IDS rules for scan patterns | You run sensors on internal segments and can write aggregation queries |
Where identity fits
Service accounts and automation hosts produce some of the most regular connection patterns on a network, so a scheduler or a monitoring server suddenly failing to reach new destinations stands out. The reverse also matters: inventory and vulnerability scanners run under privileged service accounts and generate exactly the pattern D3-CAA looks for. Allowlist those scanners by source host and schedule, and alert when the same pattern comes from any other host or at any other time. Credential-based follow-on activity is covered in D3-ANET Authentication Event Thresholding.
Implementation steps
- Collect failed connection data first. Confirm which sources you already have: internal sensor logs with connection state, internal firewall deny logs, cloud flow logs with REJECT records. Add host firewall logging on servers in segments no sensor sees.
- Build the address map. Export allocated ranges and live hosts from IPAM, DHCP and the CMDB, and mark unallocated ranges. Schedule the export so the map follows the network, as D3FEND's considerations require.
- Write the base analytics. Count distinct destinations with failed attempts per source in a short window (horizontal sweep), distinct ports per source and destination pair (vertical scan) and any contact with unallocated space. Start with conservative example thresholds and tune.
- Allowlist the expected scanners. Register vulnerability scanners, discovery tools and monitoring systems by host and schedule. Alert if their schedule or source changes.
- Cover IPv6. Confirm that sensors and firewall logs record IPv6 traffic and that the analytics include it. If IPv6 is not used, alert on any internal IPv6 connection attempt.
- Pilot and tune. Run alert-only for two to four weeks, then route high-confidence detections (darknet contact, broad sweeps from user workstations) to the on-call queue.
- Roll back cleanly. Version each analytic and disable only the noisy one; keep collecting data.
How to verify it works
- Authorised sweep test: from an approved test host outside the scanner allowlist, run a small, scheduled connection sweep against a test range during a change window and confirm the alert fires with the correct source.
- Darknet touch test: make a single connection attempt to an unallocated address and confirm it is detected.
- IPv6 test: repeat one test over IPv6 where the network carries it.
- Coverage check: list segments with no sensor, flow log or host firewall logging, and track that list to zero.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Internal segments with failed connection visibility | Rising to 100% | Scans in unmonitored segments are invisible |
| Age of the unallocated address map | Refreshed at least weekly | Stale maps create false positives |
| Authorised sweep and darknet tests detected | 100% | End-to-end proof |
| Time from first sweep event to alert | Minutes, not hours | Discovery precedes movement, so speed matters |
| Alerts from allowlisted scanners outside their schedule | Investigated every time | Scanner hosts and their accounts are attractive targets |
Limits, bypasses and failure patterns
- Quiet, targeted movement: an attacker who reads targets from Active Directory, DNS or configuration files connects only to hosts that exist, so few connections fail. Pair D3-CAA with authentication and remote session analytics such as D3-RTSD Remote Terminal Session Detection.
- Slow scans: a sweep spread over days stays below short-window thresholds. Add a long-window count of distinct failed destinations per source.
- Flat networks with no internal visibility: sensors at the internet edge never see host-to-host attempts on the same segment. Host firewall logging or segmentation fixes this; see the Network Segmentation Guide.
- Allowlists that grow: every new tool that scans is added to the allowlist, until a compromised tool host is ignored. Review the allowlist with owners each quarter.
- IPv6 left out: D3FEND specifically notes IPv6 traffic bypassing IPv4-specific firewalls and IDS.
- Worm-speed spread: self-propagating malware exploiting a remote service generates large sweeps, which D3-CAA detects well, but alerting alone does not stop it; response must include rapid isolation.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring for attacks and indicators of potential attacks, including internal traffic |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Internal managed interfaces where denied connections are logged |
| NIST SP 800-53 Rev 5 | AU-6 Audit Record Review, Analysis, and Reporting | Review of firewall and flow records |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Network monitoring and analysis of adverse events |
| MITRE D3FEND | Network Traffic Analysis, D3-CAA | Parent and technique |
Related countermeasures
- Client-server Payload Profiling (D3-CSPP): profiles successful exchanges, complementing the failure view. See D3-CSPP.
- Network Traffic Community Deviation (D3-NTCD): flags a host that talks unlike its peers. See D3-NTCD.
- Relay Pattern Analysis (D3-RPA): catches the internal proxying that follows discovery. See D3-RPA.
- Network Access Mediation (D3-NAM): the preventive side, reducing what a compromised host can reach. See D3-NAM Network Access Mediation.
Practitioner checklist
- Inventory every source of failed connection data and the segments each covers.
- Maintain an automatically refreshed map of allocated and unallocated internal address space.
- Alert on any contact with unallocated space and on broad sweeps from user workstations.
- Allowlist authorised scanners by host and schedule, and alert outside that schedule.
- Include IPv6 in collection and analytics, or alert on unexpected IPv6.
- Add long-window counts to catch slow scans.
- Collect Windows event 5157 on servers in segments no sensor sees.
- Test detection with an authorised sweep and a darknet touch on a schedule.
Standards and references
- MITRE D3FEND: Connection Attempt Analysis (D3-CAA)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-4)
- Zeek: base/protocols/conn/main.zeek (conn_state and history)
- Microsoft Learn: Event 5157, the Windows Filtering Platform has blocked a connection
- AWS: VPC Flow Logs records
- Suricata: EVE JSON format
Related NHI Mgmt Group resources: Lateral Movement Guide · NDR Guide · T1021 Remote Services · MITRE D3FEND Guide