AN1448: Analytic 1448
A remote host sends a short sequence of failed connection attempts (RST/ICMP unreachable) to a set of closed ports. Within a brief window the endpoint (a) adds/enables a firewall rule or (b) a sniffer-backed process begins listening or opens a new socket, after which a successful connection occurs. Also detects Wake-on-LAN magic packets seen on local segment.
Analyst context for executives and security teams
This analytic is about recognizing a possible “hidden door opens after a signal” pattern on Windows: failed connection attempts to closed ports are followed shortly by a firewall rule change or a new listening socket, then a successful connection. It also includes Wake-on-LAN magic packets observed on a local network segment. For leaders, the value is not the specific ports; it is whether the organization can prove that network signals, endpoint firewall changes, and new listeners are correlated quickly enough to support incident decisions.
Executive priority
Prioritize this where Windows systems, local network access, and host firewall policy changes are material to business continuity or compliance evidence. The key executive question is: can the SOC distinguish authorized remote administration or scanning from an endpoint that becomes reachable only after a trigger-like sequence? Coverage depends on collecting both network and endpoint evidence, not on either one alone.
Technical view
For Windows environments, validate correlation across a brief time window: a remote host generates failed connection attempts indicated by RST or ICMP unreachable responses to closed ports; the endpoint then adds or enables a firewall rule, or a sniffer-backed process begins listening or opens a new socket; a successful connection follows. Also validate visibility for Wake-on-LAN magic packets on the local segment. Because no ATT&CK detection logic is supplied, teams should implement this as a behavioral correlation using locally available firewall, process/socket, and network telemetry.
Likely telemetry
- Network sensor or packet metadata showing failed connection attempts, RST responses, ICMP unreachable messages, and later successful connections
- Windows host firewall rule creation, enablement, or configuration-change events
- Endpoint process and socket/listener telemetry showing newly opened sockets or listening ports
- Evidence of packet-sniffing or network-observing processes where available
- Local-segment network telemetry capable of identifying Wake-on-LAN magic packets
Detection direction
- Test whether the SOC can join network events and Windows endpoint events by host, remote source, port, and time window.
- Tune for sequences rather than single events: failed attempts to closed ports, followed by firewall enablement or new listener/socket activity, followed by a successful connection.
- Baseline legitimate vulnerability scans, administrative firewall changes, remote support activity, and Wake-on-LAN operations to reduce false positives.
- Check blind spots where endpoint firewall changes are logged but network failed-connection evidence is not retained, or where network sensors cannot see local-segment Wake-on-LAN traffic.
- Because ATT&CK provides no official detection query for this analytic, require local validation with known-good administrative workflows before treating alerts as high confidence.
Mitigation priorities
- Ensure Windows host firewall rule changes are governed, logged, and reviewable.
- Limit who can add or enable firewall rules on endpoints and servers.
- Maintain default-deny or least-exposure firewall posture where operationally feasible.
- Inventory and authorize tools or services that open listening sockets or perform packet capture/sniffing functions.
- Document approved Wake-on-LAN usage so unexpected local-segment magic packets can be investigated in context.
Analyst notes and limits
This object is a detection analytic, AN1448, for Windows in the enterprise ATT&CK domain. No tactics, relationships, aliases, labels, or official detection query were supplied. The strongest use is as a validation pattern for managed detection, incident response readiness, and control evidence around host firewall changes and network-triggered reachability.
The supplied ATT&CK fields do not identify related techniques, procedures, adversaries, campaigns, or active exploitation. The official detection field is not provided, so any operational rule must be built and tested against local telemetry, baselines, retention, and approved administration patterns.
Analytic 1448
A remote host sends a short sequence of failed connection attempts (RST/ICMP unreachable) to a set of closed ports. Within a brief window the endpoint (a) adds/enables a firewall rule or (b) a sniffer-backed process begins listening or opens a new socket, after which a successful connection occurs. Also detects Wake-on-LAN magic packets seen on local segment.
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 | f506dd32a343… |
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 AN1448Open 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.