Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1814: Analytic 1814

Exfiltration Over Alternative Protocols can be difficult to detect, and therefore enterprises may be better served focusing on detection at other stages of adversarial behavior.

MobileAN1814AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This ATT&CK analytic is a caution for iOS environments: exfiltration over alternative protocols may be hard to observe directly, so leaders should not assume that network monitoring alone will reliably prove or disprove data theft. The practical value is to verify whether the organization can detect related adversary behavior before or around exfiltration, rather than relying on a single late-stage signal.

Executive priority

Treat this as a coverage and assurance question for mobile security and incident response. Executives should ask whether iOS device activity, mobile network evidence, and surrounding behavioral detections are sufficient to support timely incident decisions, compliance evidence, and data-loss investigations. Because the official analytic does not provide a concrete detection rule, priority should be on validating end-to-end visibility and response readiness rather than claiming direct detection coverage.

Technical view

For SOC, detection engineering, and IR teams, this object provides limited technical logic: it references Exfiltration Over Alternative Protocol on iOS and explicitly notes detection difficulty. Teams should validate what evidence is available from managed mobile devices, mobile network paths, proxy or DNS infrastructure where applicable, and any endpoint or mobile device management telemetry that can establish context before suspected exfiltration. Since no tactic mapping, detection query, or relationship context is supplied, detection design should be environment-specific and correlated with other stages of adversarial behavior.

Likely telemetry

  • iOS mobile device management or enterprise mobility management records where deployed
  • Mobile device network connection metadata available to the enterprise
  • Proxy, secure web gateway, firewall, VPN, or DNS logs for managed mobile traffic where routed through enterprise controls
  • Application inventory, configuration, and policy compliance state for managed iOS devices
  • Incident response evidence from related pre-exfiltration or post-compromise activity

Detection direction

  • Do not rely on this analytic as a standalone detection rule; the official detection field is not provided.
  • Validate whether managed iOS traffic is actually visible to enterprise controls, especially when devices leave corporate networks or use non-enterprise connectivity.
  • Prioritize correlation with earlier or adjacent suspicious behavior because the official description states direct detection of this behavior can be difficult.
  • Document blind spots for unmanaged iOS devices, traffic not routed through enterprise inspection points, encrypted channels, and limited mobile telemetry.
  • Tune investigations to avoid over-interpreting unusual protocol or destination patterns without device, user, application, and business-context correlation.

Mitigation priorities

  • Establish mobile visibility requirements first: which iOS devices are managed, what telemetry is collected, and when traffic is routed through enterprise controls.
  • Use policy and configuration management to reduce unmanaged or unmonitored mobile data paths where business requirements allow.
  • Strengthen incident response playbooks for suspected mobile data exfiltration, including evidence sources, escalation thresholds, and preservation steps.
  • Review whether compliance and audit evidence can demonstrate mobile monitoring and data-protection controls, not just traditional endpoint or network coverage.
  • Where direct detection is weak, invest in controls and detections around earlier adversary behavior rather than depending only on exfiltration-stage alerts.
Analyst notes and limits

This is a mobile ATT&CK detection analytic for iOS with no supplied relationships and no official detection logic. Its main decision value is highlighting that direct detection of Exfiltration Over Alternative Protocol may be difficult, making telemetry validation and adjacent-stage detection important for SOC and IR readiness.

The supplied ATT&CK fields are sparse: no tactics, no detection query, no relationships, no mitigations, no groups or software, and no active exploitation context are provided. Any assessment of coverage, risk, or control effectiveness requires local telemetry, device management scope, network architecture, and incident response process evidence.

Official MITRE ATT&CK definition

Analytic 1814

Exfiltration Over Alternative Protocols can be difficult to detect, and therefore enterprises may be better served focusing on detection at other stages of adversarial behavior.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
b156edb990e48458...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle b156edb990e4…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1814
    Open source URL
Source and licensing

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.