AN1733: Analytic 1733
Detects indirect evidence of host-side indicator removal by correlating (1) local artifact creation or compromise-state-relevant activity, (2) later disappearance, alteration, or reporting loss for those artifacts or state indicators, and (3) continued application or device activity under reduced visibility. Because iOS provides weaker direct visibility into some Android-style artifact and jailbreak-indicator manipulation patterns, the defender relies more on app-private artifact lifecycle changes, managed posture shifts, and continued runtime or network activity after expected evidence disappears.
Analyst context for executives and security teams
AN1733 is an iOS mobile detection analytic focused on spotting indirect signs that host-side evidence has been removed, altered, or is no longer being reported while the device or application continues to operate. For leaders, the practical issue is visibility loss: if security, compliance, or mobile posture evidence disappears but business activity continues, teams may be making incident and access decisions with incomplete data.
Executive priority
Prioritize this analytic where iOS devices or managed mobile applications are material to business operations, regulated workflows, executive access, or incident response evidence. The decision value is not simply detecting a single artifact change; it is validating whether mobile security programs can recognize reduced visibility, posture-reporting gaps, and continued activity after expected evidence disappears. This supports incident triage, mobile access governance, audit confidence, and resilience planning for environments that rely on iOS telemetry.
Technical view
SOC and detection engineering teams should validate correlation logic across three conditions described by the ATT&CK analytic: creation or observation of local artifacts or compromise-state-relevant activity; later disappearance, alteration, or loss of reporting for those artifacts or state indicators; and continued application, device, runtime, or network activity after visibility is reduced. Because the object specifies iOS and notes weaker direct visibility into some manipulation patterns, teams should emphasize app-private artifact lifecycle monitoring, managed posture shifts, and continuity of device or application activity rather than relying only on direct host artifact manipulation signals.
Likely telemetry
- iOS managed device posture or compliance state changes
- Mobile application-private artifact creation, modification, deletion, or reporting loss where available
- Application runtime activity after expected artifacts or indicators disappear
- Device activity continuing after posture or evidence visibility is reduced
- Mobile network activity associated with the device or application
Detection direction
- Test whether telemetry can correlate artifact or state creation with later disappearance, alteration, or loss of reporting on iOS.
- Tune logic to distinguish expected application lifecycle behavior, updates, policy changes, or device management transitions from suspicious evidence loss followed by continued activity.
- Validate that continued runtime or network activity is included in the analytic; disappearance alone may be insufficient for high-confidence triage.
- Review blind spots caused by iOS visibility limits, app-private storage boundaries, intermittent mobile connectivity, and delayed reporting from managed posture systems.
- Because no tactics or relationship context were supplied, avoid over-mapping this analytic to a specific intrusion phase without local evidence.
Mitigation priorities
- Ensure managed iOS posture and application telemetry are consistently collected, retained, and available for correlation.
- Define expected artifact and reporting lifecycles for critical managed applications so abnormal disappearance or reporting loss can be evaluated.
- Harden mobile access decisions to account for reduced visibility, including escalation or review when posture evidence disappears but activity continues.
- Include mobile evidence-loss scenarios in incident response playbooks and compliance evidence reviews.
- Use local testing to confirm which iOS artifact, posture, runtime, and network events are actually observable in the organization’s tooling.
Analyst notes and limits
This is a detection analytic object for the mobile ATT&CK domain, platform iOS, external ID AN1733. The strongest use is as a coverage validation pattern for reduced mobile visibility rather than as a standalone indicator. It is especially relevant to managed detection, incident response, mobile security operations, identity/access decisions tied to device posture, and compliance evidence quality.
The supplied object provides an official description but no official detection implementation, no tactics, and no relationship context. The take is therefore limited to defensive validation guidance derived from the analytic description and iOS platform scope. Local environment telemetry, mobile management architecture, application behavior, and retention settings are required to determine feasibility and alert quality.
Analytic 1733
Detects indirect evidence of host-side indicator removal by correlating (1) local artifact creation or compromise-state-relevant activity, (2) later disappearance, alteration, or reporting loss for those artifacts or state indicators, and (3) continued application or device activity under reduced visibility. Because iOS provides weaker direct visibility into some Android-style artifact and jailbreak-indicator manipulation patterns, the defender relies more on app-private artifact lifecycle changes, managed posture shifts, and continued runtime or network activity after expected evidence disappears.
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 | aef8f57ee552… |
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 AN1733Open 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.