AN1450: Analytic 1450
Remote knock sequence followed by PF/socketfilterfw rule update or a background process listening on a new port; then a successful TCP session. Also flags WoL magic packets on local segment.
Analyst context for executives and security teams
This analytic is about spotting a macOS system that appears to become reachable only after a trigger sequence: a remote “knock,” a PF or socketfilterfw rule change, or a new background listener, followed by a successful TCP connection. It also calls out Wake-on-LAN magic packets on the local segment. For leaders, the value is not the knock itself; it is whether the organization can prove that unexpected exposure of macOS services would be noticed before it becomes an incident-handling surprise.
Executive priority
Prioritize this where macOS endpoints or servers are material to operations, administration, or privileged workflows. The business question is whether security teams can validate changes in host firewall posture, new listening services, and successful inbound sessions with enough fidelity to support incident response, audit evidence, and control assurance. Because no tactic or relationship context is supplied, treat this as a detection-readiness analytic rather than evidence of a specific campaign or threat actor.
Technical view
For SOC and detection engineering, validate telemetry on macOS for PF and socketfilterfw rule updates, process creation or persistence leading to a new listening port, network connection events showing successful TCP sessions, and local-segment Wake-on-LAN magic packets. The analytic description implies correlation across sequence and timing: trigger-like network activity, host firewall or listener change, then successful TCP connectivity. Since ATT&CK provides no official detection text beyond the description, local tuning must define what constitutes an expected firewall change, authorized listener, or legitimate WoL event.
Likely telemetry
- macOS host firewall configuration changes, including PF and socketfilterfw activity
- Process execution and background process telemetry for services that begin listening on new ports
- Network connection logs showing inbound or successful TCP sessions
- Endpoint or network sensor evidence of newly opened listening ports
- Local network telemetry capable of observing Wake-on-LAN magic packets
Detection direction
- Correlate remote knock-like traffic with subsequent macOS firewall rule updates or a newly listening background process, then a successful TCP session.
- Baseline approved PF/socketfilterfw changes and known administrative tooling to reduce false positives.
- Alert on new listening ports when there is no corresponding approved change or expected application behavior.
- Validate whether network monitoring can actually see local-segment Wake-on-LAN magic packets; many centralized logs may miss them.
- Avoid overfitting to a single port or sequence because the supplied analytic does not specify ports, protocols beyond TCP success, or exact timing windows.
Mitigation priorities
- Maintain approved-change processes for macOS firewall rule modifications and service exposure.
- Restrict who can modify PF/socketfilterfw settings and run persistent background listeners.
- Reduce unnecessary inbound reachability on macOS assets and review exposed services regularly.
- Ensure endpoint and network logging are retained long enough to reconstruct the knock-change-connect sequence during incident response.
- Document accepted Wake-on-LAN usage and monitor for unexpected local-segment activation patterns where operationally relevant.
Analyst notes and limits
This is a detection analytic object, not a full ATT&CK technique entry. The supplied fields identify macOS as the platform and describe a behavioral sequence involving remote knock activity, firewall or listener changes, successful TCP connectivity, and Wake-on-LAN packets. No ATT&CK tactics, relationships, aliases, labels, or official detection implementation details were supplied.
The source does not provide tactic mapping, related techniques, data components, exact event IDs, timing thresholds, ports, commands, or validated detection logic. Any production rule must be built and tested against local macOS administration patterns, network visibility, and change-control evidence.
Analytic 1450
Remote knock sequence followed by PF/socketfilterfw rule update or a background process listening on a new port; then a successful TCP session. Also flags WoL magic packets 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 | 42fa9ead6b77… |
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 AN1450Open 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.