AN1024: Analytic 1024
Encrypted traffic or ICMP tunneling from border routers to internal routers or unknown external IPs. Forwarded traffic shows consistent hop-to-hop relaying without matching configured VPN or expected network topology.
Analyst context for executives and security teams
This analytic matters because it looks for network devices behaving like unauthorized relay points: border routers sending encrypted traffic or ICMP tunnels toward internal routers or unknown external IPs, in ways that do not match the approved VPN design or expected topology. For leaders, the key issue is not the protocol alone; it is whether routing infrastructure could be used to move traffic through the environment outside normal visibility and change-control assumptions.
Executive priority
Prioritize validation if network routers are critical to business continuity, segmented operations, regulated environments, or cyber-physical connectivity. Executives should ask whether the organization has an authoritative network topology, an approved VPN/tunnel inventory, and telemetry from border and internal routers sufficient to prove that unexpected relaying would be noticed. This is also useful audit evidence: defenders can show whether router-to-router traffic patterns align with documented architecture and change approvals.
Technical view
For SOC, detection engineering, and IR teams, this analytic should be treated as a topology-and-telemetry validation problem on Network Devices. Confirm whether border-router flows to internal routers and unknown external IPs are logged, whether encrypted and ICMP traffic can be profiled, and whether expected VPN peers, tunnels, routing paths, and hop-to-hop forwarding behavior are baselined. Since no official detection logic is provided, implementation should focus on deviations from configured VPNs and expected network topology rather than simple presence of encryption or ICMP.
Likely telemetry
- Network device flow records from border and internal routers
- Router interface and forwarding logs where available
- VPN/tunnel configuration and session metadata
- ICMP traffic summaries and flow patterns
- Encrypted traffic flow metadata such as source, destination, ports/protocols, volume, and timing
Detection direction
- Build allowlists or baselines from approved VPN peers, expected router-to-router paths, and documented topology before alerting on deviations.
- Look for consistent hop-to-hop relaying from border routers to internal routers or unknown external IPs that lacks a matching approved tunnel or route design.
- Treat ICMP tunneling indicators carefully: legitimate diagnostics, monitoring, and network troubleshooting can generate ICMP activity, so correlate with persistence, volume, destinations, and topology mismatch.
- For encrypted traffic, avoid assuming maliciousness from encryption alone; prioritize unexplained encrypted flows between network devices and unrecognized external destinations.
- Validate blind spots around router telemetry retention, NAT visibility, asymmetric routing, unmanaged network devices, and incomplete topology documentation.
Mitigation priorities
- Maintain an authoritative inventory of routers, approved VPN tunnels, routing relationships, and expected external peers.
- Ensure border and internal network devices produce sufficient flow or forwarding telemetry for SOC review and incident response.
- Restrict router-to-router and router-to-external communications to documented business and operations requirements where feasible.
- Use change control to reconcile new tunnels, routes, peers, or encrypted paths against security monitoring baselines.
- Review segmentation and management-plane protections so unexpected relay behavior on network devices is easier to contain and investigate.
Analyst notes and limits
This object is a MITRE ATT&CK detection analytic, AN1024, for the enterprise domain and Network Devices platform. The strongest decision value is in verifying whether monitoring reflects the real network design. Detection quality will depend heavily on local topology documentation, VPN inventory, router logging, and flow collection.
The supplied ATT&CK object provides a description but no official detection logic, no tactics, no related techniques, and no relationship context. This take therefore avoids attribution, impact claims, active exploitation claims, or guaranteed coverage. Local environment evidence is required to define normal topology and acceptable tunnel behavior.
Analytic 1024
Encrypted traffic or ICMP tunneling from border routers to internal routers or unknown external IPs. Forwarded traffic shows consistent hop-to-hop relaying without matching configured VPN or expected network topology.
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 | 1c7899cad015… |
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 AN1024Open 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.