AN1794: Analytic 1794
A defender observes an application generating application-layer communications that blend with normal traffic (HTTP(S), WebSocket, DNS, mail protocols) but show deviations from enterprise baselines for that bundle ID—such as persistent background network sessions, regular low-volume polling intervals, anomalous SNI/Host destinations, uncommon DNS patterns, or uniform request/response sizing—suggesting command and control over legitimate-looking protocols without relying on tool signatures.
Analyst context for executives and security teams
This analytic matters because it focuses on iOS apps that may be hiding command-and-control style communications inside traffic that looks normal at first glance, such as HTTPS, WebSocket, DNS, or mail protocols. The business value is not in spotting a known tool signature, but in validating whether the organization can notice when a specific mobile app bundle ID starts behaving differently from its normal network baseline.
Executive priority
Treat this as a mobile security and monitoring coverage question: do security teams have enough iOS application network visibility to distinguish normal business app behavior from persistent, low-volume, or unusual communications? For leaders, the priority is confirming whether mobile telemetry, DNS/proxy records, and baseline processes can support incident decisions and compliance evidence when suspicious app communications are reported.
Technical view
For SOC, detection engineering, and IR teams, validate whether iOS network activity can be analyzed by bundle ID and compared against enterprise baselines. The supplied analytic points to deviations such as persistent background sessions, regular low-volume polling, anomalous SNI or Host destinations, uncommon DNS patterns, and uniform request/response sizing across legitimate-looking application-layer protocols. Because no official detection logic is provided, teams should focus on behavior-based baselining and triage workflows rather than signature matching.
Likely telemetry
- iOS application or mobile device management inventory with bundle ID context
- Network proxy, secure web gateway, or firewall logs showing HTTP(S) and WebSocket destinations where available
- DNS query and response logs associated with mobile devices or app activity
- TLS metadata such as SNI where collected and permitted
- Network session metadata including timing, duration, volume, and request/response size patterns
Detection direction
- Confirm whether telemetry can tie network activity back to an iOS bundle ID; without that, the analytic loses much of its value.
- Build or validate baselines for expected destinations, DNS behavior, polling intervals, session persistence, and traffic sizing per app or app category.
- Tune carefully for legitimate apps that use background sync, push-related communications, CDNs, or stable polling patterns to reduce false positives.
- Prioritize anomalies that combine multiple weak signals, such as uncommon destination plus persistent background sessions plus uniform traffic sizing.
- Document visibility gaps where encrypted traffic, unmanaged devices, privacy controls, or lack of mobile network attribution prevent confident triage.
Mitigation priorities
- Establish approved iOS application inventory and ownership so anomalous bundle IDs can be investigated quickly.
- Improve mobile network visibility through managed device controls, DNS logging, proxy/SWG telemetry, or equivalent enterprise monitoring where appropriate.
- Define incident response playbooks for suspicious mobile app communications, including device isolation, app review, and evidence preservation steps.
- Use baselining outputs to support risk reviews for mobile apps that communicate with unusual domains or maintain unexpected background sessions.
- Retain enough telemetry to support audit, compliance, and post-incident reconstruction without assuming content inspection is always available.
Analyst notes and limits
This is a detection analytic for the mobile ATT&CK domain and is explicitly scoped to iOS. The object describes behavioral indicators of legitimate-looking application-layer communications that deviate from enterprise baselines for a bundle ID. No tactics, relationships, aliases, labels, or formal detection logic were supplied, so the most defensible use is as guidance for validating mobile network baselining and telemetry readiness.
The supplied ATT&CK object does not provide a concrete detection query, tactic mapping, related technique, mitigation relationship, procedure example, attribution, or evidence of active exploitation. Local environment baselines, managed-device coverage, and available network metadata are required before this analytic can be operationalized.
Analytic 1794
A defender observes an application generating application-layer communications that blend with normal traffic (HTTP(S), WebSocket, DNS, mail protocols) but show deviations from enterprise baselines for that bundle ID—such as persistent background network sessions, regular low-volume polling intervals, anomalous SNI/Host destinations, uncommon DNS patterns, or uniform request/response sizing—suggesting command and control over legitimate-looking protocols without relying on tool signatures.
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.1 | Current bundle | ec08198c3c93… |
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 AN1794Open 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.